rfc916.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.




RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      places B in the SYN-RECEIVED state.  B now sends a SYN packet to A
      which acknowledges the SYN it just received from A. Note that the
      AN field indicates B is now expecting to hear SN=1, thus
      acknowledging the SYN packet from A which used SN=0.  B also
      specifies in the LENGTH field the largest number of data octets it
      is prepared to consume.

      Side A receives the SYN packet from B which acknowledges A's
      original SYN packet in line 4.  This places A in the ESTABLISHED
      state.  Side A can now be confident that B expects to receive more
      packets from A.

      A is now free to send B the first DATA packet.  In line 5 upon
      receipt of this packet side B is placed into the ESTABLISHED
      state.  DATA cannot be sent until the sender is in the ESTABLISHED
      state.  This is because the LENGTH field is used to specify the
      MDL when opening the connection.

   3.2. Recovering from a Simultaneous Active OPEN

      It is of course possible that both ends of a connection may choose
      to  perform an active OPEN simultaneously.  In this case neither
      end of the connection is in the LISTEN state, both send SYN
      packets.  A reliable bidirectional protocol must recover from this
      situation.  It should recover in such a manner that the connection
      is successfully initiated.























Finn                                                           [Page 14]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      Side A                                             Side B

      1. CLOSED                                          CLOSED

      2. [OPEN request]
         SYN-SENT -->  <SN=0><CTL=SYN><MDL=n>       ...

      3.     ...                                         [OPEN request]
                       <SN=0><CTL=SYN><MDL=m>       <--  SYN-SENT

      4.                                            -->  SYN-RECEIVED
             ...  <SN=0><AN=1><CTL=SYN,ACK><MDL=m>  <--

      5. (packet finally arrives)
         SYN-RECEIVED  <--  <SN=0><CTL=SYN><MDL=m>

             -->  <SN=0><AN=1><CTL=SYN,ACK><MDL=n>  -->  ESTABLISHED
              ...       <SN=1><AN=1><CTL=ACK>       <--

      6. (packet finally arrives)
         ESTABLISHED <-- <SN=0><AN=1><CTL=SYN,ACK><MDL=m>
                     -->   <SN=1><AN=1><CTL=ACK>    ...

      During simultaneous connection both  sides  of  the  connection
      cycle  from  the CLOSED state through SYN-SENT to SYN-RECEIVED,
      and finally to ESTABLISHED.

   3.3. Detecting a Half-Open Connection

      Any computer may crash after a connection has been established.
      After recovering from the crash it may attempt to open a new
      connection.  The other end must be able to detect this condition
      and treat it as an error.
















Finn                                                           [Page 15]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      Side A                                             Side

      1. ESTABLISHED                                     ESTABLISHED

                -->   <SN=0><AN=1><CTL=ACK><DATA>  ...
                                                   -->
      (crashes)

      2.        XXX   <SN=1><AN=1><CTL=ACK><DATA>  <--

      3. (attempts to open new connection )
                -->    <SN=0><CTL=SYN><MDL=m>      -->
                ...  <SN=0><AN=1><CTL=RST,ACK>     <--   (abort)
                                                         CLOSED

      4.        <--
      (connection refused)
         CLOSED

   3.4. Closing a Connection

      Either side may choose to close an established connection.  This
      is accomplished by sending a packet with the FIN  control bit set.
      No  data may appear in a FIN packet.  The other end of the
      connection responds by shutting down its end of the connection and
      sending a FIN, ACK in response.

      Side A                                             Side B

      1. ESTABLISHED                                     ESTABLISHED

      2. [CLOSE request from user]
         FIN-WAIT  -->     <SN=0><AN=1><CTL=FIN>    ...

      3.                                            -->  LAST-ACK
                   ...   <SN=1><AN=1><CTL=FIN,ACK>  <--

      4. TIME-WAIT <--
                   -->     <SN=1><AN=0><CTL=ACK>    ...

      5.                                            -->  CLOSED

      6. (after 2*SRTT time passes)
         CLOSED

      In line 2 the user on side A of the fully opened connection has
      decided to close it down by issuing a CLOSE call.  No more data


Finn                                                           [Page 16]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      will be accepted for sending.  If data remains unsent a message
      "Warning: Unsent data remains." is communicated to the user.  No
      more data will be received.  A packet containing a FIN but no data
      is constructed and sent.  Side A goes into the FIN-WAIT state.

      Side B sees the FIN sent and immediately builds a FIN, ACK packet
      in response.  It then goes into the LAST-ACK state.  The FIN, ACK
      packet is received by side A and an answering ACK is immediately
      sent.  Side A then goes to the TIME-WAIT state.  In line 5 side B
      receives the final acknowledgment of its FIN, ACK packet and goes
      to the CLOSED state.  In line 6 after waiting to be sure its last
      acknowledgment was received side A goes to the CLOSED state (SRTT
      is the Smoothed Round Trip Time and is defined in section 6.3.1).




































Finn                                                           [Page 17]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


4. Packet Reception

   The act of receiving a packet is relatively straightforward.  There
   are a few points which deserve some discussion.  This chapter will
   discuss packet reception stage by stage in time order.

   Synch Detection

      The first stage in the reception of a packet is the discovery of a
      SYNCH pattern.  Octets are read continuously and discarded until
      the SYNCH pattern is seen.  Once SYNCH has been observed proceed
      to the Header Reception stage.

   Header Reception

      The remainder of the header is three octets in length.  No further
      processing can continue until the complete header has been read.
      Once read the header checksum test is performed.  If this test
      fails it is assumed that the current SYNCH pattern was the result
      of a data error.  Since the correct SYNCH may appear immediately
      after the current one, go back to the Synch Detection stage but
      treat the three octets of the header following the bad SYNCH as
      new input.

      If the header checksum test succeeds then proceed to the Data
      Reception stage.

   Data Reception

      A determination of the remaining length of the packet is made.  If
      either of the SYN, RST, SO, or FIN flags are set then legally the
      entire packet has already been read and it is considered to have
      'arrived'.  No data portion of a packet is present when one of
      those flags is set.  Otherwise the LENGTH field specifies the
      remaining amount of data to read.  In this case if the LENGTH
      field is zero then the packet contains no data portion and it is
      considered to have arrived.

      We now assume that a data portion is present and LENGTH was
      non-zero.  Counting the data checksum LENGTH+2 octets must now be
      read.  Once read the data checksum test is performed.  If this
      test fails the entire packet is discarded, return to the Synch
      Detection stage.  If the test succeeds then the packet is
      considered to have arrived.





Finn                                                           [Page 18]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


   Once arrived the packet is released to the upper level protocol
   software.  In a multiprocess implementation packet reception would
   now begin again at the Synch Detection stage.














































Finn                                                           [Page 19]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


5. Functional Specification

   A convenient model for the discussion and implementation of protocols
   is that of a state machine.  A connection can be thought of as
   passing through a variety of states, with possible error conditions,
   from its inception until it is closed.  In such a model each state
   represents a known point in the history of a connection.  The
   connection passes from state to state in response to events.  These
   events are caused by user calls to the protocol interface (a request
   to open or close a connection, data to send, etc.), incoming packets,
   and timeouts.

   Information about a connection must be maintained at both ends of
   that connection.  Following the terminology of [TCP 81] the
   information necessary to the successful operation of a connection is
   called the Transmission Control Block or TCB.  The user requests to
   the protocol interface are OPEN, SEND, RECEIVE, ABORT, STATUS, and
   CLOSE.

   This chapter is broken up into three parts.  First a brief
   description of each protocol state will be presented.  Following this