Did this article resolve your question/issue?



Can the time a socket spends in TIMED-WAIT state be reduced?

« Go Back


TitleCan the time a socket spends in TIMED-WAIT state be reduced?
URL NameCan-the-time-a-socket-spends-in-TIMED-WAIT-state-be-reduced
Article Number000112040
EnvironmentProduct: OpenEdge
Version: All supported versions
OS: All supported platforms
Other: sockets programming
Question/Problem Description
Can the time a socket spends in TIMED-WAIT state be reduced?
Over time a number of sockets accumulate in TIME-WAIT state. Is this a problem?
Can the time a socket is waiting after close to handle packets still in the network be reduced?
Is there a method for reducing the time before a socket's resources are returned to the O.S.?
Why do sockets in a TIMED-WAIT state remain in the system?
Steps to Reproduce
Clarifying Information
Error Message
Defect Number
Enhancement Number
An application employs a server socket that opens, accepts a connection, receives a message, returns a message, then closes the socket. This results in intermittent connection failure when this occurs many times and quickly. TIMED-WAIT state is a mechanism in TCP/IP stacks that keeps sockets open after an application has shutdown the socket. Its purpose is two fold:
  1. It stops packets that are delayed from being accepted by another socket using the same source address, source port, destination address, destination port combination.
  2. It ensures the remote end of a connection has closed the connection. This is especially needed when a last ACK packet is lost.

MSL (maximum segment length) is the unit of time associated with TIMED-WAIT state.
  • By default on Windows MSL (maximum segment length) is 120 seconds (2 minutes). The wait time, default is 2*MSL, 240 seconds or 4 minutes.
  • By default on Linux MSL (maximum segment length) is 60 seconds (1 minute). The wait time, default is 2*MSL, 120 seconds or 2 minutes.
It is widely recommended that TCP TIME-WAIT state value not be changed. It is normal for sockets to accumulate when a server is opening and closing sockets faster then the TIME-WAIT state will allow the socket's resources to be absorbed back into the system. Besides the potential for new sockets accepting delayed packets from previous connections, this value is a global value. Being a global value, all sockets created after this value is changed will inherit the new value. You could potentially cause some applications to stop working.

TIMED-WAIT state is a O.S. attribute. There are no APIs within ABL for modifying the value of this attribute.

On Windows systems the TIMED-WAIT state is a registry value:
(Where: 1E = 30 seconds)

On Linux systems the TIMED-WAIT state is a kernel value. tcp/sys/net/ipv4/tcp_fin_timeout is where this kernel value is stored.

To update the current setting:
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

To view the current setting:
cat /proc/sys/net/ipv4/tcp_fin_timeout
References to other Documentation:

The following web sites contain addition information describing TIMED-WAIT state:  (Microsoft TechNet: TcpTimedWaitDelay). (Coping with the TCP TIME-WAIT state on busy Linux servers).  Red Hat Linux: What is a CLOSE_WAIT socket, and what does it mean).

To check the state of socket usage on a system, use the command netstat -a. This can be run from a cmd prompt on Windows or a shell on Linux.
The following web site describes the netstat command:
Last Modified Date6/15/2020 2:24 PM
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.