Data retransmission and WSAECONNABORTED (10053) socket error

Question

Say I have two sockets that are connected to each other (Socket A and Socket B).

If the computer that have Socket B is unplugged from power, then if Socket A tries to send some data to Socket B, the data will not get acknowledged and so TCP will retransmit the data again and again in hope for an acknowledgment, until TCP gives up and decides not to retransmit the data anymore and tells Socket A that the socket error WSAECONNABORTED (10053) has occurred.

My questions are:

• Is it guaranteed that I will always get the socket error WSAECONNABORTED (10053) after some retransmission retries (I believe it is, because otherwise TCP will just continue to retransmit forever!)?
• How many retransmission retries does it take for TCP to decides to give up and causes the WSAECONNABORTED (10053) socket error?
• Is this number of retransmission retries configurable?

Answer 1

Windows timers for TCP use a unit of time called retransmission timeout (RTO) that is based on the estimated round-trip time (or RTT) between the sender and receiver, as well as the variance in this round trip time. The behavior of this timer is specified in RFC 6298. For more information see the Wikipedia article Transmission Control Protocol.

The way it works in Windows is as follows :

1. An estimated RTO is first established
2. The TCP message is sent and we wait for an ACK (acknowledge) packet
3. If the ACK has not arrived, we double the wait time and go back to step 2
4. If the ACK is received, a new RTO is calculated
5. IF an ACK is never received, the connection is aborted with error WSAECONNABORTED.

Windows uses two registry parameters for this protocol, described in this Microsoft article
How to modify the TCP/IP maximum retransmission time-out.

TcpMaxDataRetransmissions

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Value Name:  TcpMaxDataRetransmissions
Data Type:   REG_DWORD - Number
Valid Range: 0 - 0xFFFFFFFF
Default:     5

Description :

This parameter controls the number of times TCP retransmits an individual data segment (non connect segment) before aborting the connection. The retransmission time-out is doubled with each successive retransmission on a connection. It is reset when responses resume. The base time-out value is dynamically determined by the measured round-trip time on the connection.

TCPInitialRtt

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID for Adapter

Value Name:  TCPInitialRtt
Data Type:   REG_DWORD
Valid Range: 300-65535 (milliseconds in decimal)
Default:     0xBB8 (3000 milliseconds expressed in hexadecimal)
                

Description:

This parameter controls the initial retransmission time-out that is used by TCP on each new connection. It applies to the connection request (SYN) and to the first data segments that is sent on each connection. For example, the value data of "5000 decimal" sets the initial retransmit time to five seconds.

NOTE: You can increase the value only for the initial time-out. Decreasing the value is not supported.

Although TCPInitialRtt starts with an initial timeout of 3 seconds, it will be smoothed-out to a more reasonable value when packets are transmitted correctly.

For example of how this works, if we take the default values of 3 seconds RTO and 5 retries, the total wait-time will be :

1. first timeout time : 3 seconds
2. second timeout : 6 seconds
3. third timeout : 12 seconds
4. fourth timeout : 24 seconds
5. fifth and last timeout : 48 seconds

Which gives a total wait-time of 93 seconds before the connection is aborted. In most cases, if the connection has ever worked correctly, the timeout will be much less.

Answer 2

Normally time is used (keep retrying until a timeout value has been reached), but it depends on how the client/server software has been written.

If time is used then in order to know the number of retries you would have to know how often the retries happen.

See below for the possible ways to set a timeout if the program is using Winsock.

The software could also be written to use number of retries before failing or time before failing or a combination of both.

---

Source Winsock Programmer’s FAQ

2.15 - How can I change the timeout for a Winsock function?

Some of the blocking Winsock functions (e.g. connect()) have a timeout embedded into them. The theory behind this is that only the stack has all the information necessary to set a proper timeout. Yet, some people find that the value the stack uses is too long for their application; it can be a minute or longer.

You can adjust the send() and recv() timeouts with the SO_SNDTIMEO and SO_RCVTIMEO setsockopt() options. .

For other Winsock functions, the best solution is to avoid blocking sockets altogether. All of the non-blocking socket methods provide ways for you to build custom timeouts:

• Non-blocking sockets with select() – The fifth parameter to the select() function is a timeout value.

• Asynchronous sockets – Use the Windows API SetTimer().

• Event objects – WSAWaitForMultipleEvents() has a timeout parameter.

• Waitable Timers – Call CreateWaitableTimers() to make a waitable timer, which you can then pass to a function like WSAEventSelect() along with your sockets: if none of the sockets is signalled before the timer goes off, the blocking function will return anyway.

Note that with asynchronous and non-blocking sockets, you may be able to avoid handling timeouts altogether. Your program continues working even while Winsock is busy. So, you can leave it up to the user to cancel an operation that’s taking too long, or just let Winsock’s natural timeout expire rather than taking over this functionality in your code.