My university’s Internet connection went down this Friday afternoon and that caused LimeWire to lose its connection. However, since the local campus network stayed up I figured now would be a time to see if I could make a local connection. I had from before a list of local IPs to try and only one of them worked but when I downloaded files from that host man was the speed fast (450 KB/s). Normally I get 2 KB/s for downloads.

That got me to thinking: why doesn't LimeWire prefer local hosts? For one thing the downloads would be faster since intranet speeds are better than on the Internet and the file doesn't have to travel as far. Also, this would reduce the amount of bandwidth needed on the backbone for peer to peer. A complaint that universities and ISPs give about peer to peer is the amount of Internet bandwidth it consumes since that part of the network costs money on a regular basis and is one of the first things that fills to capacity as usage increases. LAN bandwidth is typically much more substantial and has lower recurring costs.

Also, connections would be more reliable since there are fewer hops between hosts. Perhaps being overly general here, you probably are looking for files that other hosts in your geographic area (ISP) have so you are more likely to get relevant search results.

In terms of how this idea would be implemented in LimeWire there would be two points where the preferencing would be used: establishing handshake connections and downloads. The local preference method would work like this (my IP here is 12.34.56.78): when presented with a list of IPs to connect or download from if the IP is 12.34.56.*, try this host first. If this fails or there are no matches go up another level to 12.34.*.*. Still nothing try, 12.*.*.*. At this point if no connection or download is carried through try the rest of the list like before.

A problem that I see with this idea is if the local preferencing works too well then the network would turn into islands that would be separated based on subnets and ISPs. A fix for this potential problem is to always maintain one non-local connection. This reaching out would also ensure that available content remains geographically diverse.

It would take a critical mass of servents with this localization feature for download speeds to increase most of the time. Other local hosts you are connected to but don't have this feature would connect to distant hosts, not preferring locals. Your first hop would be local but the rest of the hops would be distant.

Ideally with local preferencing on your entire horizon and with three connections, two local and one distant, about two-thirds of your search results would be from local hosts and one-third would be from distant hosts.