Implementing Remote Procedure Calls

Andrew D. Birrell and Bruce J. Nelson

Xerox Palo Alto Research Center
Published: ACM Transactions on Computer Systems, Vol. 2, No. 1,
February 1984, pages 39-59.

Presented by Gary Huang

October 4, 2006
 Outline
 Introduction
Definitions, Mechanism, Structure, Environment, and Goals
 Binding
Naming & location, Interface (type, instance), and Binding Events
 Transport Protocol
Simple Calls and Complicated Calls
 Exceptions
 Processes - Optimizations
 Security
 Performance
 Conclusion
 1. Introduction
 1.1 Definitions
– Procedure Calls:
Transfer of control and data within a program
– Remote Procedure Calls (RPC):
Extend procedure calls across communication network
– Caller:
Environment that invokes RPC
– Callee:
Environment where procedure is to execute
 1. Introduction
 1.2 Mechanism
– Caller invoke a remote procedure and get suspended.
– Parameters are passed across the network to the Callee.
– Callee executes the procedure and produce results.
– Results are passed back to the caller and caller resumes
execution.

The authors wanted their implementation of this concept

to be relatively transparent to the programmer, so that
an RPC call would look and feel semantically like a
local procedure call.
 1. Introduction
 1.3 Structure
– Five pieces involved: the user, the user-stub, the RPC
communications package (RPCRuntime), the server-stub, and the
server.
 1. Introduction
 1.4 Environment
– Cedar:
developing and programming environment. Designed to be used on single-user
workstation. Also used for the construction of servers.
– Dorado:
Powerful machine with 24 bit virtual address space.
– Network:
2.94 megabit / sec Ethernet
– Protocol:
PUP
– Language:
Mesa (modified for the purpose of Cedar)
 1. Introduction
 1.5 Goals
– To make distributed computation (i.e. RPC) easy
– To make RPC communication efficient
– To provide secure communication with RPC
 2. Binding
 2.1 Naming and Location
– Naming: Specifying what machine a caller wants to
bind to.
– Location: Determining machine address of the callee
and specifying the procedure of the callee to be
invoked.
 2. Binding
 2.2 Interface
The caller needs to bind to a callee that can perform the remote procedure. This
is specified for the callee by the abstraction that the authors call an interface.

An interface consists of two components:

(1) Type – specify which interface the caller expects the callee to implement.
This concept is similar to an object oriented programming interface

(2) Instance – specify which particular implementer of an abstract interface is

desired. The instance is similar to an object that implements the OOP interface.

For example:
Type: mail server
Instance: a specific mail server of type mail server
 2. Binding
 2.3 Binding Events
 2. Binding
 2.3.1 Binding Events on Callee
– The caller binds to the callee by specifying something to uniquely identify
the callee (Naming in this case) and the callee’s location.
– But first the caller must find out what callees are available to handle the
request at the time of the procedure call. This is accomplished by a
database lookup:
– When a callee wishes to export an interface (make it available to callers),
it stores information about its interface in a network accessible database.
 2. Binding
 2.3.2 Binding Events on Caller
– The caller can then find the server callee in a database lookup:
– By specifying a particular instance of the desired interface type and
receiving location information about that instance, or
– By specifying the type of the interface and receiving a list of instances
that implement that type, and then iterating through them to find an
available match.
 3. Transport Protocol
The protocol used is intended for small, discrete chunks of
data, each of which can contain:
– Identifiers specifying caller, callee and call.
– Requested procedure and procedure arguments.
– Procedure results.
– Acknowledgements of received packets.
– Exception information.

Note: a caller may send requests for acknowledgement to the

callee, and as long as the callee responds, the caller may
wait indefinitely for results if the remote procedure
deadlocks or loops (just like local procedure calls).
 3. Transport Protocol
 3.1 Simple Calls
– Retransmission of a packet (either from caller or callee) occurs until an
acknowledgement is received.
– To the caller, a received packet containing the procedure results is viewed as an
acknowledgement.
– To the callee, a received packet containing a new procedure call is viewed as an
acknowledgement of the last procedure result sent.
– Each call by the caller carries a unique identifier so that subsequent calls to the
same procedure may be processed, but duplicate packets (from retransmissions) for
the same call will be discarded.
– Any given caller (process or thread on a given machine) will have at most one
outstanding remote call.
 3. Transport Protocol
 3.2 Complicated Calls
– An acknowledgement is expected for each packet sent.
– The caller may send additional packets, called probes, if the callee is taking a long
time to send results. After a certain threshold of probes sent without an
acknowledgment, the caller may raise an exception to the user about a
communication failure (again, a deadlocked callee can’t be detected).
– If the contents of a packet (procedure arguments or return results) are too large to fit
in one packet, multiple packets are sent with all but the last requiring
acknowledgement before transmission of the next. Each packet is sequentially
marked.
 4. Exceptions
 Exceptions for RPC are published in a server’s interface
along with all of the normal procedure calls.
 The remote call acts just like a local call, propagating any
exceptions back to the caller and any handlers that may be
waiting there to catch them.
 Callee can transmit an exception instead of result packet.
Exception packet is handled as new call packet.
 One additional exception is the RPCRuntime call failed
exception, raised by the callee. This exception may be
raised when there are communication difficulties.
 5. Processes - optimizations
Processes:
 A server callee maintains a pool of available server processes to handle incoming requests:
 This saves the cost of creating a new process to handle each request.
 A new process is created to handle a new request when the available processes are busy.
 To save on the costs of context switches between processes, each packet contains Ids of
calling and serving processes.

Optimizations:
 Minimize the costs of maintaining connections.
 Avoid costs of establishing and terminating connections.
 Reduce the number of process switches involved in a call .

Other Optimizations:
 Use the subsequence packet as ACK
 Bypass software layer if within same network
 6. Security
 Encryption end to end – based security for
calls
 Garpevine can be used as an authentication
server
 7. Performance
 Measurements made for remote calls between two Dorados computers
connected by Ethernet (2.94 Mbps)
 Ethernet shared with other users, but the network was lightly loaded.
 Did not use any encryption facilities.
 12000 calls made on each procedure.
 Interval timed is from the time the user invokes a local procedure to the return
of the procedure call.

Listed below are times for remote procedures to complete in comparison to local
procedure calls.
 7. Performance
 Performance Summary:
– Mainly RPC overhead – not due to local call
– For small packets, RPC overhead dominates
– For large packets, transmission time dominates
 8. Conclusion
 The authors concluded that the RPC
package was fully implemented and in use
by Cedar programmers.
 Implementations were created in a number
of other languages, including C and
SmallTalk.
 Should encourage development of new
distributed applications formerly considered
infeasible.
Discussion …