Retransmissão de dados e erro de soquete WSAECONNABORTED (10053)

Question

Digamos que eu tenha dois soquetes conectados uns aos outros ( Socket A e Socket B ).

Se o computador que tiver Socket B estiver desconectado da energia, se Socket A tentar enviar alguns dados para Socket B , os dados não serão reconhecidos e, assim, o TCP retransmitirá os dados novamente e novamente na esperança de uma confirmação, até o TCP desistir e decidir não retransmitir mais os dados e informar Socket A que ocorreu o erro de soquete WSAECONNABORTED (10053) .

Minhas perguntas são:

• É garantido que sempre receberei o erro de soquete WSAECONNABORTED (10053) após algumas tentativas de retransmissão (acredito que sim, porque senão o TCP continuará a retransmitir para sempre!)
• Quantas tentativas de retransmissão são necessárias para o TCP desistir e causar o erro WSAECONNABORTED (10053) do soquete?
• Esse número de novas tentativas de retransmissão é configurável?

Answer 1

Os timers do Windows para TCP usam uma unidade de tempo chamada tempo limite de retransmissão (RTO) baseado no tempo de ida e volta estimado (ou RTT) entre o emissor e o receptor, bem como a variação neste tempo de ida e volta. O comportamento deste temporizador é especificado em RFC 6298 . Para mais informações, consulte o artigo da Wikipédia Protocolo de Controle de Transmissão .

A maneira como funciona no Windows é a seguinte:

1. Um RTO estimado é estabelecido pela primeira vez
2. A mensagem TCP é enviada e esperamos por um pacote ACK (confirmação)
3. Se o ACK não chegou, duplicamos o tempo de espera e voltamos para o passo 2
4. Se o ACK for recebido, um novo RTO será calculado
5. SE um ACK nunca for recebido, a conexão será cancelada com o erro WSAECONNABORTED.

O Windows usa dois parâmetros de registro para este protocolo, descritos neste artigo da Microsoft Como modificar o tempo limite de retransmissão máximo de TCP / IP .

TcpMaxDataRetransmissions

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

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

Descrição:

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)

Descrição:

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.

Embora TCPInitialRtt comece com um tempo limite inicial de 3 segundos, será suavizado para um valor razoável quando os pacotes são transmitidos corretamente.

Por exemplo, como isso funciona se tomarmos os valores padrão de 3 segundos RTO e 5 tentativas, o tempo total de espera será:

1. primeiro tempo limite: 3 segundos
2. segundo tempo: 6 segundos
3. terceiro tempo: 12 segundos
4. quarto tempo limite: 24 segundos
5. quinto e último tempo: 48 segundos

O que dá um tempo total de espera de 93 segundos antes que a conexão seja interrompida. Na maioria dos casos, se a conexão já funcionou corretamente, o tempo limite será muito menos.

    

Answer 2

Normalmente time é usado ( continue tentando até que um valor de tempo limite tenha sido alcançado ), mas isso depende de como o software cliente / servidor foi gravado.

Se o tempo for usado, para saber o número de novas tentativas, você precisará saber com que frequência as novas tentativas acontecem.

Veja abaixo as possíveis maneiras de definir um tempo limite se o programa estiver usando o Winsock.

O software também pode ser escrito para usar número de tentativas antes de falhar ou tempo antes de falhar ou uma combinação de ambos.

Fonte Perguntas freqüentes sobre o programador Winsock

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.