Publisher
Living-room sensor publishes a concrete temperature topic.
MQTT Pub/Sub Routing Workbench
MQTT Pub/Sub Routing Workbench
Route MQTT publications through exact topic filters, wildcards, retained state, and QoS caps.
animation
mqtt
protocols
Learner-ready MQTT publish-subscribe workbench with scenario presets, step/play controls, topic-filter validation, wildcard matching, retained-message behavior, QoS delivery calculation, source links, and desktop/mobile visual verification.
MQTT Pub/Sub Routing Workbench
Publishers send to a concrete Topic Name. The broker compares that name with each subscriber Topic Filter, then fans out one copy to every matching subscription using the appropriate delivery QoS.
Published topic
home/livingroom/temperature
Matching subscribers
3 matches
Broker output
3 copies
Delivery QoS
min(pub, sub)
TryChoose Multi-level wildcard, publish plant/line-a/pump-7/status at QoS 2, and give one subscriber maximum QoS 1.
ObserveMatching subscribers includes every filter whose # consumes remaining levels, while Delivery QoS becomes min(2,1)=1 for the capped subscriber.
ExplainFor QoS 2 publish, the broker compares Topic Names with subscription filters level by level; + matches 1 level, # matches a suffix, and subscription caps delivery QoS.
Technical boundariesRouting examples omit shared subscriptions, overlapping-filter duplicate rules, ACLs, topic aliases, subscription identifiers, retained handling details, session persistence, broker clustering, and packet loss.
Colour keyintegration gateways identitycurrent / primaryreference / datasuccesscautionerror / failure
1. Subscribe
2. Publish
3. Validate topic
4. Match filters
5. Fan out
6. Deliver
Configure publish
publish 1
risk: low
Application message
Payload: 22.4 C, Topic Name: home/livingroom/temperature.
Broker topic matcher
The broker validates the Topic Name, then tests it against each active subscription filter.
home/livingroom/temperature
A PUBLISH uses a Topic Name. Wildcards are reserved for subscription filters.
P
publisher
broker
subscribers
Routing trace
Step through subscription filters, publish validation, matching, fan-out, and delivery QoS.
Fan-out to every matching subscription
One PUBLISH can produce several broker-to-client deliveries because several subscriptions match the same Topic Name.
Quick reference
Topic Name vs Topic Filter
- PUBLISH uses a concrete Topic Name and cannot contain
+or#. - SUBSCRIBE uses a Topic Filter and may use wildcards if the wildcard occupies a whole level.
- The broker routes by comparing each Topic Name to active Topic Filters.
Wildcard rules
+matches exactly one topic level.#matches zero or more levels and must be the final level.home/#matcheshomeand every topic below it.
QoS and retained state
- Delivery QoS is the lower of the incoming publish QoS and the subscriber's maximum QoS.
- A retained publish also stores the latest value for that exact Topic Name.
- New subscribers can receive retained messages that match their filter.
Technical accuracy notes
Fan-out is per matching subscription
The broker sends an application message to every matching subscription. Shared subscriptions are a separate MQTT 5 feature and intentionally not modeled as normal fan-out here.
Duplicate paths are possible
If a client has overlapping subscriptions, MQTT 5 allows the server to send one copy or multiple copies depending on subscription identifiers and server behavior. This workbench flags overlap risk.
Retained does not mean queued
A retained message is the latest value for a Topic Name. It is not a historical queue, and a new retained publish replaces the retained value for that topic.