[bittorrent] Re: HAVE messages

dpmott at sep.com dpmott at sep.com
Thu Jun 23 03:53:13 EDT 2005

> From: Olaf van der Spek <olafvdspek at gmail.com>
> Subject: Re: [bittorrent] Re: HAVE messages
>> True, but so long as you can see at least one copy of each piece, I'm
>> not sure that this is so important.  The whole "rarest first" algorithm
>> is an arbitrary algorithm
> No, it's not.

No, it's not arbitrary, or no, it's part of the official spec?

Don't get me wrong -- I've encouraged people to use the rarest first
algorithm.  Other algorithms may work just as well, or better under heavy
loading conditions.

>> Doesn't the tracker make available the progress (uploaded and/or
>> downloaded bytes) of each peer, if you ask for it?  If you monitor that,
> No.

Hmmm.  Clients send their 'uploaded', 'downloaded', and 'left' to the
tracker, but those numbers just get boiled down to scrape statistics.  So
I stand corrected, you can't actually monitor the progress of a peer in
the swarm (aside from receiving HAVE messages, which doesn't tell you how
much they might be uploading).  Pity.

>> Yes, I believe that this was also mentioned on the Yahoo mailing list.
>> It's a good improvement to the current protocol, no argument.  I have no
>> reason to believe that client authors are not currently doing this.
> I'm afraid your belief is wrong.

I'll update the wiki tomorrow and hopefully authors will take notice.

>> I won't argue that queueing is necessary to overcome network latency.  I
>> was trying to point out that clients should reserve the right to simply
>> drop requests (i.e. if they get flooded with requests or if requests
>> become "stale" because it is taking too long to get to them).
> In that case, a mechanism would be needed to notify the peer of the
> dropped request.

I was thinking that "no answer" would be interpreted as the notification,
but I like Elliott's idea better, which addresses your concern.

>> Well stated.  Specifically what about large numbers of connections do
>> the TCP stack implementations have issues with?  Is it just having them
>> connected, or trying to push/pull data through all of them at once?
> Both, but mainly the second part.

It seems like you have control over both your up and down bandwidth.  You
can send at whatever rate you like on each socket, and you can limit your
request for peers to send you data.  Why isn't that sufficient?


More information about the BitTorrent mailing list