In this document, we will discuss clients, calls, servers, replies, services, programs, procedures, and versions.  Each remote procedure call has two sides: an active client side that sends the call to a server, which sends back a reply.  A network service is a collection of one or more remote programs.  A remote program implements one or more remote procedures; the procedures, their parameters, and results are documented in the specific program’s protocol specification.  A server may support more than one version of a remote program in order to be compatible with changing protocols.

For example, a network file service may be composed of two programs. One program may deal with high-level applications such as file system access control and locking.  The other may deal with low-level file input and output and have procedures like “read” and “write”.  A client of the network file service would call the procedures associated with the two programs of the service on behalf of the client.

The Sun RPC protocol is based on the remote procedure call model, which is similar to the local procedure call model.  In the local case, the caller places arguments to a procedure in some well-specified location (such as a register window).  It then transfers control to the procedure, and eventually regains control.  At that point, the results of the procedure are extracted from the well-specified location, and the caller continues execution.

The remote procedure call model is similar.  One thread of control logically winds through two processes: the caller’s process, and a server’s process.  The caller process first sends a call message to the server process and waits (blocks) for a reply message.  The call message includes the procedure’s parameters, and the reply message includes the procedure’s results.  Once the reply message is received, the results of the procedure are extracted, and 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.

In this model, only one of the two processes is active at any given time.  However, this model is only given as an example.  The Sun RPC protocol makes no restrictions on the concurrency model implemented, and others are possible.  For example, an implementation may choose to have RPC calls be asynchronous, so that the client may do useful work while waiting for the reply from the server.  Another possibility is to have the server create a separate task to process an incoming call so that the original server can be free to receive other requests.

The RPC protocol can be implemented on several different transport protocols.  The RPC protocol does not care how a message is passed from one process to another, but only with specification and interpretation of messages.  On the other hand, the application may wish to obtain information about (and perhaps control over) the transport layer through an interface.

For example, the transport protocol may impose a restriction on the maximum size of RPC messages, or it may be stream-oriented like TCP with no size limit.  The client and server must agree on their transport protocol choices, through a mechanism.

It is important to point out that RPC does not try to implement any kind of reliability and that the application may need to be aware of the type of transport protocol underneath RPC.  If it knows it is running on top of a reliable transport such as TCP, then most of the work is already done for it.  On the other hand, if it is running on top of an unreliable transport such as UDP, it must implement its own time-out, retransmission, and duplicate detection policies as the RPC layer does not provide these services.

Because of transport independence, the RPC protocol does not attach specific semantics to the remote procedures or their execution requirements.  Semantics can be inferred from (but should be explicitly specified by) the underlying transport protocol.  For example, consider RPC running on top of an unreliable transport such as UDP.  If an application retransmits RPC call messages after timeouts, and does not receive a reply, it cannot infer anything about the number of times the procedure was executed.  If it does receive a reply, then it can infer that the procedure was executed at least once.

A server may wish to remember previously granted requests from a client and not regrant them in order to insure some degree of execute-at-most-once semantics.  A server can do this by taking advantage of the transaction ID that is packaged with every RPC message.  The main use of this transaction is by the client RPC layer in matching replies to calls.  However, a client application may choose to reuse its previous transaction ID when retransmitting a call.  The server may choose to remember this ID after executing a call and not execute calls with the same ID in order to achieve some degree of execute-at-most-once semantics.  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, but if it 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 time-outs and reconnection to handle server crashes.

As previously stated, authentication parameters are opaque but open-ended to the rest of the RPC protocol.  This section defines some “flavors” of authentication implemented at (and supported by) Sun.  Other sites are free to invent new authentication types, with the same rules of flavor number assignment as there is for program number assignment.