In protocol design, why would you ever use 2 ports?

Question

When a TCP Server does a socket accept on a port, it gets a new socket to work with that Client.
The accepting socket remains valid for that port and can accept further

Answer 1

FTP is an old protocol. That's really the only reason. The designers thought that the amount of data flowing over the data port would make it so that they couldn't send control commands in a timely manner, so they did it as two ports. Firewalls, and especially NAT, came much later.

Answer 2

Like many of the older wire protocols, FTP is suited for use by humans. That is it is quite easy to use FTP from a terminal session. The designers of FTP anticipated that users might want to continue working with the remote host while data was transferring. This would have been difficult if command and data were going over the same channel.

Answer 3

FTP was designed at a time when the stupidity of a modern firewall was inconceivable. TCP ports are intended for this functionality; multiplexing multiple connections on a single IP. They are NOT a substitute for Access Control Lists. They are NOT intended to extend IPv4 to 48 bits addresses, either.

Any new non-IPv6 protocol will have to deal with the current mess, so it should stick to a small contiguous range of ports.

Answer 4

When a user starts a FTP session with a remote host, FTP first sets up a control TCP connection on server port number 21. The client side of FTP sends the user identification and password over this control connection. The client side of FTP also sends, over the control connection, commands to change the remote directory.

When the user requests a file transfer (either to, or from, the remote host), FTP opens a TCP data connection on server port number 20. FTP sends exactly one file over the data connection and then closes the data connection. If, during the same session, the user wants to transfer another file, FTP opens another data TCP connection. Thus, with FTP, the control connection remains open throughout the duration of the user session, but a new data connection is created for each file transferred within a session (i.e., the data connections are non-persistent).

Answer 5

The initial rationale behind this was so that you could:

• Continue sending and receiving control instruction on the control connection while you are transfering data.
• Have more than one data connection active at the same time.
• The server decides when it's ready to send you data.

True, they could have achieved the same result by specifying a complicated multiplexing protocol integrated to the FTP protocol, but since at that time NAT was a non issue, they chose to use what already existed, TCP ports.

Here is an example:

Alice wants two files from Bob. Alice connects to Bob port 21 and asks for the files. Bob open connections to Alice port 20 when it's ready and send the files there. Meanwhile, Charles needs a file on Alice's server. Charles connects to 21 on Alice and asks for the file. Alice connects to port 20 on Charles when ready, and sends the files.

As you can see, port 21 is for client connecting to servers and port 20 is for servers connecting to clients, but those clients could still serve files on 21.

Both ports serve a totally different purpose, and again for sake of simplicity, they chose to use two different ports instead of implementing a negotiation protocol.

Answer 6

I think they did this so that while a transfer was occuring you could continue to work with the server and start new transfers easily (if your client could support this).

Note that passive mode solves nearly all firewall/NAT problems.