The event-loop execution on each node in this model is similar to the server's event-loop in the client-server model. Essentially, each node acts as an authoritative server for each primary object in its local store (serving as a serialization point for updates, just as a single-server would serialize commands from multiple clients), and as a client of other nodes for the replicas in its local store (sending its writes on a replica to the node maintaining the primary).
Although there can be transient inconsistency between primary and replica state, all replicas eventually converge to the same state due to single-copy serialization. In addition, because the primary always has access to other objects it is interested in, the ``read-set'' is loosely consistent with that of a centralized model. Moreoever, bounded inconsistency is tolerable in games since there is a fundamental limit to human perception in short time-scales. For example, even in current client-server architectures, the client-side state is always slightly out-of-date with respect to the authoritative server state.
We believe game developers can also tolerate these minor inconsistencies in object store state, resolve frequently occurring conflicts simply and inexpensively, and that strict consistency across multiple objects is rarely required. As an example, in our distributed Quake II implementation, we observed that the only frequent conflict that affected gameplay was a failure to detect collisions between solid object on different nodes. We implemented a simple ``back-off'' conflict resolution strategy which, from the perspective of a player, resulted in game-play virtually indistinguisable from that had we actually detected the collision. When consistent modifications to multiple objects are required (i.e., a distributed transaction), simple solutions, such as having one node act as a serializer, could be employed at the expense of some performance. For simplicity, some developers might also prefer to implement the logic for special regions of the game world without the complexity of managing (possibly) distributed state. This model can facilitate this desire by migrating all objects within that special region to the same node.
There are certainly other components of online games that this model does not encompass, such as content distribution and persistent storage, but the problem of distributing most of these components is orthogonal to distributing gameplay and is readily addressed by other research intiatives [15,17].