Table of Contents OS/2
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:
The RPC concept can be simplified as follows:
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:
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.
Each call message contains three fields (unsigned integers):
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:
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:
Data (parameters) passed to the remote procedure.
Several replies exist, depending on the action taken:
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.
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.
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:
VM provides an RPC application programming interface (API) for both the client and the server side.
For the client side, there are calls to:
For the server side, there are calls to:
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.
MVS TCP/IP provides the same RPC support as VM TCP/IP.
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.
Full client and server RPC functions are available in AIX/6000.
The following programming interfaces are available:
For details about the RPC programming interface for AIX, see the documentation available for each implementation and AIX Distributed Environments, GG24-3489.
Full RPC client and server functions are provided in the AIX/ESA environment.
Full RPC client and server functions are provided in the OS/2 environment.
Table of Contents Network
Computing System (NCS)