Group communication

Powell, David

doi:10.1145/227210.227225

Cited by 128 publications

(51 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…a portion of the overall computation of a system supporting dynamic groups in which join events may only appear at the beginning of the sub-run. Consider the computation depicted in Figure 3: it can be decomposed in three static sub-runs, namely sr 1 , sr 2 , sr 3 . A sub-run can be described with events and process histories as those introduced in Section 2.1, i.e.…”

Section: Static Vs Dynamic Group Communicationsmentioning

confidence: 99%

“…To achieve this, in this paper we first present six existing TO specifications organized into a hierarchy, and then we identify how specifications differ in terms of the possible behavior of faulty processes. Then, we classify into the hierarchy both fixed sequencer and privilege-based TO protocols given in the context of primary component group communications [2,3], by also pointing out real systems implementing these primitives. These are the results of a formal analysis available in a companion paper [4].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Total Order Communications: A Practical Analysis

Baldoni

Cimmino

Marchetti

2005

Dependable Computing - EDCC 5

View full text Add to dashboard Cite

Abstract. Total Order (TO) broadcast is a widely used communication abstraction that has been deeply investigated during the last decade. As such, the amount of relevant works may leave practitioners wondering how to select the TO implementation that best fits the requirements of their applications. Different implementations are indeed available, each providing distinct safety guarantees and performance. These aspects must be considered together in order to build a correct and sufficiently performing application. To this end, this paper analyzes six TO implementations embedded in three freely-distributed group communication systems, namely Ensemble, Spread and JavaGroups. Implementations are first classified according to the enforced specifications, which is given using a framework for specification tailored to total order communications. Then, implementations are compared under the performance viewpoint in a simple yet meaningful deployment scenario. In our opinion, this structured information should assist practitioners (i) in deeply understanding the ways in which implementations may differ (specifications, performance) and (ii) in quickly relating a set of total order algorithms to their specifications, implementations and performance.

show abstract

Section: Static Vs Dynamic Group Communicationsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Total Order Communications: A Practical Analysis

Baldoni

Cimmino

Marchetti

2005

Dependable Computing - EDCC 5

View full text Add to dashboard Cite

show abstract

“…The Isis system extended the group model of the V system by providing support for fault-tolerance through mechanisms such as process group membership and reliable totally ordered multicast [2]. Inspired by Isis, several group communication systems such as Transis, Totem, and Horus [9] have more recently been developed. These systems mainly differ in the way messages are ordered (e.g., total order/causal order) and in the way atomicity of message delivery is ensured in the case of process or link failures.…”

Section: Related Work: From Process Groups To Corba Object Groupsmentioning

confidence: 99%

“…Unlike in the integration approach, the ORB is not aware of the existence of group mechanisms. Eternal [1] uses this mechanism: the Eternal Interceptor captures IIOP messages and the Eternal Replication Manager maps them onto the Totem multicast group communication system [9]. Eternal intercepts system calls before they reach the kernel, by performing a low level continual trace of inter-process communications.…”

Section: Related Work: From Process Groups To Corba Object Groupsmentioning

confidence: 99%

Programming with object groups in CORBA

Felber

Guerraoui²

2000

IEEE Concurrency

View full text Add to dashboard Cite

The Object Group Service (OGS) extends CORBA with the ability to gather several objects inside a group and to transparently handle the group membership and the consistent invocations of the group members. OGS does not require any change to the CORBA specification: it is portable on any CORBA 2.0 ORB and does not rely on ORB vendorspecific features. We present the OGS programming model and we discuss various levels of group transparency and their impact on invocation overheads.

show abstract

“…There are two major systems: (a) subject-based, and (b) content-based. In subject-based subscription an event is classified and labeled by the publisher as belonging to one of a fixed set of groups (or channels) [2,17]. Here, each item is referred to by only one attribute (an id or a name).…”

Section: Related Work and Contributionmentioning

confidence: 99%