Timeout behavior of the Windows application server

Various types of timeout related to the Windows application server are discussed in this topic.

On Windows, the TCP/IP protocol suite implementation reads all of its configuration data from the registry. All of the TCP/IP on Windows parameters are registry values that are located under one of two different subkeys of \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Adapter-specific values are listed under sub-keys for each adapter that is identified by the adapter's globally unique identifier (GUID). The parameters described in this topic normally do not exist in the registry. They may be created to modify the default behavior of the TCP/IP protocol driver.

To avoid negative effects on system performance, it is recommended that you change default values only after careful study.

For more information about registry values, refer to the Windows online documentation and its references to TCP/IP documentation.

Client connection timeout

When the client connects to the server, each connection attempt times out after a time period determined by the value of the TcpMaxConnectRetransmissions registry value (under Tcpip\Parameters). When this happens, the connect attempt has failed. The client then writes an error message and returns the error to the calling process.

The default value of TcpMaxConnectRetransmissions is 2. The retransmission timeout is doubled with each successive retransmission in a given connect attempt. The initial timeout value is three seconds. This means that a Windows connection request times out after approximately 21 seconds.

For an example of where you might need to change this default see Additional considerations. This setting is system-wide and affects all TCP connections that are established from the system.

For the relationship between the setting of the TCP/IP client connection timeout and the Db2® connection timeout, see Timeout behavior of Db2 client connections.

Client transmission timeout

Each time the client sends data to the server, TCP/IP waits for acknowledgment of this data. TCP/IP retransmits data if acknowledgments are missing. The time period that TCP/IP waits for the acknowledgment before it times out is variable and dynamically calculated. This calculation uses, among other factors, the measured round-trip time on the connection. The timeout interval is doubled with each successive retransmission. When the final transmission timeout occurs, the client's next receive call fails with a send timeout error. The client writes an error message and returns the error to the calling process.

The length of a transmission timeout on Windows is determined by the TcpMaxDataRetransmissions registry value (under Tcpip\Parameters), and can amount to several minutes. The actual time is based upon the default value of TcpMaxDataRetransmissions, which is 5, and upon the initial timeout value, which depends on the measured roundtrip time on the connection as already mentioned. For example, if your initial timeout value is 2 seconds, then the transmission timeout is 2 minutes and 6 seconds.

Recommended values:: It is recommended that you run with the default value.

Client idle timeout

If there is no data flow on a client/server connection, TCP/IP uses a so-called keepalive mechanism to verify that such an idle connection is still intact after a predefined period of time. The term idle means with respect to TCP/IP, and includes the case where the client is waiting in the recv() function because this waiting for data is a passive task and does not initiate any packet transfers for itself. If the remote system is still reachable and functioning, it will acknowledge the keep-alive transmission.

On Windows, this mechanism is controlled by the KeepAliveInterval and KeepAliveTime registry values (under Tcpip\Parameters).

The default values of these registry values determine that an idle connection is closed after two hours and six seconds if no keep-alive probes are acknowledged.

Recommended values:

It is recommended that you change the registry values of KeepAliveInterval to 360000 milliseconds (6 minutes).

This results in approximately 6 minutes + (6 * 1) seconds = 6 minutes and 6 seconds.