HiveMQ is an MQTT-based messaging platform designed to power IoT applications. Recently released HiveMQ 4 adds support for MQTT 5, improves its extension system, and integrates better with Docker and Kubernetes, and AWS EC2.
HiveMQ 4 supports all new MQTT 5 features, including user properties, negative acknowledgement, and topic aliases and strives to enable MQTT 3 and MQTT 5 clients to communicate transparently. Additionally, HiveMQ 4 introduces a new extension system aimed to ease integration with enterprise systems.
Message Queuing Telemetry Transport (MQTT) is an ISO-standard communication protocol for IoT applications. It defines a publish-subscribe protocol supporting one-to-many communication between devices. MQTT clients can publish messages and/or subscribe for notifications of new messages through a broker service.
InfoQ has taken the chance to speak with dc-square CTO, Dominik Obermaier.
InfoQ: Could you briefly explain what value MQTT 5 brings to IoT applications? In what ways is it an improvement over MQTT 3?
Dominik Obermaier: MQTT was first developed in 1999 and the MQTT 3.1 specification was made available in 2010. A lot has changed since 2010, especially in the area of cloud computing and large scale systems development. MQTT has also become a lot more popular, so it was time for an update to the specification. Some of the key goals for MQTT 5 were:
Make it easier to host large-scale systems in a scalable and reliable manner.
Improved error reporting so the overall applications can be more resilient.
Make it possible to add user properties to MQTT messages, and Improve performance and support for small clients.
If I had to summarize, MQTT 5 is about making MQTT more scalable and reliable for cloud native applications. While a single HiveMQ deployment with MQTT 3.1 already supported up to 10,000,000 concurrent MQTT connections with more than 1,000,000 messages per second for data exchange, MQTT 5 is the foundation to scaling to even larger numbers.
InfoQ: The arena of MQTT implementations is quite crowded and highly competitive. How does HiveMQ try to stand out among its competitors?
Obermaier: It has been really great to see MQTT become such a popular IoT standard. Lots of IoT platform vendors include MQTT support as one of their supported protocols. However, for HiveMQ, MQTT is at the core of our platform; it is not an add-on. We believe MQTT is the best protocol for moving data between connected devices and cloud platforms.
Some of the things we do better are:
HiveMQ can scale to 10 million connections. At runtime, the HiveMQ broker can scale up and down through our automatic elastic clustering and supports state-of-the-art technology like Docker with Kubernetes, Openshift and DC/OS as the operation environment.
HiveMQ is more resilient to cluster node failures. HiveMQ creates a pool of device sessions that are independent of cluster nodes. This means if a cluster node fails, all the the MQTT clients can just resume their session on another node without any knowledge of the underlying infrastructure. This is really important if your IoT connected device needs to have a very responsive user experience and requires an always-on experience for the end user.
HiveMQ 4 introduces a new extension framework to make it a lot easier for integrating HiveMQ and MQTT messages into different back-end systems. For instance, we have integrations with InfluxDB and Prometheus to make it easier to monitor MQTT message data. Our customers also use the extension framework to integrate their (often proprietary) security systems with HiveMQ.
We have spent a lot of time building the management and troubleshooting tools that companies need to deploy an MQTT based system. For instance, with HiveMQ it is possible to setup a real-time trace recording to record the interactions between MQTT clients and the broker. This allows the operations team to identify bottlenecks and issues with a deployed system and enables support teams to help end users who are experiencing issues with their connectivity.
Finally, HiveMQ is 100% MQTT compliant. You can use any MQTT compliant client, like Eclipse Paho, to connect with the HiveMQ broker. Some of the other vendors require customers to use their own client SDK since they aren’t 100% compliant. We have more than 110 customers worldwide who require a 100% standards based communication in order to avoid vendor lock-ins.
InfoQ: MQTT is an ISO standard but far from being the only protocol existing in the IoT arena. Could you explain in which scenarios MQTT provides the best value, in comparison with other widely used IoT communication protocols?
Obermaier: You are correct, there are lots of protocols and in fact HTTP is often used for IoT solutions. There are a number of scenarios where we see developers benefiting from MQTT:
If you are building a connected product that can’t rely upon having a consistent network connection. For instance, a car sharing app that needs to work if the network connection is dropped and then reconnected when the car goes through a tunnel. MQTT allows for the session connection to persist between the client and the broker.
If you are building an IoT application that needs to be very efficient with network bandwidth, for instance work over GSM/3G. MQTT messages are very small and the pub/sub protocol make MQTT less chatty than something like HTTP or a verbose XML based protocols like XMPP. MQTT was initially designed in 1999 for oil and gas industry to monitor pipelines. They needed a protocol that was efficient for the network and power, which is exactly the key challenges today for IoT products.
I think the key technical differences that make MQTT popular for IoT are:
It is lightweight and easy to learn and use (compared to some other, heavy-weight protocols like AMQP).
The publish/subscribe protocol is well suited for large scale deployments of connected devices.
It works over TCP/IP so it is firewall-friendly and easy to set-up in a data center or cloud platform.
All connection attempts are initiated by the client and a MQTT client is never addressable over the Internet, which is a huge security feature. Compared to other protocols like CoAP, MQTT does not open an attack vector on the client side for Denial of Service attacks, so MQTT is secure by design.
InfoQ: One of the biggest concerns in IoT applications is security. How do MQTT 5 and HiveMQ 4 perform in this respect? What is still requiring improvements in your opinion, to make IoT devices secure?
Obermaier: Security is by far one of the most important challenges for all IoT deployments. The good news is: MQTT 5 is secure by design. Due to the Publish/Subscribe architecture, all connectivity is initiated by the client. A MQTT broker never establishes a connection itself to any of the clients. So it’s not possible for an attacker to get access to devices since MQTT clients are not addressable over the Internet.
For advanced application layer security, MQTT 5 also introduced the AUTH protocol packet, which allows challenge/response protocols (like Kerberos, SCRAM or other SASL framework protocols) to be used for authentication and authorization. Of course, classic token- or credentials based authentication mechanisms (like OAuth 2.0 or good ol’ username/password authentication) are still supported by MQTT.
One important lesson the IT industry has learned over the years when it comes to security is: don’t reinvent the wheel yourself! This is why MQTT uses TLS (preferably 1.2 or the brand new 1.3 version) for encrypted communication between clients and broker. This is the foundation for our secure Internet today and is the same method HTTP and other Internet protocols like SMTP and FTP use for creating encrypted communication channels.
HiveMQ 4 implements all the security mechanisms discussed above. With the flexible extension system, it’s possible to plug-in your OAuth 2.0 server, LDAP or device management database via pre-built extensions. The broker offers advanced permission management, so you can restrict what data is allowed to be published or subscribed by individual clients or groups of clients. Since HiveMQ is often deployed in corporate environments with enterprise systems, advanced security mechanisms like OCSP stapling or PKI integration are included out-of-the-box.
InfoQ: How do you see the evolution of IoT communication protocols? Are they going to converge towards one common standard? What in particular do you envision in MQTT's future?
Obermaier: There will always be different IoT communication protocols since there are many different types of IoT use cases. I don’t see one common standard ever emerging. However, if you look at recent survey data, it seems MQTT and HTTP are going to be the dominant standard. We also see this at our customer deployments.
For MQTT in the future, I think the adoption of MQTT as the communication protocol for edge computing will be interesting to watch. This will especially be important when edge nodes communicate with each other, forming a network mesh. MQTT-SN is a potential solution for mesh networks that I think will be adopted in the next number of years.
It’s clear that MQTT is here to stay, and from my point of view, the adoption will continue to increase in the future, especially for professional, large-scale deployments.
