What Are MQTT No Local and Retain As Published?

No Local: Not Hearing Your Own Echo

By default in publish/subscribe, if a client both publishes to a topic and subscribes to a pattern that matches it, the broker delivers the client's own message back to it. Usually harmless, but it becomes a real problem in two situations. The first is a bidirectional client that acts as both source and sink on overlapping topics and does not want to process its own output. The second, more serious, is a bridge that subscribes to a topic in order to forward it, because without care the forwarded message can come straight back and form a loop.

The no local option, set per subscription in MQTT 5, instructs the broker simply not to deliver to a client any message that client itself published on that subscription. It cleanly suppresses the echo at the source. This is the property that makes bridging between brokers safe, because a bridge can subscribe with no local set and know it will never receive back the very messages it just forwarded, which is the classic cause of a storm in a naively configured MQTT bridge.

There is a constraint worth knowing: no local cannot be used with a shared subscription. Because a shared subscription is deliberately shared among a group of clients rather than tied to one identity, the notion of a message being from this client is not well defined for the group, so the specification disallows the combination. That is rarely a limitation in practice, since the echo problem is a single-client concern that does not arise the same way in a load-balanced consumer group.

Retain As Published: Preserving the Flag Across a Hop

Normally, when the broker delivers a message to a subscriber, it clears the retain flag on the copy it delivers unless the message is being sent because it is the retained value for a new subscription. This default keeps ordinary subscribers from misinterpreting live traffic as retained state. But it causes trouble for a bridge, because a bridge subscribes to receive messages and then republishes them onto another broker, and if the retain flag has been stripped on the way in, the republished message loses its retained status and the second broker no longer holds a last-known value.

The retain as published option, also set per subscription, tells the broker to leave the retain flag exactly as the original publisher set it on the messages it forwards to this subscriber. A bridge subscribing with retain as published sees each incoming message with its true retained status intact, so when it republishes, it can faithfully reproduce whether the value should be retained on the far side. This keeps retained state consistent across a multi-broker fabric.

Both options are, in the end, tools for the same audience: people building fabrics rather than single-broker systems. A lone gateway talking to one broker rarely needs either. The moment you introduce a second broker, a bridge, or a bidirectional client, no local prevents loops and self-processing, and retain as published preserves the last-known-value semantics that a naive bridge would silently destroy. Reaching for them is a sign you are past the simplest topology and into real integration.

Frequently Asked Questions