Why Short TCP Connections Fail: Decoding Errors 110 & 99 and Fixes

Short Connection Common Errors

When clients frequently use short connections, they often encounter [110][connection time out] and [99][could not assign requested address] . These errors are mainly caused by the client’s TIME‑WAIT port state and the server’s listen queue limits.

Root Causes of the Two Errors

[99][could not assign requested address] occurs when the number of ports in TIME‑WAIT state fills the entire ip_local_port_range defined by the kernel, leaving no free ports for new connections.

On the server side, a massive influx of short connections can overflow the listen queue (both SYN and ACCEPT queues). When the ACCEPT queue is full, new connection requests are dropped, leading to error 110.

TIME‑WAIT Explanation

TIME‑WAIT is the state after a connection is actively closed and the final ACK is sent. It lasts for 2MSL (Maximum Segment Lifetime) to ensure delayed packets from the previous connection do not interfere with new ones.

During TIME‑WAIT, the same 4‑tuple cannot be reused, and the kernel checks if the port can be rebound for a new connection.

Below is a snippet from the Linux 2.6.32.70 kernel showing the reuse logic:

The function returns 1 if the port can be reused, otherwise 0, which results in the EADDRNOTAVAIL error.

Verification steps:

If tcp_tw_reuse is disabled and no free ports exist, error 99 occurs.

If tcp_tw_reuse is enabled but the interval between two connections on the same port exceeds 1 second, error 99 also occurs.

Test by limiting the port range to a single value:

$cat "net.ipv4.ip_local_port_range = 1024 1024" >> /etc/sysctl.conf && sysctl -p

The client then receives the [99][could not assign requested address] error, confirming the analysis.

Accept Queue Overflow and Error 110

Linux moves incoming connections through the SYN queue and then the ACCEPT queue. The lengths of these queues are limited by three parameters:

listen backlog argument

kernel parameter somaxconn (affects ACCEPT queue)

kernel parameter tcp_max_syn_backlog (affects SYN queue)

In our production issue the ACCEPT queue overflowed. The kernel code that truncates the backlog based on somaxconn is shown below:

When the ACCEPT queue is full, new SYN requests are dropped, causing the client to time out and report error 110.

Kernel snippet illustrating the check:

Verification experiments:

Set somaxconn to 128, backlog to 8192, run many short‑lived clients and observe frequent errors.

Set both somaxconn and backlog to 8192, repeat the test and observe no errors.

Results show that increasing somaxconn reduces dropped SYNs.

Summary

The experimental results align with kernel code and our expectations.

Solutions

Increase the client connection timeout (e.g., from 300 ms to 3 s).

Raise the server’s somaxconn limit (note this mitigates but does not fully solve the issue).

Use a connection pool on the client side to convert short connections into long‑lived ones, which is the most effective long‑term fix.