Jupiter implements a centralized architecture, with each client node communicating with the main server. This server has for purpose to centralize the actions, coordinate the clients and ensure the consistency.
To the server, each client appears to be operating synchronously with respect to the server’s actions. The server can thus use a simple change propagation algorithm to keep all the clients updated and in sync.
Note: it is possible to merge the HTML and the REST server by editing the config file, for instance when there is only one port available.
We this differentiate two kind of nodes in this architecture: - the Master node, ie. the central server/coordinator - the multiple Client nodes, which are running the edition application
Jupiter consistency algorithm is based on the optimistic concurrency control heuristic, which requires no communication with the coordinator before applying changes locally. Those changes are applied immediately, while the other parties of the action are getting informed.
If more than one participant makes a change at the same time, a conﬂict resolution algorithm is applied. This algorithm transforms the local operations to non-conflicting ones, so that every party can move to the same final state.
These transformations are assured by the function xform, which takes as parameters the local (and thus already applied) operation Ol and the incoming one Oi, and returns the 2 transformed operations Ol' and Oi'. The party thus only have to apply Oi' to reach the consistent and final state.
The transformations applied by xform over the operations are defined for each couple of potential conflicting operations. (see Operations & Transformation Rules).