The Horus system [7] provides a framework for designing and building complex distributed systems. Horus follows the group-communication model, in which sets of processes can be grouped into managed entities. Processes may belong to multiple groups, which they can join and leave dynamically. Horus supports multiple ``flavors'' of process groups by composing different communication protocols, including the virtually synchronous groups on which Isis was based.
Each protocol is a separate module that follows some strict rules. These modules use, and supply, the same interface, called the Horus Common Protocol Interface [7]. This interface contains downcalls for sending messages, and upcalls for delivering messages and new memberships. The interface for each module is accessed through a dispatch table, so that there are no naming conflicts. This discipline allows the protocol modules to be stacked on top of each other like Lego.9extm blocks (see Figure 1). An application may use multiple stacks, each providing a different semantics suited for a particular aspect of that application.
: Layers can be stacked at run-time like
Lego.9extm blocks.
Horus has a library with protocols for flow-control, membership and failure detection, ordering, security, and other features. New protocols can be added dynamically. Each protocol is optional, and the basic group provides no communication guarantees. When using multiple protocols, Horus will pack the messages of the different protocols together, optimizing the number of packets that actually travel on the networks. All message packing and passing within a process is done by pointer manipulation for optimal efficiency.
Each group in Horus can run over a different data-link protocol, and Horus currently includes drivers for UDP, IP (both with the Deering hardware multicast extensions), a variety of ATM adaption layers and interfaces, and shared memory. Horus has been ported to UNIX BSD and SVR4 systems, the Lynx real-time operating system, and the Chorus micro-kernel.
Horus provides prioritized threads and prioritized communication. Work is underway to add rigorous resource reservation throughout the Horus system, allowing for increased predictability. All resources in Horus are managed by a credit or contract scheme, allowing for resource independent schedulers that can implement a variety of policies.
The Horus architecture gives the application designer full control over the composition of the communication subsystems, and multiple subsystems can be active concurrently within a single application. This flexibility intends to support all the distribution needs of the application. The failure detection, security, and membership protocols are necessary for the control of the distributed application (e.g., floor and participant control), while flow-control is necessary for timely, predictable data dissemination.
Horus supports an extensive set of user-level interfaces. For multi-media applications, the TCL/TK [3] and Python interfaces to Horus are especially valuable. These combine the advanced distributed control from Horus with powerful GUI development tools.
