Group Communication Specifications Gregory V Chockler Idit Keidar

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

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

What is Group Communication? n What is a group? q n 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

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

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

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

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

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

General Framework n Signature of GCS service q q q 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

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

Membership service – Safety properties n Assumptions q q q 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

External actions of GCS November 19 2004 - NC state university

Membership service n Ideal membership service q n Practically impossible due to unreliable asynchronous network Membership service q q 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

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

Partitionable Vs Primary Component Membership service n Partitionable q n A membership service that allows multiple active groups Primary component q q q 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

Partitionable GCS November 19 2004 - NC state university

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

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

Multicast service – Safety properties n Sending view delivery q q q Minimizes the context information with each message. Useful for applications for which message received in the same view is important Limitation n 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

Multicast service – Safety properties n Virtual Synchrony q If two processes in a view V install the same new view, then the processes receive the same messages in V n This property avoids state transfers for a view change in some applications q 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

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

Ordering and reliability properties n FIFO delivery q n If a process sends two messages, then every process that receives both messages receives them in the order they were send. Reliable FIFO q 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

Ordering and reliability properties n Causal delivery q n If a message m causally precedes m’, then every process that receives both messages receives m before m’ Reliable causal q 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

Totally ordered multicast n 3 types q Strong total order n q Weak total order n q Ensures that messages are delivered in the same order at all the process 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 n 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

Liveness n Stable component q n 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 q If it reports to any stable component S that their reachable set is S November 19 2004 - NC state university

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

Thank You Q? November 19 2004 - NC state university