CSE 480 Lecture Notes
February 13, 1996

Group Communication

one-to-many vs point-to-point
groups are dynamic -- need to manage group membership

implementation
1) multicasting -- delievered to selected machine
2) broadcasting -- delievered to all machines
3) unicasting

-----
Design Issues

+ Closed Groups vs Open Groups (Fig. 2-31)

who can communicate with a group, i.e.,
whether or not an outsider can send msgs to a group

closed group: a parallel chess program
open group: a client sends a request to replicated servers

+ Peer Groups vs Hierarchical Groups (Fig. 2-32)

internal structure of a group
decision by boss (i.e., coordinator) vs by all members

advantages and disadvantages
- no single point of failure
- decision making is more complicated
- loss of the coordinator bring the entire group to halt

+ Group Membership
creation and deletion of groups
joining and leaving of a group

+ Group Addressing (Fig. 2-33)

mutlicast, broadcast, unicast

+ Send and Receive Primitives

RPC -- the caller needs to deal with n replies
group send and group receive

+ Atomicity (or Atomic Broadcast)

all-or-nothing property, i.e., a message sent to a group is received
by all members or by none of them.

Why?  It makes easy to program distributed applications.

Issues in implementation:
1) if no failure, easy to implement using ack
2) if a sender fails before receiving all acks, some may not
have received the msg.  Those who have not received the msg
do not know that they have not received the msg. 

How to implement?  One algorithm is as follows:
1) sender sends the msg to every process (using timeout and retransmission)
2) if a proccess receives a msg for the first time, it forward to
all other processes (again using timeout and retransmission).

Property: No matter how many processes crash and how many msgs lost,
all surviving processes will eventually receive the msg.

+ Message Ordering

Every process sees the messages in the same order.
Problem (Fig. 2-34)

global time ordering -- 
If all messages are delivered instantaneously in the order they are sent,
then every proccess sees the messages in the same order.

consistent time ordering -- if two msgs, A and B, are sent close together,
the system picks one of them being first and delivers to all group members
followed by the other.  Messages are guaranteed to delivered to all group 
members in the same order, but that order may not be the real order in 
which they were sent.

causality order -- only the causal relation is preserved.

+ Overlapping Groups

a group can be a member of multiple groups
problem (Fig. 2-35)

+ Scalibility

members per group -- tens, thousands

presene of gateways -- duplicate detection

-----
Group Communication in ISIS

Fig. 2-37 (three types of synchronous system)
1) synchronous system -- events happen strictly sequentially
with each event (e.g., broadcast) taking zero time to complete.
2) loosely synchronous system -- events take a finite amout of time,
but all events appear in the same order to all parties.
3) virtually synchronous system -- the ordering constraint is relaxed
such a way that it does not matter under given circumstances.

causally related --
two events are said to be causally related if the behavior of the second
could have been influenced by the occurrence of the first one.

concurrent --
two events are said to be concurrent if they are unrelated.
e.g., A sends a msg to B and C sends a msg to D at the same time.

Communication Primitives in ISIS
1) ABCAST -- loosely synchronous, based on two phase commit protocol
2) CBCAST -- ordered delivery between causally related msgs
3) GBCAST	-- similar to ABCAST and used for managing group membership

ABCAST
 sender
   send (M,timestamp)
   receive (Yes,time_i)
   send (Commit, max(time_i))

 receiver_i
   recv (M, timestamp)
   /*  time_i is later than any timestamp used locally */
   send (Yes, time_i)  
   recv (Commit, timestamp)
   /* deliver mssages to application in the order of the timestamps */

Property: All messages are delivered to all processes in the same order.
1) Observation: every commit msg has a unique timestamp
2) Question: how do we know that commit msgs arrive in order to a receiver?
Do not deliver any committed msg if there is an outstanding Yes msg
whose timestamp is later than the timestamp of the commit msg.

CBCAST (Fig. 2-38)