rfc969.txt

RFC 相关的技术文档

RFC 969                                                    December 1985
NETBLT: A Bulk Data Transfer Protocol


   Obviously each of the parameters depend on many factors-- gateway and
   host processing speeds, available memory, timer granularity--some of
   which cannot be checked by either client.  Each client must therefore
   try to make as best a guess as it can, tuning for performance on
   subsequent transfers.

5. RELIABILITY

   Each NETBLT transfer has three stages, connection setup, data
   transfer, and connection close.  Each stage must be completed
   reliably; methods for doing this are described below.

   5.1. Connection Setup

      A NETBLT connection is set up by an exchange of two packets
      between the active client and the passive client.  Note that
      either client can send or receive data; the words "active" and
      "passive" are only used to differentiate the client initiating the
      connection process from the client responding to the connection
      request.  The first packet sent is an OPEN packet; the passive end
      acknowledges the OPEN packet by sending a RESPONSE packet.  After
      these two packets have been exchanged, 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 transfer of data are also negotiated.
      These parameters are (1) the maximum number of buffers that can be
      sending at any one time (this permits multiple buffering and
      higher throughput) and (2) whether or not DATA/LDATA 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.
      NETBLT uses the same checksumming algorithm as TCP uses.

      Finally, each end transmits its death-timeout value in either the
      OPEN or the RESPONSE packet.  The death-timeout value will be used
      to determine the frequency with which to send KEEPALIVE 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 16 bit port number.

      In order to allow the active and passive ends to communicate


Clark & Lambert & Zhang                                         [Page 6]



RFC 969                                                    December 1985
NETBLT: A Bulk Data Transfer Protocol


      miscellaneous useful information, an unstructured, variable-
      length field is provided in OPEN and RESPONSE messages for an
      client-specific information that may be required.

      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 pre-determined maximum number of OPEN packets have been sent.
      A similar scheme is used for the passive end when it sends a
      RESPONSE packet.  When a RESPONSE packet is received by the active
      end, it clears its timer.  The passive end's timer is cleared
      either by receipt of a GO or a DATA packet, as described in the
      section on data transfer.

      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.  A matching unique ID implies a duplicate
      packet, and the packet is ignored.  A non-matching unique ID must
      be treated as an attempt to open a second connection between the
      same port pair and must be 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 into it. Once the GO message has been 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 which time the receiver sends an OK
      message inside a CONTROL packet to the sender, 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 message, and repeats the process.

      There are several obvious flaws with this scheme.  First, if the
      LDATA packet is lost, how does the receiver know when the buffer
      has been transmitted?  Second, what if the GO, OK, or RESEND


Clark & Lambert & Zhang                                         [Page 7]



RFC 969                                                    December 1985
NETBLT: A Bulk Data Transfer Protocol


      messages are lost?  The sender cannot act on a packet it has not
      received, so the protocol will hang.  Solutions for each of these
      problems are presented below, and are based on two kinds of
      timers, a data timer and a control timer.

      NETBLT solves the LDATA packet loss problem by using a data timer
      at the receiving end.  When the first DATA packet in a buffer
      arrives, the receiving NETBLT sets its data timer; at the same
      time, it clears its control timer, described below.  If the data
      timer expires, the receiving end assumes the buffer has been
      transmitted and all missing packets lost.  It then sends a RESEND
      message containing a list of the missing packets.

      NETBLT solves the second problem, that of missing OK, GO, and
      RESEND messages, through use of a control timer.  The receiver can
      send one or more control messages (OK, GO, or RESEND) within a
      single CONTROL packet.  Whenever the receiver sends a control
      packet, it sets a control timer (at the same time it clears its
      data timer, if one has been set).

      The control timer is cleared as follows: 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, and returns this number in every packet flowing
      back to the receiver.  The receiver is permitted to clear the
      control timer of every packet with a sequence number equal to or
      lower than the sequence number returned by the sender.

      Ideally, a NETBLT implementation should be able to cope with
      out-of-sequence 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.

      When the control timer expires, the receiving NETBLT resends the
      control message and resets the timer.  After a predetermined
      number of resends, the receiving NETBLT can assume that the
      sending NETBLT has died, and can reset the connection.

      The sending NETBLT, upon receiving a control message, should act
      as quickly as possible on the packet; it either sets up a new
      buffer (upon receipt of an OK packet for a previous buffer),
      resends data (upon receipt of a RESEND packet), or sends data


Clark & Lambert & Zhang                                         [Page 8]



RFC 969                                                    December 1985
NETBLT: A Bulk Data Transfer Protocol


      (upon receipt of a GO packet).  If the sending NETBLT is not in a
      position to send data, it sends a NULL-ACK packet, which contains
      a
      high-received-sequence-number as described above (this permits the
      receiving NETBLT to clear the control timers of any packets which
      are outstanding), and waits until it can send more data.  In all
      of these cases, the overhead for a response to the incoming
      control message should be small; the total time for a response to
      reach the receiving NETBLT should not be much more than the
      network round-trip transit time, plus a variance factor.

      The 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 being transferred; a control
      timer is active while it is between buffer transfers.

      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 all its control timers 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 just hang waiting for control messages.

      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 at one end expires, it can assume the other
      end has died and can close the connection.

      It is quite possible that the sending or receiving NETBLTs will
      have to wait for long periods of time 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
      is waiting for buffer space.  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


Clark & Lambert & Zhang                                         [Page 9]



RFC 969                                                    December 1985
NETBLT: A Bulk Data Transfer Protocol


      death-timeout 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.

      Both ends must have some way of estimating the values of the death
      timers, the control timers, and the data timers.  The timer values
      obviously cannot be specified in a protocol document since they
      are very machine- and network-load-dependent.  Instead they must
      be computed on a per-connection basis.  The protocol has been
      designed to make such determination easy.

      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.

      The control timer must be more carefully estimated.  It can have
      as its initial value an arbitrary number; this number can be used
      to send the first control packet.  Subsequent control packets can
      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 the corresponding sequence number)
      plus a variance factor.  The timer value should be continually
      updated, based on a smoothed average of collected round-trip
      transit times.

      The data timer is dependent not on the network round-trip transit
      time, but on the amount of time required to transfer a buffer of
      data. The time value can be computed from the burst rate and the
      number of bursts per buffer, plus a variance value <1>. During the
      RESENDing phase, the data timer value should be set according to
      the number of missing packets.

      The timers have been designed to permit reasonable estimation.  In
      particular, in other protocols, determination of round-trip delay
      has been a problem since the action performed by the other end on
      receipt of a particular packet can vary greatly depending on the
      packet type. In NETBLT, the action taken by the sender on receipt
      of a control message is by and large the same in all cases, making
      the round-trip delay relatively independent of the client.



Clark & Lambert & Zhang                                        [Page 10]