MQTT broker bridging lets you connect disparate MQTT clusters, enabling message exchange between them.
Let’s see it in action. Imagine two independent MQTT brokers, broker-a and broker-b, each managing their own set of clients. We want clients connected to broker-a to receive messages published by clients on broker-b, and vice-versa.
Here’s a simplified configuration for broker-a to bridge to broker-b:
# mosquitto.conf on broker-a
listener 1883
allow_anonymous true
# Bridge configuration
bridge_protocol_version 5
bridge_address broker-b.example.com:1883
bridge_retry_interval 15
bridge_clean_session true
bridge_username bridge_user
bridge_password bridge_password
bridge_cafile /etc/mosquitto/certs/ca.crt
bridge_certfile /etc/mosquitto/certs/client.crt
bridge_keyfile /etc/mosquitto/certs/client.key
# Topic forwarding rules
bridge_topic_in topic/a/# out
bridge_topic_out topic/b/# in
In this setup:
listener 1883:broker-ais listening for client connections on port 1883.bridge_protocol_version 5: Specifies the MQTT protocol version for the bridge. Version 5 offers enhanced features.bridge_address broker-b.example.com:1883: The address and port of the remote broker (broker-b) to whichbroker-awill connect.bridge_retry_interval 15: If the connection tobroker-bdrops,broker-awill attempt to reconnect every 15 seconds.bridge_clean_session true: Whenbroker-aconnects tobroker-b, it will start with a clean session, meaning any previously held subscriptions or QoS 1/2 messages not yet delivered will be discarded.bridge_username bridge_userandbridge_password bridge_password: Credentials forbroker-ato authenticate withbroker-b.bridge_cafile,bridge_certfile,bridge_keyfile: These lines configure TLS/SSL for the bridge connection, ensuring secure communication between the brokers.ca.crtis the Certificate Authority that signedbroker-b’s certificate.
The crucial part is how topics are handled:
bridge_topic_in topic/a/# out: This tellsbroker-ato forward messages published ontopic/a/#(onbroker-a) tobroker-b. Theoutdirection signifies that these messages are outgoing frombroker-a’s perspective to the remote broker.bridge_topic_out topic/b/# in: This tellsbroker-ato subscribe totopic/b/#(onbroker-b) and forward any messages it receives on that subscription to its local clients. Theindirection signifies that these messages are incoming tobroker-afrom the remote broker.
By configuring broker-b with similar but reversed bridge_topic_in and bridge_topic_out rules (e.g., bridge_topic_in topic/b/# out and bridge_topic_out topic/a/# in), you create a bidirectional bridge.
The primary problem bridging solves is distributed IoT deployments. Instead of having a single, massive broker handling all devices, you can have regional brokers that are then bridged together. This reduces latency for local devices, improves fault isolation (if one regional broker goes down, others can continue operating), and simplifies network management by allowing brokers to be placed closer to their client populations. It’s also a way to integrate different MQTT systems that might be managed by separate teams or even different organizations.
Bridging isn’t just about routing messages; it’s about creating a unified logical MQTT network from multiple physical instances. Each broker in the bridged setup maintains its own client connections and local message queues. When a message is published locally on a topic that has a corresponding bridge_topic_in rule, the broker acts as a client to the remote broker, publishing that message to the remote broker’s topic. Conversely, when a message arrives on the remote broker for a topic that broker-a is subscribed to via a bridge_topic_out rule, broker-a receives it and then publishes it to its local clients that are subscribed to that topic.
A common misconception is that bridging automatically synchronizes the entire broker state. This is not true. Bridging is solely focused on topic-based message routing. Client states, user credentials, and other broker-specific configurations remain independent unless explicitly managed or synchronized by external systems.
The most surprising aspect of MQTT bridging is its ability to create a seamless, unified topic namespace across geographically dispersed brokers without requiring a central orchestrator for message flow. While a central broker might exist for management or initial connection, the actual message traffic between bridged brokers is peer-to-peer based on the configured topic patterns. This inherent decentralization in message routing is key to its scalability and resilience.
The next challenge is often managing topic hierarchies and ensuring efficient routing without creating message loops or excessive network traffic.