The Horus system is fully operational, although we are continuing to extend it with new kinds of protocol stacks. The current system can be accessed through a variety of user-level interfaces. In addition to the HCPI, Horus can present a process group through a standard UNIX sockets interface (e.g. a UNIX sendto operation will be mapped to a multicast, and a recvfrom will receive the next incoming message). A similar approach could be used to hide Horus beneath a file system interface, much as in the operating system called Plan/9. Horus has also been embedded into object oriented languages, such as ORCA and the Electra version of C++.
Horus stacks exist to support the virtual synchrony model, as well as weaker, less ordered, or less reliable communication models. Horus can thus emulate our older Isis Toolkit, but can also be presented through interfaces matching those of the Hebrew University's Transis system. Very lightweight protocol stacks permit Horus users to obtain the performance of an ATM network with almost no overhead at all. A security architecture for Horus provides for authentication and encryption of messages, using a novel approach that combines security features with fault-tolerance. Looking to the future, we will be adding protocol layers to support guarantees of throughput and low latency, which require resource allocation and scheduling mechanisms within the system. Coordination of behaviors between stacks, in systems that use several stacks simultaneously, has emerged as a topic for future study.
Finally, as noted earlier, the Horus architecture promotes the decomposition of protocols into independent layered modules with clear structure and standard interfaces. For example, in the past, our work on Isis was clouded by an architecture in which protocols for group communication were ``mixed'' with protocols for membership agreement. In Horus, the system membership service is supported as a layer which uses potentially inaccurate failure suspicions as well as member join (actually, view merge) and leave events to create the abstraction of a fail-stop environment.
Thus, the membership layer sees two kinds of inputs: inaccurate failure and merge events. Its output are failure and merge events that have been filtered by a membership appropriate agreement protocol-a dynamically sequenced uniform agreement in our case, although other protocols could also be used here. A protocol operating over this layer will also see merge and leave input events, but these membership change events will be indistinguishable from fail-stop events. Such an approach is not just easier to implement or extend, but also to understand and reason about. The modular framework thus encourages a theoretical perspective in which it can be made precise what the semantics of a composed set of protocols and a failure detector are, layer by layer.
This leads to another major challenge for future work. Notice that the membership services discussed above each implement a complex protocol that converts merge and failure events with weak semantics to merge and failure events with much stronger (simpler) semantics. This process of filtering a complex environment to create a simpler one is not what one would intuitively expect from the composition of protocol layers. After all, composition should in the general case yield layers with semantics much more complex than those of any of the constituent layers. We believe that the issue of how composition leads to simplicity, in a formal sense, emerges as an extremely interesting opportunity for future study. We would argue that, in showing how complex protocols can be simplified using modular techniques, Horus takes a very positive step in the desired direction.