I have a server application which uses permanently connected incoming ports within the range that W2k8 now uses in the IANA recommended range of ~49000-65000. (For legacy reasons it's extremely difficult to change this, so I'm going to have to change Window's range to avoid my range, but that's not the question).
I've been researching how to avoid conflicts with ephemeral ports in Windows 2008 Server, but can't find details on the Windows algorithm for selecting ephemeral ports.
When the Windows network layer is assigning a 'random' ephemeral port for the response to an outgoing TCP/IP connection, does it test the proposed port to see if it's being used already?
(The Linux kernel seems to do a check_established test but could still re-use some used connections, so I'm wondering what decisions Windows might make in taking seemingly unused or idle ports off another process...)
i.e. if my server opens winsocks on all its ports, and keeps them in LISTENING state, will Windows respect and skip over them because they're in use? Or will it ignore the fact they're in use, and assign them to other processes anyway for ephemeral use, causing conflicts?
I have found that sometimes when my server starts it cannot allocate a few of its ports, because they're being used for random purposes by other processes - which makes sense and I understand that. But I haven't yet been able to prove if ports it does manage to initially open are subsequently 'stolen' for ephemeral purposes (it's a difficult thing to test or force due to the large range and random nature).
As I said, I am going to reconfigure windows to avoid my server anyway, so this question is more out of curiosity and to explain recent behaviour more clearly (to rule in/out other possible bugs!)
thanks in advance
I would answer that;
For a program you wrote with the winsock API, it handle it kinda that way; http://support.microsoft.com/kb/173619.
When you close the handle to a socket, some additional negotiation goes on between the client and the server. The socket will wait for up to two times the maximum time that windows would wait to receive an acknowledgement from the other end of the socket that closed the port. By default, this option is set to two minutes. Therefore, Windows may wait up to four minutes before the port is actually released. This makes that specific port unavailable until it is actually released.
For Windows RPC service;
*This article does not specify which services rely on other services for network communication. For example, many services rely on the remote procedure call (RPC) or DCOM features in Microsoft Windows to assign them dynamic TCP ports. The Remote Procedure Call service coordinates requests by other system services that use RPC or DCOM to communicate with client computers. Many other services rely on network basic input/output system (NetBIOS) or SMBs, protocols that are provided by the Server service. Other services rely on HTTP or on Hypertext Transfer Protocol Secure (HTTPS). These protocols are provided by Internet Information Services (IIS). A full discussion of the architecture of the Windows operating systems is beyond the scope of this article. However, detailed documentation on this subject is available on Microsoft TechNet and on the Microsoft Developer Network (MSDN) websites. Although many services may rely on a particular TCP or UDP port, only one service or process at a time can listen on that port.
When you use RPC with TCP/IP or with UDP/IP as the transport, incoming ports are frequently dynamically assigned to system services as required; TCP/IP and UDP/IP ports that are higher than port 1024 are used. These are also informally known as random RPC ports. In these cases, RPC clients rely on the RPC endpoint mapper to tell them which dynamic port or ports were assigned to the server. For some RPC-based services, you can configure a specific port instead of letting RPC dynamically assign a port. You can also restrict the range of ports that RPC dynamically assigns to a small range, regardless of the service. For more information about this topic, see the "References" section.*
From: http://support.microsoft.com/kb/832017