rfc1235.txt

中、英文RFC文档大全打包下载完全版 .


RFC 1235                          CFDP                         June 1991


       0                   1                   2                   3
       0 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           "ticket"                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           checksum                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      'P'      |       0       |      data length (2*N)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Block #0            |           Block #1            |
      |           Block #2            |           Block #3            |
      /                                                               /
      \      data  (block numbers requested)                          \
      /                                                               /
      |           Block #N-2          |           Block #N-1          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Fig. 5: PARREQ (PARtial file REQuest) packet.

   When all packets have been received the client enters the CLEND state
   and stops listening.

   Figure 6 summarizes the client's operations in a state diagram.




























Ioannidis & Maguire, Jr.                                        [Page 7]

RFC 1235                          CFDP                         June 1991


                           +-----------+
                           |  CLSTART  |
                           |           | <---.
                           |   send    |     | timeout TOUT-1
                           |  FULREQ   | ----'
                           |           |
                           +-----------+
                                 |
             received packet     | received packet
      .-----------------------.  |
      |                       V  V
     +---------+             +---------+
     | INCMPLT |             |  RXING  |
     |         |   timeout   |         | <---.
     |  send   |<------------| process |     | received packet
     | PARREQ  |    TOUT-2   | packet  | ----'
     |         |             |         |
     +---------+             +---------+
        ^   |                     |
        |   |                     |finished
        `---'                     |
       timeout                    V
        TOUT-3               +---------+
                             |  CLEND  |
                             +---------+

                Fig. 6: Client State Transition Diagram

 Server Protocol:

   As described above, the CFDP server accepts two kinds of requests: a
   request for a full file transfer, "FULREQ", and a request for a
   partial (some blocks only) file transfer, "PARREQ".  For the first,
   it is instructed to start sending out the contents of a file.  For
   the second, it will only send out the requested blocks.  The server
   should know at all times which files correspond to which "tickets",
   and handle them appropriately.  Note that this may run into
   implementation limits on some Unix systems (e.g., on older systems, a
   process could only have 20 files open at any one time), but that
   should not normally pose a problem.

   The server is initially in the SIDLE state, idling (see diagram
   below).  When it receives a FULREQ packet, it goes to the FULSND
   state, whence it broadcasts the entire contents of the file whose
   ticket was specified in the FULREQ packet.  When it is done, it goes
   back to the SIDLE state. When it receives a PARREQ packet, it goes to
   the PARSND state and broadcasts the blocks specified in the PARREQ
   packet. When it has finished processing the block request, it goes



Ioannidis & Maguire, Jr.                                        [Page 8]

RFC 1235                          CFDP                         June 1991


   once again back to the SIDLE state.

                     receive    +-------+    receive
                .---------------| SIDLE |---------------.
                |    FULREQ     +-------+     PARREQ    |
                |                 ^   ^                 |
                |                 |   |                 |
                V                 |   |                 V
            +--------+            |   |            +--------+
            | FULSND |            |   |            | PARSND |
            |        |    done    |   |    done    |        |
            |  send  |------------'   `------------|  send  |
            | entire |                             | req'ed |
            |  file  |                             | blocks |
            +--------+                             +--------+

                Fig. 7: Server State Transition Diagram

Packet Formats

   The structure of the packets has been already described.  In all
   packet formats, numbers are assumed to be in network order ("big-
   endian"), including the ticket and the checksum.

   The checksum is the two's complement of the unsigned 32-bit sum with
   no end-around-carry (to facilitate implementation) of the rest of the
   packet.  Thus, to compute the checksum, the sender sets that field to
   zero and adds the contents of the packet including the header.  The
   it takes the two's complement of that sum and uses it as the
   checksum.  Similarly, the receiver just adds the entire contents of
   the packet, ignoring overflows, and the result should be zero.

Tuneable Parameters: Packet Size, Delays and Timeouts

   It is recommended that the packet size be less than the minimum MTU
   on the connected network where the file transfers are taking place.
   We want this so that there be no fragmentation; one UDP packet should
   correspond to one hardware packet.  It is further recommended that
   the packet size be a power of two, so that offsets into the file can
   be computed from the block number by a simple logical shift
   operation.  Also, it is usually the case that page-aligned transfers
   are faster on machines with a paged address space.  Small packet
   sizes are inefficient, since the header will be a larger fraction of
   the packet, and packets larger than the MTU will be fragmented.  A
   good selection for BLKSZ is 512 or 1024. Using that BLKSZ, one can
   transfer files up to 32MB or 64MB respectively (since the limit is
   the 16-bit packet sequence number).  This is adequate for all but
   copying complete disks, and it allows twice as many packets to be



Ioannidis & Maguire, Jr.                                        [Page 9]

RFC 1235                          CFDP                         June 1991


   requested in a PARREQ request than if the sequence number were 32
   bits.  If larger files must be transferred, they could be treated as
   multiple logical files, each with a size of 32MB (or 64MB).

   Since most UDP/IP implementations do not buffer enough UDP datagrams,
   the server should not transmit packets faster than its clients can
   consume them.  Since this is a one-to-many transfer, it is not
   desirable to use flow-control to ensure that the server does not
   overrun the clients.  Rather, we insert a small delay between packets
   transmitted.  A good estimate of the proper delay between two
   successive packets is twice the amount of time it takes for the
   interface to transmit a packet.  On Unix implementations, the ping
   program can be used to provide an estimate of this, by specifying the
   same packet length on the command line as the expected CFDP packet
   length (usually 524 bytes).

   The timeouts for the client are harder to compute. While there is a
   provision for the three timeouts (TOUT-1, TOUT-2 and TOUT-3) to be
   different, there is no compelling reason not to make them the same.
   Experimentally, we have determined that a timeout of 6-8 times the
   transfer time for a packet works best.  A timeout of less than that
   runs the risk of mistaking a transient network problem for a timeout,
   and more than that delays the transfer too much.

Summary

   To summarize, here is the timeline of a sample file distribution
   using CFDP to three clients.  Here we request a file with eight
   blocks.  States are capitalized, requests are preceded with a '<'
   sign, replies are followed by a '>' sign, block numbers are preceded
   with a '#' sign, and actions are in parentheses:

SERVER       CLIENT1     CLIENT-2      CLIENT-3      comments

IDLE                                                everybody idle
             CLSTART                                CL1 wants a file
             <TKRQ                                  requests ticket
TIYT>                                               server replies
             (timeout)                              listens for traffic
             <FULREQ                                full request
#0           RXING                                  CL1 starts receiving
             (rx 0)
#1           (rx 1)      CLSTART                    CL2 decides to join
                         <TKRQ
#2           (rx 2)                                 SRV still sending
TIYT>                                               responds to TKRQ
#3           (rx 3)      (listens)                  CL2 listens
                         RXING                      found traffic



Ioannidis & Maguire, Jr.                                       [Page 10]

RFC 1235                          CFDP                         June 1991


#4           (rx 4)      (rx 4)        CLSTART      CL3 joins in
                                       <TKRQ
#5           (missed)    (rx 5)                     CL1 missed a packet
TIYT>                                  (listens)
#6           (rx 6)      (rx 6)        RXING        CL3 found traffic

#7           (rx 7)      (rx 7)        (rx 7)       Server finished
IDLE
             (wait)      (wait)        (wait)       CL1 managed to
             (timeout)   (wait)        (wait)       timeout
             <PARREQ[5]  (timeout)     (timeout)    CL1 blockrequests...
#5           (rx 5)      <PARREQ[0123] <PARREQ[0123456] ignored by SRV
             CLEND                                  CL1 has all packets
IDLE                     (wait)        (wait)       CL2+3 missed #5
                         (timeout)     (timeout)
                         <PARREQ[0123] <PARREQ[0123456] CL2's req gets
#0                       (rx 0)        (rx 0)       through, CL3 ignored
#1                       (rx 1)        (rx 1)       moving along
#2                       (rx 2)        (rx 2)
#3                       (rx 3)        (rx 3)
IDLE                     CLEND         (wait)       CL2 finished
                                       (timeout)
                                       <PARREQ[456]
#4                                     (rx 4)
#5                                     (rx 5)
#5                                     (rx 6)
IDLE                                   CLEND        CL3 finished

References

   [1] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, MIT, June
       1981.

   [2] Finlayson, R., "Bootstrap Loading Using TFTP", RFC 906, Stanford,
       June 1984.

   [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
       Stanford and SUN Microsystems, September 1985.

   [4] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
       USC/Information Sciences Institute, December 1988.

   [5] Postel, J., "User Datagram Protocol", RFC 768, USC/Information
       Sciences Institute, August 1980.

   [6] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
       Stanford University, August 1989.




Ioannidis & Maguire, Jr.                                       [Page 11]

RFC 1235                          CFDP                         June 1991


   [7] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       Specification", RFC 791, DARPA, September 1981.

   [8] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data
       Transfer Protocol", RFC 998, MIT, March 1987.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   John Ioannidis
   Columbia University
   Department of Computer Science
   450 Computer Science
   New York, NY 10027

   EMail:  [e-mail]


   Gerald Q. Maguire, Jr.
   Columbia University
   Department of Computer Science
   450 Computer Science
   New York, NY 10027

   Phone:  [phone]

   EMail:  [e-mail]





















Ioannidis & Maguire, Jr.                                       [Page 12]