Remote Procedure Call : Remote Procedure Call CISC 879 – Spring 03
Tam Vu (tvu@mail.eecis.udel.edu)
March 06, 03
Outline : Outline
Introduction
RPC mechanisms
Design issues
Programming with RPC
Case study: SUN RPC
Introduction : Introduction Problem with sockets
Socket interface is straightforward
Connect
Read/write
Disconnect
Forces read/write mechanism
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
Introduction : 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
Introduction : 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.
The RPC model : The RPC model
RPC Mechanisms : 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
RPC Mechanisms : 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.
RPC Mechanisms : RPC Mechanisms Client stub receives call reply, unmarshals value, returns to client code
RPC Mechanisms : RPC Mechanisms
Benefits : 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
Characteristics : 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.
Design issues : Design issues
Parameter passing : Parameter passing By values
easy, just copy data to network message.
By reference
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
Representing data : 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
Representing data : 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
Binding : 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
Failures : Failures Local procedure calls do not fail
If they core dump, the entire process dies
RPC is more vulnerable to failure:
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
Delivery guarantees : Delivery guarantees
Retry request message:
Client retransmits the request message until either a reply or the server is assumed to have failed.
Duplicate filtering :
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.
Call Semantics : 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)).
Call Semantics : 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.
Call Semantics : 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.
Call Semantics : Call Semantics
More issues : 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
Programming with RPC : 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)
Programming with RPC : 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
Programming with RPC : 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
Case Studies: SUN RPC : Case Studies: SUN RPC Interface definition language: XDR
a standard way of encoding data in a portable fashion between different systems;
Pre-compiler: rpcgen
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
References : References http://www.cisco.com/univercd/cc/td/doc/product/software/ioss390/ios390rp/rprpcgen.htm
http://pandonia.canberra.edu.au/OS/l14_1.html
http://www.cs.cf.ac.uk/Dave/C/node33.html
Thank you! : Thank you!