<p>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. </p>
<p>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. </p>

<p>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. </p>

<p>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? </p>

<p>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. </p>

<p>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. </p>

<p>I wonder if any upper-layer programs (FTP,  Web,  whatever)  actually use the Urgent mechanism in TCP. </p>
<p>/Jack<br>
(at the time implementing the first TCP for Unix on a PDP-11/40) <br>
</p>
<div class="gmail_quote">On Jun 21, 2012 8:32 AM, "John Day" <<a href="mailto:jeanjour@comcast.net">jeanjour@comcast.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

<br>
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.<br>

<br>
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.<br>
<br>
John<br>
<br>
<br>
At 10:20 -0400 2012/06/21, Noel Chiappa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have this bit vaguely set that NCP sockets were unidirectional, whereas TCP<br>
ports are bidirectional. Was that a factor at all (if my memory of how things<br>
worked is even true :-)?<br>
<br>
       Noel<br>
</blockquote>
<br>
</blockquote></div>