MQTT Request-Response Pattern – MQTT 5 Essentials Part 9
Welcome to Part 9 of our MQTT 5 Essentials series. In Part 8, we covered Payload Format Description in MQTT 5. In this article, we spotlight two standout elements: Response Topic and Correlation Data.
Navigating the complexities of modern IoT projects demands teamwork across diverse vendors and teams. As MQTT has become the protocol par excellence for IoT, enhanced interoperability and system transparency emerged as prime requirements in the MQTT version 5 blueprint. The features we’re delving into today answer these user needs by providing a standard solution for implementing a request-response pattern with MQTT.
What is Request-Response Pattern in MQTT?
MQTT is rooted in asynchronous messaging, adopting the publish-subscribe paradigm. This design allows senders and receivers to function independently of one another, facilitating one-to-many relationships. It’s vital to grasp that MQTT’s request-response pattern tackles challenges differently from synchronous, one-to-one-based protocols like HTTP.
In MQTT, a response typically doesn’t directly answer a request’s “question”. Instead, the request triggers a specific action in the receiver, and the response communicates the result of this action.
Sounds complicated? Don’t fret; a concrete example will soon bring this into perspective!
What is Response Topic in MQTT 5?
A response topic is an optional UTF-8 string incorporated into any PUBLISH or CONNECT packet. If a value is present in the response topic, the sender immediately classifies the associated PUBLISH as a request. The response topic field indicates the topics where the message receivers’ responses are expected. The initial PUBLISH (request) and the response topic can have multiple or no subscribers. Ideally, the original PUBLISH (request) sender should subscribe to the response topic before dispatching the request.
What is Correlation Data in MQTT 5?
Correlation data is optional binary data that trails the response topic. It helps the request’s sender identify which specific request a later received response relates to. The correlation data allows the original request sender to manage asynchronous responses potentially sent from multiple receivers. It’s important to note that this data is not relevant to the MQTT broker but serves to identify the relationship between sender and receiver.
What is Response Information in MQTT 5?
To foster transparent implementation and improved standardization, the MQTT 5 specification introduced the Response Information property. Through a boolean field in the CONNECT, a client can request response information from the broker. When set to true, the broker can dispatch an optional UTF-8 String field (response information) in the CONNACK packet to communicate anticipated response topics.
This feature allows users to globally define a specific part of your topic tree on the broker, accessible by all clients indicating their intention to use the request-response pattern at the connection establishment.
End-to-End Acknowledgement in MQTT 5
MQTT ensures the complete decoupling of message senders and receivers. Use cases often call for an acknowledgment of message receipt from the intended recipient. For example, when opening the door of your smart home via a command, the sender (typically a mobile app) would want to know when and if the message was received and the outcome of the command.
Example: Smart door opening with a mobile device using the MQTT 5 Request Response feature.
The inclusion of the request-response pattern in the MQTT 5 specification was largely driven by the need for these “business ACKs.” MQTT users sought the capability to provide end-to-end acknowledgments between an application message’s sender and receiver. Adding response topics, correlation data, and response information as protocol fields significantly bolsters extensibility, dynamism, and transparency in application development using the request-response pattern.
MQTT 3 users previously embraced this pattern. By integrating response topics, correlation data, and response information directly into protocol fields, we’ve significantly enhanced application development’s versatility, dynamism, and transparency under the request-response pattern.
Source Code Example of MQTT Request-Response Workflow
Below is a quick code snippet showcasing the HiveMQ MQTT Client’s capabilities, providing a taste of the request-response pattern workflow in MQTT. Note that it’s not a complete, functioning excerpt.
You can access a full example on GitHub and engage in our HiveMQ Community Forum for any implementation queries.
//Requester subscribes to response topic
Mqtt5SubAck subAck = requester.subscribeWith()
.topicFilter("job/client1234/result")
.send();
//Requester publishes request
Mqtt5PublishResult result = requester.publishWith()
.topic("job")
.correlationData("1234".getBytes())
.responseTopic("job/client1234/result")
.payload(message.getBytes())
.send();
//Responder subscribes to request topic
Mqtt5SubAck subAck = responder.subscribeWith()
.topicFilter("job")
.send();
//Responder sends response after receiving the request
Mqtt5PublishResult result = responder.publishWith()
.topic(publish.getResponseTopic().get())
.payload(msg.getBytes())
.correlationData(publish.getCorrelationData().get())
.send();Key Takeaways from Request-Response in MQTT
Here are a few key takeaways of request-response in MQTT:
The request-response pattern in MQTT significantly differs from its counterpart in synchronous, client-server-based protocols like HTTP.
MQTT allows multiple, single, or even no subscribers for requests and responses.
Correlation data ensures the proper linking between request and response, enhancing message tracking.
This pattern facilitates the implementation of “business acknowledgment” functionality, providing an extensible, dynamic, and transparent solution.
Best Practices to Consider While Using Request-Response in MQTT
Here are a few best practices to consider while using request-response in MQTT:
Ensure the requester subscribes to the relevant response topic before sending a request.
Employ unique identifiers within the response topic to avoid confusion.
Ascertain that responders and requesters possess the necessary permissions to publish and subscribe to response topics.
Dedicate a specific section of the topic tree for response purposes, and utilize the response information field to relay it to clients.
Conclusion
As we journey through the transformative features of MQTT v5, we discover the power of protocol evolution. These enhancements, like the request-response pattern, not only streamline existing practices but also unlock new realms of dynamic, transparent, and extensible application development. Next up in Part 10, we’ll tackle the topic of Topic Alias.
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.
Watch the Video
Chapters
- 00:00 - Introduction
- 00:17 - The Request Response pattern in MQTT
- 01:12 - New Request Response features in MQTT 5
- 02:43 - Use case: door opening for a Smart Home using MQTT5
- 03:31 - Best practices and gotchas of MQTT5
- 04:50 - Conclusion and announcement of part 9: Topic Alias in MQTT5
FAQs on MQTT Request-Response
Florian Raschbichler
Florian serves as the head of the HiveMQ support team with years of first hand experience overcoming challenges in achieving reliable, scalable, and secure IoT messaging for enterprise customers.
