FAQ

In this page we list and answer common questions that new users asks when running BFT-SMaRt for the first times.

1. I have download BFT-SMaRt from the project's page. What's next? How can I use it? Is there an example?

BFT-SMaRt code comes with several demonstration examples. This page has a description of some of these demos and how to run them. You can also check out our tutorial.

2. How many replicas do I need to keep my service working?

The BFT-SMaRt protocol works with the assumption that the system is comprised by at least 3f+1 replicas, where f is the number of replicas that can be faulty. Replicas that do not fail are said to be correct. Considering that, for f = 1, only three correct replicas (out of a total of 4) are required for the protocol to make progress. If f = 2, 5 correct replicas are needed and so on. Moreover, having only the correct replicas executing, the system will not tolerate any more faults.

3. How can I extend BFT-SMaRt to replicate the business logic for my application?

The class bftsmart.tom.ServiceProxy provides the methods for clients to send requests and receive responses from BFT-SMaRt. In the server side, there are many interfaces in the package bftsmart.tom.server to be implemented depending on the behavior desired by the user. The main ones are Executable and Recoverable, to implement the processing of requests from the application and state management, respectively. You can save some time and effort by using our "off-the-shelf" implementations, by extending classes from package bftsmart.tom.server.defaultservices. Abstract class DefaultRecoverable offers the most stable implementation.

4. I try to run BFT-SMaRt but it is not working. I keep getting messages claiming that a replica cannot connect to the others, messages about timeout or messages being forwarded to some replica. Am I doing something wrong?

BFT-SMaRt is a replication protocol comprised of several pieces like state transfer, leader change and reconfiguration. Because of those small details, there is a lot of configuration parameters and options to "tune up" BFT-SMaRt to the needs of the application being replicated. However, there are some common practices to make BFT-SMaRt work as expected for most of the cases. Read our deployment guidelines to learn what these practices are.

5. When I force a replica to crash, re-start it and kill another replica, the protocol stops working. What is wrong?

The state transfer protocol has several steps and takes some time until a replica is considered recovered. In the case above, we consider that the number of faults tolerated is one, so, we can't have any other fault until the replica is recovered. To test it properly, the first replica has to be killed and re-started so that the state transfer is trigered. The replica will ask the state for the other replicas, receive it, install it and, only after that it will start processing the requests that were added to its queue while the state was being installed. It may take some time to synchronize the processing with the other replicas. The replica is considered to be recovered after it finishes installing its state. Only then the protocol can tolerate faults in another replica.

6. How can I change the leader in BFT-SMaRt?

The leader of the protocol is not chosen by the client or the anyone that administer the system. The protocol votes for new leader if a request timeout is triggered, be it because the leader stops behaving as expected, networks delays or more requests queued than the system is able to process.

7. I found a bug in BFT-SMaRt. What do I do?

You can report problems at the issue tracker of this repository or contact us.