MQTT QoS Playground

Compare MQTT QoS choices under packet loss, latency, retry limits, disconnects, and subscriber QoS caps.

animation
mqtt
qos
reliability
protocols
Learner-ready MQTT QoS network-condition playground with scenario presets, step/play protocol flow, deterministic trial comparison, effective subscriber QoS calculation, duplicate-risk guidance, and OASIS MQTT source links.
Animation MQTT QoS Network conditions

MQTT QoS Network Playground

Choose a network condition, step through the packet exchange, and compare how QoS 0, QoS 1, and QoS 2 behave when packets are lost, acknowledgements are delayed, or subscribers request a lower delivery QoS.

Scenario Crowded LPWAN gateway
Selected QoS QoS 1
Estimated delivery High with retries
Main risk Duplicates possible

1. Pick a network

Start with a preset such as a crowded gateway, satellite backhaul, or safety command path.

2. Choose QoS

Compare QoS 0, 1, and 2 as delivery guarantee, duplicate risk, and packet cost change.

3. Step the exchange

Use Step or Play to see which MQTT packet is active and why a retry may happen.

4. Read the tradeoff

The trial cards estimate delivery, duplicates, packets, and time for the same conditions.

1. PublishThe client sends PUBLISH toward the broker.
2. ConfirmQoS 1 and 2 require acknowledgements.
3. Retry or hold stateLoss changes retry count, packet cost, and delay.
4. DeliverThe subscriber receives at the lower effective QoS.
5. DecideMatch guarantee to safety, power, latency, and duplicate tolerance.

Packet exchange under the selected network

Packet loss is a teaching model here. Real MQTT clients have implementation-specific retry timers, session behavior, and reconnect policies, so use the comparison as a decision aid, not a certification test.

Active packet PUBLISH
Publisher application client
->
Broker tracks QoS state
Active packet PUBLISH
Broker applies subscription cap
->
Subscriber receives QoS 1
QoS 1 stores the message until PUBACK arrives.
MQTT QoS packet exchange between publisher, broker, and subscriber A publisher sends MQTT packets to a broker. The broker forwards to a subscriber at the effective subscriber QoS. A packet token moves along the active path. Publisher MQTT client Broker QoS state Subscriber requested cap lost PUBLISH QoS 1 stores the message until PUBACK arrives. Effective subscriber QoS = min(publisher QoS, subscriber requested QoS).
QoS 1 stores the message until PUBACK arrives. If PUBACK is lost, the publisher retries the PUBLISH. The broker may see the same Packet Identifier again, so the application must tolerate duplicates.
Live-window delivery High

Retries recover most lost PUBLISH packets in this scenario.

Duplicate risk Possible

QoS 1 can repeat PUBLISH after a lost PUBACK.

Packet pressure Moderate

Normal flow uses PUBLISH plus PUBACK; loss increases retries.

Recommendation Good fit

Use when confirmation matters and the application can deduplicate.

QoS comparison under this network

The same deterministic trial set is applied to QoS 0, QoS 1, and QoS 2 so learners can compare the tradeoff, not random luck.

Learning Support

What QoS means

QoS is a delivery promise for one MQTT hop. It does not prove that a door unlocked, a motor stopped, or a database transaction committed.

What to try first

Set packet loss above 20%, then compare QoS 0, 1, and 2. Watch delivery improve while packets and delay increase.

How to read duplicates

QoS 1 can deliver more than once when the receiver gets PUBLISH but the acknowledgement is lost. Use message IDs or idempotent handlers.

Technical Quick Reference

QoS 0

One PUBLISH packet. Lowest latency and packet cost. The message may be lost because the sender receives no MQTT acknowledgement.

QoS 1

PUBLISH plus PUBACK. The receiver should get the message at least once, but a lost PUBACK can make the sender retry and create duplicates.

QoS 2

PUBLISH, PUBREC, PUBREL, and PUBCOMP. Avoids duplicate MQTT delivery on that hop, but uses the most packets and state.

Effective subscriber QoS

The broker delivers at the lower of the publish QoS and the subscriber's requested QoS: min(publish, subscribe).

Retry budget

This playground uses a finite teaching retry budget. Real clients choose their own retransmission timing and reconnect behavior.

Practice Checks

Telemetry stream

A temperature sensor reports every 5 seconds and the latest reading replaces old readings. Start with QoS 0 unless loss changes the business need.

Alarm event

A motion alert should arrive, and duplicate events can be ignored by event ID. QoS 1 is usually a practical fit.

Non-idempotent command

A command that must not execute twice needs more than MQTT QoS. Use QoS 2 for the MQTT hop and application-level command IDs or confirmation.

Related MQTT Animations
MQTT QoS Delivery Workbench MQTT Pub/Sub Routing MQTT Session Management MQTT Retained Messages