Browse Prior Art Database

A One Message Join Protocol - Best case

IP.com Disclosure Number: IPCOM000013515D
Original Publication Date: 2002-Jul-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 3 page(s) / 44K

Publishing Venue

IBM

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

Page 1 of 3

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.

     Embodiment: The architecture consists of a set of nodes participating in the GCS, each containing a GCS daemon. The GCS daemons are all members of the same group, capable of communicating via reliable and totally ordered messages. The daemons group provides, among other things, group membership services to the GCS clients. Upon joining or leaving, a GCS client sends a totally ordered reliable message to the GCS daemons. Daemons that share the same node with members of the group execute a membership change protocol on behalf of the group members. The protocol terminates with a VIEW message sent by exactly one of the daemons, that defines the new membership of the group. This message is delivered to all the group members.

     The Global Group Table: The one message join protocol relies on a global group table (GGT), a replicated table maintained by each GCS daemon. The GGT contains an entry for each group having members on one of the GCS nodes. Each entry contains the group name, and the nodes on which its members reside. The GGT is updated by a GCS daemon upon receiving a client join message or a daemon VIEW...