rfc998.txt

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

   performance on subsequent transfers.

5. The NETBLT Transfer Model

   Each NETBLT transfer has three stages, connection setup, data
   transfer, and connection close.  The stages are described in detail
   below, along with methods for insuring that each stage completes
   reliably.

5.1. Connection Setup

   A NETBLT connection is set up by an exchange of two packets between
   the active NETBLT and the passive NETBLT.  Note that either NETBLT
   can send or receive data; the words "active" and "passive" are only
   used to differentiate the end making the connection request from the
   end responding to the connection request.  The active end sends an
   OPEN packet; the passive end acknowledges the OPEN packet in one of
   two ways.  It can either send a REFUSED packet, indicating that the
   connection cannot be completed for some reason, or it can complete
   the connection setup by sending a RESPONSE packet.  At this point the
   transfer can begin.

   As discussed in the previous section, the OPEN and RESPONSE packets
   are used to negotiate flow control parameters.  Other parameters used
   in the data transfer are also negotiated.  These parameters are (1)
   the maximum number of buffers that can be sending at any one time,
   and (2) whether or not DATA packet data will be checksummed.  NETBLT
   automatically checksums all non-DATA/LDATA packets.  If the
   negotiated checksum flag is set to TRUE (1), both the header and the
   data of a DATA/LDATA packet are checksummed; if set to FALSE (0),
   only the header is checksummed.  The checksum value is the bitwise
   negation of the ones-complement sum of the 16-bit words being
   checksummed.

   Finally, each end transmits its death-timeout value in seconds in
   either the OPEN or the RESPONSE packet.  The death-timeout value will
   be used to determine the frequency with which to send KEEPALIVE



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


   packets during idle periods of an opened connection (death timers and
   KEEPALIVE packets are described in the following section).

   The active end specifies a passive client through a client-specific
   "well-known" 16 bit port number on which the passive end listens.
   The active end identifies itself through a 32 bit Internet address
   and a unique 16 bit port number.

   In order to allow the active and passive ends to communicate
   miscellaneous useful information, an unstructured, variable-length
   field is provided in OPEN and RESPONSE packets for any client-
   specific information that may be required.  In addition, a "reason
   for refusal" field is provided in REFUSED packets.

   Recovery for lost OPEN and RESPONSE packets is provided by the use of
   timers.  The active end sets a timer when it sends an OPEN packet.
   When the timer expires, another OPEN packet is sent, until some
   predetermined maximum number of OPEN packets have been sent.  The
   timer is cleared upon receipt of a RESPONSE packet.

   To prevent duplication of OPEN and RESPONSE packets, the OPEN packet
   contains a 32 bit connection unique ID that must be returned in the
   RESPONSE packet.  This prevents the initiator from confusing the
   response to the current request with the response to an earlier
   connection request (there can only be one connection between any two
   ports).  Any OPEN or RESPONSE packet with a destination port matching
   that of an open connection has its unique ID checked.  If the unique
   ID of the packet matches the unique ID of the connection, then the
   packet type is checked.  If it is a RESPONSE packet, it is treated as
   a duplicate and ignored.  If it is an OPEN packet, the passive NETBLT
   sends another RESPONSE (assuming that a previous RESPONSE packet was
   sent and lost, causing the initiating NETBLT to retransmit its OPEN
   packet).  A non-matching unique ID must be treated as an attempt to
   open a second connection between the same port pair and is rejected
   by sending an ABORT message.

5.2. Data Transfer

   The simplest model of data transfer proceeds as follows.  The sending
   client sets up a buffer full of data.  The receiving NETBLT sends a
   GO message inside a CONTROL packet to the sender, signifying that it
   too has set up a buffer and is ready to receive data.  Once the GO
   message is received, the sender transmits the buffer as a series of
   DATA packets followed by an LDATA packet.  When the last packet in
   the buffer has been received, the receiver sends a RESEND message
   inside a CONTROL packet containing a list of packets that were not
   received.  The sender resends these packets.  This process continues
   until there are no missing packets.  At that time the receiver sends
   an OK message inside a CONTROL packet, sets up another buffer to
   receive data, and sends another GO message.  The sender, having
   received the OK message, sets up another buffer, waits for the GO



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


   message, and repeats the process.

   The above data transfer model is effectively a lock-step protocol,
   and causes time to be wasted while the sending NETBLT waits for
   permission to send a new buffer.  A more efficient transfer model
   uses multiple buffering to increase performance.  Multiple buffering
   is a technique in which the sender and receiver allocate and transmit
   buffers in a manner that allows error recovery or successful
   transmission confirmation of previous buffers to be concurrent with
   transmission of the current buffer.

   During the connection setup phase, one of the negotiated parameters
   is the number of concurrent buffers permitted during the transfer.
   If there is more than one buffer available, transfer of the next
   buffer may start right after the current buffer finishes.  This is
   illustrated in the following example:

   Assume two buffers A and B in a multiple-buffer transfer, with A
   preceding B. When A has been transferred and the sending NETBLT is
   waiting for either an OK or a RESEND message for it, the sending
   NETBLT can start sending B immediately, keeping data flowing at a
   stable rate.  If the receiver of data sends an OK for A, all is well;
   if it receives a RESEND, the missing packets specified in the RESEND
   message are retransmitted.

   In the multiple-buffer transfer model, all packets to be sent are
   re-ordered by buffer number (lowest number first), with the transfer
   rate specified by the burst size and burst rate.  Since buffer
   numbers increase monotonically, packets from an earlier buffer will
   always precede packets from a later buffer.

   Having several buffers transmitting concurrently is actually not that
   much more complicated than transmitting a single buffer at a time.
   The key is to visualize each buffer as a finite state machine;
   several buffers are merely a group of finite state machines, each in
   one of several states.  The transfer process consists of moving
   buffers through various states until the entire transmission has
   completed.

   There are several obvious flaws in the data transfer model as
   described above.  First, what if the GO, OK, or RESEND messages are
   lost?  The sender cannot act on a packet it has not received, so the
   protocol will hang.  Second, if an LDATA packet is lost, how does the
   receiver know when the buffer has been transmitted?  Solutions for
   each of these problems are presented below.

5.2.1. Recovering from Lost Control Messages

   NETBLT solves the problem of lost OK, GO, and RESEND messages in two
   ways.  First, it makes use of a control timer.  The receiver can send
   one or more control messages (OK, GO, or RESEND) within a single



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


   CONTROL packet.  Whenever the receiver sends a control packet, it
   sets a control timer.  This timer is either "reset" (set again) or
   "cleared" (deactivated), under the following conditions:

   When the control timer expires, the receiving NETBLT resends the
   control packet and resets the timer.  The receiving NETBLT continues
   to resend control packets in response to control timer's expiration
   until either the control timer is cleared or the receiving NETBLT's
   death timer (described later) expires (at which time it shuts down
   the connection).

   Each control message includes a sequence number which starts at one
   and increases by one for each control message sent.  The sending
   NETBLT checks the sequence number of every incoming control message
   against all other sequence numbers it has received.  It stores the
   highest sequence number below which all other received sequence
   numbers are consecutive (in following paragraphs this is called the
   high-acknowledged-sequence-number) and returns this number in every
   packet flowing back to the receiver.  The receiver is permitted to
   clear its control timer when it receives a packet from the sender
   with a high-acknowledged-sequence-number greater than or equal to the
   highest sequence number in the control packet just sent.

   Ideally, a NETBLT implementation should be able to cope with out-of-
   sequence control messages, perhaps collecting them for later
   processing, or even processing them immediately.  If an incoming
   control message "fills" a "hole" in a group of message sequence
   numbers, the implementation could even be clever enough to detect
   this and adjust its outgoing sequence value accordingly.

   The sending NETBLT, upon receiving a CONTROL packet, should act on
   the packet as quickly as possible.  It either sets up a new buffer
   (upon receipt of an OK message for a previous buffer), marks data for
   resending (upon receipt of a RESEND message), or prepares a buffer
   for sending (upon receipt of a GO message).  If the sending NETBLT is
   not in a position to send data, it should send a NULL-ACK packet,
   which contains its high-acknowledged-sequence-number (this permits
   the receiving NETBLT to acknowledge any outstanding control
   messages), and wait until it can send more data.  In all of these
   cases, the system overhead for a response to the incoming control
   message should be small and relatively constant.

   The small amount of message-processing overhead allows accurate
   control timers to be set for all types of control messages with a
   single, simple algorithm -- the network round-trip transit time, plus
   a variance factor.  This is more efficient than schemes used by other
   protocols, where timer value calculation has been a problem because
   the processing time for a particular packet can vary greatly
   depending on the packet type.

   Control timer value estimation is extremely important in a high-



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


   performance protocol like NETBLT.  A long control timer causes the
   receiving NETBLT to wait for long periods of time before
   retransmitting unacknowledged messages.  A short control timer value
   causes the sending NETBLT to receive many duplicate control messages
   (which it can reject, but which takes time).

   In addition to the use of control timers, NETBLT reduces lost control
   messages by using a single long-lived control packet; the packet is
   treated like a FIFO queue, with new control messages added on at the
   end and acknowledged control messages removed from the front.  The
   implementation places control messages in the control packet and
   transmits the entire control packet, consisting of any unacknowledged
   control messages plus new messages just added.  The entire control
   packet is also transmitted whenever the control timer expires.  Since
   control packet transmissions are fairly frequent, unacknowledged
   messages may be transmitted several times before they are finally
   acknowledged.  This redundant transmission of control messages
   provides automatic recovery for most control message losses over a
   noisy channel.

   This scheme places some burdens on the receiver of the control
   messages.  It must be able to quickly reject duplicate control
   messages, since a given message may be retransmitted several times
   before its acknowledgement is received and it is removed from the
   control packet.  Typically this is fairly easy to do; the sender of
   data merely throws away any control messages with sequence numbers
   lower than its high-acknowledged-sequence-number.

   Another problem with this scheme is that the control packet may
   become larger than the maximum allowable packet size if too many
   control messages are placed into it.  This has not been a problem in
   the current NETBLT implementations: a typical control packet size is
   1000 bytes; RESEND control messages average about 20 bytes in length,
   GO messages are 8 bytes long, and OK messages are 16 bytes long.
   This allows 50-80 control messages to be placed in the control
   packet, more than enough for reasonable transfers.  Other
   implementations can provide for multiple control packets if a single
   control packet may not be sufficient.

   The control timer value must be carefully estimated.  It can have as
   its initial value an arbitrary number.  Subsequent control packets
   should have their timer values based on the network round-trip
   transit time (i.e. the time between sending the control packet and
   receiving the acknowledgment of all messages in the control packet)
   plus a variance factor.  The timer value should be continually
   updated, based on a smoothed average of collected round-trip transit
   times.







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


5.2.2. Recovering from Lost LDATA Packets

   NETBLT solves the problem of LDATA packet loss by using a data timer
   for each buffer at the receiving end.  The simplest data timer model
   has a data timer set when a buffer is ready to be received; if the
   data timer expires, the receiving NETBLT assumes a lost LDATA packet
   and sends a RESEND message requesting all missing DATA packets in the
   buffer.  When all packets have been received, the timer is cleared.

   Data timer values are not based on network round-trip transit time;
   instead they are based on the amount of time taken to transfer a
   buffer (as determined by the number of DATA packet bursts in the
   buffer times the burst rate) plus a variance factor <1>.

   Obviously an accurate estimation of the data timer value is very
   important.  A short data timer value causes the receiving NETBLT to
   send unnecessary RESEND packets.  This causes serious performance
   degradation since the sending NETBLT has to stop what it is doing and
   resend a number of DATA packets.

   Data timer setting and clearing turns out to be fairly complicated,
   particularly in a multiple-buffering transfer model.  In
   understanding how and when data timers are set and cleared, it is
   helpful to visualize each buffer as a finite-state machine and take a
   look at the various states.

   The state sequence for a sending buffer is simple.  When a GO message
   for the buffer is received, the buffer is created, filled with data,
   and placed in a SENDING state.  When an OK for that buffer has been