MQTT Vs ZeroMQ for IoT

MQTT is a lightweight, publish-subscribe protocol ideal for IoT use cases where reliability, low bandwidth, and message delivery guarantees (QoS) are crucial, whereas ZeroMQ is a messaging library designed for complex, low-latency distributed systems but lacks built-in message persistence, delivery guarantees, or pub-sub semantics out of the box.

Now, let’s dive deeper into the difference between MQTT and ZeroMQ.

Understanding the Difference Between MQTT and ZeroMQ

MQTT is a client-server protocol that was designed for the Internet of Things (although it wasn’t called that at the time). The MQTT server, or broker, allows inspection and management of the connected IoT devices and messages, and provides services shared among them, such as retained messages. There are many client libraries and brokers available: free, open source and commercially supported.

ZeroMQ, or 0MQ, is primarily an open-source messaging library, where the Zero stands for zero broker, zero cost, and zero administration. ZeroMQ does define a wire protocol but the API is the main way to use it. It’s supported by an open source community. ZeroMQ was originally designed as a mechanism for distributing messages to many targets as quickly as possible - one way and unreliably. Since then, it has developed to provide general messaging capabilities.

MQTT requires TCP/IP, whereas ZeroMQ can use a number of underlying transports, including UDP and shared memory. But still for ZeroMQ, TCP/IP is the primary transport used for inter-machine communication.

The ZeroMQ API looks a little like the TCP/IP socket API supporting several messaging styles: request/reply, multicast distribution, publish/subscribe and more. MQTT is focussed on publish/subscribe (MQTT 5.0 has request/reply too), and provides features that would have to be built on top of ZeroMQ, such as reliable publish/subscribe messaging.

What is MQTT Protocol for IoT?

MQTT is a communication protocol with features specifically targeted at IoT solutions:

• Uses TCP connections, for reliability (assured delivery and packet error checking), fragmentation and ordering.

• Aims to minimize data overhead of each MQTT packet.

• The last known good data value for a device can be stored (retained messages).

• Notifications when client unexpectedly disconnects (will message) to allow client state to be monitored.

• Bi-directional message flow - data from and commands to devices can use the same TCP connection.

• Publish subscribe routing, which allows the easy addition of more consumers and producers of data.

MQTT Publish / Subscribe Architecture

The MQTT commands are CONNECT, SUBSCRIBE, PUBLISH, UNSUBSCRIBE and DISCONNECT. Topics are the medium of distribution, to which clients can PUBLISH and SUBSCRIBE. All authorized subscribers to a topic will receive all messages published to the topic. MQTT topics do not have to be pre-defined: client applications can create them simply by publishing or subscribing to them.

The Advantages and Disadvantages of MQTT

MQTT offers several key benefits:

1. Lightweight and efficient: Requires minimal device resources and network bandwidth

2. Bidirectional communication: Enables communication between devices and servers, supporting publishing and subscribing. It also allows broadcasting messages to groups of devices

3. Scalability: Supports millions of connected devices in IoT/IIoT systems

4. Flexible, dynamic topics: Supports millions of hierarchically structured topics, enabling efficient and precise communication through flexible topic-based filtering

5. Quality of Service (QoS) levels: Ensures reliable message delivery

6. Persistent sessions: Reduces reconnection time over unreliable networks

7. Security: For authentication, MQTT supports username and password verification, while advanced authentication and authorization mechanisms can be implemented using broker-specific extensions, for example, HiveMQ’s Enterprise Security Extension (ESE).

While MQTT is lightweight and efficient, its performance and security can vary greatly depending on the broker used. Some brokers may lack the scalability, observability, or enterprise-grade security features needed for critical applications. Today, MQTT brokers like HiveMQ address these limitations with robust support for scalability, flexibility, reliability, observability, and security.

What is ZeroMQ?

ZeroMQ is an application library that was designed to distribute messages as fast as possible in a financial environment - price updates, alerts and so on. It was conceived, and still largely operates, on a peer-to-peer basis, which means that each ZeroMQ node has access to the same capabilities as any other. A ZeroMQ application can still be asymmetrical, where one application can be a publisher and the other a subscriber for instance, but that is up to the applications and agreed between them. ZeroMQ presents an API that looks somewhat like TCP/IP sockets. To connect two applications, one application calls zmq_bind() to become a server on a well-known network address and port, and the other connects to it with zmq_connect(). To create the 0MQ sockets on which these APIs operate, zmq_socket() is called. At 0MQ socket creation time, the type of the socket is set, which can be one of the following:

• ZMQ_CLIENT or ZMQ_SERVER

  • client/server (documented as still in draft)

• ZMQ_RADIO or ZMQ_DISH

  • alternative pub/sub (still in draft)

• ZMQ_(X)PUB or ZMQ_(X)SUB

  • publish/subscribe pair - one to many messaging

• ZMQ_PULL or ZMQ_PUSH

  • round robin one-to-one messaging

• ZMQ_PAIR

  • peer to peer inter thread communications

• ZMQ_STREAM

  • A connection to a non 0MQ peer

• ZMQ_REQ or ZMQ_REP and ZMQ_DEALER, ZMQ_ROUTER

  • request response pair, round robin requests

The socket types can only be used with a socket of a matching type - generally those in the same group in the above list. Some of the socket types have inbuilt message queueing, some don’t. For instance, the ZMQ_PUB socket type, the publisher, will silently drop any messages that can’t be delivered, similar to an MQTT QoS of 0. The ZMQ_SUB subscriber socket type will queue incoming messages up to a defined high-water mark. This is an example of a small scale Pub-Sub network from the ZeroMQ guide:

(Image copyright (c) 2010-2012 Pieter Hintjens)

Interestingly, as ZeroMQ is considered brokerless, a number of the solutions do introduce a central node of one kind or another, such as this to help with discovery of publishers and subscribers:

(Image copyright (c) 2010-2012 Pieter Hintjens)

In these cases the central node takes on the roles that are served by the broker in MQTT. For more examples see the ZeroMQ Guide.

The Advantages and Disadvantages of ZeroMQ Compared to MQTT

ZeroMQ can be effectively used as a message queue to store messages in a FIFO order. Here are some benefits of using ZeroMQ as a message queue:

• Low Latency: Suitable for real-time applications where quick message delivery is essential.

• Scalability: Can handle a large number of clients and messages

• Flexibility: ZeroMQ supports multiple messaging patterns, allowing it to be used in a wide range of use cases.

ZeroMQ is a flexible messaging toolkit that allows developers to build custom solutions, including MQTT-like brokers and services. However, this flexibility comes with complexity—developers must implement many features themselves, from message routing to session management. In contrast, MQTT brokers like HiveMQ provide these capabilities natively, with built-in support for scalability, reliability, security, and observability.

While ZeroMQ offers multiple socket types for different messaging patterns, replicating MQTT’s pub/sub behavior often requires combining several of these, increasing development effort. Additionally, ZeroMQ’s peer-to-peer model can become difficult to scale without introducing central components, which MQTT brokers handle seamlessly by design.

Security in ZeroMQ, introduced with CurveMQ in version 4.0, has seen limited updates, and may not match the robustness of MQTT’s reliance on widely adopted TLS standards. And while ZeroMQ benefits from a strong open-source community, commercial support remains limited—unlike MQTT solutions like HiveMQ, which offer enterprise-grade support and SLAs.

MQTT Performance Vs. ZeroMQ Performance

These are the approximate TCP/IP packet sizes measured with Wireshark for MQTT and ZeroMQ. Two sockets each are used for the ZeroMQ “client” and “broker” applications, one PUSH/PULL pair to send the publish request to the broker, and a PUB/SUB pair to implement the publish/subscribe operations.

The following throughput figure for ZeroMQ was measured with the same configuration as above. For MQTT these figures were obtained with a local HiveMQ broker, using a round-trip scenario (one message received on a subscription for each message published). In both cases, the client application waited for the response before sending the next. All messages were 256 bytes.

All these measurements are very similar in outcome, but a very simple scenario is used. This is not a comprehensive performance comparison.

Conclusion: MQTT Vs. ZeroMQ - Which is Better for IoT?

As MQTT was designed for IoT solutions it is much quicker to get started than ZeroMQ. MQTT features that are provided out of the box, including reliability, would have to be re-engineered in ZeroMQ and would take significant effort. MQTT cloud services and brokers are available, making the process of building IoT solutions very quick.

ZeroMQ could be suitable for an edge of network on-premises high-speed network which connects to an MQTT broker for IoT services, but not as a complete IoT solution on its own.

If you want to know more about what MQTT can offer you then check out these resources:

• MQTT Essentials

• HiveMQ’s open-source software

• HiveMQ’s public MQTT broker

• Other MQTT client libraries

• MQTT 5 Essentials (the latest version of MQTT)

For IoT purposes, you’ll find that MQTT does much more than ZeroMQ, and it’s not difficult to get started.

Additional Reading

1. Read the blog MQTT Vs. HTTP for IoT to learn the differences between MQTT and HTTP protocol or if you are contemplating using MQTT or HTTP for your use case.

2. Read the blog MQTT Vs. AMQP for IoT to learn the differences between MQTT and AMQP protocol.

3. Read the blog MQTT Vs. CoAP for IoT to learn the differences between MQTT and CoAP protocol.

4. Read the blog Transferring Data from Modbus to MQTT Broker for Advanced IIoT Data Use Cases to learn the differences between MQTT and Modbus TCP.