[ih] Why FTP uses two ports?
Jack Haverty
jack at 3kitty.org
Thu Jun 21 10:03:49 PDT 2012
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" <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/a3c0d6b2/attachment.htm>
More information about the Internet-history
mailing list