Why constrain multi-level wildcard '#' to the end? And why only one?

[Eric Tsai]

I sometimes think it would be useful to have multi-level wild cards in the middle, or maybe have multiple multi-level wild cards.  I know MQTT doesn't allow this, that the '#' has to be at the end of the subscription topic string.  Why does MQTT constrain the use of the # wild card like this?

Thanks,
Eric

[Paul Fremantle]

Eric

I'm not sure of the answer. Maybe Andy SC can jump in. I think it was probably designed that way so that small broker implementations like RSMB could process it efficiently.

Paul

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--

Paul Fremantle

Doctoral Researcher, University of Portsmouth, School of Computing

Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart

Visiting Lecturer, Software Engineering Programme, Oxford University

Co-Founder, WSO2
Apache Member and Committer

email: paul.fr...@port.ac.uk, pa...@fremantle.org

twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org

[John Archbold]

Hi Eric,

I think '+' is used for what you are proposing as an interior multi-level wildcard.

--

[ran...@bevywise.com]

Eric 

The need for the # in the middle of the topic is needed for the implementation of the multiple parallel hierarchy.  The application will be very much loaded and the code base will be very tough to maintain and do additions when we start using # at the middle. 

So keep your topics in both the hierarchy and use # at the end. 

Take an example of a facility with 4 floors and 3 apartments each.  An Air conditioner in an apartment 3 of floor 2 should be controlled via two topics 

/facility/floor_2/appartment_3/AC_x  and at the same time /facility/AC/AC_X ,  So when you want to control or send command to the all components of appartment_3, you can use /facility/floor_2/appartment_3/# and when you want to send command to all air conditioners, you can use /facility/AC/#

All real world operations including HRM , CRM or any device management will follow this multiple hierarchy. 

Hope this solves your need of using the # at the middle. 

Best,

Ranjith 

CEO, Bevywise Networks

www.bevywise.com 

[Andy Stanford-Clark]

@eric/paul 

as @ranjith said, it’s to do with complexity of implementation of the topic matcher in the broker.

If you allow an arbitrary number of clauses (slash-delimited sections) to match in the middle of a topic, and then have to match some others at the end,  then you have to pretty much implement a regex parser (with backtracking and stuff), which we really didn’t want to force on anyone implementing a lean, mean, high-scale broker.

@John, no, a + is a *single* level wild card. You can only have a # at the end for ‘the rest of the sub-tree.

@ranjith careful - you can’t *control* things with a wildcard - + and # are for subscriptions for receiving a range of topics (e.g. all the air conditioners). You have to give an explicit topic name in a publish message.

Andy

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

[John Archbold]

I must be mis-interpreting this discussion. Following is the section from

https://mosquitto.org/man/mqtt-7.html.

Clearly "+/+/+" is valid.

as is "+/AC/#"

To me, this looks like a single-level wildcard, followed by a topic AC, followed by a multi-level wildcard.

If you want "#/AC/#" it would make no sense as the AC is redundant - the # would include AC, and the following #.

+ can be used as a wildcard for a single level of hierarchy. It could be used with the topic above to get information on all computers and hard drives as follows:

• sensors/+/temperature/+

As another example, for a topic of "a/b/c/d", the following example subscriptions will match:

• a/b/c/d

• +/b/c/d

• a/+/c/d

• a/+/+/d

• +/+/+/+

The following subscriptions will not match:

• a/b/c

• b/+/c/d

• +/+/+

# can be used as a wildcard for all remaining levels of hierarchy. This means that it must be the final character in a subscription. With a topic of "a/b/c/d", the following example subscriptions will match:

• a/b/c/d

• #

• a/#

• a/b/#

• a/b/c/#

• +/b/c/#

Zero length topic levels are valid, which can lead to some slightly non-obvious behaviour. For example, a topic of "a//topic" would correctly match against a subscription of "a/+/topic". Likewise, zero length topic levels can exist at both the beginning and the end of a topic string, so "/a/topic" would match against a subscription of "+/a/topic", "#" or "/#", and a topic "a/topic/" would match against a subscription of "a/topic/+" or "a/topic/#".

[ran...@bevywise.com]

Thanks @Andy for the caution. 

We rely on the transformation engine based on rules at the broker side. But for the platform, we support the wild card as it is the standard. 

The rule engine helps in sending messages to individual topics subscribed based on the message received from the publisher than publishing it to the wild card.

Thanks,

Ranjith

Bevywise Networks. 

On Monday, July 24, 2017 at 3:48:08 AM UTC+5:30, andysc wrote:

@eric/paul 

as @ranjith said, it’s to do with complexity of implementation of the topic matcher in the broker.

If you allow an arbitrary number of clauses (slash-delimited sections) to match in the middle of a topic, and then have to match some others at the end,  then you have to pretty much implement a regex parser (with backtracking and stuff), which we really didn’t want to force on anyone implementing a lean, mean, high-scale broker.

@John, no, a + is a *single* level wild card. You can only have a # at the end for ‘the rest of the sub-tree.

@ranjith careful - you can’t *control* things with a wildcard - + and # are for subscriptions for receiving a range of topics (e.g. all the air conditioners). You have to give an explicit topic name in a publish message.

Andy

On 21 Jul 2017, at 12:06, Paul Fremantle <paul.fr...@port.ac.uk> wrote:

Eric

I'm not sure of the answer. Maybe Andy SC can jump in. I think it was probably designed that way so that small broker implementations like RSMB could process it efficiently.

Paul

On 21 July 2017 at 05:18, Eric Tsai <ericm...@gmail.com> wrote:

I sometimes think it would be useful to have multi-level wild cards in the middle, or maybe have multiple multi-level wild cards.  I know MQTT doesn't allow this, that the '#' has to be at the end of the subscription topic string.  Why does MQTT constrain the use of the # wild card like this?

Thanks,
Eric

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--

Paul Fremantle

Doctoral Researcher, University of Portsmouth, School of Computing

Visiting Scientist, Institute of the Architecture of Application Systems, Stuttgart

Visiting Lecturer, Software Engineering Programme, Oxford University

Co-Founder, WSO2
Apache Member and Committer

email: paul.fr...@port.ac.uk, pa...@fremantle.org

twitter: pzfreo / skype: paulfremantle / blog: http://pzf.fremantle.org

[Andy Stanford-Clark]

No, you’ve got it right.. it was just that in your earlier post you said:

>I think '+' is used for what you are proposing as an interior multi-level wildcard.

it was the “multi” I was objecting to, as that should have said “single”, as you describe below :)

Andy

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+uns...@googlegroups.com.

[Andy Stanford-Clark]

no wonder I was confused ;)

[John Archbold]

Thanks Andy. (Otherwise I would have a serious amount of code to re-write :) ) 

Cheers, John

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.

To post to this group, send email to mq...@googlegroups.com.
Visit this group at https://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--
To learn more about MQTT please visit http://mqtt.org
---
You received this message because you are subscribed to the Google Groups "MQTT" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mqtt+unsubscribe@googlegroups.com.