Sockets (which btw, totally SUCK PUS) were coded into
things
and even (YECHH) made POSIX and IETF spec status. Streams didn't stand
a chance.
The question that originally pulled me into researching Unix networking 1975-1985 was more
or less “how did we end up with sockets?”. That was 7 years or so ago, I now have a basic
feel for how it came to be, and I also have better appreciation of the trade offs. What is
the most “Unixy” of networking (as in the API and its semantics) is not something with an
easy answer.
If I limit myself to the 1975-1985 time frame, I see three approaches:
1. The API used in Arpanet Unix, which was also used by BBN in its first reference
implementation of TCP/IP
2. The BSD sockets API, in two flavours: the Joy flavour in BSD4.1a, and the Karels
flavour in BSD4.1c and later
3. The Ritchie/Presotto IPC library / API from V8/V9. This evolved into SysV networking,
but the original is the clean idea
At a high level of abstraction, there is a lot of similarity; close-up they are quite
different. I like all three solutions!
One thing that struck my attention was that the Ritchie/Presotto IPC library has the
concept of “calling” a host and the host/network can reply with a response code (“line
busy”, “number unknown”, “not authorised”, etc.). BSD sockets do not cover that. I guess
it derives from Spider/Datakit having that functionality, and Arpanet / tcp-ip not having
that (resorting to a connection ‘reset’ or dead line instead). Sockets have a more elegant
solution for connectionless datagrams (imo), and for the same reason I guess.
Sure, sockets has too much of the implementation sticking through the abstractions, but it
is IMO not a bad design. That it became dominant I think is in equal measure due to
economics and due to being “good enough”.
If someone has a proposal for a network API that is cleaner and better than what was out
there, and would have worked with the hardware and use cases of the early 80’s, I’m all
ears. But maybe better on COFF...
Paul