You probably heard about the classic IoT example where someone is returning home and uses the cell phone to turn on the air conditioner remotely to enjoy a more comfortable temperature as soon as that person opens the main door.

That’s a simple example with one request and one response but there are many other situations were we could have many responses to one request.

For example, consider having to manage a fleet of taxis. A customer calls asking for a taxi and you need to know which taxi is available in the neighborhood. It’s possible to implement these patterns with the previous MQTT protocol versions but MQTT 5
formalizes these request/response patterns.

The request/response pattern

One of those clents publishes requests. Let’s call this client Requester. The rest of the clients publish responses and we call these clients Responders. In some situations the request will be responded by one client but in other situations there could be many clients responding a request or none at all.

In the air conditioner example the cell phone used to turn on the heat remotely is the Requester and the computer at home that controls the appliances is the Responder. In the taxi fleet example the computer at the call center is the Requester and the cell phones on each taxi are the Responders.

The MQTT 5 protocol details

Request messages and response messages are published in different topics. The requests are published in the Request Topic and the responses are published in the Response Topic.
The MQTT 5 protocol added a new property called Response Topic to specify which is the topic where the responses should be published. The Requester must be subscribed to the Response Topic before sending any request and it must have privileges to publish messages in the Request Topic.

The Responders must be subscribed to the Request Topic and they must have privileges to publish messages in the Response Topic. Only messages that include a Response Topic property are considered requests. The Responders must not set the Response Topic property.

The MQTT 5 specification also added a Correlation Data property used to know which request message is answering each response message. This is an optional property and its contents are not defined by the specification.

The Response Topic property can have any topic name but brokers may send a Response Information property in the CONNACK packet and the clients can use that information to generate those topic names.
For example, the Response Information property may be a part of the topic tree reserved for responses during a session.
The broker may send the Response Information property when the clients set the new Request Response Information property to true in the CONNECT packet.

TMS MQTT implementation

TMSMQTTClient1.Subscribe('tms/responses');

After that, the Requester will set the Response Topic and the Correlation Data properties:

TMSMQTTClient1.PublishProperties.CorrelationData := 'my_request_id';
TMSMQTTClient1.PublishProperties.ResponseTopic := 'tms/responses';

TMSMQTTClient1.Publish('tms/requests', 'my_custom_request_command');

On the other hand, the Responder connects to the broker and subscribes to the Request Topic:

TMSMQTTClient1.Subscribe('tms/requests');

Then it can use the OnRawPacketReceived event to read the requests like this:

procedure TRespMainForm.TMSMQTTClient1RawPacketReceived(ASender: TObject; const APacket: TTMSMQTTPacket);
var
  LProperties: TTMSMQTTPublishProperties;
  LMessage: string;
begin
  if Assigned(APacket) and (APacket is TTMSMQTTPublishPacket) then
  begin
    LMessage := TEncoding.UTF8.GetString(APacket.GetPayload(True));
    if LMessage = 'my_custom_request_command' then
    begin
      LProperties := TTMSMQTTPublishProperties(APacket.VariableHeader.Properties);
      TMSMQTTClient1.PublishProperties.CorrelationData :=
      TEncoding.UTF8.GetString(LProperties.CorrelationData);
      TMSMQTTClient1.Publish(LProperties.ResponseTopic, 'my_custom_response');
    end;
  end;
end;

References