Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!ogicse!milton!mrc
From: mrc@milton.u.washington.edu (Mark Crispin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Is the Internet usable for wide-area interactive conversations?
Message-ID: <1991Jun18.173511.7510@milton.u.washington.edu>
Date: 18 Jun 91 17:35:11 GMT
References: <2039.Jun1803.33.1391@kramden.acf.nyu.edu>
Organization: University of Washington, Seattle
Lines: 29

In article <2039.Jun1803.33.1391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Keep in mind that an active TCP connection---e.g., a remote login---dies
>the second that the network becomes unreachable.

The above statement is only true with certain broken versions of BSD
TCP software.  It is not true on other operating systems; nor is it
true on fixed versions of BSD (you can thank me for nagging NeXT to
fix it).

What happened is that long ago some cretin thought that it was
important to tell user programs about `network unreachable' errors
(which generally are transient) so he made the TCP I/O system calls
fail if it happened.  The problem is that 99.99% of TCP user software
considers a failure of a read() or write() system call to be a hard
failure that necessitates the termination of the program.

The fix is to change the `network unreachable' handling in the kernel
so that it will cause an open() system call to fail, but no-op it for
read() and write().  I believe the Host Requirements RFC mandates
this.  The idea is that `network unreachable' will stop you from
opening a connection in the first place, but won't affect an existing
connection.

A few stubborn individuals continue to insist that every user program
in the world should instead interpret the error code and figure out
from that whether or not it is a hard error, but fortunately they are
in a dwindling minority.

-- DoD#105