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-197) Support request/reply as a new MEP

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

Shawn McAllister commented on MQTT-197:

The description above of the new protocol items and the server processing is as I would expect. This would apply to both the request and the reply message - the server does nothing different.
I also believe that a 4 byte integer is sufficient and appropriate for a Correlation ID.

What needs to also be stated is processing by a MQTTv5 Client under various conditions. This is described in the WD https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/56842/reqreply-v1%200-wd04.docx but paraphrased here:

1. To issue a request, a Client:
- includes an appropriate Topic in the ReplyTopic field and -may- also include a Correlation ID
- the requesting Client must subscribe to the ReplyTopic in advance of sending the request message to receive the reply messages

2. When a Client receives a PUBLISH packet containing a ReplyTopic and (optional) CorrelationID:
- If the receiving Client is to issue a reply to an incoming PUBLISH (request) packet, then it places the contents of the ReplyTopic into the TopicName field and if a Correlation ID was included in received PUBLISH packet, this same Correlation ID value is placed in the outgoing packet

3. Similarly for the requesting Client, 
- PUBLISH packets received as replies to previously-issued requests may contain the Correlation ID of the original request and can be used by the requester to associate this reply with state from a previous request

I think it would also help to have a non-normative section explaining the requester/responder roles and an overview of this mechanism. I suggest we lift from the WD.

> 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
>    Affects Versions: 5
>            Reporter: Shawn McAllister
>            Assignee: 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

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