[TUHS] 2.9bsd with networking on 18-bit possible?

[Paul Ruizendaal <pnr@planet.nl>]

> I'm sure it's been attempted before, but would anyone be up to the
> challenge of trying to get that going with networking on an
> 18-bit-address-space pdp11?

By coincidence I’m in the middle of a project to make V6 run with the Gurwitz TCP stack on a TI990 clone (which is pretty similar to a PDP11). It runs without separate I/D as two processes in about 100KB.

The Gurwitz TCP stack was the reference implementation for the VAX that BBN did in 1981. It is in the THUS archive:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP

As documented in IEN168, the actual TCP processing happens in a separate kernel process, much like process 0 (swapper) in Unix itself. It turns out that the network process shares no data (other than the u struct) with the kernel proper and can be run in a separate address space. Just a few ’thunks’ are needed: open/read/write/close from the kernel to the TCP stack and sleep/wakeup in the other direction.

A V6 Unix kernel runs in 48KB with buffers, the TCP stack with buffers needs about the same; both must remain resident - i.e. it ties up about 100KB of the 256KB core on a 18-bit machine. I suppose when using separate I/D it can run without thunks: the code size is about 25KB for both a minimal V6 kernel and the TCP stack, the rest is data.

In my setup, network connectivity is via a SLIP interface. The Gurwitz code also has an Ethernet driver (note ARP was not invented yet), but I’m not using that. I’m happy to report that this 1981 tcp/ip code can still talk to current OSX and Linux machines. 

Just yesterday I got the setup working and I can run minimalist telnet connections etc. Alas it is not quite stable yet, it tends to crash after 5-10 minutes of use.

The BBN reference implementation includes FTP and Telnet servers and clients which I think will still interoperate with current versions. As a final remark note that this BBN code uses an API that is almost unchanged from the API as used on NCP Unix. As compared to sockets this means that a listening connection is not a rendez-vous, but blocks until a connection is made (and then becomes an active connection, i.e. stops listening), and that there is no “select” type functionality.