Welcome to the Hedera Project!

What is Hedera?

Hedera is an open-source framework designed to provide a uniform API to different group communication libraries. The currently available instance sits on top of JGroups∞ and Appia∞. It is also available a preliminary implementation that uses Spread∞. Hedera is the continuation of the Tribe∞ project.

Hedera is targeted at reliable group communication within clusters. In such environments, we expect group memberships to be relatively stable and group sizes to be moderate (at most a few hundreds). However, we expect a potentially large number of logical groups.

In the framework of the Sequoia∞ technology, group communication is needed to support replicated databases where the replicas are managed by different controllers.

For an overview of some of the concepts related to Hedera, look at Distributed Systems Concepts and Design∞ by G. Couloris, J. Dollimore and T.Kindberg, 2001. In particular section 11.4 about multicast communication and section 14.2 about group communication.

Architectural overview

Figure 1 gives an overview of group communication concepts as understood in Hedera. We consider two clients running on distributed nodes connected by a network. They need to exchange messages with certain ordering and reliability guarantees. Hence, each of them instantiates one adapter per needed communication mode. Each adapter relies on a group channel which in turn joins a single uniquely identified group. Group channel instances on both nodes exchange messages while providing the required guarantees.

Basic Abstractions

Distributed Virtual Database

This is a Sequoia abstraction corresponding to a database that is distributed (i.e. replicated) across several database backends managed by different controllers. Group communication is useful in this type of configuration.

Multicast Request Adapter

Defines an adapter which is similar to JGroups Message Dispatcher. It is a type of multicast RPC (Remote Procedure Call) where a message is multicast and each member returns a response. Several policies are available:

• WAIT_NONE: do not wait for any response before returning (asynchronous).
• WAIT_FIRST: wait for the first response before returning.
• WAIT_MAJORITY: wait for a majority of responses before returning.
• WAIT_ALL: wait for all responses before returning.

Push/Pull Adapter

It allows a client to be notified when messages are received instead of having to actively poll the channel for new messages.

Reliable Group Channel

This is the abstraction used by the client application. A channel is associated with a single group at any given time. It provides different message delivery guarantees such as reliability, FIFO ordering or total ordering, depending on the channel type.

Group Membership Service

GMS offers a way to retrieve members of a group, add and remove members from a group. The GMS can take advantage of two optional services: a Discovery Service and a Fault Detector.

Fault Detector

It is used to update the group composition. In case of a suspected failure of a current member, it can be removed from the group. Without such a service, the GMS only shows the group composition updated by programmatic (voluntary) calls to the join and quit primitives.

Discovery Service

It is responsible for finding other group members when a new member wants to join a group. Without such a service, the GMS would have to be provided the IP addresses, in a configuration file, of all potential group members as it would not be able to determine them dynamically.