OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (MQTT-312) Propose non-normative text for how clients effect a request/reply interaction in MQTTv5

     [ https://issues.oasis-open.org/browse/MQTT-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-312:

4.10 Request / Reply Message Exchange
A Client sends a Request Message by publishing an Application Message which has a Reply Topic Property as described om section  The Request optionally include a Correlation Data Property as described in section
4.10.1 Basic Request Reply (non-normative)
In the request/reply interaction, one MQTT Client, the Requester, publishes a Request Message to a topic.  An Application Message with a Reply Topic is a Request Message.  Another MQTT Client (the Responder) has subscribed to this topic and receives the Request Message.  There may be multiple Responders subscribed to the topic or there may be none.  The Responder takes the appropriate action based on the Request Message, and then publishes a Response Message to the Reply Topic.  The Requestor commonly subscribes to the Reply Topic and thereby receives the Response.  However, some other Client might be subscribed to the Reply Topic and the Response will be received and processed by that Client.  As with the Request Message, the topic on which the Response is sent may be subscribed by multiple Clients, or by none.

If the Request Message contains a Correlation Data Property, the Responder copies it to the Response Message and this is used by the receiver of the Response Message to associate the Response Message with the Request Message.  The Response Message does not include the Reply Topic Property.

The Server is forwards the Reply Topic and Correlation Data Properties in the Request Message, and the Correlation Data in the Reply Message. The Server treats the Request Message and the Response Message like any other Application Message.

The Requestor normally subscribes to the Reply Topic before publishing a Request Message.  If there are no subscribers to the Reply Topic when the Response Message is sent, the Response Message will not be delivered to any Client.

The Request Message and Response Message can be of any QoS, and the subscription can be in a session with a non-zero Session Expiry Interval.  It is common to send Request Messages at QoS=0 and only when the Responder is expected to be connected.  However this is not required.

The Responder can use a Shared Subscription to allow for a pool of responding Clients.  Note however that when using Shared Subscriptions that the order of message delivery is not guaranteed between multiple Clients.

It is the responsibility of the Requestor to make sure it has the necessary authority to publish to the request topic, and to subscribe to the Reply Topic.  It is the responsibility of the Responder to make sure it has the authority to subscribe to the request topic and publish to the Reply Topic.  While topic authorization is outside of this specification, it is recommended that Servers implement such authorization.  

4.10.2 Determining a Reply Topic Value (non normative)
Requesters can determine a Reply Topic to use in any manner they choose including local configuration. In many cases it is desirable that the Reply Topic used by a Client be unique to that Client. As the Requestor and Responder commonly need to be authorized to these topics, it can be an authorization problem to use randomized topic name.

This specification defines a mechanism to aid the Client to determine the Reply Topic to use. This mechanism is optional for both the Client and the Server. At connect time, the Client requests that the Server send a Reply Info Property by setting the Request Reply Info Property in the CONNECT Packet.  The Reply Info Property is a UTF-8 encoded string sent in the CONNACK Packet.  This specification does not define the contents of that string.:

A common use of this is to pass a globally unique portion of the topic tree which is reserved for this Client for at least the lifetime of its Session.  It is normal to use this as the root of a topic tree for a particular client.  For the Server to return this information, it normally needs to be correctly configured.  Using this mechanism allows this configuration to be done once in the Server rather than in each Client.

Refer to section for the definition of the Reply Info Property.

> Propose non-normative text for how clients effect a request/reply interaction in MQTTv5
> ---------------------------------------------------------------------------------------
>                 Key: MQTT-312
>                 URL: https://issues.oasis-open.org/browse/MQTT-312
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: core
>    Affects Versions: 5
>            Reporter: Shawn McAllister
>            Assignee: Shawn McAllister
>             Fix For: 5
> Related to the jira MQTT-197, this jira is to propose non-normative text to the editors for inclusion into v5 of the specification on how clients are to effect a request/reply interaction with the new protocol components that have been added to v5.

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]