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

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