2. Lecture 5: RPC and Distributed Objects Haibin Zhu, PhD. Assistant Professor Department of Computer Science Nipissing University © 2002

3. 2 Contents  RPC (Remote Procedure Calling)  Distributed objects  RMI (Remote Method Invocation)

4. 3 Remote Procedure Call (RPC)  Paradigms in building distributed applications  The RPC model  Primitives  Issues

5. 4 Building Distributed Programs: Two Paradigms  Communication-Oriented Design –– Start with communication protocol –– Design message format and syntax –– Design client and server components by specifying how they react to incoming messages  Application-Oriented Design –– Start with application –– Design, build, test conventional implementation –– Partition program  Problems – Protocol-design problems – Application components as finite state machines !? – Focus on communication instead of application! – Concurrency

6. 5

7. 6 RPC Properties  Uniform call structure  Type checking  Full parameter functionality  Distributed binding  Recovery of orphan computations

8. 7 RPC Primitives  Invocation at caller side –call service (value_args; result_args);  Definition at server side –declaration  remote procedure service (in value_pars; out result_pars);  begin body end;

9. 8

10. 9 RPC Issues  Parameter passing –value parameters –reference parameters?  Marshalling –simple data types –complex data structures  Exception handling –language dependent –need to deal with asynchronous events

11. 10 Locating Servers  Broadcast requests –– broadcast call and process incoming replies  Name servers –– server registers with name server  Combination: publish/subscribe

12. 11 Communication Protocols for RPC  Reliable protocols: e.g. TCP  Unreliable datagram protocols: e.g. UDP  Specifically designed protocols: Example –Simple Call Complicated Call long gaps between requests acknowledge each message transmission separately or periodically send “I-am-alive” message and use simple-call scheme. long messages (don’t fit into packet) segment message segment-relative seq #’s retransmission scheme for segments Client times out and retransmits request. Three cases: request lost server still executing ack lost

13. 12 RPC in Heterogeneous Environments  Compile-time support  Binding protocol  Transport protocol  Control protocol  Data representation

14. 13 Case Study: SUN RPC Defines format for messages, arguments, and results. Uses UDP or TCP. Uses XDR (eXternal Data Representation) to represent procedure arguments and header data. Compiler system to automatically generate distributed programs. Remote execution environment: remote program. Mutually exclusive execution of procedure in remote program.

15. 14 Identifying Remote Programs and Procedures  Conceptually, each procedure on a computer is identified by  pair :  (prog, proc) –– prog: 32-bit integer identifying remote program –– proc: integer identifying procedure  Set of program numbers partitioned into 8 sets. –0x00000000 - 0x1fffffff assigned by SUN –0x20000000 - 0x3fffffff assigned by local system manager –0x40000000 - 0x5fffffff temporary –0x60000000 - 0xffffffff reserved  Multiple remote program versions can be identified: –(prog, version, proc)

16. 15 Communication Semantics  TCP or UDP ?  Sun RPC semantics defined as function of underlying  transport protocol.  – RPC on UDP: calls can be lost or duplicated.  at-least-once semantics if caller receives reply.  zero-or-more semantics if caller does not receive reply.  Programming with zero-or-more semantics: idempotent  procedure calls.  Sun RPC retransmission mechanism:  – non-adaptive timeouts  – fixed number of retransmissions

17. 16

18. 17

19. 18 Message Dispatch for Remote Programs

20. 19 Specification for rpcgen  /* rdict.x */  /* RPC declarations for dictionary program */  const MAXWORD = 50;  const DICTSIZ = 100;  struct example { /* unused; rpcgen would */  int exfield1; /* generate XDR routines */  char exfield2; /* to convert this structure.*/  };  /* RDICTPROG: remote program that provides  insert, delete, and lookup */  program RDICTPROG { /* name (not used) */  version RDICTVERS { /* version declarat.*/  int INITW(void) = 1;/* first procedure */  int INSERTW(string)= 2;/* second proc.... */  int DELETEW(string)= 3;  int LOOKUP(string) = 4;  } = 1; /* version definit.*/  } = 0x30090949; /* program no */  /* (must be unique)*/ Specify: constants data types remote programs, their procedures, types of parameters

21. 20

22. 21 Distributed object model  Remote object reference: an identifier that can be used throughout a distributed system to refer to a particular unique remote object.

23. 22 Distributed object model invocation remote invocation remote local invocation A B C D E F  each process contains objects, some of which can receive remote invocations, others only local invocations  those that can receive remote invocations are called remote objects  objects need to know the remote object reference of an object in another process in order to invoke its methods. How do they get it?  the remote interface specifies which methods can be invoked remotely Figure 5.3

24. 23 Figure 5.4 A remote object and its remote interface interface remote m1 m2 m3 m4 m5 m6 Data implementation remoteobject { of methods

25. 24 Invocation semantics  Local invocations are executed exactly once  Remote invocations cannot achieve this. Why not? –the Request-reply protocol can apply fault-tolerance measures Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Not applicable No Yes Not applicable Re-execute procedure Retransmit replyAt-most-once At-least-once Maybe Figure 5.5

26. 25 Invocation semantics: failure model  Maybe, At-least-once and At-most-once can suffer from crash failures when the server containing the remote object fails.  Maybe - if no reply, the client does not know if method was executed or not –omission failures if the invocation or result message is lost  At-least-once - the client gets a result (and the method was executed at least once) or an exception (no result) –arbitrary failures. If the invocation message is retransmitted, the remote object may execute the method more than once, possibly causing wrong values to be stored or returned. –if idempotent operations are used, arbitrary failures will not occur  At-most-once - the client gets a result (and the method was executed exactly once) or an exception (instead of a result, in which case, the method was executed once or not at all)

27. 26 RMI (Remote Method Invocation)  Communication Module  Remote reference module  RMI software –Proxy: make RMI transparent –Dispatcher: receives the request message from the communication module, use methodId to select and pass the request –Skelton: implements the methods in the remote interfaces.  Generation of RMI software: by rmic  Server and client programs

28. 27 The architecture of remote method invocation object A object B skeleton Request proxy for B Reply Communication Remote Remote reference Communication module reference module module for B’s class & dispatcher remote client server Figure 5.6 RMI software - between application level objects and communication and remote reference modules carries out Request- reply protocol translates between local and remote object references and creates remote object references. Uses remote object table Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests and unmarshals results. Forwards request. Dispatcher - gets request from communication module and invokes method in skeleton (using methodID in message). Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object.

29. 28 Representation of a remote object reference Internet addressport numbertimeobject number interface of remote object 32 bits  a remote object reference must be unique in the distributed system and over time. It should not be reused after the object is deleted. Why not?  the first two fields locate the object unless migration or re-activation in a new process can happen  the fourth field identifies the object within the process  its interface tells the receiver what methods it has (e.g. class Method)  a remote object reference is created by a remote reference module when a reference is passed as argument or result to another process –it will be stored in the corresponding proxy –it will be passed in request messages to identify the remote object whose method is to be invoked Figure 4.10

30. 29 Shared whiteboard example (p 194)  In the RMI and CORBA case studies, we use a shared whiteboard as an example –this is a distributed program that allows a group of users to share a common view of a drawing surface containing graphical objects, each of which has been drawn by one of the users.  The server maintains the current state of a drawing and it provides operations for clients to: –add a shape, retrieve a shape or retrieve all the shapes, –retrieve its version number or the version number of a shape

31. 30 Java Remote interfaces Shape and ShapeList import java.rmi.*; import java.util.Vector; public interface Shape extends Remote { int getVersion() throws RemoteException; GraphicalObject getAllState() throws RemoteException; } public interface ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException; Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; } Note the interfaces and arguments GraphicalObject is a class that implements Serializable.

32. 31 The Naming class of Java RMIregistry void rebind (String name, Remote obj) This method is used by a server to register the identifier of a remote object by name, as shown in Figure 15.13, line 3. void bind (String name, Remote obj) This method can alternatively be used by a server to register a remote object by name, but if the name is already bound to a remote object reference an exception is thrown. void unbind (String name, Remote obj) This method removes a binding. Remote lookup(String name) This method is used by clients to look up a remote object by name, as shown in Figure 15.15 line 1. A remote object reference is returned. String [] list() This method returns an array of Strings containing the names bound in the registry.

33. 32 Java class ShapeListServer with main method import java.rmi.*; public class ShapeListServer{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try{ ShapeList aShapeList = new ShapeListServant();1 Naming.rebind("Shape List", aShapeList );2 System.out.println("ShapeList server ready"); }catch(Exception e) { System.out.println("ShapeList server main " + e.getMessage());} }

34. 33 Java class ShapeListServant implements interface ShapeList import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.util.Vector; public class ShapeListServant extends UnicastRemoteObject implements ShapeList { private Vector theList; // contains the list of Shapes1 private int version; public ShapeListServant()throws RemoteException{...} public Shape newShape(GraphicalObject g) throws RemoteException {2 version++; Shape s = new ShapeServant( g, version);3 theList.addElement(s); return s; } public Vector allShapes()throws RemoteException{...} public int getVersion() throws RemoteException {... } }

35. 34 Java client of ShapeList import java.rmi.*; import java.rmi.server.*; import java.util.Vector; public class ShapeListClient{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); ShapeList aShapeList = null; try{ aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList");1 Vector sList = aShapeList.allShapes();2 } catch(RemoteException e) {System.out.println(e.getMessage()); }catch(Exception e) {System.out.println("Client: " + e.getMessage());} } Figure 5.15

36. 35 Summary  PRC –Interface –Parameter passing –Marshalling  Distributed Objects –Remote Object Reference –Remote interface  RMI –each object has a (global) remote object reference and a remote interface that specifies which of its operations can be invoked remotely. –local method invocations provide exactly-once semantics; the best RMI can guarantee is at-most-once –Middleware components (proxies, skeletons and dispatchers) hide details of marshalling, message passing and object location from programmers.