[TUHS] First appearance of named pipes
lm at mcvoy.com
Sun Mar 8 12:47:00 AEST 2020
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.
> 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
More information about the TUHS