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

Justin Cormack justin at
Tue Feb 8 13:07:11 EST 2005

> > 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.

But having *both* makes for complicated decisions (when do I use each one)
and optimisation. Whats wrong with one kind of have message which refers
to something that just got transferred.

> 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.

Well you shouldnt unchoke if you arent prepared to feed one chunk. And
so 32k is clearly ok, as thats what BT1 uses. I think scaling it by file
size makes some sense, as assuming the number of peers is not proportional
to the size of the file you are going to have to feed them more.
> And you don't have to redownload 'chunks' if a 'piece' fails (advantage 
> over BT1).

Yes thats a big advantage.

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