Background File Transfer Program (BFTP)
RFC 1068

Document Type RFC - Unknown (August 1988; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1068 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text