rfc636.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 447 行 · 第 1/2 页

                                   3

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490
TIP/TENEX Reliability Improvements



         17 !  RAS   !  link  !
            !        !        !
            -------------------
         Reset Allocation by Sender

              8 bits   8 bits
            -------------------
            !        !        !
         20 !  RAP   !  link  !
            !        !        !
            -------------------
         Reset Allocation Please

      The RAS command is sent from the Host sending on "link" to the
      Host receiving on "link".  This command may be sent whenever the
      sending Host desires to resynch the status information associated
      with the connection (and doesn't have a message in transit through
      the network).  Some circumstances in which the sending Host may
      choose to do this are:                                        

         1)  After a timeout when there is traffic to move but no
         allocation (assumes that an allocation has been lost);

         2)  When an inconsistent event occurs associated with that
         connection (e.g. an outstanding allocation in excess of 2^32
         bits or 2^16 messages);

         3)  After the sending host has suffered an interruption of
         network service;

         4)  In response to a RAP (see below).

      The RAR command is sent from the Host receiving on "link" to the
      Host sending on "link" in response to an RAS.  It marks the
      completion of the connection resynchronization.  When the RAR is
      returned the connection is in the known state of having no
      messages in transit in either direction and the allocations are
      zero.  The receiving Host may then start afresh with a new
      allocation and normal message transmission can proceed.  Since the
      RAR may be sent ONLY in response to an RAS, there are no races in
      the resynchronization.  All of the initiative lies with the
      sending Host.                                                 

      If the receiving Host detects an anomalous situation, however,
      there is no way to inform the sending Host that a
      resynchronization is desirable.  For this purpose, the RAP command
      is provided.  It constitutes a "suggestion" on the part of the





                                   4

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490
TIP/TENEX Reliability Improvements



      receiving Host that the sending Host resynchronize; the sending
      Host is free to honor it or not as it sees fit.  Since there is no
      obligatory response to a RAP, the receiving Host may send them as
      frequently as it chooses and no harm can occur.  For example, if a
      message in excess of the allocate arrives, the receiving Host
      might send RAPs every few seconds until the sending Host replies
      with no fears of races if one or more RAPs pass a RAS in the
      network.                                                      

   A.3  Resynchronization Procedure                                 

      The resynchronization sequence below may be initiated only by the
      sender either for internally generated reasons or upon the receipt
      of a RAP.                                                     

         a)  Sender - decision to resynch

            1)  Set state to "Wait-for-RAR" (Defer transmission of
            message.)
            2)  Wait until no RFNM outstanding
            3)  Send RAS
            4)  Zero allocation
            5)  Ignore allocates until RAR received
            6)  Set state to "Open" (Resume normal message transmission
            subject to flow control.)

         b)  Receiver - receipt of RAS

            1)  Send RAR
            2)  Zero allocation
            3)  Send a new allocation

      When the sender is in the "Wait-for-RAR" state it is not permitted
      to send new regular messages.  (Note that steps 4 and 5 will
      insure this in the normal course of events.)  With the return of
      the RAR the pipeline contains no messages and no allocates, the
      outstanding allocation variables at both ends are forced into
      agreement by setting them both to zero.  The receiver will then
      reconsider bit and message allocation, and send an ALL command for
      any allocation it cares to do.                                

   A.4  The Problem of Half-closed Connections                      

      The above procedures provide a way to resynchronize a connection
      after a brief lapse by a communications component, which results
      in lost messages or allocates for an open connection.         






                                   5

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490
TIP/TENEX Reliability Improvements



      A longer and more severe interruption of communication may result
      from a partitioning of the subnet or from a service interruption
      on one of the communicating hosts.  It is undesirable to tie up
      resources indefinitely under such circumstances, so the user is
      provided with the option of freeing up these resources (including
      himself) by unilaterally dissolving the connection.  Here
      "unilaterally" means sending the CLS command and closing the
      connection without receiving the CLS acknowledgement.  Note that
      this is legal only if the subnet indicates that the destination is
      dead.                                                         

      When service is restored ater such an interruption, the status
      information at the two ends of the connection is out of
      synchronization.  One end believes that the connection is open,
      and may proceed to use the connection.  The disconnecting end
      believes that the connection is closed (does not exist), and may
      proceed to re-initialize communication by opening a new connection
      (RTS or STR command) using the same socket pair or same link. 

      The resynchronization needed here is to properly close the open
      end of the connection when the inconsistency is detected.  We will
      accomplish this by specifying consistency checks and adding a new
      pair of commands.                                             

   A.5  The NXS and NXR Commands                                    

      The "missing CLS" situation described above can manifest itself in
      two ways.  The first way involves action taken by the NCP at the
      "open" end of the connection.  It may continue to send regular
      messages on the link of the half-closed connection, or control
      messages referencing its link.  The closed end should respond with
      an NXS if the message referred to a non-existent transmit link
      (e.g. was an ALL) or NXR if the message referred to a non-existent
      receive link (e.g. a data message).  On receipt of such an NXS or
      NXR message, the NCP at the "open" end should close the connection
      by modifying its tables (without sending any CLS command) thereby
      bringing both ends into agreement.                            

              8 bits   8 bits
            -------------------
            !        !        !
         21 !  NXR   !  link  !
            !        !        !
            -------------------
         Non-existent Receive Link

              8 bits   8 bits





                                   6

NWG/RFC# 636                 JDB BPC RST DCW3 MLK 23-OCT-75 22:27  30490
TIP/TENEX Reliability Improvements



            -------------------
            !        !        !
         22 !  NXS   !  link  !
            !        !        !
            -------------------
         Non-existent Send Link

   A.6  Consistency Checks                                          

      A second way this inconsistency can show up involves actions
      initiated by the NCP at the "closed" end.  It may (thinking the
      connection is closed) send an STR or RTS to reopen the connection.
      The NCP at the "open" end should detect the inconsistency when it
      receives such an RTS or STR command, because it specifies the same
      socket pair as an existing open connection, or, in the case of an
      RTS, the same link.  In this case, the NCP at the "open" end
      should close the connection (without sending any CLS command) to
      bring the two ends into agreement before responding to the
      RTS/STR.                                                      

   A.7  Conclusion                                                  

      The scheme presented in Section A.2 to resynchronize allocation
      has one very important property:  the data stream is preserved
      through the exchange.  Since no data is lost, it is safe to
      initiate resynchronization from either end at any time.  When in
      doubt, resynchronize.                                         

      The consistency checks for RTS and STR, and the NXR and NXS
      commands provide the synchronization needed to complete the
      closing of "half-closed" connections.                         

      The protocol changes above