High-level programming through remote procedure calls (RPC) provides logical client-to-server communication for network application development -- without the need to program most of the interface to the underlying network. With RPC, the client makes a remote procedure call that sends requests to the server, which calls a dispatch routine, performs the requested service, and sends back a reply before the call returns to the client.
RPC does not require the caller to know about the underlying network.
For example, a program can simply
call
rnusers
(a C routine that returns the number of users
on a remote machine) much like making a system call to
malloc.
You can make remote procedure calls from any language, and between different
processes on the same machine.
1.1 The RPC Model
The remote procedure call model is similar to that of the local model, which works as follows:
The caller places arguments to a procedure in a specific location (such as a result register).
The caller temporarily transfers control to the procedure.
When the caller gains control again, it obtains the results of the procedure from the specified location.
The caller then continues program execution.
The remote procedure call is similar, in that one thread of control logically winds through two processes -- that of the caller and that of the server:
The caller process sends a call message to the server process and blocks (that is, waits) for a reply message. The call message contains the parameters of the procedure and the reply message contains the procedure results.
When the caller receives the reply message, it gets the results of the procedure.
The caller process then continues executing.
On the server side, a process is dormant -- awaiting the arrival
of a call message.
When one arrives, the server process computes a reply
that it then sends back to the requesting client.
After this, the server
process becomes dormant again.
Figure 1-1
illustrates
this basic form of network communication with the remote procedure call.
Figure 1-1: Basic Network Communication with Remote Procedure Call
This figure shows a synchronous RPC call, in which only one of the two
processes is active at a given time.
The remote procedure call hides the
details of the network transport.
However, the RPC protocol does not restrict
the concurrency model.
For example, RPC calls may be asynchronous so that
the client can do another task while waiting for the reply from the server.
Another possibility is that the server could create a task to process a certain
type of request automatically, freeing it to service other requests.
Although
RPC provides a way to avoid programming the underlying network transport,
it still allows this where necessary.
1.2 RPC Procedure Versions
Each RPC procedure is uniquely defined by program and procedure numbers.
The
program number
specifies a group of related remote
procedures, each of which has a different
procedure number.
Each program also has a version number so that, when a minor change is made
to a remote service (adding a new procedure, for example), a new program number
does not have to be assigned.
When you want to call a procedure to find the
number of remote users, you must know the appropriate program, version, and
procedure numbers to use to contact the service.
This information can be found
in several sources.
For example, the
/etc/rpc
file lists
some RPC programs and the
rpcinfo
command lists the registered
RPC programs and corresponding version numbers running on a particular system.
Typically, a service provides a protocol description so that you can
write client applications that call the service.
The RPC Administrator at
Sun Microsystems, Inc.
has a list of programs that have been registered with
them (that is, have received port numbers from them) but you can write your
own local RPC programs.
Knowing the program and procedure numbers is useful
only if the program is running on a system that you have access to.
1.3 Using portmap to Determine the Destination Port Number of RPC Packets
The
portmap
network service command starts
automatically when a machine is booted.
As part of its initialization, a server
program calls its host portmap to create a portmap entry for its program and
version number.
To find the port of a remote program, a client sends an RPC
call message to a server portmap.
If the remote program is registered with
the portmap, it returns the relevant port number in an RPC reply message.
The client program can then send RPC call message packets to that remote
program port.
The
portmap
network service has a well-known (dedicated)
port.
Other network service port numbers can be assigned statically or dynamically
when they register their ports with the portmap of their host.
Refer to the
portmap(8)
reference page for more information about the port mapping service.
1.4 RPC Independence from Transport Protocol
The RPC protocol is concerned only with the specification and interpretation of messages; it is independent of transport protocols because it needs no information on how a message is passed among processes.
Also, RPC does not implement any kind of reliability -- the application itself must be aware of the transport protocol type underlying RPC. With a reliable transport, such as TCP/IP, the application need not do much else. However, an application must use its own retransmission and time-out policy if it is running on top of an unreliable transport, such as UDP/IP.
Because of transport independence, the RPC protocol does not actively interpret anything about remote procedures or their execution. Instead, the application infers required information from the underlying protocol (where such information should be explicitly specified). For example, if RPC is running on top of an unreliable transport (such as UDP/IP), and the application retransmits RPC messages after short time-outs, and if the application receives no reply, then it can infer only that a certain procedure was executed zero or more times. If it receives a reply, then the application infers that the procedure was executed at least once.
With a reliable transport, such as TCP/IP, the application can infer from a reply message that the procedure was executed exactly once, but if it receives no reply message, it cannot assume the remote procedure was not executed.
Note
Even with a connection-oriented protocol like TCP, an application still needs time-outs and reconnection to handle server crashes.
ONC RPC is currently supported on both UDP/IP and TCP/IP transports. The selection of the transport depends on the application requirements. The UDP transport, which is connectionless, is a good choice if the application has the following characteristics:
The procedures are idempotent; that is, the same procedure can be executed more than once without any side effects. For example, reading a block of data is idempotent; creating a file is not.
The size of both the arguments and results is smaller than the UDP packet size of 8K bytes.
The server is required to handle as many as several hundred clients. The UDP server can do so because it does not retain any information about the client state. By contrast, the TCP server holds state information for each open client connection and this limits its available resources.
TCP (connection-oriented) is a good transport choice if the application has any of the following characteristics:
The application needs a reliable underlying transport.
The procedures are non-idempotent.
The size of either the arguments or the results exceeds 8K bytes.
1.5 External Data Representation (XDR)
RPC can handle arbitrary data structures, regardless of the byte order or structure layout convention on a machine. It does this by converting them to a network standard called External Data Representation (XDR) before sending them over the wire. XDR is a machine-independent description and encoding of data that can communicate between diverse machines, such as a VAX, Sun workstation, IBM-PC, or Cray.
Converting from a particular machine representation to XDR format is
called
serializing; the reverse process is
deserializing.
1.6 Using rpcinfo to Get RPC Registration Information
The
rpcinfo
command reports current
RPC registration information known to
portmap; administrators
can use it to delete registrations.
The
rpcinfo
command
can also find the RPC services registered on a specific host and report their
port numbers and the transports for which the services are registered.
You
can also use it to call (through
ping) a program version
on a specific host using the TCP or UDP transport, and to report whether the
response was received.
For more information, see the
rpcinfo(8)
reference page.
1.7 Assigning Program Numbers
Program numbers are assigned in groups of
0x20000000
according to the following chart:
| 0x0 - 0x1fffffff | Defined by Sun |
| 0x20000000 - 0x3fffffff | Defined by user |
| 0x40000000 - 0x5fffffff | Transient |
| 0x60000000 - 0x7fffffff | Reserved |
| 0x80000000 - 0x9fffffff | Reserved |
| 0xa0000000 - 0xbfffffff | Reserved |
| 0xc0000000 - 0xdfffffff | Reserved |
| 0xe0000000 - 0xffffffff | Reserved |
Sun Microsystems administers the first range of numbers, which should
be identical for all ONC users.
An ONC RPC application for general use should
have an assigned number in this first range.
The second range of numbers is
for specific, user-defined customer applications, and is primarily for debugging
new programs.
The third, called the
Transient
group, is
reserved for applications that generate program numbers dynamically.
The
final groups are reserved for future use, and are not used.
To register a protocol specification, send a request
by network mail to
rpc@sun.com
or write to:
Include a compilable
rpcgen
.x
file describing your protocol; you will then receive a unique program number.
See
rpcgen(1)
for more information.
Some of the RPC program numbers are
in
/etc/rpc.