Trying to anticipate behaviour of .NET TcpClient.GetStream() regarding ephemeral port usage in multithreaded environment

Question

Hi,

I'm wondering if anyone has experience of this...

I'm in the process of multithreading a currently serial process that makes request via a .NET TCPClient to a remote server.

We know connect to the remote server on the same port via multiple threads, as we have several instances of the serial processing application running connecting to the remote server on the same port.

However, I am less sure what will happen if I make multiple TCPClient.GetStream() requests using multiple threads in the same application - with regard to the local ephemeral (short lived) port.

If the remote server knows that it has to send responses back to the ephemeral port from which the request originated, are there any guarantees that each thread will use a differing ephemeral port for the request - or is there any chance of use of the same port?

For context, this is a card processing application.

Hope that makes sense.

Answer 1

You don't need to worry about this unless you're making so many connections that you get port starvation. The Socket related APIs abstract away the issue of ephemeral ports and these need be of no concern to you (regardless of threads/processes) unless you've got thousands of connections that aren't clearing quick enough. In my experience, it's only spiders that run into these kinds of problems. In this case it would be considerably easier to manage if all the connections were made from a single process.

On newer Windows the port range is 49152-65535 (or ~16k concurrent connections), on earlier Windows, considerably less.