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


  1. Thanks Steve! Your tutorials have been great.
    Quick question, is there a way for the broker to publish a message on behalf of a publisher that gracefully disconnects?
    I know about Last Will, but in the event that a client purposely disconnects (maybe on a scheduled reboot or something), can the broker tell its subscriber that it did so?

    Thanks again!

      1. Thanks Steve, the problem is I can’t rely on the client script to publish a message on disconnect. An example would be during a reboot (I just tested this), the client will send a disconnect message automatically, in a background process somewhere and the new code that publishes to the new “/connected/#” topic doesn’t get received.

        Is there a way to have the broker perform this upon receiving the DISCONNECT?


        1. Chris
          The broker can’t do this. You need a another client to monitor the connected client. To do this the client needs to somehow publish it’s status.
          There is a roundabout way of doing it with broker logs but that also assumes you have access to these. I’m not sure if a disconnect is published on a topic when you configure topic logging. But if you use centralised logging using syslog it should be possible.


          1. This is a great article and set of mqtt resources. Thanks.

            I am dipping my toe in to making and have an iot device under development. I think this question is similar to what I have been thinking. I want to know when my IOT device goes offline. My thought is simply to publish a heartbeat periodically, in my case every minute. My set up is I have node red subscribing and it can act on lack of a heartbeat.

            My heartbeat actually includes the CPU temperature in its payload. It serves a dual purpose. I live in a hot environment and this will be deployed outside in an enclosed, sealed, water tight electrical box. This might be overkill, but I am not sure how the pi zero will behave in the height of summer.

          2. Hi
            It really is the only way you can be sure that the device is still active. You could use the keep alive and set it lower but as you need to publish the temp data you might as well use that.

  2. Thank you so much Steve for the information. It is so helpful. I just started learning about MQTT and your information is really making my job easy. I have one question.. it may sound silly..

    Does subscriber also need to send CONNECT packet first to broker? or is it only publisher will send CONNECT packet?

  3. I have just installed a Mosquitto broker on a Raspberry Piand the two clients.
    I can publish and subscribe on the local machine as per the examples given in the tutorials.

    pi@HomeVision:/ $ mosquitto_pub -h localhost -t “mqtt/pimylifeup” -m “Hello world”
    pi@HomeVision:/ $

    pi@HomeVision:/ $ mosquitto_sub -h localhost -t “mqtt/pimylifeup”
    Hello world

    It works fine. but how do i publish form another Pi to the other or even remove the “localhost” and put in the actual IP address. The moment I use instead of localhost….I just get an Error:Connection refused

  4. Hi steve, thanks for the valuable content.

    Can a client publish to two or more different MQTT brokers(server) without disconnecting with the existing MQTT connection? (where two servers doesn’t have any link with each other)

  5. Steve,
    Great information. But I am having a problem understanding how to publish to a mosquitto broker created on another computer.
    I have a Raspberry Pi running mosquitto. It works fine for all kinds publish and subscribes but they are all on the same computer so the mosquitto instance is readily available to all.
    But now I want to add a second RPi that will both publish to some topics and subscribe to others. both the publish and subscribe functions require a valid mosquitto instance, typically called mosq. How do I get the mosq value to the second computer?
    Here is what I used to create the mosquitto instance the first computer:
    void createMosquitto(){
    mosq = mosquitto_new(“345Mz”,true,NULL);

  6. Hi Steve,
    In Publish-Subscribe approach, if a subscriber remain offline/ disconnected in the network for several days, after rejoining/ reconnected, subscriber wants to receive all those packets which were shared during his absence/ disconnected time. Those packets are latest and unavailable to subscriber.

    My Question is, How subscriber can know about latest packets? How publisher can send all those packets which unavailable to subscriber.

    Looking for your response please.



    1. The subscriber must subscribe with a persistent connection( clean session false) and with a qos of 1 or 2.The publisher must publish with a qos or 1 or 2. The broker will have a limit of how many messages it will hold. Mosquitto defaults to 100 ( I think).
      So providing you meet those conditions you will get all the messages. If 200 get sent then you only get the last 100.
      If the publisher uses qos 0 you don’t get any.
      Hope that helps

  7. 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?

  8. 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.

  9. 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.

  10. 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 *