[OASIS Issue Tracker] Commented: (MQTT-1) Flowing MQTT V3.1.1 protocol over a WebSocket

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Raphael Cohen commented on MQTT-1:
----------------------------------

My 2 cents worth:-

Path portion: I'd argue that's out of scope. The 'path portion' is duplicating the functionality of the subprotocol. Many, many users either (a) can't control it or (b) will want to expose the same resource with different protocols (eg STOMP, MQTT, something else). So I'd simply say we say (a) nothing or (b) say there is no default.

Version: we'd want to register 3.1.1 or 3.2 or whatever we finally use

Packet alignment: I'd go for anything goes - ie no alignment of any sort, so we maximise compatibility and interop; we allow people to pick any WebSockets gateway, and wire in any broker or client; to tunnel TCP generically over WebSockets; to use an existing java client with a Java socket that 'wraps' websockets, to use legacy code, to avoid the need for brokers to implement a different network / socket driver, etc. It is also far more efficient. When writing MQTT frames, you just want to do POSIC writev() (a scattered write) of an array of iovec. With frame alignment, you can't do that  nearly as efficiently. The downside of anything goes is it is *slightly* more complex for a javascript client. Slightly, because onMessage() != a frame, so you just keep a buffer, iterate over frames, and keep the last 'fragment' and push (compact) to the front of your buffer in preparation for the next call. it'd be no more than a tweak to the excellent Paho code, for instance.

Other WebSocket features: I'd like a simple statement that other things (ping-pong, gzip extensions, use of headers for security / cookies are out-of-scope / not required / extend at your own risk / something,  for implementation, so we can maximise interop).

Most importantly: is this core or can it be dealt with a technical note, etc post-spec? How do people feel?

> 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