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

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Clem Cole <clemc@ccc.com>

    > This is why I suggested that if you really want telnet and ftp to the
    > PDP-11, you might be better off moving the networking stack out of the
    > kernel

Really, the answer is that I need to get off my @ss and put the MIT V6+ system
up (I have all the files, just need to get a round tuit).


It has TCP/IP, but is it not all crammed into the kernel. And unlike the early
BBN V6, it doesn't do TCP as a single process to which all the other
client/server processes talk via IPC.

Instead, the only thing in the kernel is inbound demuxing, and minimal outbound
processing. (IIRC, outbound packets are copied into kernel buffers; an earlier
version of the networking interface driver actually did do inbound and outbound
DMA directly from buffers in the user's process, but only one process could use
the network interface at a time.)

The TCP code was a library that was built into the user process which did the
server/client applications. (The servers which supported login, like FTP,
needed to run as root, like the ordinary login, setuid'ing to the entered
user-id.) I don't remember if we supported server Telnet, but I think we
did. So we must have added PTY's of some sort, I'll have to check.

Since the TCP was in the user process, we actually had a couple of different
ones, depending on the application. Dave Clark had done a quick-n-dirty TCP on
the Alto (in BCPL) which was only good for things like user Telnet, not for
applications that sent a lot of data. We ported that one for the first TCP; we
later did a 'high-speed bulk data' TCP, used for FTP, etc. I don't remember
which one SMTP used.

The whole thing worked _really_ well. Alas, I don't think anyone else picked
up on it.


The kernel code is not that large, it should even run on a /40, without
overlays (although the number of disk buffers would probably get hit).  And
since the TCP is in user processes, it could all get swapped out, so it would
run OK on machines without that much physical memory.

The issue is going to be that it will need a new network interface driver,
since I think the only driver ever done for it was for Pronet. And now we get
back to the 'what interfaces are available' question. Doing a DEC driver would
allow use of DEQNA's and DELQA's on QBUS machines, which would be optimal,
since they are common. And people could bring up Unix with TCP/IP on -11/23's.

But we'd have to add ARP (which I would do as a process, with only the
IP->Ether address mapping table stored in the kernel). I wrote a really nice
ARP for the C Gateway that could easily be used for that.

      Noel