Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!NNSC.NSF.NET!craig From: craig@NNSC.NSF.NET (Craig Partridge) Newsgroups: comp.protocols.tcp-ip Subject: re: SO_KEEPALIVE considered harmful? Message-ID: <8905231944.AA06042@ucbvax.Berkeley.EDU> Date: 23 May 89 16:41:15 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 75 > I have a random question that I hope this illustrious audience can answer > definitively for me (or else point me to a definitive source). Is the BSD > notion of SO_KEEPALIVE on a TCP connection considered kosher with respect to > the TCP specification? If so, is its use to be encouraged? Specifically, > it has been suggested that in the X Window System world, X libraries > should automatically be setting SO_KEEPALIVE on connections to X servers. Is this > a reasonable thing to do? Oh what fun! Keepalive wars return.... Well, I'm a firm hater of keep-alives, although Mike Karels has persuaded me that in the current world they are a useful tool for catching clients that go off into hyperspace without telling you. I have lots of fellow travellers (actually, I'm probably a fellow traveller with Phil Karn, president of the "I hate keep-alives" party), witness the current host requirements text, which is appended. Craig Implementors MAY include "keep-alives" in their TCP | implementations, although this practice is not universally | accepted. If keep-alives are included, the application MUST | be able to turn them on or off for each TCP connection, and | they MUST default to off. | Keep-alive packets MUST NOT be sent when any data or | acknowledgement packets have been received for the | connection within a configurable interval; this interval | MUST default to no less than two hours. | An implementation SHOULD send a keep-alive segment with no | data; however, it MAY be configurable to send a keep-alive | segment containing one garbage octet, for compatibililty | with erroneous TCP implementations. | DISCUSSION: | A "keep-alive" mechanism would periodically probe the | other end of a connection when the connection was | otherwise idle, even when there was no data to be sent. | The TCP specification does not include a keep-alive | mechanism because it could: (1) cause perfectly good | connections to break during transient Internet | failures; (2) consume unnecessary bandwidth ("if no one | is using the connection, who cares if it is still | good?"); and (3) cost money for an Internet path that | charges for packets. | Some TCP implementations, however, have included a | keep-alive mechanism. To confirm that an idle | connection is still active, these implementations send | a probe segment designed to elicit a response from the | peer TCP. Such a segment generally contains SEG.SEQ = | SND.NXT-1. The segment may or may not contain one | garbage octet of data. Note that on a quiet | connection, SND.NXT = RCV.NXT and SEG.SEQ will be | outside the window. Therefore, the probe causes the | receiver to return an acknowledgment segment, | confirming that the connection is still live. If the | peer has dropped the connection due to a network | partition or a crash, it will respond with a reset | instead of an acknowledgement. | Unfortunately, some misbehaved TCP implementations fail | to respond to a segment with SEG.SEQ = SND.NXT-1 unless | the segment contains data. Alternatively, an | implementation could determine whether a peer responded | correctly to keep-alive packets with no garbage data | octet. | A TCP keep-alive mechanism should only be invoked in | network servers that might otherwise hang indefinitely | and consume resources unnecessarily if a client crashes | or aborts a connection during a network partition. |