CSE 127: Lecture 9

The topics covered in this lecture are Network Services RPCs

Network Services and System Daemons

Network-based services are provided by daemon processes which accept client connections over the network. Examples are sshd, inetd, ftpd, etc. There are several common designs.

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.

Remote Procedure Calls

Remote Procedure Calls (RPCs) are an abstraction that makes it easier for application programmers to build distributed applications. Rather than exchanging messages asynchronously, a client sends a request message to the server and then waits for a response message. The idea is that a stub procedure at the client is used (usually created by a stub generator from an intermediate interface definition language description of the RPC). The stub procedure takes care of copying the input arguments into a message (this is called marshalling), sending it, and then blocking the process (or thread) awaiting the reply. A corresponding stub exists on the server side, where a main loop accepts messages from clients, figures out what the request is (an RPC number is located in the message header), parses the message for the input arguments for the request (unmarshalling them), and calls the actual server-side procedure that implements the request. When that procedure returns, output arguments and return values are packed into the reply message which is sent back to the client.

We will study in some detail how RPCs are implemented and look for security issues in a simple RPC system in the next assignment.

Links

These are links additional security-related information. Exploring them is optional unless otherwise stated.

Boston student indicted: keystroke logging and fraud

A chapter on sunrpc.

bsy+cse127.w03@cs.ucsd.edu, last updated Fri Feb 14 13:24:20 PST 2003. Copyright 2003 Bennet Yee.
email bsy.