Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!OKEEFFE.BERKELEY.EDU!karels
From: karels@OKEEFFE.BERKELEY.EDU (Mike Karels)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ..."layering violations"
Message-ID: <8711010759.AA08856@okeeffe.Berkeley.EDU>
Date: Sun, 1-Nov-87 02:59:53 EST
Article-I.D.: okeeffe.8711010759.AA08856
Posted: Sun Nov  1 02:59:53 1987
Date-Received: Thu, 5-Nov-87 07:48:46 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 23

Two comments on your recent message.  First, about TCP behavior
when ICMP unreachables are received: I definitely agree that TCP
ought not to quit when it receives an unreachable.  However, in Unix
and probably most other systems, it's hard to report "soft" errors
to a network client.  In 4.3, I chose to return a single error
on the next send or receive, but the TCP connection remains open.
Unfortunately, most network applications carefully check for errors
on each send/receive, and they give up on the first error.
(4.2 aborted the connection when ICMP errors were received,
and thus the application had no chance to keep trying.)

I also agree that you're right to distinguish between interactive
network users and automatic daemons.  However, it's precisely for
the daemons that are willing to wait patiently forever that "keep alive"
messages are needed.  Although the telnet client will give up and close
the connection manually, there needs to be a way to prevent systems
from accumulating useless, disconnected telnet servers and other such
trash.  Most application-level programs don't have their own keep-alive
or are-you-there to detect network failure.  For those reasons, we use
TCP-level keepalives (which are also not well provided-for at this level)
only on network servers that don't have their own time-out scheme.

		Mike