The Totem single-ring ordering and membership protocol

Abstract

Fault-tolerant distributed systems are becoming more important, but in existing systems, maintaining the consistency of replicated data is quite expensive. The Totem single-ring protocol supports consistent concurrent operations by placing a total order on broadcast messages. This total order is derived from the sequence number in a token that circulates around a logical ring imposed on a set of processors in a broadcast domain. The protocol handles reconfiguration of the system when processors fail and restart or when the network partitions and remerges. Extended virtual synchrony ensures that processors deliver messages and configuration changes to the application in a consistent, systemwide total order. An effective flow control mechanism enables the Totem single-ring protocol to achieve message-ordering rates significantly higher than the best prior total-ordering protocols.

A Nonblocking Approach for Reaching an Agreement on Request Total Orders

“…Several literatures addressed the issue of message total ordering with the logical token ring. In Totem developed by UCSB, a symmetrical fault tolerant protocol based on the logical token ring was implemented, including total ordering protocol with single ring and multiple rings respectively [1], [2]. The functioning replicas had to stay in the Recovery state before they were switched to the Operational state if some faults occurred and all functioning replicas needed to reach an explicit agreement on their decisions about the ring before any new decisions were made.…”

“…There are numerous literatures regarding total ordering protocols [7], especially using the logical token ring [1], [2], [12]. A logical token ring is composed of replicas.…”

The Bancomat problem: An example of resource allocation in a partitionable asynchronous system

“…1 We give here an informal and incomplete description of the problem to introduce the key concepts a complete speci cation is in Section 4.…”

“…Because of this fact, we restrict our discussion to protocols for which at least n ; 1 of the bancomats i will attempt to withdraw more than u i . In doing so, we will never construct a run that has bancomat 1 wait for a message to withdraw more than u 1 . We refer to a bancomat i as being drained when w i = u i and r i > w i (i.e., it has given out u i quanta and has requests to give out more).…”

“…To satisfy the last request n ; 1 needs to receive an authorization message. Suppose that one is sent, and then partition n ; 1 We call the two resulting protocols CS1 and CS2 (for the initials of the last names of the developers). We do not consider the question of the implementability of group membership in an asynchronous system 7].…”