rfc1068.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,515 行 · 第 1/4 页

Network Working Group                                         A. DeSchon
Request for Comments: 1068                                     R. Braden
                                                                     ISI
                                                             August 1988

                Background File Transfer Program (BFTP)


Status of This Memo

   This memo describes an Internet background file transfer service that
   is built upon the third-party transfer model of FTP.  No new
   protocols are involved.  The purpose of this memo is to stimulate
   discussion on new Internet service modes.  Distribution of this memo
   is unlimited.

1. Introduction

   For a variety of reasons, file transfer in the Internet has generally
   been implemented as an interactive or "foreground" service.  That is,
   a user runs the appropriate local FTP user interface program as an
   interactive command and requests a file transfer to occur in real
   time.  If the transfer should fail to complete for any reason, the
   user must reissue the transfer request.  Foreground file transfer is
   relatively simple to implement -- no subtleties of queuing or stable
   storage -- and in the early days of networking it provided excellent
   service, because the Internet/ARPANET was lightly loaded and
   reasonably reliable.

   More recently, the Internet has become increasingly subject to
   congestion and long delays, particularly during times of peak usage.
   In addition, as more of the world becomes interconnected, planned and
   unplanned outages of hosts, gateways, and networks sometimes make it
   difficult for users to successfully transfer files in foreground.

   Performing file transfer asynchronously (i.e., in "background"),
   provides a solution to some of these problems, by eliminating the
   requirement for a human user to be directly involved at the time that
   a file transfer takes place.  A background file transfer service
   requires two components: a user interface program to collect the
   parameters describing the required transfer(s), and a file transfer
   control (FTC) daemon to carry them out.









DeSchon & Braden                                                [Page 1]

RFC 1068                                                     August 1988


   Background file transfer has a number of potential advantages for a
   user:

   o    No Waiting

        The user can request a large transfer and ignore it until a
        notification message arrives through some common channel (e.g.,
        electronic mail).

   o    End-to-end Reliability

        The FTC daemon can try a transfer repeatedly until it either
        succeeds or fails permanently.  This provides reliable end-to-
        end delivery of a file, in spite of the source or destination
        host being down or poor Internet connectivity during some time
        period.

   o    Multiple File Delivery

        In order for background file transfer to be accepted in the
        Internet, it may have to include some "value-added" services.
        One such service would be an implementation of a multiple file
        transfer capability for all hosts.  Such a facility is suggested
        in RFC-959 (see the description of "NLST") and implemented in
        some User-FTP programs.

   o    Deferred Delivery

        The user may wish to defer a large transfer until an off-peak
        period.  This may become important when parts of the Internet
        adopt accounting and traffic-based cost-recovery mechanisms.


   There is a serious human-engineering problem with background file
   transfer: if the user makes a mistake in entering parameters, this
   mistake may not become apparent until much later.  This can be the
   cause of severe user frustration.  To avoid this problem, the user
   interface program ought to verify the correctness of as many of the
   parameters as possible when they are entered.  Of course, such
   foreground verification of parameters is not possible if the remote
   host to which the parameters apply is currently unreachable.

   To explore the usefulness of background file transfer in the present
   Internet, we have implemented a file-mover service which we call the
   Background File Transfer Program or BFTP.

   Section 2 describes BFTP and Section 3 presents our experience and
   conclusions.  The appendices contain detailed information about the



DeSchon & Braden                                                [Page 2]

RFC 1068                                                     August 1988


   user interface language for BFTP, a description of the program
   organization, and sample execution scripts.

2. Background File Transfer Program

   2.1 General Model

      In the present BFTP design, its user interface program and its FTC
      daemon program must execute on the same host, which we call the
      BFTP control host.

      Through the user interface program, a BFTP user will supply all of
      the parameters needed to transfer a file from source host S to
      destination host D, where S and D may be different from the BFTP
      control host.  These parameters include:

      o    S and D host names,

      o    login names and passwords on S and D hosts, and

      o    S and D file names (and optionally, directories).


      The user may also specify a number of optional control parameters:

      *    Source file disposition -- Copy, move (i.e., copy and
           delete), or simply delete the source file.  The default is
           copy.

      *    Destination file operation -- Create/Replace, append to, or
           create a unique destination file.  The default is
           create/replace ("STOR").

      *    FTP Parameters -- Explicitly set any of the FTP type, mode,
           or structure parameters at S and D hosts.

      *    Multiple Transfers -- Enable "wildcard" matching to perform
           multiple transfers.

      *    Start Time -- Set the time of day for the first attempt of
           the transfer. The default is "now" (i.e., make the first
           attempt as soon as the request has been queued for the FTC
           daemon).


      Finally, the user specifies a mailbox to which a completion
      notification message will be sent, and "submits" the request to
      the FTC daemon queue.  The user can then exit the BFTP user



DeSchon & Braden                                                [Page 3]

RFC 1068                                                     August 1988


      interface program.

      If the transfer should fail permanently, the FTC daemon will send
      a notification message to the user's mailbox.  In the event of a
      temporary failure (e.g., a broken TCP connection), the FTC daemon
      will log the failure and retry the transfer after some timeout
      period.  The retry cycles will be repeated until the transfer
      succeeds or until some maximum number of tries specified has been
      reached.  In either case, a notification message will then be sent
      to the user's mailbox.

      The user can check on the progress of the transfer by reentering
      the BFTP user interface program, supplying a key that was defined
      with the request, and displaying the current status of the
      request.  The user may then cancel the request or leave it in the
      queue.

      The BFTP program includes a server-Telnet module, so it can be
      executed as a remotely-accessible service that can be reached via
      a Telnet connection to the BFTP well-known port (152).  This
      allows a user on any Internet host to perform background file
      transfers without running BFTP locally, but instead opening a
      Telnet connection to port 152 on a BFTP service host.  Of course,
      a user can also run the local BFTP user interface program directly
      on any host that supports it and for which the user has login
      privileges.

      The next section discusses how BFTP uses standard FTP servers to
      perform the transfers, while the following section covers the user
      interface of BFTP.

   2.2 File Transfer Mechanics for BFTP

      The BFTP makes use of the "third party" or "Server-Server" model
      incorporated in the Internet File Transfer Protocol [RFC-959].
      Thus, the FTC daemon opens FTP control connections to the existing
      FTP servers on source host S and destination host D and instructs
      them to transfer the desired file(s) from S to D.  The S and D
      hosts may be any two Internet hosts supporting FTP servers (but at
      least one of them must support the FTP "PASV" command).  This
      approach allows the implementation of a background file transfer
      capability for the entire Internet at a very low cost.

      Figure 1 illustrates the BFTP model of operation.  Note that the
      BFTP control host is not necessarily the same as S or D.  Figure 2
      illustrates the FTP command interchange used in a typical Server-
      Server file transfer operation; this may be compared with the
      User-Server FTP scenario illustrated in Section 7 of RFC-959.



DeSchon & Braden                                                [Page 4]

RFC 1068                                                     August 1988


      Since BFTP may be asked to transfer files between any two hosts in
      the Internet, it must support all the file types and transfer
      modes that are defined in RFC-959, not just a subset implemented
      by particular hosts.

      BFTP supports the transfer of a set of files in a single request,
      using the standard technique:

      (1)  Send an NLST command to the source host S, specifying a
           pathname containing "wildcard" characters.  The reply will
           contain a list of matching source file names.

      (2)  Execute a separate transfer operation for each file in this
           list.  The destination file name in each case is assumed to
           be the same as the source file name; this requires that these
           names be compatible with the naming conventions of D.

      It will typically be necessary to specify working directories for
      the transfers at S and D, so the file names will be simple,
      unstructured names on each system.

      This approach depends upon the wildcard matching capability of the
      source host S.  A more general implementation would acquire a
      complete list of the file names from the source host and do the
      matching in the FTC daemon, for example using a regular-expression
      matcher.  Another useful extension would be a general pattern-
      matching file name transformation capability (e.g., like the one
      included in the 4.3BSD version of FTP) to generate appropriate
      destination pathnames for multiple requests.






















DeSchon & Braden                                                [Page 5]

RFC 1068                                                     August 1988


                    Figure 1 -- BFTP Model of Operation





                            ---------                        Remote
                           |  BFTP   |      (telnet)      o    User
             Local         | Network | <---------------- -|-
             User  o       | Server  |                   / \
                  -|-       ---------
                  / \  |       |
                       |       |
                       |       |
                       v       v
                      -----------  (Submit    +---+
                     | BFTP User |  request)  |---| Request
                     | Interface | ---------> |---| Queue
                      -----------             |---|
                              .               +---+
                               .              /
                                .            /
                    (foreground  .          / (try/retry
                      request--   .        /   request)
                      see 2.3)     v      v
                                   --------                 +---+
                                  |  FTC   | -------------> |   |  User
                                  | Daemon |     Notify     |   | Mailbox
                                   --------      Message    +---+
                                  /        \
                                 /   FTP    \
                                /   Control  \
                               /  Connections \
                      HOST S  v                v  HOST D
                       --------                --------
                      |  FTP   | ===========> |  FTP   |
                      | Server |  file        | Server |
                       --------    transfer    --------













DeSchon & Braden                                                [Page 6]

RFC 1068                                                     August 1988


             Figure 2 -- Server-Server File Transfer



          Server FTP            BFTP Daemon             Server FTP
            HOST S                HOST C                  HOST D
           ----------           -----------             ----------

                      <-------- Open TCP Ctrl conn
                           Open TCP Ctrl conn -------->

                      <-------- (log in)
      (login confirm.) -------->
                                     (log in) -------->
                                             <-------- (login confirm.)

                      <-------- TYPE, STRU, MODE, CWD
       (confirmations) -------->
                        TYPE, STRU, MODE, CWD -------->
                                             <-------- (confirmations)

                      <--------  PASV command
          PASV confirm -------->
                                 PORT command -------->
                                             <-------- PORT confirm

                                  RETR file   -------->
                      <--------   STOR file
                      <------------------------------ Open TCP Data conn
                      <------------------------------ Send file
                      <------------------------------ Close Data conn
                                            <-------- RETR confirm
          STOR confirm -------->

                      <-------- QUIT command
                                QUIT command -------->
       Close Ctrl conn -------->