Grauw’s blog

sixshot posted an nice reply on the µTorrent forum, which explains very well why Azureus is not a good client. I think he makes a good point:

Azureus gets its popularity due to the incredible amount of features it has. The client has a queue system, seeding priority, bandwidth controls, torrent creation function, personalized tracker, auto-update, and lots others. People can be blinded from the truth about Azureus in that most people won’t need to use the features that it has. Yet development continues on without any sign of stopping or slowing. The client is written in Java and as a result has some form of cross-platform ability. Funny... Python originated in the ‘nix/BSD world with cross-platform in mind. There’s even Python for OS X. Due to the client written in Java, you need the Java Runtime Environment in order to run it. Depending on your setup, that’s an additional download. And since it runs in Java, the Java Virtual Machine is run in order to process the client’s Java byte-code. That consumes memory. And because it is a Virtual Machine, that’s a heavy process and consumes CPU cycles.

Many do not realize that some of the simple features, while a few possibly found only in Azureus, exists in other clients. As such, people blindly follow the word of the herd and use it, never realizing that they’re making their computer choke and suffer. The client is good, feature-wise. But its popularity and its numerous features became the client’s drawbacks and downfall.

Ah, thanks for the info. Interesting, I now understand what it does.

Large amounts of half-open connections are caused by viruses, and Microsoft is trying to slow them down with this limitation. For a regular program, that will hardly ever happen, however for peer-to-peer software, that is different because it makes a lot of connections, and it tries to make them to potentially difficult-to-reach or offline users (causing a connection to stay half-open until it times out).

But it is only for half-open connections. This is what Microsoft says about it:

The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system’s event log.

Two things to note in particular in this text: it only limits outgoing incomplete connections, and the connections that are attempted while the limit has been reached will still be made.

So this is still a shortcoming for BitSpirit, in two aspects: first because it tries to install the patch without explaining why, and second because the real fix is to just make sure you never hit the limitation by postponing opening new connections when there are 10 or more still in progress. This is probably good anyway, because it reduces the amount of connection requests at once.

Because of that, I also don’t think I should be recommending people to install this patch. You are basically disabling a security measure that Microsoft rightfully added to its OS.

I’ve updated the part about BitSpirit in the article with a small note containing more information about the patch.

p.s. I looked in my event log to see if those 4226 events showed up on my computer as well, and they do, but only a couple of times per day. So I think Microsoft balanced it out quite well. Surely they were also aware of p2p applications when implementing this security measure, and considered them…

So to say that the limitation is hurting my speed… Given the conditions that are needed for the limitation to become active, and this practical ‘research’ in my own event log, I don’t believe that is the case. It’s probably something that is pulled out of proportion.

Anyways, everyone thanks for the interesting information and thoughts :).

Heh :). Glad you like it too!

For the ones who interest it, µTorrent 1.2 just came out, and it now supports Mainline DHT (trackerless torrents) which seems to be a popular feature. Along with a slew of other improvements.

Hi John,

As you can read in the article, the reason BitTornado was not reviewed was because of requirement no. 1.

Either search for the term ‘BitTornado’ or look here.

I don’t have anything in particular against BitTornado, in fact I’ve used it a long time through TorrentStorm which was a UI wrapper around it, but as the text explains I just think a single-window-per-download user interface is not very convenient, and thus it was not interesting for me to review.

It is not just a matter of convenience by the way, one of the real disadvantages is that in such a multi-window environment usually the torrents can’t have a single incoming port, which makes it a hassle to configure or sometimes even impossible if you’re using a router or firewall.

Hi Ian,

With regard to the ‘lvllord’ patch for Windows XP SP2, with µTorrent it is not necessary to use this patch (which disables a security measure in XP SP2). It automatically avoids the security measure, in fact, that’s exactly what the ‘number of half-open connections’ option you mentioned is for. Increasing that number will not improve the performance of Bittorrent, it is only limiting the half-open connections, so there is no limit on the total number of opened connections.

There is an item in µTorrent’s FAQ which describes the advanced settings. Note that the default settings are already set for optimal performance, and you normally do not need to modify them.

OndrejSc, thanks for the heads up. I’ll put reviewing the official BitTorrent client on my TODO-list.

GDP, I don’t really know about that. I suppose BitComet is able to traverse NATs with UDP using the STUN protocol, but that’s not supported by µTorrent or any other client that I know of. Most clients (including µTorrent) do support UPnP however, which is also used to do NAT traversal. This will only work when your router supports UPnP though, but most modern routers do.

Well, I think that’s not true, just an urban legend. People are already biased to start with, think it should help, try out one torrent, and it might just coincidentally be a little faster than they remembered and they immediately assume it indeed does help.

But as torrent speeds are very variable, and we’re talking about reasonably long durations, I don’t think there are many people who have really based their opinion on solid evidence, just perception.

Technical rationale: connections are made in matters of seconds, even fractions of seconds. Only during that time is a connection half-open. So to make 50 connections in a torrent, with each connection taking an average of 2 seconds, it should take only ten seconds at the most for all connections to be established. Even with longer connection times, we’re still talking about maybe a few tens of seconds here.

So I do not see a technical basis for this slowing down the torrent to such an extent.

Also, I have a 100mbit connection, and I never experienced such problems with download speeds as you mentioned. 5 minutes is pretty normal for a torrent to get up to speed (as far as you can talk about a torrent’s ‘speed’, as it is always variable).

Hi Therock,

I wouldn’t say it’s unsafe to change the limit, however I don’t think it gains you very much. Microsoft placed the restrictions there for a very good reason, so it’s not good that some sites/programs encourage you to remove them. Most torrent clients like µTorrent throttle the half-opened outgoing connections to make sure you don’t hit the Windows limit, and many people who have never changed their operating system settings are using Bittorrent without issues.

How to undo the changes depends on the patcher, whether it offers an undo or uninstall option (let’s hope it does!). If not, worst case you have to manually dive in the Windows registry or system files to undo it. Obviously I am not familiar with those tools, because I did not modify my system in this way :).