RFC281 Suggested addition to File Transfer Protocol

0281 Suggested addition to File Transfer Protocol. A.M. McKenzie. December 1971. (Format: TXT=12006 bytes) (Updates RFC0265) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group                                        A. McKenzie
Request for Comment: 281                                             BBN
NIC: 8163                                                8 December 1971
Category: D.7
Reference: RFC #264, #265


             A suggested Addition to File Transfer Protocol


On November 16, an informal meeting was held at UCLA to discuss
prospects for a network standard Remote Job Service (RJS) protocol.  In
attendance were representatives of UCLA-CCN and UCSB, the
network's only current RJS sites, as well as UCLA-NMC and the BBN
network project.  A report on that discussion will be published as an
RFC shortly and will not be discussed here.  In thinking about the use
of the proposed File Transfer Protocol (FTP) (RFC #265) for RJS,
however, we came to the conclusion that a "restart" procedure might be
an extremely useful addition to the FTP.

Many, perhaps most, of the individuals involved in protocol design thus
far are oriented toward the use of short date transmissions over the
network the transmission lengths that have been considered "typical" are
a few characters, a print line, or perhaps as much as a page of text.
The experience of the current RJS sites, however, is that single files
are commonly much longer, for example a line-printer output file of 400
pages would not seem unusual to these sites.  Further, one might
reasonably predict that network use of Remote Job Services will be
preselected with a tendency toward large jobs (although large jobs do
not necessarily imply large I/O files) and that the addition of other
batch service sites (ILLIAC, UCSD) will increase the number of long-file
transfers.  In light of this kind of experience/prediction, it would
seem that the FTP should include (perhaps as an option which
interactive-user oriented systems could ignore) a method of "restarting"
a long file transfer if some element in the transmission path fails
after a large volume of data has been transferred.

The critical element in a "restart" procedure is the ability to arrange
agreement between both ends of the transmission path as to where,
exactly, the retransmission should begin.  There are two potential
candidates for marking possible restart locations already built into the
proposed Data Transfer Protocol (RFC #264) which underlies the FTP;
these are:

      a) The "information separators" (transaction type B4) which are
      available in both "transparent block" transfers and "descriptor
      and counts" transfers, and




McKenzie                                                        [Page 1]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


      b) The "sequence numbers" which can be used with the "descriptor
      and counts" transfer mode.

















































McKenzie                                                        [Page 2]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   After some discussion, we seemed to agree that the "information
   separators" (as they would be used in "transparent block" transfer
   mode, i.e., without "sequence numbers") were unlikely to serve as
   UNAMBIGUOUS restart location marker, and therefore we suggest the use
   of "sequence numbers" as markers.  We were aware of the fact that
   this choice might exclude TIPs and other Hosts which do not use
   sequence numbering from the type of recovery under discussion; we
   believe, however, that our suggestion eliminates at least some of
   this problem.

   Imagine that some site, which we will call the "user site" or "user",
   has initiated a connection from its own file transfer process to a
   file transfer process at some other site, which we will call the
   "server site" or "server".  After the appropriate exchanges of
   information, a file transfer (using the File Transfer Protocol)
   begins over the path between these two sites.  After some information
   is transferred, the path between the user and server is broken.  At
   some later time the user initiates a new connection between the file
   transfer processes at user and server, establishes relevant access
   privileges, and wishes to resume the transmission which was in
   progress when the path was broken.  First we describe four new op-
   codes for the File Transfer Protocol:

   Hex        Operation
   ---        ---------
   10         Append at sequence number

              This command is essentially the same as any of the "Store"
              or "Append..." commands except that a 16-bit sequence
              number immediately follows the op-code (before the
              pathname).

   11         Retrieve at sequence number

              This is the same as the "Retrieve"command except that a
              16-bit sequence number immediately follows the op-code
              (before the pathname).

   12         Resume Retrieve

              To be used when the user wishes the server to choose the
              sequence number; in other respects this is identical to
              the "Retrieve" command.








McKenzie                                                        [Page 3]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   13         Use the sequence number

              This command contains only the op-code and a 16-bit
              sequence number.  It is intended as a denial of the
              ability to locate the sequence number given in an "Append
              at sequence number" or "Retrieve at sequence number"
              command and, simultaneously, to suggest another number
              which can be located.

   There are several possible cases which are shown below.  The user
   site is always presumed to be the site at the left of the page.








































McKenzie                                                        [Page 4]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   A.   User site sending at time path is broken:
       /
      /   Append at sequence number
     |    ------------------------------------------->
     |    Acknowledge
     |    <------------------------------------------
     |    Data
     |    ------------------------------------------->
     |
      \   The server site agrees to resume at the user-chosen point.
       \  The first data transaction is numbered with the chosen
        \ sequence number.

       /  Append at sequence number
      /   ------------------------------------------->
     |    Unsuccessful Terminate
     |    <-------------------------------------------
     |
      \   The server site will never permit restart for some reason
       \  (seq. #s were ignored or not used initially, seq #s were not
        \ stored with the file, the file was lost when the path was
         \broken, etc.)

       /  Append at sequence number
      /   ------------------------------------------->
     |    Use this sequence number
     |    <-------------------------------------------
     |       /       Data
     |      /        --------------------------------->
     |      \        The user site agrees to use the server-chosen number
     |       \       and the first data transaction is numbered with the
     |        \      chosen number.
     |
     |                       or
     |
     |         /      Unsuccessful Terminate
      \       /       ------------------------------->
       \      \       The user site cannot restart at this number for
        \      \     some reason.












McKenzie                                                        [Page 5]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   B.  User site receiving at time path is broken, and the user site
   does not particularly care about the exact sequence number (for
   example, if the user site is sending the file to a printer, some
   duplicate pages are probably acceptable and the user site would
   probably not want to remember sequence numbers).

               /  Resume Retrieve
              /   ------------------------------------>
             |    Data
             |    <------------------------------------
             |    The server picks some point and begins transmission at
             |    that point.  If sequence numbers were used during the
             |    original transmission, then the first transaction of
             |    this transmission must exactly match (including
             |    sequence number) some transaction of the original
              \   transmission.

               /  Resume Retrieve
              /   ------------------------------------>
             |    Unsuccessful Terminate
              \   <------------------------------------
               \  The server site is unable or unwilling to restart the
                \ transmission.




























McKenzie                                                        [Page 6]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   C.  User site receiving at time path is broken, and does care about
   the value of the sequence number.

               /  Retrieve at sequence number
              /   ---------------------------------------->
             |    Data
             |    <----------------------------------------
              \   The server agrees to resume at the user-chosen
               \  point. The first data transaction is numbered
                \ with the chosen sequence number.

               /  Retrieve at sequence number
              /   ---------------------------------------->
             |    Unsuccessful Terminate
             |    <----------------------------------------
             |
             |    The server site will never permit restart for some
             |    reason.
             |    Retrieve at sequence number
             |    ---------------------------------------->
             |    Use this sequence number
             |    <-----------------------------------------
             |            /    Acknowledge
             |           /     ---------------------------->
             |          |      Data
             |          |      <----------------------------
             |           \     The user site agrees to use the
             |            \    server-chosen number.  The first data
             |             \   transaction is numbered with the chosen
             |              \  number.
             |
             |                               or
             |
             |             /   Unsuccessful Terminate
             |            /    ----------------------------->
             |           |
              \           \    The server cannot use the user-chosen
               \           \   number and the user cannot use the
                \           \  server-chosen number. Therefore the attempt
                 \           \ to restart must be abandoned.











McKenzie                                                        [Page 7]

RFC 281      A Suggested Addition to File Transfer ProtocolDecember 1971


   Some sites (e.g., UCLA-CCN) have agreed (in principle, at least) to
   implement these commands and, more important, to store sequence
   numbers (with files being transferred) on a non-volatile storage
   medium so that restarts may be effected.  This will be done, of
   course, only if this, or some similar, proposal is accepted by the
   NWG as part of the File Transfer Protocol.  We hope interested
   parties will communicate comments or counter-proposals to the FTP
   committee and/or publish their ideas in the RFC series.

   AAM/jm











          [This RFC was put into machine readable form for entry]
      [into the online RFC archives by Kelly Tardif, Viaginie 10/99]




























McKenzie                                                        [Page 8]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

history.forward

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る