Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!PUCC.PRINCETON.EDU!08071TCP%MSU
From: 08071TCP%MSU@PUCC.PRINCETON.EDU (Doug Nelson)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: rlogind server doesn't die when client goes away
Message-ID: <9008210058.AA18055@ucbvax.Berkeley.EDU>
Date: 20 Aug 90 20:55:57 GMT
References: <tiamat!jim@uunet.uu.net>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Doug Nelson <NELSON%MSU.EDU@pucc.PRINCETON.EDU>
Organization: The Internet
Lines: 26

>Were's the situation:  We have an HP 9000/835 running HP-UX 7.0, an Annex II
>terminal server, and a few 386PC's running SCO Xenix with TCP/IP from SCO.
>If we do rlogins such as:  [list omitted]
>and the client end of the connection crashes [...], the server end of the
>connection NEVER goes away, unless the processes are killed by hand or the
>server machine is rebooted.
>
>Is this the "normal" behavior, or am I missing something completely obvious?

This is "normal" behavior for TCP connections.  There is no mechanism in the
TCP protocol spec for detecting a broken connection, unless the working end
attempts to send more data across the connection.  That will eventually
trigger a timeout, or, if the other host has been restarted, it will send a
reset, immediately closing the connection.

Many Unix systems (most BSD-based systems) have a mechanism called
"keep-alive" built into the TCP code.  A periodic probing of the
connection is done to see if it is still alive.  The probe is a single
data byte just outside the valid data window; on a good connection, this
triggers an ACK packet in response.  If the connection is gone, a reset
will be sent in response.  The keep-alive can have a negative effect,
however, in cases where both end systems are still alive, but the
network is temporarily disrupted due to a network problem of some sort.

Doug Nelson
Michigan State University