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

Ken Borgendale commented on MQTT-197:
-------------------------------------

If we do not want to involve the server, then any content format is fine and using http header parsing is no better or worse than using JSON or XML.  All you need is the two clients to agree on what is passed and to parse it as they like.  if the client can set its reply topic, then security for reply can be set up the same as any other topic. 

We should keep to the design that topics starting with $ are for communications between client and server and not client to client, and that MQTT will not define them.  If the server is not directly involved in request/response, then $ topics should not be used.

Request/response in a pub/sub world is not an RPC.  If a client publishes a request, it does not know if 0 or multiple other clients will respond.  Any of those servers can make multiple responses, and it is likely that the response could come a long time in the future.  This is all true whether we use a scheme like Andy's, or like Raph's.  It is certainly true today in JMS.

Andy's design gives us a small server involvement at the cost of needing a few extra bits where we do not have any (in PUBLISH).  By using an extended form of PUBLISH we can specify the originator ID as well as an optional correlation id.  The originator id needs to map to a session (not a connection).  While the simple key to a session is client id, any surrogate for this would work.  We certainly would need to work thru the expected results in the case of client or server failure, and the interaction with QoS (which we cannot specify on the subscribe as there is no subscribe).  We also need to specify what happens when a response comes in that we cannot map to a session.  This would be a bit easier if we had some form of NAK on the publish.

Anything we use as a correlation id should be set by the client.  This is only passed along by the server and responder and they do not require any form of uniqueness.  While some client applications might want to match up responses and retry requests without a response, other clients might not care.

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