A protocol to send bi-directional messages (data) from one point to another. Unlike the traditional communication protocols like REST, socket communication works by establishing a channel where the publisher can publish to that channel and receivers can listen to that channel. In other words, it’s a way of publishing subscribing method.
MQTT (Message Queuing Telemetry Transport) is a very light weight publish-subscribe protocol that enables us to build systems capable of publishing (server) and receiving messages (client).
Let’s go with an example: Assume user’s A, B and C is listening to a channel `updates/*`, and let’s a X publishes a message `New Update: Please update your application to 2.2`on to `updates/*` channel, the user’s A, B and C would immediately get to see the message.
Below are some common use cases:
MQTT being a light weight protocol sits aside your existing server side and brings you to a lot of capabilities of pub-sub service.
Let’s think of a scenario where you are building a fleet (say Cab) tracking application where the location is updated from a mobile application every 5 seconds (say). And you have a dashboard on a web application to show these cabs. How would you think about designing it?
The initial call would be to have a REST API to trigger the location update from the Android every 5 seconds to the server? Good catch. But this is not something scalable or reliable going forward. Think of the number of HTTP requests hitting the server along with the load handling capability of server.
Consider the dashboard also makes API call for those cars for each user seeing the dashboard. You wouldn’t be happier with that figure and that’s why MQTT comes into rescue.
So, if we were to use MQTT how would we design the solution for above problem? Let’s say each of the cabs are having a channel of format `location/
A question to ask yourself. How would you track an individual cab’s location instead of all cars? Well, the answer is to change the listening channel to `location/
So, what is a broker here? You could imagine broker as a postman who is responsible for delivering one message to another. There are plenty of brokers to choose from; out of which Mosquitto, HiveMQ, redis and RabbitMQ are very commonly used.
Let’s take a look at the above parameters:
c. Let’s define some required methods:
Let’s discuss on above methods; `on_connect` is a callback method that is triggered whenever a connection is established. Having a value of 0 for `rc` implies a successful connection.
d. Set the client to listen to the above channel:
And you are ready!! By now, you have a MQTT listener listening to channel ` location/123` of broker 'broker.hivemq.com'.
Let’s keep the terminal window open.
3. Now let’s setup a MQTT server (say mqtt_server.py) that publishes to the messaging channel ` location/123`
a. Like before; we start by importing the paho client.
b. Let’s setup the broker configuration
c. Let’s create a mqtt client to publish the data to the `location/123` channel.
d. Now that the client is ready; let’s publish the data:
As soon as above line is triggered, you will see the message "Bengaluru, India" will be received in the previous terminal window that was kept open earlier.
e. Disconnect when you are done.
Complete code below (using Public Eclipse Broker):
By now, I assume you know how to setup a MQTT layer on top of an existing python development services, and thereby advances you one step towards building highly scalable and reliable applications.