On communication support for fault tolerant process groups
RFC - Unknown
(November 1986; No errata)
||RFC Editor Note
RFC 992 (Unknown)
||Send notices to
K. P. Birman (Cornell)
Network Working Group T. A. Joseph (Cornell)
Request for Comments: 992 November 1986
On Communication Support for Fault Tolerant Process Groups
K. P. Birman and T. A. Joseph
Dept. of Computer Science, Cornell University
Ithaca, N.Y. 14853
1. Status of this Memo.
This memo describes a collection of multicast communication primi-
tives integrated with a mechanism for handling process failure and
recovery. These primitives facilitate the implementation of fault-
tolerant process groups, which can be used to provide distributed
services in an environment subject to non-malicious crash failures.
Unlike other process group approaches, such as Cheriton's "host
groups" (RFC's 966, 988, [Cheriton]), our approach provides powerful
guarantees about the behavior of the communication subsystem when
process group membership is changing dynamically, for example due to
process or site failures, recoveries, or migration of a process from
one site to another. Our approach also addresses delivery ordering
issues that arise when multiple clients communicate with a process
group concurrently, or a single client transmits multiple multicast
messages to a group without pausing to wait until each is received.
Moreover, the cost of the approach is low. An implementation is be-
ing undertaken at Cornell as part of the ISIS project.
Here, we argue that the form of "best effort" reliability provided by
host groups may not address the requirements of those researchers who
are building fault tolerant software. Our basic premise is that re-
liable handling of failures, recoveries, and dynamic process migra-
tion are important aspects of programming in distributed environ-
ments, and that communication support that provides unpredictable
behavior in the presence of such events places an unacceptable burden
of complexity on higher level application software. This complexity
does not arise when using the fault-tolerant process group alterna-
This memo summarizes our approach and briefly contrasts it with other
process group approaches. For a detailed discussion, together with
figures that clarify the details of the approach, readers are re-
ferred to the papers cited below.
Distribution of this memo is unlimited.
Birman & Joseph [Page 1]
RFC 992 November 1986
This memo was adopted from a paper presented at the Asilomar workshop
on fault-tolerant distributed computing, March 1986, and summarizes
material from a technical report that was issued by Cornell Universi-
ty, Dept. of Computer Science, in August 1985, which will appear in
ACM Transactions on Computer Systems in February 1987 [Birman-b].
Copies of these paper, and other relevant papers, are available on
request from the author: Dept. of Computer Science, Cornell Universi-
ty, Ithaca, New York 14853. (email@example.com). The ISIS
project also maintains a mailing list. To be added to this list,
contact M. Schmizzi (firstname.lastname@example.org).
This work was supported by the Defense Advanced Research Projects
Agency (DoD) under ARPA order 5378, Contract MDA903-85-C-0124, and by
the National Science Foundation under grant DCR-8412582. The views,
opinions and findings contained in this report are those of the au-
thors and should not be construed as an official Department of De-
fense position, policy, or decision.
At Cornell, we recently completed a prototype of the ISIS system,
which transforms abstract type specifications into fault-tolerant
distributed implementations, while insulating users from the mechan-
isms by which fault-tolerance is achieved. This version of ISIS, re-
ported in [Birman-a], supports transactional resilient objects as a
basic programming abstraction. Our current work undertakes to pro-
vide a much broader range of fault-tolerant programming mechanisms,
including fault-tolerant distributed bulletin boards [Birman-c] and
fault-tolerant remote procedure calls on process groups [Birman-b].
The approach to communication that we report here arose as part of
this new version of the ISIS system.
Unreliable communication primitives, such as the multicast group com-
munication primitives proposed in RFC's 966 and 988 and in [Cheri-
ton], leave some uncertainty in the delivery status of a message when
failures and other exceptional events occur during communication.
Instead, a form of "best effort" delivery is provided, but with the
possibility that some member of a group of processes did not receive
Show full document text