Considerando a descrição de TCP_USER_TIMEOUT :
When the value is greater than 0, it specifies the maximum amount of time in milliseconds that transmitted data may remain unacknowledged before TCP will forcibly close the corresponding connection and return ETIMEDOUT to the application.
Very short USER TIMEOUT values can affect TCP transmissions over high-delay paths. If the user timeout occurs before an acknowledgment for an outstanding segment arrives, possibly due to packet loss, the connection closes. Many TCP implementations default to USER TIMEOUT values of a few minutes. Although the UTO option allows suggestion of short timeouts, applications advertising them should consider these effects.
Eu esperaria um TCP_USER_TIMEOUT de 2 ms ter conseqüências catastróficas: em uma rede onde o RTT é menor que 2 ms, todo pacote TCP enviado teria tempo limite esperando por um ACK e a conexão seria fechada. No entanto, no meu ambiente eu não estou experimentando isso. Conexões podem ser estabelecidas e os dados são enviados e recebidos corretamente. Eu percebo, no entanto, que se eu puxar o cabo ou a interface de recepção, o TCP_USER_TIMEOUT efetivamente detecta uma perda na conexão e a conexão é fechada em tempo hábil. Então, TCP_USER_TIMEOUT está funcionando, mas não da maneira que eu esperava.
O que eu estou entendendo mal sobre TCP_USER_TIMEOUT? Por que os valores inferiores ao RTT não causam a queda da conexão?
Caso seja útil, meu cliente é uma caixa do Scientific Linux 6.1 com o kernel 2.6.32.
A implementação do UTO no Linux foi imprecisa e foi corrigida recentemente por este conjunto de patches: (caso você não seja o autor deste conjunto de patches): link
No entanto, mesmo depois que o UTO é disparado, o host pára de retransmitir e vai para o estado TCP_CLOSE, mas não redefine a conexão. É de responsabilidade do aplicativo enviar o RST.
Tags tcp