November 19 2004 - NC state university

Group Communication Specifications

Gregory V Chockler, Idit Keidar, Roman Vitenberg

Presented by –

Jyothish S Varma

November 19 2004 - NC state university

Outline

Group communication – background Safety properties

Membership service Multicast service

Safe messages Ordering and reliability properties Liveness

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.

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

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

November 19 2004 - NC state university

Objectives of this paper

Formulate a comprehensive set of specifications

Combine representations of most existing GCS

Correlate terminology

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)

November 19 2004 - NC state university

Model

Asynchronous message passing network Allows partitions and merges View

Set of process that belongs to a group

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.

November 19 2004 - NC state university

General Framework

Join

Groupaddress

expansion

Multicastcommunication

Group

send

FailGroup membership

management

Leave

Process group

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

November 19 2004 - NC state university

External actions of GCS

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

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

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.

November 19 2004 - NC state university

Partitionable GCS

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

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

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

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

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

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.

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

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

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

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

November 19 2004 - NC state university

Thank You

Q ?