Transcript Implementing Remote Procedure Calls

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!