At this point, the slaves are updated: each master sends the
update together with the signed and time-stamped and new value for
the
variable to all its subordinates through
a secure broadcast. In order to prevent race conditions, two
write operations cannot be, time-wise, closer than
to each other. This ensures that any reads on which the second
write depends will take into account the first write. This
obviously limits the number of write operations that can be
executed in a given time, which is why we advocate our
architecture only for applications where there is a high reads to
writes ratio.
In order to satisfy the latency constraint, the master servers
have to periodically broadcast ``keep-alive'' packets consisting
of the signed and time-stamped value of the
variable to their server set, even when no writes occur. A slave
can handle client requests only if the most recently receive
``keep-alive'' packet is less than
old.