Thanks to you for taking a look, Flavio!
If it is idle, then it doesn't do anything. The implementation is a class that has 4 methods:
- start() : Invoked from LearnerHandler thread.
- updateProposal() : Invoked from the thread that sends packets. If process has started, and there is no proposal, it starts monitoring that proposal. If there is a proposal already, it updates the "next proposal" to monitor.
- updateAck() : Invoked from the thread that receives packets. If the ACK corresponds to the current proposal, then it removes the current proposal and if there is a "next proposal" it starts using that one.
- check() : Invoked from the Leader thread. It returns true if everything is ok, false if there is a timeout.
It has the following states:
- NOT_STARTED: It doesn't do anything. Check will always return true. It can only transition to WAITING_FOR_PROPOSAL.
- WAITING_FOR_PROPOSAL: It expects a new proposal. Check will always return true. As soon as one proposal arrives it will start monitoring it and transition to MONITORING_PROPOSAL.
- MONITORING_PROPOSAL: It waits for the ACK of the proposal under monitoring. Check will return true unless there is a timeout for the current proposal. It continuously update the "next proposal" with incoming proposals. If the ACK for the current proposal arrives, it will either update the proposal with the "next proposal" or transition to WAITING_FOR_PROPOSAL if there is no "next proposal".
The monitoring is started when the synchronization phase ends (and the timeout in the socket is updated to syncLimit*tickTime). The processing required in each of the calls to the four functions is minimal, so there should be no disturbance of performance at all.
Since proposals are executed in order, with this checking the longest time between a proposal and its ACK will be if there is a proposal that comes immediately after the one that is being monitored, and its ACK arrives immediately before the ACK for the "next proposal" after that. That would mean (2 * syncLimit) * tickTime, and then since we check the timeout every 1/2 tickTime, that needs to be added so it is (2'5 * syncLimit) * tickTime. In usual operation, ACKs will take more or less the same for every proposal and the timeout will jump more or less as soon as any of the ACKs takes longer than (syncLimit * tickTime).
Or at least that is how I intend it to work .
... and I don't mind to turn this upside down for anything else that covers the requirement, so I hope that we won't have a problem in converging on a patch ... we'll see.
Sorry about deleting the patches. It made me unconfortable to leave there something that didn't work. But I will keep in mind that way of working from now on.