[BitTorrent] hash-based requests
ehem at m5p.com
Tue Feb 15 19:41:09 EST 2005
>From: Justin Cormack <justin at street-vision.com>
> > 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...
Problem is this turns back into a variable length string.
> > > 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
I'm working with block size divided by hash size as the branching factor.
This results in a node fitting into a single message. At the same time
a block of hashes can be accounted for like a payload block. Should also
mollify the folks looking for a flatish tree (2TB with only 3 levels).
Problem is computing the indicies correctly. %-)
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\ ( | EHeM at gremlin.m5p.com PGP 8881EF59 | ) /
\_ \ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
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