[feature request] Notification on topic subscription.

[falemagn]

In order to avoid wasting time and bandwidth, I propose a mechanism by which a client would be notified by the broker whenever another client subscribed to a given topic, so that the former client could decide whether or not to publish anything on that topic.

This would work in a way similar to how bridge notifications work at the moment and would extend the current way of knowing how many subscriptions there are in total.

The client that wanted to be notified about a certain topic's subscription would subscribe to the following topic:

$SYS/broker/subscriptions/count/<monitored topic>

Where <monitored topic> is the topic the client is really interested about.

The broker would publish on that topic the current amout of subscriptions to the monitored topic, whenever that number changed. Therefore, a client that wanted to publish something on a topic only whenever that topic has been subscribed to, would be informed when the count would become greater than 0 or would become equal to 0 again, and start or stop publishing to that topic accordingly.

If such a feature is deemed desirable, I could work on it myself.

[ralight]

I think this is covered in a slightly different way in the MQTT 5 spec. When you publish a message with QoS > 0 then one of the responses can be "no matching subscribers.

Alternatively, you could have clients subscribe to $SYS/broker/log/M/subscribe and $SYS/broker/log/M/unsubscribe to see subscribe and unsubscribe events.

I need to have a think about your actual suggestion.

[falemagn]

I think this is covered in a slightly different way in the MQTT 5 spec. When you publish a message with QoS > 0 then one of the responses can be "no matching subscribers.

That means that the message has to be published first, doesn't it? It would then defy the objective of saving bandwidth and time: the client still has to send (possibly huge amout of) message data to the broker.

Alternatively, you could have clients subscribe to $SYS/broker/log/M/subscribe and $SYS/broker/log/M/unsubscribe to see subscribe and unsubscribe events.

Didn't know about these topics. Using those would mean that the clients would have to parse the log messages: are those guaranteed to stay the same in format, for the time being?

Also, and I believe this is a stumbling block, if a client connects the the broker after a certain topic has already been subscribed to, the information won't be catched.

[Pell17]

Also, and I believe this is a stumbling block, if a client connects the the broker after a certain topic has already been subscribed to, the information won't be catched.

The broker could simply publish the information as a retained message.