How MQTT Works -Beginners Guide

MQTT is a messaging protocol i.e it was designed for transferring messages, and uses a publish and subscribe model.

This model makes it possible to send messages to 0,1 or multiple clients.



A useful analogy is TV or radio.

A TV broadcaster broadcasts a TV program using a specific channel and a viewer tunes into this channel to view the broadcast.

There is no direct connection between the broadcaster and the viewer.

In MQTT a publisher publishes messages on a topic and a subscriber must subscribe to that topic to view the message.

MQTT requires the use of a central Broker as shown in the diagram below:

MQTT- Publish-Subscribe-Model

Important Points to Note

  1. Clients do not have addresses like in email systems, and messages are not sent to clients.
  2. Messages are published to a broker on a topic.
  3. The job of an MQTT broker is to filter messages based on topic, and then distribute them to subscribers.
  4. A client can receive these messages by subscribing to that topic on the same broker
  5. There is no direct connection between a publisher and subscriber.
  6. All clients can publish (broadcast) and subscribe (receive).
  7. MQTT brokers do not normally store messages.

Introductory Video

This video takes you through the basics of MQTT.

MQTT Client-Broker Connections

MQTT uses TCP/IP to connect to the broker.

TCP is a connection orientated protocol with error correction and guarantees that packets are received in order.

You can consider a TCP/IP connection to be similar to a telephone connection.

Once a telephone connection is established you can talk over it until one party hangs up.

Most MQTT clients will connect to the broker and remain connected even if they aren’t sending data.

Connections are acknowledged by the broker using a Connection acknowledgement message.

You cannot publish or subscribe unless you are connected.

mqtt-message-flow

MQTT clients publish a keepalive message at regular intervals (usually 60 seconds) which tells the broker that the client is still connected.

See MQTT Keep Alive Interval Explained

The Client Name or Client ID

All clients are required to have a client name or ID.

The client name is used by the MQTT broker to track subscriptions etc.

Client names must also be unique.

If you attempt to connect to an MQTT broker with the same name as an existing client then the existing client connection is dropped.

Because most MQTT clients will attempt to reconnect following a disconnect this can result in a loop of disconnect and connect.

The screen shot below show what happens when I try and connect a client to the broker using the same client id as an existing connected client.

mqtt-broker-duplicate-ids

Clean Sessions

MQTT clients by default establish a clean session with a broker.

A clean session is one in which the broker isn’t expected to remember anything about the client when it disconnects.

With a non clean session the broker will remember client subscriptions and may hold undelivered messages for the client.

However this depends on the Quality of service used when subscribing to topics, and the quality of service used when publishing to those topics.

Understanding Clean sessions Video

Last Will Messages

The idea of the last will message is to notify a subscriber that the publisher is unavailable due to network outage.

The last will message is set by the publishing client on a topic.

This means that each topic cab have its own last will message associated with it.

The message is stored on the broker and sent to any subscribing client (to that topic) if the connection to the publisher fails.

If the publisher disconnects normally the last Will Message is not sent.

The will messages is including with the connect request message.

See Last Will and Testament example using Python

Python Client Example

This tutorial takes you though creating a client connection using the Paho MQTT client.

It looks at successful and failed connections and how to deal with them. – Working with Client Connections

Next ==> MQTT Topics and Topic Structure

Resources:

Please rate? And use Comments to let me know more
[Total: 16    Average: 4.6/5]

12 comments

      1. As you have explained in your article “Mosquitto Username and Password Authentication -Configuration and Testing” in above link that “…if the client supplies a username and password then it works even if they are invalid.”. It means that even if client tries to login with invalid password, it gets the access to broker! Does other Broker also has this drawback like it is in Mosquitto? How can this authentication be made secure then?

        1. That would be implementation dependent as it is not specified.However this is only if anonymous access is enabled

  1. Hi Steve, thanks for great article. In your article you wrote that “If you attempt to connect to an MQTT broker with the same name as an existing client then the existing client connection is dropped.” It is well true. But suppose if I am an attacker and I know the existing clientID of your device and topic your client is publishing at. So if I use the same existing clientID then your device will be disconnected and from this time forward I force my device to publish the false information on the topic. What will happen, the system will generate wrong insight. So is there any way to make a broker refuse the connection if there’s a connection with same clientID is already established. Thanks.

    1. On Mosquitto no. I also think that the MQTT spec specifies that behaviour.
      You would need to implement username/password to block the client from sending data
      Rgds
      Steve

      1. Since multiple clients can use same username and password to login to broker, is there any way to restrict a client to use only one username/password?

          1. Thanks steve, and what about login with wrong password? Like Mosquitto, other brokers too have this drawback?

          2. Not sure what you mean regarding wrong password. If anonymous is off then it will fail as expected otherwise the username/password is ignored for authentication but will be taken into account in the ACL.
            Rgds
            Steve

Leave a Reply

Your email address will not be published. Required fields are marked *