Multi-thread flow control method under MQTT protocol and communication equipment

Abstract

The invention relates to a multi-thread traffic control method under an MQTT protocol and communication equipment, relates to the technical field of Internet of Things, and solves the problem that traffic control is unreliable in a network instability or high-concurrency scene in a traditional scheme. The method comprises the following steps: determining the token generation rate of each thread group according to the weight of each thread group and the real-time total bandwidth of a network; according to the token generation rate of each thread group, determining the leaky bucket capacity of the thread group; and setting the leaky bucket outflow rate of each thread group to be the same as the token generation rate of the thread group. According to the invention, fine control of multi-thread flow is realized, the bandwidth utilization rate is improved, and the probability of system congestion collapse is reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things, and particularly relates to a control method for multi-thread traffic under an MQTT protocol and a communication device. BACKGROUND

[0002] The MQTT protocol (Message Queuing Telemetry Transport) is a lightweight communication protocol widely used in the field of Internet of Things. The traditional implementation of the MQTT protocol (such as MQTT v3.1.1) adopts a fixed allocation scheme according to the number of threads or the number of MQTT messages to allocate tokens, and the token allocation algorithm in the traditional implementation is not combined with the leaky bucket algorithm or the leaky bucket algorithm also adopts a fixed allocation scheme. The traditional scheme lacks a fine-grained multi-thread traffic control mechanism, and in the case of unstable network or high concurrency, it is easy to cause loss of key data or data congestion, and the traffic control in the case of unstable network or high concurrency has the problem of unreliability. SUMMARY

[0003] In view of the above analysis, the embodiments of the present application aim to provide a control method for multi-thread traffic under an MQTT protocol and a communication device to solve the problem of unreliable traffic control of the traditional scheme in the case of unstable network or high concurrency.

[0004] In the first aspect, the present application provides a control method for multi-thread traffic under an MQTT protocol, comprising the following steps:

[0005] determining the token generation rate of each thread group according to the weight of each thread group and the real-time total bandwidth of the network;

[0006] determining the leaky bucket capacity of each thread group according to the token generation rate of each thread group; and

[0007] setting the leaky bucket outflow rate of each thread group to be the same as the token generation rate of its thread group.

[0008] Further improvements based on the above control method further comprise the following steps:

[0009] determining the allocation weight of idle tokens of each thread group according to the weight of each thread group and its real-time load factor; and

[0010] allocating the idle tokens according to the allocation weight of idle tokens of the thread group;

[0011] The real-time load factor of the thread group is determined by a current queue depth of a task queue of the thread group, the task queue being used to store tasks executed by the thread group for processing messages under a message queue telemetry transport protocol.

[0012] The further improvement of the control method comprises the following steps:

[0013] The weight of the thread group is dynamically adjusted according to a packet loss rate and a network round-trip delay in a network layer.

[0014] The further improvement of the control method comprises the following steps:

[0015] The high-priority thread group is used to execute tasks in a high-priority task queue, the high-priority task queue being used to store tasks to be executed for processing messages under a message queue telemetry transport protocol of a high priority;

[0016] The thread in the high-priority thread group has a first scheduling priority, the thread in the low-priority thread group has a second scheduling priority, the first scheduling priority is higher than the second scheduling priority, and the weight of the high-priority thread group is higher than the weight of the low-priority thread group.

[0017] The further improvement of the control method comprises the following steps:

[0018] The packet loss rate in the network layer and the packet retransmission rate in the transport layer are monitored in real time.

[0019] The weight of the low-priority thread group is dynamically adjusted according to the packet loss rate and the packet retransmission rate and the size of a corresponding preset threshold.

[0020] The further improvement of the control method comprises the following steps:

[0021] In response to the packet loss rate being greater than a packet loss rate threshold and the packet retransmission rate being less than a retransmission rate first threshold, the weight of the low-priority thread group is reduced according to the packet loss rate;

[0022] In response to the packet retransmission rate being greater than a retransmission rate second threshold, the weight of the low-priority thread group is set to 0.

[0023] The second threshold of the retransmission rate is greater than the first threshold of the retransmission rate.

[0024] Based on the further improvement of the control method, the weight of the thread group is dynamically adjusted according to the packet loss rate in the network layer and the network round-trip delay, and the adjustment includes:

[0025] The new weight of each thread group is determined according to the following formula

[0026]

[0027] Wherein, represents the preset basic weight of the i th thread group, RTT current represents the current network round-trip delay, RTT base represents the optimal network round-trip delay; PLR current represents the current packet loss rate, PLR max represents the maximum tolerated packet loss rate, and α and β represent system default parameters, wherein α+β=1.

[0028] Based on the further improvement of the control method, the weight of the thread group is dynamically adjusted according to the packet loss rate in the network layer and the network round-trip delay, and the adjustment includes:

[0029] The token generation rate R of the i th thread group is determined according to the following formula i

[0030]

[0031] Wherein, ω i represents the weight of the i th thread group, R total represents the real-time total bandwidth of the network, and n represents the total number of thread groups.

[0032] Based on the further improvement of the control method, the weight of the thread group is dynamically adjusted according to the packet loss rate in the network layer and the network round-trip delay, and the adjustment includes:

[0033] The leak bucket capacity C of the i th thread group is determined according to the following formula i

[0034] C i =k*R i *T max

[0035] Wherein, T max represents the maximum allowed burst duration, and k represents the system default burst factor.

[0036] Secondly, the application provides a communication device based on MQTT protocol, which comprises:

[0037] ​​a central processing unit,

[0038] a memory in communication with the central processing unit; and instructions stored in the memory and executable by the central processing unit to cause the communication device to perform the method of any one of the first aspect of the application.

[0039] Compared with the prior art, the application can at least achieve one of the following beneficial effects:

[0040] 1. The application achieves fine control of multi-threaded traffic through a dynamic association mechanism of leaky bucket capacity and token generation rate, improves bandwidth utilization, and reduces the probability of system congestion collapse.

[0041] 2. The dynamic binding mechanism of leaky bucket capacity and token rate in the application scheme not only improves the burst traffic absorption capacity of high-priority services, but also takes into account the burst protection of low-priority services while ensuring the basic availability of low-priority services.

[0042] 3. The residual token redistribution mechanism provided by the application scheme ensures fairness and avoids resource waste by using a two-dimensional allocation strategy of "proportional to weight + dynamic load factor".

[0043] 4. The application scheme can adjust the token allocation weight in real time according to the network state (such as RTT, packet loss rate), and the leaky bucket of the high-priority thread group can temporarily "borrow" the tokens of the low-priority group to protect critical tasks, which not only reduces the delay of high-priority services when the system is congested, but also reduces the probability of system collapse due to network jitter, and provides system network jitter adaptability.

[0044] In the application, the above technical solutions can be combined with each other to achieve more preferred combination schemes. Other features and advantages of the application will be described in the subsequent specification, and some advantages will become apparent from the specification or by implementing the application. The purpose and other advantages of the application can be achieved and obtained from the contents specifically pointed out in the specification and the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0045] The accompanying drawings are included to provide a further understanding of the application and are incorporated herein and constitute a part of the application. The application will be described with reference to the accompanying drawings, and the same reference numerals in the various figures indicate the same or similar components.

[0046] Figure 1 A flowchart of a method for controlling multi-threaded traffic under the message queue telemetry transport protocol according to an embodiment of the application is shown.

[0047] Figure 2 A message processing process flowchart designed based on independent thread pools and independent queues according to an embodiment of the application is shown. Detailed Implementation

[0048] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0049] Figure 1 A flowchart illustrating a multi-threaded traffic control method under a message queue telemetry transport protocol according to an embodiment of the present invention is shown. Figure 1 As shown, the multi-threaded traffic control method under this message queue telemetry transport protocol includes the following steps:

[0050] Step S100: Determine the token generation rate of each thread group based on the weight of each thread group and the real-time total bandwidth of the network.

[0051] A network protocol stack is a collection of layered protocols used to implement network communication in a computer network. Network protocol stacks are typically organized according to a layered model, such as the TCP / IP four-layer model. The TCP / IP four-layer model is a widely used protocol model in the Internet, dividing network communication into four layers: the physical layer, the network layer, the transport layer, and the application layer. The physical layer is responsible for transmitting raw bit streams over the physical medium, as well as frame encapsulation, error detection, and correction, such as Ethernet and Wi-Fi; Ethernet, Wi-Fi, and other link layer protocols are responsible for transmitting data frames onto the physical medium. The network layer is responsible for routing and packet forwarding, such as the IP protocol; the IP protocol is responsible for routing packets from the source host to the destination host. The transport layer provides end-to-end reliable transmission services, such as the TCP protocol; MQTT typically uses the TCP protocol to implement reliable message transmission, and the TCP protocol is responsible for establishing connections and ensuring the order and integrity of data. The application layer provides communication between applications, such as the MQTT protocol and the HTTP protocol; the MQTT protocol provides message publishing and subscription functions, allowing devices and applications to exchange messages.

[0052] In this paper, messages based on the Message Queuing Telemetry Transport Protocol are referred to as MQTT messages or simply messages, and they include a fixed header, a variable header, and a payload. For example, an MQTT message can be a PUBLISH message within the MQTT protocol layer. In MQTT-based communication, the sender and receiver encapsulate, package, and compress MQTT messages using a layered protocol, and then decapsulate them to restore the original MQTT messages. MQTT-based communication provides an efficient method for encrypting, decrypting, and compressing MQTT messages for efficient message transmission.

[0053] The MQTT protocol is implemented using a thread group approach to process MQTT messages. Specifically, it employs thread groups and message queues. Each thread group maintains a task queue, which stores executable (runnable) or callable tasks for MQTT messages that are yet to be executed. Each executable or callable task corresponds to the processing logic for one message. The message queue stores the raw data packets of MQTT messages received from the transport layer.

[0054] The token bucket algorithm is a commonly used algorithm in network traffic shaping and rate limiting. Typically, it controls the amount of data sent over the network while allowing bursts of data. The traditional token bucket algorithm works by adding tokens to a bucket at a constant rate. If a request needs to be processed, it must first obtain a token from the bucket; if there are no tokens left in the bucket, service is denied.

[0055] The leaky bucket algorithm is also a commonly used algorithm in network traffic shaping or rate limiting. Its main purpose is to control the rate at which data is injected into the network, smoothing out bursts of traffic. The leaky bucket algorithm provides a mechanism by which bursts of traffic can be shaped to provide a stable flow to the network.

[0056] In this embodiment, when a thread group needs to perform the operation of writing MQTT messages to the message queue, the thread group needs to apply for a token first; after obtaining the token, the thread group writes the MQTT message to the message queue. The token bucket algorithm can control the writing rate of MQTT messages.

[0057] In this embodiment, when a thread group needs to retrieve an MQTT message from the message queue and send it over the network, retrieving the MQTT message from the message queue requires passing it through a leaky bucket before sending it over the network. The leaky bucket algorithm can control the rate at which MQTT messages are sent over the network; through the leaky bucket algorithm, bursty traffic can be shaped into smooth traffic.

[0058] Unlike the traditional token bucket algorithm, which adds tokens to the bucket at a constant rate, this embodiment proposes a novel token bucket algorithm that dynamically allocates tokens based on the weight of thread groups and the real-time total network bandwidth. The novel token bucket algorithm in this embodiment is described below.

[0059] In the novel token bucket algorithm of this embodiment, the token generation rate of each thread group is related to its weight. Thread groups with higher weights have higher token generation rates, while thread groups with lower weights have lower token generation rates. The higher the token generation rate, the more network bandwidth it consumes. By setting the weights, higher-priority thread groups can be allowed to consume more network bandwidth.

[0060] In some embodiments, the token generation rate of each thread group can be determined by the following formula:

[0061]

[0062] Among them, R i ω represents the token generation rate of the i-th thread group. i R represents the weight of the i-th thread group. total This represents the real-time total network bandwidth, and n represents the total number of thread groups.

[0063] In some embodiments, the novel token bucket algorithm of this embodiment may include the following steps:

[0064] Step 101: Monitor the real-time total bandwidth of the network;

[0065] Step 102: Determine whether the change in the real-time total bandwidth exceeds the change threshold. If so, proceed to step 103; otherwise, maintain the token generation rate of each thread group unchanged.

[0066] Step 103: Update the token generation rate of each thread group according to Formula 1.

[0067] In the above embodiments, by setting a change threshold (e.g., 10%) for the change in total network bandwidth, a margin can be set for the novel token bucket algorithm of this embodiment, avoiding repeated system oscillations.

[0068] Step S200: Determine the leaky bucket capacity of each thread group based on the token generation rate of each thread group.

[0069] This embodiment also proposes a method for dynamically adjusting the leaky bucket capacity based on the token generation rate. Specifically, the leaky bucket capacity of each thread group is related to its token generation rate. The higher the token generation rate of a thread group, the larger its leaky bucket capacity, thus allowing for short-term burst traffic; the lower the token generation rate of a thread group, the smaller its leaky bucket capacity.

[0070] In some embodiments, the bucket capacity of each thread group can be determined according to the following formula:

[0071] C i =k*R i *T max Formula 2

[0072] Among them, C i T represents the capacity of the leaky bucket in the i-th thread group. max This represents the maximum allowed burst duration, and k represents the system's default burst factor.

[0073] Step S300: Set the bucket outflow rate of each thread group to be the same as the token generation rate of its thread group.

[0074] In this embodiment, setting the leaky bucket outflow rate of the thread group to be the same as its token generation rate can smooth the flow.

[0075] In some embodiments, Figure 1 The method also includes the following steps:

[0076] Step S400: Determine the allocation weight of each thread group to the idle token based on the weight of each thread group and its real-time load factor.

[0077] This embodiment proposes a fairness guarantee mechanism: if a thread group has unused tokens, the idle tokens can be allocated to other active thread groups to avoid resource waste. The number of tokens allocated to other active thread groups is determined by their allocation weight. The allocation weight in this embodiment is explained below.

[0078] In this embodiment, the allocation weight of other active thread groups can be determined by the weight of the thread group and its real-time load factor. The real-time load factor of each thread group is determined by the current queue depth of its task queue. It should be noted that when a task is added to the task queue, the current queue depth of the task queue increases. The current queue depth of the task queue reflects the load of the thread group corresponding to the task queue. The deeper the current queue depth, the heavier the load of the corresponding thread group, and the larger the real-time load factor of the thread group; the shallower the current queue depth, the lighter the load of the corresponding thread group, and the smaller the real-time load factor of the thread group.

[0079] In some embodiments, the real-time load factor of a thread group can be determined by the following formula:

[0080]

[0081] Among them, L i QueueDepth represents the real-time load factor of the i-th thread group. i QueueThreshold represents the current queue depth of the i-th thread group. i This represents the queue depth threshold for the i-th thread group.

[0082] As shown in Formula 3, if the current queue depth is less than the queue depth threshold, then L i <1 indicates that the task queue of the i-th thread group is not fully loaded, and the i-th thread group does not have an urgent need for tokens; if the current queue depth is greater than or equal to the queue depth threshold, then L i =1, which means that the task queue of the i-th thread group is full and the i-th thread group urgently needs token resources.

[0083] In some embodiments, the allocation weights of other active thread groups can be determined by the following formula:

[0084]

[0085] Where, ω i L represents the weight of the i-th thread group. i This represents the real-time load factor of the i-th thread group, and ActiveGroups represents the active thread groups (i.e., L) with a backlog of tasks. i Thread groups > 0), AllocRatio i This represents the weight assigned to the i-th thread group.

[0086] Step S500: Distribute the idle tokens according to the allocation weight of each thread group.

[0087] In this embodiment, idle tokens can be allocated according to the weight ratio of each allocation weight.

[0088] In some embodiments, Figure 1 The method also includes the following steps:

[0089] The weights of thread groups are dynamically adjusted based on the packet loss rate and network round-trip latency in the network layer.

[0090] Packet Loss Rate (PLR) and Round-Trip Time (RTT) are two different metrics reflecting network latency. PLR data comes from network layer statistics and reflects the quality of the underlying network links, indicating physical signal loss. RTT refers to the total time required for a data packet to travel from the sender to the receiver and receive an acknowledgment; it is a key indicator of network performance. In this embodiment, the weights of each thread group can be adjusted in real time according to the network latency status. When network quality is good, the weights of each thread group are increased; when network quality deteriorates, the weights of each thread group are decreased. Specifically, when PLR increases, the weight decreases; when PLR decreases, the weight increases. When RTT increases, the weight decreases; when RTT decreases, the weight increases.

[0091] In some embodiments, the new weight of the i-th thread group It can be determined by the following formula:

[0092]

[0093] in, Represents the preset base weight of the i-th thread group, RTT current Indicates the current network round-trip time, RTT. base PLR represents the optimal network round-trip time. current Indicates the current packet loss rate, PLR max This represents the maximum tolerable packet loss rate, where α and β represent system default parameters, and α+β=1.

[0094] In some embodiments, Figure 1 The method also includes the following steps:

[0095] S1: Real-time monitoring of packet loss rate in the network layer and packet retransmission rate in the transport layer.

[0096] Packet Loss Rate (PLR) and Retransmission Rate (RR) are two different metrics reflecting network latency. PLR data comes from network layer statistics, reflecting the quality of the underlying network links and indicating physical signal loss. RR data comes from transport layer statistics, reflecting the degree of congestion at the protocol layer and including false positive retransmissions. It's important to note that the packet retransmission rate includes retransmissions triggered by packet loss and false positive retransmissions caused by out-of-order delivery / delay; therefore, RR is always greater than or equal to PLR.

[0097] S2: Dynamically adjust the weight of the low-priority thread group based on the packet loss rate, the packet retransmission rate and the corresponding preset threshold.

[0098] In this embodiment, the thread groups are divided into high-priority thread groups and low-priority thread groups. The high-priority and low-priority thread groups are described below.

[0099] The MQTT protocol supports different levels of Quality of Service (QoS) to meet the needs of message reliability and transmission efficiency in different scenarios. The MQTT protocol defines three QoS levels: QoS 0, QoS 1, and QoS 2. The appropriate QoS level needs to be selected based on the specific application scenario and requirements. For example, if the message is very important, its QoS level is set to QoS 2; if the message is of moderate importance, its QoS level is set to QoS 1; and if the message is of low importance, its QoS level is set to QoS 0. Furthermore, if the message needs to be transmitted in real time, its QoS level is set to QoS 2; if the message does not need to be transmitted in real time, its QoS level is set to QoS 1 or QoS 0. The higher the QoS level of a message, the higher its priority.

[0100] Traditional solutions use a fixed thread pool to process MQTT messages. Specifically, they employ a shared thread pool and a shared message queue to handle high-priority and low-priority messages. The shared thread pool maintains a shared task queue, which stores executable (Runnable) or callable tasks for all MQTT messages (regardless of priority). Each executable or callable task corresponds to the processing logic for one message. The shared message queue stores the raw data packets of high-priority and low-priority messages received from the transport layer.

[0101] This invention proposes a scheme based on message priority, employing independent thread pools (i.e., independent thread groups) and independent queues. The independent queues and independent thread pools in this embodiment are described below.

[0102] 1. Independent thread pool design

[0103] (1) Thread pool (i.e., thread group in this article) partitioning

[0104] The thread pool is divided into a high-priority thread pool and a low-priority thread pool. The high-priority thread pool is dedicated to handling high-priority messages, such as those with high real-time requirements (e.g., device alarms, control commands). The low-priority thread pool is dedicated to handling low-priority messages, such as non-real-time messages (e.g., data acquisition, log uploads). Each thread pool maintains its own task queue. The high-priority thread pool maintains a high-priority task queue, and the low-priority thread pool maintains a low-priority task queue. The high-priority task queue stores executable (Runnable) or callable tasks for high-priority messages. The low-priority task queue stores executable or callable tasks for low-priority messages. Each executable or callable task corresponds to the processing logic for one message.

[0105] In this embodiment, the thread scheduling priority of the high-priority thread pool is the high priority at the operating system level, such as the SCHED_FIFO policy in Linux; the thread scheduling priority of the low-priority thread pool is the default priority of the operating system, such as the SCHED_OTHER policy in Linux.

[0106] In this embodiment, the high and low priority thread pools are physically isolated and do not share resources, thus avoiding low priority tasks blocking the thread resources of high priority tasks.

[0107] 2. Queue Isolation Design

[0108] (1) Message Queue Design

[0109] Message queues are divided into high-priority message queues and low-priority message queues. High-priority message queues store the raw data packets of high-priority messages (such as MQTT PUBLISH messages). Low-priority message queues store the raw data packets of low-priority messages (such as MQTT PUBLISH messages). Both high-priority and low-priority message queues store raw data packets received from the transport layer, but they are routed to different queues according to message priority.

[0110] In some embodiments, the high-priority message queue can be a fixed-capacity lock-free queue, such as a circular buffer. Employing a lock-free design allows for zero contention for writing / reading high-priority messages.

[0111] In some embodiments, low-priority message queues can employ a linked list structure that supports dynamic expansion. Using a linked list structure allows for short-term message accumulation and is subject to global memory quotas.

[0112] Figure 2 A flowchart illustrating a message processing procedure based on an independent thread pool and an independent queue, as designed according to an embodiment of the present invention, is shown.

[0113] like Figure 2 As shown, after receiving MQTT messages from the transport layer, they can be distributed to different message queues based on their priority. Specifically, high-priority MQTT messages are stored in the high-priority message queue, and low-priority MQTT messages are stored in the low-priority message queue. Then, the high-priority thread pool processes messages in the high-priority message queue at the MQTT protocol layer, and the low-priority thread pool processes messages in the low-priority message queue at the MQTT protocol layer.

[0114] The above design of independent thread pools and independent queues has the following two advantages:

[0115] 1. No shared resources

[0116] High and low priority queues use separate memory areas, and high priority thread pools either exclusively occupy CPU cores or preempt CPU resources through the operating system scheduler.

[0117] 2. Priority preemption

[0118] When there is data in the high-priority message queue, if a high-priority thread and a low-priority thread compete for the same CPU core, the high-priority thread will be immediately scheduled and executed by the operating system, while the low-priority thread will be suspended.

[0119] It should be noted that in embodiments where thread groups are divided into high-priority and low-priority thread groups, the weight of the high-priority thread group is higher than that of the low-priority thread group. For example, the weight of the high-priority thread group is 5, and the weight of the low-priority thread group is 1.

[0120] Return to step S2.

[0121] This embodiment proposes a weight adjustment method controlled collaboratively by RR and PLR, which includes the following process:

[0122] Step S201: Continuously monitor RR and PLR;

[0123] Step S202: Determine whether PLR is greater than the packet loss rate threshold and whether RR is less than the first retransmission rate threshold. If yes, proceed to step 803; otherwise, proceed to step 804.

[0124] Step S203: Reduce the weight of low-priority thread groups according to PLR;

[0125] Step S204: Determine whether RR is greater than the second threshold of retransmission rate. If yes, proceed to step 805; otherwise, do not perform any operation.

[0126] Step S205: Set the weight of the low-priority thread group to 0.

[0127] In the above embodiments, the second retransmission rate threshold is greater than the first retransmission rate threshold. For example, the first retransmission rate threshold is 5%, and the second retransmission rate threshold is 10%. For example, the packet loss rate threshold in the above embodiments can be 2%.

[0128] In the above embodiment, step 803 may include the following:

[0129] Reduce the weight of low-priority thread groups according to the following formula:

[0130]

[0131] Where, ω base The base weight of a low-priority thread group is represented by PLR.max This represents the maximum tolerable packet loss rate.

[0132] The present invention also provides a communication device based on a message queue telemetry transmission protocol, comprising: a central processing unit (CPU); a memory communicating with the CPU; and instructions stored in the memory and executable by the CPU to cause the communication device to perform the method described in any one of the first aspects of the present invention.

[0133] Compared with the prior art, the embodiments of the present invention can achieve at least one of the following beneficial effects:

[0134] 1. The present invention achieves fine-grained control of multi-threaded traffic through a dynamic correlation mechanism between leaky bucket capacity and token generation rate, thereby improving bandwidth utilization and reducing the probability of system congestion and crash.

[0135] 2. The dynamic binding mechanism of leaky bucket capacity and token rate in the present invention ensures the basic availability of low-priority services while guaranteeing high-priority services. It not only improves the ability to absorb sudden traffic of high-priority services, but also takes into account the sudden protection of low-priority services.

[0136] 3. The remaining token redistribution mechanism provided by the present invention adopts a two-dimensional allocation strategy of "weight ratio + dynamic load factor" to ensure fairness and avoid resource waste.

[0137] 4. The present invention can adjust the token allocation weight in real time according to the network status (such as RTT, packet loss rate). The leaky bucket of the high-priority thread group can temporarily "borrow" the tokens of the low-priority group to ensure critical tasks. This not only reduces the latency of high-priority services when the system is congested, but also reduces the probability of system crash due to network jitter, and provides system network jitter adaptability.

[0138] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for controlling multi-threaded traffic under the MQTT protocol, characterized in that, Includes the following steps: The token generation rate of each thread group is determined based on the weight of each thread group and the real-time total network bandwidth. The bucket capacity of each thread group is determined based on the token generation rate of each thread group. as well as Set the bucket outflow rate of each thread group to be the same as the token generation rate of its thread group.

2. The control method according to claim 1, characterized in that, It also includes the following steps: Based on the weights of each thread group and their real-time load factors, determine the allocation weight of each thread group for idle tokens; and The idle tokens are allocated according to the allocation weight of the idle tokens in the thread group; The real-time load factor of the thread group is determined by the current queue depth of the task queue of the thread group. The task queue is used to store tasks executed by the thread group that process messages under the message queue telemetry transport protocol.

3. The control method according to claim 1, characterized in that, It also includes the following steps: The weights of the thread groups are dynamically adjusted based on the packet loss rate and network round-trip latency in the network layer.

4. The control method according to claim 1, 2, or 3, characterized in that, The thread group includes a low-priority thread group and a high-priority thread group. The low-priority thread group is used to execute tasks in the low-priority task queue. The low-priority task queue is used to store tasks to be executed that process messages under the low-priority message queue telemetry transmission protocol. The high-priority thread group is used to execute tasks in the high-priority task queue, which stores tasks to be executed that process messages under the high-priority message queue telemetry transmission protocol. The threads in the high-priority thread group have a first scheduling priority, and the threads in the low-priority thread group have a second scheduling priority. The first scheduling priority is higher than the second scheduling priority, and the weight of the high-priority thread group is higher than the weight of the low-priority thread group.

5. The control method according to claim 4, characterized in that, It also includes the following steps: Real-time monitoring of packet loss rate in the network layer and packet retransmission rate in the transport layer; The weight of the low-priority thread group is dynamically adjusted based on the packet loss rate, the packet retransmission rate, and the corresponding preset threshold.

6. The control method according to claim 5, characterized in that, Dynamically adjusting the weight of the low-priority thread group based on the packet loss rate, the packet retransmission rate, and the corresponding preset threshold includes: In response to the packet loss rate being greater than a packet loss rate threshold and the packet retransmission rate being less than a first retransmission rate threshold, the weight of the low-priority thread group is reduced according to the packet loss rate. In response to the packet retransmission rate being greater than the second retransmission rate threshold, the weight of the low-priority thread group is set to 0; Wherein, the second threshold of retransmission rate is greater than the first threshold of retransmission rate.

7. The control method according to claim 3, characterized in that, Dynamically adjusting the weights of the thread groups based on packet loss rate and network round-trip time in the network layer includes: The new weights of each thread group are determined using the following formula. in, Represents the preset base weight of the i-th thread group, RTT current Indicates the current network round-trip time, RTT. base PLR represents the optimal network round-trip time. current Indicates the current packet loss rate, PLR max This represents the maximum tolerable packet loss rate, where α and β represent system default parameters, and α+β=1.

8. The control method according to claim 1, 2, 3, or 7, characterized in that, The token generation rate for each thread group is determined based on its weight and the network's real-time total bandwidth, including: The token generation rate R of the i-th thread group is determined according to the following formula. i : Where, ω i R represents the weight of the i-th thread group. total This represents the real-time total network bandwidth, and n represents the total number of thread groups.

9. The control method according to claim 8, characterized in that, Determining the bucket capacity of each thread group based on its token generation rate includes: The bucket capacity C of the i-th thread group is determined according to the following formula. i : C i =k*R i *T max Among them, T max This represents the maximum allowed burst duration, and k represents the system's default burst factor.

10. A communication device based on the MQTT protocol, comprising: CPU, Memory that communicates with the central processing unit; And instructions, which are stored in the memory and can be executed by the central processing unit to cause the communication device to perform the method according to any one of claims 1 to 9.

Images