rfc1068.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,515 行 · 第 1/4 页
TXT
1,515 行
<-------- Close Ctrl conn
DeSchon & Braden [Page 7]
RFC 1068 August 1988
BFTP currently utilizes the following Server-FTP commands [RFC-
959]: USER, PASS, ACCT, PASV, PORT, RETR, STOR, STOU, CWD, NLST,
MODE, STRU, TYPE, and QUIT.
The FTC daemon attempts to work around FTP servers that fail to
support certain commands. For example, if a server does not
support the optional command "CWD", the FTC daemon will attempt to
construct a complete path name using the source directory name and
the source file name. However, it is necessary that at least one
of the two hosts support the FTP passive (PASV) command. While
many FTP server implementations support do this command, some (in
particular, the 4.2BSD FTP) do not. The PASV command was
officially listed as being optional in RFC-959.
2.3 Reliable Delivery
The reliable delivery function of BFTP is analogous to reliable
delivery in a transport protocol like TCP. Both depend upon
repeated delivery attempts until success is achieved, and in both
cases the choice of the retry interval requires some care to
balance overhead against unresponsiveness.
Humans are impatient, but even their impatience has a limit. If
the file cannot be transferred "soon", a human will turn to
another project; typically, there is a tendency for the transfer
to become less urgent the longer the wait. The FTC daemon of BFTP
therefore starts each transfer request with a very short retry
interval -- e.g., 10 minutes -- and then doubles this interval for
successive retries, until a maximum interval -- e.g., 4 hours --
is reached. This is essentially the exponential backoff algorithm
of the Ethernet, which is also used by transport protocols such as
TCP, although BFTP and TCP have quite different rationales for the
algorithm.
We must also define the meaning of reliable transmission for a
multiple-transfer request. For example, the set of files selected
by wildcard characters in a pathname is not well defined; the set
may change while the request is pending, as files are created and
deleted. Furthermore, it is unreasonable to regard the entire
multiple transfer as a single atomic operation. Suppose that
transferring a set of files fails part way through; for an atomic
operation, the files which had been successfully transferred would
have to be deleted pending the next retry of the entire set. This
would be ridiculously inefficient and may be impossible (since the
communication path may be broken when it is time to issue the
deletion requests).
DeSchon & Braden [Page 8]
RFC 1068 August 1988
BFTP addresses these issues in the following manner:
* For a multiple file operation, the FTC daemon saves the file
name list returned by the first successful NLST command in
the request queue entry. This name list determines the set
of source files for the transfer; there can be no later
additions to the set.
* The FTC daemon maintains a transfer status pointer. On each
retry cycle, it tries to transfer only those files that have
not already been successfully transferred.
* The request is complete when all the individual file
transfers have been successful, a permanent failure has
occured, or when the retry limit is reached.
* The notification message to the user lists the status of each
of the multiple files.
2.4 BFTP User Interface
The purpose of BFTP is to simplify the file transfer process and
to place the burden of reliability on the BFTP control host. We
have attempted to provide a "user friendly" command interface to
BFTP, similar in flavor to the user interface of the TOPS-20
operating system. This interface provides extensive prompting,
defaulting, and help facilities for every command.
For a list of all BFTP commands, the user may enter "?<Return>" at
the main BFTP prompt ("BFTP>"). Entering "help<Return>" and
"explain<Return>" will provide increasing levels of explanatory
material. To obtain information on a particular command, "help
<command name><Return>" may be entered. The 'quit' or 'exit'
command will exit from BFTP. Command and subcommand names may be
abbreviated to the shortest unique sequence for that context;
alternatively, a partial name can be automatically completed by
typing <Return>.
The normal procedure for a BFTP user is to set up a set of
parameters defining the desired transfer and then submit the
request to the FTC daemon. To give the user the maximum
flexibility, BFTP supports three modes of submission:
o Background Operation
To request a reliable background file transfer, the user will
issue the BFTP 'submit' command to the FTC daemon.
DeSchon & Braden [Page 9]
RFC 1068 August 1988
o Foreground Verification, Background Operation
The BFTP 'verify' command may be used to ascertain that file
transfer parameters are valid. It causes BFTP to connect to
the FTP servers on both the source and the destination hosts
(if possible), log into both, verify the FTP parameters, and
verify that the specified source file is present.
Once the 'verify' command has successfully completed, the
user can issue the 'submit' command to schedule the actual
file transfer.
o Foreground Operation
The BFTP 'transfer' command will perform the specified
third-party transfer in foreground mode. This is illustrated
by the dotted path bypassing the queue in Figure 1.
The easiest way to set up the parameters is to issue the 'prompt'
command, which will prompt the user for all of the basic
parameters required for most transfers. Certain unusual
parameters must be set with the 'set' command (see Appendix B for
details).
When entering any parameter, the following control characters may
be used:
? will display help text for the parameter, indicating its
meaning, the choices, and the default, and then reprompt for
the parameter.
<ESC> will display the default value (or the last value set) for
this parameter. The user can accept this default by entering
<Return>, or else erase it with Control-W and enter a
different value for the parameter, followed by <Return> to
accept the entered value.
<Control-W>
will erase the value typed or displayed for current
parameter.
<Return>
will accept the value displayed for this parameter, and
continue to the next parameter, if any. If the user has not
typed a value or used <ESC> to display the default, <Return>
will display the default and then accept it.
DeSchon & Braden [Page 10]
RFC 1068 August 1988
It is important to provide a means for a user to obtain status
information about an earlier request or even to cancel an earlier
request. However, these functions, especially cancellation, must
be controlled by some user authentication. We did not want to
build a user authentication database with each BFTP instance or
require login to BFTP itself, and there is no Internet-wide user
authentication mechanism. We adopted the following weak
authentication mechanism as a compromise:
* When the 'submit' command is issued, it prompts the user for
a character string called a "keyword", which recorded with
the request.
* This keyword can be entered later as the argument to a 'find'
command, which will display the status of all requests with
matching keywords.
* Similarly, the keyword may be used to cancel the
corresponding request.
If two different users happen to choose the same keywords, of
course, this scheme will not protect each other's requests from
accidental or malicious cancellation. However, a notification
message will be sent at the time that a cancellation occurs.
To make a series of similar requests, the user needs only to
change the individual parameters that differ from the preceding
request and then issue a new 'submit' command, for each request.
There are commands for individually setting each of the parameters
that 'prompt' sets -- and 'time' -- to provide a shortcut for BFTP
experts. A simpler but lengthier procedure is to use the 'prompt'
command to run through the current set of parameters, reentering
the parameters that must change and using the sequence
<ESC><return> to retain the previous value for each of the others.
The same procedures may be used to correct a mistake made in
entering a particular parameter.
The current settings of all the BFTP parameters can be displayed
at any time with the 'status' command, while the 'clear' command
will return all parameters to their initial values. Finally, the
'request' command allows the user to save the current set of
parameters in a file or to restore the parameters from a
previously-saved file.
There is also a window-based BFTP user interface for use on a Sun
Workstation, described in Appendix A. The complete list of BFTP
commands is presented in Appendix B.
DeSchon & Braden [Page 11]
RFC 1068 August 1988
3. Experience and Conclusions
BFTP has been available to users at ISI for some months. Users have
reported a number of advantages of using BFTP:
(a) Some users prefer the prompting style of BFTP to the user
interface of the foreground FTP they normally use.
(b) The BFTP "verify" command allows the user to verify that host
names, passwords, and filenames are correct without having to
wait for the entire transfer to take place.
(c) Since results are returned through the mail system, a transfer
can occur without tying up a terminal line, a phone line, or
even a window.
BFTP must be able to communicate with a variety of Server-FTP
implementations, and we have observed much variation in the commands
supported, error handling, and the timing in these servers. Some of
the problems we have encountered are:
(1) Some systems (e.g., 4.2BSD) do not support the PASV command.
(2) 4.2/3BSD systems return a non-standard response to the NLST
command. Instead of returning a list of complete path-names,
they use an ad hoc format consisting of a directory name
followed by a list of files.
(3) 4.2/3BSD systems may return a "permanent negative completion
reply" (a 5xx FTP reply code) as a result of a communications
failure such as a broken TCP connection. According to RFC-959,
the appropriate response is a "transient negative completion
reply" (a 4xx FTP reply code), which would inform the BFTP that
the transfer should be retried.
(4) A number of servers return badly formatted responses. An
example of this is the 4.2/3BSD response to an NLST command for
a non-existent file name: an error string which is not preceded
by a numerical response code.
To diagnose problems that do occur, we have found it very useful to
have a complete record of the interchange between the FTC daemon and
the two FTP servers. This record is saved and is currently always
included in the notification message mailed to the user (see Appendix
D for an example). As we get more experience with this program, some
of the details of the transfer may be omitted from this log.
DeSchon & Braden [Page 12]
RFC 1068 August 1988
The use of library routines shared between modules makes it
relatively easy to implement additional user interface programs. We
are currently experimenting with a window version of BFTP, the
"bftptool", which runs in the SunView environment, and is described
in Appendix A. Some additional interfaces that might be useful are:
o A command line interface for use in shell scripts and
"Makefiles".
o A more general library interface which would make it easy to
invoke BFTP from a variety of programs.
o Additional full-screen form based interfaces, for example a tool
running in X-Window system environment.
Lastly, BFTP would benefit from the resolution of the following open
protocol issues:
o There currently exist no provisions for Internet-wide user
authentication. In the BFTP context, this means that passwords
required for a file transfer must be present in BFTP request
files. The security of these passwords is subject to the
limitations of the file system security on the BFTP control
host. Anonymous file transfer provides a partial solution, but
a more general, long term solution is needed.
o Better mechanisms are needed to cope with the diversity of real
file systems in the Internet.
For example, an extension could be made to the FTP protocol to
allow the daemon to learn the delimiter conventions of each host
file system. This could allow a more flexible and powerful
multiple-file facility in BFTP. This could include the
automatic transfer of directory subtrees, for example.
4. References
[RFC-959] Postel, J., and J. Reynolds, "File Transfer Protocol
(FTP)", RFC-959, USC/Information Sciences Institute,
October 1985.
DeSchon & Braden [Page 13]
RFC 1068 August 1988
Appendix A -- BFTP Implementation Structure
BFTP has been implemented on both a Sun workstation running Sun OS
3.4 (based on 4.2BSD) and a VAX running 4.3BSD. The program modules
are: the local user interface programs "bftp", the Internet server
program "bftpd", and the FTC daemon "fts". BFTP makes use of the
"at" command, a UNIX batch job facility, to submit requests and
execute the daemon. An additional user interface program, the
"bftptool", is available for Sun OS 3.4, and runs in the SunView
environment.
BFTP keeps its state in a set of control files: request files,
command files, and message files. These files are stored in the home
directory specified for the environment of the process running
"bftp". If a user is running "bftp" directly, this will typically be
the user's home directory. In the case where a user has made a
Telnet connection to the well-known port 152 on a BFTP service host,
"bftp" is started by "bftpd" (or "inetd", indirectly). As a result,
the control files will be owned by the user-id under which "inetd"
was started, normally "root", and stored in the top level directory
"/". Note, however, that under BFTP all user files are written by
the FTP servers, which are presumed to enforce the operating systems'
access control conventions. Hence, BFTP does not constitute a system
integrity exposure.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?