8 Mar
2020
8 Mar
'20
3:47 a.m.
I hear you but sockets are here to stay. Sun tried to get rid of them
by going to a STREAMS networking stack (not saying that was in any way
a better answer, just different). Didn't work, they had to put sockets
back, there was just way too much software written around the socket API.
I tried to make a more sane interface and never got to something that
handled all the edge cases.
Did Plan 9 make it sane? If so, care to say how or point me at something
like Masscomp's introduction to network programming?
On Sun, Mar 08, 2020 at 01:36:14PM +1100, Rob Pike wrote:
Always bemused me that to get a named local I/O
connection one ended
up with "Unix domain (what does that even mean?) sockets" rather than
named pipes, especially since sockets are about as natural a Unix
concept as lawn mowers. I've been told, but haven't confirmed, that
early sockets didn't even support read and write. They still don't
support open and close, and never will.
Networks are not intrinsically more special than any other I/O
peripheral, but they have become gilded unicorns mounted on rotating
hovercrafts compared to the I/O devices Unix supported before them.
-rob
On Sun, Mar 8, 2020 at 3:48 AM Derek Fawcus
<dfawcus+lists-tuhs(a)employees.org> wrote:
>
> On Sat, Mar 07, 2020 at 01:17:09PM +0100, Paul Ruizendaal wrote:
> >
> > Interestingly, Luderer also refers to a 1978 paper by Steve Holmgren (one of
the Arpa Unix authors), suggesting ???sockets??? (in today???s parlance) for interproces
communication.
>
> Could that simply be bleed over of terminology from the ARPAnet / Internet
> usage, in that "socket" is used to refer to protocol end points?
>
> i.e. see these from 1970:
>
> https://tools.ietf.org/html/rfc54
> https://tools.ietf.org/html/rfc55
> https://tools.ietf.org/html/rfc60
>
> DF
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm