[OASIS Issue Tracker] (MQTT-197) Support request/reply as a new MEP

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62313#comment-62313 ] 

Shawn McAllister commented on MQTT-197:
---------------------------------------

Good question Ken. The problem to solve is: (a) how do you ensure that a "reply-to" topic is unique within a space of multiple interconnected MQTT brokers and (b) how do you make authorization simple and ideally uniform? 

ClientID in the reply-to topic, imo, is part of the solution but that is unique to a particular MQTT broker only - dups can exist on different brokers  leading to problems. Letting the client choose anything they want also problematic wrt uniqueness as well as for management of authorization rules. Having the client ask a 3rd party constructed outside MQTT is a problem because this is a request/reply MEP and the client doesnt (yet) have a unique reply-to address.

The alternative I was considering is one where the MQTT broker gives to the client, in a manner to be determined (eg during CONNECT or otherwise), a topic prefix that is configured on the broker to be unique within the broker's network. Then, reply-to topics for a client would follow a convention such as  <brokerID>/<clientID>/<more stuff that is client specific if they like>
Or have the broker return all of <brokerID>/<clientID> as the reply-to prefix if we want - many options here. Key is that it be unique within the MQTT network and ideally aggregatable.

The advantages of such an approach are:
- unique reply-to addresses within a multi-broker environment
- subscription aggregation between brokers for scalability reasons, (since <brokerID>/> would attract all replies to clients connected to <brokerID> (this is also important to solve race conditions of (i) add my reply-to (ii) send a request (iii) reply is generated before all brokers know of the client's reply-to subscription)
- authorization rules easily managed, configured and uniform across all applications

I realize there has been some reluctance in the group for the MQTT spec to place usage restrictions on MQTT topics, but my concern is that without some conventions or rules like this, we will define a mechanism that allows so much freedom that it is not easily supported in practice as it requires too much coordination between each application and the MQTT broker administration.

Thoughts?

> Support request/reply as a new MEP 
> -----------------------------------
>
>                 Key: MQTT-197
>                 URL: https://issues.oasis-open.org/browse/MQTT-197
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: candidateCN, ReqRespMEP
>            Reporter: Shawn McAllister
>
> This JIRA requests that the version of the MQTT protocol after 3.1.1 be augmented to support the request/reply message exchange pattern.  Minimally what is required is the ability to (optionally) carry a "reply-to" topic in a published "request" message that would allow the receiver to publish a "reply" message addressed to the contained reply-to topic.
> Hopefully the need to support request/reply is not in dispute as it is a very common message exchange pattern supported by HTTP, JMS and all major messaging products because of its usefulness and for which there are many applications in M2M use cases.
> The only way now with MQTT3.1.1 (that I am aware of)  to return a reply to the sender of a request message is for the requester and replier to coordinate on the reply-to address outside of any specific services provided by MQTT.  For example, by embedding the reply-to address in the payload of the message.   The main functional reason this is insufficient is that it does not allow protocol interworking functions(MQTT to some other messaging protocol)  that are not (and should not be) aware of application payloads to create an end-to-end request/reply flow.
> Therefore I would like to request that the TC consider and implement the protocol changes required to support this functionality.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)