As per Relevance of the word parameter, we have this rfc below:
Network Working Group A.
Request for Comments: 1068 R.
August 1988
Background File Transfer Program (BFTP
Status of This
This memo describes an Internet background file transfer service
is built upon the third-party transfer model of FTP. No
protocols are involved. The purpose of this memo is to
discussion on new Internet service modes. Distribution of this
is unlimited
1.
For a variety of reasons, file transfer in the Internet has
been implemented as an interactive or "foreground" service. That is
a user runs the appropriate local FTP user interface program as
interactive command and requests a file transfer to occur in
time. If the transfer should fail to complete for any reason,
user must reissue the transfer request. Foreground file transfer
relatively simple to implement -- no subtleties of queuing or
storage -- and in the early days of networking it provided
service, because the Internet/ARPANET was lightly loaded
reasonably reliable
More recently, the Internet has become increasingly subject
congestion and long delays, particularly during times of peak usage
In addition, as more of the world becomes interconnected, planned
unplanned outages of hosts, gateways, and networks sometimes make
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
requirement for a human user to be directly involved at the time
a file transfer takes place. A background file transfer
requires two components: a user interface program to collect
parameters describing the required transfer(s), and a file
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
user
o No
The user can request a large transfer and ignore it until
notification message arrives through some common channel (e.g.,
electronic mail).
o End-to-end
The FTC daemon can try a transfer repeatedly until it
succeeds or fails permanently. This provides reliable end-to
end delivery of a file, in spite of the source or
host being down or poor Internet connectivity during some
period
o Multiple File
In order for background file transfer to be accepted in
Internet, it may have to include some "value-added" services
One such service would be an implementation of a multiple
transfer capability for all hosts. Such a facility is
in RFC-959 (see the description of "NLST") and implemented
some User-FTP programs
o Deferred
The user may wish to defer a large transfer until an off-
period. This may become important when parts of the
adopt accounting and traffic-based cost-recovery mechanisms
There is a serious human-engineering problem with background
transfer: if the user makes a mistake in entering parameters,
mistake may not become apparent until much later. This can be
cause of severe user frustration. To avoid this problem, the
interface program ought to verify the correctness of as many of
parameters as possible when they are entered. Of course,
foreground verification of parameters is not possible if the
host to which the parameters apply is currently unreachable
To explore the usefulness of background file transfer in the
Internet, we have implemented a file-mover service which we call
Background File Transfer Program or BFTP
Section 2 describes BFTP and Section 3 presents our experience
conclusions. The appendices contain detailed information about
DeSchon & Braden [Page 2]
RFC 1068 August 1988
user interface language for BFTP, a description of the
organization, and sample execution scripts
2. Background File Transfer
2.1 General
In the present BFTP design, its user interface program and its
daemon program must execute on the same host, which we call
BFTP control host
Through the user interface program, a BFTP user will supply all
the parameters needed to transfer a file from source host S
destination host D, where S and D may be different from the
control host. These parameters include
o S and D host names
o login names and passwords on S and D hosts,
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
delete), or simply delete the source file. The default
copy
* Destination file operation -- Create/Replace, append to,
create a unique destination file. The default
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
multiple transfers
* Start Time -- Set the time of day for the first attempt
the transfer. The default is "now" (i.e., make the
attempt as soon as the request has been queued for the
daemon).
Finally, the user specifies a mailbox to which a
notification message will be sent, and "submits" the request
the FTC daemon queue. The user can then exit the BFTP
DeSchon & Braden [Page 3]
RFC 1068 August 1988
interface program
If the transfer should fail permanently, the FTC daemon will
a notification message to the user's mailbox. In the event of
temporary failure (e.g., a broken TCP connection), the FTC
will log the failure and retry the transfer after some
period. The retry cycles will be repeated until the
succeeds or until some maximum number of tries specified has
reached. In either case, a notification message will then be
to the user's mailbox
The user can check on the progress of the transfer by
the BFTP user interface program, supplying a key that was
with the request, and displaying the current status of
request. The user may then cancel the request or leave it in
queue
The BFTP program includes a server-Telnet module, so it can
executed as a remotely-accessible service that can be reached
a Telnet connection to the BFTP well-known port (152).
allows a user on any Internet host to perform background
transfers without running BFTP locally, but instead opening
Telnet connection to port 152 on a BFTP service host. Of course
a user can also run the local BFTP user interface program
on any host that supports it and for which the user has
privileges
The next section discusses how BFTP uses standard FTP servers
perform the transfers, while the following section covers the
interface of BFTP
2.2 File Transfer Mechanics for
The BFTP makes use of the "third party" or "Server-Server"
incorporated in the Internet File Transfer Protocol [RFC-959].
Thus, the FTC daemon opens FTP control connections to the
FTP servers on source host S and destination host D and
them to transfer the desired file(s) from S to D. The S and
hosts may be any two Internet hosts supporting FTP servers (but
least one of them must support the FTP "PASV" command).
approach allows the implementation of a background file
capability for the entire Internet at a very low cost
Figure 1 illustrates the BFTP model of operation. Note that
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
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
the Internet, it must support all the file types and
modes that are defined in RFC-959, not just a subset
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
pathname containing "wildcard" characters. The reply
contain a list of matching source file names
(2) Execute a separate transfer operation for each file in
list. The destination file name in each case is assumed
be the same as the source file name; this requires that
names be compatible with the naming conventions of D
It will typically be necessary to specify working directories
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
source host S. A more general implementation would acquire
complete list of the file names from the source host and do
matching in the FTC daemon, for example using a regular-
matcher. Another useful extension would be a general pattern
matching file name transformation capability (e.g., like the
included in the 4.3BSD version of FTP) to generate
destination pathnames for multiple requests
DeSchon & Braden [Page 5]
RFC 1068 August 1988
Figure 1 -- BFTP Model of
---------
| BFTP | (telnet) o
Local | Network | <---------------- -|-
User o | Server | / \
-|- ---------
/ \ | |
| |
| |
v
----------- (Submit +---+
| BFTP User | request) |---|
| Interface | ---------> |---|
----------- |---|
. +---+
. /
. /
(foreground . / (try/
request-- . / request
see 2.3) v
-------- +---+
| FTC | -------------> | |
| Daemon | Notify | |
-------- Message +---+
/ \
/ FTP \
/ Control \
/ Connections \
HOST S v v HOST
-------- --------
| FTP | ===========> | FTP |
| Server | file | Server |
-------- transfer --------
DeSchon & Braden [Page 6]
RFC 1068 August 1988
Figure 2 -- Server-Server File
Server FTP BFTP Daemon Server
HOST S HOST C HOST
---------- ----------- ----------
<-------- Open TCP Ctrl
Open TCP Ctrl conn -------->
<-------- (log in
(login confirm.) -------->
(log in) -------->
<-------- (login confirm.)
<-------- TYPE, STRU, MODE,
(confirmations) -------->
TYPE, STRU, MODE, CWD -------->
<-------- (confirmations
<-------- PASV
PASV confirm -------->
PORT command -------->
<-------- PORT
RETR file -------->
<-------- STOR
<------------------------------ Open TCP Data
<------------------------------ Send
<------------------------------ Close Data
<-------- RETR
STOR confirm -------->
<-------- QUIT
QUIT command -------->
Close Ctrl conn -------->
<-------- Close Ctrl
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
support certain commands. For example, if a server does
support the optional command "CWD", the FTC daemon will attempt
construct a complete path name using the source directory name
the source file name. However, it is necessary that at least
of the two hosts support the FTP passive (PASV) command.
many FTP server implementations support do this command, some (
particular, the 4.2BSD FTP) do not. The PASV command
officially listed as being optional in RFC-959.
2.3 Reliable
The reliable delivery function of BFTP is analogous to
delivery in a transport protocol like TCP. Both depend
repeated delivery attempts until success is achieved, and in
cases the choice of the retry interval requires some care
balance overhead against unresponsiveness
Humans are impatient, but even their impatience has a limit.
the file cannot be transferred "soon", a human will turn
another project; typically, there is a tendency for the
to become less urgent the longer the wait. The FTC daemon of
therefore starts each transfer request with a very short
interval -- e.g., 10 minutes -- and then doubles this interval
successive retries, until a maximum interval -- e.g., 4 hours --
is reached. This is essentially the exponential backoff
of the Ethernet, which is also used by transport protocols such
TCP, although BFTP and TCP have quite different rationales for
algorithm
We must also define the meaning of reliable transmission for
multiple-transfer request. For example, the set of files
by wildcard characters in a pathname is not well defined; the
may change while the request is pending, as files are created
deleted. Furthermore, it is unreasonable to regard the
multiple transfer as a single atomic operation. Suppose
transferring a set of files fails part way through; for an
operation, the files which had been successfully transferred
have to be deleted pending the next retry of the entire set.
would be ridiculously inefficient and may be impossible (since
communication path may be broken when it is time to issue
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
name list returned by the first successful NLST command
the request queue entry. This name list determines the
of source files for the transfer; there can be no
additions to the set
* The FTC daemon maintains a transfer status pointer. On
retry cycle, it tries to transfer only those files that
not already been successfully transferred
* The request is complete when all the individual
transfers have been successful, a permanent failure
occured, or when the retry limit is reached
* The notification message to the user lists the status of
of the multiple files
2.4 BFTP User
The purpose of BFTP is to simplify the file transfer process
to place the burden of reliability on the BFTP control host.
have attempted to provide a "user friendly" command interface
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 "?"
the main BFTP prompt ("BFTP>"). Entering "help"
"explain" will provide increasing levels of
material. To obtain information on a particular command, "
" may be entered. The 'quit' or 'exit
command will exit from BFTP. Command and subcommand names may
abbreviated to the shortest unique sequence for that context
alternatively, a partial name can be automatically completed
typing .
The normal procedure for a BFTP user is to set up a set
parameters defining the desired transfer and then submit
request to the FTC daemon. To give the user the
flexibility, BFTP supports three modes of submission
o Background
To request a reliable background file transfer, the user
issue the BFTP 'submit' command to the FTC daemon
DeSchon & Braden [Page 9]
RFC 1068 August 1988
o Foreground Verification, Background
The BFTP 'verify' command may be used to ascertain that
transfer parameters are valid. It causes BFTP to connect
the FTP servers on both the source and the destination
(if possible), log into both, verify the FTP parameters,
verify that the specified source file is present
Once the 'verify' command has successfully completed,
user can issue the 'submit' command to schedule the
file transfer
o Foreground
The BFTP 'transfer' command will perform the
third-party transfer in foreground mode. This is
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
parameters required for most transfers. Certain
parameters must be set with the 'set' command (see Appendix B
details).
When entering any parameter, the following control characters
be used
? will display help text for the parameter, indicating
meaning, the choices, and the default, and then reprompt
the parameter
will display the default value (or the last value set)
this parameter. The user can accept this default by
, or else erase it with Control-W and enter
different value for the parameter, followed by
accept the entered value
will erase the value typed or displayed for
parameter
will accept the value displayed for this parameter,
continue to the next parameter, if any. If the user has
typed a value or used to display the default,
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
information about an earlier request or even to cancel an
request. However, these functions, especially cancellation,
be controlled by some user authentication. We did not want
build a user authentication database with each BFTP instance
require login to BFTP itself, and there is no Internet-wide
authentication mechanism. We adopted the following
authentication mechanism as a compromise
* When the 'submit' command is issued, it prompts the user
a character string called a "keyword", which recorded
the request
* This keyword can be entered later as the argument to a 'find
command, which will display the status of all requests
matching keywords
* Similarly, the keyword may be used to cancel
corresponding request
If two different users happen to choose the same keywords,
course, this scheme will not protect each other's requests
accidental or malicious cancellation. However, a
message will be sent at the time that a cancellation occurs
To make a series of similar requests, the user needs only
change the individual parameters that differ from the
request and then issue a new 'submit' command, for each request
There are commands for individually setting each of the
that 'prompt' sets -- and 'time' -- to provide a shortcut for
experts. A simpler but lengthier procedure is to use the 'prompt
command to run through the current set of parameters,
the parameters that must change and using the
to retain the previous value for each of the others
The same procedures may be used to correct a mistake made
entering a particular parameter
The current settings of all the BFTP parameters can be
at any time with the 'status' command, while the 'clear'
will return all parameters to their initial values. Finally,
'request' command allows the user to save the current set
parameters in a file or to restore the parameters from
previously-saved file
There is also a window-based BFTP user interface for use on a
Workstation, described in Appendix A. The complete list of
commands is presented in Appendix B
DeSchon & Braden [Page 11]
RFC 1068 August 1988
3. Experience and
BFTP has been available to users at ISI for some months. Users
reported a number of advantages of using BFTP
(a) Some users prefer the prompting style of BFTP to the
interface of the foreground FTP they normally use
(b) The BFTP "verify" command allows the user to verify that
names, passwords, and filenames are correct without having
wait for the entire transfer to take place
(c) Since results are returned through the mail system, a
can occur without tying up a terminal line, a phone line,
even a window
BFTP must be able to communicate with a variety of Server-
implementations, and we have observed much variation in the
supported, error handling, and the timing in these servers. Some
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
command. Instead of returning a list of complete path-names
they use an ad hoc format consisting of a directory
followed by a list of files
(3) 4.2/3BSD systems may return a "permanent negative
reply" (a 5xx FTP reply code) as a result of a
failure such as a broken TCP connection. According to RFC-959,
the appropriate response is a "transient negative
reply" (a 4xx FTP reply code), which would inform the BFTP
the transfer should be retried
(4) A number of servers return badly formatted responses.
example of this is the 4.2/3BSD response to an NLST command
a non-existent file name: an error string which is not
by a numerical response code
To diagnose problems that do occur, we have found it very useful
have a complete record of the interchange between the FTC daemon
the two FTP servers. This record is saved and is currently
included in the notification message mailed to the user (see
D for an example). As we get more experience with this program,
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
relatively easy to implement additional user interface programs.
are currently experimenting with a window version of BFTP,
"bftptool", which runs in the SunView environment, and is
in Appendix A. Some additional interfaces that might be useful are
o A command line interface for use in shell scripts
"Makefiles".
o A more general library interface which would make it easy
invoke BFTP from a variety of programs
o Additional full-screen form based interfaces, for example a
running in X-Window system environment
Lastly, BFTP would benefit from the resolution of the following
protocol issues
o There currently exist no provisions for Internet-wide
authentication. In the BFTP context, this means that
required for a file transfer must be present in BFTP
files. The security of these passwords is subject to
limitations of the file system security on the BFTP
host. Anonymous file transfer provides a partial solution,
a more general, long term solution is needed
o Better mechanisms are needed to cope with the diversity of
file systems in the Internet
For example, an extension could be made to the FTP protocol
allow the daemon to learn the delimiter conventions of each
file system. This could allow a more flexible and
multiple-file facility in BFTP. This could include
automatic transfer of directory subtrees, for example
4.
[RFC-959] Postel, J., and J. Reynolds, "File Transfer
(FTP)", RFC-959, USC/Information Sciences Institute
October 1985.
DeSchon & Braden [Page 13]
RFC 1068 August 1988
Appendix A -- BFTP Implementation
BFTP has been implemented on both a Sun workstation running Sun
3.4 (based on 4.2BSD) and a VAX running 4.3BSD. The program
are: the local user interface programs "bftp", the Internet
program "bftpd", and the FTC daemon "fts". BFTP makes use of
"at" command, a UNIX batch job facility, to submit requests
execute the daemon. An additional user interface program,
"bftptool", is available for Sun OS 3.4, and runs in the
environment
BFTP keeps its state in a set of control files: request files
command files, and message files. These files are stored in the
directory specified for the environment of the process
"bftp". If a user is running "bftp" directly, this will typically
the user's home directory. In the case where a user has made
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
"/". Note, however, that under BFTP all user files are written
the FTP servers, which are presumed to enforce the operating systems
access control conventions. Hence, BFTP does not constitute a
integrity exposure
A.1 User Interface
The BFTP user interface program "bftp" may be run directly via
UNIX shell. Once the program has been started, the prompt "BFTP>"
will appear and commands may be entered. These commands
described in detail in Appendix B
A.2 Tool-Style User Interface
The BFTP user interface program "bftptool" may be started from
shell window in the SunView environment on a Sun workstation.
BFTP commands may be selected via the left mouse button.
various file transfer parameters appear in a form-style interface
defaults and multiple-choice style parameter values can be
in via menus. An advantage of this form-style interface
is that it is possible to view all of the file transfer
simultaneously, providing the user with a sense for
parameter values might be mutually exclusive
Help information can be displayed in a text subwindow
positioning the on-screen mouse pointer over a command or
parameter, and clicking the center mouse button. (No
mechanism for displaying help information is currently included
DeSchon & Braden [Page 14]
RFC 1068 August 1988
the SunView package.)
The commands used in the "bftptool" are for the most part
similar to the commands described in Appendix B.
submittal and the execution of the FTC daemon are identical
the "bftp" and the "bftptool" interface programs
A.3 Internet
The Internet server program "bftpd" can be invoked by opening
Telnet connection to a well-known port, and does not
login. The "bftpd" program runs under "inetd", the
BSD4.x well-known port dispatcher. When a SYN arrives for
BFTP well-known port, "bftpd" opens the TCP connection
performs Telnet negotiations. It then passes control to the
interface "bftp" which allows the user to enter file
requests
A.4 BFTP Server
The BFTP file transfer control daemon program is named "fts" (
"File Transfer Service"). This module contains code to
cause a single file transfer operation using the FTP server-
model as shown in Figures 1 and 2. It is invoked with the
"fts ". The contains the
parameters for the file transfer, in ASCII format, separated
linefeeds. Such a request file may be created by the
interface program, "bftp".
As a byproduct of the development of BFTP, "fts" represents
server-server FTP driver that can be run independent of the "bftp
program. Parameters used in the file transfer are read from
request file, which is created and accessed via library
which can be shared between modules. This could be used
perform FTP's under program control
DeSchon & Braden [Page 15]
RFC 1068 August 1988
Appendix B: BFTP Command
B.1 Special Editing
In the "bftp" program, the special editing characters for
words, subcommands, and parameter fields are as follows
Accept current command/field
Complete current command/field, or display default
Complete and delimit current command
Erase last character
control-L Refresh screen
control-R Refresh line
control-U Erase line
control-W Erase current token
? List legal options
B.2 BFTP
The remainder of Appendix B consists of a list of the
commands. Each command should be followed by a carriage-return
In the description of the syntax for each command, square
"[]" are used to indicate a ssubcommand, or a list of
subcommands, which are separated by the "|" character.
brackets "<>" are used to indicate a description of a
where the choices would be too numerous to list, for
"".
B.2.1 Clear
Return all parameters to their default values
B.2.2 Destination
Set the destination directory
ddir <directory name
Set the destination file name
dfile
Set the destination host, user, and password
dhost <password
DeSchon & Braden [Page 16]
RFC 1068 August 1988
B.2.3 Explain
Display a short explanation of how to use BFTP
B.2.4 Find
Find and display a previous request
BFTP will prompt for the request id, which is printed when
request is first submitted. An example of a request id
"bftp583101774". BFTP also prompts for the request keyword,
was determined by the user when the request was first submitted
If no keyword was specified, a should be typed. If
request id is entered, BFTP will display all requests
contain a matching keyword
RequestID (optional):
RequestKeyword:
After BFTP has displayed a summary of a matching request, it
whether the request is to be changed, or canceled
Do you wish to change this request? [yes | no
Do you wish to cancel this request? [yes | no
If the user indicates that the request is to be changed, BFTP
read in the parameters and cancel the existing request. At
point the user may make any desired changes and use the "submit
command to requeue the request. At this point a new request
will be assigned and displayed
DeSchon & Braden [Page 17]
RFC 1068 August 1988
Although this may happen extremely rarely, if at all, it
possible that a system crash (or the interruption of the
program) at a particularly inopportune moment may leave a
which is not queued. When the "find" command locates such
request, it displays the warning
Your request is NOT currently queued
If this happens, the request may be read in and resubmitted
the following procedure
Your request is NOT currently queued
Do you wish to change this request?
(BFTP displays the parameters that have been read in.)
Previous request canceled
Use the 'submit' command to submit a new request
B.2.5 Help
Print local help information
help
B.2.6 Quit
Clear parameters and exit the BFTP program
B.2.7 Prompt
Prompt for commonly-used parameters
DeSchon & Braden [Page 18]
RFC 1068 August 1988
The following are the parameters that BFTP prompts for
copy/move/delete: [copy | move | delete
ascii/ebcdic/image/local
[ascii|ebcdic] [nonprint|telnet|carriage-control
[image
[local]
(see "set type" for additional information
Source --
Host:
User:
Password: <password
Dir: <directory including a delimiter, e.g., "/" or ">">
(either an absolute path, or relative to the login
File:
Destination --
Host:
User:
Password: <password
Dir: <directory
File:
Once the prompting has been completed, the current values of
parameters will be displayed. Parameters not mentioned in
prompting will be initialized with default values, and may
changed via the "set" commands
DeSchon & Braden [Page 19]
RFC 1068 August 1988
B.2.8 Request
The request commands enable the user to save a set of
parameters in a "request-file" for future use. Subcommands
provided to to list all available request-files, or to read
write, or delete a request-file. All request-files are stored
the user's home directory. Therefore, this facility is
available when the user is accessing BFTP by telneting to
152.
Delete request file "bftp-save.name".
request delete
List all bftp-save files
request
Read a request file in as the current request
request load
Save the current request in a file named "bftp-save.name".
request store
B.2.9 Set
The "set" commands have complex subcommand structures and are
to set many of the less commonly used FTP parameters.
subcommands of "set" are as follows
Set the account for the source/destination login
set account [source | destination]
Set to true to append to destination file
set append [true | false
The source file will be copied to the destination file name
set
The source file will be deleted after the file has been moved
copied
set
DeSchon & Braden [Page 20]
RFC 1068 August 1988
Set the mailbox to which the results will be returned.
mailbox should be in standard internet format, for example
"deschon@isi.edu".
set mailbox
Set the FTP transfer mode
set mode [stream | block | compress
The source file will be deleted after it has been copied
set
Set to true to transfer multiple files
set multiple [true | false
Set the port for the source/destination FTP connection
set port [source | destination]
Set the FTP structure
set structure [file | record | page
Set the FTP type and format / byte size parameters. Note that
normal text file is usually "ascii", and a "binary" file is
the same as an "image" file
set type [ascii|ebcdic] [nonprint|telnet|carriage-control
set type [image
set type [local]
Set to true if the STOU command is to be used. If the
command is supported by the destination host, the file will
stored into a file having a unique file name
set unique [true | false
Set to true to display full FTP conversations for "verify"
"transfer" commands
set verbose [true | false
DeSchon & Braden [Page 21]
RFC 1068 August 1988
B.2.10 Source
Set the source directory
sdir <directory name
Set the source file name
sfile
Set the source host, user, and password
shost <password
B.2.11 Status
Display the current parameter values
B.2.12 Submit
Submit the current request for background FTP
BFTP prompts for the following information
StartTime:
ReturnMailbox: <internet mailbox
RequestKeyword:
B.2.13 Time
Set the start time, the starting retry interval, and the
number of tries
time
B.2.14 Transfer
Perform the current request in the foreground
DeSchon & Braden [Page 22]
RFC 1068 August 1988
B.2.15 Verify
Make the connections now to check parameters
DeSchon & Braden [Page 23]
RFC 1068 August 1988
Appendix C: Example BFTP User
deschon.isi.edu 1% telnet hobgoblin.isi.edu 152
Trying 128.9.0.42 ...
Connected to hobgoblin.isi.edu
Escape character is '^]'.
BFTP Server (hobgoblin.isi.edu
Background File Transfer: For help, type '?', 'help', or 'explain'.
BFTP>
Copy/Move/Delete:
Source --
Host: deschon.isi.
User:
Password
Dir: ./
File: foo
Destination --
Host: venera.isi.
User:
Password
Dir: ./temp
File: foo
StartTime: Tue Oct 6 10:14:43 1987 (interval) 60 (tries) 5
ReturnMailbox: deschon@isi.
RequestPassword
BFTP> set multiple
BFTP>
Request type:
Source --
Host: 'deschon.isi.edu
User: 'deschon
Pass:
Acct: ''
Dir: './'
File: 'foo*'
Port: 21
Destination --
Host: 'venera.isi.edu
DeSchon & Braden [Page 24]
RFC 1068 August 1988
User: 'deschon
Pass:
Acct: ''
Dir: './temp/'
File:'foo*'
Port: 21
Structure: file, Mode: stream, Type: ascii, Format:
Multiple matching:
Return mailbox: 'deschon@isi.edu', Password:
Remaining tries: 5, Retry interval: 60
Start after Tue Oct 6 10:14:43 1987.
BFTP>
Checking parameters...
Request bftp560538880 submitted to run at 10:14 Oct 6.
BFTP>
Connection closed by foreign host
deschon.isi.edu 2%
DeSchon & Braden [Page 25]
RFC 1068 August 1988
Appendix D: Sample BFTP Notification
Received-Date: Tue, 6 Oct 87 10:15:52
Date: Tue, 6 Oct 87 10:15:47
From: root (Operator
Posted-Date: Tue, 6 Oct 87 10:15:47
To:
Subject: BFTP Results: bftp560538880
Request bftp560538880 submitted to run at 10:14 Oct 6.
Tue Oct 6 10:15:22 1987: starting...
Request type:
Source: deschon.isi.edu-deschon-XXX--21-./-foo
Destination: venera.isi.edu-deschon-XXX--21-./temp/-
Stru: F, Mode: S, Type: A N, Creation:
Multiple matching:
Return mailbox: 'deschon@isi.edu', Password:
Remaining tries: 5, Retry interval: 60
Connect to: deschon.isi.edu, 21
deschon.isi.edu ==> 220 deschon.isi.edu FTP server (Version 4.7
Sun Sep 14 12:44:57 PDT 1986) ready
Connect to: venera.isi.edu, 21
venera.isi.edu ==> 220 venera.isi.edu FTP server (Version 4.107
Thu Mar 19 20:54:37 PST 1987) ready
deschon.isi.edu <== USER
deschon.isi.edu ==> 331 Password required for deschon
deschon.isi.edu <== PASS
deschon.isi.edu ==> 230 User deschon logged in
venera.isi.edu <== USER
venera.isi.edu ==> 331 Password required for deschon
venera.isi.edu <== PASS
venera.isi.edu ==> 230 User deschon logged in
deschon.isi.edu <== CWD ./
deschon.isi.edu ==> 200 CWD command okay
venera.isi.edu <== CWD ./temp
venera.isi.edu ==> 250 CWD command successful
deschon.isi.edu <== PORT 128,9,1,56,4,106
deschon.isi.edu ==> 200 PORT command okay
deschon.isi.edu <== NLST foo
deschon.isi.edu ==> 150 Opening data connection for /bin/
(128.9.1.56,1130) (0 bytes).
deschon.isi.edu ==> 226 Transfer complete
deschon.isi.edu <==
deschon.isi.edu ==> 502 PASV command not implemented
venera.isi.edu <==
DeSchon & Braden [Page 26]
RFC 1068 August 1988
venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,200)
deschon.isi.edu <== PORT 128,9,0,32,6,200
deschon.isi.edu ==> 200 PORT command okay
deschon.isi.edu <== RETR
venera.isi.edu <== STOR
deschon.isi.edu ==> 150 Opening data connection for
(128.9.0.32,1736) (0 bytes).
deschon.isi.edu ==> 226 Transfer complete
venera.isi.edu ==> 150 Openning data connection for
(128.9.1.56,20).
venera.isi.edu ==> 226 Transfer complete
venera.isi.edu <==
venera.isi.edu ==> 227 Entering Passive Mode (128,9,0,32,6,201)
deschon.isi.edu <== PORT 128,9,0,32,6,201
deschon.isi.edu ==> 200 PORT command okay
deschon.isi.edu <== RETR foo
venera.isi.edu <== STOR foo
deschon.isi.edu ==> 150 Opening data connection for foo
(128.9.0.32,1737) (4 bytes).
deschon.isi.edu ==> 226 Transfer complete
venera.isi.edu ==> 150 Openning data connection for foo
(128.9.1.56,20).
venera.isi.edu ==> 226 Transfer complete
deschon.isi.edu <==
venera.isi.edu <==
Tue Oct 6 10:15:39 1987: completed successfully
DeSchon & Braden [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
