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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf