First, a daemon may be a multiprocess or single process daemon. A multiprocess daemon forks a subprocess for each client connection, and the parent process simply is in an infinite loop which continually accepts new connections and forks, after initially reading configuration files, allocating the socket via socket, associating it with a network port via bind, and optionally setting a maximum network connection queue length via listen. All the real work to provide service to the client is performed in the child processes. If switching to an authenticated user's account is needed, this is done in the child.
A single process daemon provides services to all clients in one process. Typically it must use select (or poll in Linux) to accept requests from all connected clients simultaneously. This is more complex to write, but can be more efficient since forking is expensive: process tables etc must be updated, and virtual memory pages must be marked copy-on-write, etc.
The other major design choice is whether to run a multiprocess daemon standalone or under inetd. A standalone daemon starts up at system boot, and runs in the background until the system is shut down. Since there are many network system services and many of them are only used very occasionally, this option uses up many process table slots and paging space.
Instead of doing this, the inetd ``master daemon'' was designed. It reads a configuration file inetd.conf, which specification all the less frequently used services and the programs which implement them. The inetd daemon starts at boot time, and creates a socket for every subdaemon listed in its configuration. When a client connects to one of these sockets, inetd forks a subprocess which runs the program for that service. This means that when the system is largely quiescent, only one process table slot is used, and the swap area would contain only inetd. The cost is that if the subdaemons need to read configuration files, they must do so every time they start up (contrast this with reading them a single time at startup for standalone daemons), so run time efficiency is not as good as with standalone daemons.
We will study in some detail how RPCs are implemented and look for security issues in a simple RPC system in the next assignment.
Boston student indicted: keystroke logging and fraud
A chapter on sunrpc.
email@example.com, last updated