enhancement: add support to publish message to specific clients

[maxwang789]

Release notes

What does this PR do?

add support to publish message to specific clients

It's a fixed version of #786

Why is it important/What is the impact to the user?

The original request is that one request will be sent to topic "/request", but the response should be sent back on another topic "/response".
With these modifications, the embedding broker could distinguish all connections and support such send/resp mechanism without MQTT5 version.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files (and/or docker env variables)
• I have added tests that prove my fix is effective or that my feature works
• I have updated the Changelog if it's a feature or a fix that has to be reported

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

[maxwang789]

I don't change the semantics of NO_FILTER this time, but I think NO_FILTER should be unmodifiable.

[andsel]

Hi @maxwang789 thanks for your interest in the project.
I think that this a deviation from MQTT protocol, all client subscribed to topics that matches the topic on which publish is done, has to be notified of a message. The MQTT 3.1 and MQTT 3.1.1 doesn't specify anything of this shape, so could be considered a break of the protocol.

[maxwang789]

Hi @maxwang789 thanks for your interest in the project. I think that this a deviation from MQTT protocol, all client subscribed to topics that matches the topic on which publish is done, has to be notified of a message. The MQTT 3.1 and MQTT 3.1.1 doesn't specify anything of this shape, so could be considered a break of the protocol.

HI @andsel You are correct, this is not part of MQTT specification.
But we are facing some old equipment which already implemented such mechanism.
We have no choice by to adopt this legacy interface.
And in the same time we should try not make any side effect to normal user which follow MQTT spec.
This method only available inside an embedded server, the external subscriber/publisher could not access it and they will not notice any change.

[andsel]

Hi @maxwang789 I understand your reason, but internalPublish is an API method that Server provides to it's consumers. So the ask here is to modify a published API intended to respect the MQTT protocol to satisfy a specific request that's outside the protocol specification.
If you provide any number of valid use cases would be helpful , because as I can understand it so satisfy your specific requirements.
Having more context, for example which devices claims to be MQTT compliant (while in reality they aren't) and if it solves a specific use case or is more general, would help understand if it worthwhile to go outside of specs or not.
For example, I don't know if other brokers implements such customizations.