Derek Fawcus:
Yeah - I always found that a bit weird, having to use socketpair()
to get a bidirectional "pipe".
In the Research system, pipes became bidirectional when
they became streams. That happened slightly before my
time, but so far as I know it broke absolutely nothing.
Some time in the late 1980s, the System V people wanted
to allow pipes to be streams, but were worried about the
bidirectionality. They proposed to have a new system call
to make a bidirectional pipe.
I attended a meeting with the relevant programmers and
program manager to find out why they thought pipes couldn't
just be bi-directional, as they had been without fuss in
the Research system for some years. They agreed with me
that that was how it ought to be; the trouble was that
System V releases all had to pass an official System V
Verification Suite (reasonable enough), and that suite
checked not only that you could read the one pipe file
descriptor and write the other, but that you couldn't
do it the wrong way.
Wait a minute, I said. I'm pretty sure that's not how
the official System V Interface Description reads. Anyone
got a current copy handy?
We found one, and we looked, and sure enough, the official
verification suite was wrong. The specification said
that data written to fd[1] must be readable from fd[0],
but nothing about the other direction: full-duplex pipes
were not required but neither were they outlawed!
The programming group was delighted: I'd given them the
ammo they needed to do it right (make pipes streams, and
make them full-duplex by default). I believe that is
how it came out, though the only reference I have is
Solaris 10, where the manual page specifically says
that what pipe(2) makes is full-duplex (and a stream).
I wish POSIX and Linux and the BSDs would catch up; that
was only 30 years ago.
Norman Wilson
Toronto ON
> 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.
My interest in Unix networking 1975-1985 originally came from wondering how we came up with this alien feeling socket API as the dominant model. The original ideas for this API are in the recently found CSRG tech reports #4 and #3 - which I hope to discuss on this list in Spring.
I think we have to distinguish the API and the underlying paradigms.
When it comes to the “Arpa” lineage of Unix networking, the original API model was fully within the open-read-write-close framework. See for instance RFC681 and this document: https://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-Vax-TCP/doc/net.5.P; the entire BBN network API model fits on a few pages of ‘man’ text.
In 1975 Arpa Unix, the network name space was integrated with the file name space, by creating a character special file for each network host. This was possible because at that time an Arpa network address was 8 bits, and this fitted in the minor number; when Arpa addresses were expanded to 24 bits soon after this approach was abandoned (but one could think of a mechanism akin to symbolic links that could have continued the practice). One could have an entry for the local host, e.g. “/n/local” or something like that.
In my mind, “socket” does not only refer to the sockets API, but also to the concept of a bi-directional, possibly remote, named pipe; ‘named' as in “discoverable by a possibly unrelated process”, i.e. the in file name space, the network name space if different, etc. [aside: I realise (now) that this is a confusing use of the word socket, but I don’t have a better phrase at hand.] In my opinion, it is this concept that has proven strong and durable, much more so than the socket API itself.
When viewed in this definition a ‘fifo’ is a limited form of socket: it is unidirectional, local only (although in the 1981 S/F-Unix it wasn’t) and a server process cannot easily distinguish or delegate individual client connections. The Rand Port was better in the sense that it prefixed each client’s data with a header block.
> 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
"Networks are not intrinsically more special than any other I/O peripheral”: that indeed is the paradigm that underlies Spider-Datakit-streams-STREAMS-Plan9, networks are just an I/O peripheral. There is nothing wrong with that paradigm, excellent systems can be built on top of it.
The other paradigm is that the network is a (mostly hidden) substrate that carries bidirectional pipes between processes. It would seem to me that there is nothing wrong with that paradigm either and it can be implemented in a “natural Unix” way as well.
> 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 meant ’socket’ in the sense that I described above.
“Socket” must be one of the most overloaded words in networking. My understanding is that on the Arpanet the “socket number” was what we now would call a "port number”, although I think it was initially meant to identify a user on a host, rather than a service on a host. In the 1980 BBN TCP implementation “socket” is used to mean “ip address”. A year later, Bill Joy uses “socket” as an API call name.
>> >
>> > 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
Arnold Robbins writes:
>> There was no tac in V7 Unix. It was first posted to USENET, I don't
>> know by who, and picked up by Linux and *BSD.
That brought back memories, and to verify them, I checked the tac.c
source code in the latest GNU coreutils test release. It says
/* Written by Jay Lepreau (lepreau(a)cs.utah.edu)
GNU enhancements by David MacKenzie (djm(a)gnu.ai.mit.edu) */
So my memory was right that my old friend Jay was the author. Sadly,
we lost him in September 2008: see
https://www.legacy.com/obituaries/saltlaketribune/obituary.aspx?page=lifest…
Jay founded the influential Flux group in advanced networking research:
http://www.flux.utah.edu/profile/lepreau
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
The Luderer paper on distributed Unix has the following paragraph:
"A new special UNIX interprocess communication mechanism is the fifo, which provides communication between unrelated processes by associating a new special file type with a file name. Since remote fifos are legal, they can be used for interprocessor communication between S-UNIX machines or between an S-UNIX machine and an F-UNIX machine.”
The paper is from late 1981. Maybe I’m especially mud-eyed today, but I cannot see FIFO’s implemented in V7..V8 or 4.1xBSD. When did FIFO’s become a standard Unix feature?
Paul
> These go all the way back to v7 unix, where ls has an option to reverse
the sort order (which could have been done by passing the output to tac).
A cool idea, but tac was not in v7. And tail didn't get the -r
option until v8.
As for rev, I don't know why it was first written, but one
use was to examine suffixes--a kind of thing that several
word lovers in the Unix lab were prone to do.
Apropos of using rev to make rhyming dictionaries, Walker's
Rhyming Dictionary was published decades before Noah
Webster's dictionary appeared and stayed in print
for about 200 years. Notionally the relation between
webster and walker is
rev <webster | sort | rev >walker
Doug
I’m making a little progress with early Datakit & Unix.
It would seem that there were various experimental protocols before URP was arrived upon.
The first protocol appears to have been designed by Chesson in 1979. One Fraser paper says: ""The first Datakit protocols used a packet structure that was aligned with cell boundaries. Chesson designed a file transfer protocol that transported data in variable length packets, each ending with a trailer.” I think this protocol is being described in his paper "Datakit Software Architecture” (vol. 2, pp. 20.2.1-20.2.5 Proceedings of the IEEE Int. Conf. on Communications, June 1979, Boston) - which unfortunately does not seem to be available in the IEEE online library. Maybe it will surface some day.
Next there was a protocol tied to a Datakit terminal interface board that used an 8-slot packet sequence/acknowledge mechanism that carried over into URP. Not much appears to have been published about this.
The most interesting experiment seems to have been a project by Luderer, Che and Marshall to build a Datakit-based distributed Unix in 1980/81. Marshall is credited by Fraser as one of the inventors of the URP protocol. The papers are “A virtual switch as the basis for distributed systems” and “A distributed unix system based on a virtual circuit switch” (available online from the ACM library).
The first has a good overview description of how early Datakit worked (including interface hardware) and describes the Network Kernel or “NK protocol”. It would seem that URP combines the flow & retransmission control from the terminal interface board with the concept of a single simple receiver algorithm from NK. Unfortunately the paper does not describe the design of the NK transmitter algorithm(s). It confirms that everything ran on V7, but it remains unclear how the Datakit channels were exposed to the user (I currently assume as a cluster of character devices, with the major number identifying the switch connection and the minor number identifying the channel - similar to what later would be used in V8).
The second has a description of a modified Unix system, where clients (“S-Unix”) talk to file servers (“F-Unix”), with the file servers mounted into the local file tree of the client. This appears to predate the work of Weinberger for the V8 network file system and its implementation appears different.
Questions:
- Are Luderer, Che and Marshall still around? (especially Bill Marshall might still recall some more details of the genesis of the URP protocol)
- Any recollections about S/F-Unix and how it did or did not influence V8-V10/Plan9?
Hi All.
I have a full set (hardcopy) of the USENIX "Computing Systems" journal.
It's just sitting on my shelf taking up space, and I'd like to give them to
someone who'll give them a good home.
So, first person to reply to me directly, who's willing to pay
shipping from Israel, gets them. (Payment via paypal, or preferably
a US dollar check sent to my US address.)
Thanks!
Arnold
I was just discussing this with someone today, and I realized this
information has fallen out of working memory, and I can't find it on
secondary storage anywhere... ;-)
Does anyone remember the release history and version numbering of Ultrix
for the VAX and MicroVAX (which I believe was referred to at various times
as Ultrix-32 and Ultrix-32M, until some point when the "-32" thing was
dropped, I think?) I was trying to remember what the various released
versions of Ultrix were. The person I was discussing with thinks he
remembers a version 1.4 and 1.6, before Ultrix 2.0. I honestly don't
remember any 1.x version beyond 1.2. Is there a timeline somewhere?
--Pat.
All, I've had a few queries about the proposed video chat sessions, so
I'll kick the first one off tomorrow:
UTC Brisbane London New York
Friday, 28 Feb 2020 at 21:00 Sat 7:00am Fri 9:00pm Fri 4:00 pm
I'll only be able to stay for an hour but the chat session should
continue when I've gone.
URL: https://meet.tuhs.org/COFF
Password: unix
Cheers, Warren
This explains something, I think!
Luca Cardelli and Mark Manasse later worked at the Digital Systems Research Center in Palo Alto, which was formed in 1984 after PARC fired Bob Taylor.
Mark helped write the window system we used, and at some point a cat appeared, which would sleep until you moved the mouse and then come over to pat at the mouse.
My impression was that Luca wrote it, be he was cagy about it.
This later evolved into xneko for X Windows.
-Larry
