RFC 1831 (rfc1831) - Page 3 of 18
RPC: Remote Procedure Call Protocol Specification Version 2
Alternative Format: Original Text Document
RFC 1831 Remote Procedure Call Protocol Version 2 August 1995
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 ONC 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.
There are a few important ways in which remote procedure calls differ
from local procedure calls:
1. Error handling: failures of the remote server or network must
be handled when using remote procedure calls.
2. Global variables and side-effects: since the server does not
have access to the client's address space, hidden arguments cannot
be passed as global variables or returned as side effects.
3. Performance: remote procedures usually operate one or more
orders of magnitude slower than local procedure calls.
4. Authentication: since remote procedure calls can be transported
over unsecured networks, authentication may be necessary.
Authentication prevents one entity from masquerading as some other
entity.
The conclusion is that even though there are tools to automatically
generate client and server libraries for a given service, protocols
must still be designed carefully.
Srinivasan Standards Track