1 / 27

Group Communication Specifications Gregory V Chockler, Idit Keidar, Roman Vitenberg

Group Communication Specifications Gregory V Chockler, Idit Keidar, Roman Vitenberg. Presented by – Jyothish S Varma. Outline. Group communication – background Safety properties Membership service Multicast service Safe messages Ordering and reliability properties Liveness.

moswen
Download Presentation

Group Communication Specifications Gregory V Chockler, Idit Keidar, Roman Vitenberg

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. Group Communication SpecificationsGregory V Chockler, Idit Keidar, Roman Vitenberg Presented by – Jyothish S Varma November 19 2004 - NC state university

  2. Outline • Group communication – background • Safety properties • Membership service • Multicast service • Safe messages • Ordering and reliability properties • Liveness November 19 2004 - NC state university

  3. What is Group Communication? • What is a group? • A group is a collection of processes that cooperate to provide a service • Group Communication is a means for providing multi-point to multi-point communication, by organizing processes in groups. November 19 2004 - NC state university

  4. Distributed applications • Highly available servers • Web • Video-on-Demand • Collaborative computing • Shared white-board, shared editor, etc. • Military command and control • On-line strategy games • Stock market November 19 2004 - NC state university

  5. Important Issues in Building Distributed Applications • Consistency of view • Same picture of game, same shared file • Fault tolerance, high availability • Performance • Conflicts with consistency? • Scalability • Topology - WAN, long unpredictable delays • Number of participants November 19 2004 - NC state university

  6. Objectives of this paper • Formulate a comprehensive set of specifications • Combine representations of most existing GCS • Correlate terminology November 19 2004 - NC state university

  7. Send(G) G Group Communication • Group abstraction - a group of processes is one logical entity • Dynamic Groups (join, leave, crash) Systems: Ensemble, Horus, ISIS, Newtop, Psync, Sphynx, Relacs, RMP, Totem, Transis November 19 2004 - NC state university

  8. Model • Asynchronous message passing network • Allows partitions and merges • View • Set of process that belongs to a group November 19 2004 - NC state university

  9. General Framework • Signature of GCS service • crash(p) : process p crashes • recover(p) : process p recovers • send(p,m) : p sends message m • recv(p,m) : p receives message m • view_change(p,(id,members),T) : p receives message that new view is id, consisting of processes in members. T is the transitional set. November 19 2004 - NC state university

  10. Group address expansion Leave Group send Multicast Group membership Fail communication management Join Process group General Framework November 19 2004 - NC state university

  11. Membership service – Safety properties • Assumptions • All live process in a single group • No process leave or join the system • Membership changes when process crash/recover November 19 2004 - NC state university

  12. External actions of GCS November 19 2004 - NC state university

  13. Membership service • Ideal membership service • Practically impossible due to unreliable asynchronous network • Membership service • Monitors status of all processes and links • Keeps group members up to date through view_chg events • Each view labeled by value from a totally ordered set. • A process installs a view when it receives view_chg with that view November 19 2004 - NC state university

  14. Membership service – Basic properties • Self Inclusion • A process is a member of any view it installs • Local Monotonicity • The views that a process installs increase in time • Initial View Event • Every event at a process occurs in some view November 19 2004 - NC state university

  15. Partitionable Vs Primary Component Membership service • Partitionable • A membership service that allows multiple active groups • Primary component • A membership service that allows only one active group • The set of views installed by all the processes can be totally ordered • For consecutive views in the ordering, there must be a process in smaller view which installed the larger view. November 19 2004 - NC state university

  16. Partitionable GCS November 19 2004 - NC state university

  17. Multicast service – Safety properties • Basic properties • Delivery integrity • For every receive event, there is a preceding send event of the same message • No duplication • No message is received twice November 19 2004 - NC state university

  18. Multicast service – Safety properties • Sending view delivery • If a process receives a message in some view, then the message was sent in that view. • Same view delivery • All processes which receive some message receive it in the same view November 19 2004 - NC state university

  19. Multicast service – Safety properties • Sending view delivery • Minimizes the context information with each message. • Useful for applications for which message received in the same view is important • Limitation • GCS sometimes blocks view changes when messages from the old view are delivered – to avoid this we use same view delivery which don’t care what view a message was sent in November 19 2004 - NC state university

  20. Multicast service – Safety properties • Virtual Synchrony • If two processes in a view V install the same new view, then the processes receive the same messages in V • This property avoids state transfers for a view change in some applications • Since these two processes received the same messages in the previous view, state transfer is not required between them in the new view November 19 2004 - NC state university

  21. Virtual Synchrony • Group members all see events in same order • Events: messages, process crash/join • Powerful abstraction for replication • Framework for fault tolerance, high availability November 19 2004 - NC state university

  22. Ordering and reliability properties • FIFO delivery • If a process sends two messages, then every process that receives both messages receives them in the order they were send. • Reliable FIFO • If a process sends two messages, then any process that receives the latter messages receives the earlier messages first. November 19 2004 - NC state university

  23. Ordering and reliability properties • Causal delivery • If a message m causally precedes m’, then every process that receives both messages receives m before m’ • Reliable causal • If a message m causally precedes m’, and both are send in the same view, then any process that receives m’ receives m earlier November 19 2004 - NC state university

  24. Totally ordered multicast • 3 types • Strong total order • Ensures that messages are delivered in the same order at all the process • Weak total order • For every pair of view V and V’, there is a total order f on the messages so that every process that installs V in V’ receives messages in V’ in an order consistent with f. • Reliable total order • There is a total order f on the messages such that if m and m’ are two messages sent in the same view and m precedes m’ in f , then any process that receives m’ receives m earlier November 19 2004 - NC state university

  25. Liveness • Stable component • Set of processes that are alive and connected to each other and link from any process in this set to any process outside is down • Perfect failure detector • If it reports to any stable component S that their reachable set is S November 19 2004 - NC state university

  26. Liveness • For every process p in stable component S, there exists a view V such that we have – • Membership precision • P installs V as its last view • Multicast Liveness • Every message p sends in V is received by every process in S November 19 2004 - NC state university

  27. Thank You Q ? November 19 2004 - NC state university

More Related