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

Richard Coppen commented on MQTT-197:
-------------------------------------

Comment on behalf of Andy Stanford-Clark

MQTT request/response

In keeping with the idea of a "service", the server subscribes to a "service topic". The client uses this topic to identify which service it wishes to call (so a server offering several services, or sub-services of a service, can do so using multiple topics or wildcards in its subscription).

The client publishes a message with the topic of the service, and with a "req/resp" flag set in the header.

The broker notes the req/resp flag and adds to the variable header an extra field with a requestor identifier in it.
I'm not sure if this should be the client ID of the client, or an internal identifier which the broker uses to identify that client connection. I think in the interests of the anonymity of pub/sub, I prefer the latter, and that it be implementation specific (hence semantically meaningless).

The subscribing service receives the message and notes the req/resp flag is set. It services the request and constructs a publish message in reply. It sets the req/resp flag and puts the broker-provided requestor identifier in the variable header (in the same way that the broker did). So effectively it just replaces the payload (for QoS 0).
The topic is set to the incoming topic, to act as a kind of correlator for the requesting client to know which of several possible services it has outstanding requests with, this response is from.
The service publishes the message to the broker, which notes the req/resp flag and uses the client identifier in the variable header to locate the client connection across which to send the message. The broker removes the requestor identifier from the message before sending it on.

The client receives an unsolicited (i.e. it doesn't have to subscribe to the topic) publication on the topic it sent the original request on, with the req/resp flag set so it knows it's a response, and (in case of ambiguity), the lack of a client identifier in the variable header confirms it's a response and not a request, but if that ambiguity exists, it suggests a poor application design.

Possible variations:

Two flags - one for request and one for response, which the client and server respectively set in their messages.

Correlator - an additional field in the variable header which the client sets to enable it to relate requests to responses. The broker passes these through blindly, and the server sends back the correlator from the request in the response.

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