In this commit, it was added a new feature to SMaRt. It now supports dynamic views. Some bugs from the previous commit were also fixed. This was a fairly extensive update to SMaRt.

Nonces are now generated for each TOMMessage in a Batch with a single seed that is sent along with the batch instead of a fixed number of nonces per Batch.
Decided notification in Consensus.java now is done via a sync monitor instead of busy waiting on the decided value to be set. Because of the Java MemoryModel the former mechanism was problematic and could theoretically lead to the DeliveryThread never learning the new value - which is very unlikely though.

Fixed a Bug where a remote Server with an id equals to the number of nodes caused an ArrayOutOfBoundsException

In this commit I updated the readme and configuration file, and also made the state transfer protocol able to be disabled

In this commit I made an optimization to the state transfer protocol that consists on the sending of hash's of the state. Only one replica will send the actual state. I also worked towards fixing some bugs.

In this commit I started to clean up the code that I wrote. I also added some debug messages which are produced with the Logger object.

In this commit, I continued to work on the state transfer protocol .I finally managed to correctly implement the optimization for the revived replica to request the state sooner than the paxos highmark.

In this commit, I continued to work on the state transfer protocol.I finally tested the protocol in the case of a crash of a replica. I was able to make the replica recover the state on those circunstances.  However, the replica will still only requests the state after it passes the highmark value. I started working on an optimization to request the state before it reaches that highmark, but its still not completed.

In this commit, I continued to work on the state transfer protocol. It is already capable of transfering leader information, and supply it to the delayed replica. This means the code is no longer hacked to always assume replica 0 is the leader. It also does garbage collection again.

I also made some minor adjustements to some debbuging messages and the new demo

In this commit, i fixed a bug that would make the delayed replica get in an invalid state, which would manifestitself  in the counter as more increments than the ones issued by the clients

I this commit, I tried to fix some race conditions and bugs regarding the out of context thread, when it executes concurrently with the update of the delayed replica

I this commit, I made the TOM layer pass information about the execution id, decision round, and leader to the application. I also continued to work on the exchange of leader info in the state transfer protocol, and implemented a new demo which is more sofisticated than the counter.

In this commit, i've continued to try to find and fix more errors related to the updating of delayed replicas. I have managed to fix three of them, but the code is merely "patched". If there is a leader change, SMaRt will go haywire. This version o the code should not be used for other purpose then testing.

I added more debug messages, and I will keep looking at the code during the weekend. I expect to fix some more bugs that i found during that period. I will also produce more debug logs so i can try to find more bugs.

In this commit, i've continued to try to find the errors on the state transfer protocol. I think i found one, and I'm beginning to add code to fix it. However, I would like to speak to the teachers tomorrow about this.

P.S. I also added more debug messages

I this commit, I continued the work on the state transfer protocol. I implemented the modifications discussed. However, the protocol remains faulty. Further debugging is required.

In this commit, i've only added some debug messages.But I committed it anyway, so I can work on SMaRt during the weekend at home

In this commit, i've continued my task of debuging the code.I finally managed to get the replica to update itself. However, when the clients finish to send requests, that same replica still remains a little behind, even though it sucessfully updates itself during previous executions of the state transfer protocol.

In this commit, i've continued my task of debuging the code. I believe the protocol itself is functioning correctly, but I still have to set the replicas to actually enforce the received state upon the application. The commited code is tested, and SMaRt seems to work properly according to the counter demo.

In this commit, i've continued my task of debuging the code. I made sure that the checkpoints are indeed working properly, so i re-activated the code which implements it.  Part of the state transfer protocol is also working, but I committed it de-activated. I'll resume the debugging tomorrow.

I've resumed my work on the state transfer protocol. However, I'm having trouble getting it to work right. I've de-activated the protocol, in order to safely commit the changes.

I have completed the coding of the state transfer protocol. However, I'm still yet to test the changes made in this commit. Therefore, this is likely to be an unstable version of SMaRt

More work done in the state transfer. It's near the stage where it can deliver the state to the application, and execute the stored batches

More work done related to the state transfer. The replica which requested for the state is starting to process it

Small changes to classes in package statemanagment. Added some test code to methods that I created in tomlayer (currently commented). The client of the counter demo is changed to infinitely send requests.

Previous changes to the message handler were not intended. It were really meant in the execution manager. Fixed.

Within this commit, the code that implements the checkpoints is completed. However, it still needs to be tested.

Isto foi so um teste, para ver se esta tudo ok. Apenas acrescentei um metodo inutil a uma das classes q fiz