Replicated Applications, Data and Multicast Transactions

An alternative to replicating the interface to the application is to replicate the application itself (assuming we have access to the source. Processes are grouped so that messages concerned with changing the state of each replicant can be propagated by a multicast system to the group. These groups can be taken as host groups, or use a transport level multiplexor (e.g. UDP or TCP ports) to have multiple process groups per host group. The simplest model for replicating the application is to separate the access to any state in the application into read-only and modify operations. Then if the floor control system is such, the modify operations are only permitted from one copy of the application to all the others (using multicast), and read operations from the other copies. Of course, since there is only one writer and many readers, the only consistency requirement is to synchronise the views all the applications have. However, many users and applications require less strict floor control, and in these cases, there will be multiple concurrent sources of read operations as well as write. This will entail concurrency control. Since messages are not ;SPM_quot;idem-potent;SPM_quot; in the sense of a video or audio update, it is necessary to ensure uniqueness and reliability of delivery of group addressed messages. It may be further necessary to ensure overall atomicity of messages, and even global ordering. Each of these requirements entails further group and unicast messages, which reduce the gain from the basic multicast facility. Factors contributing to the extra cost of carrying out atomic replicated communication using multicast:
  1. how long do we wait before we can be sure that all messages has arrived before we sort them
  2. Arguments similar to those above can be made for storage.
  3. Although unlikely, there will be cases when the timestamp on two messages are the same. We would need some arbitrary mechanism to sort the order. One way is to append the timestamp with host identifier/address.
A simple calculation shows the reduction in traffic for an 2-phase commit protocol, when using multicast:

Figure: 2-Phase Commit Protocol

The Cost of using unicast for a complete 2-phase commit for the master is shown in #fn8c1#1766>.

Figure: Costs for 2-phase commit unicast protocol

Cost of using multicast for a complete 2-phase commit (assuming the master and all slaves are on the same multicast net) is shown in figure #fn8c2#1770>

Figure: costs for 2-phase commit multicast protocol