What's the method uTorrent uses to poll the half-open TCP connections?

[TheFatTubist]

I've noticed that there are a few threads here about the issue with the half-open TCP connections issue. Some threads here "solve" the issue by modifying the max half open connections parameter. I'm not sure that this really corrects the issue, since it shouldn't matter what you set that number to, as long as it is under 10 -- that threshold should never be passed if uTorrent is working correctly.

So it seems to me that the issue is that the polling method uTorrent is using is faulty in some way. To support my hunch, when I first start the program and it starts to put the call out to all the trackers, there has to be some half-open connections, but a look at the statistics and no half-open connections are reported. This just cannot be, since the program has just started and the transfers are not yet fully going.

In a possible relation to the issue, I know that the WinPcap software used in packet sniffing is not compatible with some wireless adapters. I wonder if this is the same type of issue?

[thelittlefire]

You could read up on the development threads.. there is some mention of what changes were made in 1.7, during beta of 1.8.1 to make sure half open limits aren't breached.. apparently they assumed something which wasn't true.

[Switeck]

It seems that uTorrent holds off on making many new outgoing connections till it completes all the tracker updates.

The v1.8.1 beta tests discovered a problem with Windows XP? Vista? misreporting the number of half open connections in use, so uTorrent thought there were fewer than there really were...and was issuing them too fast. They backed up until windows started dropping them. Eventually, uTorrent thought there were more half open connections going than it allowed, so it quit making any more. At that point, even tracker updates no longer occurred. At least that's what I saw...though the underlying mechanisms can be far more complex than that.

[TheFatTubist]

It is very good to hear that some progress is being made on this front. I think the way you describe the issue most accurately defines what is going on here. Lets hope those mechanisms can be wrangled!

[Ultima]

Either way, though, some connections may be fully opened very quickly, in which case they obviously won't count toward the half-open connection count.

[TheFatTubist]

That slightly contradicts evidence from my event log complaining of TCP connect attempts going over the limit. If the connection attempts were being resolved so fast that they do not show up in the statistics, then I shouldn't be getting this message:

Log Name: System

Source: Tcpip

Date: 11/13/2008 11:09:23 AM

Event ID: 4226

Task Category: None

Level: Warning

Keywords: Classic

User: N/A

Computer: *******

Description:

TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.

[Ultima]

Dunno. Perhaps it was overloading the halfopen connection limit for a short period of time, but got resolved?

FWIW, I'm not trying to make excuses for any possible inaccuracies in the Statistics dialog -- I'm just pointing out random possibilities I don't pay enough attention to the Statistics dialog and halfopen connections to be able to draw any definite conclusions.