Critical Based on a query in MQTT Google group, a query was posted with a requirement that the server should not publish message to a subscriber if messages are published by the same client-id and subscribed by the using the same client-id for the same topic. In this case a client connection may both publish and subscribe to a topic and the subscriber should inhibit the delivery of messages published by its own connection. This feature is available in JMS and a subscriber can inhibit to receive publication by using the noLocal flag during subscription.
This feature is also needed to enable bridging and making proxy subscription between servers so as to stop messages going round in loops.
I would like propose to add a element in SUBSCRIBE Control packet for individual subscriptions to make a choice on noLocal parameter. This field could be shared in the same byte as for requstedQos.
I think that noLocal should not apply to shared subscriptions. If requested on a shared subscription it should result in an error on the subscribe.
TC agreed that if nolocal was requested on a shared subscription it should result in an error on the subscribe.
Apologies for my sloppy language in the previous comment. TC agreed that if nolocal was requested on a shared subscription it MUST result in an error being returned on the subscribe.
Issue included in MQTTv5.0 CS01 December 25, 2017
Shared Subscription (
MQTT-234) was introduced and discussed in the face to face meeting in April 2016. The proposals on shared subscription include that the MQTT server owns the shared subscription and it is not owned by any one session. This means that there could be situations where one of the client session which could be part of Shared subscription chose to say I am not interested in noLocal and the second client session in same shared subscription could suggest that its interested in noLocal. This could be a tricky situation for the MQTT server to handle and understand if the message originating from one of the sessions in the same group should be delivered to any one of the client in that group. I did a little more reading on how JMS 2.0 handled this situation.https://java.net/jira/browse/JMS_SPEC-40
"The JMS 2.0 expert group has agreed that the noLocal parameter serves no useful purpose for shared subscriptions (both durable and non-durable) and should be removed."
Not suggesting that we should think in similar lines, but it will be worth to understand complexities which will be introduced with the combination of noLocal and shared subscription use cases.