🚀 go-pugleaf

The ISODE function start_tcp_server sets the socket option SO_KEEPALIVE.
Over the last few days I have received many notes suggesting that the use
of SO_KEEPALIVE violates the TCP protocol (in essence, this is because the
KEEP_ALIVE traffic can cause an otherwise idle connection to fail:  if the
connection is not in use and some intermediate site goes down and comes back
up, the end points will carry on as if nothing happened.  If the down-and-up
happens while one end is waiting for a KEEP_ALIVE response, that end will
know of the intermediate problem).

Furthermore, the KEEP_ALIVE timeout seems unrelated to any useful quantity
(and is generally implememtation dependent).  To quote of the notes I
received recently:

"The keepalive implementations that I have heard about do not use the TCP
round trip time estimator to decide how long to wait for a response to the
keepalive.  This causes perfectly functional connections to die when the
round trip time gets too high."

To quote other notes: "Never predefine a timeout, it will eventually be too
small."  "Who's to say that 30 seconds (or 1 minute or 1 hour) is a
reasonable interval between keepalives? What's reasonable today might be
very unreasonable tomorrow."

If the reason KEEPALIVE is used is make the server aware of a client
crashing, then the error returns from read() or write() (or the appropriate
return from select()) should be sufficient to indicate that the client
has gone to la-la-land.

So why does ISODE use SO_KEEPALIVE?

Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Integration
pww@bnr.ca           [                          ]   Bell Northern Research
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7