In message <4C28A787(_dot_)2040706(_at_)gulbrandsen(_dot_)priv(_dot_)no>, Arnt
Gulbrandsen writes:
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.
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?
Actually it was a pair of RFCs (manditory and optional parts of the
(singular) API). The Open Group then botched the incorporation of
them into POSIX by only adding the manditory parts when they were
ment to be added as a pair. Linux developers then componded Open
Group's error by hiding the optional parts of the API behind #ifdef's.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf