[ih] FTP design

[David P. Reed]

I remember all the things you do John (but my connection to the FTP design, 
pre-internet as it was, was through Ken Pogran, who did the work for it on 
Multics).   I'd just like to add my comment that "separate control and data 
connections" was hardly a mistake.   It was very much on purpose, and for 
exactly the reason that John points out.   Rather than invent a magical 
"out of band" feature in TCP, which would have multiplied the congestion 
control complexities, as well as introducing problems of mixing data and 
control coding schemes, just using two connections was simple.

As far as the directionality of streams, one idea that was contemplated was 
the idea of having control host A create a transfer from host B to host C, 
while not having a control connection from B to C.

Finally, but Ken Pogran can clarify this more if you talk to him, FTP's 
multiple connection scheme was somewhat hard to implement in Multics 
security model, but rather than have Multics influence the design, the 
Multics guys figured out how to generalize the connection notification 
mechanism to get this to work right.


At 07:42 PM 8/2/2002 -0400, John Day wrote:
>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
>