[TUHS] Unix with TCP/IP for small PDP-11s

[Clem Cole]

We'll have to do some digging. And having too been part of too many, but
similar of different implementations. The Chaos code used the partial
parsing as did a few others.  IIRC: That's the same trick Apollo used with
Domain too.  I had thought I had remember that Chesson and the UofI folks
used the same trick with the Arpanet code, but I have not looked at it in
years and clearly as you point out he did not.

As for DataKit et al..  Greg Chesson was a grad student at UoI.  The UoI
folks did the original  V6 Arpanet for UNIX code and Greg was the one of
the primary developers same.  What I do not remember is who came first, the
Rand networking work for the UoI work.   Rand did the the ports (later
called named pipes) and a few other things pretty early.   But again all
those dates sort of mix together in the early middle 70s.  USENIX was not
yet publishing proceedings so it's hard to keep straight.   It pretty much
just email and memories of those of us that were sharing things at the time.


Anyway, when Greg graduated, he was hired by Ken when he finished and
developed DataKit at Bell labs.   One of the pieces of datakit that was
released as part of V7 was Greg's mpx(2) code - which was the multiplexer.
The legend is that on is way to UCB for his sabbatical, Ken was checking in
Greg and the infamous v6 patches tape was left behind at UoI.  Greg used to
deny all knowledge of same, but smiled all the time he said it.

Clem

On Mon, May 22, 2017 at 6:07 PM, Paul Ruizendaal <pnr at planet.nl> wrote:

> Clem,
>
> You've got me confused.
>
> > The API pretty much worked this way...  there was one simple kernel
> hook.   A small mod was done to the old nami routine (what modern UNIX
> calls 'lookup'), as a path was being parsed, the rest of the path was left
> in place made available to other routines.
>
> The UoI Arpanet code did not use the partial path parsing that you
> describe.
> The namei() routine is unchanged (see http://www.tuhs.org/cgi-bin/
> utree.pl?file=SRI-NOSC/ken/nami.c).
>
> The code recognizes a network open, because the open() is of a special
> character file with major number 255;
> the minor number would be the remote address (1974 arpanet used 8 bit
> network addresses - 6 bits IMP, 2 bits host).
> If the 'mode' parameter to open() is 0, 1 or 2, then a NCP/telnet
> connection would be made to that host. If the mode parameter was anything
> else, it was a pointer to a data block with the full specification of the
> connection to be made. See:
> http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c - open1()
> http://www.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ncpk/nopcls.c -
> netopen()
>
> The data block contained all the parameters that are set via calls to
> connect/bind/listen in the BSD sockets API.
>
> > There were a couple of different schemes with V7's multiplexor call was
> created by Chesson for DataKit (which was similar to was used in the UofI
> code Arpanet code).
>
> You've lost me here.
>
> Paul
>
> On 22 May 2017, at 18:29 , Clem Cole wrote:
>
> > The Rand API is documented in a couple of papers that have been
> discussed here previously.   I'll have to do a little googling to find
> them.   The ChaosNET docs are the best MIT docs.
> >
> >
> > The API pretty much worked this way...  there was one simple kernel
> hook.   A small mod was done to the old nami routine (what modern UNIX
> calls 'lookup'), as a path was being parsed, the rest of the path was left
> in place made available to other routines.
> >
> > Thus you could open:  /dev/tcp/xxx  and the string xxx was available in
> call that was implementing tcp and was then able to be passed xxx as a
> parameter.  Hence, the traditional open/close/read/write was all that was
> needed.
> >
> > Joy codified a new API that was supposed to be more network centric and
> map to different network protocols - the thinking being that
> open/close/read/write were insufficient semantics for network operations.
> >
> > Also, the only other issue at the time was that BSD's select(2) did not
> exist, and the UNIX I/O were 100% synchronous.  So some other mechanism
> (also discussed here) needed to be created to avoid blocking in the
> application.  There were a couple of different schemes with V7's
> multiplexor call was created by Chesson for DataKit (which was similar to
> was used in the UofI code Arpanet code).   Rand, UNET & Chaos had something
> else that gave the save async function, who's name I've forgotten at the
> moment, but I believe Noel posted the code for same in the last year from
> one of the MIT kernels - we had used it at CMU that we had gotten from Rand.
> >
> > On Mon, May 22, 2017 at 10:51 AM, Steve Simon <steve at quintile.net>
> wrote:
> > hi Clem,
> >
> > do you have pointers to any documentation on the rand/MIT network API?
> >
> > -Steve
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170522/e97f362d/attachment.html>