TCP/IP Tutorial and Technical Overview

Table of Contents OS/2
TCP/IP Tutorial and Technical Overview

4.10 Remote Procedure Call (RPC)

Figure: Remote Procedure Call (RPC)

Sun-RPC is a proposed standard protocol. Its status is elective.

Remote Procedure Call is a standard developed by SUN Microsystems and used by many vendors of UNIX systems. The current Sun-RPC specification can be found in RFC 1057 - RPC: Remote Procedure Call Protocol Specification Version 2.

The Remote Procedure Call protocol is an application programming interface (API) available for developing distributed applications. It allows programs to call subroutines that are executed at a remote system. The caller program (called a client) sends a call message to the server process, and waits for a reply message. The call message includes the procedure's parameters and the reply message contains the procedure's results.

Sun RPC consists of the following parts:

RPCGEN: a compiler that takes the definition of a remote procedure interface, and generates the client stubs and the server stubs.
XDR (eXternal Data Representation): a standard way of encoding data in a portable fashion between different systems. It imposes a big-endian byte ordering and the minimum size of any field is 32 bits. This means that both the client and the server have to perform some translation.
A run-time library.

4.10.1 RPC Concept

The RPC concept can be simplified as follows:

The caller process sends a call message and waits for the reply.
On the server side a process is dormant awaiting the arrival of call messages. When one arrives, the server process extracts the procedure parameters, computes the results and sends them back in a reply message.

See Figure - RPC for a conceptual model of RPC.

This is only a possible model, as the SUN RPC protocol doesn't put restrictions on the concurrency model. In the model above, the caller's execution blocks until a reply message is received. Other models are possible; for instance, the caller may continue processing while waiting for a reply, or the server may dispatch a separate task for each incoming call so that it remains free to receive other messages.

The remote procedure calls differ from local procedure calls in the following ways:

Use of global variables as the server has no access to the caller program's address space.
Performance may be affected by the transmission times.
User authentication may be necessary.
Location of server must be known.

Figure: RPC - Remote Procedure Call Model

4.10.1.1 Transport

The RPC protocol can be implemented on any transport protocol. In the case of TCP/IP, it can use either TCP or UDP as the transport vehicle. The type of the transport is a parameter of the RPCGEN command. In case UDP is used, remember that this does not provide reliability, so it will be up to the caller program itself to ensure this (using timeouts and retransmissions, usually implemented in RPC library routines). Note that even with TCP, the caller program still needs a timeout routine to deal with exceptional situations such as a server crash.

The call and reply message data is formatted to the XDR standard.

4.10.1.2 RPC Call Message

The RPC call message consists of several fields:

Program and procedure numbers
Each call message contains three fields (unsigned integers):
- Remote program number
- Remote program version number
- Remote procedure number
that uniquely identify the procedure to be executed. The remote program number identifies a functional group of procedures, for instance a file system, which would include individual procedures like "read" and "write". These individual procedures are identified by a unique procedure number within the remote program. As the remote program evolves, a version number is assigned to the different releases.
Each remote program is attached to an internet port. The number of this port can be freely chosen, except for the reserved "well-known-services" port numbers. It is evident that the caller will have to know the port number used by this remote program.
Assigned program numbers:

00000000 - 1FFFFFFF
defined by Sun
20000000 - 3FFFFFFF
defined by user
40000000 - 5FFFFFFF
transient (temporary numbers)
60000000 - FFFFFFFF
reserved
Authentication fields
Two fields, credentials and verifier, are provided for the authentication of the caller to the service. It is up to the server to use this information for user authentication. Also, each implementation is free to choose the varieties of supported authentication protocols. Some authentication protocols are:
- Null authentication.
- UNIX authentication. The callers of a remote procedure may identify themselves as they are identified on the UNIX system.
- DES authentication. In addition to user ID, a timestamp field is sent to the server. This timestamp is the current time, enciphered using a key known to the caller machine and server machine only (based on the secret key and public key concept of DES).
Procedure parameters
Data (parameters) passed to the remote procedure.

4.10.1.3 RPC Reply Message

Several replies exist, depending on the action taken:

SUCCESS: procedure results are sent back to the client.
RPC_MISMATCH: server is running another version of RPC than the caller.
AUTH_ERROR: caller authentication failed.
PROG_MISMATCH: if program is unavailable or if the version asked for does not exist or if the procedure is unavailable.

For a detailed description of the call and reply messages, see RFC 1057 - RPC: Remote Procedure Call Protocol Specification Version 2, which also contains the type definitions (typedef) for the messages in XDR language.

4.10.1.4 Portmap or Portmapper

As stated above, the caller has to know the exact port number used by a specific RPC program to be able to send a call message to it. Portmap is a server application that will map a program number and its version number to the internet port number used by the program. Because Portmap is assigned a reserved (well-known service) port number 111, all the caller has to do is ask the Portmap service on the remote host about the port used by the desired program. See Figure - Portmap.

Portmap only knows about RPC programs on the host it runs on (only RPC programs on the local host).

In order for Portmap to know about the RPC program, every RPC program should register itself with the local Portmap when it starts up. It should also cancel its registration when it closes down.

Normally, the calling application would contact Portmap on the destination host to obtain the correct port number for a particular remote program, and then send the call message to this particular port. A variation exists when the caller also sends the procedure data along to Portmap and then the remote Portmap directly invokes the procedure.

Figure: Portmap - Informs the caller which port number a program on its host occupies.

4.10.1.5 RPCGEN

RPCGEN is a tool that generates C code to implement an RPC protocol. The input to RPCGEN is a file written in a language similar to C, known as the RPC language. Assuming that an input file named proto.x is used, RPCGEN produces the following output files:

A header file called proto.h that contains common definitions of constants and macros
Client stub source file, protoc.c
Server stub source file, protos.c
XDR routines source file, protox.c

4.10.2 Implementations

4.10.2.1 VM

VM provides an RPC application programming interface (API) for both the client and the server side.

For the client side, there are calls to:

Invoke (send) a remote procedure call.
Query the remote Portmap application about ports.

For the server side, there are calls to:

Attach the program to a port number.
Register the program and its port number with the local Portmap application.
Cancel registration with Portmap.
Send a reply back to the caller.

This programming interface is available for programs written in the C language. In addition to this, the XDR type definitions are shipped with the product, in the form of C header files.

The rpcinfo command can be used to display the list of currently active RPC server programs on a host.

4.10.2.2 MVS

MVS TCP/IP provides the same RPC support as VM TCP/IP.

4.10.2.3 OS/400

The RPC programming interface is included in the licensed program offering DCE Base Services/400 Version 3.

The RPC facility consists of an application development tool and a runtime library. When developing a DCE application, you simply define an RPC interface between the client application and the server application. DCE uses the DCE interface definition language (IDL) to define this interface. The language is similar to ANSI C definitions. The application development tool consists of an IDL compiler that compiles your interface definitions into portable C-language source code. This IDL-generated source code can be compiled with your application code using the ILE C compiler and linked to the DCE runtime library to form the distributed application.

To allow RPC to participate in an open distributed computing environment, the RPC interface must be uniquely identified. This is accomplished by giving the interface a universal unique identifier (UUID). A UUID is a hexadecimal number that contains information that makes it unique from all other UUIDs. The application development tool also includes a UUID generator that generates and automatically includes a UUID in the RPC interface description.

The runtime service implements the network protocols by which the client and server sides of an application communicate.

4.10.2.4 AIX/6000

Full client and server RPC functions are available in AIX/6000.

The following programming interfaces are available:

RPCGEN protocol compiler.
High layer interface - This interface is actually a method for using RPC routines, rather than a part of RPC proper. An example is rnusers().
Middle layer interface - This interface is RPC proper. That is, the programmer only needs to make RPC calls, but need not consider details about sockets or other low-level implementation mechanisms. On this interface, RPC does not allow timeout specifications, choice of transport, or process control in case of errors. Nor does it support multiple types of call authentication. Example routines are registerrpc(),callrpc() and svc_run().
Low layer interface - This interface allows the programmer greatest control but also requires more low-level coding efforts. This interface may be necessary if for example, the programmer needs to use TCP instead of UDP (used by the two higher layers). Example routines are svctcp_create() and clnt_call().

For details about the RPC programming interface for AIX, see the documentation available for each implementation and AIX Distributed Environments, GG24-3489.