uTorrent Speeds Up Downloads and Counters DDoS Attacks

[Ernesto]

With well over 150 million active users a month uTorrent is by far the most used BitTorrent client.

The popular application began as a minimalist and no-nonsense client targeted at a BitTorrent-savvy crowd, but evolved into a feature-rich download tool during the years that followed.

This week the uTorrent development team released uTorrent version 3.4. Aside from the standard bug fixes, new features and aesthetic upgrades, the latest release includes one of the most significant changes in years.

Spearheaded by BitTorrent developer Arvid Norberg, the new release includes a new method of connecting people who are sharing the same file. This change is welcome, since the traditional way of choosing peers has some major drawbacks.

“If [a BitTorrent client] chooses poorly, or if there are malicious actors in the swarm, the connections between clients are not well distributed through the swarm, leading to a large number of hops from node to node. That slows down the ability to each client to pass data on to the next,” BitTorrent’s Adam Kelly explains.

With Canonical Peer Priority, as it’s called, peers will no longer be selected on a first come first serve basis.

The new peer selection method will now give priority to peers who are close in the network (fewer hops away). This means that when uTorrent has reached the maximum number of connections for a torrent, it will still accept incoming peers with a higher priority.

Instead of refusing the connection of the new peer, it will accept it and kick out a lower priority peer. This will help peers to connect to each other faster, and also reduce the distance between peers, which ultimately results in faster downloads.

In addition to increased connection times and faster downloads, the new peer selection method also prevents DDoS attacks against larger swarms.

With the old method malicious parties could flood a swarm with download requests, pretending to offer a piece of the file. By doing so, they could lock up dozens of connection slots, seriously degrading download performance by taking up space of legitimate peers.

“There’s an opportunity to DDoS a swarm by filling up everyone’s connections slots, and continuously making incoming connections at such rate that peers won’t have an opportunity to connect to anyone else,” Norberg explained.

With the new selection method this problem is solved, as low priority peers will be swapped out for newcomers who have real data to offer.

uTorrent users are not expected to notice a difference right away. The effectiveness depends on how many other peers in the swarm use uTorrent 3.4, which will be relatively low for now. However, as time changes this is expected to pick up. Whether other BitTorrent clients plan to implement the same technology has yet to be seen.

In addition to the new peer selection method and other improvements, the uTorrent team also announced that it will release newer versions of the software more quickly. In recent month there have been some complaints in the forums from users about a lack of updates and fixes.

BitTorrent Inc. has put more developers on uTorrent, so fixes and new features are expected to come out faster in the months to come. This is expected to include a paywall to unlock premium bundles from artists.

Source: TorrentFreak, for the latest info on copyright, file-sharing and VPN services.

source

[kjf]

hmmm... just because they are closer to you geographically doesn't mean they are going to be faster, or less malicious.

[NIK]

It's a typical--poorly written and misleading--TorrentFreak article but the problem they've failed to describe is a genuine one and the solution they've failed to describe isn't without merit.

The supporting links are pretty fucking dense and I haven't gotten my head around it all yet but they're not talking about geographical distance or even network distance in the "miles of cable and number of routers" sense. They're talking about the mathematical distance between numbers-which-identify-nodes-on-a-semi-abstract-overlay.

And they're not talking about the upload bandwidth of individuals at a point in time but rather the cumulative time it takes all members of a swarm to complete a download (which includes a degree of waiting time). It's the time spent waiting that they're trying to reduce on the assumption that there won't be much difference in the average upload bandwidths of the set of peers you connect to under their new scheme than the set of peers you connect to now (which is a valid starting assumption I think, though it will need proving because of the only semi-abstractness of the overlay).

[SectorVector]

This idea reminded me of this bit from Friends. "The one with Rachel's other sister"

Amy : Okay, how about this, you guys die and the crazy plate lady dies, then do I get the baby?
Chandler : No, if crazy plate lad.. If Monica dies then I would get Emma, Right?

Just wondering how "IP Address distance" translates to geographical distance.
I mean are say Sweden and Australia mathematically close, even though they are geographically far.

Also. is there a free downloadable database like this sample, for class B (pref in hexadecimal) ?
http://www.ip2location.com/samples/db1-ip-country.txt
That crc32 is puzzling. I guess it has some property which guarantees nearness of two IPs.

Nice simulation. Guess we will have to wait till "rubber hits the road".

[NIK]

Just wondering how "IP Address distance" translates to geographical distance.
I mean are say Sweden and Australia mathematically close, even though they are geographically far.

It doesn't, that's the point. ie. some houses in Sweden and some houses in Australia will be mathematically close and others will be mathematically distant, geography is almost totally irrelevant.*

If they did, that would be a very bad thing. It would lead (for example) to people in South Korea and Japan (where they enjoy the highest broadband speeds in the world) clustering together and almost always experiencing super fantastic speeds and people in Africa clustering together and almost always experiencing super appalling speeds.

What they're trying to do is to ensure that African users are able to "butt in" to South Korean swarms, to even things out. Currently, when a swarm is large (ie. over around 100 peers) that generally isn't allowed. [It's not deliberately or explicitly set up that way, it's an "unintended consequence" of the way it works.]



* I say "almost totally" because IP ranges are allocated in blocks, to ISPs with market presences that are generally geographically based and relatively small. So two customers of small-time-ISP in Hicksville, Arizona will probably be both mathematically and geographically close. But most ISPs are bigger, and own multiple disparate ranges of IP addresses. The question becomes: how closely does geography match mathematics? If it's "very little" which is what I would suspect, then there is no problem. If it is "heavily" then that's not so good.



A big disclaimer being: I suspect it's not IP addresses they're talking about measuring the distance between. That's not the way DHT works (with DHT, every client randomly generates a node ID and it's the mathematical distance between those that is measured, and they ARE totally unrelated to geography) and they already do that so considering IP addresses would be a needless and backwards step.

[kjf]

So, in a nutsack, they are looking to put the swarm in a blender so that peers that come late to the swarm can connect to peers that joined early, that would otherwise refuse incoming connections due to having all their slots full.

In theory, this does make sense, and (as the article acknowledges) some of this already happens with peers coming and going for whatever reasons. This extension if/when adopted will work to increase the odds that each mini swarm will have a piece availability representative of the swarm as a whole.

Of course, on an individual basis, there will be circumstances where a fast peer with high availability will get booted for a slow peer with next to nothing simply because the newcomer's network address is closer to home. I find it hard to believe that wasn't taken into account, but I see no mention of it.

[SectorVector]

Nice explanations. Thank you both. This will probably evolve like RIP to OSPF. YIFY torrents will proly be a good testbed.

NIK, know any example where "math IP distance" != Geographical distance (to kind of prove your point).
I'd search it myself if I could find a full database. Thx.

[NIK]

Of course, on an individual basis, there will be circumstances where a fast peer with high availability will get booted for a slow peer with next to nothing simply because the newcomer's network address is closer to home. I find it hard to believe that wasn't taken into account, but I see no mention of it.

That's the bit that I hadn't worked out. And, like you, I also find it hard to believe (so I suspect that I've missed something because Arvid Norberg is a genuinely smart cookie).

@SV. Nope, sorry, I don't keep IP range allocations in my head. Besides, as I said, I don't think it works that way anyway.

Rather: imagine that I thought of a number between 1 and 1000 (say 243), as did you (say 657), and kfj (say 134). And then we told each other our numbers. And then I calculated the difference between my number and each of yours and chose to reply to you because (657 - 243) > (243 - 134).

Now, I know where I live, and I know where kjf lives, and I think I know where you live. But that is not the basis I'm using to decide who to reply to. If someone else joined the threaed (say, your parent/sibling/partner/child/gimp/whatever, who happened to live in the same house as you), and chose for their number 987, I would drop you in a heartbeat and talk to them even though you were both the same distance from me.

[SectorVector]

Found one doc which may be useful in this context.
http://www.cisco.com/web/about/ac123/ac1...-cons.html

[kjf]

Rather that kicking the peer with the lowest priority, I'd like to see it kick the peer that's logged the most snub time. Maybe they are snubbed because they are part of a DDoS. Maybe there is a network issue between us. Maybe they just don't know how to configure their client. Regardless, they are doing me no favors, and it is fairly unlikely the incoming peer can do worse.


Regarding IP address vs geographic location -

Here is the IPv4 space registry:

http://www.iana.org/assignments/ipv4-add...-space.xml


And here is a map of what regions each registry serves:

https://www.arin.net/knowledge/rirs/maps/rirmap.png


Given the further fragmentation brought on by the exhausting of the v4 address space, it is entirely possible your network neighbor could be on the other side of the continent, while your geographic neighbor could be in an entirely different Class A.

One thing to consider is that peering arrangements can make routing packets to your geographic neighbor the equivalent of a long distance phone call while your network neighbor on the other side of the continent is a local call. I experience this first hand when I connect to my mail server. It is physically about 15 km away, but my network connection goes through two different cities which creates a physical route that is over 2500 km long.

Another example would be your neighbor next door. If they don't have the same ISP, they are further away from you than someone across town who shares your ISP... Or take your mobile phone (if it is internet capable). It may be on your desk right next to your computer, but it is not going to be in the same network neighborhood.