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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf