Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!ucbcad!ucbvax!GUMBY.WISC.EDU!g-tasman
From: g-tasman@GUMBY.WISC.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ..."layering violations"
Message-ID: <8711030915.AA00844@gumby.wisc.edu>
Date: Sat, 7-Nov-87 21:46:12 EST
Article-I.D.: gumby.8711030915.AA00844
Posted: Sat Nov  7 21:46:12 1987
Date-Received: Tue, 10-Nov-87 04:49:37 EST
References: <12347435144.54.PADLIPSKY@A.ISI.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 25


     You suggest that if a "host down" indication is received, a daemon
should immediately close the associated TCP connection.

     With an 1822 Distant Host connection to DDN, this may be a fairly
reasonable approach.  However, a typical DDN connection of late has been
X.25 or HDH.  Here, "host down" may have a more transitory meaning:  simply 
that there was noise on the host access line.  The remote host may well
reappear with all TCP connections intact.

     Consider in particular the case of a Telnet server.  If connections 
are cleared prematurely/incorrectly, extremely annoyed users will result.
On the other hand, I understand all too well the importance of eventually 
detecting and closing "half-open" connections which result from an actual
crash (since these will eventually inhibit new remote terminal sessions).

     The issue of distinguishing between a dead host and an "unhealthy"
host access line is likely to become increasingly serious over time, as more
DDN hosts switch to synchronous access protocols.  For a network client,
remote host status can simply be reported to the (human) user.  For a server,
however, I don't see a straightforward solution.


   						Mitchell Tasman