1. November 19 2004 - NC state university Group Communication Specifications Gregory V Chockler, Idit Keidar, Roman Vitenberg Presented by – Jyothish S Varma

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

3. November 19 2004 - NC state university 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.

4. November 19 2004 - NC state university 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

5. November 19 2004 - NC state university 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

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

7. November 19 2004 - NC state university 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 G Send(G)

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

9. November 19 2004 - NC state university 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.

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

11. November 19 2004 - NC state university 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

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

13. November 19 2004 - NC state university 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

14. November 19 2004 - NC state university 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

15. November 19 2004 - NC state university 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.

16. November 19 2004 - NC state university Partitionable GCS

17. November 19 2004 - NC state university 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

18. November 19 2004 - NC state university 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

19. November 19 2004 - NC state university 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

20. November 19 2004 - NC state university 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

21. November 19 2004 - NC state university 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

22. November 19 2004 - NC state university 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.

23. November 19 2004 - NC state university 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

24. November 19 2004 - NC state university 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

25. November 19 2004 - NC state university 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

26. November 19 2004 - NC state university 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

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