Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!boring.cray.com!hrp From: hrp@boring.cray.com (Hal Peterson) Newsgroups: comp.protocols.tcp-ip Subject: SO_KEEPALIVE considered harmful? Message-ID: <8905231702.AA03922@rothko.cray.com> Date: 23 May 89 17:02:52 GMT References: <8905231205.AA00500@expire.lcs.mit.edu> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 34 Here are a couple of relevant extracts from section 4.2.3.5 of the 17 May draft of the Requirements for Internet Hosts RFC: 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. | [ . . . ] 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. | Bob Braden points out that one of the design goals of TCP/IP was and is robustness in the face of errors: even if a few gateways melt down, the TCP connections that had been using them should pick up where they left off when new routes materialize. Keepalives are explicitly designed to avoid this. The pros and cons, however, are subject to some disagreement. -- Hal Peterson Domain: hrp@cray.com Cray Research Old style: hrp%cray.com@uc.msc.umn.edu 1440 Northland Dr. UUCP: uunet!cray!hrp Mendota Hts, MN 55120 USA Telephone: +1 612 681 3145