MQTT with QoS levels in Raspberry Pi - Time & Space Complexity
When using MQTT with different Quality of Service (QoS) levels, the time it takes to send messages can change. We want to understand how the message delivery steps grow as we send more messages.
How does the number of message exchanges grow when using various QoS levels?
Analyze the time complexity of the following MQTT publish code with QoS.
client = mqtt.Client()
client.connect("broker.hivemq.com", 1883)
for i in range(n):
client.publish("topic/test", f"Message {i}", qos=1)
client.disconnect()
This code sends n messages to a topic with QoS level 1, which requires acknowledgment for each message.
Look at what repeats as we send messages.
- Primary operation: Sending each message and waiting for acknowledgment.
- How many times: Exactly
ntimes, once per message.
As the number of messages n increases, the total steps to send and confirm messages grow directly with n.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 send-and-acknowledge steps |
| 100 | About 100 send-and-acknowledge steps |
| 1000 | About 1000 send-and-acknowledge steps |
Pattern observation: The work grows evenly as you send more messages.
Time Complexity: O(n)
This means the time to send messages grows in a straight line with the number of messages.
[X] Wrong: "QoS 1 sends messages instantly without waiting, so time does not grow with more messages."
[OK] Correct: QoS 1 requires waiting for an acknowledgment for each message, so sending more messages means more waiting steps, making time grow with n.
Understanding how message delivery steps grow with QoS levels helps you explain real-world network communication delays and reliability trade-offs clearly.
What if we changed the QoS level from 1 to 0? How would the time complexity change?
Practice
Solution
Step 1: Understand QoS levels in MQTT
QoS 0 means no guarantee, QoS 1 means at least once, QoS 2 means exactly once.Step 2: Identify QoS 1 guarantee
QoS 1 ensures the message is delivered at least once, but duplicates may occur.Final Answer:
At least once delivery of the message -> Option AQuick Check:
QoS 1 = At least once delivery [OK]
- Confusing QoS 1 with exactly once delivery
- Thinking QoS 1 has no delivery guarantee
- Mixing QoS 0 and QoS 1 guarantees
Solution
Step 1: Recall valid QoS values in MQTT
MQTT QoS levels are 0, 1, and 2 only; 3 is invalid.Step 2: Check syntax for publishing with QoS 2
The Paho client uses qos parameter in publish method; qos=2 is valid.Final Answer:
client.publish(topic, payload, qos=2) -> Option CQuick Check:
QoS 2 publish syntax = client.publish(..., qos=2) [OK]
- Using qos=3 which is invalid
- Omitting qos parameter defaults to 0
- Confusing qos=1 with qos=2 syntax
client.publish('sensor/data', 'temp=22', qos=0)
client.publish('sensor/data', 'temp=23', qos=1)
client.publish('sensor/data', 'temp=24', qos=2)
What is the expected behavior regarding message delivery?Solution
Step 1: Analyze QoS 0 message delivery
QoS 0 means message sent once, no retry, may be lost.Step 2: Analyze QoS 1 and QoS 2 messages
QoS 1 guarantees at least once delivery (may duplicate), QoS 2 guarantees exactly once delivery.Final Answer:
First message may be lost, second delivered at least once, third exactly once -> Option BQuick Check:
QoS 0=may lose, QoS 1=at least once, QoS 2=exactly once [OK]
- Assuming QoS 0 always delivers
- Confusing QoS 1 with exactly once
- Ignoring possible duplicates at QoS 1
client.publish('home/lights', 'ON', qos=2)
But the message is sometimes duplicated on the subscriber side. What is the likely cause?Solution
Step 1: Understand QoS 2 guarantees
QoS 2 guarantees exactly once delivery, so duplicates should not occur in transmission.Step 2: Identify cause of duplicates
If duplicates appear, likely the subscriber application is not filtering duplicates properly.Final Answer:
The subscriber is not handling duplicate messages properly -> Option DQuick Check:
QoS 2 = no duplicates in network, subscriber must handle duplicates [OK]
- Blaming QoS 2 for duplicates
- Assuming broker always supports QoS 2
- Thinking publish syntax is wrong
Solution
Step 1: Analyze requirements for reliability and no duplicates
The system needs reliable delivery and no duplicate messages despite unstable network.Step 2: Match QoS levels to requirements
QoS 0 is fastest but unreliable, QoS 1 may duplicate, QoS 2 guarantees exactly once delivery.Step 3: Confirm Raspberry Pi supports QoS 2
MQTT clients on Raspberry Pi support QoS 2, so it is suitable.Final Answer:
QoS 2, to guarantee exactly once delivery with no duplicates -> Option AQuick Check:
Reliable + no duplicates = QoS 2 [OK]
- Choosing QoS 1 and ignoring duplicates
- Thinking QoS 0 is reliable
- Assuming Raspberry Pi can't use QoS 2
Ready to prove it?
Pass the test and this pattern moves unknown
