In my experiments with IOT I have used HTTP extensively for device communication in the form of RESTFul APIs.
But in my journey these past 2 weeks I was able to come across MQTT.
As stated in its wikipedia page:
It is a publish-subscribe-based messaging protocol. It works on top of the TCP/IP protocol. It is designed for connections with remote locations where a “small code footprint” is required or the network bandwidth is limited.
It is one of the protocols designed for IOT systems when they are constrained with slow internet speed or intermittent disconnection from its network and when the data to send is a bit small (temperature readings, float switch is up etc.).
It solves the first issue of network speed and disconnection through its Message Bus and through the Quality of Service levels.
For a really good understanding of its Quality of Service levels checkout HiveMQ’s article on the subject.
I’m still in the process of learning what more the protocol can offer.
Architectural Differences Between HTTP vs MQTT
HTTP
HTTP is based around a client/server architecture.
The client issues a request to a resource to the server and the server responds to that request with the appropriate resource data.
The client might issue a GET, POST, PUT, PATCH, DELETE while the server may respond with a number of Status Codes for each type of request with or without the associated data.
The Data that is associated with a request and a response might be a JSON, XML, YAML, HTML or some other format.
MQTT
MQTT on the hand is based on Brokers, Publishers and Subscribers since it builds upon the publish-subscribe pattern.
Subscribers and Publishers need to connect to the broker in order to do their respective roles.
Publishers publish a message with a signature of { topic, messageContent } and Subscribers sibscribe to a { topic }.
Whenever a Publisher publishes a topic that a Subscriber is subscribing it will receive the message.
You can think of it as like chat-rooms wherein you only receive messages from rooms you are in.
The data that flows in MQTT are only Strings or StringBuffers.
That means a format like JSON needs to be stringified first before being published and needs to be parsed back to JSON on receiving.
Connections in MQTT are long-lasting like WebSockets.
Due to its pub-sub architecture MQTT allows Bi-directional communication: The Subscriber can also be a Publisher and the Publisher can also be a Subscriber.
Flexibility, Support and Performance
MQTT is a bit flexible as it can run over the WebSocket Protocol and therefore also run on top of HTTP.
This allows browsers to also participate in the Publishing and Subscribing of Messages as long as it connects to the broker.
MQTT is also well supported on production environments for IOT and Web Apps.
Examples include but are not limited to:
For its Performance Benefits I’ll just point you to some really good resources. Let’s just say that since MQTT is data-centric rather than document-centric its much faster over HTTP.
Closing
In future articles that I’m going to write especially on IOT the protocol that I’ll be using will now be MQTT instead of HTTP.
Comments