Message transmission method and device, electronic equipment and computer storage medium

Abstract

The invention provides a message transmission method and device, electronic equipment and a computer storage medium, which can be applied to the technical fields of computers, data transmission and information security. The message transmission method comprises: in response to receiving a first message from a first device, determining message information matching the first message, the message information comprising receiving device information and a message type, the message type comprising a type for managing a device group composed of a plurality of devices; calling a transmission interface, determining a transmission mode for transmitting the message information according to the message type, and transmitting the message information to receiving equipment matched with the receiving equipment information through the transmission mode; wherein the transmission modes comprise a first transmission mode and a second transmission mode which use different transmission protocols, and the security level of the transmission protocol used by the first transmission mode is higher than that of the transmission protocol used by the second transmission mode; and the transmission interface is also used for encrypting the message information.

Description

Technical Field

[0001] The present application relates to the fields of computers, data transmission, and information security technology, and in particular to a message transmission method, device, electronic device, and computer storage medium. Background Art

[0002] With the continuous development of computer technology, automatic discovery and communication between multiple devices in a local area network (LAN) or server cluster is extremely important. The Simple Service Discovery Protocol (SSDP) is an application layer protocol used to discover and publish devices and services in a LAN or server cluster.

[0003] Currently, SSDP uses the simple User Datagram Protocol (UDP) to transmit messages for device discovery and communication. However, in practical applications, such as large-scale intelligent campuses, UDP-based message transmission struggles to ensure security, reliability, and isolation between multiple devices. Summary of the Invention

[0004] In view of the above problems, the present application provides a message transmission method, device, electronic device and computer storage medium.

[0005] According to the first aspect of the present application, a message transmission method is provided, comprising: in response to receiving a first message from a first device, determining message information matching the first message, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group consisting of multiple devices; calling a transmission interface, determining a transmission mode for transmitting the message information according to the message type, and transmitting the message information to a receiving device matching the receiving device information through the transmission mode; wherein the transmission mode includes a first transmission mode and a second transmission mode using different transmission protocols, and the security level of the transmission protocol used by the first transmission mode is higher than the security level of the transmission protocol used by the second transmission mode; the transmission interface is also used to encrypt the message information.

[0006] The second aspect of the present application provides a message transmission device, including: a determination module, used to determine message information matching the first message in response to receiving a first message from a first device, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group consisting of multiple devices; a calling module, used to call a transmission interface, determine a transmission method for transmitting the message information according to the message type, and transmit the message information to a receiving device matching the receiving device information through the transmission method; wherein the transmission method includes a first transmission method and a second transmission method using different transmission protocols, and the security level of the transmission protocol used by the first transmission method is higher than the security level of the transmission protocol used by the second transmission method; the transmission interface is also used to encrypt the message information.

[0007] The third aspect of the present application provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0008] The fourth aspect of the present application further provides a computer-readable storage medium having a computer program or instructions stored thereon, which implements the steps of the above method when the computer program or instructions are executed by a processor.

[0009] The fifth aspect of the present application further provides a computer program product, comprising a computer program or instructions, which implement the steps of the above method when executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The above contents and other objects, features and advantages of the present application will become more apparent through the following description of the embodiments of the present application with reference to the accompanying drawings.

[0011] Figure 1 An application scenario diagram of the message transmission method, apparatus, device, medium, and program product according to an embodiment of the present application is shown.

[0012] Figure 2 A schematic diagram of a protocol architecture according to an embodiment of the present application is shown.

[0013] Figure 3 A flowchart of a message transmission method according to an embodiment of the present application is shown.

[0014] Figure 4 A scenario diagram of digital certificate verification based on MDP according to an embodiment of the present application is shown.

[0015] Figure 5 A scenario diagram of device group creation and device group joining based on MDP according to an embodiment of the present application is shown.

[0016] Figure 6 A scenario diagram of device registration based on MDP according to an embodiment of the present application is shown.

[0017] Figure 7 A scenario diagram of performing a service request based on MDP according to an embodiment of the present application is shown.

[0018] Figure 8 A diagram of an extended message transmission scenario for customizing message types and service information based on MDP according to an embodiment of the present application is shown.

[0019] Figure 9 A diagram showing a scenario of encryption and decryption using a symmetric encryption algorithm and an asymmetric encryption algorithm according to an embodiment of the present application.

[0020] Figure 10 A diagram showing a retransmission scenario of TCP transmission based on MDP according to an embodiment of the present application is shown.

[0021] Figure 11 A scenario diagram of UDP transmission based on MDP according to an embodiment of the present application is shown.

[0022] Figure 12 The figure shows a structural block diagram of a message transmission device according to an embodiment of the present application.

[0023] Figure 13 A block diagram of an electronic device suitable for implementing a message transmission method according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present application. In the detailed description below, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of the embodiments of the present application. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessarily confusing the concepts of the present application.

[0025] The terms used herein are only for describing specific embodiments and are not intended to limit this application. The terms "comprise," "include," etc. used herein indicate the presence of the features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0026] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0027] In the technical solution of this application, the user information involved (including but not limited to user personal information, user image information, user device information, such as location information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0028] For service and device discovery scenarios, SSDP uses UDP for underlying message transmission. During the device discovery phase, a device periodically sends a NOTIFY message containing its own device information and service description to a specific multicast address. The message format follows the Hypertext Transfer Protocol (HTTP) over UDP, also known as the HTTPU protocol format, and carries key information such as the device name, type, and service address in text form. Receiving devices capture the notification message through this multicast address, thereby discovering new devices on the network. For example, on a home network, when a smart TV first connects to the network, it automatically sends a NOTIFY message to the multicast address. Other SSDP-supported devices in the home (such as smart speakers and smart routers) can receive this message and become aware of the smart TV's presence.

[0029] When a device needs to find a specific service, it sends a search request message (M-SEARCH), which contains the target service type or other filtering criteria. After receiving the M-SEARCH message, if the service it provides matches the request, the device on the network will reply with a response message (HTTP 200 OK) containing a detailed description of the device and service. In SSDP scenarios, devices describe their device information and detailed descriptions of services by providing standardized text files, such as Extensible Markup Language (XML). For example, in an office network, if a computer needs to find a network print service, it will send an M-SEARCH message. After receiving the message, a printer in the office area, if it supports the print service, will send a response message to the computer. Based on the information in the response message, the computer can connect to the printer and perform the print task.

[0030] However, the UDP protocol used by SSDP is inherently connectionless, eliminating the need for a handshake between the sending and receiving devices before message transmission, and eliminating the need to establish a dedicated logical connection channel. Consequently, message transmission is prone to packet loss, out-of-order messaging, or duplication, leading to unreliable message transmission. Furthermore, the lack of a security verification mechanism makes it difficult to verify the identity of the device sending SSDP messages, making them vulnerable to interception and devices unable to handle SSDP amplification attacks, limiting the security of message transmission. This problem becomes increasingly prominent in large-scale network environments.

[0031] For example, large intelligent campuses with numerous network devices typically utilize large-scale network environments. For the simple unicast and multicast methods described above, when devices perform periodic service notifications, reliable message transmission cannot be guaranteed. This can result in notification messages sent by some devices not being fully received by other devices, or being duplicated or out of order during transmission. This can lead to incomplete device discovery or delayed service status updates, impacting the normal use and collaborative operation of devices and services within the network. Furthermore, in complex network environments, the packet loss rate for UDP-based messages can reach 10%-20%, severely hindering efficient network operation. For SSDP amplification attacks, attackers can fabricate source Internet Protocol (IP) addresses to send SSDP query requests to a large number of reflectors, causing these reflectors to flood the campus with search request messages, resulting in network congestion and even denial of service for devices within the campus.

[0032] Furthermore, in real-world applications, large-scale intelligent campuses with numerous network devices often require group management. This allows for differentiated management by differentiating devices, and also for security reasons, allows for device and service isolation. However, current SSDP messaging makes it difficult to implement flexible device grouping, as well as differentiated access control, service control, and bandwidth allocation within these groups.

[0033] To this end, the present application proposes a message transmission method, including: in response to receiving a first message from a first device, determining message information that matches the first message, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group composed of multiple devices; calling a transmission interface, determining a transmission method for transmitting the message information according to the message type, and transmitting the message information to a receiving device that matches the receiving device information through the transmission method; wherein the transmission method includes a first transmission method and a second transmission method using different transmission protocols, and the security level of the transmission protocol used by the first transmission method is higher than the security level of the transmission protocol used by the second transmission method; the transmission interface is also used to encrypt the message information. By encapsulating the new Managed Discovery Protocol (MDP) into the transmission interface, after receiving the first message from the first device and determining the message information that matches the first device, the transmission interface can be called to automatically select the transmission method of the message information to be transmitted according to the message type in the message information, and perform encrypted transmission to make up for the shortcomings of SSDP and meet the security and reliability of message transmission between multiple devices in device discovery and service discovery scenarios; for message types including those used to manage device groups composed of multiple devices, the MDP-based transmission interface can provide corresponding group management functions to improve the security, reliability and flexibility of group management of device discovery and service management in the network.

[0034] Figure 1 An application scenario diagram of the message transmission method, apparatus, device, medium, and program product according to an embodiment of the present application is shown.

[0035] like Figure 1 As shown, the application scenario according to this embodiment may include multiple first terminal devices 101, second terminal devices 102, and third terminal devices 103. A network 104 is used as a medium to provide communication links between the first terminal devices 101, the second terminal devices 102, and the third terminal devices 103. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. The first terminal devices 101, the second terminal devices 102, and the third terminal devices 103 may be various electronic devices with display screens and web browsing support, including but not limited to smartphones, tablet computers, laptop computers, and desktop computers. They may also be network devices such as gateways, routers, and servers.

[0036] It should be noted that the first terminal device 101, the second terminal device 102, and the third terminal device 103 can all be used as sending devices or receiving devices to realize message transmission between devices. Therefore, the message transmission method provided in the embodiment of the present application can be executed by the first terminal device 101, the second terminal device 102, and the third terminal device 103. Correspondingly, the message transmission device provided in the embodiment of the present application can be set in the first terminal device 101, the second terminal device 102, and the third terminal device 103. It should be understood that Figure 1 The number of terminal devices and networks in the embodiment is merely illustrative. Any number of terminal devices and networks may be provided as required.

[0037] Figure 2 A schematic diagram of a protocol architecture according to an embodiment of the present application is shown.

[0038] In the embodiment of the present application, the MDP integrated with the transmission interface adopts a layered architecture, which includes the application layer, the transport layer, the network layer, the data link layer and the physical layer from top to bottom. Figure 2 As shown, two adjacent layers can communicate with each other.

[0039] Application layer: Responsible for handling application logic such as device and service discovery, registration, deregistration, and group management. The application layer interacts with application software, generates corresponding application layer messages, packages these messages, and sends them to the transport layer. The application layer also parses and processes application software messages, invoking and processing the corresponding functional modules based on business needs. For example, if a user sends a device query request through the network management platform, the application layer receives the request, constructs an MDP query message based on the query criteria, and sends it.

[0040] Transport layer: This layer implements hybrid transmission and can transmit messages via both a primary and secondary transmission mode. For example, the primary transmission mode might use the Transmission Control Protocol (TCP), while the secondary transmission mode might use the UDP. The primary and secondary transmission modes are referred to as TCP and UDP, respectively. The transport layer is responsible for message encapsulation and decapsulation, as well as conversion and forwarding between different transmission protocols. It selects the appropriate transport protocol based on the message type and priority to achieve efficient and reliable message transmission. For example, the transport layer can leverage the reliability of TCP to ensure the accurate transmission of critical messages (such as device registration, deregistration, and group management), ensuring network connectivity stability. UDP is also reserved for the rapid transmission of device discovery messages to improve discovery efficiency.

[0041] Network layer: Responsible for routing and addressing within the network. Specifically, it routes MDP messages and determines their forwarding paths, ensuring they are accurately delivered to the receiving device or target service within the receiving device. The network layer combines network topology information and routing policies to select the optimal transmission path for messages. It supports device discovery and service interaction in multi-network environments, enabling cross-subnet device and service communication.

[0042] Data Link Layer: Performs Media Access Control (MAC) processing, such as MAC address resolution, frame construction, and de-framing, to ensure correct data transmission on the physical medium. The data link layer also detects and corrects errors in received data to ensure accurate data transmission, and controls access to the transmission medium to avoid data conflicts.

[0043] Physical layer: The lowest level of physical media transmission, used for interaction of physical media and message transmission.

[0044] The first message, message information, and other information involved in the message transmission method provided herein are all MDP messages, which can be transmitted using TCP or UDP. The format of an MDP message includes a message header and a message body. The message header includes the message type and receiving device information, while the message body includes specific content and fields corresponding to the message type. Furthermore, encryption and decryption of message information refers to the encryption and decryption of information within the message body.

[0045] For example, the message header may include the following.

[0046] The protocol version information can be a version number (Version) with a length of 4 bits, which is used to ensure that the sending device and the receiving device of the message use compatible protocol versions for communication.

[0047] Message Type (Type): 8 bits, defines the type of message, such as device discovery type (DiscoverRequest), device discovery response type (DiscoverResponse), device registration type (Register), device deregistration type (Unregister), device group creation type (CreateGroup), device group joining type (JoinGroup), device group exit type (LeaveGroup), etc. The receiving device can select the corresponding processing logic according to the message type.

[0048] Message ID: 32 bits, used to uniquely identify an MDP message, facilitating message confirmation, retransmission, and matching operations. In the same interaction process, the sent and received messages have the same Message ID.

[0049] Source IP address: 32 bits or 128 bits, compliant with the Internet Protocol version (IPv4) such as IPv6, used to identify the IP address of the device sending the message and used for message routing and return.

[0050] Destination IP address: 32 bits or 128 bits, used to identify the IP address of the message receiving device. For UDP broadcast or multicast messages, it can be a broadcast address or a multicast address.

[0051] Source Port: 16 bits, used to identify the application port number that sends the message, used to distinguish different MDP application instances and services.

[0052] Destination Port: 16 bits, used to identify the application port number that receives the message, ensuring that the message is correctly delivered to the target application.

[0053] Message Length: 16 bits, indicating the total length of the entire MDP message (including the message header and message body), in bytes, used for message parsing and integrity checking.

[0054] Checksum: 16 bits, used to detect errors during message transmission. The receiving device calculates the checksum of the received message and compares it with the checksum in the message header. If they do not match, the message is discarded and a retransmission request may be requested. For example, the message sum can be a hash value calculated using a hash algorithm or a message digest.

[0055] The following will be based on Figure 1 The scene described by Figures 3 to 11 The message transmission method of the embodiment of the present application is described in detail.

[0056] Figure 3 FIG. 1 shows a flow chart of a message transmission method according to an embodiment of the present application. Figure 3 As shown, the embodiment 300 includes operations S310 to S320.

[0057] In operation S310, in response to receiving a first message from a first device, message information matching the first message is determined, wherein the message information includes receiving device information and a message type.

[0058] In a message transmission scenario, a device can be both a receiver and a sender of a message. For example, the first device that sends a message is the sender of the first message, while the current device that receives the first message is the receiver. For messages to be sent, the current device can also be the sender of the message.

[0059] The first message has a specific function, such as notification, service request, device discovery, device registration, etc. Message information matching the first message refers to message information sent to the receiving device after processing the first message. For example, for a first message with multiple functions, after receiving the first message, the current device invokes a service of the current device based on the first message, obtains a service result, and generates message information based on the service result.

[0060] Receiving device information represents attribute information of the receiving device of the message. For example, this attribute information may include at least one of the following: device name, device type, IP address, MAC address, port address, and device description. For a receiving device, the IP address in its attribute information can be used as the destination IP address in the message header, and other information can be set in the message body to facilitate the transmission of the receiving device message.

[0061] The message type defines the type of message and indicates the function of the message information. For example, the function indicated by the message type may be the same as or different from the first message. For example, the message type may be a type indicating functions such as notification, service request, device discovery, and device registration.

[0062] Message types can include those used to manage device groups composed of multiple devices, enabling device group management in device and service discovery scenarios. Message types include types for creating a device group, joining a device group, and exiting a device group. Multiple devices in a large intelligent campus can be organized into multiple device groups. For example, five devices can form one device group, and another three devices can form another device group, or three of the five devices can form a new device group with another three devices. Multiple device groups typically have multiple permissions and management policies.

[0063] For example, in one embodiment, a first message is used to request a service on the current device. In response to receiving the first message, the current device processes the information in the first message according to the service indicated in the first message to obtain the corresponding service result. In this case, the receiving device is the first device, the message information may include the service result, the message type may be feedback on the service request, and the receiving device information may be the IP address of the first device.

[0064] In operation S320 , a transmission interface is called to determine a transmission method for transmitting the message information according to the message type, and the message information is transmitted to a receiving device that matches the receiving device information through the transmission method.

[0065] According to an embodiment of the present application, a transmission interface encapsulates a new MDP, and by calling the transmission interface, various functions corresponding to the MDP can be implemented. In an embodiment of the present application, calling the transmission interface in an SSDP scenario can realize the autonomous selection of a transmission method based on the message type in the message information, rather than relying on only one transmission method. For example, by calling the transmission interface, the transmission method that matches the message type can be determined based on the mapping relationship between the message type and the transmission method in the MDP, and the message information can be transmitted to the receiving device via the transmission method.

[0066] MDP supports message transmission using a first transmission mode and a second transmission mode using different transmission protocols. This means that the message information can be transmitted to the receiving device using either the first transmission mode or the second transmission mode. It is understood that for message information of multiple message types, the first transmission mode may be used for some message types, while the second transmission mode may be used for other message types.

[0067] The security level of the transmission protocol used in the first transmission mode is higher than the security level of the transmission protocol used in the second transmission mode. The security level of the transmission protocol is determined based on its characteristics. For example, if a transmission protocol requires more device authentication operations or handshake operations, the security level of the transmission protocol is higher. For example, the transmission protocol used in the first transmission mode may be TCP, and the transmission protocol used in the second transmission mode may be UDP.

[0068] The transmission interface is also used to encrypt message information, that is, MDP also supports encryption of message information, which solves the problem that SSDP does not support encryption and further improves the security of message transmission.

[0069] In one embodiment, the transmission interface may determine whether to encrypt the message information according to the transmission mode; and may also encrypt the message information using at least one encryption algorithm.

[0070] It should be noted that, as the sending device of the first message, the first device may also call a transmission interface to determine a transmission mode of the first message, such as TCP or UDP, according to the message type included in the first message.

[0071] In an embodiment of the present application, in response to receiving a first message from a first device and determining that the message information matches the first device, the current device can automatically select a transmission method for the message information to be transmitted based on the message type in the message information by calling a transmission interface encapsulated with a new MDP, and perform encrypted transmission, thereby meeting the security and reliability of message transmission between multiple devices in SSDP scenarios. For message types including those used to manage device groups composed of multiple devices, the MDP-based transmission interface can also provide corresponding group management functions to improve the security, reliability, and flexibility of group management for device discovery and service management in the network.

[0072] Consider that SSDP only supports sending notification messages via multicast to a specific multicast address, which is accessible to all devices for message synchronization. However, in large intelligent campuses, devices / services across buildings may not need to be synchronized, and management policies for devices / services in different buildings may differ. Therefore, SSDP's group management capabilities for devices and services are weak, unable to meet the requirements for flexible device grouping and differentiated policy deployment in complex networks, resulting in inefficient group management.

[0073] In an embodiment of the present application, the current device is capable of receiving the first message of multiple management device groups sent by the first device, and determining the message information matching the first message, and then sending the message information of the management device group to the receiving device by calling the transmission interface, so that the device group management function is applicable between the first device, the current device and the receiving device.

[0074] In a specific embodiment, the first message includes a device group creation message, and in response to receiving the first message from the first device, determining message information that matches the first message includes: in response to receiving the device group creation message from the first device, parsing the device group creation message to obtain group information of the first device group to be created, wherein the group information includes at least one of the following: identification information, description information, device range, access rights, and group management policy; generating a group record for the first device group based on the group information of the first device group; determining that the message type that matches the device group creation information is a new group broadcast type; and determining at least one device in the second device group other than the current device based on the second device group to which the current device belongs; wherein the message information includes: group record, new group broadcast message, and receiving device information indicating that at least one device is a receiving device.

[0075] For example, identification information includes a universally unique identifier (UUID) and the group name. The device scope can include the conditions for devices allowed to join the device group, or the service configurations supported by devices within the device group. For example, the service configurations can include the types of services allowed to be published and discovered within the group, service priorities, and so on. Descriptive information is used to indicate the service functions and management functions of the device group. Access rights can include which roles or device attributes are supported for access by devices within the device group. Group management policies can include access control policies that adjust the aforementioned access rights, service discovery policies that adjust the aforementioned device scope, and other management policies, such as data transmission policies and bandwidth limitation policies. This group information is used to create device groups with specific attributes and rules in the MDP to organize and manage devices and services. For the device group creation message (CreateGroup), the message body contains this group information.

[0076] Each device group can have one or more group management policies. For example, for a specific floor of an enterprise network, all R&D devices in the "R&D Group" can be grouped together to prioritize network bandwidth and assign specific service access permissions, limiting access to internal R&D servers and related testing tools. All marketing devices in the "Marketing Group" can be grouped together to assign different network resources and access permissions. When a device is added to a specific device group, the group management policy for that device group is automatically applied, enabling refined network management and resource allocation based on the device group, improving network security and management efficiency.

[0077] In one implementation, the first device may be provided with a network management platform. A user may interact with the network management platform of the first device to specify the group information of the first device group to be created. Based on the interaction, the first device encapsulates the group information of the first device group into a device group creation message. In this case, the message type is device group creation type. The first device determines a transmission method that matches the device group creation type by calling a transmission interface, and transmits the device group creation message to the current device using this transmission method. In response to receiving the device group creation message from the first device, the current device parses the device group creation message to obtain the group information of the first device group.

[0078] For example, the user can specify the identification information of the created device group as A, the description information as the power supply device group of all devices on the current floor, the device range as all power supply devices on the current floor, the access permission as power supply service personnel, and the group management policy can be that the network bandwidth priority is lower.

[0079] The current device may be a group management server. After receiving the group information of the first device group, the current device may generate a group record in a predetermined format based on the group information of the first device group and create a group record for the first device group in a corresponding group management database. For example, the format of the group record may match that of the group management database. Furthermore, the group management database may store relevant configuration information and a member list of the device group to provide data support for subsequent group management operations.

[0080] When the first message is a device group creation message, in order to ensure that the device group can be created sequentially and allow multiple devices to automatically join the device group, the group information of the first device group needs to be broadcast to multiple devices. Therefore, the message type in the message information can be directly determined to be a new group broadcast type.

[0081] Because the current device is a group management server, and the group management server can simultaneously belong to at least one second device group to implement management functions for multiple devices in the at least one second device group, to ensure that all devices permitted to join the first device group can discover and join the newly created first device group, at least one device in the at least one second device group, excluding the current device, can be identified as a receiving device based on the member list of the at least one second device group. It is understood that the group management server can pre-store information about at least one device. Once the at least one device is identified, the group management server can directly obtain information about each of the at least one device, i.e., the receiving device information.

[0082] Therefore, the message information matching the device group creation message includes: the group record, the new group broadcast type, and receiving device information indicating at least one receiving device. This broadcasts the creation of the first device group to the at least one device, and each device can determine whether to join the first device group based on its own attribute information. For example, each device can determine whether to join the first device group based on its device type, department, geographic location, and the device range in the group record. If joining the first device group is desired, the device can proactively send a device group join message to the group management server.

[0083] In an embodiment of the present application, by receiving a device group creation message and using at least one second device group to which the group management server belongs, at least one device to be notified is determined, thereby avoiding the situation where the device cannot join the first device group due to failure to receive a message that the first device group has been created, thereby realizing the device group creation function in the group management scenario.

[0084] In another specific embodiment, a large-scale intelligent campus can simultaneously host multiple group management servers, each managing one or more device groups. The device scope can also include designated group management servers. Thus, a first device can send a device group creation message to the designated group management server and broadcast the creation of the first device group to at least one second device group belonging to the designated group management server, without broadcasting to all devices. This not only avoids the situation where devices cannot join the first device group due to not receiving the creation message, but also enables notification at the granularity of multiple device groups.

[0085] In another specific embodiment, the first message includes at least one of the following: a device group join message and a device group exit message; in response to receiving the first message from the first device, determining that the message information that matches the first message includes: in response to receiving the first message from the first device, parsing the first message to obtain the digital certificate information of the first device and the third device group; for the device group join message, verifying the digital certificate information of the first device and the device join conditions of the third device group respectively to obtain group change information for the third device group; for the device group exit message, verifying the digital certificate information of the first device to obtain group change information for the third device group; determining that the message type that matches the first message is a device group change type; wherein the message information includes: group change information, device group change type, and receiving device information indicating that at least one device in the third device group is a receiving device.

[0086] For a certain established third device group, a first device can proactively apply to join or leave the third device group. For example, if the first device needs to be offline for maintenance, the first device can proactively apply to leave the third device group; if the first device comes online, the first device can proactively apply to join the third device group. For an entire large-scale intelligent campus, because multiple first devices come online and offline at different times, the number of first devices joining and leaving the entire third device group changes dynamically, and the devices included in the third device group also change.

[0087] For a first device requesting to join or exit a device group, the first device can invoke a transmission interface, determine a transmission method based on the device group join or exit type, and, based on this transmission method, encapsulate a message containing the first device's digital certificate, the third device group, and the message type into a device group join or device group exit message and send it to the current device. Furthermore, if the device group has permissions corresponding to roles, the device group join message can also include the role requested when joining the device group.

[0088] The current device may be a group management server. In response to receiving a device group join message or a device group exit message, the current device may parse the device group join message or the device group exit message to obtain the digital certificate information of the first device and the third device group. It should be noted that the device group join message or the device group exit message may refer to the third device group using identification information.

[0089] Regarding the device group join message, since the third device group has a corresponding group management policy, if the first device's identity and device group joining conditions are not verified, the first device's risk could expose all devices in the third device group to risk. Therefore, the current device not only verifies the digital certificate information but also locally obtains the device joining conditions for the third device group and verifies whether the first device meets these conditions.

[0090] For example, digital certificate information includes the device's identity, validity period, and digital signature. Furthermore, when using an asymmetric encryption algorithm to encrypt messages, the digital certificate also includes the device's public key. Before connecting to the network, each MDP device must apply for and install a digital certificate from a Certificate Authority (CA).

[0091] The method for verifying digital certificate information includes: obtaining a verification public key that matches the identity information; comparing the public key in the digital certificate information with the verification public key to determine whether they are consistent, thereby obtaining a first verification result; verifying the issuing authority of the digital signature based on the digital signature to obtain a second verification result; and verifying the validity of the digital certificate information based on the validity period to obtain a third verification result. If the first, second, and third verification results all pass, the verification result of the digital certificate information is determined to be passed; otherwise, if any verification result fails, the verification result of the digital certificate information is determined to be failed. For example, if the public key and the verification public key are consistent, the first verification result is determined to be passed; otherwise, it is failed. By verifying the compliance of the issuing authority of the digital signature, if the verification passes, the second verification result is determined to be passed; otherwise, it is failed. If the validity of the digital certificate information passes, the third verification result is determined to be passed. In this embodiment, through a two-way authentication mechanism based on digital certificate information, identity authentication is not only performed on the first device, but also further authentication is performed when joining a third device group, thereby avoiding security risks caused by device identity fraud.

[0092] Figure 4 FIG1 shows a scenario diagram of digital certificate verification based on MDP according to an embodiment of the present application. Figure 4As shown, the first device is device A and the current device is device B. When device A accesses the network, device A applies for digital certificate information from the CA. After the application is successful, device A installs the digital certificate information locally. Device A sends a message carrying the digital certificate information, and device B receives the message carrying the digital certificate information. The message carrying the digital certificate information can be of various message types. Device B verifies the digital certificate information, including: verifying the digital signature, validity period, and public key separately, and determining whether all three verifications pass. If all three verifications pass, the identity authentication passes, a trusted connection is established, and the operation corresponding to the message is executed; if any verification fails, the connection is rejected and a log is recorded.

[0093] The device joining condition can be determined based on the group information provided when the device group is created. For example, the device joining condition can be: the first device meets the device range of the third device group.

[0094] In this embodiment, if the verification results of the digital certificate information of the first device and the device joining conditions of the third device group are both passed, the first device is allowed to join the third device group, the first device can be added to the member list of the third device group, and group change information indicating that a change has occurred to the third device group is generated, such as the group change information "the first device is added to the third device group."

[0095] In response to the device group withdrawal message, the digital certificate information of the first device is verified to obtain group change information for the third device group. The verification of the digital certificate information is described above. If the verification result of the digital certificate information is positive, the first device is allowed to withdraw from the third device group. The first device may be deleted from the member list of the third device group, and group change information indicating a change in the third device group is generated, such as the group change information indicating "the first device withdraws from the third device group."

[0096] For device group join and exit messages, not only do the first device and the group management server need to change the device group's group information, but all other devices in the third device group also need to update their member lists to ensure consistent information across all devices in the third device group. Therefore, the message information includes: group change information, device group change type, and receiving device information indicating that at least one device in the third device group is a receiving device. The group management server can broadcast the message information to at least one device in the third device group to dynamically update the device's member list.

[0097] In an embodiment of the present application, the group management server (the current device) receives a device group join message and verifies the digital certificate information of the first device and the device join information of the third device group. This dual assurance mechanism ensures that the first device is protected from identity theft and meets the conditions for joining the third device group, thereby ensuring the security of the device group while dynamically managing the device group. The group management server receives a device group exit message and verifies the digital certificate information of the first device. This ensures that the first device is protected from identity theft, thereby ensuring the security of the device group while dynamically managing the device group. Furthermore, by using at least one device in the third device group as a receiving device, data consistency between the third device and at least one device in the device group can be further guaranteed.

[0098] Figure 5 A scenario diagram of device group creation and device group joining based on MDP according to an embodiment of the present application is shown.

[0099] like Figure 5 As shown in the figure, the administrator creates device group 1 through the network management platform and specifies detailed group information. The server of the network management platform constructs a device group creation message (CreateGroup) and transmits the CreateGroup message to the group management server through TCP. The group management server creates a group record locally and broadcasts a new group broadcast type message to multiple devices in device group 2 to which the group management server belongs. For example, a group creation notification message (GroupNotification) is sent to devices A, B, C, etc. to notify the creation of the new device group 1. Devices A, B, and C can decide whether to apply to join device group 1 based on their own circumstances.

[0100] When device C needs to join an existing device group 1, it constructs a JoinGroup message and sends it to the group management server via TCP. The group management server parses the JoinGroup message and verifies the digital certificate information and the device joining conditions for device group 1. If verification succeeds, device C is added to the member list and the other devices in device group 1 are notified, completing the joining process. For example, a message indicating a change in joining the device group, such as a JoinResponse message, is sent to device C. The server also notifies the other devices in device group 1 of the joining status via TCP, updates the group member list, and completes the joining process. If verification fails, the group management server sends a JoinFailureResponse message to device C via TCP, indicating the reason for the failure.

[0101] Similarly, when device C needs to exit device group 1, it sends a LeaveGroup message to the group management server via TCP. The group management server removes device C from the member list of device group 1 and notifies other devices in the group via TCP to update the member list, completing the group exit process.

[0102] In another embodiment, the first message includes a registration message; in response to receiving the first message from the first device, determining the message information that matches the first message includes: in response to receiving the registration message from the first device, parsing the registration message; in a case where the parsed registration message includes the registration information of the first device, group information of the fourth device group and the digital certificate information of the first device, verifying the digital certificate information of the first device and the device joining conditions of the fourth device group respectively to obtain the registration result of the first device, wherein the fourth device group is the device group that the first device requests to join when registering; determining that the message type that matches the registration message is a registration result notification type; generating message information based on the registration result, wherein the message information includes the registration result, the registration result notification type, and receiving device information indicating that at least one device in the fourth device group and the first device are receiving devices.

[0103] If the first device is new, it must complete initialization before joining the network. The initialization process involves loading local information, including device attributes and key files, upon device startup. The device then starts the MDP protocol stack, initializes each protocol layer module, establishes connections with the network and transport layers, and prepares to begin sending, receiving, and processing MDP messages. After initialization, the first device actively registers itself to provide services on the network or participate in group management.

[0104] The fourth device group refers to the device group that a device must join by default when registering.

[0105] For example, a first device generates a Register message, which typically includes detailed registration information, such as device attributes, a list of provided services, security level, and scalable service attributes. Furthermore, for a first device that has completed initialization, the Register message also includes the digital certificate information issued by the CA. For a first device that is required to join a device group by default, the Register message also includes the group information for the device group to be joined. The aforementioned digital certificate information, group information, and registration information can all be located in the body of the Register message.

[0106] For the first device, the transmission mode corresponding to the Register message can be determined by calling the transmission interface, and the Register message can be sent to the current device through the transmission mode.

[0107] The current device may be a group management server. Upon receiving the Register message, the current device parses the message. If the Register message includes the first device's registration information, digital certificate information, and group information for the fourth device group, the group management server must authenticate the first device and verify whether the first device can join the fourth device group. The verification methods for the digital certificate information and device joining conditions are described above and are not further elaborated here.

[0108] If both the digital certificate information and the device joining conditions of the fourth device group are verified as successful, the registration result is determined to be successful, the first device's registration information is stored locally on the group management server, and the first device is added to the fourth device group. Conversely, if either verification result is unsuccessful, the registration result is determined to be unsuccessful. Regardless of whether the registration result is successful, the devices in the fourth device group and the first device are notified. Therefore, the message type matching the registration message is the registration result notification type.

[0109] For example, if the registration result is successful, a message (e.g., a registration success response (RegisterResponse) indicating success) is broadcast to the devices in the fourth device group and the first device, notifying at least one device in the fourth device group to update its member list. The first device is notified of the registration success and its member list is updated. If the registration result is unsuccessful, the message (e.g., a registration failure response (Registerfault) indicating failure) may also include the reason for the failure, such as identity authentication failure, digital certificate expiration, or network policy restrictions.

[0110] It can be understood that when the Register message does not include the group information of the fourth device group, only the digital certificate information of the first device can be verified. If the verification is successful, the registration result is determined to be successful, and the registration information of the first device is stored locally on the group management server; otherwise, the registration result is determined to be failed.

[0111] In an embodiment of the present application, the group management server receives a registration message and, when the registration message includes the group information of the fourth device group, synchronously verifies the digital certificate information of the first device and the device joining information of the fourth device group, and synchronously completes the verification of device group joining when the device is registered. This not only enables dynamic joining of the device group during registration, but also ensures that the first device will not suffer from identity theft and ensures the security of the device group.

[0112] It should be noted that the above-mentioned first device group, second device group, third device group, and fourth device group are only nicknames for describing the first messages of multiple functions. In fact, the above-mentioned four device groups can be the same or different, depending on the actual situation.

[0113] Figure 6 FIG1 shows a scene diagram of device registration based on MDP according to an embodiment of the present application. Figure 6 As shown, device P can construct and send a registration message by calling a transmission interface. Device P sends the registration message to the group management server via TCP. If the registration message includes group information, the group management server verifies the digital certificate information and the device's joining conditions. If verification is successful, the group management server stores the registration information locally and updates the member list. A registration success response is then returned to device P. Otherwise, the server returns the failure reason.

[0114] According to an embodiment of the present application, a transmission mode for transmitting message information is determined according to the message type, including: when the message type is determined to be the first type, the first transmission mode is determined as the transmission mode for transmitting the message information; when the message type is determined to be the second type, the second transmission mode is determined as the transmission mode for transmitting the message information.

[0115] The security level of the first type is higher than that of the second type. For example, the first type may be a type with a higher security level, and thus, it can be transmitted through a first transmission method with a higher security level, such as TCP, to ensure the security of the message transmission process; the second type may be a type with a lower security level, and can be transmitted through a second transmission method with a lower security level, such as UDP, to ensure the speed of message transmission.

[0116] In the embodiments of the present application, by calling a transmission interface and selecting a corresponding transmission method based on the message type, the security level of the message information can be determined independently based on the message type of the message to be transmitted, thereby determining a transmission method that is compatible with the security level and meeting the security transmission requirements or the speed transmission requirements of the message information. For the current device, since the current device can send multiple message information to multiple devices, by calling the transmission interface to determine the corresponding transmission method for each message information, it is possible to balance the security and speed of the overall message transmission of the current device.

[0117] According to an embodiment of the present application, the first type includes at least one of the following: a device registration type, a registration result notification type, a device deregistration type, a deregistration result notification type, a data transmission type, a backup data recovery type, a network exception handling type, a fault handling type, and a type for managing a device group consisting of multiple devices. The type for managing a device group consisting of multiple devices includes one of the following: a device group creation type, a new group broadcast type, a device group change type, a device group join type, and a device group exit type. The second type includes at least one of the following: a device discovery type, a device survival type, a backup notification type, a backup verification type, a network status type, and a fault alarm type.

[0118] In an embodiment of the present application, a new function of managing device groups is added in the service discovery and device discovery scenarios through a transmission interface. The device group management function is to improve the security and isolation of the interaction between devices and services. Therefore, in order to avoid the leakage or loss of messages related to the management of device groups, types used to manage device groups and types related to registration and deregistration that may involve changes in device groups can be transmitted through a first transmission method with a higher security level. The security of information transmission is further improved while achieving refined management of device group functions. For types involved in fault and abnormal scenarios, transmission through the first transmission method can ensure the security of fault and abnormality analysis and processing. For types related to device discovery, service discovery or alarm notifications, transmission is carried out through the second transmission method to improve the speed of notifications.

[0119] In one embodiment, the first message and the message information are transmitted in the same manner, and both may use the first transmission manner.

[0120] Taking the device group creation message, device group join message, device group exit message, and registration message (including group information of the fourth device group) included in the first message as an example, if the first messages are respectively a registration message, a device group join message, a device group exit message, and a device group creation message, and the message types of the first messages are respectively device registration type, device group join type, device group exit type, and device group creation type, the first device can transmit the first message via the first transmission method. After the current device determines the message information corresponding to each of the first messages, it determines to use the first transmission method to transmit the message information based on the new group broadcast type, device group change type, and registration result notification type in the message information.

[0121] In addition, the deregistration type and deregistration result notification type are similar to the registration type and registration result notification, respectively. For example, if the first message includes a deregistration message, the group management server receives the deregistration message from the first device and parses the deregistration message. The parsed deregistration message includes the group information of the fifth device group to which the first device belongs and the digital certificate information of the first device. If the verification result of the digital certificate information of the first device is passed, the deregistration result is determined to be passed, and the registration information of the first device is deleted on the group management server. The message type is determined to be a deregistration result notification type, and the message information includes the deregistration result, the deregistration result notification type, and receiving device information indicating that at least one device in the fifth device group and the first device are receiving devices.

[0122] In one embodiment, the first message and the message information may both use the second transmission mode. For example, the first message and the message information of the device discovery type and the device survival type may both use the second transmission mode.

[0123] For example, in an active discovery scenario, when a first device needs to discover other devices or services within a network, it constructs a first device discovery message, such as a DiscoverRequest message, setting parameters such as the discovery scope and requested device attributes. These parameters can be used as the message body of the DiscoverRequest message. By invoking a transport interface, it selects UDP for transmission to the current device (including the group management server and other devices). After receiving the DiscoverRequest message, other devices on the network determine whether they meet the discovery criteria based on their own attributes and current authorization status. If so, they generate a device discovery message, such as a DiscoverResponse message. This message contains the device's attributes, service information, a message type indicating the device discovery type, and a message from the receiving device (typically the first device sending the DiscoverRequest). The message is then returned to the first device via UDP. After collecting multiple DiscoverResponse messages, the first device can organize and analyze the device attributes and service information, update its local device and service lists, and complete the device discovery process.

[0124] In a passive discovery scenario, the first device can periodically send a first device presence notification message (such as an AliveNotification) via UDP multicast to inform other devices of its presence status, device information, and service information. Upon receiving the AliveNotification message, the current device updates the corresponding information in its local device list and service list and generates a device presence message. This message includes the updated device and service list, as well as receiving device information indicating that the first device is the recipient. The current device can also return the message to the first device via UDP. This passive discovery mechanism ensures timely and accurate updates to the device and service lists.

[0125] In another embodiment, the first message and the message information are transmitted using different transmission modes, for example, the first message uses the first transmission mode and the message information uses the second transmission mode; or the first message uses the second transmission mode and the message information uses the first transmission mode.

[0126] In actual application, for the message transmission process that supports a single transmission method, such as the existing SSDP, it can only meet the speed of message transmission, but cannot meet the security, let alone balance security and speed.

[0127] In an embodiment of the present application, devices that perform message transmission based on MDP all support the first transmission mode and the second transmission mode, such as both supporting UDP and TCP. Therefore, the sending and receiving of messages do not need to follow a single transmission mode, but can select a transmission mode different from the first message to transmit the message information based on the message type in the message information, so as to simultaneously meet the security and speed of a message sending and receiving process.

[0128] According to the embodiments of the present application, all devices in a large-scale intelligent park can be servers and configured using a master-slave architecture, such as a one-master-three-slave mode. When other devices register devices or services with the master server of the group management server, they can synchronize the registration information to multiple backup servers, thereby improving the reliability of the storage of registration information and avoiding the loss of device information or service unavailability due to a single point of failure. When the master server fails, the backup server can quickly take over and continue to provide group management services and device discovery functions, ensuring the continuous and stable operation of the network.

[0129] According to an embodiment of the present application, the first device includes a data production device, and the first message includes a backup notification message transmitted via a second transmission mode; in response to receiving the first message from the first device, message information matching the first message is determined, including: in response to receiving the backup notification message from the data production device, parsing the backup notification message to obtain the data volume and estimated transmission duration of the data to be backed up; determining that the message type matching the backup notification message is a data transmission type; determining the data transmission time information based on the data volume, the estimated transmission duration and the operating status of the current device; wherein the message information includes data transmission time information, the data transmission type and receiving device information indicating that the data production device is a receiving device, and the message information is transmitted via the first transmission mode, and the first transmission mode is determined based on the data transmission type.

[0130] For example, in a data backup scenario, the first device may be a data production device, such as a master server of a group management server, capable of generating a variety of data, and the current device may serve as a backup device of the data production device, such as a backup server.

[0131] For data production equipment, when critical business data is generated, such as financial transaction records and medical imaging data, this part of the data can be regarded as data to be backed up, and a backup notification message can be quickly sent to the current device via UDP. The backup notification message can include brief information such as the unique identifier of the data to be backed up, the data volume, and the estimated transmission time. The unique identifier can be a timestamp, business serial number, etc.

[0132] The current device receives and parses the backup notification message to obtain the data volume and estimated transmission duration. The operating state of the current device includes the load state. If the current device is in a high-load state, the data volume is higher than the first threshold value in the high-load state and / or the estimated transmission duration is higher than the second threshold value in the high-load state, then the data transmission time information is determined to be delayed for the first predetermined duration to transmit the data to be backed up; otherwise, the data transmission time information is determined to be delayed for the second predetermined duration to transmit the data to be backed up, and the first predetermined duration is greater than the second predetermined duration. If the current device is in a low-load state, the data volume is higher than the third threshold value in the low-load state and / or the estimated transmission duration is higher than the fourth threshold value in the low-load state, then the data transmission time information is determined to be delayed for the third predetermined duration to transmit the data to be backed up; otherwise, the data transmission time information is determined based on the current time and the estimated transmission duration, that is, the data to be backed up can be transmitted at this time. Therefore, the current device determines to use TCP based on the data transmission type and returns the data transmission time information to the data production device so that the data production device can transmit the data to be backed up at the time indicated by the data transmission time information. For example, the data production device can encapsulate the data to be backed up into a first message of the data transmission type and transmit it to the current device via TCP.

[0133] In the embodiment of the present application, since the data generated by the data production device is business-related data with a high security level, the security and reliability of the data cannot be guaranteed through UDP. However, the backup notification message for the data does not include the data itself, but only includes brief information about the data for negotiating the backup time. Therefore, the embodiment of the present application transmits the backup notification message through UDP, and the current device determines the data transmission time information based on the backup notification message and transmits it through TCP. This not only improves the security of the data transmission time information but also improves the efficiency of negotiating the transmission time. In addition, since the attacker cannot determine the specific transmission time of the backup data, the security of the transmission of the data to be backed up is further improved.

[0134] According to an embodiment of the present application, the first device includes a backup device, and the first message includes a backup data recovery message transmitted via a first transmission mode; in response to receiving the first message from the first device, message information matching the first message is determined, including: in response to receiving the backup data recovery message from the backup device, parsing the backup data recovery message to obtain backup data; determining that the message type matching the backup data recovery message is a backup verification type; using a hash algorithm, determining a first hash value of the backup data; wherein the message information includes the first hash value, the backup verification type, and receiving device information indicating that the backup device is a receiving device, and the message information is transmitted via a second transmission mode so that the backup device determines the integrity of the backup data based on the first hash value and the second hash value, and the second transmission mode is determined based on the backup verification type.

[0135] For example, in a backup and recovery scenario, the first device may be a backup device, such as a backup server of a group management server, and the current device may be a data production device, such as a primary server of a group management server.

[0136] When it is necessary to restore backup data from a backup device, the first device encapsulates the backup data into a data transmission type backup data recovery message and transmits the backup data recovery message via TCP. During the recovery process, the current device receives and parses the backup data recovery message to obtain the backup data. To ensure the integrity of the backup data, the current device also uses a hash algorithm to calculate the first hash value of the backup data in real time. After the backup data is restored, the current device sends a backup verification type message (such as a recovery data verification request) to the first device via UDP. The first device uses a hash algorithm to calculate the locally stored backup data, obtains a second hash value, and stores it on the first device. After receiving the first hash value transmitted by the current device, the first device determines whether the backup data is complete by comparing the first hash value with the second hash value. If complete, it can feedback the completeness of the backup data via UDP; otherwise, it can determine the missing backup data based on the first hash value and the second hash value, and transmit the missing backup data again via TCP.

[0137] In an embodiment of the present application, backup data is securely transmitted via TCP and a first hash value based on the backup data is quickly transmitted via UDP, thereby achieving integrity verification on both the first device and the current device, thereby balancing the security and speed of backup data in a data recovery scenario.

[0138] According to an embodiment of the present application, the first message includes a network status message transmitted via a second transmission mode; in response to receiving the first message from the first device, determining message information matching the first message includes: in response to receiving the network status message from the first device, parsing the network status message to obtain network status information, wherein the network status information includes at least one of the following: processor usage, memory occupancy status, network interface traffic, network delay duration, packet loss rate of the first device within a target time period, and bandwidth fluctuation amplitude; detecting the network status information to obtain a detection result; when it is determined that the detection result is an abnormality, determining that the message type matching the network status message is a network abnormality processing type; generating a first request information for obtaining the operating information of the first device; wherein the message information includes the first request information, the network abnormality processing type, and receiving device information indicating that the first device is a receiving device; the message information is transmitted via the first transmission mode, and the first transmission mode is determined based on the network abnormality processing type.

[0139] For example, in a failure or anomaly scenario, the first device may be a router, switch, or terminal device, and the current device may be a group management server, which is used to obtain network status information for each first device in the device group. The target period in the network status information may be a fixed interval from the current time. For example, the packet loss rate within the target period may be the packet loss rate 5 seconds before the current time.

[0140] The first device can periodically generate a network status message of the network status type and transmit it to the current device via UDP, for example, every 5 seconds. The group management server receives and parses the network status message, obtains network status information, and then tests the network status information to obtain a test result. If the test result is normal, no message is returned. If the test result is abnormal, the current device can leverage its management and analysis capabilities to obtain the first device's operating information and perform abnormality analysis and handling. After the current device determines that the network status message matches the network abnormality handling type, it can invoke a transmission interface and, based on the network abnormality handling type, transmit the message to the first device using TCP. The first device then responds with operational information based on the first request information in the message. For example, the first request information may be the storage address of the first device's operational information. The operational information may include load status, a list of network connections, and process status. Similarly, the first device can transmit the first device's operational information to the current device via TCP, so that the current device can analyze the cause of the network abnormality based on the operational information and handle it.

[0141] In an embodiment of the present application, since the anomaly in the network status information of the first device in the device group may be caused by a large number of requests constructed by an attacker, the first device may be at risk. Therefore, the embodiment of the present application utilizes the group management server to quickly obtain network status information from the first device via UDP, and securely transmits operating information via TCP when an anomaly is detected, thereby achieving rapid detection and security analysis of network anomalies, and further achieving safe operation and rapid recovery of the first device in the device group. In addition, since the operating information of the first device generally includes relatively detailed information, once leaked, the first device will be completely exposed to an unsafe environment, and the risk of attack will increase dramatically. Therefore, transmitting the operating information via TCP can further ensure the security of the first device.

[0142] According to an embodiment of the present application, network status information is detected to obtain a detection result, including at least one of the following: comparing the network status information with at least one network status threshold to obtain a detection result, wherein the network status threshold includes: a processor usage threshold, a memory occupancy status threshold, a network interface traffic threshold, a network delay time threshold, a packet loss rate threshold of the first device within a target time period, a bandwidth fluctuation threshold, and a comprehensive weighted threshold; inputting the network status information into a prediction model and outputting a prediction result; and determining a detection result based on the prediction result.

[0143] For example, the method for determining that the detection result is abnormal may include at least one of the following: if the processor usage is higher than a processor usage threshold, the memory occupancy is higher than a memory occupancy threshold, the network interface traffic is higher than a network interface traffic threshold, the network delay duration is higher than a network delay duration threshold, the packet loss rate of the first device during the target time period is higher than a packet loss rate threshold, and the bandwidth fluctuation range is higher than a bandwidth fluctuation threshold. Otherwise, the detection result is normal.

[0144] Alternatively, at least two of the selected parameters, including processor usage, memory usage, network interface traffic, network latency, packet loss rate of the first device during the target time period, and bandwidth fluctuation range, may be weighted and summed according to respective thresholds to produce a comprehensive result. If the comprehensive result exceeds the comprehensive weighted threshold, the detection result is abnormal; otherwise, the detection result is normal. For example, the comprehensive result may be a transmission quality index (TQI), which can be determined based on three dimensions: network latency (RTT), packet loss rate, and bandwidth fluctuation range, such as TQI = (latency weight × RTT) + (packet loss rate weight × packet loss rate) + (bandwidth fluctuation weight × fluctuation range). When TQI exceeds the comprehensive weighted threshold, such as 80 points, the network status is determined to be poor and the detection result is abnormal; otherwise, the detection result is normal.

[0145] Alternatively, the prediction model can be a machine learning model, such as a Long Short-Term Memory Network (LSTM), which predicts the network status trend for the next 10 seconds and generates a corresponding prediction result. If the network status trend indicates poor network status, the test result is a failure; otherwise, the test result is normal. The machine learning model can be trained based on historical network status information, such as using the historical information used to calculate the TQI above.

[0146] In the embodiment of the present application, by adopting multiple detection methods to detect network status information, it is possible to integrate multiple data and multiple dimensions to perform network status detection, so as to improve the accuracy of network status detection by the group management server.

[0147] According to an embodiment of the present application, the first message includes: a fault alarm message transmitted via a second transmission mode, and in response to receiving the first message from the first device, determining message information that matches the first message, including: in response to receiving the fault alarm message from the first device, parsing the fault alarm message to obtain the fault type and at least one second device associated with the first device; determining that the message type that matches the fault alarm message is a fault processing type; generating a second request information for obtaining operating information that matches the fault type; wherein the message information includes the second request information, the fault processing type, and receiving device information indicating that at least one second device and the first device are receiving devices; the message information is transmitted via the first transmission mode, and the first transmission mode is determined based on the fault processing type.

[0148] For example, in a failure or abnormality scenario, the first device may be a router, a switch, a terminal device, etc., and the current device may be a group management server.

[0149] During the daily operation of the first device, the network link or other communication between the first device and other devices may be suddenly interrupted. Therefore, when the network link or communication interruption is detected, the first device sends a fault alarm message via UDP. The message type of the fault alarm message is the fault alarm type. The fault alarm message may include at least one second device associated with the first device, the fault type, the time when the fault occurred, the affected service, etc. The at least one second device associated with the first device is also the device that will be affected when the first device fails. The current device receives and parses the fault alarm message, obtains the fault type and the second device, and generates a second request information through rule matching to obtain a log file of a specific range or time period. Afterwards, the message information is transmitted to the first device via TCP, so that the first device returns the log file of the specific range or time period via TCP, so as to use the above log file for fault analysis and fault handling.

[0150] In an embodiment of the present application, a group management server is used to quickly obtain a fault alarm message from the first device via UDP to achieve rapid detection of the fault. When a fault is detected, a second request message for obtaining operating information that matches the fault type is securely transmitted via TCP, thereby avoiding fault analysis security issues caused by the leakage of the second request message. This not only enables rapid fault detection but also enables secure fault analysis. In addition, since the operating information of the first device typically includes relatively detailed information, once leaked, the first device will be completely exposed to an unsafe environment, dramatically increasing the risk of attack. Therefore, transmitting the operating information that matches the fault type via TCP can further ensure the security of the first device.

[0151] Therefore, in a specific embodiment, the transmission mode for transmitting message information is determined according to the message type, including: when the message type is a service request, determining the target service of the request from the message information; and determining the transmission mode for transmitting the message information according to the security level of the target service, wherein a target service with a higher security level corresponds to a first transmission mode, and a target service with a lower security level corresponds to a second transmission mode.

[0152] For some messages, the corresponding transmission method can be directly determined based on the message type in the message information. However, for some message types related to the requested service, the security and speed requirements for message transmission are related to the specific service requested. For example, if the security level of the requested target service is higher, the message information can be returned using the higher security level TCP; conversely, if the security level is lower, the message information can be returned using the lower security level UDP.

[0153] For example, the security level of services related to permission modification is higher, the security level of services related to query is lower, and the security level of services related to device groups is higher.

[0154] Figure 7 The following diagram shows a scenario of a service request based on MDP according to an embodiment of the present application. Taking the first device as the device that interacts with the user, the current device as device A, and the receiving device as device B as an example, the user can interact with the first device to specify the target service to be requested. The first device encapsulates the specified target service into a first message of the service request type, and transmits the first message to device A via TCP or UDP according to the target service selection. In the case where the target service is provided by device B, device A determines that the target service is provided by device B based on the target service in the first message and the pre-stored service information of each device (pre-obtained from the device discovery process or obtained through the group management server). Thus, the determined message information includes the requested target service, service type, operating parameters, device information of device A, digital security information, message type indicating the service request, etc. At this time, the message information is also called the message information of the service request message (ServiceRequest), or simply the service request message (ServiceRequest).

[0155] like Figure 7As shown, device A invokes the transport interface and sends a service request message via TCP or UDP, depending on the security level of the target service. Upon receiving the service request, device B parses and validates it, including verifying the digital certificate and the requested operation parameters (e.g., whether they are in the same device group). If verification succeeds, device B invokes the corresponding service handler to perform the service operation and encapsulates the service result in a service response message (ServiceResponse), which is returned via the corresponding TCP or UDP. After receiving the service response message, device A processes and uses the received service result, completing the service interaction.

[0156] Furthermore, in the aforementioned service request process, the current device can also be device B, the first device and the receiving device can be device A, the ServiceRequest sent by device A can be the first message, and the message returned by device B can be the ServiceResponse message. Furthermore, if devices A and B do not belong to the same device group, the ServiceRequest will fail validation, the target service cannot be requested, and a service request failure message will be returned via TCP.

[0157] In the embodiments of this application, MDP selects a transmission method based on the security level of the target service, ensuring the confidentiality, integrity, authenticity, and speed of service request and response messages. Service requests implemented through device group management can further improve the security and isolation of service interactions at the device group level.

[0158] According to an embodiment of the present application, a transmission method for transmitting message information is determined according to the message type, including: when the message type is determined to be a custom type, determining the protocol version information from the message information; and determining the transmission method for transmitting the message information according to the protocol version information and the custom type.

[0159] As the network scale expands and the number of device types increases, the existing SSDP architecture is difficult to adapt to large-scale network environments. It cannot be flexibly expanded to support the access of more devices and service types, and the integration and expansion of new functions are also relatively difficult, which limits the further development and evolution of the network.

[0160] In the embodiments of this application, the MDP integrated into the transport interface not only defines basic message formats, fields, and message types, but also supports customization of message types and service information to meet the specific needs of different application scenarios. For example, dedicated service information and message types can be defined for specific industry devices, enabling customized extension of the protocol to meet diverse development needs. For example, medical devices can add a "Sensor Data Format" field, while industrial devices can expand the "Control Command Protocol" field, enabling the protocol to quickly adapt to emerging scenarios such as smart grids and the Internet of Vehicles.

[0161] Since message types correspond to TCP or UDP transmission methods, to ensure support for determining the corresponding transmission method for custom types, the message information can also include protocol version information, such as the protocol version number in the form of a field. The latest version of the MDP protocol is determined based on the protocol version information, and the transmission method corresponding to the custom type is determined based on the latest version of the MDP protocol. Similarly, for the receiving device, the receiving device can select the corresponding parsing and processing method based on the protocol version information to ensure the interactivity of the custom message type. Similarly, if the message information includes custom service information, the custom service information is determined based on the protocol version information and the corresponding operation is performed.

[0162] In an embodiment of the present application, the protocol version information indicated in the message information enables both the current device and the receiving device to implement custom type transmission mode selection and transmission, supports transmission mode selection in multiple scenarios, and improves scenario applicability.

[0163] Figure 8 The following diagram shows an extended message transmission scenario diagram based on MDP for customizing message types and service information according to an embodiment of the present application. Figure 8 As shown, based on user needs, message types and service information can be customized by upgrading the protocol version, thus extending the message format. Subsequently, any device carrying the upgraded protocol version can construct corresponding message information based on the protocol version information. For example, device E generates an extended message in an extended message format and sends the extended message carrying the protocol version information. Device F receives the extended message carrying the upgraded protocol version and processes the extended message based on the protocol version information, implementing customized service information and message type execution operations.

[0164] According to embodiments of the present application, MDP protocol version updates are compatible with information from previous versions. For example, subsequent MDP protocol versions can be extended and optimized while maintaining compatibility with previous versions. Consequently, during MDP version upgrades, multiple devices based on different MDP versions can coexist and communicate within the network, achieving smooth evolution and upgrades of the MDP protocol.

[0165] In addition to determining the transmission method based on the message type mentioned above, the transmission interface can also perform encryption and message transmission.

[0166] According to an embodiment of the present application, message information is transmitted to a receiving device that matches the receiving device information through a transmission method, including: when the transmission method is a first transmission method, encrypting the message information using at least one encryption algorithm to obtain an encrypted message; transmitting the encrypted message to the receiving device that matches the receiving device information through the first transmission method; when the transmission method is a second transmission method, transmitting the message information to a device that matches the receiving device information through the second transmission method.

[0167] For example, the encryption algorithms that can be used to encrypt message information include at least one of the following: the Advanced Encryption Standard (AES) symmetric encryption algorithm, the Rivest–Shamir–Adleman (RSA) asymmetric encryption algorithm, and the National Secret Algorithm (SM). AES, RSA, and SM can use a variety of specific algorithms, such as SM4.

[0168] In the embodiments of the present application, by further encrypting the message information and transmitting the encrypted message via the first transmission method with a higher security level, the security of message transmission using the first transmission method is further improved. If the second transmission method is used, the message information is directly transmitted without encryption to ensure the speed of message transmission.

[0169] In one embodiment, at least one encryption algorithm is used to encrypt message information to obtain an encrypted message, including: performing a hash calculation on the message information to obtain a first message digest; using a symmetric key of a symmetric encryption algorithm to encrypt the message information; wherein the encrypted message includes the encrypted message information and the first message digest, so that the receiving device uses the symmetric key to decrypt the encrypted message information, and the symmetric key is encrypted using the public key of the receiving device and then transmitted to the receiving device; the length of the symmetric key is determined according to the security level of the current device, and the length of the public key is determined according to the security level of the receiving device.

[0170] For example, a combination of AES and RSA can be used for encryption. During the device discovery process, the RSA public keys of the receiving device and the current device can be exchanged. The AES encryption key generated by the current device is then encrypted using the receiving device's RSA public key and transmitted to the receiving device. The receiving device then decrypts the key using its own RSA private key to obtain the AES encryption key. This key can then be used to decrypt the message during the message transmission phase.

[0171] During the message transmission phase, the current device encrypts the message using the AES encryption key to improve encryption efficiency. Furthermore, because the AES encryption key is encrypted using RSA before transmission, this phase ensures secure message transmission. The current device also hashes the message to generate a message digest, such as using a 256-bit Secure Hash Algorithm (SHA-256), to produce a first message digest. Since the first message digest is sent to the receiving device during message transmission, the receiving device can re-hash the message to produce a second message digest. If the first and second message digests match, the message has not been tampered with during transmission, ensuring message integrity. Otherwise, the message has been tampered with, and appropriate security measures can be taken.

[0172] According to an embodiment of the present application, when using RSA and AES in combination for encryption, due to the different security levels of different devices, their security requirements for message transmission are different. Therefore, for multiple devices, keys of different lengths can also be used for encryption. For example, according to the security level from high to low, the devices can include three security levels: core devices, ordinary devices, and temporary devices. For devices with different security levels, the length of the AES encryption key (128 bits / 256 bits) and the length of the RSA key (2048 bits / 4096 bits) are dynamically adjusted. It can be understood that since RSA uses a key pair consisting of a public key and a private key, the length of the public key and the private key are determined according to the security level of the device.

[0173] For example, the core equipment for industrial control uses 256-bit AES+4096-bit RSA, and the guest equipment and temporary equipment use 128-bit AES+2048-bit RSA to balance security and encryption resource consumption.

[0174] In an embodiment of the present application, encryption is performed by combining AES and RSA, and the length of the key is determined according to the security level of the device, so as to realize message transmission based on the security level and the composite encryption algorithm. On the basis of transmitting message information based on TCP, the security of message transmission is further improved.

[0175] Figure 9 The following diagram shows a scenario of encryption and decryption using a symmetric encryption algorithm and an asymmetric encryption algorithm according to an embodiment of the present application. Figure 9As shown, for a message transmitted using TCP, including a first message and message information of the corresponding message type, device A and device B serve as the sending and receiving devices, respectively. Device A can generate an encryption key using a symmetric encryption algorithm, encrypt the encryption key using an asymmetric encryption algorithm, and pre-transmit the encrypted encryption key to device B before message transmission. Device B decrypts the message using the private key of the asymmetric encryption algorithm to obtain the encryption key of the symmetric encryption algorithm. During the message transmission phase, device A encrypts the message information using the encryption key of the symmetric encryption algorithm to obtain the encrypted message information. It then processes the message information using a hash algorithm to generate a first message digest and transmits the encrypted message information and the first message digest via TCP. Device B decrypts the encrypted message information using the encryption key to obtain the decrypted message information and generates a second digest information using a hash algorithm. Furthermore, the message information transmitted via TCP includes digital certificate information, which is verified as described above. If verification passes, processing continues; otherwise, the message information is discarded.

[0176] According to an embodiment of the present application, the message transmission method also includes: when the symmetric key meets the expiration condition, generating a new symmetric key of a predetermined length according to the security level of the current device; wherein the expiration condition includes at least one of the following: the number of times the symmetric key is used reaches a number threshold, and the effective duration of the symmetric key reaches a duration threshold; using the public key of the receiving device to encrypt the new symmetric key, and transmitting the encrypted new symmetric key to the receiving device through the first transmission method, wherein the public key of the receiving device is updated periodically.

[0177] For example, each device's AES symmetric key automatically expires after encrypting 1,000 messages or after 24 hours. A new symmetric key can be regenerated for the current device. The predetermined length of the new symmetric key is determined by the device's security level, such as 128 or 256 bits. After the new encryption key is generated, it is renegotiated using RSA. For example, the new encryption key is encrypted using the receiving device's RSA public key and transmitted to the receiving device via TCP. The receiving device then decrypts it using its own RSA private key to obtain the new encryption key. RSA public key updates are controlled by the CA and are mandatory every six months. For example, when the receiving device or the current device requests a new certificate from the CA via TCP, the new RSA public key is automatically synchronized.

[0178] In the embodiments of the present application, the dynamic update of the AES symmetric key is achieved by judging whether the symmetric key meets the expiration condition, and the dynamic update of the key of the asymmetric encryption algorithm is achieved by regularly updating the RSA public key, thereby solving the security risks of the traditional AES / RSA "one key to the end" and avoiding the security risks caused by the long-term use of the same key, thereby improving the security of TCP message transmission.

[0179] According to an embodiment of the present application, the method also includes: in response to detecting that a key abnormality exists in the current device, generating a first message information based on the identification information of the abnormal key, the message type indicating the key abnormality, and the receiving device information indicating that at least one device in the second device group to which the current device belongs is a receiving device; transmitting the first message information to at least one device through a second transmission method; generating a second message information based on the identification information, the message type indicating the key negotiation, and the receiving device information indicating that the target management device is a receiving device; encrypting the second message information using the spare public key stored in the hardware security device to obtain a third message information; transmitting the third message information to the target management device through the first transmission method, so that the target management device generates a key for replacing the abnormal key.

[0180] For example, the current device can receive messages transmitted by other devices. If the number of exceptions in decryption using the AES symmetric key exceeds a threshold, the number of exceptions in decryption using the RSA private key exceeds a threshold, the number of exceptions in verifying the public key of the current device in the digital certificate information transmitted by other devices exceeds a threshold, such as 3 times, or message tampering is detected by comparing different message digests, it can be determined that the current device has a key abnormality.

[0181] When a key anomaly occurs on the current device, it transmits a first message to all devices in the second device group to which the current device belongs via UDP, and broadcasts the abnormal key and the message type of the key anomaly to all devices in the second device group to which the current device belongs, so that these devices can mark the abnormal key and the message type of the key anomaly. Upon receiving a message of this type, the current device sets the information carried in the message as untrusted information for subsequent processing (such as requiring the retransmission of such a message after renegotiation of the key). At the same time, in order to be able to negotiate with a target management device, such as a group management server or CA, to generate a new key to replace the abnormal key, after generating a second message of the key negotiation type, the current device not only encrypts the second message using a more secure backup public key to obtain a third message, but also transmits the third message to the target management device using the more secure TCP, so that the target management device can regenerate a key to replace the abnormal key. Similarly, the target management device returns the regenerated key to the current device via TCP.

[0182] The backup public key is stored offline in a hardware security device. The hardware security device can be a hardware security chip, which ensures the security of the internally stored backup public key through hardware-level protection, making it more secure than network-negotiated keys. The hardware security device can be integrated into the current device. When a key anomaly occurs, the second message can be transmitted to the hardware security device, which internally encrypts the second message and then transmits the third message via the TCP connection between the current device and the target management device.

[0183] In an embodiment of the present application, when there is an anomaly in the key, the anomaly of the current device can be quickly notified to the devices in the second device group through UDP, thereby achieving a rapid security alarm; at the same time, the current device uses a more secure backup public key and negotiates with the target management device through a more secure TCP to generate a new key, which can further ensure the security of the key.

[0184] According to an embodiment of the present application, the message transmission method includes: in response to detecting that the network delay duration of the current device meets the delay condition, replacing the symmetric encryption algorithm with a predetermined encryption algorithm to encrypt the message information using the predetermined encryption algorithm, wherein the resource consumption of the predetermined encryption algorithm is less than the resource consumption of the symmetric encryption algorithm; in response to detecting that the current device is in a risky environment, determining a symmetric key with an increased length, and encrypting the message information using the symmetric key with an increased length.

[0185] In addition to implementing the aforementioned encryption, decryption, and key anomaly detection functions, the MDP encapsulated by the transport interface also features a built-in encryption algorithm priority queue, such as AES > RSA > SM4. For example, the delay condition can be that the network delay exceeds a predetermined delay. For example, if the network delay exceeds 50ms, SM4 can be used instead of AES, automatically downgrading AES to a lightweight algorithm. In this embodiment, the predetermined encryption algorithm is SM4, and SM4 consumes less resources during encryption than AES.

[0186] In addition, the current device may be attacked and is in a risky environment. If the number of exceptions when the current device uses the AES symmetric key to decrypt, the number of exceptions when using the RSA private key to decrypt, and the number of exceptions when verifying the current device's public key in the digital certificate information transmitted by other devices exceeds the environmental risk threshold, such as 10 times, it is determined that the current device is in a risky environment and the security level of the current device may not be reliable, that is, the security risk is increased. In this case, the AES symmetric key used by the current device can be automatically upgraded to an AES key with a longer length, and combined with other RSA and hash algorithms used to generate message digests to form a higher security level algorithm combination, such as 256-bit AES + 4096-bit RSA + 512-bit SHA.

[0187] In the embodiments of this application, by detecting whether the current device is in a risky environment, the encryption algorithm can be automatically upgraded, further improving encryption security while ensuring secure message transmission via TCP. By detecting the network delay duration of the current device, the encryption algorithm can be downgraded, further improving encryption security and message transmission efficiency while ensuring secure message transmission via TCP.

[0188] In the above embodiment, the message information is encrypted before TCP transmission to transmit the encrypted message; after TCP transmission, it is also necessary to ensure that the receiving device receives and decrypts the encrypted message.

[0189] Therefore, according to an embodiment of the present application, the message transmission method also includes: in response to no response to the encrypted message being detected within a preset time length, when the number of transmissions of the encrypted message is less than the preset number of transmissions, the encrypted message is transmitted again to the receiving device that matches the receiving device information through the first transmission method, and the number of transmissions of the encrypted message is updated; when the number of transmissions of the encrypted message is greater than or equal to the preset number of transmissions, an error message is displayed to the user.

[0190] The preset duration can be, for example, a timer timeout duration, and the preset number of transmissions can be, for example, a maximum number of retransmissions.

[0191] Figure 10 FIG. 1 shows a retransmission scenario diagram of TCP transmission based on MDP according to an embodiment of the present application. Figure 10 As shown, as a sending device, the current device generates message information and determines the message type from the message information. Based on the message type, it is determined to use the first transmission method. After encrypting the message information, the encrypted message is sent via the first transmission method, and a retransmission timer is started. When no response (ACK) is received from the receiving device before the timer times out, it is determined whether the number of transmissions of the encrypted message is less than the preset number of transmissions. If the number of transmissions is less than the preset number of transmissions, the encrypted message is retransmitted, the retransmission timer is reset, and the number of transmissions of the encrypted message is increased until an ACK is received or the maximum number of retransmissions is reached. The ACK is fed back via TCP. If the number of transmissions is greater than or equal to the maximum number of retransmissions, the transmission is terminated and an error message is displayed to the user, such as "message transmission failed or verification failed."

[0192] The receiving device receives the encrypted message and verifies its integrity, for example, by determining whether the first message digest and the second message digest are identical. If they are, the device sends a reply to the sending device, confirming successful receipt and verification of the encrypted message. Otherwise, the message is discarded and no reply is returned.

[0193] In an embodiment of the present application, by timing the responses to encrypted messages and combining them with the maximum number of retransmissions, not only can the security and reliability of TCP transmission be ensured, but also accidental transmission failures due to network fluctuations or other factors can be avoided, thereby ensuring the secure transmission of messages.

[0194] According to an embodiment of the present application, message information is transmitted to a device that matches the receiving device information through a second transmission mode, including: determining the sliding window length for dividing sequence numbers based on the network status information of the current device; determining the sequence number list of the message information based on the sliding window length; transmitting the message information and the sequence number list to the receiving device that matches the receiving device information through the second transmission mode, so that the receiving device that matches the receiving device information responds to receiving the message information and the sequence number list, and determines the packet loss detection result for the message information based on the sequence number list.

[0195] UDP messages are subject to network fluctuations, bandwidth, and other factors, making them susceptible to message loss, duplication, or out-of-order transmission. Therefore, in addition to assigning sequence numbers to UDP messages based on the sliding window, the sliding window length is dynamically updated based on the device's current network status. For more information about network status, see the previous section and will not be repeated here.

[0196] For example, when the packet loss rate is less than 5%, the sliding window length is 10; when the packet loss rate is 10%-20%, the sliding window length is reduced to 5. The current device can divide the message information into consecutive sequence numbers based on the sliding window length, forming a sequence number list. Therefore, when the message information and the sequence number list are transmitted via UDP, the receiving device can determine whether there has been packet loss during the UDP transmission by checking the continuity of the sequence numbers in the sequence number list. For example, if the sequence number list could be

[01235] , by checking the sequence number continuity, it can be determined that the lost information is within the sliding window indicated by four sequence numbers. The receiving device can then request retransmission of the information within the sliding window indicated by four sequence numbers from the current device via UDP. Alternatively, if the receiving device determines that the stored information is lost, it does not immediately request retransmission. Instead, it waits for one full window transmission period, such as 50ms, to aggregate all lost sequence numbers and request a batch retransmission (BRQ) via UDP, thus reducing the number of retransmission interactions. For example, in a large smart campus, using this mechanism for UDP heartbeat messages (device keepalive messages) from thousands of devices can reduce retransmission traffic by 30%.

[0197] In an embodiment of the present application, when transmitting message information via UDP, the sliding window length is dynamically changed according to the network status, and a sliding window of varying length is used to generate a sequence number list to ensure the reliability of UDP transmission and facilitate retransmission of lost packet information.

[0198] Figure 11 FIG1 shows a scenario diagram of UDP transmission based on MDP according to an embodiment of the present application. Figure 11 As shown, the current device generates message information, determines the message type, and when determining to transmit through the second transmission mode, that is, UDP, assigns a sequence number list to the message information, and sends the message information and the sequence number list through the second transmission mode. The receiving device receives the message information and the sequence number list, and determines whether the sequence number list is continuous. In the case that the sequence number list is continuous, the operation corresponding to the message information is performed; conversely, in the case that it is discontinuous, retransmission is requested according to the sequence number list through UDP. After the current device receives the message for retransmission, the current device retransmits the information with the missing sequence number in the sequence number list. The receiving device receives the retransmission information in the retransmitted message, and merges the retransmission information with the previous information.

[0199] According to an embodiment of the present application, to further optimize the transmission performance of MDP, regardless of whether TCP or UDP is selected for message transmission, message compression and fragmented transmission are also supported for larger MDP messages. For example, a registration message may contain a large amount of service information and device information. To reduce transmission bandwidth occupancy and improve transmission efficiency, a message compression algorithm is used to compress the message information before transmission. At the same time, for messages that exceed the maximum transmission unit (MTU) of the transport layer, fragmentation can also be performed, splitting the message information into multiple smaller fragments for transmission. The fragments are then reassembled and restored at the receiving device to ensure the integrity and correct transmission of the message. This is particularly suitable for large-scale network environments and scenarios with high bandwidth requirements.

[0200] According to embodiments of the present application, MDP-based information transmission also incorporates a caching mechanism. For example, after a successful device discovery or service query, a device caches the query results (including device attribute information, service information, etc.) locally, setting a reasonable cache validity period. Subsequent identical or similar query requests within a certain period of time can retrieve results directly from the local cache, reducing the number of discovery requests sent over the network, reducing network traffic and device resource consumption, and improving discovery efficiency. Furthermore, the device regularly receives AliveNotification messages from other devices or device group change messages from the group management server. Based on these messages, it updates outdated information in the local cache to ensure the accuracy and validity of the cached content.

[0201] According to embodiments of the present application, MDP-based information transmission also incorporates multi-threaded processing and asynchronous operations. The MDP protocol stack employs a multi-threaded processing mechanism on both the device and server sides. Dedicated threads are used for message reception, parsing, processing, and sending. Threads communicate and share messages via thread-safe queues, improving protocol processing concurrency and responsiveness. For time-consuming operations (such as device registration and database access and network communication involved in group management), asynchronous operations are employed. Submissions return immediately, and subsequent processing of operation results is accomplished through callback functions or event notifications. This avoids thread blocking and improves overall system performance and resource utilization.

[0202] According to the embodiments of the present application, the MDP-based protocol adopts a modular plug-in design, encapsulating different functions into independent functional modules, such as security authentication, group management, and device discovery. These modules interact with each other through defined interfaces. This plug-in architecture allows for the convenient expansion of new functional modules or upgrade of existing functional modules, such as adding new security authentication algorithm plug-ins or integrating new device type identification plug-ins, without modifying the core architecture of the protocol, thus achieving flexible expansion and functional enhancement of the protocol.

[0203] According to an embodiment of the present application, in a network based on MDP for message transmission, a multipath transmission pool is established at the bottom layer for management devices such as group management servers. The same message is transmitted simultaneously over two or three physical links, such as the primary link, backup Wi-Fi, and 4G modules. The receiving device layer uses a first-come, first-served basis, deduplicating duplicate messages by sequence number. If transmission fails on a link in the multipath transmission pool, the system automatically switches to another link, sends a failure notification via UDP, and closes the transmission of information related to the failed link and the supplementary link.

[0204] In addition, to ensure the effectiveness and security of message transmission, the message type also includes multiple priorities, for example, P0-P4, with P0 being the highest. P0-level messages are forced to use TCP multipath transmission to seize the highest bandwidth. For example, P0-level messages can be the message type used for master-slave switching. P1-P2 level messages (such as the first type of messages mentioned above): In addition to using TCP transmission by default, if the TCP connection queue is full and / or the waiting time has timed out, TCP is temporarily backed up by the retransmission mechanism of UDP+sequence number list. However, this part of the transmission requires confirmation from the administrator before it can be backed up. P3-P4 level messages (such as the second type of messages mentioned above): UDP transmission is used by default. If the network delay is long, it will automatically downgrade to "delayed send" mode to extend the interval of UDP transmission.

[0205] Figure 12 FIG. 1 shows a structural block diagram of a message transmission device according to an embodiment of the present application. Figure 12 As shown, the message transmission device 1200 includes a determination module 1210, which is used to determine message information matching the first message in response to receiving a first message from a first device, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group consisting of multiple devices; a calling module 1220, which is used to call a transmission interface, determine a transmission method for transmitting the message information according to the message type, and transmit the message information to a receiving device matching the receiving device information through the transmission method; wherein the transmission method includes a first transmission method and a second transmission method using different transmission protocols, and the security level of the transmission protocol used by the first transmission method is higher than the security level of the transmission protocol used by the second transmission method; the transmission interface is also used to encrypt the message information.

[0206] According to an embodiment of the present application, the first message includes a device group creation message, and the determination module 1210 includes: a first parsing sub-module, for parsing the device group creation message in response to receiving the device group creation message from the first device, and obtaining group information of the first device group to be created, wherein the group information includes at least one of the following: identification information, description information, device range, access rights, and group management policy; a first generating sub-module, for generating a group record of the first device group based on the group information of the first device group; a first determining sub-module, for determining that the message type matching the device group creation information is a new group broadcast type; a second determining sub-module, for determining at least one device other than the current device in the second device group based on the second device group to which the current device belongs; wherein the message information includes: group record, new group broadcast message, and receiving device information indicating that at least one device is a receiving device.

[0207] According to an embodiment of the present application, the first message includes at least one of the following: a device group join message and a device group exit message; the determination module 1210 includes: a second parsing submodule, which is used to parse the first message in response to receiving the first message from the first device, and obtain the digital certificate information of the first device and the third device group; a first verification submodule, which is used to verify the digital certificate information of the first device and the device joining conditions of the third device group for the device group join message, and obtain group change information for the third device group; the second verification submodule is used to verify the digital certificate information of the first device for the device group exit message, and obtain group change information for the third device group; the third determination submodule is used to determine that the message type matching the first message is the device group change type; wherein the message information includes: group change information, device group change type, and receiving device information indicating that at least one device in the third device group is a receiving device.

[0208] According to an embodiment of the present application, the first message includes a registration message; the determination module 1210 includes: a third parsing sub-module, which is used to parse the registration message in response to receiving the registration message from the first device; a third verification sub-module, which is used to verify the digital certificate information of the first device and the device joining conditions of the fourth device group respectively when the parsed registration message includes the registration information of the first device, the group information of the fourth device group and the digital certificate information of the first device, so as to obtain the registration result of the first device, wherein the fourth device group is the device group that the first device requests to join when registering; a fourth determination sub-module, which is used to determine that the message type matching the registration message is the registration result notification type; a second generation sub-module, which is used to generate message information according to the registration result, wherein the message information includes the registration result, the registration result notification type, and receiving device information indicating that at least one device in the fourth device group and the first device are receiving devices.

[0209] According to an embodiment of the present application, the calling module 1220 includes a mode determination submodule for determining a transmission mode for transmitting message information based on a message type. The mode determination submodule includes: a first determination unit for determining a first transmission mode as the transmission mode for transmitting the message information when the message type is determined to be a first type; and a second determination unit for determining a second transmission mode as the transmission mode for transmitting the message information when the message type is determined to be a second type, wherein the security level of the first type is higher than the security level of the second type.

[0210] According to an embodiment of the present application, the first type includes at least one of the following: device registration type, registration result notification type, device deregistration type, deregistration result notification type, data transmission type, backup data recovery type, network exception handling type, fault handling type, and a type for managing a device group composed of multiple devices; the type for managing a device group composed of multiple devices includes one of the following: device group creation type, new group broadcast type, device group change type, device group join type, and device group exit type; the second type includes at least one of the following: device discovery type, device survival type, backup notification type, backup verification type, network status type, and fault alarm type.

[0211] According to an embodiment of the present application, the first message and the message information are transmitted through different transmission modes.

[0212] According to an embodiment of the present application, the first device includes a data production device, and the first message includes a backup notification message transmitted via a second transmission mode; the determination module 1210 includes: a fourth parsing submodule, for parsing the backup notification message in response to receiving a backup notification message from the data production device, and obtaining the data volume and estimated transmission duration of the data to be backed up; a fifth determination submodule, for determining that the message type matching the backup notification message is a data transmission type; a sixth determination submodule, for determining the data transmission time information based on the data volume, the estimated transmission duration and the operating status of the current device; wherein the message information includes data transmission time information, the data transmission type and the receiving device information indicating that the data production device is a receiving device, and the message information is transmitted via the first transmission mode, and the first transmission mode is determined based on the data transmission type.

[0213] According to an embodiment of the present application, the first device includes a backup device, and the first message includes a backup data recovery message transmitted via a first transmission mode; in response to receiving the first message from the first device, message information matching the first message is determined, including: a fifth parsing submodule, for parsing the backup data recovery message to obtain backup data in response to receiving the backup data recovery message from the backup device; a seventh determination submodule, for determining that the message type matching the backup data recovery message is a backup verification type; an eighth determination submodule, for determining a first hash value of the backup data using a hash algorithm; wherein the message information includes a first hash value, a backup verification type, and receiving device information indicating that the backup device is a receiving device, and the message information is transmitted via a second transmission mode so that the backup device determines the integrity of the backup data based on the first hash value and the second hash value, and the second transmission mode is determined based on the backup verification type.

[0214] According to an embodiment of the present application, the first message includes a network status message transmitted via a second transmission mode; the determination module 1210 includes: a sixth parsing sub-module, for parsing the network status message in response to receiving a network status message from the first device to obtain network status information, wherein the network status information includes at least one of the following: processor usage, memory occupancy status, network interface traffic, network delay duration, packet loss rate of the first device within a target time period, and bandwidth fluctuation amplitude; a detection sub-module, for detecting the network status information to obtain a detection result; a ninth determination sub-module, for determining that the message type matching the network status message is a network exception handling type when it is determined that the detection result is an abnormality; a third generation sub-module, for generating a first request information for obtaining the operating information of the first device; wherein the message information includes the first request information, the network exception handling type, and the receiving device information indicating that the first device is a receiving device; the message information is transmitted via the first transmission mode, and the first transmission mode is determined according to the network exception handling type.

[0215] According to an embodiment of the present application, the detection submodule includes at least one of the following: a first detection unit, used to compare the network status information with at least one network status threshold to obtain a detection result, wherein the network status threshold includes: a processor usage threshold, a memory occupancy status threshold, a network interface traffic threshold, a network delay time threshold, a packet loss rate threshold of the first device within a target time period, a bandwidth fluctuation threshold, and a comprehensive weighted threshold; a second detection unit, used to input the network status information into a prediction model and output a prediction result; and determine the detection result based on the prediction result.

[0216] According to an embodiment of the present application, the first message includes: a fault alarm message transmitted via a second transmission mode, and the determination module 1210 includes: a seventh parsing submodule, for parsing the fault alarm message in response to receiving a fault alarm message from the first device, and obtaining the fault type and at least one second device associated with the first device; a tenth determination submodule, for determining that the message type matching the fault alarm message is a fault handling type; a fourth generation submodule, for generating a second request information for obtaining operating information matching the fault type; wherein the message information includes the second request information, the fault handling type, and receiving device information indicating that at least one second device and the first device are receiving devices; the message information is transmitted via the first transmission mode, and the first transmission mode is determined according to the fault handling type.

[0217] According to an embodiment of the present application, the calling module 1220 includes a mode determination submodule for determining a transmission mode for transmitting message information based on the message type. The mode determination submodule includes: a third determination unit for determining a target service of the request from the message information when the message type is a service request; and a fourth determination unit for determining a transmission mode for transmitting the message information based on the security level of the target service, wherein a target service with a higher security level corresponds to a first transmission mode, and a target service with a lower security level corresponds to a second transmission mode.

[0218] According to an embodiment of the present application, the method determination submodule includes: a fifth determination unit, which is used to determine the protocol version information from the message information when the message type is determined to be a custom type; and a sixth determination unit, which is used to determine the transmission method for transmitting the message information based on the protocol version information and the custom type.

[0219] According to an embodiment of the present application, the calling module 1220 includes a transmission submodule for transmitting the message information to a receiving device that matches the receiving device information via a transmission mode. The transmission submodule includes: a first transmission unit for encrypting the message information using at least one encryption algorithm to obtain an encrypted message when the transmission mode is a first transmission mode; transmitting the encrypted message to the receiving device that matches the receiving device information via the first transmission mode; and a second transmission unit for transmitting the message information to the device that matches the receiving device information via the second transmission mode when the transmission mode is a second transmission mode.

[0220] According to an embodiment of the present application, the first transmission unit includes: a calculation subunit, used to perform hash calculation on the message information to obtain a first message digest; an encryption subunit, used to encrypt the message information using a symmetric key of a symmetric encryption algorithm; wherein, the encrypted message includes the encrypted message information and the first message digest, so that the receiving device uses the symmetric key to decrypt the encrypted message information, and the symmetric key is encrypted using the public key of the receiving device and then transmitted to the receiving device; the length of the symmetric key is determined according to the security level of the current device, and the length of the public key is determined according to the security level of the receiving device.

[0221] According to an embodiment of the present application, the calling module 1220 also includes: a first update sub-module, which is used to generate a new symmetric key of a predetermined length according to the security level of the current device when the symmetric key meets the expiration condition; wherein the expiration condition includes at least one of the following: the number of times the symmetric key is used reaches a number threshold, and the valid duration of the symmetric key reaches a duration threshold; a second update sub-module, which is used to encrypt the new symmetric key using the public key of the receiving device, and transmit the encrypted new symmetric key to the receiving device through a first transmission method, wherein the public key of the receiving device is updated periodically.

[0222] According to an embodiment of the present application, the calling module 1220 also includes: a first exception handling sub-module, which is used to generate a first message information in response to detecting that a key abnormality exists in the current device, based on the identification information of the abnormal key, the message type indicating the key abnormality, and the receiving device information indicating that at least one device in the second device group to which the current device belongs is a receiving device; a second exception handling sub-module, which is used to transmit the first message information to at least one device through a second transmission method; a third exception handling sub-module, which is used to generate a second message information based on the identification information, the message type indicating the key negotiation, and the receiving device information indicating that the target management device is a receiving device; a fourth exception handling sub-module, which is used to encrypt the second message information using the backup public key stored in the hardware security device to obtain the third message information; and a fifth exception handling sub-module, which is used to transmit the third message information to the target management device through the first transmission method, so that the target management device generates a key for replacing the abnormal key.

[0223] According to an embodiment of the present application, the calling module 1220 includes: a sixth exception handling sub-module, for, in response to detecting that the network delay duration of the current device meets the delay condition, replacing the symmetric encryption algorithm with a predetermined encryption algorithm to encrypt the message information using the predetermined encryption algorithm, wherein the resource consumption of the predetermined encryption algorithm is less than the resource consumption of the symmetric encryption algorithm; a seventh exception handling sub-module, for, in response to detecting that the current device is in a risky environment, determining the symmetric key with an increased length, and encrypting the message information using the symmetric key with an increased length.

[0224] According to an embodiment of the present application, the calling module 1220 also includes: a first retransmission submodule, which is used to, in response to not detecting a response to the encrypted message within a preset time length, transmit the encrypted message again to the receiving device that matches the receiving device information through a first transmission method when the number of transmissions of the encrypted message is less than the preset number of transmissions, and update the number of transmissions of the encrypted message; a second retransmission submodule, which is used to display an error message to the user when the number of transmissions of the encrypted message is greater than or equal to the preset number of transmissions.

[0225] According to an embodiment of the present application, the second transmission unit includes: a first determination subunit, used to determine the sliding window length for dividing the sequence numbers based on the network status information of the current device; a second determination subunit, used to determine the sequence number list of the message information based on the sliding window length; a transmission subunit, used to transmit the message information and the sequence number list to a receiving device that matches the receiving device information through a second transmission mode, so that the receiving device that matches the receiving device information responds to the received message information and the sequence number list, and determines the packet loss detection result for the message information based on the sequence number list.

[0226] According to embodiments of the present application, any multiple modules in the determination module 1210 and the invocation module 1220 can be combined into a single module, or any one of them can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in a single module. According to embodiments of the present application, at least one of the determination module 1210 and the invocation module 1220 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application-specific integrated circuit (ASIC), or can be implemented in hardware or firmware through any other reasonable means of circuit integration or packaging, or can be implemented in any one of the three implementation methods of software, hardware, and firmware, or any appropriate combination of any of these. Alternatively, at least one of the determination module 1210 and the invocation module 1220 can be at least partially implemented as a computer program module that, when executed, can perform the corresponding functionality.

[0227] Figure 13 A block diagram of an electronic device suitable for implementing a message transmission method according to an embodiment of the present application is shown.

[0228] like Figure 13 As shown, the electronic device 1300 according to an embodiment of the present application includes a processor 1301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1302 or a program loaded from a storage unit 1308 into a random access memory (RAM) 1303. The processor 1301 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 1301 may also include onboard memory for caching purposes. The processor 1301 may include a single processing unit or multiple processing units for performing different actions of the method flow according to the embodiment of the present application.

[0229] Various programs and data required for the operation of the electronic device 1300 are stored in the RAM 1303. The processor 1301, the ROM 1302, and the RAM 1303 are connected to each other via a bus 1304. The processor 1301 performs various operations of the method flow according to the embodiment of the present application by executing the programs in the ROM 1302 and / or the RAM 1303. It should be noted that the programs may also be stored in one or more memories other than the ROM 1302 and the RAM 1303. The processor 1301 may also perform various operations of the method flow according to the embodiment of the present application by executing the programs stored in the one or more memories.

[0230] According to an embodiment of the present application, electronic device 1300 may further include an input / output (I / O) interface 1305, which is also connected to bus 1304. Electronic device 1300 may also include one or more of the following components connected to I / O interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including devices such as a cathode ray tube (CRT), liquid crystal display (LCD), and speakers; a storage section 1308 including a hard disk; and a communication section 1309 including a network interface card such as a LAN card or modem. Communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to I / O interface 1305 as needed. Removable media 1311, such as a magnetic disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed in drive 1310 as needed, so that computer programs read from the removable media can be installed into storage section 1308 as needed.

[0231] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments, or may exist independently and not be incorporated into the device / apparatus / system. The computer-readable storage medium carries one or more programs, and when the one or more programs are executed, the method according to the embodiments of this application is implemented.

[0232] According to an embodiment of the present application, a computer-readable storage medium may be a non-volatile computer-readable storage medium, and may include, for example, but not limited to: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to an embodiment of the present application, a computer-readable storage medium may include the ROM 1302 and / or RAM 1303 described above, and / or one or more memories other than ROM 1302 and RAM 1303.

[0233] The embodiments of the present application also include a computer program product, which includes a computer program containing program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the method provided in the embodiments of the present application.

[0234] The computer program executes the above functions defined in the system / device of the embodiment of the present application when the processor 1301 executes the computer program. According to the embodiment of the present application, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0235] In one embodiment, the computer program may be stored on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may be transmitted and distributed in the form of a signal over a network medium, downloaded and installed via the communication portion 1309, and / or installed from removable media 1311. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to wireless, wired, or any suitable combination thereof.

[0236] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 1309, and / or installed from a removable medium 1311. When the computer program is executed by the processor 1301, the above-described functions defined in the system of the embodiment of the present application are performed. According to the embodiment of the present application, the systems, devices, means, modules, units, etc. described above can be implemented by computer program modules.

[0237] According to an embodiment of the present application, the program code for executing the computer program provided by the embodiment of the present application can be written in any combination of one or more programming languages. Specifically, these computer programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (for example, using an Internet service provider to connect via the Internet).

[0238] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0239] Those skilled in the art will appreciate that the features described in the various embodiments of this application may be combined and / or coupled in various ways, even if such combinations or couplings are not explicitly described in this application. In particular, the features described in the various embodiments of this application may be combined and / or coupled in various ways without departing from the spirit and teachings of this application. All such combinations and / or couplings fall within the scope of this application.

[0240] The embodiments of the present application have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of the present application. Although each embodiment has been described separately above, this does not mean that the measures in each embodiment cannot be advantageously used in combination. Without departing from the scope of the present application, those skilled in the art may make various substitutions and modifications, and these substitutions and modifications should all fall within the scope of the present application.

Claims

1. A message transmission method, characterized in that: The message transmission method includes: In response to receiving a first message from a first device, determining message information matching the first message, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group consisting of multiple devices; Calling a transmission interface, determining a transmission method for transmitting the message information according to the message type, and transmitting the message information to a receiving device that matches the receiving device information through the transmission method; Among them, the transmission mode includes a first transmission mode and a second transmission mode using different transmission protocols, and the security level of the transmission protocol used by the first transmission mode is higher than the security level of the transmission protocol used by the second transmission mode; the transmission interface is also used to encrypt the message information.

2. The message transmission method according to claim 1, wherein: The first message includes a device group creation message, and in response to receiving the first message from the first device, determining message information matching the first message includes: In response to receiving the device group creation message from the first device, parsing the device group creation message to obtain group information of the first device group to be created, wherein the group information includes at least one of the following: identification information, description information, device range, access rights, and group management policy; generating a group record of the first device group according to the group information of the first device group; Determining that a message type matching the device group creation information is a new group broadcast type; Determining, based on the second device group to which the current device belongs, at least one device in the second device group other than the current device; The message information includes: the group record, the new group broadcast type, and the receiving device information indicating that the at least one device is a receiving device.

3. The message transmission method according to claim 1, wherein: The first message includes at least one of the following: a device group join message and a device group exit message; In response to receiving a first message from a first device, determining message information matching the first message includes: In response to receiving a first message from the first device, parsing the first message to obtain digital certificate information of the first device and a third device group; Verifying the digital certificate information of the first device and the device joining condition of the third device group respectively for the device group joining message to obtain group change information for the third device group; Verify the digital certificate information of the first device in response to the device group exit message to obtain group change information for the third device group; Determining that a message type matching the first message is a device group change type; The message information includes: the group change information, the device group change type, and receiving device information indicating that at least one device in the third device group is a receiving device.

4. The message transmission method according to claim 1, wherein: The first message includes a registration message; and in response to receiving the first message from the first device, determining message information matching the first message includes: In response to receiving a registration message from the first device, parsing the registration message; If the parsed registration message includes the registration information of the first device, the group information of the fourth device group, and the digital certificate information of the first device, verifying the digital certificate information of the first device and the device joining condition of the fourth device group, respectively, to obtain a registration result of the first device, wherein the fourth device group is the device group that the first device requested to join during registration; Determining that a message type matching the registration message is a registration result notification type; The message information is generated according to the registration result, wherein the message information includes the registration result, the registration result notification type, and receiving device information indicating that at least one device in the fourth device group and the first device are receiving devices.

5. The message transmission method according to any one of claims 1 to 4, characterized in that: The determining, according to the message type, a transmission mode for transmitting the message information includes: In a case where it is determined that the message type is the first type, determining the first transmission mode as the transmission mode for transmitting the message information; When it is determined that the message type is the second type, the second transmission mode is determined as the transmission mode for transmitting the message information, and the security level of the first type is higher than the security level of the second type.

6. The message transmission method according to claim 5, characterized in that: The first type includes at least one of the following: a device registration type, a registration result notification type, a device deregistration type, a deregistration result notification type, a data transmission type, a backup data recovery type, a network exception handling type, a fault handling type, and a type for managing a device group consisting of multiple devices; The type for managing a device group composed of multiple devices includes one of the following: a device group creation type, a new group broadcast type, a device group change type, a device group join type, and a device group exit type; The second type includes at least one of the following: a device discovery type, a device survival type, a backup notification type, a backup verification type, a network status type, and a fault alarm type.

7. The message transmission method according to claim 1, wherein: The message transmission method also includes: the first message and the message information are transmitted through different transmission modes.

8. The message transmission method according to claim 7, wherein: The first device includes a data production device, and the first message includes a backup notification message transmitted via the second transmission mode; The step of determining, in response to receiving a first message from a first device, message information matching the first message includes: In response to receiving the backup notification message from the data production device, parsing the backup notification message to obtain the data volume and estimated transmission time of the data to be backed up; Determining that a message type matching the backup notification message is a data transmission type; Determining data transmission time information based on the data volume, the estimated transmission duration, and the current operating state of the device; Among them, the message information includes the data transmission time information, the data transmission type and the receiving device information indicating that the data production device is the receiving device. The message information is transmitted through the first transmission mode, and the first transmission mode is determined according to the data transmission type.

9. The message transmission method according to claim 7, wherein: The first device includes a backup device, and the first message includes a backup data recovery message transmitted via the first transmission mode; The step of determining, in response to receiving a first message from a first device, message information matching the first message includes: In response to receiving the backup data restoration message from the backup device, parsing the backup data restoration message to obtain backup data; Determining that a message type matching the backup data restoration message is a backup verification type; Determine a first hash value of the backup data using a hash algorithm; In which, the message information includes the first hash value, the backup verification type and the receiving device information indicating that the backup device is the receiving device, and the message information is transmitted through the second transmission mode so that the backup device determines the integrity of the backup data based on the first hash value and the second hash value, and the second transmission mode is determined according to the backup verification type.

10. The message transmission method according to claim 7, wherein: The first message includes a network status message transmitted via a second transmission mode; The step of determining, in response to receiving a first message from a first device, message information matching the first message includes: In response to receiving the network status message from the first device, parsing the network status message to obtain network status information, wherein the network status information includes at least one of the following: processor usage, memory occupancy, network interface traffic, network delay duration, packet loss rate of the first device within a target time period, and bandwidth fluctuation range; Detecting the network status information to obtain a detection result; In the case where it is determined that the detection result is an abnormality, determining that the message type matching the network status message is a network abnormality processing type; generating first request information for obtaining operation information of the first device; Among them, the message information includes the first request information, the network exception processing type, and receiving device information indicating that the first device is the receiving device; the message information is transmitted through the first transmission method, and the first transmission method is determined according to the network exception processing type.

11. The message transmission method according to claim 10, characterized in that: The detecting of the network status information to obtain a detection result includes at least one of the following: Comparing the network status information with at least one network status threshold to obtain the detection result, wherein the network status threshold includes: a processor usage threshold, a memory occupancy threshold, a network interface traffic threshold, a network delay threshold, a packet loss rate threshold of the first device within a target time period, a bandwidth fluctuation threshold, and a comprehensive weighted threshold; The network status information is input into a prediction model, and a prediction result is output; and the detection result is determined based on the prediction result.

12. The message transmission method according to claim 7, wherein: The first message includes: a fault warning message transmitted through the second transmission mode, and the determining, in response to receiving the first message from the first device, message information matching the first message includes: In response to receiving the fault warning message from the first device, parsing the fault warning message to obtain a fault type and at least one second device associated with the first device; Determining that a message type matching the fault warning message is a fault handling type; generating second request information for obtaining operation information matching the fault type; Among them, the message information includes the second request information, the fault handling type, and receiving device information indicating that at least one of the second device and the first device is a receiving device; the message information is transmitted through the first transmission mode, and the first transmission mode is determined according to the fault handling type.

13. The message transmission method according to claim 1, wherein: The determining, according to the message type, a transmission mode for transmitting the message information includes: In the case where the message type is a service request, determining the requested target service from the message information; A transmission mode for transmitting the message information is determined according to the security level of the target service, wherein a target service with a higher security level corresponds to the first transmission mode, and a target service with a lower security level corresponds to the second transmission mode.

14. The message transmission method according to claim 1, wherein: The determining, according to the message type, a transmission mode for transmitting the message information includes: In a case where it is determined that the message type is a user-defined type, determining protocol version information from the message information; A transmission mode for transmitting the message information is determined according to the protocol version information and the custom type.

15. The message transmission method according to claim 1, wherein: The transmitting the message information to a receiving device matching the receiving device information by the transmission mode includes: When the transmission mode is the first transmission mode, encrypt the message information using at least one encryption algorithm to obtain an encrypted message; and transmit the encrypted message to a receiving device that matches the receiving device information through the first transmission mode; In a case where the transmission mode is the second transmission mode, the message information is transmitted to a device matching the receiving device information via the second transmission mode.

16. The message transmission method according to claim 15, characterized in that: The step of encrypting the message information by using at least one encryption algorithm to obtain an encrypted message includes: Performing a hash calculation on the message information to obtain a first message digest; Encrypting the message information using a symmetric key of a symmetric encryption algorithm; The encrypted message includes the encrypted message information and the first message digest, so that the receiving device uses the symmetric key to decrypt the encrypted message information. The symmetric key is encrypted using the public key of the receiving device and then transmitted to the receiving device; the length of the symmetric key is determined according to the security level of the current device, and the length of the public key is determined according to the security level of the receiving device.

17. The message transmission method according to claim 16, characterized in that: The message transmission method further includes: If the symmetric key meets the expiration condition, a new symmetric key of a predetermined length is generated according to the security level of the current device; wherein the expiration condition includes at least one of the following: the number of times the symmetric key is used reaches a number threshold, and the validity period of the symmetric key reaches a duration threshold; The new symmetric key is encrypted using the public key of the receiving device, and the encrypted new symmetric key is transmitted to the receiving device through the first transmission mode, wherein the public key of the receiving device is updated regularly.

18. The message transmission method according to any one of claims 15 to 17, characterized in that: The message transmission method further includes: In response to detecting that a key anomaly exists in the current device, generating first message information according to identification information of the abnormal key, a message type indicating the key anomaly, and receiving device information indicating that at least one device in a second device group to which the current device belongs is a receiving device; transmitting the first message information to the at least one device through the second transmission mode; generating second message information according to the identification information, the message type indicating the key negotiation, and the receiving device information indicating that the target management device is the receiving device; encrypting the second message information using the backup public key stored in the hardware security device to obtain third message information; The third message information is transmitted to the target management device through the first transmission mode, so that the target management device generates a key for replacing the abnormal key.

19. The message transmission method according to claim 16, wherein: The message transmission method includes: In response to detecting that the network delay duration of the current device satisfies the delay condition, replacing the symmetric encryption algorithm with a predetermined encryption algorithm to encrypt the message information with the predetermined encryption algorithm, wherein resource consumption of the predetermined encryption algorithm is less than resource consumption of the symmetric encryption algorithm; In response to detecting that the current device is in a risky environment, a symmetric key with an increased length is determined, and the message information is encrypted using the symmetric key with the increased length.

20. The message transmission method according to claim 15, wherein: The message transmission method further includes: In response to not detecting a reply to the encrypted message within a preset time period, and if the number of transmissions of the encrypted message is less than a preset number of transmissions, retransmitting the encrypted message to a receiving device matching the receiving device information by using the first transmission mode, and updating the number of transmissions of the encrypted message; When the number of transmissions of the encrypted message is greater than or equal to the preset number of transmissions, an error message is displayed to the user.

21. The message transmission method according to claim 15, wherein: The transmitting the message information to a device matching the receiving device information by using the second transmission mode includes: Determine the length of the sliding window used to divide the sequence numbers based on the network status information of the current device; Determining a sequence number list of the message information according to the sliding window length; The message information and the sequence number list are transmitted to a receiving device that matches the receiving device information through the second transmission mode, so that the receiving device that matches the receiving device information responds to receiving the message information and the sequence number list, and determines the packet loss detection result for the message information based on the sequence number list.

22. A message transmission device, characterized in that: The message transmission device includes: a determining module configured to, in response to receiving a first message from a first device, determine message information matching the first message, wherein the message information includes receiving device information and a message type, and the message type includes a type for managing a device group consisting of multiple devices; a calling module, configured to call a transmission interface, determine a transmission mode for transmitting the message information according to the message type, and transmit the message information to a receiving device matching the receiving device information through the transmission mode; Among them, the transmission mode includes a first transmission mode and a second transmission mode using different transmission protocols, and the security level of the transmission protocol used by the first transmission mode is higher than the security level of the transmission protocol used by the second transmission mode; the transmission interface is also used to encrypt the message information.

23. An electronic device comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the message transmission method according to any one of claims 1 to 21.

24. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the message transmission method according to any one of claims 1 to 21 are implemented.

25. A computer program product comprising a computer program or instructions, characterized in that When the computer program or the instructions are executed by a processor, the steps of the message transmission method according to any one of claims 1 to 21 are implemented.

Images