FTP server-server interaction - II
A proposal for FTP servers to establish a direct data connection.
Bressler, R.D. and R. Thomas, "FTP server-server interaction - II", RFC 478, DOI 10.17487/RFC0478, March 1973, <https://www.rfc-editor.org/info/rfc478>.
@misc{rfc478,
series = {Request for Comments},
number = 478,
howpublished = {RFC 478},
publisher = {RFC Editor},
doi = {10.17487/RFC0478},
url = {https://www.rfc-editor.org/info/rfc478},
author = {R.D. Bressler and R. Thomas},
title = {{FTP server-server interaction - II}},
pagetotal = 2,
year = 1973,
month = mar,
} RFC text
Network Working Group B. Bressler
Request for Comments: 478 B. Thomas
NIC: 14947 BBN
26 March 1973
FTP Server-Server Interaction-II
At the recent FTP meeting at BBN in Cambridge, one of the topics
discussed was that of server-server interaction. In a typical
situation a user (A) conversing with two servers (B,C) is interested
in retrieving a file from one site (B) and sending it to the other
(C).
+------+
| USER |
| A |
/+------+\
control control
/ \
+------+ +------+
|SERVER| DATA |SERVER|
| B |----------->| C |
+------+ +------+
The consensus of the meeting was that mechanisms were necessary to
make B and C aware of each other and to allow a data connection to be
established without forcing each other to queue RFCs for local
sockets before they exist.
The proposed solution to this problem was a command called PASSIVE
(PASV?). The following is our conclusion as to the meaning of the
command and how it would be used.
Third party connections would be established using the SOCK command,
which says "Be prepared to use socket S at Host H to establish your
data connection", and the PASV command which says "open your data
socket for listening, and upon receipt of a transfer command wait for
an RFC rather than initiating one."
A positive acknowledgement to the PASV command indicates that the
data socket has been opened for listening. When an RFC for its data
socket arrives after it has positively acknowledged a PASV command,
the server should respond with a matching RFC to open the data
connection (assuming, of course, that the incoming RFC is consistent
with the previous SOCK commands, if any).
+---------------+
| |
+----------| USER PROCESS |----------+
| | A | |
telnet +---------------+ telnet
| |
| |
+-----------+ +-------------+
| |--------> --------->| |
| SERVER |data sockets data socket| SERVER |
| B | Sb Sc | C |
| |<-------- <---------| |
+-----------+ +-------------+
USER A TO SERVER B USER A TO SERVER C
__________________ __________________
A->B SOCK HOST-C SKT- Sc A->C SOCK HOST-B SKT- Sb
B->A ACK C->A ACK
A->B PASV
B->A ACK
A->B STOR A->C RTRV
1. After the PASV command has been acknowledged, the two data
transfer commands can be sent in either order, since the
LISTENING action takes place with the PASV command
2. The user knows the socket numbers Sc and Sb to be the data
sockets as specified by the protocol.
3. Note that it is not essential for a SOCK command to be sent to
the same Host to whom a PASV will be sent. Sending one to him
provides security in that the incoming RFC can be checked.
RB/nlg
[This RFC was put into machine readable form for entry]
[into the online RFC archives by Helene Morin, Via Genie 12/1999]
ISO Plain Language
On this page
§1Server-to-Server File Transfer
The RFC describes a user who wants to retrieve a file from one server and send it to another. The proposed mechanism lets the two servers establish the data connection, rather than requiring the file data to pass through the user's process.
The proposal follows discussion at a recent FTP meeting at BBN.
A user may want to copy a file from one server to another. This proposal lets the servers carry the data between them.
§2SOCK and PASV
The SOCK command tells a server to prepare to use a specified socket at a specified host for its data connection. The PASV command tells a server to open its data socket for listening and, after a transfer command, wait for an incoming connection.
After a positive PASV acknowledgement, an incoming request can lead the server to send a matching request, if it agrees with any earlier SOCK command.
SOCK tells a server which other host and socket to expect. PASV tells the server to listen for the incoming connection.
§3A Transfer Sequence
The example has the user tell each server about the other server's data socket, then send PASV to one server. The user sends STOR to one and RTRV to the other; once PASV has been acknowledged, the transfer commands may be sent in either order.
The RFC notes that sending SOCK to the server that receives PASV allows it to check that the incoming connection is consistent with what it was told.
The user provides each server with the other's socket details, then asks one to listen and issues the transfer commands. The RFC says the two transfer commands can arrive in either order after the listening acknowledgement.