Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!bellcore!jupiter!karn
From: karn@jupiter (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Implementing TCP/IP outside of UNIX kernel?
Message-ID: <15285@bellcore.bellcore.com>
Date: 12 Apr 89 21:52:17 GMT
References: <8903301431.AA19142@TIS.COM> <2913@spdcc.SPDCC.COM> <2454@gandalf.UUCP>
Sender: news@bellcore.bellcore.com
Reply-To: karn@jupiter.bellcore.com (Phil R. Karn)
Organization: Bell Communications Research, Inc
Lines: 39

>Indeed.  I spent some time tweaking the KA9Q TCP/IP code to provide a BSD
>  socket interface to applications.  [...]  There's a
>  gotcha with sockets, however.  Sockets are objects upon which it is legal
>  to do read () and write () calls (a socket looks like a file descriptor that
>  is both readable and writeable).

I recently rewrote my package to use a very simple non-pre-emptive
multitasking kernel. It provides what I believe are generally known as
"lightweight processes" -- tasks share external and static variables,
but they have private stacks and therefore private automatic variables.
Tasks are switched with the C-library setjmp/longjmp functions --
simple, effective and about as portable as such code can be. As before,
heavy use is made of the storage allocator to create per-process
data structures that must be maintained between calls to a function or
shared across multiple functions.

This made it possible to implement a socket layer as a "veneer" on top
of the older upcall mechanism, and to rewrite all of the applications in
terms of the new socket interface. (I was amazed at how much simpler the
FTP client became!)

Pretty much the whole set of Berkeley socket calls are provided with
similar semantics, albeit with the caveat that I didn't test Berkeley's
code to see exactly how it behaved in all sorts of strange exception
conditions. In doing this job (now the so-called "NOS" version) I ran
smack into the problem you report. I would have very much liked to use a
common file descriptor space for both sockets and regular file
descriptors, but this just didn't seem possible to do in a portable
manner. So the socket descriptor space is distinct, and you can't do
read, write or close calls on socket descriptors (a separate call,
close_s, is provided for closing sockets).

A snapshot of my current development work can be found on
flash.bellcore.com under /pub/ka9q/src.arc. An executable is in
/pub/ka9q/net.exe.  Please don't pepper me with a lot of questions, it's
still being polished and I haven't had time to write the documentation
yet.

Phil