'Lo guys
I recently saw this (yes, off SlashDot, so sue me)
http://it.slashdot.org/comments.pl?sid=142869&cid=11970940
"Windows XP SP2 limits the number of possible TCP connection attempts per second to 10 from an unlimited number in SP1. This can affect performance on server and P2P programs that need to open many outbound connections at the same time."
Uhm, so yeah... before I consider "upgrading" to SP2... how can I be sure this won't affect my BitTorrent and gaming experience? And if so, how to disable it?
-
-
It does affect bit torrent on very popular torrents, but it doesn't stop it working altogether, it may slow performance a bit though.
I don't know of any way to disable it. Bit of a pain in the ... if you ask me. Classic example of treating the symptoms rather than the cause. I bet some hacker will work out how to patch round it using a rootkit exploit at some point though
-
Both explanation and solution can be found here http://www.speedguide.net/read_articles.php?id=1497
I have not tested the tool, so if you try pls post the results.
ThMoJe -
W3bbo wrote:
Uhm, so yeah... before I consider "upgrading" to SP2... how can I be sure this won't affect my BitTorrent and gaming experience? And if so, how to disable it?
It won't. I am using XP SP2 since the beginning and basically a few weeks later all P2P apps adjusted to the new behavior.
Note that SP2 does not limit total number of connections in any way (as is wrongly reported on many places) just number of half-open connections per sec. That will only affect those P2P apps that are frantically trying to connect to as many peers as possible... Like I said, all high-profile P2P apps are already patched and are not susceptible to this limitation.
I would recommend not to install any kind of patches, there is no need for that. You'll just risk that next SP does not update the patched file... -
It only applies to incomplete outbound connections, where the client has sent a SYN packet but hasn't yet received a SYN-ACK packet from the server. This is the first thing the server's TCP stack does, before it even informs the server application that a connection is being made (i.e. accept() doesn't return yet).
It has a slight effect on BitTorrent as the peers change - appear and disappear - so often. When it starts downloading, it makes a lot of connections, which can cause the limit to be reached. When this happens you'll see Event 4226 appear in your System event log. The effect is that until some of the connection attempts either complete or time out, new connection attempts will be queued. So if you're browsing at the same time as downloading on BitTorrent, your browsing connections may be delayed.
People have produced 'patched' versions of the TCP/IP stack driver without this limit, but I would strongly recommend that you don't install them.
The reason for the limit is simple: to prevent simple SYN-flooding attacks. -
Mike Dimmick wrote:it makes a lot of connections, which can cause the limit to be reached. When this happens you'll see Event 4226 appear in your System event log.
Thanks Mike, this is one info I had tried to look for earlier..
-
This is bullshit. Slowing down legitimate applications in a way that can't be disabled is a real step backwards.
I've been wondering why the web applications that I'm building locally sometimes take a long time to connect to a very fast SQL Server over a very fast network. It turns out that at these times I have Event 4226 in my Event Log:
TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.
This has had the totally opposite effect than Microsoft intended - some really stupid people are now downloading old (compromised?) tcpip.sys files from the web so that they can get faster BitTorrent downloads.
Apparently it is no longer possible to turn this off through a registry settings. I hope that Microsoft soon reverses this.
Thread Closed
This thread is kinda stale and has been closed but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.