Horus: A Flexible Group Communications System

Notes by Teck Chia, 4/15/98

Horus in a nutshell

• a group communication system to support the process group paradigm for fault-tolerance.
• provides a set of protocols, among them the most fundamental ones are for ordered multicasts and group membership.
• Horus can be used in two ways : 1) as a toolkit, which applications will use explicitly. 2) fitted into some system (eg. Tcl/Tk) so that functionality is transparent to the application. And Horus can be run in user space, in the kernel or somewhere in between.
• Horus supports the virtually synchronous execution model.

Key Distinguishing Features

• Flexibility in use and in configuration.
• Horus is flexible for the user because he/she can choose to use it as a toolkit or retrofit existing systems so that applications are hardened with fault-tolerance.
• Horus is flexible in configuration because protocols are implemented as microprotocols which has standardized top and bottom interfaces that enable them to be stacked together to get a macroprotocol.
• Protocols can be configured at initialization time or during run-time.
• Each protocol stack interacts with three types of objects : 1) endpoints, representing a communicating entity. 2) group object which maintains group address and membership views. 3) message object.
• The Horus Common Protocol Interface (HCPI) is a set of interfaces for common operations like sending and receiving messages, group membership and events reporting (upcalls).

Example Uses

• Tcl/Tk with Horus : Horus acts as an intercept proxy for system calls issued by Tcl. Also, tcl is extended with two functions that create endpoint and group objects.
• Electra, a CORBA compliant ORB that uses Horus to manage groups of objects.

Performance

• Ordered multicast adds significant overheads.
• Hardware multicast helps, especially when the number of members increasing.

Discussion

• Horus claims to be flexible in that it can be implemented anywhere from in the kernel to user level. Which level really makes sense for a system like Horus ?
• Runtime reconfiguration : Is it really useful ? Is the additional complexity that user applications have to deal with justified with better performance ? Is detecting events that trigger reconfiguration something that can be done correctly and easily ?