This is what I eventually upshot..<br><br><a href="http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html">http://www.telco2.net/blog/2007/08/variable_speed_limits_for_the.html</a><br><br><div><span class="gmail_quote">
On 8/19/07, <b class="gmail_sendername">Mikael Abrahamsson</b> <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Sun, 19 Aug 2007, Perry Lorier wrote:<br><br>> Many networking stacks have a "TCP_INFO" ioctl that can be used to query for<br>> more accurate statistics on how the TCP connection is fairing (number of
<br>> retransmits, TCP's current estimate of the RTT (and jitter), etc).  I've<br>> always pondered if bittorrent clients made use of this to better choose which<br>> connections to prefer and which ones to avoid.  I'm unfortunately unsure if
<br>> windows has anything similar.<br><br>Well, by design bittorrent will try to get everything as fast as possible<br>from all peers, so any TCP session giving good performance (often low<br>packet loss and low latency) will thus end up transmitting a lot of the
<br>data in the torrent, so by design bittorrent is kind of localised, at<br>least in the sense that it will utilize fast peers more than slower ones<br>and these are normally closer to you.<br><br>> One problem with having clients only getting told about clients that are near
<br>> to them is that the network starts forming "cliques".  Each clique works as a<br>> separate network and you can end up with silly things like one clique being<br>> full of seeders, and another clique not even having any seeders at all.
<br>> Obviously this means that a tracker has to send a handful of addresses of<br>> clients outside the "clique" network that the current client belongs to.<br><br>The idea we pitched was that of the 50 addresses that the tracker returns
<br>to the client, 25 (if possible) should be from the same ASN as the client<br>itself, or a nearby ASN (by some definition). If there are a lot of peers<br>(more than 50) the tracker will return a random set of clients, we wanted
<br>this to be not random but 25 of them should be by network proximity (by<br>some definition).<br><br>> You want to make hosts talk to people that are close to you, you want to make<br>> sure that hosts don't form cliques, and you want something that a tracker can
<br>> very quickly figure out from information that is easily available to people<br>> who run trackers.  My thought here was to sort all the IP addresses, and send<br>> the next 'n' IP addresses after the client IP as well as some random ones.
<br>> If we assume that IP's are generally allocated in contiguous groups then this<br>> means that clients should be generally at least told about people nearby, and<br>> hopefully that these hosts aren't too far apart (at least likely to be within
<br>> a LIR or RIR).  This should be able to be done in O(log n) which should be<br>> fairly efficient.<br><br>Yeah, we discussed that the list of IPs should be sorted (doing insertion<br>sort) in the data structures in the tracker already, so what you're saying
<br>is one way of defining proximity that as you're saying, would probably be<br>quite efficient.<br><br>--<br>Mikael Abrahamsson    email: <a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a><br></blockquote></div>
<br>