Hello Guys, in this blog I am going to tell you about a protocol that’s better than HTTP for mobile and IOT environments.
MQ Telemetry Transport Protocol (MQTT) offers a number of advantages over HTTP if you’re doing hybrid mobile development. MQTT is a lightweight publish/subscribe messaging protocol. HTTP which is designed as a request-response protocol for client-server computing, not necessarily optimized for mobile and push capabilities, particularly in terms of battery usage.
In the mobile environment, response times, throughput, lower battery use and lower bandwidth are key design criteria. Compared with HTTP, MQTT features faster response and throughput, and lower battery and bandwidth usage, making it well suited to use cases where:
- Connectivity is intermittent
- Bandwidth is at a premium
- An enterprise application needs to interact with one or more phone apps
- Phone or tablet apps need to send data reliably without requiring code retry logic
Another advantage of MQTT over HTTP is that it is integrated with enterprise messaging middleware, so it works with enterprise-level applications that push data to mobile apps. MQTT can also be integrated with IBM Worklight in such a way that developers can create mobile applications using HTML and Javascript and yet have the messaging function working at the native layer, in native Java code, deployed on Android.
Basically, MQTT is designed for low latency, assured messaging and efficient distribution. HTTP is not optimized for low power usage or minimizing the amount of bytes flowing. In one test, conducted by Stephen Nicolas,
“…you’d save ~4.1% battery per day just by using MQTT over HTTPS to maintain an open stable connection.
The reason for this is simple. While it costs MQTT more to create the initial connection, this is essentially a one off and the cost of the following keep alives is comparatively small. Whereas for HTTPS it needs to perform the ‘expensive’ connection stage every time it has to reconnect (up to once each keep alive interval, in my implementation).
As this testing has shown, MQTT uses less power to maintain an open connection, to receive messages and to send them. It also does these last two more quickly and reliably. The only place where it loses out is in establishing the initial connection (with cleanstart=true) and that’s mitigated after ~5 ½ minutes of being connected.”
Other advantages built into the MQTT protocol are retained messages and multiple subscriptions ‘multiplexed’ over one connection.
Protocol Architecture Image
So What for Developers?
So what does this mean to you? If battery consumption is a key design criteria, then MQTT is the clear answer. If you have an enterprise application pushing to a mobile device, MQTT is the easiest answer. And if you’re already working with Worklight, MQTT is built-in, so you don’t need to learn new technology. HTTP is venerable, extendable and useful. But MQTT beats it for most mobile application development.
So how can you actually implement this?
As said MQTT works in publish subscribe mechanism, a set of clients need to subscribe to a topic to which the messages are published using a broker. There are many brokers available for MQTT out of which my favourite one is Mosquitto, It is developed by Eclipse org and comes with Eclipse Public Licence. In future blogs we will discuss about its installation and set-up of Mosquitto.
–Bala
