Managing NFS and NIS, 2nd Edition - Mike Eisler [18]
The XDR and RPC layers complete the foundation necessary for a client/server distributed computing relationship. NFS and NIS are client/server applications, which means they sit at the top layer of the protocol stack and use the XDR and RPC services. To complete this introduction to network services, we'll take a look at the two mechanisms used to start and maintain servers for various network services.
Internet and RPC server configuration
The XDR and RPC services are useful for applications that need to exchange data structures over the network. Each new RPC request contains all required information in its XDR-encoded arguments, just as a local procedure call gets its inputs from passed-in arguments. RPC services are usually connectionless services because RPC requests do not require the creation of a long-lived network connection between the client and server. The client communicates with the server to send its request and receive a reply, but there is no connection or environment for the communication.
There are many other network services, such as telnet and ftp, that are commonly referred to as the Internet or ARPA services. They are part of the original suite of utilities designed for use on the Internet. Internet services are generally based on the TCP protocol and are connection-oriented — the service client establishes a connection to a server, and data is then exchanged in the form of a well-ordered byte stream. There is no need for RPC or XDR services, since the data is byte-oriented, and the service defines its own protocols for handling the data stream. The telnet service, for example, has its own protocol for querying the server about end-of-line, terminal type, and flow control conventions.
Note that RPC services are not required to be connectionless. RPC can be run over TCP, in a connection-oriented fashion. The TCP transport protocol may be used with RPC services whenever a large amount of data needs to be transferred. NIS, for example, uses UDP (in connectionless mode) for most of its operations, but switches to TCP whenever it needs to transfer an entire database from one machine to another. NFS supports either TCP or UDP for all its operations.
Most Internet services are managed by a super-daemon called inetd that accepts requests for connections to servers and starts instances of those servers on an as-needed basis. Rather than having many server processes, or daemons, running on each host, inetd starts them as requests arrive. Clients contact the inetd daemon on well-known port numbers for each service. These port numbers are published in the /etc/services file.
inetd sets up a one-to-one relationship between service clients and server-side daemons. Every rlogin shell, for example, has a client side rlogin process (that calls inetd upon invocation) and a server-side in.rlogind daemon that was started by inetd. In this regard, inetd and the services it supports are multi-threaded: they can service multiple clients at the same time, creating a new separate connection (and state information) for each client. A new server instance, or thread, is initiated by each request for that service, but a single daemon handles all incoming requests at once.
Only traffic specific to a single session moves over the connection between a client and its server. When the client is done with the service, it asks the server to terminate its connection, and the server daemon cleans up and exits. If the server prematurely ends the connection due to a crash, for example, the client drops its end of the connection as well.
Some RPC services