Interaction Scheme Sample Clauses

Interaction Scheme distinguishes a request corresponding to a Read operation (broadcast during a Prepare phase) from a request corresponding to a Write operation (broadcast during a Propose phase). In Paxos-MIC, this distinction that is managed by the leader does not appear in the messages it transmits: as explained later, each operation is interpreted as being both a Write operation and a Read operation. Thanks to this standardization of messages, all the actions performed by an acceptor and the major part of the actions performed by a coordinator, aim at maintain- ing their local state as up-to-date as possible by taking into account the received information when this one appears to be more recent. As a consequence, the query-reply communication pattern implemented in Paxos-MIC does not use well-formed requests. More precisely we assume neither that a coordinator initiates only one query-reply at a time, nor that it waits for appropriate replies before proceeding to the next step. To cope with message losses, the last sent message is retransmitted periodically as it reflects the current state of the sender. To each coordinator is attached an internal proposer-learner running on the same ma- chine (called PLint for short). A PLint is in charge of the interactions between its associated coordinator and the external proposers and learners. In Paxos-MIC, the usual specification of a coordinator is extended in order to ensure the interaction with its associated PLint. A coor- dinator never interacts with a remote PLint. The communication between a coordinator and its local PLint is performed via two functions: ProposePull and DecidePush (see Figure 4.1). Note that the call is initiated by the coordinator in both cases. The code executed by a PLint is described in Figure 4.2. The PLint may be regarded as a temporary storage unit that knows the following: • the current consensus number c; • the received proposals related to this consensus instance, denoted by Xxxxxx. An entry in this buffer contains a proposal for consensus c, with the value vp, made by proposed with identity pid; • the identities of the learners interested by the corresponding decision; • the last decision value DVal corresponding to the previous consensus instance c − 1. − At any time, a PLint gathers proposed values related to consensus c upon the invo- cation of Propose(vp, c) by a PLext (lines 1 to 4). A PLint may provide any decision already made. Indeed, it knows the last decision corresponding to consensu...