Making BitTorrent Clients Prioritize By Geography? 227
Daengbo writes "While I live in S.Korea and have virtually unlimited bandwidth in and out of the country, not all my Asian friends are so lucky. Many of the SE Asian and African countries have small international pipes. Even when a user has a high-speed local connection, downloads from abroad will trickle in.
Bittorrent clients apparently don't prioritize other users on the same ISP or at least in the same country. Why is that? Is it difficult to manage? If I were to write a plug-in for, say, Deluge, what hurdles would I be likely to come across? If this functionality is available in other clients or through plug-ins, please chime in."
Non-geo-ip (Score:4, Interesting)
One would not even need to prioritize by geographic location: the client could easily give extra priority points by network class: C first, then B, then A, then the rest. The odds of having a very fat pipe to another machine in the same class C are far better than having a fat pipe to a random machine across the planet.
And that would also alleviate the load on backbone links.
Latency? Hops? (Score:4, Interesting)
How good is latency or hops as indicator of distance from peer? The idea is that if it takes 5 hops, as opposed to 10, then the peer taking the least hops to get to is the closest.
Re:Stop It (Score:2, Interesting)
No. Prioritize by ASN. A smart tracker would get a BGP feed and then hook users together based on locality of network connectivity.
Any other approach is "wrong."
Napster's Old Peer Selection (Score:5, Interesting)
It was mostly because universities were complaining and so we weighted everyone on Internet 2 towards each other, but it also worked quite well for service providers like @Home and AOL. Since ISPs don't seem to care as much when their own bandwidth is used, a lot of complaints about our bandwidth consumption disappeared overnight. Indiana state university and someone else helped out if I remember correctly.
It was a rather simple system that used BGP routing tables from a number of routers to build a graph of network connectivity. It wasn't perfect, but it didn't have to be.
That said, with IPv6 weighting is *much* easier because of how the IP space is divided up. You can do a super naive implementation just by prefix.
An Azureus plugin Ono does something similar, though I believe they just look up the IP address for a CDN and weight people that look up the same IP towards each other. It is a decent solution, but it only works for between people who are running the plugin.
Re:Azereus already has a plugin for this (Score:3, Interesting)
Re:uTorrent (Score:3, Interesting)
It's not a plugin, and it doesn't make you more or less likely to get busted. It simply searched the peer list from the tracker and prioritizes peers on the same subnet as you, and optionally removes your throughput limits.
A good feature, but it doesn't completely solve the problem, since it only works within your local subnet, and is therefore inherently incompatible with NAT.
Re:uTorrent (Score:2, Interesting)
Well not exactly, it does try to find local users, but that is more or less useless on anything larger than any single localized network, like a university, which is all good and well.
But i seriously doubt that it optimizes this in a way that takes the network infrastructure in consideration.
Even though the local peer your downloading from may be your neighbor you might just end up being routed trough Zimbabwe for all utorrent cares at this moment, especially if net neutrality is destroyed.
And that is not good for anyone.
Re:Stop It (Score:1, Interesting)
I suppose it depends on what problem you are solving. If your goal is to get a particular piece of data as quickly as possible, then if it exists on a peer on your local network, that is where you should pull it from.
If you want a file A, broken up into parts A1, A2, A3, ... A6. Parts A1 - A4 are on computers on your local network (50 Mbps) and parts A1 - A6 are on computers across the ocean (1.5 Mbps), the quickest result will be to begin fetching A5 & A6 from the slow, distant peers and begin fetching A1 - A4 from the fast, local peers. Given the general pointlessness of providing a full BGP feed to every participant in the network, putting it at the tracker is the best location. What's more is that it would be an optimization that could be done now without making any changes at the client end.
In fact, I would not be surprised to find that ISPs would raise the cap on protocols that encouraged transfers within the ISP's network.
Basically a self configuring akamai.
They're MY bits, not YOURS (Score:3, Interesting)
The most popular answer I managed to get was "if the machine's running out of money, they should restrict the cash withdrawal function to customers of this branch".
Does anyone see a parallel here?
Re:uTorrent (Score:2, Interesting)
Re:uTorrent (Score:5, Interesting)
I run rtorrent in a detached screen session on a headless FreeBSD machine tucked away in the closet. I add torrent files to it just by dropping them into rtorrent's watch folder, everything else (starting, stopping, throttle management for off hours) is taken care of automatically. I do not have to have my laptop on or listen to the desktop whine all the time. Plus, rtorrent is blazing fast AND platform agnostic.
It is also accessible in many ways, ssh being the most obvious, but there are also many GUIs available, with which you can manage torrents from afar. I like it how it is possible to add a torrent to the queue, then take a 3 hour train ride home and find it's all done for you. Magic. So, yes, a torrent client that is run in a terminal can be a Very Good Thing for those who can set it up and use it the way it was meant to be. (And I am pretty sure it was meant to be used that way.)
Re:Azereus already has a plugin for this (Score:5, Interesting)
ISPs actually like P4P. It gives the customers what they want (fast P2P) and it gives the ISPs what they want (less data sent to the tubes that they don't own, and thus reduced costs and overhead.)
That isn't what ono does (Score:3, Interesting)
Ono [northwestern.edu] uses statistical data from CDNs to be a little bit smarter about picking peers in certain cases. In most cases the random solution is fine; your client can just randomly pick peers then stick with fast ones and drop slow ones. Ono aims to improve performance in certain cases where that strategy isn't very good.
Just in case anyone reading doesn't notice, Ono aims to find peers that are close to you on the network. That doesn't necessarily mean close to you geographically and so doesn't answer this ask /..
2 meg data file could solve most of this! (Score:3, Interesting)
And I proposed it for two popular BitTorrent clients, only to be told, "we don't need that.."
Simple enough to do. Start with Class C address.. less then 2^24 of them, as some
are reserved, and not routable. Make a bitmap that big, so divide by 8.
Only a two meg file. Then just watch your connections, total by bytes received, then divide by 8. If the result is greater than say 1 kb/sec sustained, then
set the appropriate bit to true. Allow the bitmap to be zeroed if you move or whatever.
After getting the list of peers, prioritize connection attempts towards those
that have a useful sustainable rate. Nothing worse than seeing 80% of my
connections saying connected 30 minutes, 100 KB transferred. Sigh.
While in china, I had a 2 mb connection. But too many Chinese hammering it, so
I could sustain, 2 mbit up, and 1 mbit down. Asymmetric the wrong way..
Seems blindingly obvious to me, yet I still see no clients with this feature.
Re:Stop It (Score:3, Interesting)
Re:Azereus already has a plugin for this (Score:5, Interesting)