1 / 26

Distributed (Operating) Systems -Message-oriented Communication- -Stream-oriented Communication-

Distributed (Operating) Systems -Message-oriented Communication- -Stream-oriented Communication-. Fall 2011 Kocaeli University Computer Engineering Department. Communication Issues. Message-oriented communication Transient vs Persistent Synchronous vs asynchronous

sasson
Télécharger la présentation

Distributed (Operating) Systems -Message-oriented Communication- -Stream-oriented Communication-

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed (Operating) Systems -Message-oriented Communication- -Stream-oriented Communication- Fall 2011 Kocaeli University Computer Engineering Department

  2. Communication Issues • Message-oriented communication • Transient vs Persistent • Synchronous vs asynchronous • Stream-oriented communication

  3. Message-oriented Transient Communication • Many distributed systems built on top of simple message-oriented model • Example: Berkeley sockets

  4. Berkeley Socket Primitives

  5. Message-Passing Interface (MPI) • Sockets designed for network communication (e.g., TCP/IP) • Support simple send/receive primitives • Abstraction not suitable for other protocols in clusters of workstations or massively parallel systems • Need an interface with more advanced primitives • Large number of incompatible proprietary libraries and protocols • Need for a standard interface • Message-passing interface (MPI) • Hardware independent • Designed for parallel applications (uses transient communication)

  6. MPI • Key idea: communication between groups of processes • Each endpoint is a (groupID, processID) pair • MPI are intent to be used in clusters • It is basically used for scientific applications and parallel systems • It overcomes some of the TCP communications • MPI basically run on UDP • Socket based communication is also transient but it is based on synch communication • but here MPI also support asynchronous communication

  7. MPI Primitives

  8. Message-oriented Persistent Communication • Message queuing systems • Support asynchronous persistent communication • Intermediate storage for message while sender/receiver are inactive • Example application: email • Communicate by inserting messages in queues • Sender is only guaranteed that message will be eventually inserted in recipient’s queue • No guarantees on when or if the message will be read • “Loosely coupled communication”

  9. Message-Queuing Model (1)

  10. Message-Queuing Model

  11. General Architecture of a Message-Queuing System (2) • Queue manager and relays • Relays use an overlay network • Relays know about the network topology and how to route

  12. Message Brokers • Message broker: application level gateway in MQS • Convert incoming messages so that they can be understood by destination (format conversion) • Also used for pub-sub systems

  13. IBMʼsWebSphere MQ • Queue managers manage queues • Connected through message channels • Message channel agent (MCA) • Checks queue, wraps into TCP packet, send to receiving MCA

  14. Stream Oriented Communication • Message-oriented communication: request-response • When communication occurs and speed do not affect correctness • Timing is crucial in certain forms of communication • Examples: audio and video (“continuous media”) • 30 frames/s video => receive and display a frame every 30ms • Characteristics • Isochronous communication • Data transfers have a maximum bound on end-end delay and jitter • Push mode: no explicit requests for individual data units beyond the first “play” request

  15. To Push or Pull ? • Client-pull architecture • Clients pull data from servers (by sending requests) • Example: HTTP • Pro: stateless servers, failures are easy to handle • Con: limited scalability • Server-push architecture • Servers push data to client • Example: video streaming, stock tickers • Pro: more scalable, Con: stateful servers, less resilient to failure • When/how-often to push or pull?

  16. Examples

  17. Streams and Quality of Service • 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.

  18. Quality of Service (QoS) • Time-dependent and other requirements are specified as quality of service (QoS) • Requirements/desired guarantees from the underlying systems • Application specifies workload and requests a certain service quality • Contract between the application and the system

  19. Specifying QoS: Token bucket • The principle of a token bucket algorithm • Parameters (rate r, burst b) • Rate is the average rate, burst is the maximum number of packets that can arrive simultaneously

  20. Enforcing QoS (1) • Observation: There are various network-level tools, such as differentiated services by which certain packets can be prioritized. • Also: use buffers to reduce jitter

  21. Enforcing QoS (2) • Problem: How to reduce the effects of packet loss (when multiple samples are in a single packet)? • Solution: simply spread the samples:

  22. Stream synchronization • Multiple streams: • Audio and video; layered video • Need to sync prior to playback • Timestamp each stream and sync up data units prior to playback • Sender or receiver? • App does low-level sync • 30 fps: image every 33ms, lip-sync with audio • Use middleware and specify playback rates

  23. Synchronization Mechanism • Problem: Given a complex stream, how do you keep the different substreams in synch? • Example: Think of playing out two channels, that together form stereo sound. Difference should be less than 20–30 μsec! • Alternative: multiplex all substreams into a single stream, and demultiplex at the receiver. Synchronization is handled at multiplexing/demultiplexing point (MPEG).

  24. Multicasting • Multicast: sending data to multiple receivers • Network- and transport-layer protocols for multicast bogged down at the issue of setting up the communication paths to all receivers. • Group communication • IP multicast versus application-level multicast • Construct an overlay multicast tree rooted at the sender • Send packet down each link in the tree • Issues: tree construction, dynamic joins and leaves

  25. Application-Level Multicasting • IP multicasting works in IP layer. • Why not just use that? • Often difficult to configure, requires too much administrative support, agreement, etc. • Application-level seeks to address those issues. • Peer-to-peer communication using structured overlays can use application-layer protocols to support multicast • The overlay network is used to disseminate information to members

  26. Application-Level Multicasting • Essence: Organize nodes of a distributed system into an overlay networkand use that network to disseminate data. • Two possible structures: • Tree: unique path between every pair of nodes • Mesh: multiple neighbors ensure multiple paths (more robust)

More Related