[BitTorrent] hash-based requests

Justin Cormack justin at street-vision.com
Tue Feb 15 16:33:03 EST 2005

> >From: Justin Cormack <justin at street-vision.com>
> > Have been thinking about the idea of making all requests and have messages
> > refer to hashes rather than block offsets.
> Makes a lot of sense for REQUEST and PIECE messages, turns out to make
> a lot less sense for HAVE. BITFIELD/HAVE are about maintaining a bitmap,
> a data structure almost completely unrelated to large blobs of data
> indexed by a 20 byte string.

Maybe that is the case. Certainly havent come up with any other way of dealing
with the problems.
> > It all works pretty well except that at the beginning when you only have the
> > root hash, you can be sent a have message for a block you know nothing about
> > because you dont yet have the tree (you dont even know which torrent it is
> > from yet). Has anyone thought of a solution to this yet? You could store them
> > but this gives a potential DoS by just making up random numbers and saying you
> > have those pieces.
> If HAVE messages are somehow indexed to tree location, then it works
> pretty well.

You can encode the path down a binary tree (left = 0, 1 = right) as the
HAVE message payload. Thats fairly independent of how (if at all) you
actually index your nodes. You can with non binary trees too if you insist...
> > The other alternative is a two-phase protocol where you first obtain the Merkle
> > tree before you can do anything else.
> I'm working on a sample implementation which computes the hashes, and
> uses a midsize branching factor. Turns out working with n-ary trees isn't
> always easy.  %-)

Its almost never worth it. Possbly never... Whats your reason for not using

Yahoo! Groups Links

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

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

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

More information about the BitTorrent mailing list