[ih] Why FTP uses two ports?

[John Day]

While related, these are really two very different things.  The 
Urgent or Expedited message that appeared in many transport protocols 
of that periods was suppose to be quite limited.  Sending a very 
small amount of data 8 or 16 bytes "out of band" and no more.  Some 
proposals did it purely as "head of queue" and an ack was required 
more as flow control than acknowledgement.

The imagined use of it was getting that desperately needed control-C 
to the other end and acted on as soon as possible.  ;-)

The separation of control and data in transport protocols is more 
concerned with separating data transfer mechanisms that do not 
require strong synchronization from the feedback mechanisms that do.

Take care,
John Day

At 10:03 -0700 2012/06/21, Jack Haverty wrote:
>My recollection is the same.   Two ports allowed more powerful 
>features such as 3rd-party transfers,  but the primary motivation 
>was the separation of control messages from the data streams.
>
>Just FYI,  this issue resurfaced in the late 70s when TCP/IP was 
>being fleshed out.   I recall lots of discussions in the working 
>group meetings,  1978 time frame,  when TCP was evolving through TCP 
>2.0, 2.5, 2.5+ Epsilon,  etc.
>
>There was a discussion about whether to use "in-band" or 
>"out-of-band" signaling - i e., whether to separate control 
>exchanges from data exchanges (as FTP did in the Arpanet), or to 
>embed control and data in the same byte-stream.
>
>The decision was made to adopt the in-band approach.    There were 
>then a lot of details to work out,  especially with respect to the 
>"Urgent Pointer" mechanism of TCP.    While it was straightforward 
>to define the details of Urgent in the TCP protocol,  it was much 
>less clear how the programs at either end of the connection should 
>behave.   E. G.,  when you are notified that there is urgent data 
>further downstream,  but your own buffers are full,  what do you do 
>- discard everything until you get the urgent data?
>
>The basic tradeoff here was complexity.    Out-of-band was a more 
>powerful mechanism,  but required more code as well as dealing with 
>nasty synchronization issues.   Since many of us had already tackled 
>some of those problems in projects using the Arpanet (using FTP or 
>RJE for example) ,  we understood the pain.
>
>TCP could have been structured to utilize out-of-band connections 
>for control information, similar to FTP.  But the decision was for 
>the simpler in-band approach.   I'm still not sure that was a good 
>idea.   It was easier to implement and required less memory for 
>those of us doing the early TCP implementations.   Since DARPA was 
>chartered to try new things,  this decision may have been one of 
>those - try a new approach instead of just copying from older work.
>
>I wonder if any upper-layer programs (FTP,  Web,  whatever) 
>actually use the Urgent mechanism in TCP.
>
>/Jack
>(at the time implementing the first TCP for Unix on a PDP-11/40)
>
>On Jun 21, 2012 8:32 AM, "John Day" 
><<mailto:jeanjour at comcast.net>jeanjour at comcast.net> wrote:
>
>They were unidirectional.  But I don't remember that had anything to 
>do with it.  It did mean you only had to open a data connection in 
>one direction.  The only thing the limitation on sockets required 
>was the use of ICP, the Initial Connection Protocol.
>
>But it really was so that you could send commands during a transfer 
>and they wouldn't get queued up behind a lot of the file transfer, 
>AND that it had to be usable by the TIPs, which did not have a file 
>system.  And as Dave said, the data connection could be binary.  It 
>could take awhile to drain a pipe in those days.
>
>There were some FTPs done early that only did one full duplex 
>connection.  I think the UK protocol was like that.  But I don't 
>remember how they handled the abort situation.
>
>John
>
>
>At 10:20 -0400 2012/06/21, Noel Chiappa wrote:
>
>I have this bit vaguely set that NCP sockets were unidirectional, whereas TCP
>ports are bidirectional. Was that a factor at all (if my memory of how things
>worked is even true :-)?
>
>       Noel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20120621/5afd50ce/attachment.htm>