Latency Prioritizer

[DeathfireD]

I've been reading a lot about p4p that the ISP's are trying to adopt
to replace p2p. It sounds interesting, one thing that got my eye was
how they determine where and who to share with. Apparently they have a
server side program that sends back a connection map of people within
your state or region that are currently offering the same file. Then
it connects to them.

Anyway, it got me thinking, why not add a latency prioritizer feature
and option into bittorrent? Our client could do a latency check on IPs
trying to connect to us and for us trying to connect to IPs. That way
your client knows to only connect to people with lower then xxx ping
latency and prevents the rest from connecting until you run out of low
latency IPs. An option to specify the max latency and max connections
before applying this latency check in the client could be added so
advanced users could alter the default setting at anytime to improve
their speeds. If anyone connects with a higher ping then the set value
after that torrent has reached it's max number of sources, your client
would then start to block them from making a connection to that
specific torrent in your client.

I suppose there are some draw backs to this idea that would need to be
thought about.
1) Trackers located in other country's may end up having really bad
latency so if the client doesn't know that the IP your connecting to,
or receiving data from is a tracker's ip, you may find your self
blocking the tracker from updating your peers list. I'm guessing the
simple solution to this would be to not apply the latency check to
http traffic coming and going from the bittorrent client. Trackers use
the http protocol to send and receive the peers if I'm not mistaken.
If I am wrong, then something would need to be put in place to prevent
tracker blocking.

2) a set max latency value may slow down your torrent overall if only
two people have the torrent and their located half way around the
world on a slow connection. Your client would clearly block them
leaving you with 0 sources. So an algorithm would have to be thought
up to prevent such things. As I suggested above, a simple solution to
this is if a torrent has more then xxx (some value set in the options
panel) start applying the latency check, else don't do anything and
accept and share data like you normally do.

So it would look something like this:

$max_latency_connections = 10;

If connections_for_torrent >= $max_latency_connections {
Start_applying_latency_checks()
}else {
share_data_like_always
}

function Start_applying_latency_checks() {
$max_ping = 1second;

if (ping > $max_ping) {
reject connection and refuse to make any connections to that person
for xxx number of hours.
} else{
make connection and start sharing.
}

}

3) Once the max number of connections is reached and the latency check
starts. If all the connections happen to have higher latency then your
set value, then your client will end up disconnecting from them all.
Then we start back at step one. This could potently be a never ending
loop so something would need to be thought up on how to prevent this.
Possibly to not do a latency check on the first people that connected
to you at the start or something.

4) Disconnecting peers in the middle of sharing. It may become a
problem if your in the middle of sharing with peers and the client
disconnects them because of bad latency. I’m guessing the data would
be fine and you would just start downloading data from someone else
but then again I’m not 100% on how clients share the data chunks. I
suppose a simple yet stupid solution to this would be to only apply a
latency check when a user is attempting to connect to you or your
attempting to connect to them. Like I said, stupid but it's all I
could come up with.


Anyway I thought I'd toss this idea out there since bittorrent really
does cause a lot of latency when in use and this may help slow that
down a bit. I've also noticed a lot of discussion and blog posts on
bittorrent's latency problems and I'm pretty surprised nothings been
done to solve them. QoS is not the answer to everything.