[bittorrent] Why are blocks smaller than pieces?

Ludvig Strigeus strigeus at gmail.com
Sun Sep 9 04:52:58 EDT 2007

Another alternative would be to use a hash tree like tiger tree
hashes. Then all the hashes in the torrent file would be replaced by a
single hash. The hash tree would then be sent out incrementally,
allowing each client to reconstruct its hash tree enough to be able to
verify the pieces it gets.

This would allow a client to verify blocks at a block granularity, it
would decrease the size of a torrent file, for the cost of a slight
overhead in piece packets and a slight hashing CPU time increase
(<5%), and some added implementation complexity.


On 9/9/07, Guido Seifert <tanuki64 at gmx.de> wrote:
> > Well, typically requests (and therefore blocks) are 16kb (so that slow peers
> > and high latency links don't cripple swams), compared to typical piece
> > sizes, which are between 128k to 4mb or more (no real limit).
> >
> > Consider a 20gb torrent with 16kb pieces, the consequent size of the
> > .torrent file, and more importantly, the protocol overhead required to send
> > massive bitfields and the numerous HAVE messages.
> Yeah, the reason for would be quite some overhead.
> [...]
> > Hope that's useful. Certainly that is a weakness neccessitated largely by
> > the dynamics of sending (very) large files over potentially slow links, but
> > it can be worked around.
> This sure is useful and not too difficult to implement. I am by far not that
> advanced with my client that I can yet use it, but the sooner one considers such
> problem in a new design, the better. :-)
> Guido
> _______________________________________________
> BitTorrent mailing list
> BitTorrent at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/bittorrent

More information about the BitTorrent mailing list