.NET Mobile Application Development Remote Procedure Call.
Published byModified over 6 years ago
Presentation on theme: ".NET Mobile Application Development Remote Procedure Call."— Presentation transcript:
.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 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, 3 rd edition, Addison-Wesley, 2001