In MQTT the process of sending messages is called publishing, and to receive messages an MQTT client must subscribe to an MQTT topic.
MQTT Publishing Basics
A client is free to publish on any topic it chooses. Currently there are no reserved topics. However brokers can restrict access to topics.
A client cannot publish a message to another client directly and doesn’t know if any clients receive that message.
A client can only publish messages to a single topic, and cannot publish to a group of topics.
However a message can be received by a group of clients if they subscribe to the same topic.
Message Flow and QOS on Published Messages
MQTT supports 3 QOS levels 0,1,2.
- QOS -0 – Default and doesn’t guarantee message delivery.
- QOS -1 – Guarantees message delivery but could get duplicates.
- QOS -2 -Guarantees message delivery with no duplicates.
A message is published using one of these levels with QOS level 0 being the default.
If you want to try and ensure that the subscriber gets a message even though they might not be online then you need to publish with a quality of service of 1 or 2.
The schematic below shows the message flow between client and broker for messages with QOS of 0, 1 and 2.
Messages published with a QOS of 1 and 2 are acknowledged by the server.
This results in several messages being sent.
Messages published with a QOS of 0 require only 1 message., and are not acknowledged by the server
Published messages with a QOS of 1 or 2 also have a Message ID number which can be used to track the message.
See publishing messages using the Python client for examples.
Publishing Messages and The Retain Flag
When a client publishes a message to a broker it needs to send:
- The message topic
- The message QOS
- Whether the message should be retained.- Retain Flag
The retain Flag is normally set to False which means that the broker doesn’t keep the message.
If you set the retain flag to True then the last message received by the broker on that topic with the retained flag set will be kept.
The QOS of the published message has no effect on the retained message.
The main use of this is for sensors that don’t change very much and publish their status infrequently.
If you have a door sensor, for example, then it doesn’t make much sense publishing it’s status every second when it is almost always the same.
However if it only publishes it’s status when it changes what happens when a subscriber subscribes to the sensor.
In this case if the last status was published without the retain flag set then the subscriber wouldn’t know the status of the sensor until it published it again.
What Happens to Published Messages?
1 .What happens to the published message after the subscriber receives it?
2. What happens to the published message if there are no subscribers?
To answer these questions just think of a TV or radio broadcast.
If you aren’t tuned into the broadcast you simply miss it!
So for question 1 and question 2 the answer is- The message is deleted from the broker.
When a client publishes a message on a topic then the broker will distribute that message to any connected clients that have subscribed to that topic.
Once the message has been sent to those clients it is removed from the broker (see note below).
If no clients have subscribed to the topic or they aren’t currently connected, then the message is removed from the broker. (see note)
In general the broker doesn’t store messages.
Note: Retained messages, persistent connections and QOS levels can result in messages being stored temporarily on the broker/server.
Subscribing To Topics
To receive messages on a topic you will need to subscribe to the topic or topics.
When you subscribe to a topics you also need to set the QOS of the topic subscription.
The QOS levels and their meaning are the same as those for the published messages.
When you subscribe to a topic or topics you are effectively telling the broker to send you messages on that topic.
To send messages to a client the broker uses the same publish mechanism as used by the client.
You can subscribe to multiple topics using two wildcard characters (+ and #) as discussed in the understanding MQTT topics tutorial.
All subscriptions are acknowledged by the broker using a subscription acknowledge message that includes a packet identifier that can be used to verify the success of the subscription.
Publish and Subscribe Questions and Answers
Q- Can I publish and subscribe to the same topic?
A– Yes. In MQTT version 5 you can prevent messages that a client publishes from being received (no local subscriptions).
Q- Can a MQTT broker subscribe to an MQTT client?
Q- Will received messages have the same QOS as the QOS of the subscription.
A- Not necessarily as it depends on the QOS of the published message.
Q- Can I subscribe to messages from a particular client?
- Configuring the MQTT Publish and Subscribe Nodes in Node-Red
- Using the mosquitto_pub and mosquitto_sub tools