RFC 492 (rfc492) - Page 2 of 7

Response to RFC 467

RFC 492                   RESPONSE TO RFC 467              18 April 1973


   The solution to this problem which RFC 467 proposes is to establish a
   pair of allocation-resetting control messages, one for use by the
   send side (RCS) and the other for the read side (RCR).  Whenever it
   wishes, either side may initiate the allocation-resetting sequence by
   setting its own allocation counter to zero and dispatching an RCS or
   RCR control message to the other side.  The host receiving it will
   set its own allocation counter for that connection to zero and send
   an RCR or RCS in reply.  Now the allocations for both sides are in
   synchronization (they are zero), and data transmission can begin
   again when a new allocation is sent by the receive side.  This
   procedure is intended to be initiated whenever either side thinks the
   connection has been quiescent for a suspiciously long time.  The
   actual specification of this control message pair in RFC 467 is more
   complex in that the pipeline between the two sides must be empty of
   data messages before the send side may dispatch an RCS control
   message.

   The second problem arises when the host at one side of an open
   connection crashes and purges its tables when it comes back up, while
   the host at the other end of the connection does not notice that
   anything has happened. (A similar situation occurs when the Network
   path temporarily fails between the two hosts, but only one host
   notices the failure and closes the connection.) If the host which
   crashed attempts to re-establish the connection, the host at the
   other end refuses to do so because the socket to which the connection
   request is targeted is seemingly already involved in an open
   connection.  Given the idiosyncrasies of the terminal support
   software of some systems, users at some consoles may be unable to
   reconnect to the distant system they were connected with when the
   local system supporting his terminal crashed.  This can continue
   indefinitely until the system which believes the original connections
   to be still open resets its internal state.  This is call the "half-
   closed" phenomenon, and a solution is proposed in RFC 467.  The basic
   principle of the RFC 467 proposal is that the side which has the open
   connection is able to detect an inconsistency whenever either side
   performs communication regarding this connection.  When it does, it
   is supposed to silently (without regard to normal protocol) close the
   connection and be ready to handle connection requests to the
   previously connected port.

   There are two types of interactions in which "half-closed"
   inconsistency is uncovered.  The first case occurs when the connected
   side sends a message over a write connection.  The side which has
   lost the connection receives this as a data message which does not
   correspond to an open connection and replies with an Error Report
   control message.  When the connected side receives it, it realizes
   that the connection actually no longer exists and deletes it from its
   own tables.  The second case occurs when the host which has lost the



Meyer