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

Shawn McAllister commented on MQTT-197:

On the question of the mechanics of the client "learning" its private ReplyTopic from the server if we were to support this, its quite simple:
- The client would set a bit in the CONNECT packet requesting it be given such a private topic
- In response to this, the server would put this private topic into a new field of the CONNECT ACK packet. If we make this optional for servers, then we would also have a way for the server to indicate it does not support this - via an error code or simply the absence of the private topic in the CONNACK.

On this comment from Ken:
>This is really similar to asking the server to give the client a username which is knows is valid for that client, and might well be considered a security exposure.

I don't think this is analogous because in this case you are only returning the private topic AFTER the client has successfully authenticated. That is different than giving him a user name - which is required to authenticate.

One reason for supporting this "dynamic learning" capability is that there are reasons that one might want this unique topic to change with each connection setup depending on which actual server it connects to - which means it cannot be statically configured.

More discussion to follow on this I'm sure.....

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