MQTT v5.0 support

[wrsrap]

Are there plans to support MQTT v5.0 in this plugin？Thank you.

[michaelklishin]

There are plans but we offer no ETA promises. The earliest release it can happen in will be 3.9.0.

[tsturzl]

I'm willing to contribute here as I'm coming up on needing the ability to use the Shared Subscription feature included in v5.0. If there's any general guidance you can give to how I could begin an implementation of this feature I'd be happy to make a PR hopeful in the near future.

[ajayb0507]

Hi, Is this still on schedule ? Thanks.

[michaelklishin]

It is still scheduled to be implemented but we offer no ETA as there are too many higher priority items on our roadmap. This is open source software so those who need MQTT v5.0 support can contribute it, or at the very list document all the differences from 3.1.1 which would greatly help with assessing the amount of work it would take.

[An0nymous0]

look forward to

[petersilva]

in case it is helpful, the feature that most interests me is shared queues. with AMQP 0.9 you just have multiple processes connect to the same queue to do sharing. with MQTTv3, only one consumer at a time. there is a concept of shared queues that promises to address that. Very interested in that feature in particular.

I think the idea is $share/group_name/topic_tree ...

where group_name would seem to map to a queue name (in the sense that it accomplishes the same level of grouping a multiple subscribers using a common queue) in AMQP.

[michaelklishin]

Shared queues with repeatable reads will be provided by streams in 3.9, not via MQTT but any future such features likely will lean on them.

[petersilva]

No need for new features on the rabbit side. The existing sharing of queues (has been there last ten years or so) is fine... I just have multiple subscribers connect to the same queue with a prefetch, and I can have 40 subscribers share a high speed queue (that does not build up.) I don't see a way to do that with MQTTv3. I think v5 might help.

[adiroiban]

For the reference, a document with differences between v3.1.1 and v5 - https://github.com/mqtt/mqtt.org/wiki/Differences-between-3.1.1-and-5.0

[briggySmalls]

For me a big appeal of v5.0 is the "Reason code on all ACKs" (in same link as @adiroiban).

If a client attempts to publish/subscribe to a topic that an ACL denies them, the MQTT 3.x specs silently accept the operation. MQTT 5.x introduces the return code for "Not authorised".

[petersilva]

What would be really cool for v5 support:
-- map each topic exchange to the root of mqtt topic tree.
-- prepend with $share/queue_name/exchange/ .... rest of the topics.

If the exchange is not a topic exchange, it does not participate in the mapping.
That way, people can connect to the same broker with either protocol and access the entire broker.

example:

I want five processes to use the same queue "worker" bind to "canada.public" topic on the "xwarnings" exchange in AMQP sharing the messages among the five. That should be equivalent to subscribing to "$share/worker/xwarnings/canada/public" in MQTT plugin.

[petersilva]

fwiw... I use this mapping here:
https://github.com/MetPX/sarracenia/tree/v03_wip/sarracenia/moth

There are MQTT and AMQP sub-classes of the "Messages Organized by Topic Header" I use mosquitto for the MQTT stuff, because the rabbitmq isn't rich enough currently.