MQTT vs ZeroMQ for IoT
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.
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
- peer to peer inter thread communications
- 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 (the OASIS standardization group decided it would not stand for anything)
|Peer to peer
|TCP/IP, UDP, shared memory
|TLS + username/password (SASL support possible)
|PLAIN (username/password), CurveZMQ and ZAP
|Known connection status (will messages)
|The broker can queue messages for disconnected subscribers
|Some 0MQ socket types have it
|2 bytes minimum
|2 bytes minimum
|2^63-1 bytes per frame
|Pub/sub topic matching
|Level separator: / Wildcards: + #
|One to many, one to one
|Three qualities of service:
|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.
|186 per socket (2 sockets)= 372 total
|For each message published
|Sum for 1 message
|Sum for 10 messages
|Sum for 100 messages
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.
|Msgs per second
|Avg round trip time (ms)
|MQTT - QoS 1
|MQTT - QoS 0
ZMQ_PULL/PUSH + ZMQ_PUB/SUB
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:
- 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.
Check out the video below that provides the summary of this blog
About Ian Craggs
Ian Craggs works for IBM, and has been involved with MQTT for more than 10 years. He wrote the IBM MQTT server Really Small Message Broker which became the inspiration for the Eclipse Mosquitto project. He contributed C client libraries to the Eclipse Paho project at its onset and is now the project leader.Contact HiveMQ