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 instance

of that type which have been exported.

Binding: exporter side

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)

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 side

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)

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!