Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!ucbvax!tness1.UUCP!uucp
From: uucp@tness1.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <8904041751.AA23894@rutgers.edu>
Date: 4 Apr 89 17:51:53 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 83

To: texbell!rutgers!comp-protocols-tcp-ip
Path: tness1!texbell!bigtex!milano!cs.utexas.edu!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Implementing TCP/IP outside of UNIX kernel?
Summary: Can be done, even efficiently, very few have
Message-ID: <803@aber-cs.UUCP>
Date: 3 Apr 89 20:09:06 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Distribution: eunet,world
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 68


In article <8903301431.AA19142@TIS.COM> balenson@TIS.COM (David M.
Balenson) writes:

    Is it possible to implement TCP/IP in a UNIX (Berkeley 4.{2,3},
    SunOS{3,4}) system OUTSIDE of the kernel?

If you want to create a TCP/IP server, you have two problems; how to
make it communicate with the network interface, and how with its
clients.  The first is fairly easy (euphemism). The second is easy, but
requires use of UNIX domain connections.

The server has a UNIX domain port on which it listens for requests to
open TCP/IP connections, etc... On receiving such a request, it creates
a new UNIX domain socket pair, and passes one end to the requestor
using the UNXI domain fd-in-a-message passing facility. It keeps a
table of TCP/IP addresses vs. UNXI domain connections opened.

Whenever the client writes something on its UNIX domain connection to
the server, the table is used in one way, and all data read from that
fd is sent off to the network interface using the associated TCP/IP
address; when data arrives from the network interface, the table is
used to map the TCP/IP address to the appropriate fd.

    I presume doing so would have a major impact on efficiency,

Yes and No. Of course a TCP/IP server (of for that matter, any protocol
server written in that way) means that on every message send you have
two task switches extra and daya copies, but for that there is no other
overhead. If TCP/IP is infrequently used, the server gets paged out, so
more real memory is available.

Overall I'd expect lower performance, but on an OS designed for this
style of implementation this need not be true.

    but it might be much easier to program.

Oh yes, of course. And, most importantly, you can have multiple
servers, and change them dynamically etc...

    Does anyone know o any such TCP/IP implementations?  Thanks.

The key to this whole business is to have the ability to pass fds in
messages from one process to another in the UNIX domain.

This facility has been copied from the excellently designed (by Richard
Rashid) Accent IPC facility, that can be now found in Mach. Also,
Edition 8/System V STREAMS have this ability, precisely for this
reason. Amoeba has an equivalent facility, even if I don't like
the way it is designed.

As far as I know Accent (or even Mach) network IPC is implemented
(optionally) using servers.

Note also that the unimplemented (and exceptionally difficult to
understand) user implemented domains facility of 42BSD (and in some way
wrappers) were "designed" (hackerly -- after all one of the principal
architects was Dr. Joy :-]) to enable this.

Overall, I'd suggest you look at MACH. It was designed (well -- after all
one of the principal architects was Dr. Rashid) around this idea.

You can even look at these fds that get passed around in messages
as capabilities, and build a fully distributed (and secure) capability
based system using this style.
-- 
Piercarlo "Peter" Grandi            |  ARPA: pcg%cs.aber.ac.uk@nss.cs.ucl.ac.uk
Dept of CS, UCW Aberystwyth         |  UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK  |  INET: pcg@cs.aber.ac.uk