IP tuner: TCP/IP Parameter Tuning for Windows

For a more in-depth discussion on when and why to use IP tuner, please read the associated article TCP/IP Parameter Tuning for Rapid Client Connections.

This tool is handy if you’ve ever encountered unexpected TCP port conflict exceptions when attempting to create a client socket connection.  Depending on your environment, the exception text will look one of two ways.

In a C# environment, you’ll see this exception:

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted <host>:<port>

In Java, you’ll see this:

java.net.BindException: Address already in use: connect

at java.net.PlainSocketImpl.socketConnect(Native Method)

at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)

at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)

at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)

at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)

at java.net.Socket.connect(Socket.java:519)

at java.net.Socket.connect(Socket.java:469)

If you see these exceptions thrown when a server socket attempts to listen for incoming connections, the cause is obvious: the port you’re attempting to listen on is already in use.  For example, if you bring up a Web server, but another Web server is already running, an exception will be thrown because port 80 (or 8080) is already listening on behalf of another thread or application.

These exceptions are often confusing, however, when thrown setting up a client connection.  Client TCP connections are always assigned an OS-selected port on the local side, so why is the operating system selecting an active port?  The truth is the exception indicates no local port numbers are available to the client.  This misreporting of the error by the OS is half the confusion.

The problem is two-fold.  First, Windows only makes a certain number of ports available to client sockets – the default is in the range of 1024 to 5000.  Hence, you may have only 3,976 active client connections at a time.  For most systems, this is plenty.  However, in specific circumstances on systems requiring a large number of outbound connections, this limit can be exhausted.

This limit can be tuned, however, by setting the MaxUserPort DWORD value on this registry key:


You can edit or add this value using regedit, or you can launch IP tuner for a simpler API.  When IP tuner comes up, the UI displays the current value for MaxUserPort.  If no value is specified, the box is left unchecked:
Setting the maximum user port.

Here, you can set (or erase by unchecking) the maximum port value Windows will assign to a client TCP connection.  By increasing this value, you create a larger pool for Windows to select client TCP ports from.

The other cause of these exceptions has to do with the TCP state model and the way sockets are closed.  Even after a socket has officially been “closed”, it hangs around in a TIME_WAIT state as a safety mechanism to deal with stray packets.  The default wait time is 240 seconds.  So, even if an application doesn’t require a lot of concurrent connections, it can still run out of available ports in a high load situation.  If even one connection is repeatedly opened and closed fast enough (such as in a load and performance test using LISA Test from iTKO), you’ll soon have all available local sockets hanging around in a TIME_WAIT state and none available for new clients.

The TIME_WAIT state duration, however, is also tunable.  Using the same registry key, the TCPTimedWaitDelay value can be used to adjust the TIME_WAIT duration from 30 to 300 seconds:
Setting the TCP wait delay

By decreasing the TCP Wait Delay, closed sockets spend less time in the TIME_WAIT state and get returned to the pool of available client ports faster.

Whether you use IP tuner or regedit, you’ll require administrator privileges to change registry settings, but anyone can view these settings to at least verify if they make sense.