On Friday 25 June 2010 21:10:45 ext Martin Sustrik, you wrote:
Rémi Denis-Courmont wrote:
On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote:
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various latencies and
throughputs and won't congest the network even if used on a wide scale.)
On most OSes, you can enable TCP keep-alives. Then your TCP socket will
return a time out error if the other end "dies". So yes, there is a way
to do this at the TCP protocol level.
Unfortunately, there is no standard API to use and configure this feature
of TCP. On Linux, you can adjust all parameter on a per-socket basis
(refer to 'man 7 tcp' and look for TCP_KEEP for details) though.
There is also no programmatic way to know that the other peer is using
keep- alives or not (should you need to know that anyway).
This is a dumb keepalive option (send heartbeat each N seconds, N being
defined by user), right?
What I had in mind whether there ever been an attempt to define dynamic
keepalive algorithm that adjusts keepalive intervals according to the
observed throughput and roundtrip latency figures (dynamic in the same
way as CC dynamically adjusts throughput).
Any ideas?
You can probably change the values. But I don't really see the statistical
correlation of throughput and round trip time to the probability that the peer
will fail within a certain time interval.
I mean, you can probably establish a weak correlation between them, or at
least between the variation of the bandwidth and RTT to the probability of
failure. But I somehow doubt it will be sufficiently strong a correlation that
that a very clever algorithm would be significantly better than a plain dumb
ping-pong at constant or exponential backoff interval.
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf