Presentation is loading. Please wait.

Presentation is loading. Please wait.

Two Approaches yCommunication-Oriented Design Begin with the communication protocol. Design a message format and syntax. Design the client and server components.

Similar presentations


Presentation on theme: "Two Approaches yCommunication-Oriented Design Begin with the communication protocol. Design a message format and syntax. Design the client and server components."— Presentation transcript:

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 Middleware layers Applications Middleware layers Request reply protocol External data representation (XDR) Operating System RMI, RPC and events

4 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?

5 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

6 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

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

8 Client and Server Stubs zSteps involved in doing remote computation through RPC 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. 2-8

9 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

10 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

11 Passing Value Parameters a)Original message on the Pentium b)The message after receipt on the SPARC c)The message after being inverted. The little numbers in boxes indicate the address of each byte

12 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;

13 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);

14 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

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

16 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

17 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

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

19 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

20 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)

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

22 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)

23 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

24 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; }

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

26 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());} }

27 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 {... } }

28 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());} }

29 Figure 5.16 Classes supporting Java RMI RemoteServer UnicastRemoteObject Activatable RemoteObject

30 Message Oriented Communication

31 Persistence and Synchronicity in Communication (1) zGeneral organization of a communication system in which hosts are connected through a network 2-20

32 Persistence and Synchronicity in Communication (3) a)Persistent asynchronous communication b)Persistent synchronous communication 2-22.1

33 Persistence and Synchronicity in Communication (4) c)Transient asynchronous communication d)Receipt-based transient synchronous communication 2-22.2

34 Persistence and Synchronicity in Communication (5) e)Delivery-based transient synchronous communication at message delivery f)Response-based transient synchronous communication

35 Berkeley Sockets (1) zSocket primitives for TCP/IP. PrimitiveMeaning SocketCreate a new communication endpoint BindAttach a local address to a socket ListenAnnounce willingness to accept connections AcceptBlock caller until a connection request arrives ConnectActively attempt to establish a connection SendSend some data over the connection ReceiveReceive some data over the connection CloseRelease the connection

36 Berkeley Sockets (2) zConnection-oriented communication pattern using sockets.

37 The Message-Passing Interface (MPI) zSome of the most intuitive message-passing primitives of MPI. PrimitiveMeaning MPI_bsendAppend outgoing message to a local send buffer MPI_sendSend a message and wait until copied to local or remote buffer MPI_ssendSend a message and wait until receipt starts MPI_sendrecvSend a message and wait for reply MPI_isendPass reference to outgoing message, and continue MPI_issendPass reference to outgoing message, and wait until receipt starts MPI_recvReceive a message; block if there are none MPI_irecvCheck if there is an incoming message, but do not block

38 Message-Queuing Model (1) zFour combinations for loosely-coupled communications using queues. 2-26

39 Message-Queuing Model (2) zBasic interface to a queue in a message-queuing system. PrimitiveMeaning PutAppend a message to a specified queue GetBlock until the specified queue is nonempty, and remove the first message PollCheck a specified queue for messages, and remove the first. Never block. NotifyInstall a handler to be called when a message is put into the specified queue.

40 General Architecture of a Message-Queuing System (1) zThe relationship between queue-level addressing and network-level addressing.

41 General Architecture of a Message-Queuing System (2) zThe general organization of a message-queuing system with routers. 2-29

42 Message Brokers zThe general organization of a message broker in a message-queuing system. 2-30

43 Example: IBM MQSeries zGeneral organization of IBM's MQSeries message-queuing system. 2-31

44 Channels zSome attributes associated with message channel agents. AttributeDescription Transport typeDetermines the transport protocol to be used FIFO deliveryIndicates that messages are to be delivered in the order they are sent Message lengthMaximum length of a single message Setup retry countSpecifies maximum number of retries to start up the remote MCA Delivery retriesMaximum times MCA will try to put received message into queue

45 Message Transfer (1) zThe general organization of an MQSeries queuing network using routing tables and aliases.

46 Message Transfer (2) zPrimitives available in an IBM MQSeries MQI PrimitiveDescription MQopenOpen a (possibly remote) queue MQcloseClose a queue MQputPut a message into an opened queue MQgetGet a message from a (local) queue


Download ppt "Two Approaches yCommunication-Oriented Design Begin with the communication protocol. Design a message format and syntax. Design the client and server components."

Similar presentations


Ads by Google