Low cost management of replicated data in fault-tolerant distributed systems
ACM Transactions on Computer Systems (TOCS)
Reliable communication in the presence of failures
ACM Transactions on Computer Systems (TOCS)
Maintaining availability in partitioned replicated databases
ACM Transactions on Database Systems (TODS)
An efficient reliable broadcast protocol
ACM SIGOPS Operating Systems Review
Ordered and reliable multicast communication
ACM Transactions on Computer Systems (TOCS)
Lightweight causal and atomic group multicast
ACM Transactions on Computer Systems (TOCS)
The Totem single-ring ordering and membership protocol
ACM Transactions on Computer Systems (TOCS)
Multiversion concurrency control—theory and algorithms
ACM Transactions on Database Systems (TODS)
ACM Transactions on Computer Systems (TOCS)
Time, clocks, and the ordering of events in a distributed system
Communications of the ACM
Simplifying distributed database systems design by using a broadcast network
SIGMOD '84 Proceedings of the 1984 ACM SIGMOD international conference on Management of data
Broadcast Protocols for Distributed Systems
IEEE Transactions on Parallel and Distributed Systems
A Fault-Tolerant Protocol for Atomic Broadcast
IEEE Transactions on Parallel and Distributed Systems
Hi-index | 0.24 |
The purpose of a reliable broadcast protocol is to allow groups of nodes on unreliable broadcast networks to reliably broadcast messages. A reliable broadcast protocol must guarantee two properties: (1) all of the receivers in a group receive the broadcast messages, and (2) each of the receivers orders the messages in the same sequence. In an optimistic approach to reliable broadcast protocol, a batch acknowledgement is employed for a sequence of broadcast messages, instead of one or more acknowledgements per broadcast message used in the pessimistic approach. In this paper, based on the optimistic approach, we have proposed a counter-based reliable broadcast protocol. In this protocol, the unique token ownership is circulated among all the nodes in an order specified by a token-passing-list. The system state which records related information about messages broadcast by each node is included in the token message. By appropriately updating the counter information recorded in the system state included in the token message, instead of using explicit acknowledgement messages, the proposed protocol needs fewer control messages to commit a broadcast message than other protocols, no matter whether the rate of transmission errors is high or low. Moreover, we show how to handle the flow control problem and describe the token update technique.