[TUHS] First appearance of named pipes

[Larry McVoy]

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