Mosquito optimization--subscription tree optimization (eight)

This article is written by the carefree son, forwarded please mark the original site:

http://blog.csdn.net/houjixin/article/details/46413783

Or

http://houjixin.blog.163.com/blog/static/35628410201558423159/

8.1 Mosquitto's subscription tree mechanism

In the original version of Mosquitto, all the subscription relationships are maintained through a subscription tree, in the subscription tree, topic will be organized into a tree-like structure, 5-3 of the subscription tree, where each node of the subscription tree is a topic rating, The corresponding topic for each node is the topic from the root node to the current node, and the Star list next to each node is the list of subscriptions for that node.

Figure 8-1 Subscription Tree

In the Mosquitto original version of the program, the subscription tree is built according to topic, the number of topic and hierarchical form directly determines the shape of the subscription tree, thus affecting operational efficiency. In Mosquitto, the operation of the above subscription tree is primarily query, insert, and delete operations, all of which involve traversal of the subscription tree. Take the insert operation as an example, compare the content of topic each level to the nodes of the subscription tree, find the matching node, and if found, continue to the next level of match until the topic of the subscription succeeds, just hang the context into the subscription list of the current node of the subscription tree. If the content of the topic rating in the matching process does not match successfully, the subscribed topic does not already exist in the subscription tree, and the node that does not match in the topic rating is added to the subscription tree and the context is linked to the subscription list of the new build node. For example, if a new client Context1 subscribes to TOPIC:A1/B1/C1, the Mosquitto internally first divides the topic into A1, B1, and C1 three-level lists by "/". The contents of the topic list are then recursively matched to the contents of each node in the subscription tree, and the exact matching process is:

If the contents of the current Rating in the topic list are not empty and match the contents of the nodes in the subscription tree, continue to select the next rating in the topic list, matching the subtree of the current node in the subscription tree;

If the current rating in the topic list is not empty, and the node in the current tier of the subscription tree does not find a match to the rating content, a new node is added for the rating of topic, and the new node continues to match the root node of the subtree.

If the topic list is empty, it is hung to the subscription list corresponding to the current node of the corresponding subscription tree;

Figure 8-2 is the flowchart for the above matching process.

Figure 8-2 the matching process for the subscription tree

8.2. Optimization of subscription mechanism

Mosquitto's original tree-like structure for subscribed organizations has the advantage of being logically clear, but its insertion, lookup, and deletion are less efficient.

For this flaw of Mosquitto subscription tree, this optimization process will remove the subscription tree and use the hash table to store each topic and its subscription list. Hash table is mainly in order to quickly navigate to its subscription list through topic, so the hash table value is the address of each subscription list, key is the corresponding topic of the subscription list, the content is from the root node to the current node topic content composition, The hash table shown in Figure 5-3, for example, the node C1 corresponding hash table key is: A1/b1/c1,value timely LC1, for the subscription tree shown in Figure 5-3, the resulting subscription hash table 5-5 shows:

8-3 Subscription Hash table

8.3. Optimization method

The optimization of the subscription mechanism is mainly focused on the file subs.c, which involves the following interface functions:

Mqtt3_retain_queue

Mqtt3_subs_clean_session

Mqtt3_db_messages_queue

Mqtt3_sub_remove

Mqtt3_sub_add

In the Mqtt3_sub_add function, the main completion of the Mosquitto subscription operation, will first search the hash table for the existence of the context subscribed to the topic, if present, then hang it to the corresponding list of subscriptions, or create a new hash structure, This topic is saved in the struct and the context is attached to the topic subscription list.

The function Mqtt3_db_messages_queue mainly completes the Mosquitto message publishing operation, in which the topic will be split to check whether the various sub-topic ending with "#" exist in the subscription hash table, and if there is a message sent. For example, in a context where you want to publish a message to the topic: A1/B1/C1, you need to check in the function Mqtt3_db_messages_queue if the following topic exist in the subscription hash table:

a1/#

a1/b1/#

a1/b1/c1/#

a1/b1/c1/

If the subject exists in the hash table, the message is mounted to the message queue for each context of the corresponding topic subscription list.

The functions Mqtt3_sub_remove and mqtt3_subs_clean_session mainly complete the operation of clearing the context in the hash table, which requires that the topic subscribed by the context be saved beforehand, Simply find out if the topic it subscribes to exists in the subscription hash table, and if it does, remove the context from the subscription list, or return directly.

The function Mqtt3_retain_queue completes the save operation to a context message queue, it also does not need to traverse the subscription tree, only need to take out the subscribed topic according to the context of its operation. Then through the topic from the subscription hash table to find the corresponding context can call the _retain_process function to complete the operation directly.

The optimized Mosquitto program does not support wildcard "+", but wildcard "#" is supported.

Mosquito optimization--subscription tree optimization (eight)