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

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

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) Retained messages 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 Content type Any (binary) 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.

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)

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

By clicking the subscribe button, you give your consent to the use of your data according to our Privacy Policy . You can withdraw your consent at any time with future effect.

By clicking the subscribe button you give your consent to the use of your data according to our Privacy Policy . You can withdraw your consent at any time with future effect.