XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: 5, wd07
    • Component/s: candidateCN, ReqRespMEP
    • Labels:
      None
    • Proposal:
      Hide

      Add a new section after 3.3.2.5 - ReplyTo Topic
      If absent the message is not a request.

      d (0xxx) Byte, Identifier of the ReplyTo Topic, followed by a UTF-8 string which is used as the Topic Name for a reply message. The ReplyTo Topic MUST be a UTF-8 encoded string as defined in section 1.5.3. The ReplyTo Topic MUST NOT contain wildcard characters.

      A server MUST send the ReplyTo Topic unaltered to all subscribers receiving the publication, using this version of MQTT.

      Non Normative:
      The receiver of an Application Mesage whith a ReplyTo Topic sends a response by using the ReplyTo Topic as the Topic Name of a PUBLISH. If the request message contains a Correlation Data, the receiver of the request should also include this Correlation Data as an Identifier/Value pair in the PUBLISH packet of the response.

      See section 4.x for information about how request / response works.

      Add another new Section: Correlation Data
      If absent no Correlation Data is used for the response.

      y (0xyy) Byte, Identifier of the Correlation Data Identifier followed by a 2 byte integer length, followed by that many bytes of binary data. The Correlation Data is used by the sender of a request to identify which request the response is for.

      A server MUST send the Correlation Data unaltered to all subscribers receiving the publication, using this version of MQTT.

      Non Normative:
      The receiver of an Application Message which contains both a ReplyTo Topic and a Correlation Data sends a response by using the ReplyTo Topic as the Topic Name of a PUBLISH. The client also sends the Correlation Data unmodified as part of the request PUBLISH.

      The value of the Correlation Data is only known to the sender of the request and receiver of the response.

      See section 4.x for how the request / response can be used.

      Show
      Add a new section after 3.3.2.5 - ReplyTo Topic If absent the message is not a request. d (0xxx) Byte, Identifier of the ReplyTo Topic, followed by a UTF-8 string which is used as the Topic Name for a reply message. The ReplyTo Topic MUST be a UTF-8 encoded string as defined in section 1.5.3. The ReplyTo Topic MUST NOT contain wildcard characters. A server MUST send the ReplyTo Topic unaltered to all subscribers receiving the publication, using this version of MQTT. Non Normative: The receiver of an Application Mesage whith a ReplyTo Topic sends a response by using the ReplyTo Topic as the Topic Name of a PUBLISH. If the request message contains a Correlation Data, the receiver of the request should also include this Correlation Data as an Identifier/Value pair in the PUBLISH packet of the response. See section 4.x for information about how request / response works. Add another new Section: Correlation Data If absent no Correlation Data is used for the response. y (0xyy) Byte, Identifier of the Correlation Data Identifier followed by a 2 byte integer length, followed by that many bytes of binary data. The Correlation Data is used by the sender of a request to identify which request the response is for. A server MUST send the Correlation Data unaltered to all subscribers receiving the publication, using this version of MQTT. Non Normative: The receiver of an Application Message which contains both a ReplyTo Topic and a Correlation Data sends a response by using the ReplyTo Topic as the Topic Name of a PUBLISH. The client also sends the Correlation Data unmodified as part of the request PUBLISH. The value of the Correlation Data is only known to the sender of the request and receiver of the response. See section 4.x for how the request / response can be used.

      Description

      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.

        Attachments

          Activity

            People

            • Assignee:
              ken.borgendale Ken Borgendale (Inactive)
              Reporter:
              shawn.mcallister Shawn McAllister (Inactive)
            • Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: