This is what I eventually upshot.. http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html 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