MQTT vs ZeroMQ for IoT

MQTT vs ZeroMQ for IoT

author portrait

Written by Ian Craggs

Category: MQTT IoT

Published: August 29, 2022

MQTT VS ZeroMQ: Understanding the Differences

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?

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 Client Broker

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:

    • client/server (documented as still in draft)
    • alternative pub/sub (still in draft)
  • ZMQ_(X)PUB or ZMQ_(X)SUB
    • publish/subscribe pair - one to many messaging
    • round robin one-to-one messaging
    • peer to peer inter thread communications
    • A connection to a non 0MQ peer
    • 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:

ZeroMQ Publisher

(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:

ZeroMQ Pub

(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

Full name MQTT (the OASIS standardization group decided it would not stand for anything) ZeroMQ
Architecture Client/server Peer to peer
Command targets Topics ZeroMQ sockets
Underlying Protocol TCP/IP TCP/IP, UDP, shared memory
Secure connections TLS + username/password (SASL support possible) PLAIN (username/password), CurveZMQ and ZAP
Client observability Known connection status (will messages) None
Retained messages Yes No
Messaging Mode Asynchronous, event-based Application dependent
Message queuing The broker can queue messages for disconnected subscribers Some 0MQ socket types have it
Message overhead 2 bytes minimum 2 bytes minimum
Message Size 256MB maximum 2^63-1 bytes per frame
Message fragmentation No Yes
Content type Any (binary) Any
Pub/sub topic matching Level separator: /  Wildcards: + # Prefix only
Message distribution One to many, one to one Various
Reliability Three qualities of service:
  • 0 - fire and forget
  • 1 - at least once
  • 2 - once and only once
Varies between socket types, but the equivalent of QoS 2 would have to be implemented in the application.

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.

ZeroMQ Broker Client

MQTT Bytes ZeroMQ Bytes
Establish connection 166 186 per socket (2 sockets)= 372 total
Subscribe 159 100
For each message published 388 373
Sum for 1 message 1101 1218
Sum for 10 messages 8085 7932
Sum for 100 messages 77925 75072

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.

No. messages Protocol Msgs per second Avg round trip time (ms)
10000 MQTT - QoS 1 1234 0.81
10000 MQTT - QoS 0 18416 0.054
10000 ZeroMQ
15528 0.064

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:

  • will messages allow the availability of services to be tracked by applications
  • 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 which 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:

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

About Ian Craggs

Ian Craggs has worked with MQTT since 2002. He has created MQTT client and server implementations, notably in the Eclipse Paho project. He is secretary of the OASIS MQTT standardization committee and worked on the standardization of MQTT 5.0. He is co-chair of the OASIS MQTT-SN standardization committee, and is also contributing to the standardization of Eclipse Sparkplug.
newer posts Early Access Preview of HiveMQ Enterprise Extension for GCP Pub/Sub Released
MQTT Sparkplug to AWS IoT Sitewise Integration: A Step-By-Step Guide older posts