http://www.slideshare.net/paolopat/mqtt-iot-protocols-compar...
http://www.iotprimer.com/2013/11/iot-protocol-wars-mqtt-vs-c...
http://blogs.vmware.com/vfabric/2013/02/choosing-your-messag...
I don't know if this is what you meant with "public API".
[1] http://zatar.com
Warning, abbreviation overload! I don't know if it's because of Game of Thrones (which I don't even watch) but I find "IoT" intensely difficult to remember as an abbreviation. And I had to look up "M2M". I guess MQTT is acceptable because people interested in this would already know it.
Same here, though my confusion stems from "IoC" -- Inversion of Control. When I read "IoT" I thik "Inversion of -- Trust? no doesn't fit"
Curious because I was about to start playing around with emqtt
Any benchmarks for VerneMQ?
http://www.stavros.io/posts/messaging-for-your-things/
It's basically an HTTP API for polling pub/sub, along with a streaming endpoint for push.
I quick read of both VerneMQ and your queue service indicates that your guess is wrong:
- The whole MQTT spec (compact on-the-air messages, hierarchical topics, wildcard subscriptions, QoS level, message persistence)
- Service level agreement
- Live code upgrade
- Monitoring and tracing built-in
- Extensible with plug-ins
- Fault tolerance
I compare this to Faye and the Bayeux protocol which I've been using this far, but which few developers know or are willing to learn.
Perhaps would like to see some benchmarks and comparisons with other brokers (including RabbitMQ plugin).
In general with MQTT I was always wondering about its QoS level 2 -- "Once and one once delivery". How well does that work with distributed systems. That would seem a bit hard to implement. (I can see at least once, at most once. Exactly once would be tricky. Thinking about network partitions, disconnects and other such distributed systems shenanigans).
