Re: TCP Keepalives Problem on Linux
- From: olssons@xxxxxxxxx
- Date: 22 May 2006 19:09:27 -0700
Rick Jones wrote:
By definition, from the perspective of HostA when that single byte is
sent and remains unACKed, the connection remains "active" rather than
idle so the keepalives should not start. The connection will be
timed-out based on the "normal" retransmission mechanisms.
Only when/if there is no outstanding data on a connection should a
keepalive timer fire.
Thanks for this information. It is useful for understanding what Linux
is doing under the covers.
It seems I will need to write some additional code. Fortunately the
existing application protocol I am using has a message that requires a
response. I can timeout that response by writing some extra code and
fix this specific problem. Unfortunately there are lots other
protocols that are also broken given this information.
The code I'm working with was originally developed on Tru64 and Tru64
doesn't implement their keepalive processing in the same way as Linux.
If data is not received on Tru64, the connection is considered idle and
keepalives begin. If data is not received after a given number of
keepalive probes, the connection is closed. This seems to make sense
and I wonder what it hurts for Linux to do something similar... unless
there are legitimate cases where this logic fails.
It seems like keepalive processing for Linux should be for data
received from the perspective of a host. If data is never received,
the connection should be closed after the timeout periods (assuming
keepalive is set and probes have been sent). Otherwise a host can
inadvertently prohibit keepalive processing from taking place by
attempting to send data to the other host (the one that isn't
- Prev by Date: apache 2.0 - number of httpd grows up + slow response
- Next by Date: Re: Broadcast Packets Evil?
- Previous by thread: Re: TCP Keepalives Problem on Linux
- Next by thread: apache 2.0 - number of httpd grows up + slow response