Fundamentals Stream Session 2: Client-Server, RPC and RMI

1. [http://research.lumeta.com/ches/map/] Distributed Systems Fundamentals Stream Session 2:Client-Server, RPC and RMI CSC 253 Gordon Blair, François Taïani

2. Overview of the Session • Introduction to the client-server model • The key concept of remote procedure calls (RPC) • What is RPC • Styles of RPC • Implementation considerations • From RPC to RMI • Essential characteristics • Advanced features Associated Reading: Tanenbaum and van Steen, pp. 145-158, 68-98, 99-134 G. Blair/ F. Taiani

3. Client <result> <invocation> Client <invocation> Server <result> process Client machine message <foo> The Client-Server Model Key: G. Blair/ F. Taiani

4. Example Servers • Naming and trading services • DNS service: www.bbc.co.uk  212.58.224.89 (IP address) • Service discovery protocol: SLP, SDP, UPnP, Jini, etc. • Distributed file service • Samba (MS Windows), NFS (Network File Service) (UNIX) • And many others (AFS, Coda, etc.) • Security services: Kerberos, etc. • Time and coordination services: • NTP (network time protocol) • Concurrency control and recovery services • Etc. G. Blair/ F. Taiani

5. What is RPC? • Higher level mechanism supporting the construction of distributed applications (see also discussion on transparency later) • Supports the calling of a procedure in a separate address space (process) as if it exists in the local address space; the process may or may not be on the same machine • But what is the semantics of a local procedure call? G. Blair/ F. Taiani

6. Application RMI, RPC and events Middleware layers Request reply protocol External Data Representation Operating System RPC and Middleware G. Blair/ F. Taiani

7. Styles of RPC • First class RPC • Integrated into the language => normal language mechanisms can be used for exceptions etc • Examples include Java RMI, Ada and Argus • Second Class RPC • A special Interface Definition Language (IDL) is used to define communications (see later) • Language independence • Examples include Sun RPC, CORBA and DCE G. Blair/ F. Taiani

8. Asynchronous RPC • The interconnection between client and server in a traditional RPC • The interaction using asynchronous RPC 2-12 G. Blair/ F. Taiani

9. myObject:myClass someInterface Programming with Interfaces • Separation of interface and implementation • Client software does not need to know the details of the implementation, cf. abstraction • Important for platform and language independence • Also important to support the evolution of software G. Blair/ F. Taiani

10. Interface Definition Languages • What is an IDL? • A language independent means of specifyingan interface • Similar to abstract data type specification • Dealing with Parameters • IN parameters = value passed to server • OUT parameters = value returned from server • IN/OUT parameters = combination of above G. Blair/ F. Taiani

11. Example: CORBA IDL interfaceinventory { // attributes and type definitions constlong MAX_STRING = 30; typedeflongpart_num; typedeflongpart_price; typedeflongpart_quantity; typedefstringpart_name<MAX_STRING+1>; structpart_stock{ part_quantity max_threshold; part_quantity min_threshold; part_quantity actual; }; //end of part_stock p.t.o. G. Blair/ F. Taiani

12. CORBA IDL (continued) // operations booleanis_part_available(inpart_num number); voidget_price(inpart_num nmb , outpart_price price ); voidget_stock(inpart_num number , outpart_quantity quantity); longorder_part(inpart_num number ,inoutpart_quantity quantity, inaccount_num account ); }; //end of interface inventory G. Blair/ F. Taiani

13. The Issue of Transparency • Definition • Transparency (as defined in session 1) refers to the property of hiding aspects of distribution from the user, e.g. location and access transparency • Transparency in RPC • Ultimate goal, but generally compromised by: • Overall cost of an RPC • Every remote call will cost O(1-10)ms • Extra exceptions that are raised • Parameter passing is different, e.g. pointers G. Blair/ F. Taiani

14. Communications modules Proxy Dispatcher Remote Object B Request Object A Reply Server Stub Client Stub Implementing RPC N.B. Proxies, stubs, dispatchers are generated automatically by an appropriate IDL compiler G. Blair/ F. Taiani

15. Key Components: Client Side • Proxies (see also smart proxies) • Masquerades as a local version of the remote interface • Redirects calls to client stubs • May perform other actions (smart proxies) • Client stubs • Carries out marshalling (flattening) of calls and the requests the retransmission of the message • Also must unmarshal returning replies G. Blair/ F. Taiani

16. Key Components: Server Side • Dispatchers • Receive incoming messages and direct them to an appropriate server stub • Server stubs (skeletons) • Unmarshals message and then invokes appropriate code body • Must also marshal reply values and initiate transmission back to the client G. Blair/ F. Taiani

17. Focus on Underlying Protocol • Task • You are asked to design the communications module for RPC which will provide a protocol that mimics the semantics of a local call • Problems • Request message may get lost • Reply message may get lost • Client may crash • Server may crash N.B. This assumes you are implementing over an unreliable protocol such as UDP. In practice, RPC can equally be implemented over TCP, especially in large scale systems. G. Blair/ F. Taiani

18. Lightweight Protocols • Maybe • Send request to server; which sends back a reply • No real guarantees at all if anything goes wrong • At least once • Sends message and if reply not received after a given time, the message is re-sent (failure assumed after n re-sends) • Will guarantee the call is made “at least once”, but possibly multiple times • Ideal for idempotent operations G. Blair/ F. Taiani

19. Request (#1473) Execute code Log results Request (#1473) Detect duplicate Reply (#1473) Acknowledge (#1473) At Most Once Protocols Client Server Call Re-send G. Blair/ F. Taiani

20. From “At Most Once” to “Exactly Once” • Semantics • The remote procedure call will be carried out once (completely) or not at all (the operation will be aborted) • Approach • Builds on “at most once” protocol • Requires additional support for atomicity See lectures on fault tolerance and dependability G. Blair/ F. Taiani

21. From RPC to RMI • Common organization of a remote object with client-side proxy. 2-16 But what are the essential differences? G. Blair/ F. Taiani

22. Essential Characteristics of RMI • Full integration with object-oriented programming language • Ability to exploit objects, class and inheritance • Added benefits from exploiting built in (object-oriented) approaches to, for example, exception handling • From procedure calling to method invocation • Added expressiveness of supporting object references • More sophisticated options for parameter passing • E.G. See lecture on Java RMI • Pass by (object) reference • Pass by value (exploiting serialisation) • Often integrated with code (object) mobility • E.G. Use of class loading in RMI See lectures on Java RMI and on code mobility and Aglets G. Blair/ F. Taiani

23. Advanced Features • Static vs. dynamic invocation • Static invocation is the default and assumes that interfaces are known at compile time (stubs are compiled from the IDL) • Any changes in the system require re-compilation • Dynamic invocation in contrast is used when unanticipated classes of object are discovered at run-time (programmer must compose the invocation explicitly • Object adapters • Provide a wrapper around an object or set of objects to present a common abstraction, e.g. to hide heterogeneity • At its most sophisticated, an object adapter can encapsulate policies for dispatching, thread allocation, object activation and passivation and object persistency • Such advanced features are most commonly found in more advanced distributed object platforms such as CORBA G. Blair/ F. Taiani

24. More on Object Adapters • This diagram shows a server with different object adapters each supporting a set of objects • Each adapter can implement its own policies suitable for that category of object (see previous slide) G. Blair/ F. Taiani

25. Alternative Approaches #1: Beyond Client-Server • Can we move from a world of clients and servers to a world of peers co-operating on a given task (i.e. peer to peer) • In this new world, can we re-create all the services that users of a distributed system expect • Routing • Searching and discovery • Distributed file sharing • Group communication • What impact does this have on key properties • Scalability • Dependability G. Blair/ F. Taiani

26. Alternative Approaches #2: Beyond RPC/ RMI • Can we move from the rather synchronous world of RPC or RMI towards more asynchronous modes of interaction • Message passing, e.g. MPI • Event communication/ publish-subscribe • Tuple space communication • Or, can we hide distribution more thoroughly by presenting one world-wide address space • Distributed shared memory • What impact does this have on key properties • Scalability • Dependability G. Blair/ F. Taiani

27. Expected Learning Outcomes At the end of this session: • You should understand the concept of RPC and the various styles of RPC that area available • You should appreciate the issues involved in the design of an RPC service, e.g. transparency • You should also appreciate how modern RPC services may be implemented, including the key architectural elements involved • You should understand the essential characteristics of RMI and how this adds value to RPC-based approaches • You should also be aware of characteristics of more advanced distributed object systems • You should be aware of alternative approach to those presented in this lecture, especially P2P approaches, asynchronous communication models and also approaches based on distributed shared memory G. Blair/ F. Taiani