rfc1068.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,515 行 · 第 1/4 页
TXT
1,515 行
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 -------->
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?