Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
SCC.311 Coursework Stage 3 Specification [Revision 1]
Level 5: Passive Replication (20%)
The server implementation should have at least three replicas and allow the user to easily add a new replica. You must design your server program so that any replica can function as the primaryreplica. The clients will communicate with a stateless front-end program which should then simply forward client requests to the primary replica (Note: the only acceptable state to maintain by the front-end is the IDs of one or more replicas if needed). Your front end should initially pick one replica and keep using that replica as the primary replica until it fails.
The primary replica must ensure that all replicas maintain a consistent view of the auction data before responding to each request. Your front-end is required to implement the Auction interface, and you can choose for yourself exactly how the front end and replicas interact.
Requirements: Each replica must run in a separate process, and your replica server program must support a command-line parameter to assign a unique identifier (i.e., an integer) to each replica. For example, you should be able to start a replica from the command line with ID 1 as shown below:
public interface Auction extends Remote {
Level 6: Fault Tolerance (25%)
Your system must maintain liveness even when the automated testing system kills all but one ofthe replicas (including the primary replica). Even when the current primary replica fails, yoursystem should continue functioning correctly. Your system should also allow replicas to recoverand re-join the system.
Ideally, your system should work even with a complete replica turnover; that is, you want yoursystem to start with three replicas (say with IDs 1, 2, and 3), add another replica (with ID 4), killall original replicas (with IDs 1, 2, 3) and have the system continue to function correctly.
A recovering replica, upon re-joining, must synchronise with the system and become fully up-to date as quickly as possible. The recovery process must not depend on the arrival of client requests to trigger synchronisation. This ensures the recovered replica can seamlessly serve requests and potentially take over as the primary replica without delay. Your design should prioritise an efficient recovery process that minimises downtime and ensures the consistency and correctness of the recovered replica. Replicas must not use permanent storage (i.e., disk) to store their state.
Your front-end should initially pick a replica as the primary replica, and only in the event of a failure detection, the front-end should select a different (i.e., a working) replica as the primary.
You must make sure that getPrimaryReplicaID() returns the identifier of your current primary replica.
Coursework submission instructions
Your coursework will be marked using an automated test system. For the test system to work properly, your submission must be contained in a zip file and have the following: