On 8/19/07, Mikael Abrahamsson <swmike@swm.pp.se> wrote:

On Sun, 19 Aug 2007, Perry Lorier wrote:

> Many networking stacks have a "TCP_INFO" ioctl that can be used to query for
> more accurate statistics on how the TCP connection is fairing (number of
> retransmits, TCP's current estimate of the RTT (and jitter), etc).  I've
> always pondered if bittorrent clients made use of this to better choose which
> connections to prefer and which ones to avoid.  I'm unfortunately unsure if
> windows has anything similar.

Well, by design bittorrent will try to get everything as fast as possible
from all peers, so any TCP session giving good performance (often low
packet loss and low latency) will thus end up transmitting a lot of the
data in the torrent, so by design bittorrent is kind of localised, at
least in the sense that it will utilize fast peers more than slower ones
and these are normally closer to you.

> One problem with having clients only getting told about clients that are near
> to them is that the network starts forming "cliques".  Each clique works as a
> separate network and you can end up with silly things like one clique being
> full of seeders, and another clique not even having any seeders at all.
> Obviously this means that a tracker has to send a handful of addresses of
> clients outside the "clique" network that the current client belongs to.

The idea we pitched was that of the 50 addresses that the tracker returns
to the client, 25 (if possible) should be from the same ASN as the client
itself, or a nearby ASN (by some definition). If there are a lot of peers
(more than 50) the tracker will return a random set of clients, we wanted
this to be not random but 25 of them should be by network proximity (by
some definition).

> You want to make hosts talk to people that are close to you, you want to make
> sure that hosts don't form cliques, and you want something that a tracker can
> very quickly figure out from information that is easily available to people
> who run trackers.  My thought here was to sort all the IP addresses, and send
> the next 'n' IP addresses after the client IP as well as some random ones.
> If we assume that IP's are generally allocated in contiguous groups then this
> means that clients should be generally at least told about people nearby, and
> hopefully that these hosts aren't too far apart (at least likely to be within
> a LIR or RIR).  This should be able to be done in O(log n) which should be
> fairly efficient.

Yeah, we discussed that the list of IPs should be sorted (doing insertion
sort) in the data structures in the tracker already, so what you're saying
is one way of defining proximity that as you're saying, would probably be
quite efficient.

--
Mikael Abrahamsson    email: swmike@swm.pp.se