Dealin ask

1. Replication guarantee:

   • Reliable delivery: If a transaction M is submitted by one server, it will eventually be submitted by all servers in absolute order: if one server submits transaction A before transaction B, then for all servers, A will submit before B.

   • Causal sequence (Causal Order): If transaction B is sent after the submission of B, then A must be placed before this, if the sender sends C after sending B, C must appear after sending B.

2. As long as 2 / 3 of the nodes are normal, the transaction is copied.

3. During transaction replication, transactions lost due to the fault machine should be reacquired when they are restored.

Dealin realize:The Client (s) client can start the read operation from any Dealin node. However, when it writes to any Dealin node, the status change is first forwarded to the applicant node.Dealin Use a variant of the two-phase-commit protocol to copy the transactions to the validator (s). When proposer receives a status update from a Client, it generates a transaction with the ordinal numbers c and proposer epoche (see previous definition) and sends it to all validator (s). validator Upon receiving, the transaction is added to its history queue and the ACK is returned to the proposer. When proposer receives a notifiable (quorum) ACK, it issues a transaction quorum submission. Receiving a submitted validator (s) commits the transaction unless the c value is greater than the serial number used in its history queue. This waits for the previous transaction (outstanding transaction (s)) submission before executing the commit. Once proposer collapses, a recovery protocol is executed between nodes, ensure the following two points:

• Consensus of common states between nodes before the resumption of normal service;

• Find out a new proposer to broadcast the status updates. It is also necessary to obtain a legal quantity (quorum) node support for a node to exercise the proposer role. In reality, due to the collapse and recovery of existing nodes; during a period of time, there may be multiple proposer changes, or even the same node becomes proposer many times.

Life cycle of the node: each node either performs a complete circle of this protocol at a time; or the circle is suddenly interrupted, back to Phase 0, and start a new circle.

• Stage 0 -- the applicant election

• Phase 1 -- findings

• Phase 2 -- synchronization

• Phase 3 -- broadcast

Note: Stage 1 and Stage 2 are important to ensure state consistency for all nodes, especially when the node recovers from the crash.Stage 0 (Phase 0) -- Proposer election:Nodes are run in an initialized state of election during this stage. proposer The election agreement need not be more special, as long as it can end, high probability, can choose a available node, the number of election nodes reach the legal number (Quorum).Proposer After the election algorithm ends, the node will save its election results to the local memory. Roughly: if the node p votes for p0, then p0 is called the expected proposer of p; if the node votes for itself, its state should be set to leading, otherwise it is set to following. By the way, only at the beginning of the Phase 3 can the pre-proposer selected here become a real proposer and become the main processing node.Phase 1 -- Discovery:At this stage, the validator (s) and their intended proposer maintain communication so that the proposer can collect information about the most recently received transactions of the validator (s). The purpose of this phase is to find as many received transactions as possible within the quorum (quorum) node to create a new epoch in case the previous proposer submits a new transaction.In theory, the validator (s) with a quorum (quorum) has information on all accepted status changes in the previous proposer, so the validator (quorum) has all accepted status changes in the previous proposer in its history queue. That means the new proposer will also get the information.Phase 2 -- Sync:The synchronization phase summarizes the discovery phase of the protocol, in that proposer will synchronize the cluster nodes with the change history obtained in the discovery phase. proposer Communicate with validator (s) and issues transactions from your own history queue. If the history of validator (s) lags behind proposer, validator (s) will reply to ACK; when proposer sees the ACK from the legal number of nodes (quorum), it sends submit information to them. At this point, the proposer role really established, no longer the expected proposer.Phase 3 -- Broadcasting:Starting now, if no nodes crash, they will stay at that stage forever, receiving a write request from Client and execute the transaction broadcast.Note: For failure detection, Dealin uses periodic heartbeat (heartbeat) messages between proposer and validator (s). If proposer does not receive the legal quantity (quorum) heartbeat within the specified time, it will abandon the leadership and move to the election state, Phase 0; and if validator does not receive the heartbeat (heartbeat) from proposer, it will also move to the proposer election phase.