Post on 17-Jan-2016
transcript
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 ?