0:01
Hey everyone. In this lesson, I'll be going over the MQTT protocol.
So in the last lesson,
Gonz went over JSON and REST APIs to kind of
showcase the communication between your embedded systems with the Cloud.
So, that's actually one of the main methods to do that.
There's a new method with the explosion of IoT called the MQTT protocol.
So, we'll go straight into that.
So, real quick, just want to go over MQTT.
MQTT stands for
Message Queue Telemetry Transport protocol, and that's kind of a long name,
but basically, it's a very lightweight way of
sending communication between the different services.
Whereas, REST API that sits along on top of HTTP,
it's a bit more heavy, more synchronous.
MQTT more lightweight, you can do more stuff with it in terms
of making sure data is synchronized or what not.
So, MQTT is kind of based off of this publisher subscriber model.
So, when you do some sort of HTTP request,
you know exactly who to contact,
and you have to wait for their response.
And the Pub Sub model, what you'll see is,
yourself will subscribe to some sort of service,
and then you'll just do whatever you want in the meantime,
and then whenever the service is ready they'll push information to you.
A good example is probably when you sign up for let's say,
your notifications on the phone.
Let's say, I want to get notified of the next event.
So what you do is you subscribe to let say,
your favorite bands' events,
click the 'OK' button and then you go off with your day.
You go on doing your work,
your homework, all that stuff.
And all of a sudden, there's a new event nearby you.
Sends you a notification,
and you know you've got to go to that concert next weekend.
So that's kind of an example of a Pub Sub model.
So, one of the problems with that, however,
is that you need to directly communicate with that person or that service.
So I need to directly communicate with,
let's say Google, and Google will need to directly push it to me.
So, there's a new concept called the message broker,
where they kind of abstract that out.
So my favorite example is,
let's say, I want to send Gonz over here money.
Instead of me going over directly giving Gonz money when it's ready,
I can just go sent it through the mail, and what the mail will do,
they'll be in charge of sending the money over to Gonz directly.
Gonz will ask me money,
I just give it over to the mail service,
the mail service will automatically to deliver to Gonz.
So in this way, if we kind of change that over to the IoT world,
these IoT devices will send data to some sort of channel or message broker,
and then the message broker will be in charge of sending
that data out to each of the individual subscribers.
So for example, in this case,
one of the common enterprise level brokers is something called Hive MQTT broker.
And just like I was saying before,
there's slight differences between MQTT and HTTP,
but the main difference is that HTTP kind of depends on this quote-unquote "handshake",
where you need to wait for the data to come back.
With MQTT, you can kind of configure it to how you need.
What I mean by that is,
if I send you data,
sometimes I don't want to know if you receive
that data or not. I just want to send it out.
So if I'm getting data every millisecond let say,
there's no need for you to get every single millisecond's worth of data.
You can just receive maybe half a second's worth,
or so on and so forth.
So for me, as a device,
I don't need a confirmation of whether or not you received it.
Now there's also different settings on that, but,
especially if you have a lot of devices sending data continuously,
you kind of want to tune that parameter to however you want.
So, this is kind of the process for the MQTT protocol.
What will happen is you'll have, let's say,
client one, as you see in the image,
try and connect to the MQTT broker,
and once that connection goes through,
they'll go ahead and start publishing events through some sort of topic.
Client two, on the other hand,
they'll also connect and maybe subscribe to the events topic,
and then, anytime a message is published,
they'll go out and get that message.
So, if we go through the flow-through again,
client one connects with their broker,
then client two connects and subscribes to events.
Then client one publishes an event and then it goes directly to client two,
and client two didn't have to do anything; it just automatically gets it.
So, this is kind of how AWS IoT works.
In the next video,
we'll go ahead and go over how all that works underneath the hood.
Ganz ChockalingamPrincipal Engineer
Harinath GarudadriAssociate Research Scientist
