Client and Server

This section is for those looking to implement their own ABCI Server, perhaps in a new programming language.

You are expected to have read all previous sections of ABCI++ specification, namely Basic Concepts, Methods, Application Requirements, and Expected Behavior.

Message Protocol and Synchrony

The message protocol consists of pairs of requests and responses defined in the protobuf file.

Some messages have no fields, while others may include byte-arrays, strings, integers, or custom protobuf types.

For more details on protobuf, see the documentation.

Server Implementations

To use ABCI in your programming language of choice, there must be an ABCI server in that language. CometBFT supports four implementations of the ABCI server:

• in CometBFT’s repository:
  • In-process
  • ABCI-socket
  • GRPC
• tendermint-rs
• tower-abci

The implementations in CometBFT’s repository can be tested using abci-cli by setting the --abci flag appropriately.

See examples, in various stages of maintenance, in Go, JavaScript, C++, and Java.

In Process

The simplest implementation uses function calls in Golang. This means ABCI applications written in Golang can be linked with CometBFT and run as a single binary.

GRPC

If you are not using Golang, but GRPC is available in your language, this is the easiest approach, though it will have significant performance overhead.

Please check GRPC’s documentation to know to set up the Application as an ABCI GRPC server.

Socket

The CometBFT Socket Protocol is an asynchronous, raw socket server protocol which provides ordered message passing over Unix or TCP sockets. Messages are serialized using Protobuf3 and length-prefixed with an unsigned varint

If gRPC is not available in your language, or you require higher performance, or otherwise enjoy programming, you may implement your own ABCI server using the CometBFT Socket Protocol. The first step is still to auto-generate the relevant data types and codec in your language using protoc, and then you need to ensure you handle the unsigned varint-based message length encoding scheme when reading and writing messages to the socket.

Note that our length prefixing scheme does not apply to gRPC.

Also note that your ABCI server must be able to handle multiple connections, as CometBFT uses four connections.

Client

There are currently two use-cases for an ABCI client. One is testing tools that allow ABCI requests to be sent to the actual application via command line. An example of this is abci-cli, which accepts CLI commands to send corresponding ABCI requests. The other is a consensus engine, such as CometBFT, which makes ABCI requests to the application as prescribed by the consensus algorithm used.