How to use the Paxos algorithm in the SMR (state machine Replication) system

Although we have seen so much about Paxos algorithm theory and paper, but still foggy, because there is no practice. Here we do not talk about theory, directly with the actual development to explain the application of Paxos algorithm.

The proposal (proposal) is an important component of the Paxos algorithm.
Let's take a look at the data structure used to transfer proposals (ACCEPT_REQ) between distributed nodes:

struct accept_req {    node_id_t node_id;    view_stamp msg_vs;    view_stamp req_canbe_exed;};struct view_stamp {    view_id_t view_id;    req_id_t req_id;};typedef uint32_t view_id_t;

Corresponding to it, we also need to maintain several variables on the node:

Highest_committed_vs

Highest_seen_vs

Highest_to_commit_vs

Our distributed system uses three nodes, one of which is leader, and the other two is secondary node.

Highest_seen_vs indicates that the node is currently receiving the largest number of proposals in the request.

On leader, Highest_seen_vs is used to generate a request for a proposal number (that is, the VIEW_STAMP data structure mentioned above):

view_stamp next = get_next_view_stamp(comp);view_stamp_inc(comp->highest_seen_vs);

Leader receives a request from the client (to be precise, it should be a socket operation, including connect, send, close three), binds next to this request and adds 1 in order of arrival. The Highest_seen_vs on the leader node can represent the largest number in the currently accepted request.
On the secondary node, the Highest_seen_vs update is based on a proposal from leader (the Accept_req mentioned earlier). This proposal represents a request, so it contains the proposal number MSG_VS for this request. When the secondary node receives the proposal, it compares the proposal's msg_vs with the Highest_seen_vs maintained on the node, and, if the former is larger than the latter, updates the latter to the former:

// update highest seen requestif(view_stamp_comp(&msg->msg_vs,comp->highest_seen_vs)>0){    *(comp->= msg->msg_vs;}

Go back to leader and see how the proposal is structured. A proposal represents a request. With the above introduction, we already know that the MSG_VS in the proposal is the number assigned to this proposal by leader, what does req_canbe_exed represent? Let's introduce Highest_to_commit_vs:

Highest_to_commit_vs represents the request that the node is about to submit.

The submission request means that the request has been approved by the majority of the three nodes (two or three nodes) and can be submitted to a real server for processing. This is the way Paxos is used to agree on a request between three nodes.

Highest_committed_vs indicates the maximum number of requests that have been submitted.

That is, the request can be divided into three types: received but not recognized, approved but not committed, submitted.

Back to the req_canbe_exed on leader, when the leader constructed a proposal for a request, there were:

msg->req_canbe_exed.view_id = comp->highest_to_commit_vs->view_id;msg->req_canbe_exed.req_id = comp->highest_to_commit_vs->req_id;

It is visible that req_canbe_exed conveys the proposal number of the request that will be submitted on the leader node. When the proposal is sent to the secondary node, the secondary node compares the req_canbe_exed in the proposal with its own highest_to_commit_vs, and if the former is large, updates the latter to the former:

if  (View_stamp_comp (&  msg->  req_canbe_exed, Comp ->  highest_to_commit_vs) >  0 ) {//if the former is greater than the latter  *  (Comp-& gt;     HIGHEST_TO_COMMIT_VS) =  msg->  req_canbe_exed; Sys_log (Comp, "now Node%d Can Execute Request%u:%u. \ n" , Comp->  node_id, Comp->  highest_to_commit_vs-  view_id, Comp->  highest_to_commit_vs->  req_id);}  

As can be seen, the leader and secondary nodes remain in the same state at all times: Leader updated Highest_seen_vs and Highest_to_commit_vs, which is sent to secondary node by proposal (Accept_ REQ) tells secondary that the update is up.

There is also a concept that looks at figure first:

There are still msg_vs to Highest_committed_vs arrows. The following will cover the core ideas of Paxos.
When the proposal arrives at the secondary node, the node discovers that the number of the proposal is less than or equal to the maximum number HIGHEST_COMMITTED_VS the node has submitted. This indicates that the request represented by this new proposal has been submitted to the real server for processing on that node, and the node ignores the request:

if(view_stamp_comp(&msg->msg_vs,comp->highest_committed_vs)<=0){// we have committed the operation, safely ignore it    "I‘ve already committed the operation.                               I‘ll ignore this one.\n");    goto handle_accept_req_exit;}

Here's the problem.
question one: Under what circumstances will the secondary node ignore the proposal from leader?
Question two: Why does a proposal have to be submitted with a majority of approvals?

How to use the Paxos algorithm in the SMR (state machine Replication) system