The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] sockets [was Re: forgotten versions]
@ 2022-06-17 15:18 Paul Ruizendaal
  0 siblings, 0 replies; only message in thread
From: Paul Ruizendaal @ 2022-06-17 15:18 UTC (permalink / raw)
  To: tuhs

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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2022-06-17 15:18 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-17 15:18 [TUHS] sockets [was Re: forgotten versions] Paul Ruizendaal

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).