New view handling
=================

Author: Bela Ban
Version: $Id: ViewHandling.txt,v 1.4 2005/10/10 11:45:40 belaban Exp $

Problem:
Merge, join and leave requests need to handled in the order in which they arrive. Currently,
the merge handling is independent from the view handling, which results in problems with generating
merge VIDs which are lower than the highest VIDs generated by the view handling, as described
in MergeProblem.txt.

Proposed solution:
- Turn the ViewBroadcaster into a ViewHandler which has a queue
- JOIN, LEAVE and MERGE requests received by the coordinator simply add an entry to the queue
- A thread dequeues elements from that queue and processes them, one at a time, to ensure FIFO handling
  of those requests
  --> One result of this is that the merge handling is now *not* done asynchronously anymore !
- A side effect of this is that we could implement a feature which waits for N JOIN/LEAVE requests or M milliseconds,
  and then processes a number of JOIN and LEAVE requests as *one* view, which is more efficient, given the fact that
  views are transmitted reliable, ie. for each view we need to receive an ack from each member
- When the coordinator itself leave, we need to flush the queue, ie. not accept new requests, and complete the
  existing requests

Merging:
- When we receive a MERGE event, the merge coordinator needs to inform all coordinators involved to flush their queues
  in the ViewHandler.
- This processes all requests in the queue, then simply discards new requests (or queues them in
  a separate queue). We could also simply discard all current requests in the queue, since for example a JOIN
  request will redirect its JOIN-REQ to a new coordinator until successful.
- When the merge has successfully run (or aborted), all the queues in the ViewHandlers need to resume
- The reason for doing this is that the MergeView's VID needs to be higher than any view seen by any of the
  coordinators participating in the merge. If a coordinator was allowed to continue generating new views, then
  this would not be the case


Implementation
--------------

- LEAVE of coordinator:
  - Add LEAVE request to queue
  - Stop (=flush) queue. Wait until all requests have been processed, then leave

- LEAVE of regular member P:
  - Add LEAVE request to queue:
    - Compute new view V (excluding P)
    - Multicast V to all members of V, wait for VIEW_ACKs

- JOIN(P):
  - Add JOIN request to queue
    - Compute new view V including P
    - Multicast V to all members of V *excluding* P
      (this is necessary because we won't receive a VIEW_ACK from P, so we would block)
    - Send unicast JoinRsp to P

- SUSPECT(P):
  - Add SUSPECT request to queue
  - Same as LEAVE handling

- STOP of coordinator:
  - Stop (=flush) and close queue. Wait until all requests have been processed, then leave
  - This is probably superfluous (already done by LEAVE(coord)), but double-check

- MERGE: