PIP-35: Comparison of communication protocols
| Authors | Muhammad Javad Akbarian (@akbariandev) |
|---|---|
| Discussion | View Discussion PIP-35 |
| Category | Informational |
| Created | 2024-11-14 |
Table of Contents
Abstract
This proposal shows the compare list between some communication protocols to use in Pactus blockchain notification service. The important thing is that this protocol must support PUB/SUB pattern.
Motivation
Using a stable bidirectional communication protocol is an important part of Pactus blockchain. The purpose of using this protocol is to cover the event streaming and PUB/SUB messaging between nodes and clients. To have this ability we need to know the difference between each protocol and frameworks and select the best one.
Specifications
Here we compared 9 protocols in terms of simplicity, using broker, resource consumption, community size and implementation libraries.
Compare list
| Protocol | Simplicity | Community | Implementation | Resource Consumption | Using Broker |
|---|---|---|---|---|---|
| MQTT | Simple | Large | Eclipse Paho MQTT | Low (designed for lightweight devices) | YES |
| AMQP | Moderate | Moderate | RabbitMQ Go Client | Moderate (runs a broker, can be optimized) | YES |
| XMPP | Complex | Large | Go XMPP | Moderate (similar to AMQP) | YES |
| NATS | Simple | Growing | NATS Go Client | Low (lightweight and efficient) | YES |
| Apache Kafka | Complex | Large | sarama | High (more robust features, higher overhead) | YES |
| Apache Pulsar | Moderate | Growing | - | Moderate to High (depending on usage) | YES |
| ZeroMQ | Moderate | Moderate | zmq4 | Low to Moderate (depends on pattern) | NO |
| CoAP | Simple | Small | Go-CoAP | Low (optimized for constrained devices) | NO |
| Nanomsg | Simple | Moderate | mangos | Low to Moderate (simple API, lightweight) | NO |
Simplicity & Implementation
In terms of simplicity Nonomsg, MQTT, NATS and CoAP are completely simple. They have few keywords, methods and simple structure to use. After that to ensure about good implementation, we need to have a stable and reliable libraries. The NATS supports lots of languages (see this link) and also MQTT have a complete list of languages to support (see here). in other side, Nanomsg and ZeroMQ have good resources but not much enough as NATS and MQTT. And finally we may have difficult path to implement CoAP since it has less supported languages. Other protocols like Apache Kafka, XMPP,… are not so simple to use. So we don’t compare them in terms of other parameters.
Broker
The broker is a centralized handler with a specific queue that will add more reliability and scalability to protocols. But in our case the broker may need extra works for implementation and deployment. The broker is an independent part of each protocol and this may considered as negative point for us. As you can see in above list only ZeroMQ, CoAP and Nanomsg are free of broker and this may be an important parameter to select them for Pactus project.
Resource Consumption
To be aware of huge resource consumption, we can think about NATS, MQTT, ZeroMQ, CoAP and Nanomsg. But after involving other parameters (simplicity, broker,…) we can only talk about ZeroMQ and Nanomsg. Both of these protocols are cautious to use resources and never make big concerns around this host resources.
Conclusion
As we need to support PUB/SUB patterns in a simple way without using broker, we can select Nanomsg or ZeroMQ. Both used in big projects and have good support on implementation. We must mention that other solutions are enough good to use in other cases but in this case we must completely focus on ZeroMQ or Nanomsg.
Copyright
Copyright and related rights waived via CC0.