[ih] FTP design

[John Day]

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
>list.
>
>Particularly...
>
>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
>preferred method.

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 
the server.

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 
more successful.

>
>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!

Take care,
John