A. Schiper and A. Ricciardi, "Virtually-synchronous communication based on a weak failure suspector," in Proceedings of the 23rd International Symposium on Fault-Tolerant Computing (FTCS-23), Toulouse, France, 1993, pp. 534--543.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to the group members whenever it changes. Group communication systems usually run in asynchronous fault prone environments. In such environments, group communication systems generally provide some variant of virtual synchrony semantics (for examples, please see [MAMSA94, FvR95, VKCD01, SR93, KK00] which synchronize membership notifications with regular messages and thus simulate a benign world in which message delivery is reliable within the set of connected processes. The key aspect of virtual synchrony is the semantics of interleaving of message send and delivery events with ....

....at a process p in the membership m if m was the last membership notification delivered to process p before e, or a default initial membership if no such notification was delivered. A key property specified by nearly all variants of virtual synchrony (some examples are [MAMSA94, FvR95, VKCD01, SR93, BDM98, KK00] is that processes moving together from a membership m to another membership m deliver the same messages in m. 2.4.2 Using multicast groups in the VoD service Our service creates the following three kinds of multicast groups, as shown in Figure 2.2: Service group consists of ....

A. Schiper and A.M. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Computing Symposium (FTCS), pages 534--543, June 1993.

....each node. Experiments using an implementation in the Horus system show that significant performance improvements can be achieved with this approach. Key Words: virtual synchrony, scalability, dynamic environment, performance evaluation 1. INTRODUCTION Virtually synchronous group communication [4, 6, 25] is a powerful paradigm for developing distributed applications. This paradigm allows processes to be organized in groups within which messages are exchanged to achieve a common goal. Virtual synchrony ensures that all processes in the group receive consistent information about the group ....

....(g) to a given group member, every other member that receives both views, receives them in the same order. Additionally, message delivery is ordered with regard to group view delivery: two processes that receive V (g) and V (g) receive exactly the same set of messages between these two views [25]. Thus, view delivery serves as a synchronization point for group members. The previous informal definition does not enforce any ordering between messages delivered in the same view. However, in this paper, we further assume that the virtually synchronous layer delivers messages according to ....

A. Schiper and A. Ricciardi. Virtually-synchronous communication based on a weak failure suspector. In Digest of Papers, The 23th International Symposium on Fault-Tolerant Computing, pages 534--543, Toulouse, France, June 1993.

....mappings can be established in an automated manner, using heuristics applied locally at each node. Experiments using an implementation in the Horus system show that significant performance improvements can be achieved with this approach. 1 Introduction Virtually synchronous group communication [2, 3, 9] has proven to be a powerful paradigm for developing distributed applications. This paradigm allows processes to be organized in groups within which messages are exchanged to achieve a common goal. Virtual synchrony ensures that all processes in the group receive consistent information about the ....

A. Schiper and A. Ricciardi. Virtually-synchronous communicationbased on a weak failure suspector. In Digest of Papers, The 23th International Symposium on Fault-Tolerant Computing, pages 534-- 543, Toulouse, France, June 1993.

....approaches. As a test case, the new protocols were implemented in the Horus system, although the underlying principles can be applied to other architectures as well. The paper also presents performance results from this implementation. 1 Introduction Virtually synchronous group communication [1, 2, 13] has proven to be a powerful paradigm for developing distributed applications. This paradigm allows processes to be organized in groups within which they exchange messages in order to achieve a common goal. Virtual synchrony ensures that all processes in the group receive consistent information ....

....synchrony provides each process group membership information in the form of views and guarantees that all processes that install a given view have delivered the same set of messages from the previous view. More formally, virtually synchronous multicast communication can be defined as follows [13]: vs multicast: Consider a set of processes g, a view V (g) and a message m multicast to the members of group V (g) If 9p 2 V (g) which has delivered m in view V (g) and has installed view V (g) then every process q 2 V (g) which has installed V (g) has delivered m before ....

A. Schiper and A. Ricciardi. Virtually-synchronous communication based on a weak failure suspector. In Digest of Papers, The 23th International Symposium on FaultTolerant Computing, pages 534--543, Toulouse, France, June 1993. IEEE.

....Virtual Synchrony semantics specifies how message deliveries are synchronized with view deliveries. This synchronization is done in a way that simulates a benign world in which message delivery is reliable within each view. Many variants of Virtual Synchrony have been suggested (for example, [38, 23, 16, 12, 40, 9]) Nearly all of them include a key property, called Virtually Synchronous Delivery, which guarantees that processes that receive the same pair of views from the GCS receive the same sets of messages in between receiving the views. Henceforth, when we refer to Virtual Synchrony, we assume the ....

....view are, the algorithm has to tolerate transient inconsistent views and cascading connectivity changes. In particular, a Virtual Synchrony algorithm needs to know which synchronization messages sent by di#erent processes pertain to the same view formation attempt. Existing algorithms, such as [23, 3, 40, 9, 26, 5], identify such synchronization messages by tagging them with a common identifier. Some initial communication is performed first, before synchronization messages are communicated, in order to agree upon a common identifier and to distribute it to the members of the forming view. While a view is ....

[Article contains additional citation context not shown here]

A. Schiper and A. Ricciardi, Virtually synchronous communication based on a weak failure suspector, in 23rd IEEE Fault-Tolerant Computing Symposium (FTCS), June 1993, pp. 534--543.

....semantics as a VS algorithm. VS semantics specifies how message deliveries are synchronized with view deliveries. This synchronization is done in a way that simulates a benign world in which message delivery is reliable within each view. Many variants of VS have been suggested (for example, [38, 23, 16, 12, 40, 9]) Nearly all of them include a key property, called virtually synchronous delivery, which guarantees that processes that receive the same pair of views from the GCS receive the same sets of messages in between receiving the views. Henceforth, when we refer to VS, we assume the semantics includes ....

....of the new view are, the algorithm has to tolerate transient inconsistent views and cascading connectivity changes. In particular, a VS algorithm needs to know which synchronization messages sent by di#erent processes pertain to the same view formation attempt. Existing algorithms, such as [23, 3, 40, 9, 26, 5], identify such synchronization messages by tagging them with a common identifier. Some initial communication is performed first, before synchronization messages are communicated, in order to agree upon a common identifier and to distribute it to the members of the forming view. While a view is ....

[Article contains additional citation context not shown here]

A. Schiper and A. Ricciardi, Virtually synchronous communication based on a weak failure suspector, in Proceedings of the 23rd IEEE Fault-Tolerant Computing Symposium (FTCS '93), 1993, pp. 534--543.

....through reliable channels. Communication is asynchronous and by exchanging messages. A failed process can later recover with its permanent storage intact and re join the system. Failures are detected using a (possibly unreliable) failure detector [CT96] A virtual synchronous multicast service [BSS91, Bir96, SR93] is used. This service delivers multicast messages and views. Views indicate which processes are perceived as up and connected. We assume a virtual synchrony with the following properties: 1) Strong virtual synchrony [FvR95] or sending view delivery [VKCD99] that ensures that messages are ....

.... block until joining again the majority view; 3) Liveness, when a member fails or it is partitioned from the majority view, a view excluding the failed member will be The failure detector must allow the implementation of the virtual synchrony model described below (e.g. the one proposed in [SR93]) and the non blocking atomic commitment (e.g. the one in [GLS95] eventually delivered. The protocol uses two di erent multicast primitives [HT93, SS93] reliable (rel multicast) and uniform multicasts (uni multicast) Three primitives de ne optimistic uniform reliable multicast : ....

A. Schiper and A. Ricciardi. Virtually Synchronous Communication Based on a Weak failure Suspector. In Proc. of FTCS-23, pages 534-543, 1993. 16

....services; in particular, they specify how message deliveries are synchronized with view deliveries. This synchronization is done in a way that simulates a benign world in which message delivery is reliable within each view. Many variants of Virtual Synchrony have been suggested (for example, [77, 43, 27, 19, 82, 12]) In addition to other properties, nearly all of them include a key property, called Virtually Synchronous Delivery, which guarantees that processes that receive the same pair of views from the GCS receive the same sets of messages in between receiving the views. Henceforth, when we refer to ....

....view are, the algorithm has to tolerate transient inconsistent views and cascading connectivity changes. In particular, a Virtual Synchrony algorithm needs to know which synchronization messages sent by di#erent processes pertain to the same view formation attempt. Existing algorithms, such as [43, 6, 82, 12, 47, 8], identify such synchronization messages by tagging them with a common identifier. Some initial communication is performed first, before synchronization messages are communicated, in order to agree upon a common identifier and to distribute it to the members of the forming view. While a view is ....

[Article contains additional citation context not shown here]

A. Schiper and A.M. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Computing Symposium (FTCS), pages 534--543, June 1993.

....we associate message send and delivery events with views: wesay that an event e occurs at a process p in view v if v was the last view delivered to p before e, or a default initial view v p if no such view was delivered. Many variants of virtual synchronysemantics have been suggested [32, 19, 39, 12, 34, 18]. All of these variants specify that every message is delivered in the same view by all processes that deliver it. Some of these semantics (e.g. strong virtual synchrony [19] strengthen this property to require that the view in which a message is delivered is the same view in which it was sent. ....

....has two important consequences: it guarantees that the same view is not delivered more then once to the same end point and that if two views are delivered to two end points they are delivered in the same order. These properties are fulfilled by virtually all group membership services (e.g. [12, 16, 7, 19, 10, 27, 34, 5]) In addition, using the mode[p] variable, the mbrshp automaton requires that the membership service send at least one start change to an end point p prior to every view v sent to p. It also requires that the start change identifier v.startId(p) be the same as the cid of the latest start change ....

[Article contains additional citation context not shown here]

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure suspector. Digest of Papers, FTCS-23, pages 534--543, June 93.

.... a set of messages is agreed upon and delivered at all processes before delivering the change notification; virtual synchrony, in which membership change notifications are delivered to the application at the same point in the application message stream at all processes 2o [Birman Joseph 1987, Schiper Ricciardi 1993] extended virtual synchrony, in which all messages sent by the application prior to receipt of the change notification are guaranteed to be delivered before the change notification itself [Amir et al. 1993, Moser et al. 1994] external synchrony, in which, when a process updates its ....

.... state updates to occur only in completed majority groups (where a group is completed if it is joined by all of its members) and ensures that all processes currently joined to a completed majority group agree on a unique history of updates; strict agreement (otherwise known as uniform agreement [Schiper Sandoz 1993]) which ensures that all correct processes, whether joined to a majority group or not, agree on a linear history of updates, seeing at any time some prefix of this unique history. 6.2.1. Group agreement Group agreement represents a partitionable membership service specification which allows for ....

A. Schiper and A.M. Ricciardi, "Virtually-Synchronous Communication Based on a Weak Failure Suspector", in 23th Int. Conf. on Fault-Tolerant Computing, (Toulouse, France), pp.534-43, IEEE Computer Society Press, 1993.

....we ensure that the delivered sequence is a prefix of the complete sequence. An important issue with group communication is liveness. Often, the specifications are either trivial without liveness condition [2] either impossible to achieve [6] Liveness properties can be required eventually in [5, 15, 18, 16, 20, 23] or when the system is stable [12, 8] But, when we deal with real time, eventually properties are not sufficient: we have to ensure timeliness properties. These considerations lead us to consider that the timed asynchronous system model of [7] and its extension of stable predicates is ....

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure susupector. pages 534--543, June 93. Digest of Papers FTCS 23.

....of messages and view changes that have been delivered. Ideally, the membership service should guarantee that the composition of concurrent views have empty intersections, since this scenario corresponds to the intuitive notion of clean partitions. Such a semantics is called strong partial [SR93] Unfortunately, a strong partial service may be blocking, that is, a failure (or a failure suspicion) occurring at an inopportune point of the membership protocol may delay a view installation until the failure recovers [BDGS95] Actual implementations eliminate the possibility of blocking by ....

A. Schiper, A. Ricciardi, "Virtually-synchronous communication based on a weak failure suspector", Proc. of the 23-rd International Symposium on Fault-Tolerant Computing, June 1993, pp. 534-543.

.... crashed, it may be overloaded and thus slow, the communication path may have been disconnected or it may be experiencing long delays [10] An abstraction that can simplify both reasoning about and implementation of distributed applications is view synchrony 1 in the context of process groups [16, 6, 13] (see also Chapter 3) Two aspects of view synchrony enable it to hide most of the complexities due to failures and asynchrony. On the one hand, it cleanly describes failures and recoveries in the form of changes of the group view that are agreed upon by all connected members of the group. On the ....

.... that the system being considered is such that it admits a failure detector with weak properties that have been shown to be sucient to solve view synchrony (see Chapter 3) View synchrony implements the notion of a process group and provides reliable multicast as the basic communication primitive [16, 6, 13]. Processes that want to participate in a common computation join a named group. They terminate their participation by leaving the group. While a member of the group, processes communicate with each other through reliable multicasts. View synchrony includes a membership service that provides ....

[Article contains additional citation context not shown here]

Schiper, A., Ricciardi, A.: Virtually-synchronous communication based on a weak failure suspector. In: Proc. of the 23rd Intern. Symp. on Fault-Tolerant Comp. (1993) 534-543.

....speci es how message deliveries are synchronized with view deliveries. This synchronization is done in a way that simulates a benign world in which message delivery is reliable within each view. Many variants of Virtual Synchrony have been suggested (for example, MAMSA94, FvR95, VKCD99, BJ87, SR93, BDM98] Nearly all of them include a key property, called Virtually Synchronous Delivery, which guarantees that processes that receive the same pair of views from the GCS receive the same sets of messages in between receiving the views. Henceforth, when we refer to Virtual Synchrony, we assume ....

....algorithm has to tolerate transient inconsistent views and cascading connectivity changes. In particular, a Virtual Synchrony algorithm needs to know which synchronization messages sent by di erent processes pertain to the same view formation attempt. Existing algorithms, such as [FvR95, ADKM92, SR93, BDM98, GVvR96, AMMS 95] identify such synchronization messages by tagging them with a common identi er. Some initial communication is performed rst, before synchronization messages are communicated, in order to agree upon a common identi er and to distribute it to the members of the ....

[Article contains additional citation context not shown here]

A. Schiper and A.M. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Computing Symposium (FTCS), pages 534-543, June 1993.

....or it can specify null, meaning that the invoker is not interested in knowing when the method completes. Completion of IGMI by the servers forming a group satisfies a variant of view synchrony that has proven to be an important property for reasoning about reliability in message based systems [34]. Informally, view synchrony requires two servers that install the same pair of consecutive views to complete the same set of IGMI during the first view of the pair. In other words, before a new view can be installed, all servers belonging to both the current and the new view have to agree on the ....

A. Schiper and A. Ricciardi. Virtually-synchronous Communication Based on a Weak Failure Suspector. In Proc. of the 23rd Int. Symp. on Fault-Tolerant Computing, pages 534--543, June 1993.

....views Further changes in the network connectivity can occur while the membership service is reaching agreement on earlier changes. Such concurrent changes are more likely in a WAN due to the inaccuracy of failure detection. Existing group membership algorithms (for example, AMMSB98, FvR95, SR93, BDM98] often have the current invocation of the membership algorithm proceed to termination without re ecting the new changes, and then invoke the membership algorithm again to re ect them. Membership changes cause extra overhead for applications that rely on virtual synchrony. For such ....

....Moshe is designed to be used in conjunction with a group multicast service (cf. KK00] as part of a group communication system. Group communication systems generally provide some variant of virtual synchrony semantics; many such variants have been suggested [BDM98, MAMSA94, FvR95, VKCD99, BvR94, SR93, FLS97, KK00] While detailed discussion of all of these variants is beyond the scope of this paper, we describe here the most common properties of virtual synchrony and how clients can implement them in conjunction with Moshe. A deeper discussion can be found in [KK00] The key aspect of ....

A. Schiper and A.M. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Computing Symposium (FTCS), pages 534-543, June 1993.

....MIT9904 12, and by NSF grants CCR9909114 and EIA 9901592. The output of the membership service is called a view. The reliable group multicast service delivers messages to the current view members. Group communication systems generally provide some variant of Virtual Synchrony semantics (e.g. [21, 14, 26, 24, 12, 18]) that mask environment failures, and simulate a benign world in which message delivery is reliable within each view. Such semantics are especially useful for fault tolerant applications that maintain some consistent replicated state (e.g. 3, 17, 12, 25, 6, 20] The key aspect of Virtual ....

....another view v 0 deliver the same set of messages in v. This property has been called View Synchrony or, by itself, Virtual Synchrony (see [26] All variants of Virtual Synchrony specify that every message m be delivered in the same view v by all processes that deliver m. Many variants (e.g. [9, 14, 21, 18, 16, 12, 24]) strengthen this property to require that the view in which a message is delivered be the same view in which it was sent. This latter property has been called Sending View Delivery (see [26] Sending View Delivery is exploited by applications to reduce the amount of context information sent ....

[Article contains additional citation context not shown here]

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Computing Symp. (FTCS), pages 534--543, June 1993.

....such as those described in [12, 13, 32, 33] as these algorithms can provide distributed applications with high dependability and guaranteed timeliness. We have explored the possibility of adopting an alternative approach based on the use of the virtual synchrony abstraction, as proposed in [3, 38, 52]. This abstraction allows one to develop reliable applications in asynchronous distributed systems; in particular, it ensures that the processes implementing those applications eventually perceive the occurrence of possible failures and modifications of the system configuration. However, in a ....

A. Schiper, A. Ricciardi, Virtually Synchronous Communication Based on a Weak Failure Suspector, Proc. 23rd Int. Symp. on Fault-Tolerant Computing, June 1993, pp. 534 - 543.

....of GCSs. In particular, we will discuss Consul [MPS91b] Highways [Ahu93] Horus [vRHB94] Isis [BJ87] Maestro [BFHR98] Newtop [EMS95] Phoenix [MFSW95] Relacs [BDGB94] RMP [WMK95] Totem [AMMS 95] Transis [ADKM92b] and xAMp [RV92] group communication systems and the specifications in [SR93, MAMSA94, FvR95, RB91, CS95, Cri91, FLS97, MPS91a, HS95, JFR93, BDM95, BBD96, BDM97, DMS96, MS95, SS93, WS95, Nei96] 6.1 Assumptions Assumption 4.3.1 states that the network may not spontaneously generate messages and that all delivered messages are guaranteed to be uncorrupted. Note that this ....

....the network situation. Unfortunately, as we show in Section 3.2, such a desirable membership service is not implementable in purely asynchronous environments. In order to circumvent this impossibility result we augment the model with an external failure detector. A similar approach was taken in [SR93, MS95, BDM97, HS95] We assume that each process is equipped with an external failure detector module (or oracle) which reports to the local process which of the other processes are suspected to have failed. The GCS uses the failure detector in order to detect conditions under which the ....

A. Schiper and A.M. Ricciardi. Virtually Synchronous Communication based on a Weak Failure Suspector. Digest of Papers, FTCS-23, pages 534--543, June 93.

....in particular because inconsistent mapping decisions can be made when the system is partitioned. The paper focuses on the design of reconciliation mechanisms needed when a partition is healed. 1 Introduction For developing distributed applications, virtually synchronous group communication [4, 15] is a powerful paradigm. It allows processes to be organized in groups within which messages are exchanged to achieve a common goal. Virtual synchrony ensures that all processes in the group receive consistent information about the group membership in the form of views. The This work was partially ....

A. Schiper and A. Ricciardi. Virtually-synchronous communication based on a weak failure suspector. In Digest of Papers, The 23th International Symposium on FaultTolerant Computing, pages 534--543, Toulouse, France, June 1993.

....provide some variant of virtual synchrony semantics. Virtual synchrony semantics synchronize views with regular messages and thus simulate a benign world in which message delivery is reliable within the set of connected processes. Many variants of virtual synchrony semantics have been suggested [30, 20, 36, 13, 33, 19, 25]. Such semantics are especially useful for constructing fault tolerant applications that maintain consistent replicated state of some sort (e.g. 3, 6, 24, 19, 35, 9, 28] The key aspect of virtual synchrony is the interleaving of message send and delivery events with view events. To discuss ....

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure suspector. Digest of Papers, FTCS-23, pp. 534--543, June 93.

No context found.

A. Schiper and A. Ricciardi, "Virtually-synchronous communication based on a weak failure suspector," in Proceedings of the 23rd International Symposium on Fault-Tolerant Computing (FTCS-23), Toulouse, France, 1993, pp. 534--543.

No context found.

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure suspector. Digest of Papers, FTCS-23, pages 534--543, June 93.

No context found.

A. Schiper and A. Ricciardi. Virtually synchronous communication based on a weak failure suspector. In 23rd IEEE Fault-Tolerant Comp. Symp. (FTCS), pp. 534--543, June '93.

No context found.

A. Schiper and A. Ricciardi, "Virtually-synchronous Communication Based on a Weak Failure Suspector", Proc. Int'l Symp. on Fault-Tolerant Computing, June 1993, pp. 534--543.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC