1214  MQTT QoS Playground

Interactive Simulation of QoS Levels 0, 1, and 2 Under Various Network Conditions

animation
mqtt
qos
reliability
iot-protocols

1214.1 MQTT QoS Playground

This interactive tool helps you understand MQTT Quality of Service (QoS) levels through hands-on simulation. Experiment with different network conditions and observe how each QoS level handles packet loss, latency, and connection drops.

1214.2 Learning Objectives

By using this interactive tool, you will be able to:

  • Visualize QoS handshakes: See the message exchange patterns for QoS 0, 1, and 2
  • Understand reliability trade-offs: Experience how each level handles network failures
  • Compare delivery guarantees: Use comparison mode to see all three levels side-by-side
  • Identify appropriate QoS selection: Learn when to use each level based on requirements
  • Analyze statistics: Track success rates, duplicates, and message ordering
NoteTool Overview

The QoS Playground simulates MQTT message delivery under configurable network conditions:

  1. QoS Level Selection: Choose between QoS 0 (At Most Once), QoS 1 (At Least Once), or QoS 2 (Exactly Once)
  2. Network Condition Sliders: Configure packet loss percentage, latency, and connection drop probability
  3. Message Simulation: Send messages and watch the handshake flow in real-time
  4. Visual Flow Diagram: Animated visualization of PUBLISH, PUBACK, PUBREC, PUBREL, and PUBCOMP messages
  5. Statistics Panel: Track delivery success rate, duplicate messages, and ordering issues
  6. Comparison Mode: Run all three QoS levels simultaneously under identical conditions
TipHow to Use This Tool
  1. Select a QoS level using the tabs or comparison mode toggle
  2. Adjust network conditions with the sliders (packet loss, latency, connection drops)
  3. Click “Send Message” to simulate a message transmission
  4. Observe the handshake in the flow diagram panel
  5. Check statistics to see delivery outcomes over multiple messages
  6. Try pre-built scenarios to quickly test different network environments
  7. Use comparison mode to see how different QoS levels perform under the same conditions

1214.3 Understanding MQTT QoS Levels

MQTT Quality of Service (QoS) defines the delivery guarantee between the sender and receiver. Each level trades off reliability against latency and network overhead.

1214.3.1 QoS 0: At Most Once (Fire and Forget)

NoteQoS 0 Characteristics

Message Flow:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Client
    participant B as Broker
    C->>B: PUBLISH
    Note over C,B: No acknowledgment (fire and forget)

Figure 1214.1: QoS 0 message flow: single PUBLISH with no acknowledgment

Behavior:

  • Message sent once with no acknowledgment
  • Broker does not store the message
  • No retry if delivery fails
  • Fastest and lowest overhead

When to Use:

  • High-frequency telemetry (temperature every 10 seconds)
  • Data where occasional loss is acceptable
  • Constrained devices needing minimal power consumption
  • Situations where newer data supersedes older data

1214.3.2 QoS 1: At Least Once

TipQoS 1 Characteristics

Message Flow:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Client
    participant B as Broker
    C->>B: PUBLISH
    B->>C: PUBACK
    Note over C,B: Two-way handshake

Figure 1214.2: QoS 1 message flow: PUBLISH followed by PUBACK acknowledgment

Behavior:

  • Message stored until PUBACK received
  • Sender retries if no acknowledgment within timeout
  • Guaranteed delivery but may cause duplicates
  • Moderate overhead

When to Use:

  • Alert messages (door opened, motion detected)
  • Status changes that must be delivered
  • When duplicates can be handled (idempotent operations)
  • Most common choice for IoT applications

1214.3.3 QoS 2: Exactly Once

WarningQoS 2 Characteristics

Message Flow:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant C as Client
    participant B as Broker
    C->>B: 1. PUBLISH
    B->>C: 2. PUBREC
    C->>B: 3. PUBREL
    B->>C: 4. PUBCOMP
    Note over C,B: Four-way handshake ensures exactly once

Figure 1214.3: QoS 2 message flow: four-way handshake with PUBLISH, PUBREC, PUBREL, and PUBCOMP

Behavior:

  • Four-way handshake ensures exactly one delivery
  • Message ID tracked to prevent duplicates
  • Highest reliability but slowest
  • Significant overhead

When to Use:

  • Critical commands (unlock door, start engine)
  • Financial transactions
  • When duplicates would cause problems
  • Low-frequency, high-importance messages

1214.4 QoS Selection Guide

Factor QoS 0 QoS 1 QoS 2
Latency Lowest Medium Highest
Bandwidth Lowest Medium Highest
Battery Usage Lowest Medium Highest
Message Loss Possible No No
Duplicates No Possible No
Complexity Simple Moderate Complex

1214.4.1 Decision Flowchart

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#FFFFFF', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
flowchart TD
    A[New Message to Send] --> B{Is duplicate harmful?}
    B -->|Yes| C{Is loss acceptable?}
    B -->|No| D{Is loss acceptable?}
    C -->|Yes| E[QoS 0: Fire and Forget]
    C -->|No| F[QoS 2: Exactly Once]
    D -->|Yes| E
    D -->|No| G[QoS 1: At Least Once]

    style E fill:#16A085,color:#FFFFFF
    style F fill:#9B59B6,color:#FFFFFF
    style G fill:#E67E22,color:#FFFFFF

1214.5 Network Condition Effects

1214.5.1 Packet Loss Impact

QoS 0% Loss 10% Loss 30% Loss 50% Loss
QoS 0 100% delivered ~90% delivered ~70% delivered ~50% delivered
QoS 1 100% delivered 100% (retries) 100% (more retries) 100% (many retries)
QoS 2 100% delivered 100% (retries) 100% (more retries) 100% (many retries)

1214.5.2 Latency Considerations

  • QoS 0: Message latency = network latency
  • QoS 1: Message latency = 2x network latency (PUBLISH + PUBACK)
  • QoS 2: Message latency = 4x network latency (four-way handshake)
ImportantHigh Latency Networks

On satellite links (500-800ms RTT), QoS 2 can take 2-3 seconds to complete a single message delivery. Consider:

  1. Using QoS 1 with application-level deduplication
  2. Batching messages to amortize handshake overhead
  3. Accepting QoS 0 for non-critical telemetry

1214.6 Practical Examples

1214.6.1 Smart Home System

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
    subgraph QoS0["QoS 0 - At Most Once"]
        TS[Temperature Sensor<br/>Reading every 10s]
        EM[Energy Meter<br/>Usage Data]
    end

    subgraph QoS1["QoS 1 - At Least Once"]
        MS[Motion Sensor<br/>Detection Alert]
        DS[Door Sensor<br/>Open/Close Status]
        LS[Light Switch<br/>On/Off]
    end

    subgraph QoS2["QoS 2 - Exactly Once"]
        SL[Smart Lock<br/>Lock/Unlock Cmd]
        AS[Alarm System<br/>Arm/Disarm Cmd]
    end

    style QoS0 fill:#16A085,stroke:#2C3E50,color:#fff
    style QoS1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style QoS2 fill:#9B59B6,stroke:#2C3E50,color:#fff
    style TS fill:#2C3E50,stroke:#16A085,color:#fff
    style EM fill:#2C3E50,stroke:#16A085,color:#fff
    style MS fill:#2C3E50,stroke:#E67E22,color:#fff
    style DS fill:#2C3E50,stroke:#E67E22,color:#fff
    style LS fill:#2C3E50,stroke:#E67E22,color:#fff
    style SL fill:#2C3E50,stroke:#9B59B6,color:#fff
    style AS fill:#2C3E50,stroke:#9B59B6,color:#fff

Figure 1214.4: Smart Home QoS recommendations: QoS 0 for frequent telemetry (temperature, energy), QoS 1 for alerts and status changes (motion, door, lights), QoS 2 for critical security commands (locks, alarm)

1214.6.2 Industrial IoT

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
    subgraph Critical["Critical Priority - QoS 2"]
        ES[Emergency Stop]
        SI[Safety Interlock]
    end

    subgraph High["High Priority - QoS 1"]
        TA[Threshold Alerts]
        PC[Production Count]
        FW[Firmware Update]
    end

    subgraph Standard["Standard Priority - QoS 0"]
        MT[Machine Telemetry]
    end

    Critical --> High --> Standard

    style Critical fill:#E74C3C,stroke:#2C3E50,color:#fff
    style High fill:#E67E22,stroke:#2C3E50,color:#fff
    style Standard fill:#16A085,stroke:#2C3E50,color:#fff
    style ES fill:#2C3E50,stroke:#E74C3C,color:#fff
    style SI fill:#2C3E50,stroke:#E74C3C,color:#fff
    style TA fill:#2C3E50,stroke:#E67E22,color:#fff
    style PC fill:#2C3E50,stroke:#E67E22,color:#fff
    style FW fill:#2C3E50,stroke:#E67E22,color:#fff
    style MT fill:#2C3E50,stroke:#16A085,color:#fff

Figure 1214.5: Industrial IoT QoS by priority: Critical operations (emergency stop, safety interlock) use QoS 2, high-priority events (alerts, production, firmware) use QoS 1, standard telemetry uses QoS 0

1214.7 Common Issues and Solutions

CautionQoS Mismatch Problem

The effective QoS is the minimum of publisher and subscriber QoS:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
    P[Publisher<br/>QoS 2] -->|Publish| B[Broker]
    B -->|Deliver| S[Subscriber<br/>QoS 0]
    B -->|Effective QoS| E[QoS 0!]

    style P fill:#9B59B6,stroke:#2C3E50,color:#fff
    style B fill:#2C3E50,stroke:#16A085,color:#fff
    style S fill:#16A085,stroke:#2C3E50,color:#fff
    style E fill:#E74C3C,stroke:#2C3E50,color:#fff

Figure 1214.6: QoS mismatch: Publisher sends at QoS 2 but subscriber receives at QoS 0 because effective QoS is the minimum of both

Solution: Ensure subscriber QoS matches or exceeds the required reliability level.

1214.7.1 Duplicate Handling for QoS 1

When using QoS 1, implement idempotent message handling:

# Bad: Non-idempotent operation
def handle_message(msg):
    counter += 1  # Duplicate increments twice!

# Good: Idempotent with message tracking
processed_ids = set()

def handle_message(msg):
    if msg.id in processed_ids:
        return  # Skip duplicate
    processed_ids.add(msg.id)
    counter += 1

1214.7.2 Session Persistence with QoS

QoS 1 and 2 messages are stored only if:

  1. Clean Session = false (persistent session)
  2. Subscriber is offline when message arrives
  3. Message QoS >= 1
NoteSession State Storage
Component Clean Session = true Clean Session = false
Subscriptions Cleared on disconnect Persisted
Pending QoS 1/2 Discarded Stored for delivery
Message IDs Reset Maintained

1214.8 What’s Next


This interactive tool is implemented in approximately 1,000 lines of Observable JavaScript. Key features:

  1. QoS Level Simulation: Accurate simulation of QoS 0, 1, and 2 message flows
  2. Network Condition Modeling: Configurable packet loss, latency, and connection drops
  3. Visual Flow Animation: Step-by-step handshake visualization with D3.js
  4. Statistics Tracking: Real-time delivery success, loss, and duplicate counts
  5. Comparison Mode: Side-by-side comparison of all three QoS levels
  6. Pre-built Scenarios: Five network condition presets for quick testing

Educational Simplifications:

  • Real MQTT implementations use exponential backoff for retries
  • Session persistence and message queuing not fully simulated
  • Network conditions are simplified (no jitter, congestion simulation)
  • Broker-side QoS downgrade not demonstrated

Color Palette (IEEE standard):

  • Navy (#2C3E50): Primary UI, broker
  • Teal (#16A085): QoS 0, success states
  • Orange (#E67E22): QoS 1, warnings
  • Purple (#9B59B6): QoS 2
  • Green (#27AE60): Delivery success
  • Red (#E74C3C): Failure, lost messages