Re: [paho-dev] MQTT <-> REST+websocket mapping

[Matteo Collina <hello@xxxxxxxxxxxxxxxxx>]

2013/3/15 Raphael Cohn <raphael.cohn@xxxxxxxxxxx>

Interesting stuff. We're very much in favour of keeping MQTT with a binary mapping. It makes it trivial for implementations to add a WebSockets tunnel, using a wide range of different technologies that aren't tidied to a broker, etc.

The challenge is doing a little binary handling in _javascript_, but done once, it's done.

It is already done for node.js (it is what I am using): https://github.com/adamvr/MQTT.js.

It should not be harder to port it to the browser with ArrayBuffer (there are polyfills for that).

The only weakness with WebSockets is the blasted framing (XOR? Text frames? What where they smoking? Oh well, that's a committee for you). Many of the more generic WebSockets <=> TCP implementations (correctly, in my view), scoop up as many bytes as possible and send them on as WS binary frames. Thus there's no delineations in the frames so that they align with MQTT data structures.

And the W3C's WS API is naive and assumes one should present complete frames at each callback event. This sort of thing seems to make a js' programmers job harder, until he realises that it's just life, and a WebSocket is nothing more than a TCP stream. All he has to do is keep a buffer, and pre-pend it to the next WS event...

The WebSocket specification is extremely complicated, and still it has jeopardy support.

I am not a fan of it, and I prefer the much simpler Server-Sent Events one.

The Socket.IO devised a protocol to run inside a websocket or a tcp stream to fix these problems. It's called Engine.IO.

Do you think it might be possible to route MQTT inside a long-polling connection? 

It seems it can work, and it can be a good solution.

After Nick and your email I am getting more convinced that routing binary data to browsers might be a feasible idea.

From a dev perspective, it will be much harder to debug.

I'd agree with Nick on the challenges of using HTTP for messaging. It's quarts into pint pots - messaging is async, HTTP is sync and typically short-lived. It's hard to scale a broker that does HTTP mq.

I know that's very hard, but I am trying try to solve these problems. :)

Cheers,

Matteo