
			 Interesting Problems
			 --------------------


- When a new members joins a group, rather than all existing members
  having to re-initialize their protocol stacks, have the coordinator
  send his whole protocol stack over to use before beginning to
  communicate. With such a mechanism in place, we could also
  dynamically change a protocol stack: one member would just create a
  new protocol stack, and send it to all other members in a multicast.

- Certain messages (such as member changes) have to be received by
  more than just a single layer (e.g. membership) in a protocol
  stack. For example, membership messages should be received also by a
  failure detection layer. Instead of querying the membership layer
  every time, the latter (as it is usually below the membership layer)
  could peek into the message and extract its information. In
  Horus/Ensemble, this is solved by adding two methods
  (e.g. upViewChange(), dnViewChange() to the protocol layer
  interface. All layers interested in the information must implement
  the two methods. However, this leads to a number of methods per
  interface should be avoided. 

  One solution is that each message has a type (e.g. 4 for membership
  changes, 2 for failure detection), which is unique. Every layer
  registers with a building block (TBD) which types it is interested
  in. When the building block receives a message that matches one of
  the registered types, the layer receives the message.

- Recursive calls: when a request is serviced by a server object and
  the object multicasts a request to all members (including itself),
  that request will be blocked at itself until the first call
  returns. But this never happens since the first request waits for a
  response from the second which is blocked waiting for the first: a
  typical deadlock situation exists.

  Typical ORBs encounter this situation too. They usually solve the
  problem by assigning multiple threads to service incoming
  requests. In a virtual synchrony setting, however, this cannot be
  done as messages have to be delivered in order. In the multithreaded
  ORB case above, request B would be serviced and return before A
  return, thereby reversing the order of the 2 messages (which is not
  important in that case, but it may be for virtual synchrony applications).

