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] Commented: (MQTT-1) Flowing MQTT V3.1.1 protocol over a WebSocket


    [ http://tools.oasis-open.org/issues/browse/MQTT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33263#action_33263 ] 

Nick O'Leary commented on MQTT-1:
---------------------------------

I agree with Raphael on all points.

Specifically, I don't think the path element should be of any concern, and the MQTT packet should not be required to be aligned to the WebSocket frame.

Within other javascript environments it is pretty standard to receive partial packets and to buffer as appropriate. Having implemented a Websocket/TCP gateway in node.js, it was a pain to have to add in MQTT packet awareness to ensure the  fragmented packets coming in over TCP were correctly reassembled before sending over ws. Other that for that, the code didn't need to know anything about the structure of an MQTT packet.
As Raphael points out, this does then put that burden on the javascript client side, but that code will already have MQTT packet awareness, so is not really that much of a burden.

I also don't think this should be part of the core spec. A tech-note, or otherwise, depending on what options are available within OASIS, would be a better place for it.


> Flowing MQTT  V3.1.1 protocol over a WebSocket
> ----------------------------------------------
>
>                 Key: MQTT-1
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-1
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>    Affects Versions: 3.1.1
>         Environment: Web browser
>            Reporter: Andrew Banks
>
> Constraints and considerations for flowing MQTT binary protocol over a Websocket, RFC 6455.
> See also http://wiki.eclipse.org/Paho/Paho_Websockets
> Making MQTT over Websockets inter-operable:
> Must support WebSockets as defined by RFC 6455
> Must use websocket binary frames. 
> This enables MQTT v3,1 per the specification to flow over websockets with no change to the MQTT packets
> Must use "mqttv3.1" as the websocket protocol name. 
> This is applicable when creating the websocket: e.g. new WebSocket(wsurl, 'mqttv3.1')
> The path portion of the url specified on the MQTT connect should be "mqtt" 
> For instance ws://m2m.eclipse.org:800/mqtt . mqtt should be the default with the option for an alternative to be configured / specified
> Open points for further discussion:
> Should an MQTT packet be aligned with a WebSocket frame? Should MQTT Protocol messages be sent exactly one per frame or should the framing be arbitrary with multiple or partial MQTT messages per frame with no frame alignment.?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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