A One Message Join Protocol - Best case
Original Publication Date: 2002-Jul-01
Included in the Prior Art Database: 2003-Jun-18
A One Message Join Protocol Best case Problem: The basic utilities provided by a Group Communication System (GCS) include joining and leaving groups. Both utilities start a membership change protocol within a group, that is executed by the GCS. The protocol ends with a membership change message delivered to the client, informing it of the current membership of the group. Henceforth we discuss the join protocol. There are several approaches to the join protocol. Some systems let the joining client first create a singleton group (consisting of itself only), regardless of whether other group members already exists; In case other members exist we say that the group is partitioned into several group partitions. After a singleton group is created, the GCS invokes a merge to combine the singleton group with other possibly existing group partitions. Notice that using this approach, it is possible that for a (brief) period of time several group partitions exist concurrently, although they are connected by the underlying network. This approach is taken by systems like Transis, Ensemble, Maestro, etc. The approach is problematic when the GCS is part of a cluster environment: having several group partitions damages the single system image guaranteed by the cluster. Other GCSs run a join protocol consisting of several messages, in order to avoid the creation of group partitions. This approach it taken by IBM Phoenix, for example, that has a join protocol consisting of at least two messages sent in the network to all the participating nodes. Solution: We suggest a join protocol that supports a single system image required in cluster environments. The protocol's best case behavior consists of one phase, i.e., one message send and receive in the network. Narrow Claims: Our GCS supports a join protocol that requires one message in the best case.