INFO: Winsock TCP Connection Performance to Unused Ports (175523)

MORE INFORMATION

When a process creates a TCP socket in the Microsoft Winsock layer and issues a connect() call to some host and port number, the TCP protocol performs its standard "three-way handshake" of a SYN packet, acknowledged by the target host with ACK/SYN, and a final ACK from the initiating client. However, per the TCP specifications stated in RFC-793 (Transmission Control Protocol), a reset (RST) might be generated if the SYN attempt is addressed to a host which exists but the port is unused. This is best described by the following RFC quote from page 35: Upon receiving the ACK/RST client from the target host, the client determines that there is indeed no service listening there. In the Microsoft Winsock implementation of TCP, a pending connection will keep attempting to issue SYN packets until a maximum retry value is reached (set in the registry, this value defaults to 3 extra times). Since an ACK/RST was received from the target host, the TCP layer knows that the target host is indeed reachable and will not double the time-out value in the packet's IP header, as is standard during connection attempts with unacknowledged SYNs. Instead, the pending connection will wait for the base connection's time-out value and reissue another SYN packet to initiate a connection. As long as an ACK/RST packet from an unused port is received, the time-out value will not increase and the process will repeat until the maximum retry value is reached.

This behavior may result in poor performance if for some reason a process repeatedly issues connect() calls to ports with nothing listening there, resulting in the error WSAECONNREFUSED. Note that with other implementations of TCP, such as those commonly found in many UNIX systems, the connect() fails immediately upon the receipt of the first ACK/RST packet, resulting in the awareness of an error very quickly. However, this behavior is not specified in the RFCs and is left to each implementation to decide. The approach of Microsoft platforms is that the system administrator has the freedom to adjust TCP performance-related settings to their own tastes, namely the maximum retry that defaults to 3. The advantage of this is that the service you're trying to reach may have temporarily shut down and might resurface in between SYN attempts. In this case, it's convenient that the connect() waited long enough to obtain a connection since the service really was there.

It contains the complete listing of NT TCP registry values. Of particular interest is the key: For additional information on the Windows 95 TCP registry entries, click the article number below to view the article in the Microsoft Knowledge Base: The following key is of particular interest: Restart your computer after you adjust these registry values.

WARNING: Modifying these values affects any and all TCP outgoing connection requests from the affected computer. If all of the TCP activity on the computer has little latency and little distance to travel round-trip, reducing this as low as zero (although Microsoft does not recommend this) will make no difference. However, if applications or connection attempts fail regularly with the standard Winsock errors and the target remote servers are known to be available, it is likely that these registry entries are the cause. If so, you may have to raise the maximum retries so that TCP will double the SYN packet's time-to-live value in its IP header at successive retries until it has a long enough life span to reach the target host and receive an ACK/SYN.