Transcript Remote Procedure Call .NET Mobile Application Development

.NET Mobile Application Development
Remote Procedure Call
Introduction
 In previous sessions we have considered
> distributed applications and their characteristics
> mobile devices, applications and services; characteristics and
limitations
 Remote Procedure Call (RPC)
> is an historically important distributed computing technology; many
of today’s distributed computing technologies (e.g. XML Web
services) are refinements of RPC.
 In this session we consider RPC to gain an
appreciation of how modern RPC-based distributed
technologies work
RPC – A History
 Remote Procedure Call (RPC)
> Historically, one of the most important distributed software technologies
and still extensively used today
- MSBlast/LovSan worm exploited weakness in Windows RPC layer in
Summer 2003
 Allows a client to call a procedure in a process on a remote


computer
Arguments can be passed to the remote procedure and
values returned from it
Communicating with a distributed component is (almost !)
as simple as a normal procedure call
Interfaces
 Interfaces
> Control possible interactions between software modules
> Specify procedures / variables that can be accessed from other modules
 RPC and interfaces
> interface used to define procedures of a module that are available for
calling remotely
> Parameters marked as
- Input – sent to remote module in request message
- Output – returned from remote module in reply message
> Only procedures can be accessed; variables cannot be accessed directly
> Either defined by the source language or externally with an Interface
Definition Language (IDL)
Middleware and RPC
 RPC is middleware
> RPC programming model is layered above basic communication and
process management provided by OS
- Offers location transparency
- Independence from underlying data transport protocols
- Uses standard data representation to mask differences in hardware
and OS data representation
 RPC uses a request-reply protocol
> Parameters to remote procedure sent as request message to remote
module
> Remote module executes procedure with given parameters
> Return values passed back in reply message
RPC Semantics
 Semantics of remote procedure invocation differ to those

of local invocations due to need to deal with potential
network failures
Invocation semantics of RPC vary between
implementations but are generally either
> at-most-once
- Remote procedure is guaranteed to be executed exactly zero or one
times
> at-least-once
- Remote procedure is guaranteed to be executed one or more times
> What are the semantics of a local procedure call?
RPC Implementation
 Client has communication module and one stub procedure for each
procedure in the service interface
> Stub is
- Proxy for remote procedure called locally by client
- Marshals arguments into message which is sent to remote module by
communication module
 Server has communication module and dispatcher plus one server
stub and one procedure for each procedure in service interface
> Dispatcher chooses server stub to receive message
> Server stub
- Unmarshals arguments from message and invokes procedure
- Marshals return values from procedure into message which is sent to client by
communication module
RPC Implementation…
RPC Operation
 Implementation of RPC is designed to cope with potential
failures
 At A (client stub/communication module)
> arguments packed into buffer for transfer across network
> RPC identifier generated; timer set
 At B (dispatcher)
> arguments unpacked from message
> RPC identifier noted
Remote Procedure Call
 At C (server stub / server procedure)
> procedure is called with arguments
 At D (server stub / communication module)
> return arguments packed into buffer
> another timer is set
 At E (client stub / communication modules)
>
>
>
>
arguments unpacked from message
timer set at A is disabled
acknowledgement sent for this RPC identifier
timer set at D is disabled
RPC and Failures
 Client Failure
>
>
>
>
>
May occur after sending request
Orphan remote call will still go ahead
Timer at D will expire; no acknowledgement will be received
Server made permanent state changes as result of call?
When client restarts it may repeat call; no way for RPC service to detect the
repeat
 Server Failure
> May occur before call is received or during the call
- at B, after request is received but before procedure is called
- at C, during the procedure call
- at D, after procedure call but before result is sent
> Timeout at A will occur
> Most systems do not handle roll-back of state changes for incomplete RPC calls
RPC Language Integration
 How should RPC be integrated with programming
languages?
 Distribution transparency
> Should remote procedure calls appear the same as local calls in the code (i.e.
hiding the distribution from the programmer)?
> Arguments for and against transparency. If transparency is allowed, remote call
semantics may differ
 Argument marshalling
> Should user-defined types be allowed as arguments? How does system pack
them into messages?
 Type checking
> Can compiler perform static, compile-time checking of arguments for remote
procedure calls?
Summary
 In this session we have discussed
> Remote Procedure Call
> RPC implementation and operation
> RPC language integration issues
 In the next session we will consider the creation and use
of XML Web services, a modern cross-platform
distributed computing technology which supports RPClike interaction between components of a distributed
application
Reading and Resources
Reading
 Coulouris, Dollimore & Kindberg, Distributed
Systems - Concepts and Designs, 3rd
edition, Addison-Wesley, 2001