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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >
