<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [ih] Why FTP uses two
ports?</title></head><body>
<div>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.</div>
<div><br></div>
<div>The imagined use of it was getting that desperately needed
control-C to the other end and acted on as soon as possible.
;-)</div>
<div><br></div>
<div>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. </div>
<div><br></div>
<div>Take care,</div>
<div>John Day</div>
<div><br></div>
<div>At 10:03 -0700 2012/06/21, Jack Haverty wrote:</div>
<blockquote type="cite" cite>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.<br>
</blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
<blockquote type="cite" cite>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?<br>
</blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
<blockquote type="cite" cite>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.<br>
</blockquote>
<blockquote type="cite" cite>I wonder if any upper-layer programs
(FTP, Web, whatever) actually use the Urgent
mechanism in TCP.<br>
</blockquote>
<blockquote type="cite" cite>/Jack<br>
(at the time implementing the first TCP for Unix on a PDP-11/40)<br>
</blockquote>
<blockquote type="cite" cite>On Jun 21, 2012 8:32 AM, "John Day"
<<a href="mailto:jeanjour@comcast.net">jeanjour@comcast.net</a>>
wrote:<br>
<blockquote>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>I have this bit vaguely set that NCP sockets were
unidirectional, whereas TCP</blockquote>
<blockquote>ports are bidirectional. Was that a factor at all (if my
memory of how things<br>
worked is even true :-)?<br>
<br>
Noel</blockquote>
</blockquote>
</blockquote>
<div><br></div>
</body>
</html>