[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=62319#comment-62319 ] 

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

>> If you'd be so kind, I am unclear on several points. In the case of an end-to-end path with more than one broker visit, how would the client discover the end-to-end return path? Am I correct in imagining the proposal as a kind of overlay network using explicit reply routing constructed of (<brokerID>, <topic>)+, 

- I'm not exactly sure I understand what you mean by "explicit reply routing" but I think the answer is yes:
- Each client would be given a topic root that is <brokerID>/<A>   - where <A> is unique within a broker and IMO should be the ClientID for many reasons
- Clients would then subscribe to <brokerID>/<A>/#  - to receive all their reply-to messages
- Clients can put into the reply-to field of published messages any topic that starts with <brokerID>/<A>

- The primary benefits of this are per above.

- As an analogy with IP: addresses are not chosen independently by each host, they are assigned by the network admin (via subnets & DHCP) to allow for uniqueness, access controls and scalability.

>> and perhaps a routing protocol of some type to maintain the routing information? Perhaps I misunderstand, but this seems pretty ambitious

-  I agree that a routing protocol is more than "pretty" ambitious and I am not proposing such a capability here.(we need to leave something for the next MQTT release :-)

- Please let's not get too caught up with what I write below since this reply-to assignment mechanism is required even without the below, but having such a mechanism allows people to build multi-broker deployments like this:

-  client C connected to an MQTT broker G on a remote device or gateway, that connects via an MQTT bridge over the WAN to broker D in a datacenter which in turn connects a client A in the datacenter.:
   client C <---> broker G <---> broker D <---> client A

One would of course have many, many broker G's in the deployment and we would want to ensure that client A can communicate with any client C of any broker G in an unambiguous, authorized, scalable manner.  

We will not specify the behavior of this "bridge", but it does exist in many products and is a useful capability.



> 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)