A message queue-based broadcast message and acknowledgement message processing method
By adopting a message queue-based broadcast and acknowledgment message processing method, the problem of low message delivery efficiency caused by inconsistent device protocols in IoT device management is solved. This method enables rapid delivery of device broadcast data and accurate response of acknowledgment data, thereby improving the system's communication efficiency and processing capabilities.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SICHUAN JINGKING WEIDA SMART TECH CO LTD
- Filing Date
- 2023-02-24
- Publication Date
- 2026-06-19
AI Technical Summary
In existing technologies, IoT device management suffers from problems such as low message delivery efficiency and complex broadcast message processing due to inconsistent device protocols. In particular, custom protocol devices cannot effectively utilize the MQTT protocol, resulting in cumbersome system queries and affecting message delivery and processing efficiency.
A message queue-based method for handling broadcast and acknowledgment messages is adopted. Through the collaborative work of the business server, message queue server, and connection server, and by utilizing the message publish/subscribe pattern, inter-server communication is achieved, thereby improving response speed and message transmission efficiency.
It enables accurate and rapid delivery of device broadcast data and precise response to confirmation data, optimizes the connection management of massive devices, and improves the system's communication efficiency and processing capabilities.
Smart Images

Figure CN116170499B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of Internet of Things (IoT) device management technology, and in particular to a method for processing broadcast and acknowledgment messages based on message queues. Background Technology
[0002] In existing technologies, the management of massive IoT devices typically involves two approaches, depending on whether the device communication protocols are standardized:
[0003] 1. Standardized device management based on the MQTT protocol
[0004] MQTT is a publish / subscribe-based communication protocol built on top of TCP / IP. MQTT's biggest advantage is that it provides real-time, reliable messaging services to remote devices with minimal code and limited bandwidth. Each device subscribes to the topic it wants to receive messages from. When a business server needs to send data to a device, it sends the message to the corresponding topic, and the device receives the data. MQTT also supports wildcards, enabling message broadcasting. However, this approach is limited by the requirement that devices support the MQTT protocol. If a device does not support MQTT, this method cannot be used.
[0005] 2. Personalized device management based on custom protocols
[0006] Currently, many devices do not support the MQTT protocol, but instead use custom application-layer transport protocols based on TCP. Furthermore, the transport protocols differ between different types of devices. This personalized device management approach using custom protocols typically requires the system to locate the connection server to which the downlink message is connected before data can be sent to the device. In other words, the application server must first find the connection server to which the device is connected before completing subsequent processes. There are several different implementations for finding the connection server corresponding to each device. A common approach is to store the address of the connection server connected to each device in a database or global cache. Each time the application server sends data, it retrieves the connection server address by querying the database or global cache and directly connects to that server to send data. However, for broadcast messages, it is necessary to retrieve the address of the connection server corresponding to all devices to be broadcast from the database or global cache one by one before sending the message sequentially. This query process is cumbersome and complex, severely impacting message sending and processing efficiency. Summary of the Invention
[0007] Therefore, it is necessary to propose a method for handling broadcast and acknowledgment messages based on message queues to address the above problems.
[0008] This invention discloses a broadcast message processing method based on a message queue, which is applied to an Internet of Things (IoT) system. The IoT system includes: a business server, a message queue server, a connection server, and devices that are interconnected.
[0009] The method includes:
[0010] The service server receives a broadcast request, and based on the broadcast request, obtains the broadcast content and generates device filtering conditions for a number of devices that are allowed to receive the broadcast content;
[0011] The service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic;
[0012] The message queue server pushes the broadcast message to the connected server according to the preset grouping rules and the message topic subscription status of the connected server;
[0013] The connection server receives and parses the broadcast message to obtain the broadcast content, device filtering conditions, and business server identifier in the broadcast message. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices.
[0014] The selected devices receive the broadcast message and perform service processing on the broadcast message.
[0015] Furthermore, the message queue server pushes the broadcast message to the connected server according to preset grouping rules and the message topic subscription status of the connected server, specifically including:
[0016] The message queue server divides all connected servers into different groups based on the connected server identifier, and each connected server in each group subscribes to the first message topic;
[0017] The message queue server pushes the broadcast message to all connected servers belonging to different groups that have subscribed to the first message topic.
[0018] Furthermore, the broadcast content specifically includes: broadcast data and a message identifier, wherein the message identifier is used to track the current transmission status of the broadcast data.
[0019] Furthermore, the service server assembles the broadcast message based on the broadcast content, device filtering conditions, and service server identifier, specifically including:
[0020] The service server assembles the broadcast message according to the format "service server identifier: device filtering conditions: message identifier: broadcast data" based on the broadcast data, message identifier, device filtering conditions, and service server identifier.
[0021] On the other hand, the present invention also discloses a message queue-based acknowledgment message processing method, which is applied to an Internet of Things (IoT) system, the IoT system comprising: a business server, a message queue server, a connection server, and a device that are interconnected.
[0022] The method includes:
[0023] The device receives and processes the broadcast message as described in the above broadcast message processing method, generates confirmation data in response to the broadcast message, and sends the confirmation data and the device identifier to the connection server;
[0024] The connection server obtains the service server identifier and message identifier in the broadcast message according to the broadcast message processing method described above;
[0025] The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0026] The connection server sends the confirmation messages to the message queue server through the several different second message topics respectively;
[0027] The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0028] The service server receives and parses the confirmation message to obtain the connection server identifier, device identifier, message identifier, and confirmation data in the confirmation message, and performs business processing on the confirmation data.
[0029] Furthermore, the message queue server pushes the confirmation messages to the corresponding business servers according to preset grouping rules and the message topic subscription status of the business servers, specifically including:
[0030] The message queue server divides all business servers into the same group, and each business server subscribes to different second message topics according to its own business server identifier;
[0031] The message queue server pushes the confirmation message to the corresponding business server according to the second message topic subscribed to by each business server.
[0032] Furthermore, the connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, specifically including:
[0033] The connection server assembles the confirmation message according to the format "connection server identifier: device identifier: message identifier: confirmation data" based on the confirmation data, device identifier, message identifier, and connection server identifier.
[0034] Furthermore, the IoT system also includes: a load balancing server;
[0035] The device sends the confirmation data to the connection server, specifically including:
[0036] The device sends the confirmation data to an idle connection server via the load balancing server.
[0037] On the other hand, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the following broadcast message processing method:
[0038] The service server receives a broadcast request, and based on the broadcast request, obtains the broadcast content and generates device filtering conditions for a number of devices that are allowed to receive the broadcast content;
[0039] The service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic;
[0040] The message queue server pushes the broadcast message to the connected server according to the preset grouping rules and the message topic subscription status of the connected server;
[0041] The connection server receives and parses the broadcast message to obtain the broadcast content, device filtering conditions, and business server identifier in the broadcast message. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices.
[0042] The selected devices receive the broadcast message and perform service processing on the broadcast message;
[0043] and / or perform the following steps of the acknowledgment message processing method:
[0044] The device receives and processes the broadcast message as described in the above broadcast message processing method, generates confirmation data in response to the broadcast message, and sends the confirmation data and the device identifier to the connection server;
[0045] The connection server obtains the service server identifier and message identifier in the broadcast message according to the broadcast message processing method described above;
[0046] The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0047] The connection server sends the confirmation messages to the message queue server through the several different second message topics respectively;
[0048] The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0049] The service server receives and parses the confirmation message to obtain the connection server identifier, device identifier, message identifier, and confirmation data in the confirmation message, and performs business processing on the confirmation data.
[0050] On the other hand, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the following broadcast message processing method:
[0051] The service server receives a broadcast request, and based on the broadcast request, obtains the broadcast content and generates device filtering conditions for a number of devices that are allowed to receive the broadcast content;
[0052] The service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic;
[0053] The message queue server pushes the broadcast message to the connected server according to the preset grouping rules and the message topic subscription status of the connected server;
[0054] The connection server receives and parses the broadcast message to obtain the broadcast content, device filtering conditions, and business server identifier in the broadcast message. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices.
[0055] The selected devices receive the broadcast message and perform service processing on the broadcast message;
[0056] and / or perform the following steps of the acknowledgment message processing method:
[0057] The device receives and processes the broadcast message as described in the above broadcast message processing method, generates confirmation data in response to the broadcast message, and sends the confirmation data and the device identifier to the connection server;
[0058] The connection server obtains the service server identifier and message identifier in the broadcast message according to the broadcast message processing method described above;
[0059] The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0060] The connection server sends the confirmation messages to the message queue server through the several different second message topics respectively;
[0061] The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0062] The service server receives and parses the confirmation message to obtain the connection server identifier, device identifier, message identifier, and confirmation data in the confirmation message, and performs business processing on the confirmation data.
[0063] The present invention has the following beneficial effects:
[0064] This invention is based on message queues and uses a message publish / subscribe pattern to realize inter-server communication, improve response speed, and effectively ensure that downlink device control and / or management data sent by the business server can accurately and quickly reach multiple corresponding devices through the connection server, realizing data broadcasting; at the same time, it ensures that the confirmation data of each device for the downlink data can be accurately and quickly distributed to the business server, realizing accurate command response. Attached Figure Description
[0065] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0066] in:
[0067] Figure 1 This is an application environment diagram of a broadcast message and acknowledgment message processing method in one embodiment;
[0068] Figure 2Here is a flowchart of a broadcast message processing method in one embodiment;
[0069] Figure 3 This is a flowchart of a message processing method in one embodiment;
[0070] Explanation of reference numerals in the attached diagram: Business Server 100, Message Queue Server 200, Connection Server 300, Device 400. Detailed Implementation
[0071] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0072] Figure 1 This is an application environment diagram illustrating a message queue-based method for handling broadcast and acknowledgment messages, as shown in one embodiment. (Refer to...) Figure 1 The message queue-based method for processing broadcast and acknowledgment messages is applied to an Internet of Things (IoT) system, which includes a business server 100, a message queue server 200, a connection server 300, and a device 400 that are interconnected.
[0073] Specifically, in this embodiment, the business server 100 is responsible for processing business data and can be deployed in a cluster mode. Each business server 100 has the same state and can process data from any device.
[0074] The message queue server 200 can be a traditional message queue server, such as Kafka or RabbitMQ, to handle a large number of messages and supports a certain number of connections and message topic subscriptions.
[0075] Connection server 300 is used to handle device connections. A large number of connection servers can be deployed to manage massive device connections. Each connection server can manage different device connections and only processes data from devices connected to its own server.
[0076] Currently, many devices use custom transmission protocols and do not support the MQTT protocol, making it impossible to achieve effective data delivery using standardized MQTT-based device management methods. For devices with custom protocols, common IoT systems (devices + management platform) mostly connect to the management platform's business server via TCP connection servers. Furthermore, to handle massive amounts of business data, the system often requires the deployment of multiple connection servers and business servers for load balancing, resulting in a many-to-many relationship between them. Simultaneously, the system contains a massive number of devices. Therefore, how to achieve effective connection management and corresponding communication between these numerous devices and servers has become a pressing issue.
[0077] In this embodiment, a message queue server is introduced, employing a message publish / subscribe model for communication. This improves response speed and effectively ensures that downlink device control and / or management data sent by the business server can accurately and quickly reach multiple corresponding devices through the connection server, achieving data broadcasting. Simultaneously, it ensures that acknowledgments from each device for the downlink data can be accurately and quickly distributed to the business server, achieving precise command responses. This perfectly solves the problem of ineffective connection management and communication in existing IoT systems. Furthermore, traditional message queue servers (such as Kafka and RabbitMQ) typically only have the capacity to process massive amounts of messages, but their supported number of topics and connections is limited. It's impossible to allocate a topic and / or connection to each device. Therefore, this embodiment, based on traditional message queues, also deploys a large number of connection servers to achieve connection management for massive devices, further optimizing the system's connection management capabilities. The combination of connection servers and message queues enables connection management for massive devices.
[0078] Specifically, the management of massive device connections based on message queues includes processes such as uplink message reception, downlink message processing, downlink broadcast message processing, and downlink acknowledgment message processing. The following embodiments describe the process flow of downlink broadcast message and acknowledgment message processing based on message queues.
[0079] like Figure 2 As shown, in one embodiment, a broadcast message processing method based on a message queue is provided, applicable to, for example... Figure 1 In the IoT system shown, the method specifically includes the following steps:
[0080] S110. The service server receives a broadcast request, and based on the broadcast request, obtains the broadcast content and generates device filtering conditions for several devices that are allowed to receive the broadcast content.
[0081] S120: The service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic.
[0082] S130. The message queue server pushes broadcast messages to the connected server according to the preset grouping rules and the message topic subscription status of the connected server.
[0083] S140. The connection server receives and parses the broadcast message, obtains the broadcast content, device filtering conditions, and business server identifier in the broadcast message, and filters out all devices that meet the device filtering conditions within its own management scope according to the device filtering conditions, and forwards the broadcast message to the filtered devices.
[0084] S150. The selected device receives broadcast messages and performs service processing on the broadcast messages.
[0085] In this embodiment, the broadcast content and requests are generated by the management platform, processed by the business server, sent to the message queue server, pushed by the message queue server to the connection manager, and finally reach the device managed by it.
[0086] The specific process is as follows: The business server receives the request, obtains the broadcast content, generates device filtering conditions for devices that are allowed to receive the broadcast content, and assembles a broadcast message based on the broadcast content, device filtering conditions, and its own business server identifier. The broadcast message is then published to the message queue server through a fixed message topic. The message queue server pushes the broadcast message to the connection server according to the grouping rules and the message topic subscription status of the connection server. After receiving the broadcast message, the connection server determines the devices that meet the conditions within its management scope based on the device filtering conditions, and then forwards the broadcast message to the corresponding device for processing.
[0087] In this embodiment, the service server sends broadcast messages through a fixed message topic, ensuring that all connected servers subscribed to that topic from the message queue server receive the broadcast message, thus achieving the broadcast purpose. Furthermore, this embodiment embeds filtering conditions for all devices allowed to receive broadcast content into the broadcast message, enabling targeted selection of multiple devices to send data. Additionally, the broadcast message also embeds a service server identifier, allowing connected servers or devices to quickly locate the source of the broadcast data during processing and transmission, eliminating the need for excessive global cache lookups and significantly improving message processing efficiency.
[0088] Furthermore, in one embodiment, step S130 specifically includes:
[0089] S131. The message queue server divides all connection servers into different groups according to the connection server identifier, and each connection server in each group subscribes to the first message topic.
[0090] S132. The message queue server pushes the broadcast message to all connection servers belonging to different groups that have subscribed to the first message topic.
[0091] In a message queue mechanism, producers send messages to the message queue, and consumers pull / retrieve messages from the message queue. Consumers obtain messages by subscribing to message topics (or simply topics), and are therefore also called subscribers. Subscribers must belong to a subscriber group (or simply group). The relationship between subscribers and subscriber groups is that of individuals and a community; a subscriber can belong to one or more subscriber groups, and a subscriber group can contain one or more subscribers. When a producer publishes a message on a specified topic, only one subscriber within the same group that has subscribed to that topic will receive the message; however, multiple subscribers in different groups that have subscribed to the same topic will all receive the message. That is, all groups associated with a topic can receive the message, but only one subscriber within each group can receive the message. In practice, both producers and consumers are composed of various servers. In other words, a topic can be subscribed to by different servers in multiple groups, a topic can be subscribed to by different servers in the same group, a topic cannot be subscribed to by the same server in a group multiple times, different servers in a group can subscribe to the same topic, different servers in a group can subscribe to different topics, and a server in a group cannot subscribe to the same topic multiple times. Thus, a many-to-many relationship is formed between topics and groups.
[0092] In this embodiment, the connection servers are grouped according to their identifiers. Since each connection server has a unique identifier, each connection server is divided into different groups. Each connection server in a different group subscribes to the same Topic. Therefore, each connection server can receive the broadcast message corresponding to the Topic, thereby achieving the purpose of broadcasting the message to multiple connection servers.
[0093] Furthermore, in one embodiment, the broadcast content specifically includes: broadcast data and a message identifier, wherein the message identifier is used to track the current transmission status of the broadcast data.
[0094] In this embodiment, the broadcast content may include not only the broadcast data that needs to be sent, but also a message identifier assigned to the specific broadcast data, which is used to track the sending status of the message, help to understand the sending status of the broadcast message in real time, and assist in distinguishing broadcast messages in the positioning system.
[0095] Furthermore, in one embodiment, in step S120, the service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, specifically including:
[0096] The service server assembles the broadcast message according to the format "service server identifier: device filtering conditions: message identifier: broadcast data" based on the broadcast data, message identifier, device filtering conditions, and service server identifier.
[0097] Specifically, in one embodiment, the broadcast message processing method based on message queues can introduce a message topic of type TcpSendMany for processing downlink broadcast data. There is one and only one topic of this type. It can also introduce a connection server group of type SendGroupWithCServerUID, where CServerUID is the connection server identifier, which can be replaced by the ID of each connection server. Therefore, since each connection server has a different CServerUID, there will be multiple groups of this type. That is to say, each connection server that subscribes to a topic of type TcpSendMany will belong to a different group of this type.
[0098] The specific components of a broadcast message may include:
[0099] 1) BServerUID, the business server identifier, can be replaced by the ID of each business server, describing which business server sent the current message;
[0100] 2) DeviceSelector: Device selection criteria, describing which types, regions, or organizations' devices are allowed to receive the current message;
[0101] 3) MsgUID, message identifier, does not distinguish between uplink and downlink messages, and is used to track the current message sending status.
[0102] 4) BCMsgData: The specific broadcast data in the broadcast content generated by the platform. The data format can be customized for different types of devices.
[0103] The above data can be separated by colons, that is, assembled into a broadcast message according to the format "BServerUID:DeviceSelector:MsgUID:BCMsgData".
[0104] The specific broadcast message processing procedure is as follows:
[0105] All connection servers subscribe to the message topic TcpSendMany in different SendGroupWithCServerUID groups. The CServerUID in the SendGroupWithCServerUID group is a unique identifier for the connection server, which can be replaced by the connection server ID.
[0106] When the management platform broadcasts a message to multiple devices that meet specified conditions through the business server, the business management server first finds its own unique identifier BServerUID and obtains the broadcast data BCMsgData. It then assigns MsgUID to the broadcast data, generates a device selection condition DeviceSelector that can filter out multiple devices in the system that are allowed to receive this message, and constructs a broadcast message in the format "BServerUID:DeviceSelector:MsgUID:BCMsgData". The message is then published to the message queue server through the message topic TcpSendMany.
[0107] Since each connection server is in a different group (SendGroupWithCServerUID) but subscribes to the message topic (TcpSendMany), all connection servers receive this message. Upon receiving the message, each connection server parses out the business server identifier (BServerUID), device selection condition (DeviceSelector), message identifier (MsgUID), and broadcast data (BCMsgData) from the broadcast message. Then, based on the DeviceSelector, it identifies all devices within its management scope that meet the device selection condition—the devices that need to be broadcast—and forwards the broadcast message to these devices sequentially.
[0108] After receiving the broadcast data BCMsgData, the device parses the data according to the corresponding device communication protocol and then processes the service.
[0109] In addition, such as Figure 3 As shown, in one embodiment, a message queue-based acknowledgment message processing method is also provided, which is also applicable to applications such as... Figure 1 In the IoT system shown, the method specifically includes the following steps:
[0110] S210. The device receives and processes the broadcast message in the above broadcast message processing method, generates confirmation data to reply to the broadcast message, and sends the confirmation data and device identifier to the connection server.
[0111] S220. The connection server obtains the service server identifier and message identifier in the broadcast message according to the broadcast message in the above broadcast message processing method;
[0112] S230: The connection server assembles the confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0113] S240, The connection server sends the confirmation message to the message queue server through several different second message topics;
[0114] S250: The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0115] S260. The service server receives and parses the confirmation message, obtains the connection server identifier, device identifier, message identifier and confirmation data in the confirmation message, and performs business processing on the confirmation data.
[0116] In this embodiment, the confirmation message is generated by the device. After receiving a broadcast message from the service server, the device needs to reply to the service server with the processing status of the broadcast message. This reply data is the confirmation message (or simply confirmation message) for the broadcast message. The device sends the confirmation message to the connection server, which then sends the confirmation message to the service management server that previously sent the corresponding broadcast message.
[0117] The specific process is as follows: The device generates confirmation data and sends it to the connection server. The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier of the original broadcast message, and its own connection server identifier. It also constructs multiple message topics corresponding to each business server based on the identifiers of each business server and publishes the confirmation message to the message queue server through multiple message topics. The message queue server pushes the confirmation message to the business management server according to the grouping rules and the message topic subscription status of the business servers. The business server receives and parses the confirmation message, obtains the connection server identifier, device identifier, message identifier, and confirmation data in the confirmation message, and performs business processing on the confirmation data.
[0118] In this embodiment, the connection server constructs multiple message topics based on the identifier of each business server and publishes confirmation messages using these multiple message topics. Therefore, embedding the business server identifier in the confirmation message enables precise location of the business server, i.e., accurate response to the broadcast messages previously sent by the business server. At the same time, by embedding the connection server identifier and device identifier in the confirmation message, the business server can quickly locate the source of the confirmation data after processing the data, without needing excessive global cache queries, greatly improving message processing efficiency. In addition, the confirmation message also includes the message identifier of the original broadcast message, used to specify the broadcast message to be confirmed. After receiving the message, the business server can match the confirmation message based on the MsgUID.
[0119] Furthermore, in one embodiment, step S250 specifically includes:
[0120] S251. The message queue server divides all business servers into the same group, and each business server subscribes to different second message topics according to its own business server identifier.
[0121] S252. The message queue server pushes the confirmation message to the corresponding business server according to the second message topic subscribed to by each business server.
[0122] In this embodiment, the connection server constructs multiple different message topics based on the identifier of each business server, and publishes the confirmation message through multiple message topics. When the message queue server divides all business servers into the same group, and multiple business servers in the same group subscribe to different message topics, each business server only processes the message topic it subscribes to and processes the corresponding confirmation message. That is, each business server can receive different confirmation messages, thereby enabling precise location of a certain business server.
[0123] Furthermore, in one embodiment, in step S230, the connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, specifically including:
[0124] The connection server assembles the confirmation message according to the format "connection server identifier: device identifier: message identifier: confirmation data" based on the confirmation data, device identifier, message identifier, and connection server identifier.
[0125] Furthermore, in one embodiment, the IoT system further includes: a load balancing server;
[0126] In step S210, the device sends the confirmation data to the connection server, specifically including:
[0127] The device sends the confirmation data to an idle connection server via the load balancing server.
[0128] Specifically, in one embodiment, the message queue-based acknowledgment message processing method can introduce a message topic of type TcpResponeWithBServerUID to process the echo acknowledgment data of downlink broadcast data. Here, BServerUID is the business server identifier, which can be replaced by the ID of each business processing service. Therefore, there will be multiple message topics of this type with different BServerUIDs. Each business server subscribes to a different TcpResponeWithBServerUID, thus achieving a one-to-one correspondence between message topics and business servers. In addition, a business server group of type ResponseGroup can be introduced. All business servers that subscribe to the message topic TcpResponeWithBServerUID belong to this group. There can be one or more groups of this type, but generally one is sufficient.
[0129] The specific components of a confirmation message may include:
[0130] 1) CServerUID, the connection server identifier, can be replaced by the ID of each connection server, describing which connection server sent the current message;
[0131] 2) DeviceUID, a unique device identifier, describes which device acknowledged the current message;
[0132] 3) MsgUID, message identifier, does not distinguish between uplink and downlink messages, and is used to track the current message sending status.
[0133] 4) RespMsgData: The specific data in the device confirmation message. The data format can be customized for different types of devices.
[0134] The above data can be separated by colons, that is, assembled into an acknowledgment message according to the format "CServerUID:DeviceUID:MsgUID:RespMsgData".
[0135] The specific confirmation message processing procedure is as follows:
[0136] All business servers subscribe to the message topic TcpResponeWithBServerUID in the ResponseGroup group. The BServerUID in the message topic TcpResponeWithBServerUID is a unique identifier for the business server, which can be replaced by the business server ID.
[0137] When a device sends back an acknowledgment message, it connects to a load balancer server via TCP. The load balancer server then forwards the connection to a relatively idle connection server. Upon receiving the acknowledgment message from the device, the connection server first identifies its own unique identifier (CServerUID), then obtains the device's unique identifier (DeviceUID), and performs packet segmentation and reassembly based on the device's custom protocol packet identifier to obtain the device acknowledgment data (RespMsgData). Based on the previously received broadcast message, it obtains the message identifier (MsgUID) and the business server identifier (BServerUID) of that broadcast message. Finally, it constructs an acknowledgment message in the format "CServerUID:DeviceUID:MsgUID:RespMsgData" and publishes it to the message queue server via the message topic TcpResponeWithBServerUID.
[0138] Since all business servers are in the same ResponseGroup but subscribe to different message topics, each business server has a different message topic (different BServerUID). Only the business server corresponding to each message topic can receive the confirmation message carried by that message topic, parse out the connection server identifier CServerUID, device identifier DeviceUID, message identifier MsgUID (corresponding to the previously broadcast message), and confirmation data RespMsgData from the confirmation message, and perform business processing on the confirmation data DownMsgData.
[0139] The computer device can be a terminal or a server. It includes a processor, memory, and a network interface connected via a system bus. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement a message queue-based method for handling broadcast and acknowledgment messages. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to perform a message queue-based method for handling broadcast and acknowledgment messages. Those skilled in the art will understand that the structures shown in the figures are merely block diagrams of some structures related to the present application and do not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than shown in the figures, or combine certain components, or have different component arrangements.
[0140] In one embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the following broadcast message processing method:
[0141] The business server receives broadcast requests and, based on the broadcast requests, obtains the broadcast content and generates device filtering conditions for several devices that are allowed to receive the broadcast content.
[0142] The service server assembles a broadcast message based on the broadcast content, device filtering criteria, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic;
[0143] The message queue server pushes broadcast messages to the connected server according to preset grouping rules and the message topic subscription status of the connected server;
[0144] The connection server receives and parses broadcast messages to obtain the broadcast content, device filtering conditions, and business server identifiers in the broadcast messages. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices.
[0145] The selected devices receive broadcast messages and perform business processing on the broadcast messages;
[0146] and / or perform the following steps of the acknowledgment message processing method:
[0147] The device receives and processes the broadcast message in the above broadcast message processing method, generates confirmation data to reply to the broadcast message, and sends the confirmation data and device identifier to the connection server;
[0148] The connection server obtains the business server identifier and message identifier from the broadcast message according to the broadcast message processing method described above;
[0149] The connection server assembles the confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0150] The connection server sends confirmation messages to the message queue server through several different second message topics;
[0151] The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0152] The business server receives and parses the confirmation message, obtains the connection server identifier, device identifier, message identifier, and confirmation data from the confirmation message, and performs business processing on the confirmation data.
[0153] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the steps of the following broadcast message processing method:
[0154] The business server receives broadcast requests and, based on the broadcast requests, obtains the broadcast content and generates device filtering conditions for several devices that are allowed to receive the broadcast content.
[0155] The service server assembles a broadcast message based on the broadcast content, device filtering criteria, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic;
[0156] The message queue server pushes broadcast messages to the connected server according to preset grouping rules and the message topic subscription status of the connected server;
[0157] The connection server receives and parses broadcast messages to obtain the broadcast content, device filtering conditions, and business server identifiers in the broadcast messages. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices.
[0158] The selected devices receive broadcast messages and perform business processing on the broadcast messages;
[0159] and / or perform the following steps of the acknowledgment message processing method:
[0160] The device receives and processes the broadcast message in the above broadcast message processing method, generates confirmation data to reply to the broadcast message, and sends the confirmation data and device identifier to the connection server;
[0161] The connection server obtains the business server identifier and message identifier from the broadcast message according to the broadcast message processing method described above;
[0162] The connection server assembles the confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier;
[0163] The connection server sends confirmation messages to the message queue server through several different second message topics;
[0164] The message queue server pushes the confirmation message to the corresponding business server according to the preset grouping rules and the topic subscription status of the business server.
[0165] The business server receives and parses the confirmation message, obtains the connection server identifier, device identifier, message identifier, and confirmation data from the confirmation message, and performs business processing on the confirmation data.
[0166] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.
[0167] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0168] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A method for processing broadcast messages based on message queues, characterized by, Applied to an Internet of Things (IoT) system, the IoT system includes: a business server, a message queue server, a connection server, and devices that are interconnected. The method includes: The service server receives a broadcast request and, based on the broadcast request, obtains the broadcast content and generates device filtering conditions for a number of devices that are allowed to receive the broadcast content; the broadcast content specifically includes: broadcast data and a message identifier, the message identifier being used to track the current broadcast data transmission status; The service server assembles a broadcast message based on the broadcast content, device filtering conditions, and service server identifier, and sends the broadcast message to the message queue server through a fixed first message topic; The message queue server pushes the broadcast message to the connected server according to preset grouping rules and the message topic subscription status of the connected server, including: The message queue server divides all connected servers into different groups based on the connected server identifier, and each connected server in each group subscribes to the first message topic; The message queue server pushes the broadcast message to all connected servers belonging to different groups that have subscribed to the first message topic; The connection server receives and parses the broadcast message to obtain the broadcast content, device filtering conditions, and business server identifier in the broadcast message. Based on the device filtering conditions, it filters out all devices that meet the device filtering conditions within its own management scope and forwards the broadcast message to the filtered devices. The selected devices receive the broadcast message and perform service processing on the broadcast message.
2. The message queue based broadcast message processing method according to claim 1, wherein, The service server assembles a broadcast message based on the broadcast content, device filtering criteria, and service server identifier, specifically including: The service server assembles the broadcast message according to the format "service server identifier: device filtering conditions: message identifier: broadcast data" based on the broadcast data, message identifier, device filtering conditions, and service server identifier.
3. A message queue based acknowledgement message processing method, characterized by, Applied to an Internet of Things (IoT) system, the IoT system includes: a business server, a message queue server, a connection server, and devices that are interconnected. The method includes: The device receives and processes the broadcast message as described in claim 1 or 2, generates confirmation data in response to the broadcast message, and sends the confirmation data and the device identifier to the connection server; The connection server obtains the service server identifier and message identifier in the broadcast message according to the broadcast message as described in claim 1 or 2; The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, and constructs several different second message topics based on the business server identifier; The connection server sends the confirmation messages to the message queue server through the several different second message topics respectively; The message queue server pushes the confirmation messages to the corresponding business servers according to preset grouping rules and the topic subscription status of the business servers, including: The message queue server divides all business servers into the same group, and each business server subscribes to different second message topics according to its own business server identifier; The message queue server pushes the confirmation message to the corresponding business server according to the second message topic subscribed to by each business server; The service server receives and parses the confirmation message to obtain the connection server identifier, device identifier, message identifier, and confirmation data in the confirmation message, and performs business processing on the confirmation data.
4. The acknowledgment message processing method based on message queues according to claim 3, characterized in that, The connection server assembles a confirmation message based on the confirmation data, device identifier, message identifier, and connection server identifier, specifically including: The connection server assembles the confirmation message according to the format "connection server identifier: device identifier: message identifier: confirmation data" based on the confirmation data, device identifier, message identifier, and connection server identifier.
5. The acknowledgment message processing method based on a message queue according to claim 3, characterized in that, The IoT system also includes: a load balancing server; The device sends the confirmation data to the connection server, specifically including: The device sends the confirmation data to an idle connection server via the load balancing server.
6. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, the processor performs the broadcast message processing method as described in any one of claims 1 to 2, and / or performs the acknowledgment message processing method as described in any one of claims 3 to 5.
7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, the processor performs the broadcast message processing method as described in any one of claims 1 to 2, and / or performs the acknowledgment message processing method as described in any one of claims 3 to 5.