rfc492.txt

RFC 的详细文档！

Network Working Group                                           E. Meyer
Request for Comments: 492                                    MIT-Multics
NIC: 15357                                                 18 April 1973
                          RESPONSE TO RFC 467


   Jerry Burchfiel and Ray Tomlinson of Bolt, Beranek, and Newman, Inc,
   have issued a Network Request for Comments (#467) which proposes a
   solution to two problems which have been annoying to Network users.
   This document will briefly describe the problems and proposed
   solutions, and offer comments and alternative suggestions.

BACKGROUND

   To establish a data connection between two hosts through the network,
   the Host-Host protocol requires that one host send a Request for
   Connection and that the second Host reply affirmatively.  If the
   desired socket("port") at the target host is already in use, the
   target host replies negatively.  Once a connection is established,
   data transmission may proceed, controlled by data allocation messages
   dispatched by the host at the read end of the connection.  The host
   on the write side is constrained by protocol to send only as much
   data as has been permitted by the read side.  If it exhausts the
   allocation it must wait until a new data allocation control message
   is received.  Then it can send more.

   One of the problems arises from the fact that messages apparently are
   lost somewhere in the transmission path with a low but regular
   frequency.  If an allocate control message concerning an open
   connection is lost, a situation can occur in which data transmission
   over the connection ceases permanently.  This can happen because the
   host at the send side believes it has exhausted its allocation, and
   sits holding back data to end because it is waiting for a new data
   allocation message to come from the read side.  However, the read
   side has actually sent out the allocation, but it was lost.  It
   thinks that the send side may proceed and sits waiting for data to
   come in over the connection.  This is known as the "lost allocate"
   phenomenon.  However, similar symptoms can occur if a data message is
   lost and the send side exhausts its allocation before a new
   allocation is given by the read side.  The send side waits for a new
   allocation, but the read side has not received one of the data
   messages and believes there is still some allocation left.  In either
   case, the result is a permanently blocked connection.  This appears
   to happen with enough regularity to be annoying to users who connect
   typewriters to foreign hosts through the Network.  When it happens,
   the only current solution is to disconnect and to establish a new
   connection.




Meyer                                                           [Page 1]

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                                                           [Page 2]

RFC 492                   RESPONSE TO RFC 467              18 April 1973


   connection sends a connection request to the other host specifying
   the same sockets as were involved in the previous connection.  The
   host receiving this request recognizes the inconsistency, because not
   only is the local socket already connected, it is connected to the
   same foreign socket as specified in the connection request.  It
   internally deletes its record of the connection, making the local
   socket free, and responds to the connection request normally.

COMMENTS AND ALTERNATIVE PROPOSALS

   The Project MAC Computer Systems Research Division opposes both
   protocol change proposals in this RFC.  We have moderate opposition
   to the proposal to handle half-closed connections because it fails to
   consider all aspects of the problem and it further complicates the
   protocol, but very strong opposition to the proposal for allocation
   resynchronization because it attacks a symptom, not the disease, and
   furthermore tends to mask diagnosis of a potentially very serious
   network problem.

   RFC 467 proposes the addition of two control messages, Reset
   Connection by Sender (RCS) and Reset Connection by Receiver (RCR)
   whose sole purpose is to resynchronize the allocation counters at
   both ends of a connection.  In this way the "lost allocate"
   phenomenon, in which allocate (ALL) control messages somehow are lost
   in transmission so that the sending side is unable to continue
   transmitting data is solved.  If it were truly a "lost allocate"
   problem, this would be viable solution.  However, I feel that this is
   really a "lost message" problem, in which messages of all kinds are
   being lost in transmission, which is much more serious.  ALL messages
   may be very frequent in communications with some hosts and these may
   be the ones most often lost, but if messages are actually lost in the
   network, it may also be data messages that are being lost, which
   would provide similar symptoms.  A lost message in a Telnet
   connection can be detected and overcome by the human user, but an
   undetected lost message from the middle of a transmitted file can
   have disastrous consequences, especially because the invalid file, if
   ever detected, can perhaps not be corrected.  Because this "solution"
   tends to paper over the immediate problem and to propagate it to a
   point far removed in both space and time at which it appears as an
   incomprehensible disaster, it should be strongly opposed.

   The real problem appears to be the random undetected loss of messages
   somewhere in the transmission path.  A true solution to this problem
   is either a) to eliminate the cause of undetected loss of messages,
   or b) to move to a new protocol which is designed to cope with an
   unreliable physical transmission path.  Either of these solutions is





Meyer                                                           [Page 3]

RFC 492                   RESPONSE TO RFC 467              18 April 1973


   some distance away.  A proposed interim solution which modifies the
   existing GVB and RET commands and which has the additional feature of
   simplifying them somewhat is outlined below.

   A receiving host may at an arbitrary time issue a Give-Back
   allocation (GVB) control message for a connection.

             8       8        8        8
         +-------+-------+--------+--------+
         |  GVB  | link  | f =255 | f =255 |
         |       |       |  m     |  b     |
         +-------+-------+--------+--------+

   The format of this GVB message is the same as that currently defined,
   except that the fraction fields f(m) and f(b) are required to all 1s.
   This is designed to provide a measure of upward compatibility.  A
   host operating under the modified protocol will ignore the fraction
   fields, but under the current protocol this message means return
   everything.  A sending host which receives a GVB control message
   immediately ceases transmission on the specified link.  When the RFNM
   from the last message transmitted is received (indicating an empty
   pipeline), the sending host issues a Return Allocation (RET) control
   message, returning the remaining allocation.