Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!inria!mirsa!huitema
From: huitema@mirsa.inria.fr (Christian Huitema)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Implementing TCP/IP outside of UNIX kernel?
Message-ID: <154@mirsa.inria.fr>
Date: 13 Apr 89 09:11:10 GMT
References: <15285@bellcore.bellcore.com>
Organization: INRIA, Sophia Antipolis. France
Lines: 48

From article <15285@bellcore.bellcore.com>, by karn@jupiter (Phil R. Karn):
> ........... 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....

The same problem was encountered with a lot of the early implementations of 
the OSI transport. A number of them were done outside the kernel, either 
because the programmers had not access to the kernel at all, or because they
wanted to minimize the development of kernel code, or because they barked at
increasing the kernel space by umpteen kbytes for just a seldom used
protocol. Most implementations came with a single process that would
interface the network (X.25 or Ether, in most cases), manage the protocol
engine and provide some form of interface with the user processes. Some used
named pipes, some others used their own form of ``communication drivers'',
whose design was not unlike that of pseudo ttys. All ran into a number of
problems:

1- Compatibility with the socket library is extremely hard to achieve. In
particular,  sockets can be dynamically created by the ``socket'' and
``accept'' call; this feature is embedded in most of the Berkeley
applications, and you have to devise work arounds. 

2- Performance is poor, as each packet will wake up the transport process
first, then the application process. Switching from one task to another is
by no way what Unix does best. Moreover, there could be nasty side effects,
like the transport process using a lot of CPU, thus getting lower and lower
priority in the Unix scheduler.

There is a way to circumvent the secund point, which is to provide a
subroutine implementation of the transport, for architectures where a single
user process serves multiple connexions. The key is that the application
must be the sole user of a particular network address, and that it should be
ready to multiplex its various connexion contexts, e.g. using some form of
light weight process. It should also call the transport manager at
reasonable intervals, so that the protocol machine would not break.

This architecture is commonly used for information servers, which need to
handle a very large number of connexions (several hundreds), and would be
penalized by the standard UNIX architecture: either the number of connexions
would be limited by the maximum number of file descriptor per task, or by
the maximum number of FD per system, or the number of tasks would become so
large that the system would be inefficient, and the interprocess
synchronisation a nightmare. Actually, it could be a very reasonable design
for an X-Window terminal.

Christian Huitema