[BitTorrent] Re: bt2 protocol features

Elliott Mitchell ehem at m5p.com
Wed Jun 9 16:27:21 EDT 2004


> From: Justin Cormack <justin at street-vision.com>
> On Wed, 2004-06-09 at 19:39, Elliott Mitchell wrote:
> > Assuming you use the full hash value during the request (you need all of
> > it to check the block, but not all of it is needed to make an
> > unambiguous request). A much more important question is, "Is this a
> > significant cost in bandwidth?" Figuring you might send that out 10 times
> > (once for the request, once for the response; once for the entire block
> > to announce you've got it), then the additional overhead is 160 bytes
> > total, less than 1% overhead.
> > 
> > I've almost completed two experimental implementations of this mode. I
> > carefully allowed for dropping part of the hash to save bandwidth, but
> > I'm not even sure that is significant enough to even bother with.
> 
> I wouldnt drop part of the hash. It might be nice if there was an option
> to use different hashes in bt2, but dropping it is a bad thing, as
> constructing collisions of partial hashes is apparently not too hard (ie
> has been done).

True. Notice though that this is a separate issue. Over the wire you just
need to identify which piece you're looking for. It seems unlikely
someone will be distributing a file by BitTorrent that deliberately has
two pieces with the same uppermost 32-bits of hash the same. Once in a
blue moon this will happen by accident, but you can detect this and use
more of the hash bits to distinguish these pieces (you're going to need
one hell of a large torrent before the full SHA hashes are unable to
distinguish pieces).

> Talking to peers, the overhead depends on how many have messages you
> send. When you get a block you send out one per peer, so if these are
> done by hash this is more noticeable than requests, as you might send
> out a few hundred...

The mainstream client sends requests for 16KB blocks, the full piece size
is 256KB, will connect to 35 peers and will disallow more than 55 peers.
So there will be one request/response for every 16KB so 16/piece. There
will be 1 have for every 256KB.

So assuming 50 peers, this would result in the hash being on the wire 66
times for every 256KB of payload. Using a full hash results in 16 bytes
of additional overhead, so a total of 1056 additional bytes per piece.
This is less than 0.5% increase; compare this to 30% cost for multiple
requests during the mainline client's endgame mode (using Stephan
Thomas's number).


-- 
(\___(\___(\______          --=> 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 --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/BitTorrent/

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

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 



More information about the BitTorrent mailing list