RPC Protocol and Language Specification
This appendix specifies a message protocol used in implementing the RPC package. The message protocol is specified with the XDR language. The companion appendix to this one is Appendix C, XDR Protocol Specification.
This appendix covers the following topics:
Protocol Overview
The RPC protocol provides for the following:
Unique specification of a procedure to be called.
Provisions for matching response messages to request messages.
Provisions for authenticating the caller to service and the reverse. In addition, the RPC package provides features that detect the following:
RPC protocol mismatches
Remote program protocol version mismatches
Protocol errors, such as incorrect specification of a procedure's parameters
Reasons why remote authentication failed
Consider a network file service composed of two programs. One program might handle high-level applications such as file-system access control and locking. The other might handle low-level file I/O and have procedures like read and write. A client machine of the network file service would call the procedures associated with the two programs of the service on behalf of some user on the client machine. In the client-server model, a remote procedure call is used to call the service.
RPC Model
The RPC model is similar to the local procedure call model. In the local case, the caller places arguments to a procedure in some well-specified location. The caller then transfers control to the procedure, and eventually regains control. At that point, the results of the procedure are extracted from a well-specified location, and the caller continues execution.
The RPC model is similar, in that one thread of control logically winds through two processes. One is the caller's process, the other is a server's process. Conceptually, the caller process sends a call message to the server process and waits for a reply message. The call message contains the procedure's parameters, among other information. The reply message contains the procedure's results, among other information. After the reply message is received, the results of the procedure are extracted, and the caller's execution is resumed.
On the server side, a process is dormant awaiting the arrival of a call message. When one arrives, the server process extracts the procedure's parameters, computes the results, sends a reply message, and then awaits the next call message.
Note that in this description only one of the two processes is active at any given time. However, the RPC protocol makes no restrictions on the concurrency model implemented. For example, an implementation might choose to have RPC calls be asynchronous, so that the client can do useful work while waiting for the reply from the server. Another possibility is to have the server create a task to process an incoming request so that the server is free to receive other requests.
Transports and Semantics
The RPC protocol is independent of transport protocols. That is, RPC disregards how a message is passed from one process to another. The protocol handles only specification and interpretation of messages.
RPC does not attempt to ensure transport reliability. Therefore, you must supply the application with information about the type of transport protocol used under RPC. If you tell the RPC service that it is running on top of a reliable transport such as TCP, most of the work is already done for the service. On the other hand, if RPC is running on top of an unreliable transport such as UDP, the service must devise its own retransmission and time-out policy. RPC does not provide this service.
Because of transport independence, the RPC protocol does not attach specific semantics to the remote procedures or their execution. Semantics can be inferred from, but should be explicitly specified by, the underlying transport protocol. For example, suppose RPC is running on top of an unreliable transport. If an application retransmits RPC messages after short timeouts receiving no reply, it can infer only that the procedure was executed zero or more times. If the application does receive a reply, it can infer that the procedure was executed at least once.
A server might choose to remember previously granted requests from a client and not regrant them to ensure some degree of execute-at-most-once semantics. A server can do this by using the transaction ID that is packaged with every RPC request. The main use of this transaction ID is by the RPC client for matching replies to requests. However, a client application can choose to reuse its previous transaction ID when retransmitting a request. The server application, checking this fact, can choose to remember this ID after granting a request and not regrant requests with the same ID. The server is not allowed to examine this ID in any other way except as a test for equality.
On the other hand, if using a reliable transport such as TCP, the application can infer from a reply message that the procedure was executed exactly once. If the application receives no reply message, it cannot assume the remote procedure was not executed. Note that even if a connection-oriented protocol like TCP is used, an application still needs timeouts and reconnection to handle server crashes.
Binding and Rendezvous Independence
The act of binding a client to a service is not part of the remote procedure call specification. This important and necessary function is left up to some higher-level software. The software can use RPC itself. See "rpcbind Protocol".
Implementers should think of the RPC protocol as the jump-subroutine (JSR) instruction of a network. The loader makes JSR useful, and the loader itself uses JSR to accomplish its task. Likewise, the network makes RPC useful, enabling RPC to accomplish this task.
The RPC protocol provides the fields necessary for a client to identify itself to a service and the reverse. Security and access control mechanisms can be built on top of the message authentication. Several different authentication protocols can be supported. A field in the RPC header specifies the protocol being used. You can find more information on authentication protocols in the section "Record-Marking Standard".
Program and Procedure Numbers
The RPC call message has three unsigned fields that uniquely identify the procedure to be called:
Remote program number
Remote program version number
Remote procedure number
Program numbers are administered by a central authority, as described in "Program Number Registration".
The first implementation of a program most likely has version number 1. Most new protocols evolve into better, stable, and mature protocols. Therefore, a version field of the call message identifies the version of the protocol that the caller is using. Version numbers make speaking old and new protocols through the same server process possible.
The procedure number identifies the procedure to be called. These numbers are documented in the individual program's protocol specification. For example, a file service's protocol specification might state that its procedure number 5 is read and procedure number 12 is write.
Just as remote program protocols can change over several versions, the RPC message protocol itself can change. Therefore, the call message also has in it the RPC version number, which is always equal to 2 for the version of RPC described here.
The reply message to a request message has enough information to distinguish the following error conditions:
The remote implementation of RPC does not speak protocol version 2. The lowest and highest supported RPC version numbers are returned.
The remote program is not available on the remote system.
The remote program does not support the requested version number. The lowest and highest supported remote program version numbers are returned.
The requested procedure number does not exist. This result is usually a caller-side protocol or programming error.
The server interprets the parameters to the remote procedure as garbage. Again, this result is usually caused by a disagreement about the protocol between client and service.
Provisions for authentication of caller to service and the reverse are provided as a part of the RPC protocol. The call message has two authentication fields, the credentials and verifier. The reply message has one authentication field, the response verifier. The RPC protocol specification defines all three fields to be the following opaque type.
enum auth_flavor {
AUTH_NONE = 0,
AUTH_SYS = 1,
AUTH_SHORT = 2,
AUTH_DES = 3,
AUTH_KERB = 4
/* and more to be defined */
};
struct opaque_auth {
enum auth_flavor; /* style of credentials */
caddr_t oa_base; /* address of more auth stuff */
u_int oa_length; /* not to exceed MAX_AUTH_BYTES */
};
|