Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!cbosgd!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: A Noop Strategy for TCP
Message-ID: <9331@ucbvax.ARPA>
Date: Thu, 25-Jul-85 16:47:12 EDT
Article-I.D.: ucbvax.9331
Posted: Thu Jul 25 16:47:12 1985
Date-Received: Sat, 27-Jul-85 03:15:48 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 22

From: Mark Crispin <MRC@SIMTEL20.ARPA>

     Hear hear!  This is a great idea.  It is one thing to provide
connection continuation across a service interruption (a real win
on satellite links!) but it is quite another to keep an idle
connection around for days until the operator nukes it.

     I suggest using some sort of zero-window probing, and consider
the other end to be down if there is a no-reply condition or if the
hardware level (e.g. 1822) has a "host down" condition and reports
that (this slightly violates the modularity of TCP, but if you're
careful you can make it into some sort of "signal to TCP from
hardware level" which isn't too kludgy).  There should be a minimum
"keep time" for the connection to come back -- say 30 minutes to an
hour -- after which the host should discard the connection even if
it doesn't get a reset from the other host.

     If a host comes back from a service interruption without a
reload, it should immediately probe all its connections to see what
connections are still valid and immediately nuke all the ones which
don't answer or reset.
-------