Can we have / in the topic string?

[Vivek M]

Hi,

I am evaluating MQTT(mosquitto) for our project where there is a use case of having / in the topic string.

For eg, An interface name in our switch or router is follows the convention ge-0/0/0 and our customers are so used to this convention when they use our box.
where
    ge indicates gigabit ethernet
    0/0/0 indicates slot 0/ pic 0 and port 0.

We plan to publish the above name in our topic using MQTT. However / is not taken in the topic string. And the MQTT documentation doesn't say clearly that /  cannot be part of topic string. Any way, with escape sequence or other hacks to achieve this?

Thanks,
Vivek
   

[Paul Fremantle]

Vivek

You have two options. 

1) You can use / in your string and make the topic hierarchy match the existing naming.

e.g. ge-0/# will get all messages about gigabit ethernet slot 0

       ge-0/0/# will get all messages about gig ethernet slot 0, pic 0.

       ge-0/0/0 with get messahe about gig ethernet slot 0, pic0, port0

2) You can replace the / with a different character and lose the hierarchy. 

I would think #1 is a better option.

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+uns...@googlegroups.com.
To post to this group, send email to mq...@googlegroups.com.
Visit this group at http://groups.google.com/group/mqtt.
For more options, visit https://groups.google.com/d/optout.

--

Paul Fremantle

Part-time PhD student - School of Computing

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

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

CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair, Apache Member
07740 199 729

[Vivek M]

Hi Paul,

Thanks for your reply.

I forgot to mention that there are other interfaces as well which don't have a / in its name. For eg, loopback interface named lo0.

So we cant go with second option and also it is not user friendly.

On the first option, we might face issues with wildcard matches when we use + in the subscription string that substitutes for interface name.

So, I would like to know in general is there a way to mention that / should not be treated as separator while subscribing for topics with + whose value can include / ? For eg, if interfaces/<if-name>/<line-rate-in-Gbps> is a topic and the subscription string is interfaces/+/1, then only the topics with interfaces having line-rate of 1 Gbps should be published. And the + should substitute for the exact interface name like ge-0/0/1 and should not consider the / as separator but rather it should be taken as part of the topic string.

Thanks,
Vivek

[Nicholas O'Leary]

Hi Vivek,

no, it is not possible to escape / characters so they get ignored by the wildcards.

Regards,

Nick

[Paul Fremantle]

Vivek

I don't mean to be tricky, but you are basically asking for the impossible.

 If I read your email properly you are asking for the / to sometimes mean / and other times be considered as a normal character and you aren't willing to swap it.

I can't see how that would be possible without adding a very complex set of non-standard logic to a broker (which would also severely impact performance). 

The fundamental answer is that the spec says that / is a reserved meaning, which is well defined. You can either do a global swap before and after using the string as a topic (Option #2) or you can accept the MQTT meaning (Option #1). I don't think there are any other options.

Paul

[Vivek M]

Thanks Nick. Any idea on is it being considered to include escaping characters like / in the topic string as part of MQTT standards? I feel it will be really helpful.

[Nicholas O'Leary]

Vivek,

we've managed for 15 years without needed it. There's always a way around it - as Paul has outlined.

Personally, I would do the swap of / for some other character in your interface names - for example: ge-0:0:0.

If you're exposing the MQTT side of things to your users, then they will need to know about this change. If it is entirely an internal function, there you can also swap the / back in before presenting the string to a user.

[Vivek M]

Thanks for your suggestions Nick and Paul.

I was more interested in knowing whether there is any way to do this or is this in pipeline.

Thanks,
Vivek

[Andy Stanford-Clark]

FWIW, I've run into this before, and had the client substitute the offending character ("+" in my case) for "{plus}" just before publish and then reverse it in the subscriber as soon as the message arrives.
All the application code sees the character it expects, but the reserved MQTT character is taken out.

Andy