XPSP2 will limit your max. connections/sec


Recommended Posts

I suggest a mod close this topic.

First of all the title itself is incorrect.

Most people just read the title.

XP does not limit maximum connections

It only limits connection to a host which could not be connected to earlier.

This prevents programs from repeatedly trying to connect to hosts which do not exist -- behaviour you would see in spam clients or worms.

As does shareaza for me.

Don't complain that it's not an easy reg-key type fix; if it were, it could be easily circumvented by malware.

At any rate just be glad that joe user's infected trojan/worm factory will be that much slower at throwing out crap. I say good idea MS, but it does need to work around the P2P issue.

Yes, and I'm glad that people running tests using Kazaa (!) of all things are concerned about unlimiting their tcp/ip connections. Same people that are probably complaining about the Security Center, not using an antivirus, or any type of firewall.

I say let the P2P software makers become compliant to the new security features of SP2 if they need to, not lessen security with some half-ass hack using files from beta versions of service packs, just so you can download minutely faster...which has yet to be proven, because my bittorrent connection has been, if anything, more stable and *faster* since SP2.

I'd like to think I'm capable of handling how my system uses sockets enough to not have M$ act as a govt and simply limit the number of concurrent sockets in a supposed act of "security". There is NO security is limiting sockets in the TCP layer.

P2P apps rely heavily on multiple connections, as is the entire point of p2p in the first place. Limiting these connections will only hinder applications that use multiple sockets for its functionality as well as overall bandwith benefits of higher connection counts.

Asking software developers to "become compliant to the new security features of SP2" is the most rediculous comment I've heard so far. Well, at least second to the comment about how limiting user's capabilities in the name of security is a good thing. True, worms wont spread as fast as they are currently designed, but its not that hard to limit scanning to the "new super secure limited way" (see reducing 128 scan threads to 10 for example).

I feel M$ has no right to limit anything. I do somewhat understand why they would do it in terms of the fact that most people are complete idiots and have no idea what they're doing on their computer. It would save these kinds of people from hurting themselves, getting infected by viruses they wouldn't have gotten infected with if they had a bit of sense.

Not only does this restrict simply the number of connections, but you can kiss raw sockets goodbye. Remember creating/modifying those raw packets (for whatever reason) ? Forget it, because this limitation will remove the ability to do such things.

Its a new kiddie world, and everyone is invited to have their OS simplified and functionality limited because everyone is stupid.

After digging through MS's website a bit I found some more detailed info on the restrictions they put on raw sockets and how they limited the number of simultaneous incomplete outbound TCP connection attempts. Here's the link.

Restricted traffic over raw sockets

A very small number of Windows applications make use of raw IP sockets, which provide an industry-standard way for applications to create TCP/IP packets with fewer integrity and security checks by the TCP/IP stack. The Windows implementation of TCP/IP still supports receiving traffic on raw IP sockets. However, the ability to send traffic over raw sockets has been restricted in two ways:

- TCP data cannot be sent over raw sockets.

- UDP datagrams with invalid source addresses cannot be sent over raw sockets. The IP source address for any outgoing UDP datagram must exist on a network interface or the datagram is dropped.

Limited number of simultaneous incomplete outbound TCP connection attempts

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.

So basically it shouldn't matter that much for BitTorrent clients. Under certain circumstances it may take a bit longer to connect to seeds/peers but it shouldn't really block anything nor limit your download speed. I am not sure how this may interfere with other P2P protocols and Bittorrent trackers as I am not familiar with them, but I can imagine for clients/servers that _continiously_ have to connect to other hosts at a fast rate (and if some if these connections fail), this "queueing" of connection attempts could slow them down a lot. I can not provide a definitive answer for this, because it really depends on the rate at wich these queued connection attempts are being processed.

The restrictions in the use of raw sockets seems a very wise choice. A lot of DDoS attacks at the moment are being done by 'hordes' of machines infected with trojans that are basically sending out spoofed (fake, randomised source IPs) packets targeted at one, or a select group of hosts. With SP2 these packets will not be send. This means that these trojans used for DDoS attacks will have to revert to using non-spoofed packets, which makes it a lot easier to block a DDoS attack (kinda depends on how many machines are being used in a given attack). At the same time I realise that this restriction can be a real pain for network and security specialists.

Hope this helps.

Edited by Aphax
the least they could have done is made this patch just for Home edition and not Pro

Perhaps, but I think that all the "pro" users that for some reason need unrestricted access to raw sockets or be able to continiously open connections to hosts at a fast rate, will be able to install that fixed tcpip.sys. Personally I'd rather have it back as it was in SP1, but I can't blame MS for doing this. They've been under pressure to make Windows XP more secure, and at least by limiting the use of raw sockets, that's exactly what they've done.

but you can kiss raw sockets goodbye. Remember creating/modifying those raw packets (for whatever reason) ? Forget it, because this limitation will remove the ability to do such things.

Good, raw sockets should never have been implemented in the first place. That was a huge security mistake.

Just to clear up some confusion since this topic was recently linked to, the file in question from SP2 does NOT affect any P2P applications. It does not limit your max connections in any way at all, and thus will not affect you at all. Also, it does not affect any P2P applications. Me and many other users are unpatched and experience no difference, if you have an issue try disableing SP2's firewall.

See my post here for more info:

https://www.neowin.net/forum/index.php?show...#entry584348912

As does shareaza for me.

Don't complain that it's not an easy reg-key type fix; if it were, it could be easily circumvented by malware.

At any rate just be glad that joe user's infected trojan/worm factory will be that much slower at throwing out crap. I say good idea MS, but it does need to work around the P2P issue.

which version of Shareaza?

cause i needed to patch my Tcicp.sys file for it to even connect to the networks....

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • I hope this encodes in to AV1 or AV2 as currently tiktok uses h265 and h264.
    • Qualcomm reportedly in talks to build custom video chips for TikTok parent ByteDance by Karthik Mudaliar Qualcomm is reportedly in advanced discussions to provide custom chip-design services to Chinese tech giant ByteDance, the same company behind TikTok. According to a report from Reuters, Qualcomm could be involved in designing custom silicon tailored for ByteDance's massive data-center workloads. If it goes through, the deal would make ByteDance one of Qualcomm's early anchor customers for its fastly growing custom chip-design division, For years, Qualcomm was the king of making smartphone processors and modems. The company has also been moving into the PC ecosystem and other formats such as on-device AI for Android XR headsets. However, this particular deal is about Qualcomm's custom Application-Specific Integrated Circuits (ASICs). For a platform like TikTok, ByteDance needs hardware that can help it ingest, process, and serve billions of short-form videos daily. Generalised hardware is no longer the most cost-effective and efficient route, which is why ByteDance is trying to develop custom Video Processing Units (VPUs). VPUs designed specifically for ByteDance’s algorithmic needs could drastically reduce data-center power consumption and improve encoding speeds at an unprecedented scale. The underlying tech behind these processors is actually from Qualcomm's recent acquisition of AlphaWave Semi, a high-speed connectivity specialist company. By combining AlphaWave’s high-bandwidth IP with Qualcomm’s architectural expertise, the company could begin mass production by the end of 2026, if the talks go through. All this also comes at a time when U.S.-China tech relations have dwindled. Escalating trade frictions between Washington and Beijing have severely impacted the export of high-end AI chips from U.S. firms like Nvidia, AMD, and Lam Research. Yet, the Qualcomm-ByteDance discussions show that U.S. tech companies are still actively seeking growth avenues and are open to doing business with China, where regulators still permit. Reuters notes that the outcome of this deal could be uncertain, and ByteDance might also seek partners other than Qualcomm. via Reuters | Image via DepositPhotos.com
    • Look who's back!
    • I wonder how driving laws around the world will change. No way to really tell if people are using phone. Same with smart watches i guess even now and those silly built in tablets for controlling the car instead of buttons.
  • Recent Achievements

    • Rookie
      DaviKar went up a rank
      Rookie
    • Dedicated
      HidekoYamamoto94 earned a badge
      Dedicated
    • One Month Later
      timbobit earned a badge
      One Month Later
    • One Month Later
      nates earned a badge
      One Month Later
    • Week One Done
      Almohandis earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      454
    2. 2
      +Edouard
      161
    3. 3
      PsYcHoKiLLa
      111
    4. 4
      Michael Scrip
      83
    5. 5
      Steven P.
      69
  • Tell a friend

    Love Neowin? Tell a friend!