Implementing Remote Procedure Calls Authored by: Andrew D. Birrel and Bruce Jay Nelson Presented by: Terry, Jae, Denny

Outline: An introduction to RPC Principles to follow in RPC An implementation of RPC Binding Packet-level Transport Protocol Other issues

1. Introduction to RPC Basic idea Extend local procedure calls General steps Caller calls a remote procedure System suspend caller Pass parameters of the call to callee Invoke desired procedure executed in callee Callee returns the result back to caller Caller receives the result and resumes.

RPC: Advantages Clean and simple semantics Local call alike Efficient: Procedure steps can be executed rapidly Generality: Procedures: the most important mechanism for communication between parts of the algorithm Think about distributed computation

RPC: Major issues The precise semantics of a call when Machine failure Communication failures The presentation of address in the absence of a shared address space Integration of remote calls into existing programming systems. Binding Data and control protocol between caller and callee Data integrity and security in an open communication network.

Aim to built RPC package Primary goal: Make distributed computation easy. Secondary goals: Expected to be efficient. Semantics should be as powerful as possible. Provide clients secure communication with RPC.

Built RPC: Fundamental Decisions Paradigm for expressing control and data transfer Procedure call Reason: Procedures are popular: The major control and data transfer mechanism in the language Alternatives: shared space

Built RPC: principle Semantics of remote procedure calls: as close as possible to local procedure calls Fail to obey this principle are likely to make the package difficult to use Following this rule: Have to discard some attractive ideas No timeout limiting duration of a call Local calls does not set timeout

RPC: Structure Concepts of stubs Five modules User User-stub The RPC communicate package (RPCRuntime) Server-stub Server

RPC: Steps Normal call by user invokes corresponding procedure in the user-stub User-stub place a specification of the target procedure and the arguments into packet (marshalling) User-stub ask RPCRuntime to send RPCRuntime in callee receive packets RPCRuntime pass packet to server-stub Server-stub unpack (unmarshalling ) and call local call Server returns to server-stub Result passed back to process in the caller

Structure: RPCRuntime RPCRuntime: A standard part of the operation system In charge of: Retransmission of not ACKed packets Acknowledgments of received packets Routing and encryption of packets TCP/IP protocol?

Structure: User and server stubs User and server stubs: Automate generated by a program called Lupine Generation is specified by a interface module Interface module: A list of procedure names With the types of their arguments and results Compare to Sun RPC: Interface compiler generate client and server stubs from the interface definition of the service

Structure Interface module provide sufficient info to Lupine Export interface: Program module that implements procedures in an interface Import interface: program calling procedures from an interface

How to use? Designing the interface Write interface module Presents the interface to Lupine Write user and server code Invoke the inter-machine binding Handle failures.

2. Binding Aim: Binds an importer of an interface to an exporter of an interface Two questions: How does a client of the binding mechanism specify what he wants to be bound to? How does a caller determine the machine address of the callee and specify to the callee the procedure to be invoked? Compare with port-mapper used in Sun RPC

Binding: naming Name of an interface has two parts: Type At some level of abstraction which interface the caller expects the callee to implement Instance Which particular implementor of an abstract interface is desired.

Binding: Locating an appropriate exporter Distributed database used In the database: Entry for instance Individual whose connect-site is a network address Entry for type A Group whose members are keys of the instanceinstance of that type which have been exported.type

Binding: exporter sideexporter When An exporter wishes to make his interface available to clients Server calls the server-stub Server-stub calls a procedure, ExportInterface in the RPCRuntime ExportInterface is given the interface name (type and instance), and a dispatcher.

Binding: exporter side (con’t)exporter The procedure check the DB, making sure that: the instance is the member of the type and connect-site of the instance is the network address of the exporting machine. Now Grapevine update the exporter information Every export is assigned a unique identifier (counter).

Binding: importer sideimporter When a importer wishes to bind an exporter User call user-stub User-stub calls a procedure, ImportInterface, in the RPCRuntime, giving the desired interface type and instance. RPCRuntime ask Grapevine for instance, get connect-site

Binding: importer side (con’t)importer RPCRuntime make RPC call to the RPCRuntime on that machine asking for the binding information associated with this interface type and instance. If the specified machine is not exporting then binding fails. Else returns : The corresponding unique identifier the table index to the importing machine Binding succeeds User-stub record info for next time: The exporter network address Identifier Table index of dispatcher

Binding Now user-stub make a call on the imported remote interface The call packet contains the unique identifier and table index of the desired interface RPCRuntime on the callee machine receives the packet Uses the index to look up its table of current exports Verifies the unique identifier Pass the packet to the dispatcher procedure specified in the table

Binding: compare to Port Mapper Compare to Port Mapper in Sun RPC Port mapper: Runs locally Port as result Our implementation Use distributed database Does not use TCP/IP, do not have port Interface type and instance to find Result is table index to the dispatcher and unique ID Which is better?

3. Packet-level transport protocol Specialized packet-level protocol gives us: Minimizing the time between initiating a call and result Minimizing the load imposed on a server

Packet-level transport protocol: Two schemes Simple calls Complicated calls

Simple calls: All of the call arguments will fit in a single packet So do result Calls are frequent

Simple calls: how to Caller sends a call packet containing: A call identifier Call identifier Calling machine identifier Machine-related Process identifier Sequence number of the transaction Activity is defined: [machine ID, process ID] data specifying the desired procedure, and arguments Callee return a result packet containing: The same call identifier the results

Simple calls: how to (con’t) A call packet is ACKed by the result packet A result packet is ACKed by the next call packet If duration of a call and the interval between calls are less than the transmission delay Two packets per call, one in each direction, one call, one ACK If calls last longer or intervals longer: Two additional packets send (a retransmission, an explicit ACK) An overhead we can endure

Simple calls: Call identifier Call identifier is used for several reasons: Allows the caller to determine that the result is the result of current call Allows the callee to eliminate duplicate call packets

Simple Protocol: summary No special connection establishment protocol receive of a call packet is enough No communication to maintain idle connection No explicit connection termination protocol discard state information after an interval. Relies on the unique identifier to detect duplicates Also assume that the call sequence number from an activity does not repeat.

Complicated Calls Packet transmitted are modified to request an explicit ACK Caller periodically sends probe packet to callee Callee expected to ACK to the probe Caller wait as long as probes are ACKed When communication failure caller should be told fairly soon (no ACK for probe) Only detect failure in communication levels principle of making RPC semantics similar to local calls.

Complicated Calls (con’t) If the arguments are too large, multiple packets Last of these packets request explicit ACK Use only one packet buffer at each end for the call Avoid to include buffering and flow control Call-relative sequence number for multiple data packets within a call

Complicated Call: performance If transferring a large amount of data in one direction Sends up to twice as needed if represented as procedure calls Still desirable Dominant advantage over requiring one ACK for each packet Simplifies and optimizes the implementation

Other issues Exception handling: Emulate signals: exception and catch Add a call failed exception Raise if communication difficulty happened The primary way for clients to note the difference between local and remote calls Take process creation and swap into consideration Process creation and swaps consume significant cost Aim to lower the cost After the refinement simple calls create no processes only a few process swaps in each call

Thank you!