RPC Network Services

Much of the client/server interaction over a network is implemented using the RPC (Remote Procedure Call) protocol, which is implemented as a set of library calls that make network access transparent to the client and server. RPC specifies and interprets messages but does not concern itself with transport protocols; it runs on top of TCP/IP and UDP/IP. Services that use RPC include NFS and NIS. RPC was developed by Sun as ONC RPC (Open Network Computing Remote Procedure Calls) and differs from Microsoft RPC.

In the client/server model, a client contacts a server on a specific port to avoid any mixup between services, clients, and servers. To avoid maintaining a long list of port numbers and to enable new clients/servers to start up without registering a port number with a central registry, when a server that uses RPC starts, it specifies the port it expects to be contacted on. RPC servers typically use port numbers that have been defined by Sun. If a server does not use a predefined port number, it picks an arbitrary number.

The server then registers this port with the RPC portmapper (the rpcbind [FEDORA] or portmap [RHEL] daemon) on the local system. The server tells the daemon which port number it is listening on and which RPC program numbers it serves. Through these exchanges, the portmapper learns the location of every registered port on the host and the programs that are available on each port. The rpcbind/portmap daemon, which always listens on port 111 for both TCP and UDP, must be running to make RPC calls.

The /etc/rpc file maps RPC services to RPC numbers. The /etc/services file lists system services.

The sequence of events for communication between an RPC client and server occurs as follows:

1. The client program on the client system makes an RPC call to obtain data from a (remote) server system. (The client issues a “read record from a file” request.)

2. If RPC has not yet established a connection with the server system for the client program, it contacts rpcbind/portmap on port 111 of the server and asks which port the desired RPC server is listening on (for example, rpc.nfsd).

3. The rpcbind/portmap daemon on the remote server looks in its tables and returns a UDP/TCP port number to the local system, the client (typically 2049 for nfs).

4. The RPC libraries on the server system receive the call from the client and pass the request to the appropriate server program. The origin of the request is transparent to the server program. (The filesystem receives the “read record from file” request.)

5. The server responds to the request. (The filesystem reads the record.)

6. The RPC libraries on the remote server return the result over the network to the client program. (The read record is returned to the calling program.)

Because standard RPC servers are normally started by the xinetd daemon, the portmap daemon must be started before the xinetd daemon is invoked. The init scripts make sure portmap starts before xinetd. You can confirm this sequence by looking at the numbers associated with /etc/rc.d/*/S*portmap and /etc/rc.d/*/S*/xinetd. If the portmap daemon stops, you must restart all RPC servers on the local system.

Source of Information : Prentice Hall A Practical Guide to Fedora and Red Hat Enterprise Linux 5th Edition