Lecture 5

1. Lecture 5 • Distributed object systems • Java RMI • programmer’s view • (RMI internals) • Assignment 2

2. object object Data Data interface m1 m1 implementation implementation m2 m2 m3 m3 of methods of methods [Traditional] Objects • Object = data + methods • logical and physical encapsulation • Identified by means of references • first class citizens, i.e., can be passed as arguments • Interaction defined via interfaces • define types of arguments and exceptions for methods

3. local C remote E local invocation invocation remote invocation invocation F B local A invocation D The Distributed Object Model: Idea Programs are (logically and physically) partitioned into objects  Distribute objects across memory spaces • Client-server relationship at the object level

4. local C remote E local invocation invocation remote invocation invocation F B local A invocation D The Distributed Object Model: What’s needed? • Extend the object model with: • Remote interfaces (to differentiate local access from remote one) • Remote method invocation (and new exceptions) • Remote object references • Extend runtime • Distributed garbage collection

5. 32 bits 32 bits 32 bits 32 bits interface of port number Internet address time object number remote object Remote Object References • [Traditional] Object references • used to access objects which live in processes • can be passed as argumentsandresults • can be stored in variables • Remote object references • object identifiers in a distributed system • must be unique across space and time • error returned if accessing a deleted object • may support relocation (e.g., in CORBA)

6. remote object Data remote interface m4 { m1 implementation m5 m2 m6 of methods m3 Remote Interfaces • Specify externally accessible methods • no direct references to variables(no global memory) • local interface is separate • Method arguments • input, output or both • Need to decide call semantics • How are arguments passed (call by value / call by reference / copy in-copy out) • Retry policy (at-least-once / at-most-once)

7. Handling Remote Objects • Exceptions • raised in remote invocation • clients need to handle exceptions • timeouts in case server crashed or too busy • Garbage collection • distributed garbage collection may be necessary • combined local and distributed garbage collector • multiple solutions are possible • (e.g. Java does reference counting/listing)

8. Java Remote Method Invocation

9. Argument Passing • If argument is primitive type • Pass by value • If the object implements Remote interface • Pass by reference • If object implements Serializable interface • Pass by copy out • Note: deep copy! • If none of the above • Exception is raised

10. Call semantics At-most-once invocation • Used by Java RMI (and Corba)

11. Performance Issues: Granularity • [generally] an RMI method invocation results in : • A new TCP connection to the remote server • Creation of a new thread on the remote server • [issue] Concurrency to be managed by application • [as a result] RMI calls should be used for coarse-grain computation.

12. A programmer’s view Object Registry Server (manages XYZ object) Client program XYZ Implementation uses implements XYZ interface Client Host Server Host

13. Hello World: Remote Interface import java.rmi.*; + public interfaceHelloInterface extends Remote { + /* * Remotely invocable method, * returns a message from the remote object, * throws a RemoteException * if the remote invocation fails */ public String say() throws RemoteException; + }

14. Hello World: The Remote Object import java.rmi.*; + import java.rmi.server.*; + public classHelloImpl extends UnicastRemoteObject + implements HelloInterface { + private String message; /* Constructor for a remote object * Throws a RemoteException if the object handle * cannot be constructed */ public HelloImpl(String msg) throws RemoteException{ message = msg; } /* Implementation of the remotely invocable method */ public String say() throws RemoteException { return message; } }

15. Hello World: The ‘Server’ import java.io.*; import java.rmi.*; public classHelloServer{ /* * Server program for the "Hello, world!" example. */ public static void main (String[] args) { try { Naming.rebind ("SHello", new HelloImpl ("Hello, world!")); System.out.println ("HelloServer is ready."); } catch (Exception e) { System.out.println ("HelloServer failed: " + e); } } }

16. Hello World: The Client import java.io.*; import java.rmi.*; public classHelloClient{ /* * Client program for the "Hello, world!" example */ public static void main (String[] args) { try { HelloInterface hello = (HelloInterface) Naming.lookup ("//matei.ece.ubc.ca/SHello"); /* ... Now remote calls on hello can be used ... System.out.println (hello.say()); } catch (Exception e) { System.out.println ("HelloClient failed: " + e); } }

17. Hello World: Compilation • On the server side • compile with Java compiler: HelloInterface.java,HelloImpl.java,HelloServer.java • compile with RMI compiler: Hello • command:rmic Hello  produces class Hello_Stub.class • start the RMI registry: rmiregistry &(Standard port number 1099) • On the client side • compile HelloClient • class HelloInterface.class needs to be accessible!

18. Quiz: What is this code meant to do? import java.rmi.*; public interface ComputeServer extends Remote { Object compute(Task task) throws RemoteException; } public interface Task { Object run(); } import java.rmi.*; import java.rmi.server.*; public class ComputeServerImpl extends UnicastRemoteObject implements ComputeServer { public ComputeServerImpl() throws RemoteException { } public Object compute(Task task) { return task.run(); } }

19. Recap: Steps in developing an RMI application • Design the remote interface for the object. • Implement the object specified in the interface. • Implement client/application 3. 2. XYZ Implementation XYZ Client 1. uses implements XYZ interface Client Host Server Host

20. RMI – Steps: Compile, Deploy and Use • Compile. • Compile (javac): interface, server, client • Compile interface (rmic): Generate the stubs XYZ Client Stub XYZ Implementation Stub 1. uses implements XYZ interface Client Host Server Host

21. rmiregistry 7. Retrieve object reference 6. Store object reference rmic 4. 4. 2. XYZ Client Stub XYZ Implementation Stub 1. uses implements XYZ interface Client Host Server Host RMI – Steps: Compile, Deploy and Use • Start rmiregistry • Start server, instantiate remote object & register it • Start client – locate remote object reference • Invoke method on remote object

22. Java Remote Method Invocation • Internals

23. server client remote server stub object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote module reference module module module 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 server stub(using methodID in message). Server stub - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object. Internal Implementation of RMI RMI: software layer between application level objects and communication and remote reference modules

24. Communication Modules • Reside in client and server • Carry out Request-Reply jointly • use unique message ids (new integer for each message) • implement given RMI semantics • Server’s communication module • selects dispatcher within RMI software • calls Remote Reference Module to convert remote object reference to local

25. Remote Reference Module • Creates remote object references and proxies • Translates remote to local references (object table): • correspondence between remote and local object references (proxies) • Called by RMI software • when marshalling/unmarshalling

26. RMI Software Architecture • Proxy • behaves like local object to client • forwards requests to remote object • Dispatcher • receives request • selects method and passes on request to skeleton • Server stub (aka skeleton) • implements methods in remote interface • unmarshals data, invokes remote object • waits for result, marshals it and returns reply

27. Java Remote Method Invocation • Miscelaneous

28. RemoteObject RemoteServer UnicastRemoteObject Activatable <servant class> Classes Supporting Java RMI Good if you want to control the set of active objects yourself

29. Binding and Naming Goal • mapping from textual names to remote references • used by clients as a look-up service (cf Java RMIregistry) Available methods • void rebind (String name, Remote obj) • used by a server to register the identifier of a remote object by name • void bind (String name, Remote obj) • alternatively 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) • removes a binding. • Remote lookup(String name) • used by clients to look up a remote object by name. A remote object reference is returned. • String [] list() • This method returns an array of Strings containing the names bound in the registry.

30. RMI Security • Server/client may not trust each other • User code (or even Stubs) could be malicious

31. RMI: Loading stub classes • Client can load (application & stub) classes dynamically • java.rmi.server.codebaseproperty defines where these are loaded from • The RMI class loader always tries to load stubs from the CLASSPATH first • Next, it tries downloading classes from a remote location • java.rmi.server.codebase specifies which web server • (but only if a security manager is enabled) • CLASSPATH can be confusing • 3 VMs, each with its own classpath: • Server vs. Registry vs. Client

32. RMI Security Managers • None • Remote stub loading disabled • Class/Stubs loading still works if they are in local CLASSPATH • RMISecurityManager Disables all functionality except • class definition and access • A downloaded class is allowed to make a connection if the connection is initiated via the RMI transport. if(System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } • Need to specify a security policy file at runtime by defining a value for the java.security.policy property: • java -Djava.security.policy=policyfilename • AppletSecurityManager • Stub can only do what an applet can do

33. Server logging Start logging: • from command line at startup: java java -Djava.rmi.server.logCalls=true YourServerImpl • or enable inside program: RemoteServer.setLog(System.err);

34. Assignment 2 discussion

35. Assignment 2 discussion Push vs. pull design • Server initiates communication (pushes data) • Advantage: possibly lower load on server • Drawback: server needs to maintain state (list of clients) • Client initiates communication (pulls data) • Advantage: no client registration needed, server does not maintain data, more flexibility for clients • Drawback: load on server, DoS attacks

36. Assignment 2 discussion • Server initiates communication (pushes data) • Two subsequent problems: • When to initiate communication (push the data)? • Where to push it (How to find he clients?

37. Similar to Callbacks Q: How can one implement asynchronous communication? Deal with asynchronous events? Callback mechanism • The client presents a notification method (or object for RMI) and registers it with the server • Server invokes the method (“calls back”) to notify the client • (Note for RMI: the rmiregistry is out of the loop) • RMI specific – two solutions • The object passed by the client extends UnicastRemoteObject, • The remote object prepares itself for remote use by calling • UnicastRemoteObject.exportObject (<remote_object>, 0)

38. Assignment 2 discussion: Chat system using RMI & callbacks One possible solution: • the server has • aMulticaster object with a method send(String) • each client has • a Display object with a method show(String) both methods are remote. Clients invoke send and the server invokes show. Sending a string means showing it on all displays.

39. Garbage collection in single box systems Solutions • Reference counting • Tracing based solutions (mark and sweep)

40. Garbage collection in distributed systems • Why is it different? • References distributed across multiple address spaces • Why a solution may be hard to design: • Unreliable communication • Unannounced failures • Overheads

41. Reference Counting • The problem: maintaining a proper reference count in the presence of unreliable communication. • Key: ability to detect duplicate messages • [A note on terminology: for the next few slides I’ll use proxy for client stub and skeleton for server stub.]

42. Reference Counting (cont) Passing remote object references • Copy the reference and let the destination increment the counter • Problems? • What if P1 deletes its reference before P2 increments the counter • Signal the copy first to the server • Problems? • Overheads, Coupling (what if P2 fails?)

43. Advanced Reference Counting Weighted Reference Counting • Initial assignment of weights (lifes) • New weight (life) assignment when creating a new reference.

44. Advanced Reference Counting Weighted Reference Counting (II) Weight (life) assignment when copying a reference. • Pros/cons? • + Create new references without contacting the server! • - Client machine failures

45. Reference Listing (Java RMI’s solution) • Skeleton maintains a list of client proxies • Creating a remote reference • Assume P attempts to create remote reference to O • P sends its identification to O skeleton • O acknowledges and stores P identity • P creates the proxy • Copying a remote reference • (P1 attempts to pass to P2 a remote reference to O) • Advantages: • add/delete are idempotent • i.e. duplicate operations have no effect • no reliable communication required • Drawback • overheads/scalability – the list of proxies can grow large • handling unanounced client failures (may lead to resource leak)

46. Reference Listing (Java RMI’s solution) Handling failures • Handling failures • Lease based approach: • Skeleton promises to keep info on client only for limited time. • If info not renewed then the skeleton discards it. • Pros/Cons?

47. Summary so far • Push vs. pull design • Callbacks • Distributed garbage collection • Solutions much more complex than for non-distributed case • No perfect solution: depending on the assumptions you make on your platform one or the other might offer the best tradeoffs • Lease based approaches (or soft-state): often practical solutions to scale in distributed environments