| Summary: | This paper reports on the Horus project, which provides an unusually flexible group communication model to application-developers. This flexibility extends to system interfaces, the properties provided by a protocol stack, and even the configuration of Horus itself, which can run in user space, in a operating system kernel or microkernel, or be split between them. Horus is used through an interface proxy. Proxies can support toolkits that use groups explicitly, or hide groups beneath parallel programming back-ends (for example, the Panda subsystem of the Orca language [2], and IBM's PCODE subsystem for MPI). Finally, we have developed a proxy that intercepts certain classes of system calls and maps them into Horus operations, for example to provide security or fault-tolerance features transparently [3]. This proxy has also been used to embed Horus into Tcl/TK and Python, both popular prototyping languages. Different uses of groups create different requirements on the membership and communication functionality of the system. Some properties (like virtual synchrony) may impose undesirable overheads, or even be incompatible, with other properties (like real-time communication) . Moreover, the mechanisms required to implement a desired group communication property depend on the runtime environment. In an insecure environment, one might accept the overhead of data encryption, but wish to avoid this cost when running within a firewall.
|
|---|