rfc916.txt

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

            known to be one octet the LENGTH field is superfluous and
            itself contains the data octet.  The data portion of the
            packet is not transmitted.

            The SO flag removes the need to transmit the data portion of
            the packet in this special case.  Without the SO flag seven
            octets would be required of the packet, with it only four
            are needed and so transmission efficiency is improved by 40
            percent.  The header checksum protects the single octet of
            data.

      2.1.3. Length

         The second octet following the SYNCH pattern holds length
         information.  If the SYN bit is present this contains the
         maximum number of data octets the receiver is allowed to
         transmit in any single packet to the sender.  This quantity is
         called the MDL.  A sender may indicate his unwillingness to
         accept any data octets by specifying an MDL of zero.  In this
         case presumably all the data would be moving from the sender to
         the receiver.  Obviously if data is to be transmitted both
         sides of a connection cannot have an MDL of zero.

         If neither the SYN, RST, nor FIN flags are set this is an 8-bit
         field called LENGTH.  In this case if the SO flag bit is set


Finn                                                            [Page 7]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


         then LENGTH contains a single octet of data.  Otherwise it
         contains the count of data octets in this packet.  From zero
         (0) to MDL octets of data may appear in a single packet.  MDL
         is limited to a maximum of 255.

      2.1.4. Header Checksum

         The header checksum algorithm is the 8-bit equivalent of the
         16-bit data checksum detailed below.  It is built and processed
         in an similar manner but is eight bits wide instead of sixteen.
         When sending the header checksum octet is initially cleared.
         An 8-bit sum of the control, length, and header checksum octets
         is formed employing end-around carry.  That sum is then
         complemented and stored in the header checksum octet.  Upon
         receipt the 8-bit end-around carry sum is formed of the same
         three octets.  If the sum is octal 377 the header is presumed
         to be valid.  In all other cases the header is assumed to be
         invalid.

         The reasons for providing this separate protection to the
         header are discussed in the chapter dealing with error
         handling.  The header checksum covers the control and data
         length octets.  It does not include the SYNCH pattern.

   2.2. Data Format

      The data portion of a packet immediately follows the header if the
      SO flag is not set and LENGTH > 0.  It consists of LENGTH data
      octets  immediately followed by two data checksum octets.  If
      present the data portion contains LENGTH+2 octets.



















Finn                                                            [Page 8]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


      Data Byte No.

                  +-------------------------------+
         1        |                               | High order \
                  +--                           --+             > Word
         2        |                               | Low order  /
                  +--                           --+
         .        |            Data               | High order \
                  +--                           --+             > Word
         .        |                               | Low order  /
                  +--                           --+
         LENGTH   |                               | High order \
                  +-------------------------------+             > Word
                  |   Imaginary padding octet 0   | Low order  /
                  +-------------------------------+
         LENGTH+1 |                               | High order \
                  +--       Data Checksum       --+             > Word
         LENGTH+2 |                               | Low order  /
                  +-------------------------------+

                        Data Portion of a Packet

      2.2.1. Data Checksum

         The last two octets of the data portion of a packet are a data
         checksum.  A 16-bit checksum is used by this protocol to detect
         incorrectly transmitted data.  This has shown itself to be a
         reliable method for detecting most categories of bit drop out
         and bit insertion.  While it does not guarantee the detection
         of all such errors the probability of such an error going
         undetected is on the order of 2**(-16).

         The checksum octets follow the data to enable the sender of a
         packet to compute the checksum while transmitting a packet and
         the receiver to compute the checksum while receiving the
         packet.  Thus neither must store the packet and then process
         the data for checksumming in a separate pass.

         Order of Transmission

            The order in which the 8-bit octets are assembled into
            16-bit words, which is the low order octet and which is the
            high, must be rigidly specified for the purpose of computing
            16-bit checksums.  We specify the big endian ordering in the
            diagram above [Cohen 81].




Finn                                                            [Page 9]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


         Checksum Algorithm

            The checksum algorithm chosen is similar to that used by
            IP/TCP protocols [IP 81] [TCP 81].  This algorithm has shown
            itself to be both reliable and relatively easy to compute.
            The interested reader may refer to [TCP Checksum 78] for a
            more thorough discussion of its properties.

         The checksum algorithm is:

            SENDER

               The unsigned sum of the 16-bit words of the data portion
               of the packet is formed.  Any overflow is added into the
               lowest order bit.  This sum does not include the header
               portion of the packet.  For the purpose of building a
               packet for transmission the two octet checksum field is
               zero.  The sum formed is then bit complemented and
               inserted into the checksum field before transmission.

               If the total number of data octets is odd then the last
               octet is padded to the right (low order) with zeros to
               form a 16-bit word for checksum purposes.  This pad octet
               is not transmitted as part of the packet.

            RECEIVER

               The sum is computed as above but including the values
               received in the checksum field.  If the 16-bit sum is
               octal 177777 then the data is presumed to be valid.  In
               all other cases the data is presumed to be invalid.

         This unsigned 16-bit sum adds 16-bit quantities with any
         overflow bit added into the lowest order bit of the sum.  This
         is called 'end around carry'.  End around carry addition
         provides several properties: 1) It provides full commutivity of
         addition (summing in any order is equivalent), and 2) If you
         apply a given rotation to each quantity before addition and
         when the final total is formed apply the inverse rotation, then
         the result will be equivalent to any other rotation chosen.
         The latter property gives little endian machines like a PDP-11
         the go ahead to pick up 16-bit quantities and add them in byte
         swapped order.






Finn                                                           [Page 10]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


            The PDP-11 code to calculate the checksum is:

                     CLR R0         ; R0 will get the checksum
                                    ; R2 contains LENGTH count
               LOOP: ADD (R1)+,R0   ; Add the next 16-bit byte
                     ADC R0         ; Make any carry be end around
                     SOB R2,LOOP    ; Loop over entire packet
                     COM R0         ; Bit complement result

   2.3. Sequence Numbers

      Sequence numbers work with acknowledge numbers to inform the
      sender that his last data packet was received, and to inform the
      receiver of the sequence number of the next data packet it expects
      to see.  When the ACK flag is set in a packet the AN field
      contains the sequence number of the next data packet it expects
      from the sender.  The sender looks at the AN field and by
      implication knows that the packet he just sent should have had a
      sequence number of:

         <AN received-1 modulo 2>

      If it did have that number that packet is considered to have been
      acknowledged.

      Similarly, the receiver expects the next data packet it sees to
      have an SN field value equal to the AN field of the last
      acknowledge message it sent.  If this is not the case then the
      receiver assumes that it is receiving a duplicate of a data packet
      it earlier acknowledged.  This implies that the packet containing
      the acknowledgment did not arrive and therefor the packet that
      contained the acknowledgment should be retransmitted.  The
      duplicate data packet is discarded.

      The only packets which require acknowledgment are packets
      containing status flags (SYN, RST, FIN, or SO) or data.  A packet
      which contains only an acknowledgment, i.e. <AN=n><CTL=ACK>, does
      not require a response (it contains no status flags or data).

      Both the AN and SN fields are a single bit wide.  Since at most
      one packet is in the process of being sent/acknowledged in a
      particular direction at any one time a single bit is sufficient to
      provide a method of duplicate packet detection and removal of a
      packet from the retransmission queue.  The arithmetic to advance
      these numbers is modulo 2.  Thus when a data packet has been
      acknowledged the sender's next sequence number will be the current
      one, plus one modulo 2:


Finn                                                           [Page 11]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


         <SN = SN + 1 modulo 2>

      The individual acknowledgment of each packet containing data can
      mislead one into thinking that side A of a connection cannot send
      data to side B until it receives a packet from B. That only then
      can it acknowledge B's packet and place in the acknowledging
      packet some data of its own.  This is not the case.

      As long as its last packet sent requiring a response has been
      acknowledged each side of a connection is free to send a data
      packet whenever it wishes.  Naturally, if one side is sending a
      data packet and it also must acknowledge receipt of a data packet
      from the other side, it is most efficient to combine both
      functions in a single packet.

   2.4. Maximum Packet Size

      The maximum packet size is:

         SYNCH + HEADER + Data Checksum + 255 = 261 octets

      There is therefor no need to allocate more than that amount of
      storage for any received packets.


























Finn                                                           [Page 12]



RFC 916                                                     October 1984
Reliable Asynchronous Transfer Protocol


3. The Opening and Closing of a Connection

   3.1. Opening a Connection

      A "three-way handshake" is the procedure used to establish a
      connection.  It is normally initiated by one end of the connection
      and responded to by the other.  It will still work if both sides
      simultaneously initiate the procedure.  Experience has shown that
      this strategy of opening a connection reduces the probability of
      false connections to an acceptably low level.

      The simplest form of the three-way handshake is illustrated in the
      diagram below.  The time order is line by line from top to bottom
      with certain lines numbered for reference.  User events are placed
      in brackets as in [OPEN].  An arrow (-->) represents the direction
      of flow of a packet and an ellipsis (...) indicates a packet in
      transit.  Side A and side B are the two ends of the connection.
      An "XXX" indicates a packet which is lost or rejected.  The
      contents of the packet are shown on the center of each line.  The
      state of both connections is that caused by the departure or
      arrival of the packet represented on the line.  The contents of
      the data portion of a packet are left out for clarity.

      Side A                                             Side B

      1. CLOSED                                          LISTEN

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

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

      4. ESTABLISHED <--
              -->    <SN=1><AN=1><CTL=ACK><DATA>   ...

      5.                                           -->   ESTABLISHED

      In line 2 above the user at side A has requested that a connection
      be opened.  Side A then attempts to open a connection by sending a
      SYN packet to side B which is in the LISTEN state.  It specifies
      its initial sequence number, here zero.  It places in the LENGTH
      field of the header the largest number of data octets it can
      consume in any one packet (MDL).  The MDL is normally positive.
      The action of sending this packet places A in the SYN-SENT state.

      In line 3 side B has just received the SYN packet from A. This


Finn                                                           [Page 13]