Subject: Re: sockets vs. fds

From: [email-masked] (Noel Chiappa)
Date: Fri, 5 Dec 2008 11:00:38 -0500 (EST)

> From: Melinda Shore <[email-masked]>

    > "Unix" ... was designed around a few abstractions, like pipes,
    > filedescriptors, and processes, and by the time IP was implemented we'd
    > pretty much settled on filedescriptors as endpoints for communications.
    > We could do things with them like i/o redirection, etc. ... in Unix we
    > shouldn't care whether an input or output stream is a terminal, a file,
    > or a network data stream

Wow, that tickled some brain cells that have been dormant a very, very long
time! My memory of this goes all the way back to what I believe was the very
first mechanism added to V6 Unix to allow random IPC (i.e. between unrelated
processes), which was a pipe-like mechanism produced, if vague memories
serve, by Rand. This is all probably irrelevant now, but here are a few
memories...

One of the problems I recall we had with the Unix stream paradigm is that it
was not a very good semantic match for unreliable asynchronous communication,
where you had no guarantee that the data you were trying to do a 'read' on
would ever arrive (e.g. things like UDP), nor for things which were
effectively record-based (again, UDP).

Sure, TCP could reasonably well be coerced into a stream paradigm, but just
as RPC has failure modes that a local call doesn't, and therefore needs
extended semantics beyond that of a vanilla local call, so too it is with a
Unix stream (which, in V6, was the only I/O mechanism).

	Noel
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 11:36:20 -0500

Not sure when the RAND work was.  But if you were worrying about UDP 
it was much later. When Illinois put UNIX on the Net in the summer of 
75, we ran into several initial problems.  There were real limits on 
kernel size.  So the NCP was in the kernel, telnet, etc. were 
applications.

In the initial version Telnet was written as two processes (inbound 
and outbond) because pipes were stupid and were blocking.  We hacked 
stty and gtty so they could do the minimal coordination they needed 
to do.  There was a paper on this by Greg Chesson published somewhere.

Once that initial version was working, we went back and designed a 
non-blocking IPC system for UNIX.  All of this is lost in the fogs of 
time.  With that we were able to do Telnet as a single process.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Dec 2008 08:49:39 -0800

John Day wrote:
> Not sure when the RAND work was.  

1977.  One of several IPC efforts for Unix around that time.

I was in that group, but had nothing to do with that work and frankly failed to 
tracking its significance.

 > But if you were worrying about UDP it
> was much later. When Illinois put UNIX on the Net in the summer of 75, 
> we ran into several initial problems. 

The key point that Melinda made, that resonated with me, is the unfortunate 
matter of semantic mismatch, between the Unix 'file' construct and the 
networking 'packet' construct.  Even the 'tcp' construct had some challenges.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf