rfc492.txt

RFC 的详细文档！

              8      8        16         32
          +------+------+-----------+-----------+
          | RET  | link | msg space | bit space |
          +------+------+-----------+-----------+

   The modified RET command has the same format as that currently
   defined.  The two differences are that it can not be sent until data
   transmission ceases and the last RFNM is received, and that it must
   return all remaining allocation for the send link (i.e., the
   allocation counters are set to zero).

   When the host on the read side of the connection receives the RET
   message, the allocation counters at the send side are zero and the
   pipeline is empty.  Therefore, if no error has occurred during the
   connection, the allocation returned in the RET message should be the
   same as the allocation in the counters of the read side of the
   connection.  If so, the read side can proceed to send a new
   allocation secure in the knowledge that no message has been lost.  If
   the two sets of values do not agree, some error in the transmitted
   data may have occurred.  What to do in that case is a local host
   option.  Some hosts may choose to close the connection, while others
   may choose to resume transmission by sending a new allocation to the





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


   sending side.  I feel that as a minimum a host should send a message
   indicating the error both to the user and to some human being at the
   host responsible for monitoring network performance.

   This modified control message pair is capable of both its originally
   intended function,and of detecting errors and resynchronizing
   allocations (if desired) when initiated by the receiving side.  I
   feel that the inability of this scheme to initiate allocation
   checking from either side is only a minor disadvantage which is more
   than compensated for by its positive features: this scheme gives
   positive indication that an error has occurred (the proposed RCS/RCR
   method conceals errors), and this minor change to the protocol may
   mean a correspondingly minor change to NCP's.

   I have negative feelings regarding the solution to the "half-closed"
   problem proposed in RFC 467.  To put additional burden on the RTS and
   STR commands not only unduly complicates the protocol, but in some
   sense can make operation less fail-safe and problems more obscure.
   My main objection concerns the action to be taken when control
   messages are received which conflict with the current state of the
   receiving NCP.  This proposal suggests that an NCP receiving an STR
   or RTS for a socket it believes to be connected assume something
   about the state of the foreign NCP (that the foreign NCP has closed
   the connection) and automatically change its own state to agree with
   the assumed state at the other end (close the connection at its end).
   This may work fine if the assumption is correct and the
   implementations are free from bugs.  However, the following
   situations could cause problems that are perhaps hard to diagnose: 1)
   the foreign NCP has a bug which causes it to send an RTS or STR for a
   connected socket, 2) the foreign NCP chooses to interpret the queuing
   option of the current protocol as permitting RFC's to be sent for
   already connected sockets, or 3) the local NCP has a bug which
   erroneously causes it to regard RFC's coming from a different host or
   from the particular foreign host but concerning a different foreign
   socket as pertaining to the open connection attached to the target
   socket.

   A second objection is that this proposal does not cover all
   possibilities.  Two likely possibilities are: another socket (from
   any host) attempts to connect to the socket involved in the dead
   connection.  Second, the host that lost a connection attached to one
   of its read sockets makes another connection with different sockets,
   but uses the same link number that implemented the previous
   connection.  The second case can be handled by additional
   complications to the protocol.  However, the first case is
   symptomatically identical to the situation in which an RFC is issued
   for a genuinely already-connected socket.  It can not be handled
   using this approach.



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


   I believe that a more rigorous use of the existing Reset Host (RST)
   control message would eliminate most of the causes of the "half-
   closed" phenomenon; viz. one of the hosts involved in a connection
   goes down without sending an RST when it comes back up; or the
   network between the two hosts partitions, and only one host notes it.
   If it were deemed necessary, a pair of Reset Link control commands to
   reset an individual link could be added to the protocol to cope with
   instance of the "half-closed" phenomenon due to other causes.

   I'd like to set down here a number of principles which I think are at
   least peripherally concerned with alleviating the "half-closed"
   phenomenon.  None of these is explicitly stated in the current Host-
   Host protocol document, but I believe that their enunciation would
   tend to alleviate confusion caused by network and host failures.

      1. A NCP which receives an Imp-to-Host message type 7 (Host Dead)
         concerning a host should consider all connections or connection
         attempts with that host as dead and should purge them from its
         tables.

      2. When after noting a foreign host as dead (by receiving a "Host
         Dead" Imp-to-Host message), an NCP receives any message from
         that host other than a Reset Host (RST) control message, it
         should delete the message and respond with an RST.  It should
         respond normally to a received RST.

      3. Two hosts must exchange the RST - RRP reset control message
         pair prior to any other form of communications.  An RST must
         first be sent by an NCP wishing to start communications with a
         foreign host if that host pair has not been previously reset
         since the local NCP came up or it noted the foreign NCP as
         down.  Note that this does not require an NCP to send resets to
         all other hosts each time it comes up.

      4. An NCP which receives an Imp-to-Host message type 9 (Incomplete
         Transmission) concerning a write link implementing an open
         connection, may at its option make several tries to retransmit
         the last message until a RFNM is received or the NCP gives up.
         However, unless the message is eventually successfully
         transmitted to the foreign host the NCP must abort the
         connection, sending out a CLS control message.  The successful
         implementation of retransmission depends on the retransmitting
         host to wait for a RFNM on a data link before sending a
         subsequent message and on all hosts to be able to discard
         messages which are not completely received.






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


      5. An NCP which receives a message from a foreign host that seems
         inconsistent with its current state should take no action to
         modify that state.  Rather it should send an ERR error control
         message specifying the type of inconsistency and discard the
         inconsistent message.  An NCP receiving an ERR message should
         log it for human inspection and is then allowed to silently
         modify its internal state or send out control messages in order
         to remove the inconsistency. (This is an extension of the
         proposal in RFC 467 that an NCP should delete a connection when
         it receives an ERR message specifying that the link involved is
         unknown.)


        [This RFC was put into machine readable form for entry]
   [into the online RFC archives by Helene Morin, Via Genie,12/1999]




































Meyer                                                           [Page 7]