Used to divide the topic level, / topic after division, this is a very important symbol in the message topic hierarchy design
eg: aaaa/bbbb and aaaa/bbbb/cccc and aaaa/bbbb/cccc/dddd, this message topic format is a progressive relationship, which can match both at the same time through multi-level wildcards, or single-level wildcards only Match one. In real scenarios, this can be applied to: company department-level push, national city-level push and other scenes that contain hierarchical relationships.
2. Single-level wildcard—-"+":
Single-level wildcards can only match one level of themes. eg: aaaa/+ can match aaaa/bbbb, but cannot match aaaa/bbbb/cccc. A single + sign can match all pushes of a single layer
3. Multi-layer wildcard —-"#":
#: Multi-layer wildcard, multi-layer wildcard can match multi-layer themes. For example: aaaa/# can not only match aaaa/bbbb, but also aaaa/bbbb/cccc/dddd. In other words, multi-level wildcards can match all subset topics that match the topic level before the wildcard. The single # matches all message subjects.
4. Wildcard —-"$":
The wildcard "$" means to match a character, as long as it is not placed at the very beginning of the subject, that is:
$xx/$xx/xx$
In other cases, it means to match a character.
If the client wants to receive messages with a topic starting with "SYS/" and messages with a topic not starting at the same time, it needs to subscribe to "#" and ""$SYS/#" at the same time.
5.Summary:
a. All topic names and topic filters must contain at least one character
b. Subject names or subject filters are distinguished by a leading or trailing slash "/"
c. The subject name or subject filter that only contains the slash "/" is legal
d. The subject name and subject filter are UTF-8 encoded strings, and they cannot exceed 65535 bytes
e. Subject names and subject filters are case sensitive
f. Single-level wildcards and multi-level wildcards can only be used to subscribe to (subscribe) messages but not to publish (publish) messages. The level separator can be used in both cases
MQTT topic design experience:
a. Don't add / for example: /home/device/light at the top, which means that there is an empty string level at the top. This is completely unnecessary and adds broker and other processing. Home/device/light is reasonable. .
b. Just use English + numeric characters, do not use spaces, special characters, which will increase the complexity of processing, and sometimes there will be compatibility issues
c. There are many reasons for including the device ID or identification code in the topic: it is convenient to subscribe to specific devices, to facilitate subsequent filtering, and to facilitate access control
d. Do not create a good understanding of topic during operation. It is better to communicate with expectations. In a large-scale system, arbitrary creation of topics will lead to maintenance difficulties and increased processing complexity. The most important thing is definitely very easy to cause omissions and unknown behaviors.
e. The naming is simple and clear. It’s too long to read. It’s too tired to read, it will be confused if you don’t understand it, and it’s easy to make mistakes if it is too tired or confused;
f. The topic should be as detailed as possible, and be able to locate different devices and messages in detail