Process Flow - QoS levels (0, 1, 2)
Start: Publish Message
Check QoS Level
QoS 0
Send
No Ack
Done
Done
The flow shows how a message is published with different QoS levels, each with increasing delivery guarantees and acknowledgement steps.
0
0
QoS levels (0, 1, 2) in IOT Protocols - Step-by-Step Execution
Execution Sample
IOT Protocols
Publish message with QoS 1 Send message Wait for PUBACK If no PUBACK, resend End
This code simulates sending a message with QoS 1, waiting for an acknowledgement, and retrying if needed.
Process Table
| Step | QoS Level | Action | Acknowledgement | Result |
|---|---|---|---|---|
| 1 | 0 | Send message once | No ack expected | Message sent, no retry |
| 2 | 1 | Send message | Wait for PUBACK | If PUBACK received, done |
| 3 | 1 | No PUBACK received | Timeout | Resend message |
| 4 | 1 | PUBACK received after resend | PUBACK received | Done |
| 5 | 2 | Send PUBLISH message | Wait for PUBREC | If PUBREC received, send PUBREL |
| 6 | 2 | Send PUBREL | Wait for PUBCOMP | If PUBCOMP received, done |
| 7 | 2 | No PUBREC received | Timeout | Resend PUBLISH |
| 8 | 2 | No PUBCOMP received | Timeout | Resend PUBREL |
| 9 | 2 | PUBCOMP received | PUBCOMP received | Done |
💡 Execution stops when the final acknowledgement is received or no retry is needed.
Status Tracker
| Variable | Start | After Step 1 | After Step 2 | After Step 3 | After Step 4 | After Step 5 | After Step 6 | After Step 7 | After Step 8 | Final |
|---|---|---|---|---|---|---|---|---|---|---|
| Message Sent | No | Yes (QoS0) | Yes (QoS1) | Yes (QoS1 resend) | Yes (QoS1) | Yes (QoS2) | Yes (QoS2) | Yes (QoS2 resend) | Yes (QoS2 resend PUBREL) | Yes (QoS2) |
| Acknowledgement Received | No | N/A | No | No | Yes (PUBACK) | No | Yes (PUBREC) | No | Yes (PUBCOMP) | Yes |
| Retries | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 1 | 1 | 1 |
Key Moments - 3 Insights
Why does QoS 0 not wait for any acknowledgement?
Because QoS 0 means 'fire and forget'; the message is sent once without expecting any confirmation, as shown in execution_table step 1.
What happens if the PUBACK is not received in QoS 1?
The message is resent until PUBACK is received, as shown in execution_table steps 3 and 4 where a resend occurs after timeout.
Why does QoS 2 have two acknowledgement steps?
QoS 2 ensures exactly once delivery using a two-phase handshake: PUBREC and PUBCOMP, shown in execution_table steps 5-9.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution table, at which step does QoS 1 resend the message?
💡 Hint
Check the 'Action' and 'Result' columns for QoS 1 in execution_table rows.
According to variable_tracker, how many retries happen for QoS 2?
💡 Hint
Look at the 'Retries' row under 'After Step 7' and 'After Step 8' columns.
If QoS 0 sent a message, what is the acknowledgement status immediately after?
💡 Hint
Refer to execution_table step 1 and variable_tracker 'Acknowledgement Received' for QoS 0.
Concept Snapshot
QoS Levels in MQTT: - QoS 0: Send once, no ack, possible loss - QoS 1: Send, wait PUBACK, resend if no ack - QoS 2: Two-phase ack (PUBREC, PUBCOMP), exactly once delivery Each level increases delivery guarantee and network traffic
Full Transcript
This visual execution shows how MQTT QoS levels 0, 1, and 2 handle message delivery. QoS 0 sends the message once without waiting for acknowledgement. QoS 1 sends the message and waits for a PUBACK; if none arrives, it resends until acknowledged. QoS 2 uses a two-step handshake with PUBREC and PUBCOMP to ensure the message is delivered exactly once. The execution table traces each step, showing actions and acknowledgements. Variable tracking shows message sent status, acknowledgements received, and retry counts. Key moments clarify common confusions about acknowledgements and retries. The quiz tests understanding of when resends happen and acknowledgement expectations. This helps beginners see how MQTT ensures message delivery reliability with increasing levels of guarantee.