MQTT Publish and Subscribe Beginners Guide

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.

See Retained messages-Example’

What Happens to Published Messages?

Questions –

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.

See MQTT Subscribe Example Using Paho Python Client

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?

A- No

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?

A- No you can only subscribe to topics.
Understanding MQTT Topics and Topic Structure <<Prev….Next>>An Introduction to MQTT Security Mechanisms


Related Tutorials

Please rate? And use Comments to let me know more
[Total: 12   Average: 4.5/5]You have already voted this article with


  1. Hi Steve,
    I wanted to ask something just to be sure:
    When a publisher sets a particular level of QoS to its message, that QoS level is only applied between the publisher and the Server but not between the Server and the Receiver right?

    For example:
    If Publisher A publishes Msg with QoS 1 to TOPIC, It should be ACKnowledged by the broker but when the Broker forwards it to a subscriber of TOPIC wiht QoS 0, subscriber does not send an acknowledgement packet to the broker right?

  2. Hi Steve,
    First of all, I want to thank you for all of your content as it has been very helpful to me.
    Secondly, I’m curious about the scalability of the ecosystem, how does the MQTT Brokers could support a lot of client in a realtime environment? If a load balancer proxy is required, how do I apply it in this case? Is there any available solution that is open-source out there?
    That’s all, thanks in advance Steve.

  3. Hello Steve,

    I wanna ask you something. Could the MQTT subscribers transmit the data that it receive from an MQTT publisher towards to multicast?


    1. MQTT is Multicast.There is no need for a subscriber to republish unless it republishes to a different broker thereby acting as a bridge.

  4. Hello,

    here my question, currently I ‘m using paho javascript client (over websocket) to handle my MQTT flow, I’m connected to my own mosquitto broker which works locally and I want know if it’s possible to connect the same paho javascript client to another broker this time in the cloud?
    The goal of that is suscribe to my local broker then (the same data) publish to cloud MQTT broker.

    Nb: Wife’s website (gallery of painting)
    Thank you for your help.

    1. I would think yes but I haven’t tried it with websockets and Javascript but do it all the time in Python. I will test it and let you know

Leave a Reply

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