Implementing Remote Procedure Calls

1
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

2
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

3
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

4
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.

5
1. Introduction

• 1.3 Structure
• Five pieces involved the user, the user-stub,
  the RPC communications package (RPCRuntime), the
  server-stub, and the server.

6
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)

7
1. Introduction

• 1.5 Goals
• To make distributed computation (i.e. RPC) easy
• To make RPC communication efficient
• To provide secure communication with RPC

8
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.

9
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 exampleType mail serverInstance a
  specific mail server of type mail server

10
2. Binding

• 2.3 Binding Events

11
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 callees 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.

12
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.

13
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).

14
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.

15
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
  cant 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.

16
4. Exceptions

• Exceptions for RPC are published in a servers
  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.

17
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

18
6. Security

• Encryption end to end based security for calls
• Garpevine can be used as an authentication server

19
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.

20
7. Performance

• Performance Summary
• Mainly RPC overhead not due to local call
• For small packets, RPC overhead dominates
• For large packets, transmission time dominates

21
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.

22
Discussion