rfc998.txt

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

   received, it goes into a SENT state and is disposed of.

   The state sequence for a receiving buffer is a little more
   complicated.  Assume existence of a buffer A. When a control message
   for A is sent, the buffer moves into state ACK-WAIT (it is waiting
   for acknowledgement of the control message).

   As soon as the control message has been acknowledged, buffer A moves
   from the ACK-WAIT state into the ACKED state (it is now waiting for
   DATA packets to arrive).  At this point, A's data timer is set and
   the control message removed from the control packet.  Estimation of
   the data timer value at this point is quite difficult.  In a
   multiple-buffer transfer model, the receiving NETBLT can send several
   GO messages at once.  A single DATA packet from the sending NETBLT
   could acknowledge all the GO messages, causing several buffers to
   start up data timers.  Clearly each of the data timers must be set in
   a manner that takes into account each buffer's place in the order of
   transmission.  Packets for a buffer A - 1 will always be transmitted
   before packets in A, so A's data timer must take into account the
   arrival of all of A - 1's DATA packets as well as arrival of its own
   DATA packets.  This means that the timer values become increasingly
   less accurate for higher-numbered buffers.  Because this data timer



Clark, Lambert, & Zhang                                        [Page 11]

RFC 998                                                       March 1987


   value can be quite inaccurate, it is called a "loose" data timer.
   The loose data timer value is recalculated later (using the same
   algorithm, but with updated information), giving a "tight" timer, as
   described below.

   When the first DATA packet for A arrives, A moves from the ACKED
   state to the RECEIVING state and its data timer is set to a new
   "tight" value.  The tight timer value is calculated in the same
   manner as the loose timer, but it is more accurate since we have
   moved forward in time and those buffers numbered lower than A have
   presumably been dealt with (or their packets would have arrived
   before A's), leaving fewer packets to arrive between the setting of
   the data timer and the arrival of the last DATA packet in A.

   The receiving NETBLT also sets the tight data timers of any buffers
   numbered lower than A that are also in the ACKED state.  This is done
   as an optimization: we know that buffers are processed in order,
   lowest number first.  If a buffer B numbered lower than A is in the
   ACKED state, its DATA packets should arrive before A's.  Since A's
   have arrived first, B's must have gotten lost.  Since B's loose data
   timer has not expired (it would then have sent a RESEND message and
   be in the ACK-WAIT state), we set the tight timer, allowing the
   missing packets to be detected earlier.  An immediate RESEND is not
   sent because it is possible that A's packet was re-ordered before B's
   by the network, and that B's packets may arrive shortly.

   When all DATA packets for A have been received, it moves from the
   RECEIVING state to the RECEIVED state and is disposed of.  Had any
   packets been missing, A's data timer would have expired and A would
   have moved into the ACK-WAIT state after sending a RESEND message.
   The state progression would then move as in the above example.

   The control and data timer system can be summarized as follows:
   normally, the receiving NETBLT is working under one of two types of
   timers, a control timer or a data timer.  There is one data timer per
   buffer transmission and one control timer per control packet.  The
   data timer is active while its buffer is in either the ACKED (loose
   data timer value is used) or the RECEIVING (tight data timer value is
   used) states; a control timer is active whenever the receiving NETBLT
   has any unacknowledged control messages in its control packet.

5.2.3. Death Timers and Keepalive Packets

   The above system still leaves a few problems.  If the sending NETBLT
   is not ready to send, it sends a single NULL-ACK packet to clear any
   outstanding control timers at the receiving end.  After this the
   receiver will wait.  The sending NETBLT could die and the receiver,
   with its control timer cleared, would hang.  Also, the above system
   puts timers only on the receiving NETBLT.  The sending NETBLT has no
   timers; if the receiving NETBLT dies, the sending NETBLT will hang
   while waiting for control messages to arrive.



Clark, Lambert, & Zhang                                        [Page 12]

RFC 998                                                       March 1987


   The solution to the above two problems is the use of a death timer
   and a keepalive packet for both the sending and receiving NETBLTs.
   As soon as the connection is opened, each end sets a death timer;
   this timer is reset every time a packet is received.  When a NETBLT's
   death timer expires, it can assume the other end has died and can
   close the connection.

   It is possible that the sending or receiving NETBLTs will have to
   wait for long periods while their respective clients get buffer space
   and load their buffers with data.  Since a NETBLT waiting for buffer
   space is in a perfectly valid state, the protocol must have some
   method for preventing the other end's death timer from expiring.  The
   solution is to use a KEEPALIVE packet, which is sent repeatedly at
   fixed intervals when a NETBLT cannot send other packets.  Since the
   death timer is reset whenever a packet is received, it will never
   expire as long as the other end sends packets.

   The frequency with which KEEPALIVE packets are transmitted is
   computed as follows:  At connection startup, each NETBLT chooses a
   death-timer value and sends it to the other end in either the OPEN or
   the RESPONSE packet.  The other end takes the death-timeout value and
   uses it to compute a frequency with which to send KEEPALIVE packets.
   The KEEPALIVE frequency should be high enough that several KEEPALIVE
   packets can be lost before the other end's death timer expires (e.g.
   death timer value divided by four).

   The death timer value is relatively easy to estimate.  Since it is
   continually reset, it need not be based on the transfer size.
   Instead, it should be based at least in part on the type of
   application using NETBLT.  User applications should have smaller
   death timeout values to avoid forcing humans to wait long periods of
   time for a death timeout to occur.  Machine applications can have
   longer timeout values.

5.3. Closing the Connection

   There are three ways to close a connection: a connection close, a
   "quit", or an "abort".

5.3.1. Successful Transfer

   After a successful data transfer, NETBLT closes the connection.  When
   the sender is transmitting the last buffer of data, it sets a "last-
   buffer" flag on every DATA packet in the buffer.  This means that no
   NEW data will be transmitted.  The receiver knows the transfer has
   completed successfully when all of the following are true: (1) it has
   received DATA packets with a "last-buffer" flag set, (2) all its
   control messages have been acknowledged, and (3) it has no
   outstanding buffers with missing packets.  At that point, the
   receiver is permitted to close its half of the connection.  The
   sender knows the transfer has completed when the following are true:



Clark, Lambert, & Zhang                                        [Page 13]

RFC 998                                                       March 1987


   (1) it has transmitted DATA packets with a "last-buffer" flag set and
   (2) it has received OK messages for all its buffers.  At that point,
   it "dallies" for a predetermined period of time before closing its
   half of the connection.  If the NULL-ACK packet acknowledging the
   receiver's last OK message was lost, the receiver has time to
   retransmit the OK message, receive a new NULL-ACK, and recognize a
   successful transfer.  The dally timer value MUST be based on the
   receiver's control timer value; it must be long enough to allow the
   receiver's control timer to expire so that the OK message can be re-
   sent.  For this reason, all OK messages contain (in addition to new
   burst size and burst rate values), the receiver's current control
   timer value in milliseconds.  The sender uses this value to compute
   its dally timer value.

   Since the dally timer value may be quite large, the receiving NETBLT
   is permitted to "short-circuit" the sending NETBLT's dally timer by
   transmitting a DONE packet.  The DONE packet is transmitted when the
   receiver knows the transfer has been successfully completed.  When
   the sender receives a DONE packet, it is allowed to clear its dally
   timer and close its half of the connection immediately.  The DONE
   packet is not reliably transmitted, since failure to receive it only
   means that the sending NETBLT will take longer time to close its half
   of the connection (as it waits for its dally timer to clear)

5.3.2. Client QUIT

   During a NETBLT transfer, one client may send a QUIT packet to the
   other if it thinks that the other client is malfunctioning.  Since
   the QUIT occurs at a client level, the QUIT transmission can only
   occur between buffer transmissions.  The NETBLT receiving the QUIT
   packet can take no action other than immediately notifying its client
   and transmitting a QUITACK packet.  The QUIT sender must time out and
   retransmit until a QUITACK has been received or its death timer
   expires.  The sender of the QUITACK dallies before quitting, so that
   it can respond to a retransmitted QUIT.

5.3.3. NETBLT ABORT

   An ABORT takes place when a NETBLT layer thinks that it or its
   opposite is malfunctioning.  Since the ABORT originates in the NETBLT
   layer, it can be sent at any time.  The ABORT implies that the NETBLT
   layer is malfunctioning, so no transmit reliability is expected, and
   the sender can immediately close it connection.

6. Protocol Layering Structure

   NETBLT is implemented directly on top of the Internet Protocol (IP).
   It has been assigned an official protocol number of 30 (decimal).






Clark, Lambert, & Zhang                                        [Page 14]

RFC 998                                                       March 1987


7. Planned Enhancements

   As currently specified, NETBLT has no algorithm for determining its
   rate-control parameters (burst rate, burst size, etc.).  In initial
   performance testing, these parameters have been set by the person
   performing the test.  We are now exploring ways to have NETBLT set
   and adjust its rate-control parameters automatically.

8. Packet Formats

   NETBLT packets are divided into three categories, all of which share
   a common packet header.  First, there are those packets that travel
   only from data sender to receiver; these contain the high-
   acknowledged-sequence-numbers which the receiver uses for control
   message transmission reliability.  These packets are the NULL-ACK,
   DATA, and LDATA packets.  Second, there is a packet that travels only
   from receiver to sender.  This is the CONTROL packet; each CONTROL
   packet can contain an arbitrary number of control messages (GO, OK,
   or RESEND), each with its own sequence number.  Finally, there are
   those packets which either have special ways of insuring reliability,
   or are not reliably transmitted.  These are the OPEN, RESPONSE,
   REFUSED, QUIT, QUITACK, DONE, KEEPALIVE, and ABORT packets.  Of
   these, all save the DONE packet can be sent by both sending and
   receiving NETBLTs.

   All packets are "longword-aligned", i.e. all packets are a multiple
   of 4 bytes in length and all 4-byte fields start on a longword
   boundary.  All arbitrary-length string fields are terminated with at
   least one null byte, with extra null bytes added at the end to create
   a field that is a multiple of 4 bytes long.
























Clark, Lambert, & Zhang                                        [Page 15]

RFC 998                                                       March 1987


   Packet Formats for NETBLT

   OPEN (type 0) and RESPONSE (type 1):

                      1                   2                   3
    1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +---------------+---------------+---------------+---------------+
   |           Checksum            |    Version    |     Type      |
   +---------------+---------------+---------------+---------------+
   |           Length              |           Local Port          |
   +---------------+---------------+---------------+---------------+
   |        Foreign Port           | Longword Alignment Padding    |
   +---------------+---------------+---------------+---------------+
   |                       Connection Unique ID                    |
   +---------------+---------------+---------------+---------------+
   |                         Buffer Size                           |
   +---------------+---------------+---------------+---------------+
   |                       Transfer Size                           |
   +---------------+---------------+---------------+---------------+
   |        DATA packet size       |          Burst Size           |
   +---------------+---------------+---------------+---------------+
   |           Burst Rate          |       Death Timer Value       |
   +---------------+---------------+---------------+---------------+
   |       Reserved (MBZ)      |C|M| Maximum # Outstanding Buffers |
   +---------------+---------------+---------------+---------------+
   | Client String ...
   +---------------+---------------+---------------
                                     Longword Alignment Padding    |
                    ---------------+-------------------------------+

   Checksum: packet checksum (algorithm is described in the section
   "Connection Setup")

   Version: the NETBLT protocol version number

   Type: the NETBLT packet type number (OPEN = 0, RESPONSE = 1,
   etc.)

   Length: the total length (NETBLT header plus data, if present)
   of the NETBLT packet in bytes

   Local Port: the local NETBLT's 16-bit port number

   Foreign Port: the foreign NETBLT's 16-bit port number