Subscription notifications

[tjrmarques]

Hello,

In Zenoh, is there a way to get notified of declared/undeclared subscribers and their subscribed key expressions in general, i.e. without requiring a publisher for a specific key (as in MatchingListener)?

The goal/context is bridging between Zenoh and other Pub-Sub protocols without having to bulk-subscribe to all of the other protocol's topics when the Zenoh side has no subscribers for them (and thus reducing required network bandwidth).

[JEnoch]

No, for scalability reasons the declarations of subscribers are not propagated everywhere in a Zenoh system, and could even be squashed at some points (e.g. if a router receives on the same face 2 declarations of subscriptions for a/b/** and a/b/c/** it can only propagate the first one).
Even a MatchingListener doesn't get an exact view of the matching Subscribers, but just a MatchingStatus indicating if there is at least 1 matching Subscriber.

For your bridge use case, I see 2 solutions:

1. rely on discovery of pub/sub from the other protocol rather than on discovery of Zenoh pub/sub. That's how I implemented the DDS, ROS2 and MQTT bridges.
2. rely on LivelinessTokens that the Zenoh application must declare along each of its Subscriber. Actually we're considering to eventually add an option to declare_subscriber() for an automatic declaration of an associated LivelinessToken (knowing this could have scalability impacts).

[tjrmarques]

Hi @JEnoch,
Thank you for the quick answer.

"Filtered" subscription information would be enough, and I guess it must exist in the session otherwise Zenoh wouldn't be able to filter on the publisher side?

I did take a look at the DDS bridge before posting the question and it looks like it subscribes to every publisher discovered on the DDS side (which is still a form of bulk-subscription), so it's not really a solution for the bandwidth issue.

I'll look into the LivelinessToken option and comment back with my thoughts for anyone following.

Thanks again!

[JEnoch]

"Filtered" subscription information would be enough, and I guess it must exist in the session otherwise Zenoh wouldn't be able to filter on the publisher side?

The information exists, but only for the key expressions matching a declared Publisher (hence the MatchingStatus feature on Publisher). There is no reason to push all the existing subscriptions info to each Zenoh applications (that might run on devices with limited resources) if they will never publish on their key expressions.

I did take a look at the DDS bridge before posting the question and it looks like it subscribes to every publisher discovered on the DDS side (which is still a form of bulk-subscription), so it's not really a solution for the bandwidth issue.

That's correct in the default mode, but not with the "forward discovery" mode. Here the DDS bridge subscribes to a DDS topic only if a remote bridge forwards him the discovery information about a DDS subscription on this topic. I.e. there is a remote interest announced for the topic.

The ROS 2 DDS bridge behaves in the same way, but relies on Liveliness Tokens instead of discovery events forwarding. This simplifies the implementation, uses less bandwidth and brings the benefice of the automatic notification of Tokens deletions in case of network failures.

[tjrmarques]

My use case is a simple Zenoh-to-protocol translator, not a Zenoh bridge/router between two "clusters" of the other protocol's nodes, so the forward discovery mode (although interesting) does not really apply, as I have actual native Zenoh subscribers.

After some experimentation, this use case is indeed well served by the liveliness tokens, thanks again for the pointers and thorough answers!.