Remote Procedure Call
CISC 879 – Spring 03
Tam Vu ([email protected])
March 06, 03
1
Outline

Introduction
RPC mechanisms
Design issues

Programming with RPC

Case study: SUN RPC


2
Introduction

Problem with sockets

Socket interface is straightforward




Forces read/write mechanism



Connect
Read/write
Disconnect
Not how we generally program
We usually use procedure calls
To make distributed computing look more like
centralized:

I/O is not the way to go
3
Introduction

1984: Birrell & Nelson


Mechanisms to call procedures on other machines
Processes on machine A can call procedures on
machine B




A is suspended
Execution continues on B
When B returns, control passed back to A
Goal: it appears to the programmer that a
normal call is taking place
4
Introduction

Remote Procedure Call (RPC) is a high-level model
for client-sever communication.

RPC enables clients to communicate with servers by
calling procedures in a similar way to the
conventional use of procedure calls in high-level
languages.

Examples: File service, Authentication service.
5
The RPC model
server
client
Calls procedure
and wait for reply
request
Receives request and
starts process execution
reply
Resumes
execution
Blocking state
Sends reply and wait
for next execution
Executing state
6
RPC Mechanisms

The client transfer call request (the procedure name)
and the arguments to the server via client stub
function

stub function


marshals arguments and places them into a message
together with the remote procedure identifier.
Sends message to server and waits for call return
7
RPC Mechanisms

Server receives the call request and passes to an
appropriate server stub function.

server stub function unmarshals the arguments, call
the corresponding (local) service procedure.

On return, the server stub marshals the output
arguments into a call return message and sends
back to the client.
8
RPC Mechanisms

Client stub receives call reply, unmarshals value,
returns to client code
9
RPC Mechanisms
Client computer
Local
return
Local
call
Unmarshal
results
Marshal
arguments
Receive
reply
Send
request
service
procedure
Execute procedure
client
client
stub
func.
Server computer
server
stub
func.
Communication
module
Unmarshal
arguments
Marshal
results
Select procedure
Receive
request
Send
reply
10
Benefits

Familiar procedure call interface

Writing applications is simplified



RPC hides all networks codes
Programmers don’t have to worry about details (sockets,
port numbers, byte ordering)
RPC: presentation layer in OSI model
11
Characteristics


The called procedure is in another process which
may reside in another machine.
The processes do not share address space.


Passing of parameters by reference and passing pointer
values make no sense.
The called remote procedure executes within the
environment of the server process.

The called procedure does not have access to the calling
procedure's environment.
12
Design issues
13
Parameter passing

By values


By reference


easy, just copy data to network message.
makes no sense without shared memory
Trick





Copy items referenced to message buffer
Ship them over
Unmarshal data at server
Pass local pointer to server stub function
Send new value back
14
Representing data

No such things as incompatibility on local systems

Remote machine may have:





Different byte ordering
Different sizes of integers and other types
Different floating point representations
Different character sets
Need standard encoding to enable communication
between heterogeneous systems
15
Representing data

Implicit typing



Only values are transmitted, not data type or parameter
information
E.g., Sun XDR (eXternal Data Representation)
Explicit typing


Types are transmitted with values
E.g., ISO ANS.1, XML
16
Binding


How to locate host and server process?
Solution 1: use a central DB



Server sends message to central DB indicating the
services it can offer
Clients contact this authority whenever they need to
locate a service
Solution 2:


Client needs to know server name
Server maintains a DB of available services
17
Failures

Local procedure calls do not fail


RPC is more vulnerable to failure:





If they core dump, the entire process dies
Server could generate errors
Problems in network
Server crash
Client crash while server is still running code for it
Transparency breaks here

Applications should be prepared to deal with RPC failure
18
Delivery guarantees

Retry request message:


Duplicate filtering :


Client retransmits the request message until either a reply
or the server is assumed to have failed.
server filters out duplicate message.
Retransmission of replies:

Server keeps a history of reply messages to enable lost
replies retransmitted without re-executing the server
operations.
19
Call Semantics



Semantic of local procedure calls: exactly-once
Exactly-once maybe difficult to achieve with RPC
At-least-once

The client assumes that the RP is executed at least once
(on return from the RP).

Can be implemented by retransmission of the request
message on time-out.

Acceptable only if the server’s operations are idempotent.
That is f(x) = f(f(x)).
20
Call Semantics

At-most-once

When a RPC returns, the remote procedure (RP) is
assume to have been called exactly once or not at all.

Implemented by the server's filtering of duplicate requests
and caching of replies.
21
Call Semantics

At-most-once

This ensure the RP is called exactly once if the server does
not crash during execution of the RP.

When the server crashes during the RP's execution, the
partial execution may lead to erroneous results.

In this case, we want the effect that the RP has not been
executed at all.
22
Call Semantics
RPC call
semantics
Response
At-least-once
Retry
Duplicate
request filtering
message
Yes
No
At-most-once
Yes
Retransmit
reply
Yes
Re-execute
procedure
23
More issues

Performance


remote procedure call and return time can be significantly
slower than that for local procedure call (1 - 3 orders of
magnitude).
Security



Messages visible over the network
Authenticate client
Authenticate server
24
Programming with RPC

Most languages (C, C++, Java,…) have no concept
of remote procedure calls


Language compilers will not generate client and server
stubs
Common solution:

Use a separate compiler to generate stubs
(pre-compiler)
25
Programming with RPC

Interface Definition Language


Allow programmers to specify remote procedure interfaces
(names, parameters, return values)
Pre-compiler can use this to generate client and
server stubs




Marshalling code
Unmarshalling code
Network transport protocols
Conform to defined interface
26
Programming with RPC

Client code has to be modified

Initialize RPC-related options




Transport type
Locate host/service
Handle failure of remote procedure call
Server functions

Generally need little or no modification
27
Case Studies: SUN RPC

Interface definition language: XDR


Pre-compiler: rpcgen


a standard way of encoding data in a portable fashion
between different systems;
A compiler that takes the definition of a remote procedure
interface, and generates the client stubs and the server
stubs;
Communication handling: TCP or UDP
28
References



http://www.cisco.com/univercd/cc/td/doc/product/software/ioss
390/ios390rp/rprpcgen.htm
http://pandonia.canberra.edu.au/OS/l14_1.html
http://www.cs.cf.ac.uk/Dave/C/node33.html
29
Thank you!
30
Descargar

Additional Mathematics - University of Delaware