Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!THINK.COM!barmar
From: barmar@THINK.COM (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: SO_KEEPALIVE considered harmful?
Message-ID: <19890525225353.2.BARMAR@OCCAM.THINK.COM>
Date: 25 May 89 22:53:00 GMT
References: <8905252032.AA05156@braden.isi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 29


    Date: Thu, 25 May 89 13:32:04 PDT
    From: braden@venera.isi.edu


    Sorry, but Dave Crocker is perfectly correct.  The behaviour that you
    describe is a property of many current-generation LAN-oriented TCP's
    [a transparent euphemism], but not of the original research TCP's that
    were WAN-oriented ... nor even of a TAC.  A host implementation that
    follows the Host Requirements RFC can behave like a TAC for Telnet
    connections: tell the user when it is retransmitting excessively, but DO
    NOT CLOSE the connection.  Let the user decide when to give up.  I
    don't think we users should accept anything less of our communication
    software.

RFC-793, which defines TCP, says, "If data is not successfully delivered
to the destination within the timeout period, the TCP will abort the
connection."  I can believe that the Host Requirements RFC changes
"abort the connection" to "signal an error", but this contradicts your
claim that original TCPs were more forgiving.

Also, how is a TELNET server or xterm client supposed to tell the user
when it is retransmitting excessively?  Its communication path to the
user is the failing connection.  Sure, it could put something in a
system log or write a message to the system console, but how is the
operator (if there is one) supposed to know why the remote machine isn't
responding?

                                                barmar