1. Two Approaches yCommunication-Oriented Design Begin with the communication protocol. Design a message format and syntax. Design the client and server components by specifying how each reacts to incoming message and how each generates outgoing messages. yApplication-Oriented Design Begin with the application. Design a conventional application program to solve the problem. Build and test a working version of the conventional program that operates on a single machine. Divide the program into two or more pieces, and add communication protocols that allow each piece to execute on a separate computer.

2. Communication in Distributed System zInterprocess communication is at the heart of all distributed systems. It makes no sense to study distributed systems without carefully examining the ways that processes on different machines can exchange information. zTo understand the communication in the distributed system, two main topics should be discussed: yProtocols governing the rules that communicating processes must adhere to. yModels for communication: Remote Procedure Call (RPC), Remote Method Invocation (RMI), Message-Oriented Middleware (MOM), and streams.

3. Layered Protocols (1) zFigure 4-1. Layers, interfaces, and protocols in the OSI model.

4. Layered Protocols (2) zA typical message as it appears on the network.

5. Middleware Protocols zAn adapted reference model for networked communication.

6. Middleware layers Applications Middleware layers Request reply protocol External data representation (XDR) Operating System RMI, RPC and events

7. Types of Communication zViewing middleware as an intermediate (distributed) service in application-level communication. yPersistent communication vs. Transient communication yAsynchronous communication vs. Synchronous Communication

8. Outcomes: RPC zWhat is RPC? zThe difference between conventional procedure call and RPC? zUnderstand the function of client and server stubs zHow many steps could happen for a RPC? zHow RPC deals with the parameter passing? zHow to write a client and server using DCE RPC?

9. Outcomes: Remote Object Invocation zWhat is so called distributed objects? zHow to bind a client to an object? zImplementation of object references zStatic vs dynamic remote method invocations

10. Definition of Remote Procedure Call zPrinciple of RPC between a client and server program. zWhen a process on machine A calls a procedure on machine B, the calling process on A is suspended, and execution of the called procedure takes place on B. Information can be transported from the caller to the callee in the parameters and can come back in the procedure result. No message passing at all is visible to the programmer. This method is known as Remote Procedure Call.

11. RPC - Conventional Procedure Call a)Parameter passing in a local procedure call: the stack before the call to read (fd, buf, nbytes) b)The stack while the called procedure is active 1.The stack before the call is shown in (a) 2.To make call, the caller pushes the parameters onto the stack in order, last one first, as shown in (b) 3.After the read procedure has finished running, it puts the return value in a register, removes the return address and transfers control back to the caller. 4.The caller then removes the parameters from the stack, returning the stack to the original state it had before the call.

12. Client and Server Stubs zTraditional Procedure call: The programmer puts a call to read in the code to get the data. The read routine is extracted from the library by the linker and inserted into the object program. It is a short procedure, which is generally implemented by calling an equivalent read system call. zRPC: It achieves its transparency in an analogous way. When read is actually a remote procedure, a different version of read called client stub, is put into the library. Like the original one, it too, does a call to the local OS. Only unlike the original one, it does not ask the OS to give it data. Instead, it packs the parameters into a message and request that message to be sent to the server. Following the call to send, the client stub calls receive, blocking itself until the reply comes back

13. Figure 5.7 Role of client and server stub procedures in RPC client Request Reply Communication module dispatcher service client stub server stub procedure client processserver process procedure program zThe function of stub is that, instead of asking operating to give it data, it packs the parameters into message and requests the message to be sent to the server. After client stub calls send, it calls receive, block itself until the reply comes back.

14. Client and Server Stubs zSteps involved in doing remote computation through RPC 2-8

15. Steps of a Remote Procedure Call 1.Client procedure calls client stub in normal way 2.Client stub builds message, calls local OS 3.Client's OS sends message to remote OS 4.Remote OS gives message to server stub 5.Server stub unpacks parameters, calls server 6.Server does work, returns result to the stub 7.Server stub packs it in message, calls local OS 8.Server's OS sends message to client's OS 9.Client's OS gives message to client stub 10.Stub unpacks result, returns to client

16. Passing Value Parameters a)Original message on the Pentium (number their bytes from right to left) b)The message after receipt on the SPARC ( number their bytes left to right) c)The message after being inverted. The little numbers in boxes indicate the address of each byte

17. Files interface in Sun XDR const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; }; struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version VERSION { void WRITE(writeargs)=1;1 Data READ(readargs)=2;2 }=2; } = 9999;

18. Passing Reference Parameters zPassing the reference parameter is very difficult: yread(fd, buf, nbytes) example zOne solution is to forbid pointers and reference parameters in general. zStrategy : In read example, the client stub knows the buf points to an array and the array length. yClient stub copies the array into message and send it to the server yServer stub call the server with a pointer to this array yWhen server (procedure) finishes, the original message can be sent back to the client stub yClient stub copies buf back to the client (procedure). zExample ONC RPC call functions: ycallrpc(host, prog, progver, procnum, inproc, in, outproc, out); yhandle = clan_create (host, prog, vers, proto);

19. Example: DCE RPC zServices DCE RPC has: yThe distributed file service is a world wide file system that provides a transparent way of accessing any file in the system in the same way yThe directory service is used to keep track of the location of all resources in the system yThe security service allows resources of all kinds to be protected yThe distributed time service is a service that attempts to keep clocks on the different machines globally synchronized

20. Writing a Client and a Server zThe steps in writing a client and a server in DCE RPC. 2-14

21. Binding a Client to a Server zClient-to-server binding in DCE. zTo allow a client to call a server, the server must be registered first zThe steps to locate the server and bind to it: yLocate the server’s machine yLocate the server (i.e. the correct process) on that machine 2-15

22. Remote Object Invocation zWhat is so called distributed objects? zHow to bind a client to an object? zImplementation of object references zStatic vs dynamic remote method invocations

23. Remote and local method invocations invocation remote invocation remote local invocation A B C D E F

24. Distributed Objects zCommon organization of a remote object with client-side proxy. 1.Proxy is analogous to a client stub in RPC system. Its work is to marshal method invocation into messages or unmarshl reply messages to return result to client. 2.Skeleton is analogous to server stub. It works the similar way as proxy. 2-16

25. Binding a Client to an Object a)An example with implicit binding using only global references b)An example with explicit binding using global and local references Distr_object* obj_ref;//Declare a systemwide object reference obj_ref = …;// Initialize the reference to a distributed object obj_ref-> do_something();// Implicitly bind and invoke a method (a) Distr_object objPref;//Declare a systemwide object reference Local_object* obj_ptr;//Declare a pointer to local objects obj_ref = …;//Initialize the reference to a distributed object obj_ptr = bind(obj_ref);//Explicitly bind and obtain a pointer to the local proxy obj_ptr -> do_something();//Invoke a method on the local proxy (b)

26. Implementation of Object References zObject reference must contain enough information to allow a client to bind to an object. It would include the network address of the machine where the actual object resides, along with an endpoint identifying the server that manages the object, plus an indication of which object. zTo avoid the reassignment of the object reference, for example the endpoint for the recovery of server from crash, each machine should have a local daemon to listen to a well-known endpoint and keep track of the server-to-endpoint assignments in an endpoint table. zUsing the location server to keep track of the machine where an object’s server is currently running.

27. Static versus Dynamic Remote Method Invocations zDifference between RPC and RMI: yRPC only have general-purpose client-side and server side stubs available. yRMI generally support system wide object references. zStatic Invocation: using predefined interface definitions. It requires that the interfaces of an object are known when the client application is being developed. If interfaces change, application must recompile. zDynamic invocation: able to compose a method invocation at runtime. It takes the form such as: Invoke(object, method, input_parameters, output_parameters); zExample: Appending an integer int to a file object fobject: yStatic invocation: fobject.append(int) yDynamic invocation: invoke(fobject, id(append), int)

28. Figure 5.5 Invocation semantics 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

29. Figure 5.11 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;1 } public interface ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException;2 Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; }

30. Figure 5.12 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 next slide, 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.

31. Figure 5.13 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());} }

32. Figure 5.14 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 {... } }

33. Figure 5.15 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());} }

34. Figure 5.16 Classes supporting Java RMI RemoteServer UnicastRemoteObject Activatable RemoteObject