

		    Retransmission of view changes
		    ==============================


Problem:
--------

When a new view has to be installed, the coordinator runs the FLUSH
protocol. This protocol re-broadcasts all pending messages to all
members and waits until all members have acked these messages (all of
them). Then a view change is sent (HandleViewChange()). This causes
all recipients (also the coordinator !) to reset their retransmission
tables.

Since the view change is sent using an ACK-based retransmission
scheme, any potential retransmission of the view change is
killed. This means that not all members may actually receive the view
! For example, in some cases, where a slow member P has not yet
received the view change, or when the view change message was dropped
on a lossy link, P might never receive the view change because the
coordinator stopped retransmission ! This is alo true for joining new
members, which may never receive the view change (which is the ack
that they have successfully joined the group) and keep retrying to
join.

Solution:
---------

So the solution is *not* to reset the ACK-sender retransmission table
*in the coordinator only*. All other members may reset it. The reason
is that (a) retransmission still takes place until all members have
received the new view and (b) it is only the coordinator who sends
ACK-based messages at this time (namely the view change), and nobody
else. A possible problem is that not resetting the retransmission
table may cause a large number of messages to be stored in it. This is
not the case, since the FLUSH protocol ensures that all ACK-messages
before the view change are transmitted to all receivers and therefore
removed from the table. So the view change message is effectively the
only message in the ACK-retransmission table !

The coordinator keeps re-sending the view change to those members from
which it hasn't yet received an ACK, until an ACK has been received,
or that member is suspected.

This solution is a cheap way of making sure that every non-faulty
member receives the view change message, without having to resort to
some two-phase commit protocol.
