MQTT 5’s Improved Client Feedback & Negative ACKs – MQTT 5 Essentials Part 5

Welcome to Part 5 of our MQTT 5 Essentials series. In Part 4, we delved into MQTT session expiry and message expiry. We shed light on how these features bolster message management and efficiency in IoT applications, making MQTT 5 more dynamic and effective. In this article, we focus on MQTT 5’s Enhanced Client Feedback and Negative ACKs(NACKs). We will dissect this method that MQTT 5 implements for brokers to acknowledge clients, examining their potential to simplify the work of developers and operations teams, and making the protocol more robust and efficient.

Who Needs More Client Feedback While Using MQTT?

Over the years, MQTT has become a staple in numerous IoT projects. As noted in this series, the OASIS committee thoroughly considered the feedback from actual protocol users while crafting the new MQTT 5 protocol standard. Among the predominant grievances was a glaring lack of transparency, primarily due to the insufficient return codes and limited means to communicate specific limitations or circumstances from the broker to the client. This deficiency resulted in increased debugging complexity, particularly in multi-vendor projects.

Whether it’s delving into the causes of client disconnects, examining why messages fail to reach their designated targets, or guaranteeing consistency in MQTT client deployments across various teams, MQTT 3 users often find the need to augment the basic protocol features with technology, such as the HiveMQ Extension SDK. MQTT 5 has been deliberately designed to address these challenges more efficiently and in a standardized manner by introducing the following features.

MQTT 5’s Specific Feature Set

Let’s focus on several MQTT 5 features that provide more transparency and allow centralized system control by virtue of the broker.

Feedback on Connection Establishment in MQTT 5

With MQTT version 5, it is now possible for MQTT brokers to give additional feedback to MQTT clients on connection establishment. A number of different properties can be added to the connection acknowledgment packet that tells the client which features the broker supports or the client is allowed to use. This includes the following MQTT features:

• Retained messages

• Wildcard subscriptions

• Subscription identifiers

• Shared subscriptions

• Topic aliases

• Maximum quality of service level the client can use

In addition to notifying the client about enabled and disabled features, the new properties in the CONNACK packet also allow the server to give the client feedback on the limits granted to it by the broker. These limits include:

• Keep alive

• Session expiry interval

• Maximum packet size

• Maximum number of topic aliases the client can send

Beyond supporting all of these limits, HiveMQ allows you to configure a maximum for the limits and to disable MQTT features that not needed in your use case.

Better Reason Codes in MQTT 5

In previous iterations, namely MQTT version 3.1 and 3.1.1, the assortment of available reason codes was somewhat limited, with only five codes pertaining to unsuccessful operations. However, MQTT 5 substantially enhances this aspect, offering an expanded set of over 20 reason codes dedicated to unsuccessful scenarios.

Moreover, MQTT 5 introduces the possibility of integrating reason codes into packets that previously lacked this attribute in versions 3.1 and 3.1.1. These packets include UNSUBACK, PUBACK, PUBREC, PUBREL, DISCONNECT, and PUBCOMP. This enhancement further strengthens the protocol’s transparency and troubleshooting efficiency, illustrating the forward strides made in MQTT 5.

Enhancing Clarity with Contextual Reason Strings in MQTT 5

While adding additional reason codes certainly bolsters the feedback quality to clients, these codes often fall short in providing specific contexts. This is where MQTT 5 introduces the concept of ‘reason strings’ to bridge the gap, described in the specifications as, “… a human readable string designed for diagnostics …"

Reason strings offer a comprehensive context that developers and operation teams need to swiftly pinpoint the cause of an event. In essence, a reason string is a human-readable string meticulously designed for diagnostic purposes. This valuable tool aids in understanding the nuances of events in a way that reason codes alone can’t provide.

However, it’s worth noting that reason strings, despite their usefulness in development and diagnostics, can be deactivated within HiveMQ’s configuration. This flexibility caters to scenarios where the exposure of such detailed information might not be preferred.

Server-Sent Disconnect Packets in MQTT 5

In MQTT 3.1 and 3.1.1, when a client surpasses a broker-defined limit, the broker responds by abruptly closing the client’s connection. However, this action doesn’t provide any direct insight to the client regarding the reason for the connection termination, which can lead to confusion and troubleshooting difficulties.

In contrast, MQTT 5 significantly improves this process by introducing server-sent disconnect packets. These allow the broker to deliver a DISCONNECT packet to the client before terminating the connection. Each server-sent disconnect packet includes a reason code and a corresponding reason string. These two elements work together to give the client a comprehensive understanding of why the connection was severed.

This streamlined method of connection termination not only adds clarity for the client but also substantially simplifies pinpointing the reason behind a broker-initiated connection closure. This significant enhancement in MQTT 5 dramatically improves the communication transparency between broker and client.

What are Negative Acknowledgements in MQTT 5

In MQTT 5, the communication mechanisms have been greatly improved with the addition of negative acknowledgments. Multiple packet types and message flows can now respond with a negative acknowledgment message, enhancing the messaging infrastructure’s overall feedback loop.

Contrasting with MQTT 3, where the UNSUBACK packet sent to the client lacked a payload, leaving the client uninformed in case of an unsuccessful UNSUBSCRIBE attempt, MQTT 5 fundamentally changes this. The UNSUBACK packet in MQTT 5 includes a reason code informing the client about its UNSUBSCRIBE attempt’s status, providing clear and actionable feedback. Several potential failure reasons are enumerated, such as the nonexistence of the initial subscription or a lack of client authorization to unsubscribe.

Acknowledgment packets from the publish flow, specifically PUBACK, PUBREL, PUBREC, and PUBCOMP, have also been enhanced with the ability to send a negative acknowledgment message. This ability is crucial when the server cannot process a message sent by the client, for example, due to the client not having the required authorization to publish on a certain topic. The enhanced ack packet now equips the client with all the necessary information to adapt and rectify the situation, reducing the need to contact operations or support teams to understand the issue. This marks a significant leap forward in maintaining efficient and smooth communication within MQTT 5 applications.

Exceeding the maxPacketSize is one of the new reason codes for negative acknowledgments.

MQTT 5: Refining MQTT Communication

• MQTT brokers such as HiveMQ let you set a server side max value configuration for the mentioned limits. This is extremely useful in multi-vendor projects in which the operator of the broker may not have control over the settings of the MQTT clients.

• The improved feedback for client significantly simplifies diagnosis for development and operations.

• The added transparency also improves the interoperability between different MQTT clients and brokers.

Learn More About MQTT 5

MQTT brokers, like HiveMQ, offer the advantage of allowing server side max value configuration for maximum values pertaining to the mentioned limits. This feature is particularly valuable in multi-vendor projects where the broker operator may not have direct control over the settings of MQTT clients.

Notably, the advancements in feedback for clients substantially streamline the diagnostic process for both development and operations teams. This enhanced feedback mechanism resolves issues faster and prevents potential bottlenecks in your MQTT systems.

Moreover, the transparency introduced with these improvements fosters better interoperability between different MQTT clients and brokers. This attribute is fundamental in creating robust and versatile IoT ecosystems, and it further emphasizes the strides MQTT 5 has made toward enhancing communication, debugging, and overall system control.

We’ll be moving on to Part 6 of this enlightening series, where we will delve into the topic of User Properties. Do check out our next article.

Sign up for our newsletter to get regular updates. Subscribe to our RSS feed here to stay updated. We encourage you to visit our MQTT Glossary for an in-depth understanding of the essential MQTT terminologies. It will equip you with the necessary vocabulary to grasp the complexities of MQTT and its various versions. Watch the video below that complements the concepts discussed in this article.