RFC 1068
Background File Transfer Program (BFTP)
Background File Transfer Program (BFTP) 💖
okay bestie, let's start with the header stuff 🎀 This is RFC 1068, from the Network Working Group, and it's dated August 1988. The authors are A. DeSchon and R. Braden, both at ISI. The header doesn't list a category, and it doesn't say this RFC obsoletes or updates anything 🌸
Status of This Memo 📜
okay so this memo describes an Internet background file transfer service that's built on the third-party transfer model of FTP 🦋 no new protocols are involved, ngl. the whole point is to get people talking about new Internet service modes 💬 and distribution of this memo is unlimited ✨
1. Introduction 💅
okay so for a bunch of reasons, file transfer on the Internet has usually been an interactive or "foreground" service 💖 like, you run your local FTP user interface program as a command and ask for a transfer to happen in real time. if the transfer doesn't finish for any reason, the user must reissue the transfer request 😭 foreground transfer is pretty simple to build (no fancy queuing or stable storage needed), and in the early days of networking it was honestly iconic, because the Internet/ARPANET was lightly loaded and reasonably reliable ✨
but lately the Internet is giving congestion and long delays 💀 especially at peak usage times. and as more of the world gets interconnected, planned and unplanned outages of hosts, gateways, and networks can make it really hard to transfer files in the foreground 🙈
doing the transfer asynchronously (aka in the "background") solves some of these problems 🧚 because a human doesn't have to be directly involved at the moment the transfer happens. a background service needs two pieces: a user interface program to collect the parameters describing the transfer(s), and a file transfer control (FTC) daemon to actually carry them out 🎀
background file transfer has a bunch of potential perks for a user:
- 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).
- End-to-end Reliability 🔁: the FTC daemon can try a transfer repeatedly until it either succeeds or fails permanently. this gives reliable end-to-end delivery of a file, even if the source or destination host is down or has poor Internet connectivity for some time period.
- 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 a multiple file transfer capability for all hosts. this kind of facility is suggested in RFC-959 (see the description of "NLST") and implemented in some User-FTP programs.
- 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.
heads up, there's a serious human-engineering problem with background transfer 🚨 if the user messes up entering a parameter, the mistake may not show up until much later, and that can be super frustrating 😤 to avoid this, the user interface program ought to verify as many parameters as possible when they're entered. obviously that foreground check isn't possible if the remote host the parameters apply to is currently unreachable 🙃
so to test whether background transfer is actually useful on today's Internet, we built a file-mover service and called it the Background File Transfer Program, or BFTP 🌈
Section 2 describes BFTP, Section 3 shares our experience and conclusions 📝 and the appendices have the deets: the user interface language for BFTP, how the program is organized, and sample execution scripts 🍓
2. Background File Transfer Program 🦋
2.1 General Model
in the current BFTP design, the user interface program and the FTC daemon program must execute on the same host, and we call that the BFTP control host 🏠
through the user interface program, a BFTP user supplies all the parameters needed to transfer a file from source host S to destination host D 💌 (S and D may be different from the BFTP control host!). the parameters include:
- S and D host names,
- login names and passwords on S and D hosts, and
- S and D file names (and optionally, directories).
the user may also set a bunch 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).
last step: the user gives a mailbox for the completion notification, and "submits" the request to the FTC daemon queue 📬 then they can close the BFTP user interface program and chill ✨
if the transfer fails permanently, the FTC daemon sends a notification message to the user's mailbox. if it's a temporary failure (e.g., a broken TCP connection), the FTC daemon logs the failure and retries the transfer after some timeout period. the retry cycles keep going until the transfer succeeds or until some maximum number of tries has been reached. either way, a notification message is then sent to the user's mailbox 📩
the user can check on progress by reentering the BFTP user interface program, supplying a key that was defined with the request, and displaying the current status of the request. then the user may cancel the request or leave it in the queue 👀
the BFTP program includes a server-Telnet module, so it can run as a remotely-accessible service that you reach with a Telnet connection to the BFTP well-known port (152) 🌐 this lets a user on any Internet host do background file transfers without running BFTP locally. they just open 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 they have login privileges 💜
the next section talks about how BFTP uses standard FTP servers to do the transfers, and the following section covers the BFTP user interface 🧁
2.2 File Transfer Mechanics for BFTP
BFTP makes use of the "third party" or "Server-Server" model built into the Internet File Transfer Protocol [RFC-959] 🤝 so the FTC daemon opens FTP control connections to the existing FTP servers on source host S and destination host D, and tells them to transfer the desired file(s) from S to D. S and D can be any two Internet hosts running FTP servers (but at least one of them must support the FTP PASV command). this approach makes a background file transfer capability for the entire Internet super cheap to build 🫶
Figure 1 illustrates the BFTP model of operation. note that the BFTP control host isn't necessarily the same as S or D. Figure 2 illustrates the FTP command interchange used in a typical Server-Server file transfer operation, and you may compare it with the User-Server FTP scenario in Section 7 of RFC-959 👑
since BFTP may be asked to transfer files between any two hosts on the Internet, it must support all the file types and transfer modes defined in RFC-959, not just a subset that particular hosts happen to implement 💅
BFTP supports transferring a set of files in a single request, using the standard technique:
- send an
NLSTcommand to the source host S, specifying a pathname containing "wildcard" characters. the reply contains a list of matching source file names. - 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, which means these names have to be compatible with the naming conventions of D 🍓
it'll typically be necessary to specify working directories for the transfers at S and D, so the file names end up being simple, unstructured names on each system 📂
this approach depends on the wildcard matching capability of the source host S. a more general implementation would grab a complete list of file names from the source host and do the matching in the FTC daemon, for example with a regular-expression matcher. another useful extension would be a general pattern-matching file name transformation capability (e.g., like the one in the 4.3BSD version of FTP) to generate appropriate destination pathnames for multiple requests 🧚♀️
Figure 1 -- BFTP Model of OperationOkay so bestie, here's the big picture 🦋 Figure 2 is the server-to-server setup. The BFTP daemon runs the show while the two FTP servers do the actual copying with each other. Look at all those arrows 😭
--------- 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 --------
Figure 2 -- Server-Server File TransferAnd here's the play-by-play of who talks to who, bestie 🧚 Every line is a message going one way or the other, so read it top to bottom like a group chat ✨
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 -------->
<-------- Close Ctrl connBFTP currently uses these Server-FTP commands [RFC-959]: USER, PASS, ACCT, PASV, PORT, RETR, STOR, STOU, CWD, NLST, MODE, STRU, TYPE, and QUIT. That's the whole menu 💜
The FTC daemon tries to work around FTP servers that can't handle certain commands 🙈 For example, if a server doesn't support the optional command CWD, the FTC daemon will try to build a complete path name from the source directory name and the source file name. It is necessary that at least one of the two hosts support the FTP passive (PASV) command, though. Lots of FTP server implementations support this command, but some (in particular, the 4.2BSD FTP) do not. The PASV command was officially listed as optional in RFC-959, so this is the sneaky gotcha 💀
2.3 Reliable Delivery 🔁
Reliable delivery in BFTP is basically the cousin of reliable delivery in a transport protocol like TCP 🫶 Both keep trying again and again until it works, and in both cases picking the retry interval takes some care, because you have to balance overhead against being unresponsive.
Humans are impatient, but even their impatience has a limit 😤 If the file can't be transferred "soon," a human will turn to another project. The longer the wait, the less urgent the transfer tends to feel. So the FTC daemon starts each transfer request with a very short retry interval (e.g., 10 minutes) and then doubles that interval for each successive retry, until it hits a maximum interval (e.g., 4 hours). This is essentially the exponential backoff algorithm of the Ethernet, which transport protocols like TCP also use, although BFTP and TCP have quite different rationales for it 🌸
We also have to define what reliable transmission means for a multiple-transfer request 👀 For example, the set of files picked out by wildcard characters in a pathname isn't well defined, because the set can change while the request is pending as files get created and deleted. Plus, it's unreasonable to treat the whole multiple transfer as one atomic operation. Say transferring a set of files fails part way through. For an atomic operation, the files that already transferred successfully would have to be deleted until the whole set gets retried. That would be ridiculously inefficient, and it might even be impossible, since the communication path may be broken by the time it's time to issue the deletion requests 🙃
BFTP handles all of this in the following way:
- For a multiple file operation, the FTC daemon saves the file name list returned by the first successful
NLSTcommand in the request queue entry. This name list determines the set of source files for the transfer, and 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 occurred, or 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 whole point of BFTP is to make the file transfer process simpler and to put the burden of reliability on the BFTP control host 🎀 We tried to make a "user friendly" command interface, kind of like the vibe of the TOPS-20 operating system. It comes with extensive prompting, defaulting, and help facilities for every command, so no one's left confused 🌈
For a list of all BFTP commands, enter ?<Return> at the main BFTP prompt (BFTP>). Entering help<Return> and explain<Return> gives you increasing levels of explanation. To learn about one particular command, enter help <command name><Return>. The quit or exit command exits BFTP. You can abbreviate command and subcommand names down to the shortest unique sequence for that context, or just type <Return> to automatically complete a partial name 🧠
The normal move is to set up the parameters for the transfer you want and then submit the request to the FTC daemon. To give users maximum flexibility, BFTP supports three modes of submission:
- Background Operation: To request a reliable background file transfer, the user issues the BFTP
submitcommand to the FTC daemon 🌙 - Foreground Verification, Background Operation: The BFTP
verifycommand checks that the file transfer parameters are valid. It makes BFTP 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. Onceverifyhas successfully completed, the user can issue thesubmitcommand to schedule the actual file transfer 🔍 - Foreground Operation: The BFTP
transfercommand performs the specified third-party transfer in foreground mode. This is the dotted path that bypasses the queue in Figure 1 🏃♀️
The easiest way to set up the parameters is the prompt command, which asks the user for all of the basic parameters needed for most transfers. Certain unusual parameters have to be set with the set command (see Appendix B for details) 📝
When you're entering any parameter, these control characters can help you out:
?displays help text for the parameter, showing its meaning, the choices, and the default, then reprompts you for the parameter 💡<ESC>displays the default value (or the last value you set) for this parameter. You can accept that default by pressing<Return>, or erase it with Control-W and type a different value, followed by<Return>to accept it 🫧<Control-W>erases the value typed or displayed for the current parameter 🧽<Return>accepts the value displayed for this parameter and moves on to the next parameter, if there is one. If you haven't typed a value or used<ESC>to display the default,<Return>will display the default and then accept it 🍓
Now the security-ish part, which is kind of a big deal 🔐 It's important to give a user a way to check the status of an earlier request, or even cancel one. But those functions, especially cancellation, have to be controlled by some user authentication. We didn't want to build a user authentication database into each BFTP instance or require a login to BFTP itself, and there's no Internet-wide user authentication mechanism. So we went with this weak authentication mechanism as a compromise:
- When the
submitcommand is issued, it prompts the user for a character string called a "keyword," which is recorded with the request 🗝️ - That keyword can be entered later as the argument to a
findcommand, which displays the status of all requests with matching keywords 🔎 - The keyword can also be used to cancel the corresponding request 🚫
If two different users happen to pick the same keywords, this scheme obviously won't protect each other's requests from accidental or malicious cancellation 😬 However, a notification message will be sent at the time a cancellation occurs, so nobody gets blindsided 💜
To make a series of similar requests, you only change the parameters that are different from the last one, then type a fresh submit command for each request 💅✨. For the BFTP experts there are commands for setting each parameter that prompt asks about individually (plus time), so you get a total shortcut 🚀. The longer but still chill option is to run prompt through the whole current set, retyping whatever needs to change and hitting <ESC><return> to keep the old value for everything else 🌸. The same moves work if you fat-fingered a parameter and need to fix it 🙈.
You can check every current BFTP setting any time with status 👀. clear resets everything back to the initial values 🧹. And request lets you save your current set of parameters to a file or restore them from one you saved before 💾.
There's also a window-based BFTP interface for a Sun Workstation, described in Appendix A 🪟, and the complete list of BFTP commands is in Appendix B 📜.
3. Experience and Conclusions ✨
BFTP has been available to users at ISI for some months 🏫. Users have reported some seriously good perks:
- (a) Some users prefer the prompting style of BFTP to the interface of the foreground FTP they normally use 💖.
- (b) The BFTP "verify" command lets you check that host names, passwords, and filenames are correct without waiting for the entire transfer to happen 🙌.
- (c) Since results come back through the mail system, a transfer can happen 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 honestly? We've seen a lot of variation in the commands they support, their error handling, and their timing 😭. Some of the problems we ran into 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 made of a directory name followed by a list of files 📂.
- (3) 4.2/3BSD systems may return a "permanent negative completion reply" (a
5xxFTP reply code) as a result of a communications failure, like a broken TCP connection 💀. According to RFC-959, the appropriate response is a "transient negative completion reply" (a4xxFTP reply code), which would tell BFTP that the transfer should be retried 🔁. - (4) A number of servers return badly formatted responses 🤡. An example is the 4.2/3BSD response to an NLST command for a non-existent file name: an error string that isn't preceded by a numerical response code 🙃.
To diagnose problems that do pop up, we've found it super 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 📝.
The use of library routines shared between modules makes it relatively easy to implement additional user interface programs 🧩. We're 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:
- A command line interface for use in shell scripts and "Makefiles" 🐚.
- A more general library interface which would make it easy to invoke BFTP from a variety of programs 🧰.
- Additional full-screen form based interfaces, for example a tool running in an X-Window system environment 🖥️.
Lastly, BFTP would benefit from the resolution of the following open protocol issues:
- 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 🔐.
- 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.
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 🛡️.
A.1 User Interface Program
The BFTP user interface program bftp may be run directly via a UNIX shell 🐚. Once the program has been started, the prompt BFTP> will appear and commands may be entered 💬. These commands are described in detail in Appendix B 📖.
A.2 Tool-Style User Interface Program
The BFTP user interface program bftptool may be started from a shell window in the SunView environment on a Sun workstation. The BFTP commands may be selected via the left mouse button 🖱️. The various file transfer parameters appear in a form-style interface; defaults and multiple-choice style parameter values can be filled in via menus 📋. An advantage of this form-style interface program is that it is possible to view all of the file transfer parameters simultaneously, providing the user with a sense for which parameter values might be mutually exclusive 👀.
Help information can be displayed in a text subwindow by positioning the on-screen mouse pointer over a command or a parameter, and clicking the center mouse button 🆘. (No standard mechanism for displaying help information is currently included in the SunView package.) 🤷♀️
The commands used in the bftptool are for the most part very similar to the commands described in Appendix B. Request submittal and the execution of the FTC daemon are identical for the bftp and the bftptool interface programs 🔁.
A.3 Internet Server
The Internet server program bftpd can be invoked by opening a Telnet connection to a well-known port, and does not require login 🔌. The bftpd program runs under inetd, the standard BSD4.x well-known port dispatcher. When a SYN arrives for the BFTP well-known port, bftpd opens the TCP connection and performs Telnet negotiations. It then passes control to the user interface bftp, which allows the user to enter file transfer requests 🎉.
A.4 BFTP Server Daemon
The BFTP file transfer control daemon program is named fts (for "File Transfer Service") 🧠. This module contains code to actually cause a single file transfer operation using the FTP server-server model as shown in Figures 1 and 2 📊. It is invoked with the command fts <request-file>. The <request-file> contains the necessary parameters for the file transfer, in ASCII format, separated by linefeeds. Such a request file may be created by the user interface program, bftp 📝.
As a byproduct of the development of BFTP, fts represents a server-server FTP driver that can be run independent of the bftp program. Parameters used in the file transfer are read from a request file, which is created and accessed via library routines which can be shared between modules. This could be used to perform FTP's under program control 🎀.
Appendix B: BFTP Command Summary 💅
B.1 Special Editing Characters 🎀
Okay so in the "bftp" program, these are the special editing keys for command words, subcommands, and parameter fields:
<return> Accept current command/field.
<escape> Complete current command/field, or display default.
<space> Complete and delimit current command.
<delete> 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 Commands 🦋
The rest of Appendix B is a list of the BFTP commands. Each command should be followed by a carriage-return. In the syntax for each command, square brackets [] mark a subcommand or a list of possible subcommands, separated by the | character. Angle brackets <> describe a parameter when the choices would be too numerous to list, like <host name/number>. 💖
B.2.1 Clear Command 🧹
Return all parameters to their default values.
clearB.2.2 Destination Commands 📍
Set the destination directory.
ddir <directory name>Set the destination file name.
dfile <file name>Set the destination host, user, and password.
dhost <host name/number> <login> <password>B.2.3 Explain Command 🤓
Display a short explanation of how to use BFTP.
explainB.2.4 Find Command 🔍
Find and display a previous request.
findBFTP will prompt for the request id, which is printed when the request is first submitted. An example of a request id is bftp583101774. BFTP also prompts for the request keyword, which the user picked when the request was first submitted. If no keyword was specified, a <CR> should be typed. If no request id is entered, BFTP will display all requests which contain a matching keyword. 🫶
RequestID (optional): <bftp-request-id>
RequestKeyword: <keyword>After BFTP has displayed a summary of a matching request, it asks 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 says the request is to be changed, BFTP will read in the parameters and cancel the existing request. Then the user can make any desired changes and use the "submit" command to requeue the request. At this point a new request id will be assigned and displayed. ✨
Although this may happen extremely rarely, if at all, it is possible that a system crash (or the interruption of the BFTP program) at a particularly inopportune moment may leave a request which is not queued. When the "find" command locates such a request, it displays the warning:
Your request is NOT currently queued.If this happens, the request may be read in and resubmitted using the following procedure: 🙈
Your request is NOT currently queued.
Do you wish to change this request? yes
(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 Command 🆘
Print local help information.
help
help <command>B.2.6 Quit Command 👋
Clear parameters and exit the BFTP program.
quitB.2.7 Prompt Command 💬
Prompt for commonly-used parameters.
promptThe following are the parameters that BFTP prompts for: 🌸
copy/move/delete: [copy | move | delete]
ascii/ebcdic/image/local:
[ascii|ebcdic] [nonprint|telnet|carriage-control]
or
[image]
or
[local] <byte size>
(see "set type" for additional information)
Source --
Host: <host name/number>
User: <login>
Password: <password>
Dir: <directory including a delimiter, e.g., "/" or ">">
(either an absolute path, or relative to the login)
File: <file name>
Destination --
Host: <host name/number>
User: <login>
Password: <password>
Dir: <directory>
File: <file name>Once the prompting has been completed, the current values of all parameters will be displayed. Parameters not mentioned in the prompting will be initialized with default values, and may be changed via the "set" commands. 🧁
B.2.8 Request Commands 📁
The request commands let the user save a set of BFTP parameters in a "request-file" for future use. Subcommands are provided to list all available request-files, or to read, write, or delete a request-file. All request-files are stored in the user's home directory. So this facility is not available when the user is accessing BFTP by telneting to port 152. 🥺
Delete request file "bftp-save.name".
request delete <name>List all bftp-save files.
request listRead a request file in as the current request.
request load <name>Save the current request in a file named "bftp-save.name".
request store <name>B.2.9 Set Commands ⚙️
The "set" commands have complex subcommand structures and are used to set many of the less commonly used FTP parameters. The subcommands of "set" are as follows: 🧠
Set the account for the source/destination login.
set account [source | destination] <account string>Set to true to append to destination file.
set append [true | false]The source file will be copied to the destination file name.
set copyThe source file will be deleted after the file has been moved or copied.
set deleteSet the mailbox to which the results will be returned. The mailbox should be in standard internet format, for example: "deschon@isi.edu".
set mailbox <mailbox string>Set the FTP transfer mode.
set mode [stream | block | compress]The source file will be deleted after it has been copied.
set moveSet to true to transfer multiple files.
set multiple [true | false]Set the port for the source/destination FTP connection.
set port [source | destination] <port number>Set the FTP structure.
set structure [file | record | page]Set the FTP type and format / byte size parameters. Note that a normal text file is usually "ascii", and a "binary" file is often the same as an "image" file.
set type [ascii|ebcdic] [nonprint|telnet|carriage-control]
or
set type [image]
or
set type [local] <byte size>Set to true if the STOU command is to be used. If the STOU command is supported by the destination host, the file will be stored into a file having a unique file name.
set unique [true | false]Set to true to display full FTP conversations for "verify" and "transfer" commands.
set verbose [true | false]B.2.10 Source Commands 🎯
Set the source directory.
sdir <directory name>Set the source file name.
sfile <file name>Set the source host, user, and password.
shost <host name/number> <login> <password>B.2.11 Status Command 📊
Display the current parameter values.
statusB.2.12 Submit Command 🚀
Submit the current request for background FTP.
submitBFTP prompts for the following information: 🎀
StartTime: <date and/or time>
ReturnMailbox: <internet mailbox>
RequestKeyword: <made-up keyword>B.2.13 Time Command ⏰
Set the start time, the starting retry interval, and the maximum number of tries.
time <date and/or time> <minutes between tries>
<maximum number of tries>B.2.14 Transfer Command 🏃♀️
Perform the current request in the foreground.
transferB.2.15 Verify Command ✅
Make the connections now to check parameters.
verifyAppendix C: Example BFTP User Script 🎬
Here's the whole thing in action, start to finish, so you can see how the commands actually flow together. 🧚
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> prompt
Copy/Move/Delete: copy
Source --
Host: deschon.isi.edu
User: deschon
Password:
Dir: ./
File: foo*
Destination --
Host: venera.isi.edu
User: deschon
Password:
Dir: ./temp/
File: foo*
StartTime: Tue Oct 6 10:14:43 1987 (interval) 60 (tries) 5
ReturnMailbox: deschon@isi.edu
RequestPassword:
BFTP> set multiple true
BFTP> status
Request type: COPY
Source --
Host: 'deschon.isi.edu'
User: 'deschon'
Pass: SET
Acct: ''
Dir: './'
File: 'foo*'
Port: 21
Destination --
Host: 'venera.isi.edu'
User: 'deschon'
Pass: SET
Acct: ''
Dir: './temp/'
File:'foo*'
Port: 21
Structure: file, Mode: stream, Type: ascii, Format: nonprint
Multiple matching: TRUE
Return mailbox: 'deschon@isi.edu', Password: SET
Remaining tries: 5, Retry interval: 60 minutes
Start after Tue Oct 6 10:14:43 1987.
BFTP> submit
Checking parameters...
Request bftp560538880 submitted to run at 10:14 Oct 6.
BFTP> quit
bye
Connection closed by foreign host.
deschon.isi.edu 2%Appendix D: Sample BFTP Notification Message ✨
okay so this is the sample results notification 💌 the one that lands in the mailbox after a BFTP request runs. the header lines come first, then the step-by-step log of every connection, command, and reply, and it ends with a "completed successfully" line 🎀
Received-Date: Tue, 6 Oct 87 10:15:52 PDT
Date: Tue, 6 Oct 87 10:15:47 PDT
From: root (Operator)
Posted-Date: Tue, 6 Oct 87 10:15:47 PDT
To: deschon
Subject: BFTP Results: bftp560538880
Request bftp560538880 submitted to run at 10:14 Oct 6.
Tue Oct 6 10:15:22 1987: starting...
Request type: COPY
Source: deschon.isi.edu-deschon-XXX--21-./-foo*
Destination: venera.isi.edu-deschon-XXX--21-./temp/-
Stru: F, Mode: S, Type: A N, Creation: STOR
Multiple matching: TRUE
Return mailbox: 'deschon@isi.edu', Password: SET
Remaining tries: 5, Retry interval: 60 minutes
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
deschon.isi.edu ==> 331 Password required for deschon.
deschon.isi.edu <== PASS XXX
deschon.isi.edu ==> 230 User deschon logged in.
venera.isi.edu <== USER deschon
venera.isi.edu ==> 331 Password required for deschon.
venera.isi.edu <== PASS XXX
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/ls
(128.9.1.56,1130) (0 bytes).
deschon.isi.edu ==> 226 Transfer complete.
deschon.isi.edu <== PASV
deschon.isi.edu ==> 502 PASV command not implemented.
venera.isi.edu <== PASV
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 foo
venera.isi.edu <== STOR foo
deschon.isi.edu ==> 150 Opening data connection for foo
(128.9.0.32,1736) (0 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.
venera.isi.edu <== PASV
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 foo1
venera.isi.edu <== STOR foo1
deschon.isi.edu ==> 150 Opening data connection for foo1
(128.9.0.32,1737) (4 bytes).
deschon.isi.edu ==> 226 Transfer complete.
venera.isi.edu ==> 150 Openning data connection for foo1
(128.9.1.56,20).
venera.isi.edu ==> 226 Transfer complete.
deschon.isi.edu <== QUIT
venera.isi.edu <== QUIT
Tue Oct 6 10:15:39 1987: completed successfully.📦 where this page comes from
- ietf: rfc1068 1988-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms