Checking for port exhaustion on a server (Windows)

VenosaurMan

10/21/23, 12:11 PM

This is my first question here so I hope I did it correctly.

I am using UDP packets to communicate through a server-client structure, where all clients communicate with the same server through UDP.

As I have understood it, for each client that sends a packet to the server, the server computer takes up one port for that client. That means if ~65 000 clients connects to the same server computer it will not have more ports to allocate for connecting clients, which is bad.

When a port is allocated for the client, it will take 4 minutes for it be placed in the available pool again (according to https://learn.microsoft.com/en-us/windows/client-management/troubleshoot-tcpip-port-exhaust).

My problem is that I have not found a way to check the amount of available or used ports on the server computer.

For example, if I have a client machine with 2000 different connections (I know UDP is connectionless) against my server machine, the CMD command "netstat -ano" outputs all ports being used on the client machine (which is over 2000 of course). However, on the server it does not show that many (less than 100) ports being used with the same command, which means that it does not show the ports allocated for the 2000 connections.

How can I fetch all used/unused ports on the server machine?

I realize that I can in my program get the ports being used and calculate how many ports are available in the pool, but that only takes care of the ports in my program, and not any other ports that might be used from other programs.

695

0 + 6

windows

port

Greg Askew

10/21/23, 12:46 PM

`each client that sends a packet to the server, the server computer takes up one port for that client.` That isn't accurate. Think of an LDAP server listening on udp/389. It doesn't connect a client to another port on the server. It uses the same port 389.

VenosaurMan

10/21/23, 1:46 PM

So you are saying that if a client connects to my computers server, my server does not allocate a port for that client? Every source of information states otherwise. Check: https://learn.microsoft.com/en-us/archive/blogs/askds/port-exhaustion-and-you-or-why-the-netstat-tool-is-your-friend Search for "However, in order to negotiate".

VenosaurMan

10/21/23, 1:48 PM

Same at this question: https://serverfault.com/questions/541699/nat-gateway-maximum-connection-limit "UDP is affected by the same limits. When a UDP packet leaves a NAT firewall it has to hold that port and remote ip address open for a certain amount of time for return packets to make it through."

bjoster

10/21/23, 4:30 PM

UDP is stateless, you will see a "connection" on the client, but never on the server. TCP will close the port when it's done, usually a few milliseconds later. "it will take 4 minutes" for the pool - the application (IIS for example) can use it's pool without any waiting times. Otherwise it would be a matter of seconds to DOS any windows machine.

Greg Askew

10/21/23, 4:32 PM

The example you provided on the Microsoft site is a *high port* allocation on a *client*. The port that the client connects to on the server in those examples (445 for SMB for example) remained the same. Also those are examples of other applications, not your application. Additionally, this behavior is independent of any limitations imposed by NAT, which has nothing to do with the applications on either side, that is a separate limitation.

vidarlo

10/22/23, 5:10 PM

May be worth reading [this Q&A as well](https://networkengineering.stackexchange.com/questions/54344/why-is-a-tcp-socket-identified-by-a-4-tuple)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Checking for port exhaustion on a server (Windows)

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.