IIRC is how UNET worked for V7.


FWIW: UNE T was the original product from 3COM and somewhere I have the
package with the Postmark as the 32nd of December - because 3Com had a
requirement to ship by the end of the year to their VCs.   At the last
hours, Greg Shaw and Bruce Borden ran into a problem, so it shipped a day
late [they obviously got their money].

Clem
ᐧ

On Tue, Dec 11, 2018 at 11:17 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > 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
>