HAVE messages (formerly "[bittorrent] Open letter to the BBC")

David P. Mott dpmott at sep.com
Mon Jun 20 11:30:22 EDT 2005


> Date: Sun, 19 Jun 2005 15:05:05 -0700
> From: Brian Dessent <brian at dessent.net>
> Subject: Re: [bittorrent] Open letter to the BBC
>
> That only happens if you have your client configured to allow unlimited
> (or a very large number of) connections.  [SNIP]  If there aren't
> a gazillion connections and yet still 50% of your bandwidth is 'haves',
> then that means that something is seriously wrong, since those peers
> must by definition be downloading orders of magnitude faster than you.

There was a protocol extension suggested awhile back for consolidating 
(grouping) or otherwise encoding HAVE messages.  The reasoning was that, 
for a dial-up user, the HAVE messages took up a significant amount of the 
bandwidth.  I think that the dial-up v/s broadband speeds constitutes 
something close to the "orders of magnitude" condition.

The bittorrent protocol is centered around the concept of "every peer 
knows what every other peer has at all times".  I'm still undecided if 
this is the best way to go about it.

For instance -- let's say that I wrote a protocol that was similiar to BT, 
but didn't do that whole awkward choking/choked/interesting/interested 
thing, and I didn't include HAVE messages.

Instead:
1.  Peers can request whatever they want, but I'll only service one request
     at a time and discard the rest.
2.  I'll upload at a rate that I think is appropriate.  They can block on
     their TCP/IP socket waiting for data.
3.  With #1 and #2, there's no need for
     "choking/choked/interesting/interested".
4.  The protocol provides a way to ask for the bitfield that is initially
     exchanged in the BT protocol.  Peers may ask for it initially, and
     when they get all of the pieces from me that they are interested in,
     then they can ask for the bitfield again to see if I have gotten more.
5.  If there is an absolute need to be kept periodically "up to date" on
     what the swarm looks like, then I can request the bitfield or some
     delta representation from my peers on a periodic basis.  If the
     bitfield thing is too big, then (as the extension was presented so
     long ago) a MULTIHAVE message could be included in the protocol
     and sent by my peers to me on a periodic (10 minutes?) basis.


Thoughts?  Discussion?



More information about the BitTorrent mailing list