[BitTorrent] BT2 & hash trees
ehem at m5p.com
Mon Jul 26 21:01:20 EDT 2004
>From: Mirco Romanato <painlord2k at libero.it>
> Elliott Mitchell wrote:
> >This assumes you can find the same file on their networks. Possible, but
> >highly non-trivial. This would also require a lot of work to keep them
No comment on the above?
> >Does anyone have plans to implement such a feature on any client? I
> >suppose it is a thought, but I'm *very* doubtful of the usefulness.
> Shareaza already implement Gnutella/G2/eDonkey2000/BitTorrent protocols
> and networks
> It can also search for alternate sources for dead torrents using G2.
Hmm, with them implementing that many, perhaps implementing one more
won't be a problem. Has BT1's failure to follow THEX's recommendations
harmed its popularity? Will following THEX actually save them a
significant amount of work?
> If BT2 implement standard THEX and standard hashes it could work even
> better than now.
Better in what way?
> >True, but I must bring up the question of whether it is even worth
> >bothering attempting to verify 1KB blocks, even if you have that ability.
> >All existing BitTorrent clients transfer data in blocks of 16KB or 32KB.
> >As a result, every 1KB sub-block of a 16KB block is going to of come from
> >*one* peer.
> You have the root hash of the 16 KB chunk in the THEX standard, then you
> can check this chunk.
> No need to check under this.
> The question is "because develop a custom Merkle tree when THEX is
> To save a few CPU cycles?
Please read earlier messages. John Hoffman has produced an example
implementation that shows a huge difference in speed. Though the
difference he has shown is a great deal larger than it should be, it
*has* been shown. Now, please show a bug in John's test or acknowledge
it is valid.
As to THEX, because it isn't designed that well? I admit it will work,
but the method of distinguishing leaves and internal nodes is extremely
expensive to test if you don't already know the answer (a *full*
unconditional factor of two).
(both Python's and libcrypto's implementation allow you to enter some
data into the hash structure, then duplicate that structure; appending a
cookie and producing two hash values is cheap, by contrast doing doing a
prefix as THEX suggests *cannot* be done without rehashing the entirety
of the data)
> >>Here is where I gain something if the block size used in BT is the one I already
> >>use: If I create a torrent for any file with my software, I will not even
> >>recompute the hashes to create the torrent but use my default hash tree. In case
> >>the tracker fails, I can easily query a p2p network (in my case that would be
> >>Gnutella) for the root hash of a file because this root hash will be created by
> >>default by any node in the network. Of course I could also use a non-standard
> >>extension to the torrent file I create but that would not be in my best interest.
> >I have to doubt someone who is grabbing torrents will want to bother with
> >another P2P network.
> Again SHAREAZA bother.
> And Morpheus
> And a few other I suppose
Those implement BitTorrent as a secondary transfer mode, not a primary
one. They are P2P apps of another form before they are BT clients. Please
list a program that is a BT client first that handles the other transfer
(\___(\___(\______ --=> 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 Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
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