1. .NET Mobile Application Development Remote Procedure Call

2. 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

3. 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

4. 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)

5. 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

6. 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?

7. 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

8. RPC Implementation…

9. 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

10. 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

11. 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

12.  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

13.  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

14. Reading and Resources Reading  Coulouris, Dollimore & Kindberg, Distributed Systems - Concepts and Designs, 3 rd edition, Addison-Wesley, 2001