VSta networking, some more details

I've already had some requests for more details.

The ethernet driver (for an ne2000) runs as a normal device driver task. It
offers a directory to mount (under namer net/ne) which is initially empty.
If you mount net/ne under, say, /dev/eth, and then open() /dev/eth/800, all
IP packets (type 0x800) for your MAC address (or broadcast) will start
arriving as read() completions. /dev/eth/0 receives everything.

Because each client connection can only do one I/O operation at a time, KA9Q
open()'s two connections; one for reading, another for writing.

KA9Q software itself run as a user task. I started with the Linux port, but
have hacked it extensively. The code no longer polls or does any spinning.
Instead, I created a thread for each source of data/events (keyboard, LAN
interface, timers, local TCP clients) and have the threads block for their
own data. When they get something, they take a global semaphore which I
added to the KA9Q code, queue their data, and then run the usual KA9Q
processing loop. When finished, they release the semaphore and go back to
waiting for data.

This replaces the select() overhead, and also allows me to avoid the CPU
drainage associated with all the timeout-polling which was done previously.
It seems to work OK in practice, but the code's still shaky, so it's a
little hard to tell!

I need to get the local TCP client support running, so an inetd can start
watching for incoming network stuff. This will be a VSTa server, which will
be mountable as a filesystem. The directory will contain TCP port numbers,
as well as a clone entry for just picking up a free port number. A telnetd
is the obvious service to bring up first, after which I can finally start
connecting to VSTa directly from my Xterminal.

After telnet, I will bring up a remote filesystem service. This would be a
general service for running VSTa messages over a remote connection. Using
this, VSTa contributors can then mount the central RCS repository and check
their work into the source tree directly.

So... telnet, remote filesystem, and then V1.4 will finally be out!

                                                Regards,
                                                Andy
Received on Sun Aug 28 19:32:33 1994