Synchronous Atomic Broadcast Implementation

Report by Jacob Schrum
for CS386C Spring 2009

This project was implemented as a PHP webpage in order to make it easily accessible to anyone interested in understanding how synchronous atomic broadcast works. The simulator can be accessed and used by anyone at my webpage: http://www.cs.utexas.edu/~schrum2/cs386c/sab.php

The code models synchronous atomic broadcast between processors in a network with redundant channels. The simulator also allows the user to set up several types of faults in advance, in order to test the correctness of the system. The simulator uses the model proposed by Flaviu Cristian, but a few simplifying assumptions are also made. The properties of the system are as follows:

  • Clock drift ignored: Clock drift of processors is not modelled. Given a starting time, processors will reliably maintain time relative to their starting time
  • Clock synchronization assumed: Although there is no clock drift, different clocks are allowed to have different values. These starting values all have to be within epsilon time units of each other. Because there is no drift, this means the clocks will remained synchronized within epsilon.
  • Initialize at 0: The starting global time of the simulation is always assumed, without loss of generality, to be 0. The local clocks are also synchronized within epsilon of the global time. Therefore all clocks start within times in [0,epsilon].
  • Sends occur simultaneously: When a processor sends a message, either by initiating it or by forwarding, it will typically need to send that message on more than one channel. Although sends to higher channels technically occur after sends to lower channels, the simulation processes all of these commands at the same time, meaning they all occur at the same time step of the simulation. However, processor crashes during sends can still occur between broadcasts.
  • Random transmission times: The timeout on channel broadcasts is delta. Whenever a processor executes a command to broadcast on a particular channel, a random integer in [0,delta] is chosen for each receiving processor as the transmission time.
  • Maximum faults defined for whole simulation: The maximum number of allowable faults f per broadcast is in this simulation also used to define the total number of faults during the simulation period. This was done in part to simplify the user interface, and in part because some faults are designed to affect several broadcasts.
  • Channel omissions occur across all messages on channel: One of the allowable fault types is a channel omission. This will affect all messages currently on the channel. Such an omission will only ever be a single fault to a particular broadcast, but will impact every individual broadcast curently making use of the channel.
  • Certain faults are scheduled in advance: The way that the user will specify most faults will be to designate a global time after which they will occur. For example, crashes while forwarding and in-adapter omissions are scheduled in advance, but they will only occur if conditions allow. For example, if a processor's in-adapter is scheduled to omit the first message after a certain time t, but doesn't receive any messages after that time, then the fault will never occur.

  • For more information regarding the source code and the user interface, please refer to the user manual.