[ih] History of the TCP/UDP port space

Noel Chiappa jnc at mercury.lcs.mit.edu
Tue Jan 24 05:48:27 PST 2006


    > I was suggesting who I thought were some of the key contributors to
    > follow up and find the API documentation - not to grant credit...

Ah, got it.

    > My main point, that the network APIs in these and other non-Unix OS's
    > were far from the now-current Berkeley Unix Sockets API
    > ...
    > these other systems were not at all like Unix in many ways

Yes, indeed - but even in Unix, things looked very different from sockets
in the early stages!

I got the impression that sockets came about as much because Unix didn't have
a really good complex asynchronous data-handling interface model to follow, as
for any other reason. I certainly remember that when adding network I/O to V6
Unix, one basically had to start from scratch, because the only data-handling
interface model available was file I/O, which was nowhere near rich enough
(semantically).

For a long time, each Unix networking effort:

- the NCP (I forget who did that - U Illinois, I think, maybe?)
- the first BBN Unix code (for PDP-11's)
- an early PDP-11 Unix done by U Illinois (IIRC - John Day was I think
	involved in that one)
- the MIT PDP-11 Unix effort
- the MIT PDP-11 Unix CHAOS protocol implementation, done by the Plasma
	people, IIRC (for completeness :-)
- the second BBN Unix code (for the early Unix VAX versions)

was completely standalone, and took little from the prior work, although they
mostly looked vaguely similar (except for the MIT one, which was oddball
because it only did packet demux in the kernel - although I no longer recall
if TCP was in the same process as the application, or whether they were
separate processes). But I don't think any looked much like sockets.

(I think the MIT stuff may have borrowed some from an earlier RAND [I think?]
project which had added generic IPC to Unix - i.e. not simply pipes, with
their "common parent" requirement.)

I'm not really sure what (if any) the influences on sockets were. I have this
vague memory that they looked more like the TWENEX interface than anything
else, but that could easily be incorrect...


    > and they already had "mature" APIs to NCP, which were retained so that
    > apps could be ported forward easily.

Yes - of course, one had to make minor tweaks (e.g. the destination address
was different).

    > the protocol spec avoided spec'ing in terms of an API

Well, yes and no. If you read the TCP RFC, there is a pseudo-spec for an
interface (IIRC), but it's mostly there to show you what pieces of data you
have to pass across interface.

    > (some think this a bad idea - but since I/O APIs were quite different
    > from OS to OS then, it was a pragmatic choice).

Exactly - that was explicitly the reason no standard API was given. Of
course, back then, the whole concept of portability was just coming about -
most OS's were still written in machine language, and so were many
applications - so there wouldn't have been much point to a standard interface
anyway.

	Noel



More information about the Internet-history mailing list