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 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.

3. I try to run BFT-SMaRt but it is not working. I keep receiving messages that it can't connect to replicas, messages about timeout or messages saying that it is forwarding messages 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.

Before starting BFT-SMaRt replicas, be sure that the IP addresses of the replicas is correctly configured in config/hosts.config in all replicas and that each replica has the port defined accepting messages. Keep in mind that you should always use IP addresses instead of hostnames.

Before initializing BFT-SMaRt replicas (not when replicas crash and restart), make sure to delete the file config/currentView. This file is used to keep track of the latest group membership, but when starting the system, it may point to an updated membership.

Clients requests should not be issued before all replicas have been properly initialized. Replicas are ready to process client requests when each one outputs '(DeliveryThread.run) canDeliver released.' in the console., Moreover, always make sure that each client uses an unique ID. Otherwise, clients may not be able to complete their operations due to conflicting IDs in the system.

Finally, if you are getting timeout messages it is possible that the application you are running takes too long to process the requests or the network delay is too high and propose messages from the leader don't arrive in time, so replicas may start the leader change protocol. To prevent that, try to increase the system.totalordermulticast.timeout parameter in config/system.config.

4. 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. I found a bug in BFT-SMaRt. Is there a way to open a ticket or submit a patch proposal?

You can post your findings github's issue tracker or email us. We will reply as soon as possible.

7. Should I start all replicas before accepting client's requests?

The BFT-SMaRt protocol works with the assumption of 3f-1 replicas, where f is the number of faulty replicas. Considering that, for f equals 1, only three replicas are required for the protocol to work. For f equals 2, five replicas are needed and so on. Remember that, having only the necessary replicas running, the system cannot tolerate any additional faults, since replicas that are still obtaining their state are considered faulty until they fetch and install such state.

8. 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.