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:
Important Points to Note
- Clients do not have addresses like in email systems, and messages are not sent to clients.
- Messages are published to a broker on a topic.
- The job of an MQTT broker is to filter messages based on topic, and then distribute them to subscribers.
- A client can receive these messages by subscribing to that topic on the same broker
- There is no direct connection between a publisher and subscriber.
- All clients can publish (broadcast) and subscribe (receive).
- MQTT brokers do not normally store messages.
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 clients publish a keepalive message at regular intervals (usually 60 seconds) which tells the broker that the client is still connected.
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 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.
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, and is set on a per topic basis which means that each topic can have its own last will message.
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 actual will messages is including with the connect request message.
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