
VerneMQ – An Erlang powered MQTT message broker for the IoT - dergraf
https://verne.mq
======
platz
I still wonder if MQTT really has the right tradeoffs compared to AMQP,
especially as you try to scale things beyond hello world.

[http://www.slideshare.net/paolopat/mqtt-iot-protocols-
compar...](http://www.slideshare.net/paolopat/mqtt-iot-protocols-comparison)

[http://www.iotprimer.com/2013/11/iot-protocol-wars-mqtt-
vs-c...](http://www.iotprimer.com/2013/11/iot-protocol-wars-mqtt-vs-coap-vs-
xmpp.html)

[http://blogs.vmware.com/vfabric/2013/02/choosing-your-
messag...](http://blogs.vmware.com/vfabric/2013/02/choosing-your-messaging-
protocol-amqp-mqtt-or-stomp.html)

~~~
tuukkah
Is anyone using AMQP in a _public_ API?

~~~
pietrofmaggi
Zebra Technologies' Zatar[1] platform use AMQP for the communication between
the devices and the server.

I don't know if this is what you meant with "public API".

[1] [http://zatar.com](http://zatar.com)

~~~
tuukkah
zatar.com talks of CoAP but I don't see AMQP mentioned.

------
tuukkah
Interesting open alternative to IBM's MessageSight products. In general, the
MQTT standard seems great for providing open, high-volume publish-subscribe
APIs (over TCP for native apps, over Websocket for web apps).

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.

------
bshimmin
"The most scalable MQTT Message Broker. Powering IoT, M2M, Mobile, and Web
Applications."

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.

~~~
perlgeek
> 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.

Same here, though my confusion stems from "IoC" \-- Inversion of Control. When
I read "IoT" I thik "Inversion of -- Trust? no doesn't fit"

------
randomman
How does this compare to this other open source erlang powered MQTT message
broker: [http://emqtt.io/](http://emqtt.io/)

Curious because I was about to start playing around with emqtt

Any benchmarks for VerneMQ?

~~~
dergraf
VerneMQ committer here, we haven't published any benchmarks yet. I haven't
looked at the emqtt codebase in depth, but as far as I can tell they use a
different clustering/distribution model than VerneMQ. I also don't know about
their take on plugins.

------
imglorp
Hugged.

[http://webcache.googleusercontent.com/search?q=cache:https:/...](http://webcache.googleusercontent.com/search?q=cache:https://verne.mq)

------
rdtsc
Thanks for sharing. Looked over the code, looks solid, and very well
organized.

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).

------
StavrosK
I wrote a very simple queue for embedded devices to talk to (in Go, so you
just copy the single binary), which is similar to VerneMQ (I guess) but way
less complex:

[http://www.stavros.io/posts/messaging-for-your-
things/](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.

~~~
fasteo
>>> which is similar to VerneMQ (I guess) but way less complex

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

