Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!mitel!sce!cognos!dgbt!gandalf!ml
From: ml@gandalf.UUCP (Marcus Leech)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Implementing TCP/IP outside of UNIX kernel?
Summary: KA9Q TCP/IP as user-mode process under *NIX
Message-ID: <2454@gandalf.UUCP>
Date: 7 Apr 89 03:18:51 GMT
References: <8903301431.AA19142@TIS.COM> <2913@spdcc.SPDCC.COM>
Organization: Gandalf Data Ltd, Product Development
Lines: 31

In article <2913@spdcc.SPDCC.COM>, dyer@spdcc.COM (Steve Dyer) writes:
> 
> Phil Karn's KA9Q TCP/IP implementation can run as a user process
> under most flavors of UNIX, although I wager that only those folks
> without a TCP/IP implementation on a machine would bother.  I got it
> running under XENIX 386 with SLIP last year, although I never really beat
> on it hard.  At the time it was a monolithic program and didn't provide
> a socket application library, so it was mainly of tutorial interest to me.
> I haven't examined it lately.
> 
> It is available for non-commercial use via anonymous FTP on bellcore.com
> in the pub/ka9q directory.

Indeed.  I spent some time tweaking the KA9Q TCP/IP code to provide a BSD
  socket interface to applications.  The general notion was that TCP/UDP/IP
  and the "device handlers" would run in a single process, with a socket
  library to provide an interface to applications via named pipes. 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).  Faking that up using (for example) named
  pipes turned out to be more-or-less impossible.  The BSD socket library also
  provides sock_send () and sock_recv () (the names may be wrong--this is
  from memory).  Sock_send () and Sock_recv () could certainly be made to
  work with a named-pipe/FIFO implementation--provided you don't want read()
  and write () functionality also.
My conclusion is that it is better to place at least some of the networking
  code in the kernel.  My next crack at the KA9Q code will involve burying
  much of it in a "socket" device driver.  The device driver approach lends
  to easier integration into binary-only systems.  Most binary-only
  distributions don't allow the addition of system calls (and many other
  things).