[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=33276#action_33276 ] 

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

I understand the concerns but I disagree that they actually matter.

(1) Path specification
Firewalls fall into 3 types here:-
- Stateful or Stateless port-based (the vast majority; eg Linux iptables)
- Vanilla HTTP ones (and we should add simpler load balancers, eg HAProxy, here, and things like nginx's 'firewall' plugin)
- WebSocket aware ones (quite rare)

The first set are unaffected by path but would probably be used for regulating any TCP traffic that was bridged to the protocol
The second set can mostly be set up to use HTTP headers, and so should be looking for the mqtt3.x subprotocol. They don't have to be WebSockets aware, thankfully.
The third set are a fancier second set.

In practice, it's exceedingly rare to firewall on path. Instead, you just 404.

(2) Framing
I don't understand this - it seems quite wrong. Framing in WebSockets is nothing more than a header, the most important thing of which is 'there are X bytes in this frame'. In real use, no one sane is going to use extension frames. Instead, they'll do:-

how many iovecs in my outbound queue / array? Total length?

Write websocket frame, binary, complete, size == total length of all my iovecs. Do write().
Do writev(), repeating if need be using epoll / poll / select / io completion if interuptted / would block /etc

Frame alignment is not an issue. There is no redundant processing. 

As for reading, its pretty simple. All sent frames have that silly XOR nonsense, so one has to do a non-zero-copy off the wire regardless:-

- receive frame
- copy and xor into receive buffer
- process as much as possible
- would block, so return control to epoll
- get called when more data


> 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