This looks to me like exponential backoff after an unacknowledged transmission. TCP_MAXRT will allow you to set how long you want to wait before giving up on trying to transmit. TM_TCP_MAX_REXMIT will let you set the max number of retries.
exact timing keep-alive in linux TCP/IP programming
-
29-06-2022 - |
Pergunta
as I know there's two ways to resolving the Half-Open connection problem. One is the heartbeat tech. and the other, is my problem: keep-alive.
I know that keep-alive have three properties like:
tcp_keepalive_time \ tcp_keepalive_intvl \ tcp_keepalive_probes.
And I set them to
5secs \ 1sec \ 10
Which means that the keepalive routines wait for 5 seconds before sending the first keepalive probe, and then resend it every 1 seconds. If no ACK response is received for 10 consecutive times, the connection is marked as broken.
I do enabled keep-alive and set these properties for it in my linux C++ code by calling setsockopt(), and sometimes, it works fine as follows:
But in other time, the keep-alive DOES NOT send, and the retransmission msg has been sent and stucked instead:
It just sending 7-times(the time between each resend is larger than 1sec, almost 2~5secs). And then stucked for a long time.
So why TCP keep-alive does not send sometimes? And how can I make sure that keep-alive probe can always been sent. Should I do someting else?
Thanks for all of your helping.
EDIT
- As @West said that the stuck is come from exponential backoff after a unacknowledged transmission, but why the retransmission stuck the process of sending keep-alive probe? is there any priority or something?
Solução