Path: utzoo!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SO_KEEPALIVE considered harmful?
Summary: yes, actually.
Message-ID: <2012@yunexus.UUCP>
Date: 26 May 89 12:07:40 GMT
Article-I.D.: yunexus.2012
References: <8905250638.AA21706@ucbvax.Berkeley.EDU> <20761@news.Think.COM>
Reply-To: davecb@yunexus.UUCP (David Collier-Brown)
Organization: York U. Computing Services (free at last!)
Lines: 28

In article <20761@news.Think.COM> barmar@kulla.think.com.UUCP (Barry
Margolin) writes: TCP's robustness is still a good idea.  It's nice
| to be able to swap Ethernet cables without causing all the network
| connections to die.  But in my experience (which, I admit, isn't all
| that extensive), any connection that dies for more than a minute or
| two probably isn't going to come back.  [...]

  Actually the connection might well come back: I had a crossbar switch
that timed me out every so often, assuming that I don't leave the terminal
for substantial periods without disconnecting it.  (This is silly, but not
unreasonable for a device which thinks its switching telephone voice lines).
  After I got back to the terminal controller I could then reconnect
to my process.

  Keepalives would be more secure in such a situation (anyone could
pretend to be me if the tty server disconnected), but would tend to
cause me to lose work-in-process...
  Methinks that a facility for polling a connection makes sense, as
well as one to send "reset the poll clock, if any" (keepalives redux)
would be useful.  As does Barry, I'd propose they be optional.  I'd also
propose that
	1) if one exists, so must its complement
	2) they be composed out of existing facilities, as were
	  keepalives, and
	3) they be distinguishable from any other facility (unambiguous).

--dave