Slashdot Mirror
Making BitTorrent Clients Prioritize By Geography?
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."
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.
http://www.dieblinkenlights.com
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.
Jumpstart the tartan drive.
At Napster I wrote a system to weight peers that were closer to the person searching by using network distance.
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.
When I was in my first year at college, we were asked to produce a questionnaire about using ATMs, including the question: "If you could change one thing about your bank's ATMs, what would it be?"
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?
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.)
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.)
This is worth reading about P4P: http://torrentfreak.com/uncovering-the-dark-side-of-p4p-080824/