ken@gvax.cs.cornell.edu (Ken Birman) (03/07/91)
A few people have come up with algorithms in which processes dynamically vary their relationship with a group, i.e. calling pg_client as a member, or pg_join as a client, or pg_leave as either a client or a member, or pg_delete as a member. Some people would also like to have a non-member of a group call pg_subgroup (and add/delete members), i.e. in an application with a "group manager" that might manage groups on behalf of other processes. In ISISV2.1 we didn't anticipate these sorts of sequences. Some of them won't work at all, such as switching from being a member to being a client; others work but aren't documented (like calling pg_subgroup when you don't belong to the group being created), and others "usually work", like calling pg_leave in BYPASS mode. In general, V2.1 groups are not supposed to be used in an extremely dynamic manner (i.e. membership is not supposed to change frequently with respect to the frequency of communication events). In ISISV3.0 we support the full range of possibilities, and also guarantee that if a current member becomes a client, or a current client becomes a member, no diffusion multicasts will fail to get through. We have also extended the groupview data structure to include an "event" descriptor that indicates what caused the new view to become defined, and to list the client that joined/departed if this happened. V3.0 thus supports much more dynamic use of groups. However, we still view changes to group membership as fairly heavyweight operations. Our ISIS redesign will include support for external group managers. Moreover, our new system (18 months away) will support much cheaper membership change protocols, and changing the membership of a group will not cost much more than multicasting to it. Details appear in the recent technical report on "lightweight causal and atomic multicast". However, we don't expect to be able to support these cheap protocols in V3.0, so people who want to have zillions of groups that change membership very frequently will need to wait until mid 1992... but, we are getting there. Ken Birman