For protocols to be stacked in any order, it is necessary that all protocol implementations use and supply the same interface. The Horus Common Protocol Interface (HCPI) is designed to be rich enough to support the features of most protocols, and has support for optional extensions. HCPI consists of a set of downcalls and upcalls. The interface provides for multicasting messages, installing views, and reporting error conditions. The HCPI is designed for multiprocessing, and is asynchronous and reentrant. See Tables 1 and 2 for a complete list of upcalls and downcalls. The HCPI allows users considerable flexibility in stacking the layers. Of course, certain protocol layers require that other layers be stacked above or below them, as described in Section 6.
: Horus downcalls
: Horus upcalls
When creating an endpoint, a process describes, at run-time, what stack of protocols it needs, and a base endpoint to build it on. A process is allowed to put multiple endpoints on a single base endpoint. This way, a tree or cactus stack of protocols can be built. Given an endpoint and a group address, a process can join a group of endpoints. Eventually, this results in a VIEW upcall which describes the set of endpoints the process can communicate with. In case a membership layer is part of the stack, every endpoint in the view is guaranteed to have been sent the same view.
Using the cast and send interfaces, messages may be broadcast to the view of the group, or to a subset of the view. In case of endpoints joining or crashing, a view needs to be flushed (see next section). This proceeds in different ways for different layers.
