MQTT QoS Playground

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

animation
mqtt
qos
reliability
iot-protocols
In 60 Seconds

This playground simulates MQTT QoS levels 0, 1, and 2 under configurable network conditions (packet loss, latency, connection drops), with animated handshake flows, delivery statistics, and a side-by-side comparison mode to see all three levels simultaneously.

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.

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
Tool 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
How 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

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.

QoS 0: At Most Once (Fire and Forget)

QoS 0 Characteristics

Message Flow:

Figure 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

QoS 1: At Least Once

QoS 1 Characteristics

Message Flow:

Figure 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

QoS 2: Exactly Once

QoS 2 Characteristics

Message Flow:

Figure 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

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

Decision Flowchart

Network Condition Effects

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)

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)
High 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

Practical Examples

Smart Home System

Figure 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)

Industrial IoT

Figure 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

Common Issues and Solutions

QoS Mismatch Problem

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

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

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

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
Session 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

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