[ih] FTP design
day at std.com
Fri Aug 2 16:42:26 PDT 2002
At 17:38 -0500 8/2/02, John Kristoff wrote:
>The development of ftp over the early years seems to be interesting,
>although its cumbersome if not difficult for me to put all of the pieces
>together from the early RFCs, because I wasn't there. Its a subject
>that came up here and I thought I would see what I could get out of this
>Why the design of separate control/data channels, with each typically
>opening in the opposite direction from the other (not in passive mode).
>I thought I remember hearing that it had something to do in part because
>of one particular system's design. Skimming through some of the older
>RFCs (e.g. 114), it seems originally this was considered but not the
It was a long time ago. I remember the reason for the separate
control and data channels was to ensure that commands could get thru
to cancel a transfer and would not be stuck behind half a file.
Also, the TIP was a major consideration. TIPs did not have enough
memory to implement a user FTP process, so it was the human at the
terminal, typing four letter commands. Since TIPs were not the only
resource limited systems, there was a definite decision to put most
of the burden on the Server. Since the user initiated the command,
it could not be certain when the Server would actually post a listen.
(On those old timesharing systems, response time was sometimes
seconds.) So rather than send another message back to the user
(putting more burden on the user), data connections were initiated by
I don't remember any OS that forced it into the design. You might
note that the RJE protocol was "architecturally elegant" but required
the USER to implement an FTP Server, thereby violating the
requirement to keep complexity off the user system. This protocol
never got much use and the CCN RJE written by Bob Braden was much
>In the current RFC959 there is mention of having the capability to do
>full-duplex transfer of data over the data channel, but as far as I'm
>aware you've only ever be able to 'get' or 'put', but not both at the
>same time. Was there or is there a system that piggy-backs a 'put' with
>ACKs if it was doing a 'get' or vice versa?
Remember the original FTP worked with NCP. In NCP connections were
half-duplex. As far as I know there is nothing in the protocols to
prevent overlapping gets and puts. Implementations may make such a
restriction, but there is no reason why not.
>Any additional insights into what might be considered big mistakes in
>the design with 20/20 hindsight, or collosal mistakes in intentionally
>leaving something out?
Not really. We always talked about adding file access (reading or
writing parts of a file) and Ken Pogran and I did play with the idea.
I wrote an RFC and Ken implemented it. There was much talk about
adding all of the various file system commands and some of that was
done in other efforts. I think the only real problem, if it were
that, would be that had we not had the TIP constraints some things
might have been done a little differently. But it would not have
been significant change.
Actually, I believe that Telnet and FTP got an uncommon number of
things right. I think the idea of having replies that were both
machine and human readable was brilliant. I forget who came up with
it but I think it was Postel and a couple of others.
Anyone else's memory better than mine!
More information about the Internet-history