mrc@TOMOBIKI-CHO.CAC.WASHINGTON.EDU (Mark Crispin) (02/01/89)
I cannot verify this 100%, but observation suggests that if Unix receives
an ICMP Network Unreachable message it causes select() and/or read() to return
an error. Most applications programs consider this condition to indicate a
fatal loss of connectivity and they blast the connection away.
I've observed this problem with SUNs, VAXen, and NeXT machines.
I've had telnet and rlogin sessions suddenly blow away in the middle of
typein/echoing (with no human-noticable echo delays). Since Unix doesn't have
the PDP-10 concept of "detached jobs" this means I lose whatever work I was
doing at the time. I can reconnect back immediately.
I've seen client/server interactions where the server got the error and
in the course of cleaning up sent a text string that got to the client!
Can anyone shed any light on this? What can applications programs do to
protect against this? Is there a kernel patch that keeps intermittant errors
(a gateway spazz?) from blowing away healthy connections?
I wish I could provide more details, but until we get our network monitor
I can't say for sure what it is that is biting us. I know that it hits me
several times a day.
-------Rudy.Nedved@RUDY.FAC.CS.CMU.EDU (02/03/89)
Mark et al, The CMU version of the pseudo terminal (pty) driver for 4.3BSD based Unix (or for Mach Unix) has the concept of detached jobs. For this reason, it is not a big deal to lose a network connection for Mach systems (assuming you are running the CMU modified telnet daemon which uses the CMU pty driver). For programs that use the network, you can detect a problem with an aborted connection by checking errno which is documented in intro(2). You will get an errno of ENETUNREACH, ENETRESET, ECONNABORTED or ECONNRESET (most likely). But for general transparent network support of terminal sessions, the concept of a detached terminal is needed. We have had this concept since 4.0BSD Unix before the days of TCP (we used it for Xerox BSP/PUP 'Chat' connections). -Rudy