Write Protocol

Writes are executed only on trusted (master) servers. When a client wants to perform a write, it sends the request to its assigned master, which first checks whether the client is allowed to invoke such a request, and if this is the case, it broadcasts the request to the other servers in the master set. Upon the successful completion of this broadcast, each master executes the request and increments a special variable, dubbed here $content\_version$ (which is initialized zero when the content is created). In the end, all master servers hold updated, but still identical copies of the data content (because they have executed the same write) and have the same value for the $content\_version$ variable.

At this point, the slaves are updated: each master sends the update together with the signed and time-stamped and new value for the $content\_version$ variable to all its subordinates through a secure broadcast. In order to prevent race conditions, two write operations cannot be, time-wise, closer than $max\_latency$ 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 $content\_version$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 $max\_latency$ old.