Arnt Gulbrandsen wrote:
A lot of the application code I've seen could be described as "second-guess one or more TCP timers, add pepper and salt, serve as desired". The second half of that is obviously not amenable to standardisation. The TCP stack cannot take any action. But the first part seems more... reasonable. I think the TCP stack can inform the application of its state, better than it does via the APIs I know.
The most implementations I've seen are "send a couple of bytes each N seconds" on one side and "make sure there's no more 4N seconds elapse between two heartbeats".
The obvious problem is that heartbeats can thus sit in transmit buffer waiting to be delivered. They can even be retransmitted. Etc. In any case the functionality they are supposed to provide is pretty heavily distorted.
Of course it's a local matter, not really IETFish. Where is the boundary these days? Didn't some RFC extend the Berkeley sockets API for v6?
SCTP extends BSD sockets API IIRC :) Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf