Preventing Subscription Export

In an MNR or DMR network, subscriptions are advertised by the local node to other nodes in the network. This allows clients on the local node to receive messages that match their topic subscriptions that originate on other nodes.

The #noexport syntax allows you to specify that an individual subscription should not be exported, even if the subscriptions of the message VPN as a whole are being exported. This prevents messages published on remote nodes from being attracted to the subscriber on the local node.

The #noexport syntax applies only to subscriptions and is not supported for cache requests.

If the subscription is qualified with #noexport:

  • it only attracts messages published locally on the same broker where the subscriber is. It will not be advertised to adjacent nodes by MNR or DMR.
  • it is not exported to other nodes, even if the subscriptions of the message VPN as a whole are being exported (that is, if export-policy for the message VPN is set to export-subscriptions)

You can use #noexport with shared and non-shared subscriptions:

  • #noexport/#share/ShareName/topicFilter specifies a non-exported shared subscription, where ShareName is the shared subscription identifier, and topicFilter is the topic filter.
  • #noexport/topicFilter specifies a non-exported topic subscription

Even with #noexport specified on a subscription, it is still possible for the local node to receive messages whose topic matches that subscription and that originate on other brokers, if those messages are attracted to the local broker by some other exported subscription.

For example, suppose client C1 subscribes to #noexport/a/b, and another client C2 on the same broker subscribes to a/b. In this case, messages published with topic a/b on another broker are still received by C1. This is illustrated in the following diagram:

For more information, see: