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

[Matteo Collina <hello@xxxxxxxxxxxxxxxxx>]

Raphael,

I'll reply inline.

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

Once you see WebSockets as a TCP stream, you just keep a buffer and respond to your callback for read - it's no different to epoll's eventing. Move over the buffer parsing data structures. Occasionally compact the buffer. Done. Debugging binary data doesn't have to be hard at all. You just need to build up your data structures from first principles. And if you do it right, one developer or two has to understand it; the rest just use the library. If you don't want to use binary data, then you might want to use the STOMP protocol. Having said that, I think MQTT would be far better for the majority of situations.

You and all the others convinced me.  So, mqtt over websocket is definitely the way to go.

I plan to start crafting something on GitHub on this issue.

Long-polling is, to my mind, quite retrograde. That's what a WebSocket is trying to be for. And then you should either use your protocol's 'liveness' (which MQTT has) or TCP keep-alive if it doesn't (not good). WebSockets ping-pong is quite useless, as it knows nothing of the protocol layer above it and its behaviour.

I really struggle to see the use case for Engine.IO. To my mind, Socket.IO should probably start to die. All the major browsers now support the standard WebSockets RFC. And IE 8 / 9 can use a flash shim. The only bugbear is older versions of Android and iPhone (nearly all dead).

You still need a 'shim' to support older technologies, like Long-Polling (for old Androids) or Flash for these devices.

Moreover, most PaaS and web servers still do not support WebSockets properly, so fallbacks will be needed for some more years.

You can look at SockJS.

Engine.IO handle the 'tcp' part of WebSocket, just like you said about MQTT.

In most sense, you can see Engine.IO as a competitor of MQTT over WebSocket.

 

And running a binary protocol over node.js? Clever, but wrong. Ultimately, for real scale, you're never going to do it with a dynamic language. The memory management and lack of sticky threading kill you.

It is not the right place for such an argument on this topic.

I really, really hazard against using HTTP for MQ. You end up having to use a lot of persistent state. If it is only to ship data to browsers, use WebSockets. If you want REST for messages, think long and hard. But remember that even HTTP headers are badly supported by most simpler http libs and browser plug ins. There's a good reason Amazon SQS has never really taken off...

The whole point of supporting third-party web and mobile apps is to support standard REST requests.

The goal in that area it is not about MQ, it is much broader: representing the physical devices on the web.

The fact that these devices are exposed through a MQ should be mostly irrelevant to app developers.

In order to achieve that goal massive storage capabilities are required, but that's what the cloud is for.

Cheers,

Matteo