Using MQTT Broker? You Must Know This…
Simply having 10 connected devices could mean that the MQTT broker should be capable of handling 100 messages simultaneously
There are several options for developing a message broker with full duplex functionalities and various supporting features. Some of these options are the use of a raw TCP socket, a raw UDP socket, AMQP, and CoAP. Most of these alternatives have more limitations and complications than benefits, especially when compared to MQTT. This is where MQTT becomes the most appropriate, efficient, and convenient choice, especially when building our own Internet of Things platform.
Remember that all of these protocols can coexist, and we could deploy on the same cloud instance, if necessary. This means that in the future if you decide to use AMQP as well as MQTT, it is possible to integrate some or all of them. More importantly, we can link these channels with an additional plugin program(s) so that there is a seamless communication from an applications and devices perspective.
Using MQTT Broker
Fundamentally, MQTT is an asynchronous protocol and thus enables duplex communication with a lightweight burden on systems. It allows systems to run on low bandwidth and low power. Contrarily, HTTP and similar protocols require relatively high bandwidth and power and are request-response in nature, which means that the client must always initiate communication.
In places where you want either party (server or client) to initiate communication, MQTT is the best choice. Moreover, if systems need to run on low data consumption, especially on batteries, for a long period, it is prudent to use MQTT. If the device needs to send or receive data frequently and at random, then MQTT also makes sense because it reduces a significant HTTP overhead.
If bandwidth and power is not a concern, then HTTP may be a better choice. Also, when data sending or receiving frequency is not high, which can block the resources sooner in the process.
In an application, where a live control or monitoring is required, MQTT is an obvious choice because it provides duplex and two-way communication abilities with the least amount of overhead.
You must be mindful of the fact that the workload of an MQTT-based the system can grow parabolically, which means that for each device added to the MQTT speaking network that has n devices in total, the load on the system becomes n squared (n*n). The figure below explains this concept graphically.
For example, let’s assume an extreme scenario where there are two clients in which each subscribes to all possible topics (wildcard topic i.e. #). When a client publishes a message, the broker needs to receive a message and another client needs to receive the message too.
This means one message sent could result in two transmissions. The same goes for the other client, making it four messages in total for a two-client system.
For a three-client system, this number becomes nine messages in total, (i.e. three messages per client).
Simply having 10 devices connected means that the message broker should be capable of handling 10*10 (i.e. 100 messages, and so on).
When the number of MQTT clients starts to grow, the load on the message broker, overall system, and the platform will grow almost exponentially.
Always keep this in mind as you scale any IoT platform that is based on MQTT in the later stages, or add more devices to it.
If you are interested in writing an online review of my book, get in touch with me for your free reviewer copy.
About the Author: I am an entrepreneur, business & technology advisor, a published author, futurist, and emerging technology expert. I help businesses to improve key metrics by finding meaningful problems and then solving them in innovative ways. Sane and sensible adoption of technology continues to be my area of focus.