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.
At 11:00 -0500 2008/12/05, Noel Chiappa wrote:
> From: Melinda Shore <mshore@xxxxxxxxx>
> "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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf