0

Possible Duplicate:
Why was the FTP protocol designed to use more than one port?

I know FTP uses two ports, one for commands and other for data transfer. Is there any specific reason or any advantage provided by the use of two ports. I mean, there must have been some reason that the two ports were chosen.

Community
  • 1
Ankit
  • 31
  • 1
  • 4
  • If you want one port, then you can use SFTP (not FTPS). Check out Bitvise.com . – djangofan Jun 01 '11 at 17:25
  • 5
    @djangofan, SFTP has almost nothing to do with FTP; it's a different transfer protocol implemented over SSH with commands vaguely similar to FTP. – Chris S Jun 01 '11 at 17:30
  • @Chris S - thats obvious. the guy that asked this question didn't seem to care about the protocol... what he seemed to want was a single-port solution (given by the fact that he was asking why there had to be 2 ports). rather than be argumentative, try to be helpful to the question. – djangofan Jun 06 '11 at 21:40
  • @djangofan; The question seems to be asking "Is there any specific reason or any advantage provided by the use of two ports". Nowhere in the Question did he ask for or imply that he was seeking "a single-port solution". Perhaps that is what he meant to ask, but it is most certainly not the what he asked. – Chris S Jun 07 '11 at 02:17

3 Answers3

2

In order to avoid the extra headers and details for each and every packets which will consume the bandwidth. A separate port is used for data connection.

Source: http://wiki.answers.com/Q/Why_ftp_use_two_ports_numbers#ixzz1O2rJnorL

  • Which headers, i mean they both are same connections over TCP, i think the only the difference is the port numbers. – Ankit Jun 01 '11 at 17:27
  • @Ankit - if everything was over the same connection you would need extra protocol headers to differentiate between data and commands. – JimB Jun 01 '11 at 18:30
  • The control and data connections are going to have Ethernet, IP, and TCP headers so what "extra" headers are you referring to? – joeqwerty Jun 01 '11 at 23:31
  • @Joe, if control and data were comingled, there would have to be an extra header so the client would know which each packet is. The server doesn't always know ahead of time the size of the transfer (particularly with text transfers, where FTP translates the character encoding and endianess). To keep the protocol simple, data and control were separated; control notifies the client when a transfer starts and is done, so that data doesn't have to be encoded in some sort of additional header. – Chris S Jun 02 '11 at 00:46
  • @Chris S: But it wouldn't actually be an extra header would it? It would have to be a specific sequence of characters in the data portion (payload) of the packet that would be interpreted as a control command as opposed to being interpreted as data. I mean, there's no such thing as an FTP header, right? – joeqwerty Jun 02 '11 at 01:52
  • @Joe, correct there are no FTP headers. The problem with using a specific squence of characters is that a text file could potentially contain those characters. Text files are sent across the wire in the exact format that they'll be written to disk. They could have changed this so that, like SMTP, that pattern would be escaped if found in text then un-escaped in the data written to disk; but this adds additional complexity again. There are quite a few ways the protocol could have been written, I'm sure there were more considerations at the time that have been lost to history. – Chris S Jun 02 '11 at 12:12
  • @Chris S: Which is what RFC 103 seems to be implying, although I don't know if it has any real bearing on the implementation of port usage in FTP or not. It's just odd that I can't find a clear cut declaration or explanation in any of the FTP RFC's for the use of two ports. Thanks for your insight. – joeqwerty Jun 02 '11 at 12:27
2

The wiki article above seems to have the port numbers a bit messed up :)

FTP uses 21 for control and 20 for data in active mode or a random port in passive mode.

It may have bandwidth impications but I believe one of the main reasons is to allow the control channel to be used during transfers. If you have a decent FTP client that queues transfers you may notice you can still browse the folders while it transfers. I believe it's also possible for the client to notify the server it wants to cancel an in-progress transfer.

Matt
  • 46
  • 1
  • Note that there isn't a single data connection. Anytime data is being transferred it opens a new data connection (eg listing directory contentds, down/uploading files). Also, active mode connections the Server opens (from port 20) the connection to the Client (to a negotiated port); in passive mode the Client opens (from a random port) the data connection to the Server (again to a negotiated port). – Chris S Jun 01 '11 at 17:26
  • Sounds reasonable but FTP seems to be a very old protocol and i assume that back then, they only did ftp through command line. – Ankit Jun 01 '11 at 17:33
  • @Ankit You can transfer in the background from the command line. NcFTP has "bgget" and "bgput" commands, for instance: http://www.ncftp.com/ncftp/doc/ncftp.html – Gerald Combs Jun 01 '11 at 18:08
  • @Ankit, as Gerald said, even quite old command line FTP clients could do multiple transfers simultaneously. This was a side effect, the purpose was to simplify each of the two parts, command and data. Back in the day, it was very common for two systems to use different character encoding, endianess, etc; so when transferring a text file FTP would translate as appropriate for the destination system, this meant the length of the data wasn't known before the transfer started; if command and data were together signaling would have to be added to every packet so the client would know which it was. – Chris S Jun 02 '11 at 00:43
0

I believe it's due to the fact that the client can initiate a data transfer between 2 servers instead of between the client and the server. The client maintains a control connection to both servers while the servers maintain a data connection between themselves.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 1
    That's the FXP extension to FTP, the functionality wasn't part of the original protocol. – Chris S Jun 02 '11 at 00:37
  • 1
    @Chris S: I can't seem to find anything in the original FTP RFC (114) that specifies the use of 2 ports or the reason for it other than a reference in the Endnotes to RFC 103, which dicusses NCP communications and the problem of not having enough buffer space on the receiving host to accept a control command if the data and control ports are not separated, which you seem to be implying in your comment to my comment to samarudge's answer. Am I on the right track? – joeqwerty Jun 02 '11 at 01:30
  • I'd edit your answer to reflect that re: potentially not having enough buffer space; sounds like a reasonable explanation. – gravyface Jun 02 '11 at 02:01