FTP server-server interaction - II
The command that lets two servers exchange data without forcing the user to wait.
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]
AI ELI5
On this page
§1The Third-Party Transfer Problem
In FTP, a user normally connects to a server, commands it, and receives data. But sometimes a user wants to copy a file from one server (B) to another (C) directly. Both servers must coordinate without the user in the middle.
The challenge is that without prior agreement, one server might try to connect while the other is not ready, or both might try to connect at the same time. This RFC, following discussion at an FTP meeting at BBN in March 1973, proposes the PASV command to solve this.
Two servers need to talk to each other, but they do not know when the other is ready. A signal tells one server to wait by the phone while the other server calls.
§2PASV and SOCK Commands
Two commands work together for third-party transfers. The SOCK command tells a server which socket to use and which host to expect a connection from. The PASV command tells a server to open its data socket for listening and wait for an incoming connection.
When a server receives PASV, it acknowledges positively, confirming that its data socket is open and listening. When an incoming connection arrives at that socket, the server responds with a matching connection to complete the data path.
SOCK is like writing down an address. PASV is like saying 'wait here.' The server that got PASV sits at the door, and when the other server arrives, they connect directly.
§3A Data Transfer Scenario
The user first tells server B about the location (SOCK) of server C, and server C about the location of server B. Then the user sends PASV to server B, making it listen on its data socket. Finally, the user can send transfer commands in any order: STOR (store) to server B and RTRV (retrieve) to server C. The servers connect to each other and exchange data without further user involvement.
This design lets both servers understand the transfer parameters before connecting. For security, sending a SOCK command to the same host that will receive PASV allows the receiving server to verify the incoming connection is expected.
First, tell both servers about each other. Then tell one to wait. Then tell both to start. They find each other and swap the file.