Standards (was [BitTorrent] Back to Merkle Hash Trees...)

Olaf van der Spek OvdSpek at LIACS.NL
Tue Feb 8 12:54:30 EST 2005

Justin Cormack wrote:
>>The first thing any peer does, is get the info. The info is probably 
>>very small (size depends on the file count), so would that really be an 
> I think it can be. If a lot of peers connect to a torrent at once, most wont
> have it. If you request it what should they do? You dont mention this case.

True, but my document isn't about that. The URL format is an idea for 
further extensions.

> Presumably you should only ask one peer at a time for it (or you run the risk
> of eating bandwidth by getting multiple copies) so if a small proportion of
> the peers have it it can take a long time to find them.

A have_info would solve that.

>>But what is the advantage over 32k? Do you consider 32k too large?
> Well 32k might be reasonable if piece = chunk = 32k if there is not too much
> overhead in sending out have messages. Not having piece and chunk simplifies
> things. Actually I would pick 65536, and then use 48 bit chunk numbers,
> bacause I am tidy minded that way... Its an improvement over the current
> (typical) piece size of 256k or 1M. The main reason this was so high was
> because of size of torrent file.
> Doing the maths, a 4G file with 64k pieces/chunks will have 64k of them,
> which means a bitmap is 8k, which is smaller than a request (64k) so
> thats not a huge transfer. you will get 64k have messages (worst case)
> which is 512k. These figures are per peer.
> Actually the file size for which the request size = bitmap size is:
> 64k chunk: 32G
> 32k chunk: 8G
> 4k: 128M
> With 4k pieces/chunks the bitmaps get too big (128k) especially compared
> to the transfer size which has gone down to 4k. You clearly need to change
> how these are encoded.
> In fact if we dont want to change the encoding you could specify the
> piece and chunk size by this rule...
> Your scheme where you can transfer and verify 32k chunks but cant tell
> anyone you have them until you get enough to make an arbitrary larger
> piece doesnt make much sense to me. It is a kind of lossy compression
> of have and bitmap messages in effect.

You can tell everyone that you have them if necessary/useful, that's 
what chunk_have is for.
And the disadvantage of a larger chunk size is that a peer is required 
to send the entire chunk (or to close the connection). This is related 
to the choking algorithm.

And you don't have to redownload 'chunks' if a 'piece' fails (advantage 
over BT1).

Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at

<*> Your use of Yahoo! Groups is subject to:

More information about the BitTorrent mailing list