stepchowfun / paxos Goto Github PK

Hello,

I appreciate the effort put into developing this Paxos implementation. I have a query regarding the behavior of the proposer, specifically in relation to checking the proposal number staleness.

I've noticed that the proposer doesn't seem to actively check the staleness of the proposal number; it primarily relies on the count of received majority responses. It appears that the rpc.rs component ensures that responses correspond to the correct requests, which could implicitly address the proposal number staleness. Could I infer that the RPC mechanism inherently prevents stale responses from interfering with other requests? However, I'm curious whether certain scenarios might still lead to stale responses affecting subsequent requests. For instance, if a send operation retried with exponential backoff after a timeout error, and the initially timed-out response later arrived, could it possibly impact subsequent retrying responses in the receiving queue?

Considering the critical role of the proposal number in maintaining consistency and conflict prevention within Paxos, is it reasonable to rely solely on the implicit proposal number check provided by the RPC mechanism? Could this reliance potentially compromise Paxos' fault tolerance in the face of failures, network delays, and message reordering? Also, have you considered the feasibility of decoupling the algorithm from the RPC layer to enable compatibility with other RPC mechanisms, such as those built upon UDP?

Thank you for your time and insights. I look forward to your response.

Best regards