1. Communication Chapter 4

2. Introduction  Interprocess Communication is at the heart of all distributed systems.  Communication in distributed systems is always based on low-level message passing as offered by the underlying network.  Is it difficult?  Four widely used models for communication: Remote Procedure Call (RPC), Remote Method Invocation (RMI), Message-Oriented Middleware(MOM) and streams

3. Layered Protocols  Essential for communication between two different entities.  There are different layers: Examples are OSI and TCP/IP.  OSI: Seven Layers  Connection-oriented and Connection less.  Does OSI support QoS and multicasting?

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

5. Layered Protocols (2) A typical message as it appears on the network. 2-2

6. Layered Protocols (2)  Why protocols are important.  Example: Airlines and its caterer.  Independence  OSI model was not popular.  TCP/IP was more popular.  Physical layer: concerned with the transmission of 0s and 1s, voltage levels, bits/sec  Data link layer: error detection and correction,  Framing  Checksum

7. Layered Protocols (2)  Network layer: The question of how to choose the best path is called routing.  Is shortest route is always the best route.  Some routing algorithms are adaptive while others are not.  IP is connectionless and IP packets are routed independent of others.  ATM is connection oriented  Is virtual channel is unidirectional.  Virtual paths

8. Transport layer  Upon receiving a message from the application layer, the TP breaks it into smaller pieces, assigns each one a sequence number and then sends them all.  IP over ATM  RTP (Real time Transport Protocol).

9. Client-Server TCP  Its reliable but puts more overhead.  But LANs are already reliable.  Why TCP can be unattractive for client-server interaction.  Its much better to combine setting up a connection with immediately sending the request and like-wise combine sending an answer with closing the connection (fig b). This is TCP for Transactions.

10. Higher-level Protocols  In IP suite everything above transport layer is grouped together.  Session and presentation protocols; Dialog control, which party is currently talking, and provides synchronization, crash recovery through check points  Presentation layer: meaning of bits, easier for machines to communicate with different representations.

11. Higher-level Protocols  Applications Protocols:  From OSI perspective all distributed systems are just applications.  Missing in the model is the clear distinction between applications, application-specific protocols and general- purpose protocols.  HTTP: Application Specific Protocol was designed to remotely manage and handle transfer web pages.HTTP is also used not in the context of web as well. For example Java’s RMI uses HTTP to request the invocation of remote objects that are protected by a firewall.

12. Middleware Protocols  Middleware is an application that logically lives in the application layer, but which contains many general purpose protocols.  For example ways to establish authentication (not tied to any specific application), authorization.  Commit Protocols: In a group of processes either all processes carry out a particular ops or that the ops is not carried out at all.This is called Atomicity.  Distributed Locking protocol (protection against simultaneous access)

13. Middleware Protocols An adapted reference model for networked communication. 2-5

14. Middleware Protocols  Some of the middleware comms protocols could belong to transport layer, but they are kept at a higher level. For example reliable multicasting service that guarantee scalability can be implemented only if application reqs are taken into account.

15. Remote Procedure Call  When a process on machine A calls a procedure located 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 is visible to the programmer. This is called RPC

16. Conventional Procedure Call a)Parameter passing in a local procedure call: the stack before the call to read b)The stack while the called procedure is active

17. Conventional Procedure Call  Count=read (fd, buf, nbytes)  In C parameters can be call-by-value or call-by- reference.  Call-by-value: the called procedure may modify it but changes do not affect the original value at the calling site.  A reference parameter in C is a pointer to a variable (i.e., the address of the variable) rather than the value of the variable.

18. Conventional Procedure Call  Arrays are always by reference in C. If the called procedure uses this parameter to store something into the character array it does modify the array in the calling procedure.  Call-by-copy/restore: it consists of having the variable copied to the stack by the caller, as in call- by-value and then copied back after the call overwriting the caller’s original value.

19. Client and Server Stubs  We want RPC to be transparent-calling procedure should not be aware that the called procedure is executing on a different machine.  When read is actually a remote procedure (e.g one that will run on the file server’s machine) a different version of read called a client stub is put into the library.  It does not ask the OS to give it data. Instead it packs the parameters into a message and requests that message to be sent to the server.

20. Client and Server Stubs  Following the call to send the client stub calls receive, blocking itself until the reply comes back.  When the message arrives at the server, the server’s OS passes it up to a server stub.  The server stub unpacks the parameters from the message and then calls the server procedure in the usual way (fig b).

21. Client and Server Stubs Principle of RPC between a client and server program.

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

23. Passing Value Parameters (1) Steps involved in doing remote computation through RPC 2-8

24. Passing Value Parameters (1)  Packing parameters into a message is called parameter marshaling.  Consider a remote procedure add (i,j) that takes two integer parameters i and j and returns their arithmetic sum as a result.  The call to add is shown in the left-hand portion (in the client process) in the fig.  The client stub takes its 2 parameters and put them in a message as indicated. It also puts the name of the procedure to be called in the message.

25. Passing Value Parameters (1)  When the message arrives at the server, the stub examines the message to see which procedure is needed and then makes the appropriate call.  When the server has finished, the server stub gains control again. It takes the result provided by the server and packs it into a message. This message is sent back to the client stub, which unpacks it and returns the value to the client procedure.  As long as the client and server machines are identical and all the parameters and results are scalar types this model works fine.

26. Passing Value Parameters (1) Problem: some machines such as Intel Pentium number their bytes from right to left, whereas Sun SPARC, number them the other way. The Intel format is called little endian and the SPARC format is called the big endian. Fig (a) shows the parameter portion of a message built by a client stub on an Intel pentium. Fig (b) shows the message received by a SPARC.

27. Passing Value Parameters (2) 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

28. Passing Reference Parameters  How are pointers passed?. This is really difficult.  In the previous example: If the second parameter (the address of the buffer) is 1000 on the client, one cannot pass the 1000 to the server and expect it to work.  Address 1000 on the server might be in the middle of the program text.  Solution: Copy the array into the message and send it to the server. The server stub can then call the server with a pointer to this array.

29. Passing Value Parameters (1)  This pointer has a different numerical value than the second parameter of read has.  When the server finishes the original message can be sent back to the client stub, which copies it back to the client.

30. Parameter Specification and Stub Generation a)A procedure b)The corresponding message.

31. Parameter Specification and Stub Generation  Stubs for the same protocol but different procedures generally differ only in their interface to the applications.  An interface consists of a collection of procedures that can be called by a client and which are implemented by a server.  An interface is generally available in the same programming language as the one in which client or server is written.  Interfaces are often specified by means of an Interface Definition Language (IDL)

32. Parameter Specification and Stub Generation  An interface specified in such an IDL is then subsequently compiled into a client stub and a server stub along with the appropriate compile-time or run- time interfaces.

33. Asynchronous RPC  In conventional procedure calls when a client calls a remote procedure the client will block until a reply is returned  When there is no result to return it leads to blocking the client while it could have done useful work.  To support such situation RPC systems provide for Asynchronous RPCs  The client immediately continues after issuing the RPC and the server immediately sends a reply back (ack) to the client and after that it calls the requested proc

34. Asynchronous RPC (1) a)The interconnection between client and server in a traditional RPC b)The interaction using asynchronous RPC 2-12

35. Asynchronous RPC (2) A client and server interacting through two asynchronous RPCs 2-13

36. Asynchronous RPC (2)  The client first hands over a list of host names that should be looked up and continues when the server has acknowledged the receipt of that list.  The second call is done by the server who calls the client to hand over the addresses it found. This is called Deferred Synchronous RPC  One-way RPC: the client does not wait for an ack of the server’s acceptance of the request.

37. DCE RPC  Distributed Computing Environment (DCE) is not as popular as Sun RPC.  Initially designed for UNIX it has now been ported to all major operating systems including VMS and Windows NT.  The programming model underlying all of DCE is the client server model.  There are number of services that form part of DCE itself. The distributed file service provides a transparent way of accessing any file.

38. DCE RPC  The directory service is used to keep track of the location of all resources (machines, printers, servers, etc). The directory service allows a process to ask for a resource and not to be concerned about the location  Security Service: only authorized persons are allowed  Distributed time service: attempts to keep clocks on different machines globally synchronized.

39. Goals of DCE RPC  Makes it possible for a client to access a remote service by simply calling a local procedure.  RPC system can automatically locate the correct server and subsequently set up the comms between client and server software (binding).  Can also handle the message transport in both the directions, fragmenting, reassembling them as needed (large array).  Automatically handle data type conversions between the client and server.

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

41. Binding a Client to a Server Client-to-server binding in DCE. 2-15

42. Binding a Client to a Server  To allow a client to call a server, its necessary that the server is registered and prepared to accept incoming calls.  Registration helps the client to locate the server and bind to it.  Server Location is done in two steps:  Locate the server’s machine  Locate the server (i.e., the correct process) on that machine.

43. Binding a Client to a Server  The client needs to know the endpoint on the server’s machine (port) to distinguish incoming messages for different machines  In DCE a table of (server, endpoint) is maintained on each server machine by a process called DCE daemon.  1. Before it becomes available for incoming requests the server must ask the OS for an endpoint. It then registers this endpoint with the DCE daemon. The DCE daemon records this info in the endpoint table

44. Binding a Client to a Server  The server also registers with the directory service by providing it the N/W address of the server machine and the name under which server can be looked up.  A client wants to bind a video server that is locally known under the name /local/multimedia/video/movies.  It passes this name to the directory service which returns the N/W address of the machine running the video server.

45. Binding a Client to a Server  The client then goes to the DCE daemon on that machine and asks it to look up the endpoint of the video server in its endpoint table. RPC can now take place.  The client stub marshals (collects) the parameters to the runtime library for transmission using the protocol chosen at binding time.When a message arrives at the server side it is routed to the correct server based on the endpoint contained in the incoming message. The runtime library passes the message to the server stub which unmarshals the parameters and calls the server. The reply goes back by reverse route.

46. Performing an RPC  The client stub marshals the parameters to the runtime library for transmission using the protocol chosen at binding time.  When a message arrives at the server side it is routed to the correct server based on the endpoint contained in the incoming message.The runtime library passes the message to the server stub which unmarshals the parameters and calls the server. The reply goes back by the reverse route.  Several Semantic Options: The default is at most once operation and other in which multiple attempts

47. Message-Oriented Communication  Transient Communication: A message is stored by the communication system only as long as the sending and receiving applications are executing. If the comms server cannot deliver a message to the next server the message will be discarded.  Traditional Store and Forward.  Asynchronous Communication: Sender continues immediately after it has submitted its message for transmission. The message is stored in a local buffer at sending host or the Ist comms server.

48. Message-Oriented Communication  Synchronous Communication: the sender is blocked until its message until its message is stored in a local buffer at the receiving host or actually delivered to the receiver.  Persistent Asychronous : Email systems use this. Message is persistently stored at the local host or first Comms server.  Persistent Synchronous: A sender message is blocked until its message is stored in the receiver’s buffer.  Transient asynchronous: offered by transport-level datagram services such as UDP. The message is temporarily stored at the sender in a buffer.RPC is another example.

49. Message-Oriented Communication  Transient Synchronous: In weakest form, the sender is blocked until the message is stored in a local buffer at the receiving host. The sender receives an ack and then continues. Example is asyn RPC or deferred syn ops  In delivery based transient synchronous comms the sender is blocked until the message is delivered to the receiver for further processing. Example Asyn RPC. The strongest form is response-based transient synchronous communication, sender blocks until it receives a reply message from the other side. Examples RPCs and RMIs request-reply schemes.

50. Message-Oriented Communication  What is the problem with transient communication?  Any failure transparency  Solution?

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

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

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

54. Message Oriented Transient Comms  Messaging through transport level sockets:  Berkeley Sockets:Sockets Interface introduced in Berkeley Unix.  Another Interface is XTI stands for X/Open Transport Interface, Formally known as Transport Layer Interface (TLI) developed by AT&T.  Both are similar in N/W programming model, but differ in their set of primitives.

55. Berkeley Sockets (1) Socket 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

56. Berkeley Sockets (1)  Bind: Server should bind the IP address of its machine together with a port no to a socket. Binding tells the OS that the server wants to receive the messages only on the specified address and port  Listen: allows the local OS to reserve enough buffers for a specified max no of connections that the caller is willing to accept.  Accept: When a request arrives, the local OS creates a new socket with the same properties as the original one and return to the caller.  Connect: requires that the caller specifies the transport level address to which a connection request is to be sent.. The client is blocked until a connection has been set up successfully after which both sides can start exchanging info through write and read primitives, which establish the sending and receiving of data respectively.  Close: Both Client and server call close primitive.

57. Berkeley Sockets (2) Connection-oriented communication pattern using sockets.

58. Message-Passing Interface (MPI) Sockets were insufficient due to: 1)Support only simple send and receive primitives 2)Sockets has been designed to communicate across networks using general purpose protocol stacks such as TCP/IP. They were not suitable for the proprietary protocols (used different form sof buffering and synchronization) for high speed interconnection N/Ws used in MPPs(Massively Parallel Processors). 3)These proprietary libraries were mutually incompatible. Portability problem. 4)So a standard Message-Passing Interface (MPI) is required. 5)It is for parallel comms, It makes use of under lying N/W. 6)Comms takes place within a known group of processes. Each group is assigned an identifier. Each process within a group is also assigned an identifier. 7)A (groupID, processID) pair therefore uniquely identifies the source or destination of a message.

59. The Message-Passing Interface (MPI) Some 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

60. Message-Queuing Model (1)  It is also known as Message Oriented Middleware (MOM)  Provides extensive support for persistent asynchronous communication.  Offer intermediate-term storage capacity for messages w/o requiring either the sender or receiver to be active during message transmission. Take minutes to complete.  Applications communicate by inserting messages in specific queues. The messages are forwarded over a series of servers and are eventually delivered to the destination even it was down.

61. Message-Queuing Model (1)  Each application has its own queue to which other applications can send the messages. Multiple applications can also share a queue.  No need for the receiver to be executing when the messages is being sent, and no need for the sender to be executing when the message is picked up by the receiver.  Addressing is done by providing a system wide unique name of the destination queue  The underlying system takes care of fragmentation and reassembly large messages transparent to applications

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

63. Message-Queuing Model (2) Basic 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. Notify Install a handler to be called when a message is put into the specified queue.

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

65. General Architecture of a Message-Queuing System (1)  Source Queue: Messages to be put in the queues that are local to the sender that is on the same machine.  Destination Queue: To which the message is transferred.  Collection of Queues is distributed across multiple machines  To transfer messages message queuing should map queues to network locations. Maintain a database queue names to N/W locations.Just like DNS for email in the Internet.  Queues are managed by queue managers. Queue managers interact with the applications. Queue managers also act as routers or relays to forward messages to other Queue managers. This becomes complete overlay network

66. General Architecture of a Message-Queuing System (1)  Use of relays, no general naming service that maintain dynamic queue to location mapping. Static topology. N/w management problems.  Solution is to use routers as shown in the fig. R1 may derive from B’s name that it is forwarded to R2. So routers are updated when queues are added or removed, and queue manager needs to know only the nearest router.

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

68. Message Brokers  Integration of new applications into a single coherent distributed system. Integration requires that applications can understand the messages they receive.  The sender should have its outgoing message in the same format as that of the receiver.  Problem: Each time an application is added to the system that requires a separate message format. Receiver will have to be adjusted.  Is Common message format like traditional N/W protocols possible?

69. Message Brokers  Collection of processes and applications are highly diverse.  In message queuing system conversions are handled by message brokers.  It converts incoming messages to a format that can be understood by the destination application. For example incoming message contains a table from a database, in which records are separated by a special end-of-record delimiter and fields have a known fixed length. Message can change the field to variable length.  Database of Rules: Specifies how a message in format X to be converted to a message in format Y.

70. Message Brokers  Defining Rules.  Rules to be entered manually in the database  Program conversions can be performed by using normal programming languages.  Can we compare message queuing system with email service.  General message queuing system is not aimed supporting only the end users. They enable persistence communication between processes, regardless of whether a process is running a user application, handling access to a database, performing computation so on. Message queuing have wide range of applications including email, batch processing etc.  Email systems need not provide, guaranteed message delivery etc  Example of message Q is a query expanding several databases

71. Message Brokers The general organization of a message broker in a message-queuing system. 2-30

72. Example: IBM MQSeries General organization of IBM's MQSeries message-queuing system. 2-31

73. Example: IBM’s WebSphere Message Queuing System  All queues are managed by queue managers: A queue manager is responsible for removing messages from its send queues and forwarding those messages to other queue managers.  It also picks up the incoming messages from the underlying N/W and storing them in the appropriate input queue.  Queue managers are connected to message channels. They are unidirectional reliable connection between a sending and a receiving Q manager.  Each of the two ends of a message channel is managed by a message channel agent (MCA).

74. Example: IBM MQSeries  Check send queues for a message, wrap it into a transport level packet and send it along the connection to its associated receiving MCA. Receiving MCA listens for an incoming packet, unwrap it and subsequently store the unwrapped message into the queue.  Two possibilities: Q managers can be linked to the same process as the application. Qs are hidden from the application behind a standard interface. (2) Q managers and applications run on separate machines. RPC based synchronous communication is used for comms between Q manager and application

75. Channels  Each message channel has only one associated send queue from which it fetches the messages it should transfer to the other end. Both sending and receiving MCAs are up and running. MCAs can be started by allowing the sending MCA to configure the channel’s send Q to set off a trigger when a message is first put into the Q. The trigger is associated with a handler to start the sending MCA so that it can remove messages from the send Q.  MCA can also be started by a control message sent.  Channels are stopped automatically after a specified time has expired in which no more messages were dropped into the send Q.

76. Channels Some 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 count Specifies maximum number of retries to start up the remote MCA Delivery retriesMaximum times MCA will try to put received message into queue

77. Message Transfer (1)  Each message carries its destination address for which transmission header is used (to transfer from one QM to another QM).  An address consists of 2 parts: name of QM to which message is to be delivered. The second part is the name of the destination Q in that QM to which message is to appended.  Routes are explicitly stored inside a QM in a routing table. An entry in the routing table is a pair (destQM, sendQ). This is called an alias in MQSeries).  In the fig an application linked to QMA can refer to a remote QM using the local alias LA1. The QM will first look up the actual destination in the alias table to find it is queue manager QMC. The route to QMC is found in the routing table which says that messages for QMC should be appended to the outgoing queue SQ1 which is used to transfer messages to queue manager QMB which will forward the message using its routing table

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

79. Message Transfer (2) Primitives available in an IBM MQSeries MQI(message Q Interface available to applications) PrimitiveDescription MQopenOpen a (possibly remote) queue MQcloseClose a queue MQputPut a message into an opened queue MQgetGet a message from a (local) queue

80. Stream-Oriented Communication  The ways of communications discussed so far used more or less independent and complete units of information. The timing was not important.  In audio and video timing is absolutely critical.Suppose an audio stream of CD quality, meaning that original sound wave has been sampled at a frequency of 44100 Hz. To reproduce the original sound it is essential the audio samples are played out at intervals of exactly 1/44100 sec.

81. Support for Continuous Media  Different representations are used for different types of information. Text is encoded as ASCII. Images as GIF, JPEG, audio as taking 16 samples using PCM.  In continuous (representation) media the temporal relationships between data items are fundamental to interpret what the data means. Successive images must be displayed at a uniform spacing T in time, 30-40 msec per image.  Discrete (representation) media, text and still images. the temporal relationships between data items are not fundamental.

82. Data Stream  To capture the exchange of time-dependent information, distributed systems provide support for data streams.  Timing is crucial to continuous data streams.  In asynchronous transmission mode the data items in a stream are transmitted one after the other, but no constraints when transmission of items should take place. Typical for discrete data streams. FTP.  Synchronous Transmission Mode.There is max ete delay defined for each unit in a data stream. Whether a data unit is transferred much faster than the max delay is not important.

83. Data Stream  Isochronous Transmission Mode: It is necessary that data units are transferred on time. Data transfer is subject to jitter.  Simple Stream: consists of only a single sequence of data, whereas a complex stream consists of several related simple streams called substreams. The relation between the substreams in a complex stream is often also time dependent.  For example stereo audio can be transmitted by means of a complex stream consisting of two substreams. These 2 substreams are continuously synchronized.  The other example of complex stream is movie. Such a stream could consist of a single video stream along with two streams for transmitting the sound of the movie in stereo. The 4 th stream will be subtitles for the deaf, or a translation into a different language.Synchronization is important

84. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Data Stream Figure 4-26. A general architecture for streaming stored multimedia data over a network.

85. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Streams and Quality of Service Timing (and other nonfunctional) requirements are generally expressed as QoS requirements. What is needed from the underlying distributed system Properties for Quality of Service: The required bit rate at which data should be transported. The maximum delay until a session has been set up The maximum end-to-end delay. The maximum delay variance, or jitter. The maximum round-trip delay.

86. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Enforcing QoS (1) Figure 4-27. Using a buffer to reduce jitter.

87. Enforcing QoS (1) Differentiated Services Expedited Forwarding Assured Forwarding In fig 4-27 The packets are delayed with a certain variance when transmitted over the network, the receiver simply stores them in a buffer for a maximum amount of time. This will allow the receiver to pass packets to the application at a regular rate. If a packet is delayed. The solution is to increase the buffer size

88. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Enforcing QoS (2) Figure 4-28. The effect of packet loss in (a) non interleaved transmission and (b) interleaved transmission.

89. Stream Synchronization  In complex stream different stream are mutually synchronized.  Two types of synchronization can occur.  The syn between discrete data stream and continuous data stream. For example synchronization of audio stream with the presentation of slides.  Syn between continuous data streams. Example is movie with video and audio.

90. Synchronization Mechanisms (1) The principle of explicit synchronization on the level data units.

91. Synchronization Mechanisms (1) Two issues need to be addressed.(1) the basic mechanisms for syn two streams (2) the distribution of those mechanisms in a N/W environment. Application is offered an interface that allows it to specify that rate at which images should be displayed. The next example is of multimedia middleware systems. Multimedia middleware offers a collection of interfaces for controlling audio and video streams, including interfaces for controlling devices such as monitors, cameras, microphones etc. Each device and stream has its own high level interfaces including interfaces for notifying an application when some event occurred.

92. Synchronization Mechanisms (2) The principle of synchronization as supported by high-level interfaces. 2-41

93. Synchronization Mechanisms (2) The distribution of syn mechanisms: The receiving side of a complex stream must have a complete syn spec locally available. Commonly this information is provided implicitly by multiplexing the different streams containing all data units, including those for synchronization. Example is MPEG2 in which an unlimited no of continuous and discrete streams are merged into a single stream. Broadcast video is compressed 4 to 6 Mbps.

94. Synchronization Mechanisms (2) Each input stream is turned into a stream of packets that carry a time stamp. These streams are multiplexed into a program stream consisting of packets having the same time base. The receiving side demux the stream again using the timestamps of each packet as the basic mechanism for interstream syn. Where the syn should take place, @ the sender or @ the receiver. Its better to merge the streams at the sender, because at the receiver when the streams will arrive they will be subjected to different delays depending on the N/W condition.

95. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Overlay Construction Figure 4-31. The relation between links in an overlay and actual network-level routes.

96. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Information Dissemination Models (1) Anti-entropy propagation model –Node P picks another node Q at random –Subsequently exchanges updates with Q Approaches to exchanging updates –P only pushes its own updates to Q –P only pulls in new updates from Q –P and Q send updates to each other

97. Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5 Information Dissemination Models (2) Figure 4-32. The relation between the fraction s of update-ignorant nodes and the parameter k in puas a function of k.re gossiping. The graph displays ln(s)