[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [mqtt] Groups - Request/Reply Message Exchange Patterns and MQTT uploaded
|
Hi Rick, Thanks for your comments. More details inline on each point, but I think in general what you are advocating is a higher level service akin to an RPC type mechanism. I agree this would be useful and in previous discussions on this we decided this should be something
we layer on top of the request/reply capability we are defining here. What you propose is indeed one way to use request/reply but there will be others and we want to (a) keep the base capabilities very generic to support multiple types of these uses and (b)
keep the base request/reply simple enough to define quickly in order to unlock potentially multiple parallel uses of it. Shawn -----Original Message----- Thanks for the update. A few questions/comments: 1) It is essential that the protocol support multi-part returns so that the return(ed) content is not limited to the size of a single message, and that message disassembly/reassembly be handled by the client(s) and broker(s) transparently. [spm] Absolutely agree. This is not stated as a formal requirement in the doc but would be supported in the solution I propose. Unlike AMQP, MQTT does not support message fragmentation or streaming of a single message so this would
need to be built on top, but it could be supported. I'd be happy to add this as a requirement in the requirements section if there is no objection. 2) We have had good success overlaying HTTP-like semantics on other protocols - introducing the concept of a "method", headers, parameters, status code, status message, etc. - I might suggest that if we attempt to standardize on payload
format(s) we consider something similar. It makes interop with non-MQTT clients (HTTP, websocket, etc.) much simpler. At a minimum, semantics for error returns should be standardized. [SPM] ok with me to explore this as I see it being quite useful, but I would suggest this as a layered specification that makes use of the base request/reply capability for reasons stated above. Having a
higher layer definition that is compatible with messaging protocols other than MQTT I am very supportive of because we do expect IoT infrastructures to involve several different types of messaging protocols. Ideally, if you have such a higher level interaction
specification in mind, we look at taking that protocol and defining a binding of it to the MQTT transport. This ensures we start with something already defined/in use with the benefits of its ecosystem and then showing how to map/transport it on MQTT - vs
inventing our own here.... is there a particular spec you have in mind? 3) Could we go one step further and try to standardize on the payload format(s) (request and return) to better enable true interoperability? 4) Could we include a known topic/request for browsing/querying available service(s) that are exposed by a device or endpoint? 5) Once the foundation is in place, we should then explore a series of known request endpoints for different types of use cases (browsing device capabilities, content transfer, etc) [SPM] same for all these - IMO this is a broader discussion on one option for a more standardized use of request/reply that we should treat as a separate/parallel discussion and handle in a separate document.
Handling this in parallel means that we ensure any derived requirements are handled in the underlying request/reply service but that request/reply isn’t overly focussed on this particular use. Rick ________________________________ From: mqtt@lists.oasis-open.org [mqtt@lists.oasis-open.org] on behalf of Shawn McAllister [shawn.mcallister@solacesystems.com] Sent: Monday, November 02, 2015 1:32 PM Subject: [mqtt] Groups - Request/Reply Message Exchange Patterns and MQTT uploaded Submitter's message Hi All, Latest draft version now uploaded. The changes are: - accepted all changes in WD03 - added section 3 to document a candidate solution to provide request/reply capabilities with MQTT. I suggest we discuss on the Thursday call but I welcome any comments/questions before then also. Shawn -- Mr. Shawn McAllister Document Name: Request/Reply Message Exchange Patterns and MQTT<https://www.oasis-open.org/apps/org/workgroup/mqtt/document.php?document_id=56842> ________________________________ Description This document contains all matter related to adding a request/reply capability for applications using the MQTT 3.1.1 protocol. This document contains the motivation, requirements and solution options for providing such a capability. Download Latest Revision<https://www.oasis-open.org/apps/org/workgroup/mqtt/download.php/56842/latest/reqreply-v1%200-wd04.docx> Public Download Link<https://www.oasis-open.org/committees/document.php?document_id=56842&wg_abbrev=mqtt> ________________________________ Submitter: Mr. Shawn McAllister Group: OASIS Message Queuing Telemetry Transport (MQTT) TC Folder: Committee Notes Date submitted: 2015-11-02 10:32:29 Revision: 2 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]