Remote Procedure Calls Adam Smith, Rodrigo Groppa, and Peter Tonner

Outline I. Introduction II. Binding III. Packet Level Protocol IV. Performance V. Status And Discussions

Introduction

def: Remote Procedure Calls Procedure call that executes remotely (in this paper) single threaded – caller waits for return of function Abstraction of message passing Simple syntax and simple semantics – user should not be concerned with implementation

Environment (old computers) Cedar programming environment Dorados – 24 bit virtual address space – 80 Mb disk Mesa, Smalltalk, InterLisp PUP protocol family

Aims “Make distributed computation easy” Make remote programming nearly as easy as making local procedure calls Keep efficiency within 5 times the network latency Use secure communication with encryption

Fundamental Decisions RPC vs Message Passing – same problems, same solutions – Mesa: based on procedural control flow Fork adds no significant complexity No shared address space – requires extension of address space with network location – out of solution scope

Terms of RPC Caller and callee Interface Modules – list of functions with parameter and return types Export – define functions Import – use functions of an interface Program Modules

Structure User, User Stub, RPCRuntime, Server, Server Stub Stub – Pack and unpack arguments and results RPCRuntime – exists on both machines – transmit messages from caller to callee

More Structure

II. Binding Naming – specify what a client should be bound to by the RPC Runtime Location – Caller locates callee and invokes a procedure

Naming Check whether an importer is connecting to an appropriate exporter Type – specify the interface of a callee – think Java/C# classes Instance – implements the Type interface

Locating an Appropriate Exporter RPCRuntime links caller and callee modules – stores machine locations in a Grapevine database Exporter (implementing an interface) calls ExportInterface – stores interface and procedure callback Importer (uses an interface instance) calls ImportInterface – must include interface type – instance identifier is optional

Exporting and Importing

Packet Level Transport Protocol

Requirements They believe there are performance gains available if they were to design and implement a transport protocol specially for RPC, because of the nature of the system they were creating. They believed that performance could possibly be improved by a factor of ten.

Requirements One aim they emphasized in their protocol design was minimizing the amount of real- time taken between initiating a call and getting results. With protocols for large amount of data transfer this isn’t important because so much time will be spent transferring the data. They also wanted to minimize the load given to a server by a large number of users.

Requirements They wanted their machines to be able to handle a large number of clients, and it wouldn’t be feasible to require a large amount of state info or costly connection handshaking for this situation.

Requirements They wanted to guarantee that if the call returns to the user that the user can be certain that the procedure in the server has been executed precisely once. Otherwise, he could expect an exception to have been reported and the procedure would have been executed either once or not at all, without being informed of which actually happened.

Requirements There is no upper bound on how long it will wait for results. Calls will be aborted if there is a communication problem or a crash, but not if the server stops or loops. They did this to mirror how local procedure calls work.

Simple Calls To make a call, the caller sends a call packet containing a call identifier, data specifying the desired procedure, and the arguments. When the callee machine receives this packet, the appropriate procedure is invoked. When the procedure returns, a result packet containing the same call identifier, and the results, is sent back to the caller.

Simple Calls

Complicated Calls

Exception Handling in Mesa Exceptions are called signals, and when an exception is raised, the runtime system dynamically scans the call stack to determine if there is a catch phrase for the exception. If there is, then the catch phrase code is executed, and data pertaining when it was raised is given. The catch may return to where the exception was raised, or it may terminate and jump back.

Exception Handling by RPC package The RPC package uses the way Mesa handles exceptions as a model. The protocol allows the process on the server machine to send exception packets in place of result packets. This allows the caller machine to raise an exception in the appropriate process. The results (if any) can be sent back to the callee machine, and the process can proceed normally.

Exception Handling by RPC package If the catch code terminates then the callee machine is so notified, which then unwinds the appropriate procedure activations. In addition to exceptions raised by the callee, the RPC runtime may raise a call failed exception if there is some communication difficulty.

Use of Processes Since forking processes is normally a costly event, they took extra care whilst building this package to keep that cost as low as possible. The first step to reaching this goal is the fact that they used idle server processes to remove the costs of process creation. As soon as a call is received by a callee, it may be handled.

Use of Processes Each packet contains a process identifier for both source and destination. In packets from the caller machine, the source process identifier is the calling process. In packets from the callee machine, the source process identifier is the server process handling the call.

Use of Processes A process wanting to make a call makes the first packet of the call, guesses a value for the destination process identifier, and sets the source to be itself. It then sends the packet and waits. The callee receives this and tells a server process to handle the packet and make a response packet. The destination process identifier in this packet will be that of the process waiting in the caller machine. When the response arrives in the caller machine, it is passed directly to the calling process.

Optimizations They use subsequent packets for implicit acknowledgment of previous packets, they attempt to minimize the costs of maintaining their connections, they avoid costs of establishing and terminating connections, and they reduce the number of process switches involved in a call.

Other Optimizations When transmitting and receiving RPC packets they bypass the software layers that correspond to the normal layers of a protocol hierarchy in the case of local calls. They modified the network-driver software to treat RPC packets as a special case. They want RPC to be a special case and they want it to be the dominant communication protocol. Many other options for optimization were avoided.

Security Their RPC package and protocol uses Grapevine as an authentication service and use the federal data encryption standard. This gives full end-to-end encryption of calls and results. These encryption techniques provide protection from eavesdropping, and detect attempts at modification, replay, or creation of calls.

Results Figures in microseconds.

Status Project was still its early stages at time of writing. RPC isn’t a suitable replacement for certain situations. Use Multicast/broadcast instead