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:
-
how long do we wait before we
can be sure that all messages has arrived before we
sort them
-
Arguments similar to those above can be made for
storage.
-
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:
#figure1763#
Figure: 2-Phase Commit Protocol
The Cost of using unicast for a complete 2-phase commit for the master
is shown in #fn8c1#1766>.
#figure1767#
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>
#figure1771#
Figure: costs for 2-phase commit multicast protocol