.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

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?

RPC Language Integration

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 RPC-like interaction between components of a distributed application

Summary

Reading and Resources

Reading Coulouris, Dollimore & Kindberg, Distributed

Systems - Concepts and Designs, 3rd edition, Addison-Wesley, 2001