[BitTorrent] Re: bt2 protocol features

Justin Cormack justin at street-vision.com
Wed Jun 9 19:04:35 EDT 2004

On Wed, 2004-06-09 at 21:27, Elliott Mitchell wrote:
> > 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).

You need to avoid clients that lie to try to get more bandwidth from
you. I wasnt thinking of accidents. I have heard that there are ssh man
in the middle attacks that make the beginning and end of the hash match
to make you think you have got the right host key. Just use the whole
hash, and let people choose the hash to save bandwidth if you really
want to.

> > 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).

ok, thats sounds reasonable to me. Actually I think endgame mode is
pretty unjustifiable in terms of bandwidth...



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Yahoo! Domains - Claim yours for only $14.70

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