[BitTorrent] BT2 & hash trees
ehem at m5p.com
Tue Aug 10 19:46:01 EDT 2004
>From: Mirco Romanato <painlord2k at libero.it>
> Elliott Mitchell wrote:
> >>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?
> The assumption that the same files can not be finded in the filesharing
> network is false.
> Actually, when a torrent die and Shareaza users have incomplete
> torrents, thay are able to (Manually - sic.) search for the single files
> over the networks Shareaza connect.
> But they need to search using keywords and looking for the right
> filesize, hoping to find the right copy of the files.
_I_'m assuming something? Seems like you're almost agreeing that it is a
non-trivial exercise to find the same file on Shareaza...
> >>>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?
> The problem is not implementing a new Torrent standard inside Shareaza,
> I suppose this is possible but will require additional efforts.
> The problem is to keep the various standard compatible each others so it
> is possible find the same data from different sources in different networks.
> The Internet is all about common standards. They help the users and the
> developers giving them a bigger audience and a greater value.
Yes, the Internet is about common standards. The Internet is also about
having bake-offs and selecting whoever's creation works best. The OSI
created the famous seven layer burrito; the Internet folks did what
seemed right, and solved problems as they got to them. Notice which of
these can best be deemed successful.
> As for your questions, I think no and no.
> But the questions could be others:
> 1) Does BT follow common standards with other P2P networks could give
> better performance/experience to users?
Certainly possible. I'm dubious about the direct gain though. I do
strongly suspect using THEX may cause great harm to BT2, in which case
the answer would be a strong no.
> 2) Does BT follow a different standard help its users?
I think this question is almost redundant. Using another hash arrangement
will make multi-protocol clients more complex and /possibly/ harm users.
If another hash arrangement allows for faster download that will help
users. I will have to guess the latter will be the bigger deal. I
/suspect/ trying to stick to THEX /may/ cause great harm to BT2. Not
really enough in this question to change anything.
> If the .torrent file have the TTH, SHA1 and CMD4 hashes of the files ,
> it could be able to download the missing data from the filesharing
> networks (with or without using a BT application).
I cannot dispute the thrust of the above idea. Recording the THEX-style
hash of the file(s) in the .torrent should not be a great expense in file
size. My concern is that using THEX-style hashes in the BT2 _protocol_
will be a very bad thing.
I'm going to remain skeptical of the value of including that data, but
the .torrent format easily allows for extra data like that. If that is
all you want, then fine let it be an optional but defined field in
> >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).
> As someone else noted the difference is really negligible.
> And the CPU cycles are cheap compared to the bandwidth
> Again, even if this is not the most efficient way, will developing a new
> system give more?
They're cheap on a fast system with a 56kbps modem. On a slowish system
with a 1gbps link processor cycles are fairly dear.
It will certainly be trivial to make it not require running the data
through the hash twice to detect whether it is internal node versus leaf.
> The only real requirement is that all network and protocols will be
> implemented in a way that don't harm the other clients and networks.
Well, you've noted one way that qualifies, recording alternative hashes
in the .torrent files. This doesn't harm BT, while hopefully providing
you all the help you need.
(\___(\___(\______ --=> 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