MQTT Vs ZeroMQ for IoT

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.

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.

MQTT and ZeroMQ Comparison Summary

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.

The Advantages and Disadvantages of MQTT

MQTT is more of an out of the box solution for IoT than ZeroMQ is. The centralized broker means that IoT services can be made available in a ready-made and portable form:

• The Will messages allow the availability of services to be tracked by applications

• The retained messages provide the last known good value for data streams

One of the greatest attributes of MQTT is the flexibility with which solutions can be created. The publish-subscribe paradigm allows many clients to produce and share information with each other as well as back end systems. Brokers can be chained together, and MQTT gateways connected to cloud services just by mapping the flow of messages through topics. Over the air updates of firmware and configurations can be broadcast to devices.

The inbuilt queueing of MQTT brokers can deal with connection interruptions and provide buffering for constrained devices which don’t have the capacity to do it themselves.

MQTT isn’t necessarily as flexible as ZeroMQ for solutions beyond IoT - if you want a pure peer-to-peer configuration for example.

The Advantages and Disadvantages of ZeroMQ

ZeroMQ is a flexible toolkit which allows the building of many messaging solutions. This is both its strength and weakness for IoT: you can build the equivalent of an MQTT broker and its services with ZeroMQ, but you would have to do that yourself.

Although the ZeroMQ socket types have many helpful features, each type is limited in the behavior it supports, so you may need more than one socket to accomplish what MQTT does with one (see the application above).

ZeroMQ was intended as a peer-to-peer architecture, but as networks and services grow, a central server can provide the abilities to manage that growth. The ZeroMQ Guide contains several examples of solutions which include a central server or proxy.

ZeroMQ security only arrived with version 4.0. It is provided by CurveMQ the library for which was last updated in 2017. This approach seems likely to be less reliable and secure than MQTT’s approach of outsourcing this to TLS standards and components.

ZeroMQ is supported by an active open source community, but commercial support is limited.

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.