[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
definition.
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 mailing list