Introduction to TI-RPC
This section provides an overview of TI-RPC, also known as Sun RPC. The information presented is most useful to someone new to RPC. See the Glossary for the definition of the terms used in this guide.
Topics covered in this chapter include:
What Is TI-RPC?
TI-RPC is a powerful technique for constructing distributed, client-server based applications. It is based on extending the notion of conventional, or local, procedure calling so that the called procedure need not exist in the same address space as the calling procedure. The two processes might be on the same system, or they might be on different systems with a network connecting them.
By using RPC, programmers of distributed applications avoid the details of the interface with the network. The transport independence of RPC isolates the application from the physical and logical elements of the data communications mechanism and enables the application to use a variety of transports.
Figure 2-1 How RPC Works
An RPC is analogous to a function call. Like a function call, when an RPC is made, the calling arguments are passed to the remote procedure and the caller waits for a response to be returned from the remote procedure.
Figure 2-1 shows the flow of activity that takes place during an RPC call between two networked systems. The client makes a procedure call that sends a request to the server and waits. The thread is blocked from processing until either a reply is received, or the request times out. When the request arrives, the server calls a dispatch routine that performs the requested service, and sends the reply to the client. After the RPC call is completed, the client program continues.
RPC specifically supports network applications. TI-RPC runs on available networking mechanisms such as TCP/IP. Other RPC standards are OSF DCE (based on Apollo's NCS system), Xerox Courier, and Netwise.
TI-RPC Issues
A number of issues help to characterize a particular RPC implementation.
How are parameters and results passed?
How is binding carried out?
How are transport protocols dealt with?
What are the call semantics?
What data representation is used?
Parameter Passing
TI-RPC allows a single parameter to be passed from client to server. If more than one parameter is required, the components can be combined into a structure that is counted as a single element. Information passed from server to client is passed as the function's return value. Information cannot be passed back from server to client through the parameter list.
Binding
The client must know how to contact the service. The two necessary aspects are finding out which host the server is on, and then connecting to the actual server process. On each host, a service called rpcbind manages RPC services. TI-RPC uses the available host-naming services, such as the hosts and ipnodes file, NIS+, and DNS, to locate a host.
Transport Protocol
The transport protocol specifies how the call message and the reply message are transmitted between client and server. TS-RPC used TCP and UDP as transport protocols, but the current version of TI-RPC is transport independent, so it works with any transport protocol.
Call Semantics
Call semantics define what the client can assume about the execution of the remote procedure; in particular, how many times the procedure was executed. These semantics are important in dealing with error conditions. The three alternatives are exactly once, at most once, and at least once. ONC+ provides at least once semantics. Procedures called remotely are idempotent: they should return the same result each time they are called, even through several iterations.
Data Representation
Data representation describes the format used for parameters and results as they are passed between processes. To function on a variety of system architectures, RPC requires a standard data representation. TI-RPC uses external data representation (XDR). XDR is a machine-independent data description and encoding protocol. Using XDR, RPC can handle arbitrary data structures, regardless of the byte orders or structure layout conventions of the different hosts. For a detailed discussion of XDR, see Appendix A, XDR Technical Note and Appendix C, XDR Protocol Specification.
Program, Version, and Procedure Numbers
A remote procedure is uniquely identified by the triple:
Program number
Version number
Procedure number
The program number identifies a group of related remote procedures, each of which has a unique procedure number.
A program can consist of one or more versions. Each version consists of a collection of procedures that are available to be called remotely. Version numbers enable multiple versions of an RPC protocol to be available simultaneously.
Each version contains a number of procedures that can be called remotely. Each procedure has a procedure number.
"Program and Procedure Numbers" lists the range of values and their significance and tells you how to have a program number assigned to your RPC program. A list of mappings of RPC service name to program number is available in the RPC network database /etc/rpc.
Overview of Interface Routines
RPC has multiple levels of application interface to its services. These levels provide different degrees of control balanced with different amounts of interface code to implement, in order of increasing control and complexity. This section gives a summary of the routines available at each level.
Simplified Interface Routines
The simplified interfaces are used to make remote procedure calls to routines on other machines, and specify only the type of transport to use. The routines at this level are used for most applications. Descriptions and code samples are in the section "Simplified Interface".
Table 2-1 RPC Routines--Simplified Level
Routine | Function |
|---|---|
Registers a procedure as an RPC program on all transports of the specified type | |
rpc_call() | Remotely calls the specified procedure on the specified remote host |
Broadcasts a call message across all transports of the specified type |