Timeline for What was the design rationale behind multi-port and multiple connections (and back-connections) designs of the early protocols like NFS or FTP?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 10, 2020 at 13:59 | history | edited | user3840170 | CC BY-SA 4.0 |
use box-drawing characters for the diagram
|
| May 15, 2020 at 10:11 | comment | added | Aaron F | I had forgotten all about FXP transfers until now! | |
| May 15, 2020 at 4:07 | comment | added | occipita | Another benefit is that FTP can be used without needing a dedicated client program. You can use telnet to connect the control connection and use a simple generic network stream sender/receiver (eg netcat) to handle the data transfer. | |
| May 14, 2020 at 22:43 | comment | added | ninjalj | Actually, FTP got separate control and data connections for performance reasons: mainly to be able to select the data connection byte-size and avoid format conversions, see RFC310 and RFC327. | |
| May 14, 2020 at 13:19 | comment | added | Vatine | @StephenKitt [ edit, I think it was control/data ] In ARPAnet, links were unidirectional, so it would naturally have been "one control" (from client to server") and one "data" (from the server to the client). tools.ietf.org/html/rfc33 page 3 | |
| May 14, 2020 at 11:34 | comment | added | Stephen Kitt |
@ilkkachu right, connections between remote servers wouldn’t work without PASV AFAICT, but even before that was available, there were other scenarios where the separation was “useful”; see for example scenario 1 in RFC 354, where a user connects to a remote host and sends a file directly to the printer daemon on the local host. IIUC initial FTP proposals (RFC 114) didn’t separate the control and data connections.
|
|
| May 14, 2020 at 9:48 | comment | added | ilkkachu | @Nobody, not if you only have FTP access :) | |
| May 14, 2020 at 9:48 | comment | added | ilkkachu |
I may be wrong, but I don't think this would work without PASV, would it? You'd need to have one of A and B start an outgoing connection, and have the other listen. So if PASV was added so much later, this can't at least be the original reason.
|
|
| May 14, 2020 at 8:44 | comment | added | Nobody | This seems kind of silly, you could just log in to A or B remotely. | |
| May 14, 2020 at 3:35 | comment | added | hippietrail | Yes I actually implemented this once in the '90s when it was requested by users. One thing is that C never finds out whether the transfer completed or encountered a problem, from memory. | |
| May 13, 2020 at 22:01 | comment | added | Greg Hewgill | @StephenKitt: Thanks for the reference! I should have copied the diagram from there instead of drawing a new one. :) | |
| May 13, 2020 at 22:00 | comment | added | Stephen Kitt | And this is explicitly mentioned in RFC 959 (and probably others). Another factor in the FTP design is that the control connection uses the Telnet protocol. | |
| May 13, 2020 at 21:54 | history | answered | Greg Hewgill | CC BY-SA 4.0 |