[bittorrent] Re: HAVE messages
Olaf van der Spek
olafvdspek at gmail.com
Thu Jun 23 06:21:48 EDT 2005
On 6/23/05, dpmott at sep.com <dpmott at sep.com> wrote:
> > 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?
It's not arbitrary.
> I was thinking that "no answer" would be interpreted as the notification,
> but I like Elliott's idea better, which addresses your concern.
Well, the problem I'm having with that is that currently I see
responses come in with a delay of up to 3 hours (yes, hours). That's
of course a bug somewhere, but 'no answer' isn't a precise technical
You'd probably at least want to require in-order responses (which most
but not all clients do today).
> >> 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?
The downrate control isn't very precise.
And uprate control assumes you have a fixed amount of bandwidth
available, which isn't true either.
Also, sending on more connections is also likely to increase header overhead.
More information about the BitTorrent