Download ppt

Remote Procedure Calls
- Alan West
CS533 - Concepts of Operating Systems
1
What are remote procedure calls?

Remote procedure calls
o
o
Extends notion of local procedure calls so a called
procedure could exist and be executed on a remote
machine.
Used to construct distributed client/server applications
where the client calls procedures remotely on the server.
CS533 - Concepts of Operating Systems
2
Major design issues




Semantics of a call in presence of
machine/communication failure.
How a caller binds to a callee.
Suitable protocol for transfer of data/control
between caller and callee.
How to provide data integrity and security.
CS533 - Concepts of Operating Systems
3
Goals of RPC

Make things easy to encourage people to use it
o


Construction of communicating programs perceived as
difficult.
Make RPC communication efficient otherwise its use
will be avoided
Provide secure communication with RPC
CS533 - Concepts of Operating Systems
4
Fundamental decisions made in author’s
RPC implementation

Use of the procedure call paradigm (as opposed to message
passing for instance)
o

No concept of shared address space
o

Procedures were the major data/control transfer mechanism in
Mesa.
Author’s intuition that cost of shared address space would exceed
benefits
Make remote procedure calls just like local procedure calls
o
Example: no time out feature with remote procedure calls
CS533 - Concepts of Operating Systems
5
Structure


User -> User-stub -> RPCRuntime -> Server-stub ->
Server
User-stub and Server-stub automatically generated.
o
o
Uses interface modules specifying procedure names with
types of arguments and results
A program module can export (implement) an interface or
import (call procedures from) an interface
CS533 - Concepts of Operating Systems
6
Binding



Client must specify what it wants to bind to (which
interface the expects the callee to implement)
Client must determine the address of the callee and
specify which procedure it wishes to invoke.
Grapevine is used for binding in author’s
implementation
o
Servers call ExportInterface to register their interface
name (type and instance) with Grapevine
CS533 - Concepts of Operating Systems
7
Binding (cont.)

Server:
o
o
o

Servers call ExportInterface to register their interface name
(type and instance) with Grapevine
RPCRuntime on server maintains table of exported interfaces
including the name, dispatcher procedure, and unique ID of export
Table implemented as array.
Client
o
o
Call ImportInterface to determine address of exporter
Remote procedure call performed to receive binding info. If
successful client receives unique ID of export and index into
table.
CS533 - Concepts of Operating Systems
8
Binding (cont.)


Once binding succeeds client can make a remote call.
A call to the remote machine includes unique ID and
table index so RPCRuntime can send call packet to
correct dispatcher in server-stub.
Further things to note:
o
o
Import has no effect on server (server can support
hundreds of clients w/o overhead)
Unique ID of exports provides an implicit unbinding on
server crash
CS533 - Concepts of Operating Systems
9
Transport Protocol

Transport protocol designed specifically for RPC
o
o

Goal in protocol design is to lower connection cost.
o
o

From author’s experience this could significantly improve
performance.
Request-response nature of RPC is unlike the large data transfers
which byte streams are designed for.
Large connection cost would far outweigh the small amount of data
sent each call.
Needs to scale to large number of users.
Transport layer defines semantics and guarantees for calls
o
o
A successful call will invoke the procedure on the server once
Exception reported in case of server crash or communication
failure.
CS533 - Concepts of Operating Systems
10
Calls

Caller sends three things per call
o

Call identifier allows callee to identify that result packet is the
correct one. It consists of
o




Call identifier, requested procedure, arguments
Machine ID, calling process ID, sequence number
Only one outstanding remote call per “activity” (machine ID,
process pair)
Server maintains table for each calling activity
Call packet from previously unknown activity creates a
connection implicitly.
In case of server crash RPC relies on unique server ID to
recognize crash. The ID will change after the machine reboots
CS533 - Concepts of Operating Systems
11
Calls (cont.)

Acknowledgements and retransmissions
o
o


Sender retransmits packet until ack received
Probe packets sent periodically during long calls to make
sure communication to server is still available
Multiple packets sent when argument list is too large
A protocol designed for bulk transfer may be
beneficial for more complex calls
CS533 - Concepts of Operating Systems
12
Exception handling



Semantics for exception handling equivalent to those
in Mesa.
Server can reply with an exception packet instead of
result.
If client contains a catch phrase for the exception
then it will execute it normally and notify server.
CS533 - Concepts of Operating Systems
13
Processes




Process creation and process swapping can be
expensive on the scale of a remote procedure call.
A server maintains a stock of idle server processes
to avoid procedure creation.
Each packet contains a process ID for both source
and destination.
Ethernet driver checks process ID of packet and
forwards to correct process
CS533 - Concepts of Operating Systems
14
Other stuff

Security:
o
o

Author’s implementation give a guarantee of the identity of
a callee through the use of the Grapevine DB.
Full end-to-end encryption of calls and results.
Performance
o
Remote procedure calls appeared to be 1 to 2 orders of
magnitude slower than local procedure calls.
CS533 - Concepts of Operating Systems
15