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."
IPs could, theoretically, be prioritized based on a database of known general geographies associated with certain digits. Just remember - prioritizing is one thing, but it's a slippery slope to peer exclusion.
I've always wondered why ISPs can't give higher speeds if you stay within their network. You'd get your download faster. You'd use less peering bandwidth, costing the ISP less money. Everybody wins.
Prioritize by network topology is a better way to put it, that just happens to coincide with physical AND political geography in many cases. In the case where you can get 10Mb over a 10-hop connection, or 8Mb over a 3-hop connection, which do you pick? If you pick the latter, there is a good chance that two other users can utilize the other 70% of that 10-hop connection, making total throughput (theoretically) 24Mb.
If your ISPs international pipe is flooded then bittorrent will automatically prefer local peers as they'll be the only people who can send you data at a fast enough rate. If you notice local peers who you're not connected to then it's most likely just because they've already reached their connection limit.
Most bittorent clients will connect to many peers and try to saturate your downstream bandwidth. They don't care where in the world those peers are as long as they're fast. If, in your part of the world, local peers are faster then that means you should just automatically connect to more local peers.
Nick
The 99.5% accuracy number is considerably greater than 1/200. The accuracy figure is not a percentage of lookups that are incorrect, but of how close to the correct physical location the query result will be. Even the .5% of wrong locations won't be on the wrong side of the planet so it still makes for a very useful resource for figuring out regions.
I'm, I'll, can't, it's?
Autonomous System Number. I don't think it helps much either way. You either know what it means or you don't. Also, Border Gateway Protocol.
There is little to no support for multicast by last-mile ISPs.
It would be nice - ISPs keep bitching about how P2P is eating their bandwidth, but they don't bother implementing multicast which would make P2P use a fraction of the bandwidth it currently does.
Admittedly, in addition to lack of support, IPv4 multicast is pretty "meh" - there aren't many multicast addresses available and I have yet to see a good way of choosing/assigning them on a global network.
retrorocket.o not found, launch anyway?
That just means that ws_ftp's GUI is a pile of shit, it doesn't mean that GUIs are inherently slow.
If you mod me Overrated, you are admitting that you have no penis.
Extending a business partnership with them, and convincing them that they CAN allow users to serve content without choking their already oversold bandwidth
This is fairly easy to do right now eith US ISPs...it's called a "business account".
They do cost more, but in my case I get 5 static IPs, guaranteed bandwidth, and no interference of any kind with my data (no port blocking, no throttling, and no caps) for $140. Compared to the non-business version with one dynamic IP, port blocking and some throttling (but no caps yet) at $70, it's not a bad deal.
Actually they're both true. The OS will schedule the whole process, and react to threads; the GUI thread can overtake the network thread and the whole process will get bumped down as a unit once it's used its CPU allotment. Bad network protocol behavior, reacting to too much i/o demand, etc, and the OS will schedule a lot more CPU time to the GUI and slow down network transmission; bad programming in the UI can also affect this. In either case, the presence of a GUI or extremely active text UI will slow down network activity; it's usually by a very small amount if everyone did their homework, but it's present, even in Firefox vs. wget.
Support my political activism on Patreon.
The "barrage" of pings may not have been necessary. A good first step is simply running the IPs through a geolocation database. There are various free ones available, and it's a pretty good first step for narrowing things down. They're very effective at getting the country right, and do a decent job at getting you to at least a nearby city.
From there, if you need farther precision, a single ICMP packet is required to determine the number of hops to a host by checking the TTL. Combine these two things and it shouldn't take much work to get a list of close-by IPs.
If you're considering connecting to 1000 hosts, it would take just a few seconds (or a fraction of a second) to run them all through a geolocation database, and then a few seconds to send off the thousand pings (while 1000 pings would only require 56KB of data to be sent, you might want to send them out a bit slower than that).
All in all, I don't see why you couldn't evaluate all the IPs provided by the tracker in a matter of seconds, getting both geographic and network distances to each one. That should then be more than enough information to make decent guesses about what the best IPs to connect to are.