Suitability of RabbitMQ for mobile apps?

[Virgil Kuruthers]

Dear All,

I am reading the book "RabbitMQ Cookbook" and it has an example mobile app. where is uses MQTT to connect to the RabbitMQ server, stating that MQTT is more lightweight and therefore suitable for mobile apps.  How true is this exactly?  In what exact ways is RabbitMQ not suitable for mobile apps?  I am using RabbitMQ on my Linux data logger and it's working extremely well, so figured it would be cleaner to use the same protocol on the mobile app. I'm developing too.

Thank you,

Virgil.

[Michael Klishin]

 On 25 September 2014 at 18:03:45, Virgil Kuruthers (vkuru...@gmail.com) wrote:
> where is uses MQTT to connect to the RabbitMQ server, stating
> that MQTT is more lightweight and therefore suitable for mobile
> apps. How true is this exactly? In what exact ways is RabbitMQ
> not suitable for mobile apps? I am using RabbitMQ on my Linux data
> logger and it's working extremely well, so figured it would be
> cleaner to use the same protocol on the mobile app. I'm developing
> too.

First of all, "using RabbitMQ" and "using MQTT" is not an either/or proposition.
You can use MQTT with RabbitMQ, and get most of its features:

 * Clustering and federation
 * Management UI, HTTP API for monitoring
 * TLS support
 * Pluggable authentication

and so on (not all features are exposed to all protocols but we try to
support them when possible).

MQTT is a smaller protocol compared to AMQP 0-9-1. It lacks several features
compared to some other protocols (a few I find pretty essential).

As far
as being more lightweight on the wire, both are binary protocols and are fairly
efficient for that reason alone. Without going into debunking some claims
from the MQTT community, it is fair to say that it is easier to implement
really efficiently memory-wise, but again, it can be done well for both.

One area where MQTT is easier to work with is connection recovery: connections
there have less state. One area where MQTT so far has a glaring hole is authorization. There is no way for MQTT brokers to notify a client that
something has gone wrong or it is not authorized to do something. Per MQTT 3.1.1
spec, brokers should simply close TCP connection, to which pretty much every client
reacts by automatically re-connecting.

Another difference you should be aware of is client ID. In MQTT, every client in
a broker must have a unique client ID. If the ID is duplicated, all but the newest
client with that ID will be disconnected. So you have to use device ID in some
form for the client id, which many mobile developers are not super psyched about.

If I had to recommend a messaging protocol for mobile clients which are not very
resource-constrained hardware-wise (e.g. any decent Android device or iPhone/iPad/iPod Touch), I'd recommend taking a look at STOMP. It is less efficient
on the wire but has consumer-driven message acknowledgements, is extensible and
client libraries are generally more mature than MQTT ones.

MQTT is not a bad choice. AMQP 0-9-1 can work well. All 3 are supported by RabbitMQ.
So give STOMP a try, then MQTT, then AMQP 0-9-1 if needed. Whichever works for you,
use that.

HTH.
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Virgil Kuruthers]

Thank you, that is a very detailed and informative answer.