pivoz / distributedsystem1-project Goto Github PK

Client requests. The client can issue read and write requests to any replica. Both types of request contain
the ActorRef of the client. The write request also contains the new proposed value v*.

Complete the TODO in Test.java

Flows like the following (that is correct) are signaled as not consistent:
a = [5,6,8,9,10,11]
b = [1,2,7]
c = [5,1,2,7,6]

Update Protocol: To perform the update request, the coordinator initiates the protocol by broadcasting to
all replicas the UPDATE message with the new value. Then, it waits for their ACKs until a quorum Q of
replicas is reached. In this implementation, Q = N/2 + 1, i.e., a majority of nodes. Once enough ACKs are
collected, the coordinator broadcasts the WRITEOK message.

Each UPDATE is identified by a pair <e,i> where e is the current epoch and i is a sequence number. The
epoch is monotonically increasing; a change of epoch corresponds to a change of coordinator. The sequence
number resets to 0 for every new epoch, but identifies uniquely each UPDATE in an epoch. Upon a WRITEOK,
replicas apply the update and change their local variable. They also keep the history of updates to ensure none
of them is lost in the case of a coordinator crash (see \Coordinator election").

Coordinator election. If the coordinator crashes, the remaining replicas must elect a new coordinator to take
its place. Coordinator election must be performed by a simple ring-based protocol, where the ring topology is
established based on replica IDs. ELECTION messages forwarded in the ring should contain the information
about the known updates for each node. The new coordinator should be a replica that knows the most recent
update. IDs are used to disambiguate replicas that are equally up-to-date. Eventually, the best candidate
broadcasts a SYNCHRONIZATION message to announce the new leadership and synchronize all other replicas
by sending all the updates that they missed. Then, the broadcast protocol can continue.

The coordinator should keep that message in memory forever in the current implementation

If any client send an update to any replica during the election, the "coordinator" object can be null

Create a Timeout class that takes in input a value representing the millis and a callback to call when time expires. It has to implement a cancel method that stops the timeout.

Each Replica has a different timeout to avoid concurrent message start. Used also during ELECTION

Implement READ request from Client to Replica