Kitchen equipment cloud security collaborative transmission method and system based on national secret algorithm

Abstract

The application provides a kitchen equipment cloud security collaborative transmission method and system based on a national secret algorithm. When a control instruction is transmitted by a kitchen equipment end engine, the load of the control instruction is fragmented according to a maximum transmission unit, and each link is allocated a fragment carried by each link according to a comprehensive score ratio of each link. After each fragment is attached to an encrypted check header containing a fragment serial number and a check code, the fragments are sent in parallel to the cloud through the corresponding link. The fragments of each link are cached by a cloud receiving end. When a same fragment serial number arrives on any link for the first time, it is retained, and subsequent repeated fragments are discarded. After all fragment serial numbers are complete and the check codes all pass, the load is spliced and restored according to the fragment serial numbers, and an acknowledgement message is returned to the equipment end. If the equipment end engine does not receive the acknowledgement message within a preset time, a first backup link is promoted to a new main link, and a link switching event is triggered and pushed to the cloud receiving end. Based on the above scheme, multi-link parallel transmission and dynamic fault transfer can be realized.

Description

Technical Field

[0001] This application relates to the field of national cryptographic algorithm technology, and more specifically, to a cloud-based secure collaborative transmission method and system for kitchen equipment based on national cryptographic algorithms. Background Technology

[0002] Kitchen equipment includes household and commercial smart kitchen appliances such as food processors, dough mixers, and steam ovens, which upload data such as operating parameters, user recipes, and sensor readings to the cloud for remote monitoring and collaborative control.

[0003] Current kitchen IoT systems use a single-link transmission control protocol with a long connection to handle all data interaction between devices and the cloud. This mechanism has structural flaws in the complex electromagnetic environment of a kitchen. Kitchens are equipped with high-power appliances such as microwave ovens, induction cookers, and inverter compressors. The harmonic interference and frequency band occupation caused by their switching actions lead to drastic fluctuations in the wireless signal-to-noise ratio. Under such dynamic interference, the single-link transmission control protocol relies on a retransmission timeout mechanism to recover data. The retransmission timeout is fixed at over 200 milliseconds, and the backoff is doubled with each retransmission, resulting in accumulated retransmission delays of several seconds during prolonged interference. Kitchen devices frequently switch between Wi-Fi access points and cellular networks as the terminal moves. During switching, the transmission control protocol socket breaks and reconstruction takes 300 milliseconds to 2 seconds. During reconstruction, the load of control commands accumulated in the transmission buffer faces the risk of timeout and loss. The single-link mechanism lacks path quality prediction capabilities and cannot transfer critical control commands to backup channels before signal attenuation. Once the current link is interrupted, all unconfirmed data is lost, requiring the upper application layer to maintain retransmission queues and state synchronization. Existing solutions alleviate backlog by increasing the transmission buffer capacity, but data packets are discarded upon write failure after buffer overflow. This still cannot guarantee the reliable delivery of critical commands such as emergency shutdown and temperature calibration under scenarios with overlapping interference and switching, thus restricting the security and availability of remote control of smart kitchen equipment. Therefore, how to achieve multi-link parallel transmission and dynamic failover to improve the transmission reliability of control commands in a kitchen with strong interference has become a challenge for the industry. Summary of the Invention

[0004] This application provides a cloud-based secure collaborative transmission method and system for kitchen equipment based on national cryptographic algorithms, which can realize multi-link parallel transmission and dynamic fault transfer, thereby improving the transmission reliability of control commands in a kitchen environment with strong interference.

[0005] Firstly, this application provides a cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms, including: After the kitchen equipment engine starts, it concurrently sends encrypted detection packets to multiple detection nodes pre-set in the cloud, records the round-trip latency, packet loss rate and jitter value of each detection path, and then calculates the comprehensive score. The detection path with the highest comprehensive score is the main link, and the rest are set as multi-level backup links in descending order of comprehensive score. When transmitting control commands, the device engine segments the load of the control commands into segments according to the maximum transmission unit. Based on the comprehensive score ratio of each link, it allocates the segments carried by each link. Each segment is attached with an encrypted verification header containing the segment sequence number and the verification code, and then sent to the cloud in parallel through the corresponding link. The cloud receiver caches the fragments received from each link. When the same fragment sequence number arrives for the first time on any link, it is retained. Subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all checksums are passed, the payload is reconstructed according to the fragment sequence numbers and an acknowledgment message is sent back to the device. If the device-side engine does not receive an acknowledgment message within a preset time, it will promote the primary backup link to the new primary link, thereby triggering a link switching event and pushing it to the cloud receiver.

[0006] In some embodiments, the round-trip time, packet loss rate, and jitter value of each detection path are recorded, and then a comprehensive score is calculated, specifically including: The device-side engine extracts timestamps from the encrypted probe packets returned by each probe path, calculates the difference between the current time and the timestamp, and obtains the round-trip delay of each probe path. The packet loss rate of each probe path is obtained by calculating the ratio of the number of probe packets that did not return within a preset period to the total number of packets sent. Calculate the mean square error of multiple round-trip delays for each detection path to obtain the jitter value for each detection path; The round-trip delay, packet loss rate, and jitter value of each detection path are weighted and summed to obtain a comprehensive score for each detection path.

[0007] In some embodiments, the device-side engine fragments the control command payload according to the maximum transmission unit, specifically including: The device-side engine obtains the total length of the control command payload and the maximum transmission unit of the kitchen equipment transmission link, and then obtains the total number of fragments; Data blocks of length equal to the maximum transmission unit (MTU) are sequentially extracted from the control command payload as valid fragments, and the remaining data that is less than the MTU length is taken as the last valid fragment. Assign an incrementing sequence number starting from zero to each valid shard, and write the total number of shards into the header field of each shard to obtain multiple shards.

[0008] In some embodiments, allocating fragments carried by each link based on the comprehensive score ratio of each link specifically includes: The allocation ratio of each link is determined by the comprehensive score of the main link and backup links at all levels; Link bearer allocation is performed based on the allocation ratio of each link and the total number of fragments to obtain the baseline number of fragments for each link; The remaining fragments after allocation are sequentially assigned to the links with the largest fractional part of the allocation ratio, until all fragments are allocated, thus obtaining the fragments carried by each link.

[0009] In some embodiments, each fragment, after being appended with an encrypted verification header containing a fragment sequence number and a verification code, is sent to the cloud in parallel via the corresponding link, specifically including: The device-side engine calculates a cyclic redundancy check value for each shard as a check code, and then concatenates the shard sequence number, the total number of shards, and the check code into a check header; The hardware security module is invoked to perform symmetric encryption on the entire assembly consisting of the verification header and the valid fragment using the current session key, thereby obtaining the encrypted fragment; Each encrypted shard is published to the cloud in parallel according to the allocation result via the message queue telemetry transmission protocol topic of the corresponding link.

[0010] In some embodiments, promoting a primary backup link to a new primary link, thereby triggering a link switching event and pushing it to the cloud receiver, specifically includes: The device-side engine writes the address of the current first-level backup link into the primary link address register, and downgrades the original primary link to the last-level backup link; Read the current timestamp and the switching reason field, and combine them with the new primary link to form a switching event message; The switching event message is sent to the switching event subscription topic at the cloud receiving end via the main link.

[0011] In some embodiments, after the kitchen equipment-side engine is started, it further includes: After the device-side engine starts, it reads the list of probe nodes in the local configuration file. The list of probe nodes contains the network addresses and port numbers of at least three cloud-preset nodes. The device-side engine periodically executes the entire process of detection, scoring, and link switching, with the period length specified by the interval field in the local configuration file; After each handover, the device-side engine writes the primary link address before and after the handover, as well as the handover timestamp, to the local log file.

[0012] Secondly, this application provides a cloud-based secure collaborative transmission system for kitchen equipment based on national cryptographic algorithms, comprising: The startup module is used to send encrypted detection packets concurrently to multiple detection nodes pre-set in the cloud after the engine of the kitchen equipment is started. It records the round-trip latency, packet loss rate and jitter value of each detection path, and then calculates the comprehensive score. The detection path with the highest comprehensive score is the main link, and the rest are set as multi-level backup links in descending order of comprehensive score. The processing module is used when transmitting control commands. The device-side engine segments the load of the control commands into segments according to the maximum transmission unit. Based on the comprehensive score ratio of each link, it allocates the segments carried by each link. Each segment is attached with an encrypted verification header containing the segment sequence number and the verification code, and then sent to the cloud in parallel through the corresponding link. The processing module is also used to cache the fragments received by each link at the cloud receiver. When the same fragment sequence number arrives for the first time on any link, it is retained. Subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all check codes pass, the payload is reconstructed according to the fragment sequence number and an acknowledgment message is sent back to the device. The execution module is used to upgrade the primary backup link to the new primary link if the device-side engine does not receive an acknowledgment message within a preset time, thereby triggering a link switching event and pushing it to the cloud receiver.

[0013] Thirdly, this application provides a computer device, which includes a memory and a processor. The memory is used to store a computer program, and the processor is used to call and run the computer program from the memory, so that the computer device executes the above-mentioned secure collaborative transmission method for kitchen equipment in the cloud based on national cryptographic algorithms.

[0014] Fourthly, this application provides a computer-readable storage medium storing instructions or code that, when executed on a computer, cause the computer to implement the aforementioned cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: This application provides a cloud-based secure collaborative transmission method and system for kitchen equipment based on national cryptographic algorithms. After the kitchen equipment-side engine starts, it concurrently sends encrypted detection packets to multiple pre-set detection nodes in the cloud, recording the round-trip delay, packet loss rate, and jitter value of each detection path. A comprehensive score is then calculated, with the detection path with the highest comprehensive score serving as the primary link, and the others set up as multi-level backup links in descending order of comprehensive score. When transmitting control commands, the equipment-side engine segments the load of the control commands according to the maximum transmission unit, allocating the load to each link based on the comprehensive score ratio of each link. Each fragment is attached with an encrypted verification header containing a fragment sequence number and a checksum, and then sent to the cloud in parallel through its corresponding link. The cloud receiver caches the fragments received from each link. When the same fragment sequence number arrives for the first time on any link, it is retained, and subsequent duplicate fragments are discarded. Once all fragment sequence numbers are complete and all checksums have passed, the payload is reassembled according to the fragment sequence numbers, and an acknowledgment message is sent back to the device. If the device engine does not receive an acknowledgment message within a preset time, it promotes the first-level backup link to the new primary link, thereby triggering a link switching event and pushing it to the cloud receiver.

[0016] Therefore, in this application, if the device-side engine does not receive an acknowledgment message within a preset time, it will promote the primary backup link to the new primary link, thereby triggering a link switching event and pushing it to the cloud receiver. Firstly, determining the number of fragments carried by each link enables quantitative matching of link quality and transmission load, thus preventing a single link from becoming a transmission bottleneck due to network quality degradation. The comprehensive scoring mechanism quantifies round-trip latency, packet loss rate, and jitter into a unified scale, allowing the allocation ratio to dynamically reflect the real-time carrying capacity of each link. Links with higher comprehensive scores carry more fragments, while those with lower scores carry fewer. The link carries fewer fragments, and the overall transmission load is negatively correlated with the available bandwidth and bit error rate of each link. This suppresses congestion and retransmission storms caused by weak signal links carrying excessive data, and avoids the accumulation of all fragments in the transmission buffer due to a sharp drop in the performance of a single link. After the buffer backlog is effectively distributed, a single link interruption no longer triggers a full data retransmission, thereby reducing the dependence of end-to-end transmission delay on the worst link quality. Then, by confirming the return of an acknowledgment message from the cloud receiver, a closed-loop feedback for multi-link parallel transmission can be established, thereby activating the rapid isolation of faulty links and... In the primary / backup switchover process, the acknowledgment message serves as a deterministic signaling of successful load restoration, enabling the device-side engine to clearly distinguish between link failure and transmission delay within a preset timeout window. This avoids prolonged fault response time due to passively waiting for retransmission timers to expire. Upon receiving the acknowledgment message, the engine immediately terminates redundant transmission of the current session and releases link buffer resources. If no acknowledgment message is received, the engine determines that the primary link no longer has reliable delivery capabilities and triggers the primary backup link to become the new primary link. This switchover decision uses the arrival status of the acknowledgment message as the sole criterion, without relying on the periodic sampling results of link quality detection. Therefore, it can achieve millisecond-level fault detection when sudden faults such as transmission control protocol socket breaks or route unreachability occur. After the switchover is completed, fragments are immediately redirected to the new primary link. Sent but unacknowledged fragments are automatically discarded by the cloud receiver based on the fragment sequence number deduplication mechanism. The device-side engine does not need to maintain a complex retransmission state machine, thereby simplifying the fault recovery process and reducing protocol interaction overhead during the switchover. In summary, based on the above scheme, multi-link parallel transmission and dynamic fault transfer can be achieved, thereby improving the transmission reliability of control commands in a kitchen environment with strong interference. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1This is an exemplary flowchart illustrating a cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms, according to some embodiments of this application. Figure 2 This is a schematic diagram of the process for determining the comprehensive score according to some embodiments of this application; Figure 3 This is a component association diagram of secure cloud-based collaborative transmission of kitchen equipment, as shown in some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a cloud-based secure collaborative transmission system for kitchen equipment based on national cryptographic algorithms, according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device that implements a cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms, according to some embodiments of this application. Detailed Implementation

[0019] To better understand the technical solution of this application, the technical solution of this application will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] refer to Figure 1 The figure is an exemplary flowchart of a secure collaborative transmission method for kitchen equipment in the cloud based on national cryptographic algorithms, according to some embodiments of this application. This secure collaborative transmission method for kitchen equipment in the cloud based on national cryptographic algorithms mainly includes the following steps: In step 101, after the kitchen equipment engine starts, it concurrently sends encrypted detection packets to multiple detection nodes pre-set in the cloud, records the round-trip delay, packet loss rate and jitter value of each detection path, and then calculates the comprehensive score. The detection path with the highest comprehensive score is the main link, and the rest are set as multi-level backup links in descending order of comprehensive score.

[0021] In some embodiments, the following steps can also be used after the kitchen equipment-side engine is started: After the device-side engine starts, it reads the list of probe nodes in the local configuration file. The list of probe nodes contains the network addresses and port numbers of at least three cloud-preset nodes. The device-side engine periodically executes the entire process of detection, scoring, and link switching, with the period length specified by the interval field in the local configuration file; After each handover, the device-side engine writes the primary link address before and after the handover, as well as the handover timestamp, to the local log file.

[0022] It should be noted that in this application, the probe node list is a local configuration data set that stores the network addresses and port numbers of the probe nodes preset in the cloud; the interval field is a configuration parameter that specifies the execution cycle of the entire process of probe, scoring and link switching; and the local log file is a local storage file that records the main link address and switching timestamp before and after the link switching.

[0023] In practice, the process is as follows: First, after the device-side engine starts, it opens the configuration file in the local configuration directory. The configuration file is in text format, with each line recording the network address and port number of a probe node, separated by a colon. The engine reads the configuration file line by line, filtering out blank lines and lines starting with a comment character. It parses the network address and port number of each line into address-port pairs and stores all successfully parsed address-port pairs in a memory list as the probe node list. If the engine encounters a line with an incorrect format during parsing, it skips that line and continues parsing the next line. After parsing, the total number of address-port pairs in the probe node list is recorded in a memory variable. Then, the engine reads the value of the interval field from the configuration file. This value, in seconds, is pre-written into the configuration file by the operations and maintenance personnel during device deployment. The engine uses the value of the interval field as the timer period and starts a loop timer. At the end of each timer period, the engine sequentially executes the complete process of probing the network quality of the path, calculating the comprehensive score of each path, setting the primary link and backup link based on the comprehensive score, and performing link switching when the primary link fails. After the engine completes the entire process of the current cycle, it waits for the next timed cycle to arrive. If a link switching event occurs within the current cycle, the cycle number at which the switching occurs is recorded. Finally, after each primary link switching operation, the engine reads the current time value of the device's real-time clock as the switching timestamp. The engine combines the primary link address before the switch, the new primary link address after the switch, and the switching timestamp into a log line in a fixed format, with the address before the switch, the address after the switch, and the timestamp arranged in sequence and separated by commas. The engine opens the local log file, appends the log line to the end of the file, closes the file after writing, and updates the primary link address recorded in the current memory cache to the new primary link address, which will serve as the source of the primary link address before the next switch.

[0024] It should be noted that, in this application, the encrypted probe packet is an encrypted data packet that measures the network quality of each probe path; the probe node is a cloud server node that provides the target address for network probe; and the probe path is a network transmission channel that carries the encrypted probe packet from the kitchen equipment engine to each probe node.

[0025] In practice, after the kitchen equipment engine starts, it reads the network addresses and port numbers of three cloud-preset probe nodes from the local configuration file. The port number of all three nodes is 8080. The engine obtains the current system timestamp and a randomly generated 16-byte sequence number, concatenates the timestamp and sequence number into a 16-byte probe payload, and calls the hardware security module to perform symmetric encryption on the probe payload using the current session key to obtain a 32-byte encrypted probe packet. The engine creates three User Datagram Protocol (UDP) sockets, binds them to three different local source ports, and sends the encrypted probe packets to the network addresses and port numbers of the three probe nodes through the three sockets respectively. Each socket is only responsible for sending the probe packet to one probe node. The engine records the network address of each probe node, the source port corresponding to the sending socket, and the timestamp of the sending time in a local cache table. Each record uses the probe node's network address as the index key. The engine uses the moment of the first sending of the encrypted probe packet as the start time of the probe cycle, which is used to count the number of probe packets returned for each path after 60 seconds.

[0026] In some embodiments, the round-trip time, packet loss rate, and jitter value of each detection path are recorded, and then a comprehensive score is calculated for reference. Figure 2 The diagram is a flowchart illustrating the process of determining the comprehensive score in some embodiments of this application. In this embodiment, the comprehensive score can be determined using the following steps: In step 1011, the device-side engine extracts the timestamp from the encrypted probe packets returned by each probe path, calculates the difference between the current time and the timestamp, and obtains the round-trip delay of each probe path. In step 1012, the ratio of the number of probe packets that did not return from each probe path within a preset period to the total number of packets sent is calculated to obtain the packet loss rate of each probe path. In step 1013, the mean square error of multiple round-trip delays for each detection path is calculated to obtain the jitter value of each detection path. In step 1014, the round-trip delay, packet loss rate and jitter value of each detection path are weighted and summed to obtain a comprehensive score for each detection path.

[0027] It should be noted that, in this application, round-trip latency is a value that measures the time required for a single probe packet to be sent from the device-side engine to the probe node and returned; the preset period is a fixed time length for calculating the packet loss rate; the packet loss rate is a percentage value that measures the proportion of data packets lost on the probe path; the jitter value is a value that measures the degree of fluctuation in round-trip latency on the probe path; and the comprehensive score is a value that quantifies the overall network transmission performance of the probe path.

[0028] In specific implementation, firstly, the device-side engine receives the encrypted response packets returned by each probe node, decrypts them using the current session key, and extracts the original timestamp from the response packet. The original timestamp is the sending time value written by the device-side engine when sending the probe packet in step one. The engine reads the current time value of the device's real-time clock, subtracts the original timestamp from the current time value, and uses the difference as the round-trip time of the probe path. The round-trip time of each probe path can be obtained in the above way. Secondly, the engine reads the start time of the current preset period recorded in the local cache table. The length of the preset period is 60 seconds, which is pre-written into the configuration file by the operation and maintenance personnel when the device is deployed. The engine counts the total number of probe packets sent by each probe path from the start time of the preset period to the current time, as well as the number of return response packets received. The total number of probe packets sent is subtracted from the number of return response packets received to obtain the number of probe packets that have not returned. The number of probe packets that have not returned is divided by the total number of probe packets sent, and the result is multiplied by 100 to obtain the packet loss rate expressed as a percentage. The packet loss rate of each probe path can be obtained in the above way.

[0029] Then, in the specific implementation, the engine reads the 10 most recent round-trip latency values ​​for the probe path from the local cache table. The engine calculates the average of these 10 values, then squares the difference between each value and the average. The sum of these 10 squared values ​​is divided by 10 to obtain the variance. The square root of the variance is then taken to obtain the mean square deviation, which is used as the jitter value for the probe path. The jitter value for each probe path can be obtained through this method. Finally, the engine reads the round-trip latency, packet loss rate, and jitter value for the probe path from the local cache table. The engine multiplies the round-trip latency by a weighting factor of 0.4 to obtain the first weighted value, multiplies the packet loss rate by a weighting factor of 0.3 to obtain the second weighted value, and multiplies the jitter value by a weighting factor of 0.3 to obtain the third weighted value. The first, second, and third weighted values ​​are added together to obtain the total deduction. The engine subtracts the total deduction from a fixed maximum score of 100, and uses the result as the comprehensive score for the probe path. The comprehensive score for each probe path can be obtained through this method.

[0030] It should be noted that in this application, references Figure 3This diagram illustrates the component relationships for secure collaborative transmission of kitchen equipment in the cloud. It includes four main modules: kitchen field equipment components, local security acquisition components, cloud security management components, and collaborative interaction output components. The kitchen field equipment module connects to gas stoves, fume purifiers, and water purifiers. All kitchen field equipment is connected to the local security acquisition module, which includes a data encryption unit and an equipment status acquisition unit. The local security acquisition module unidirectionally interfaces with the cloud security management platform, which contains an equipment security verification unit, a collaborative scheduling unit, and a storage unit. The cloud security management platform establishes data transmission connections with multiple collaborative interaction output terminals, which include mobile monitoring terminals and a kitchen control panel. Each kitchen terminal device is connected to the local security acquisition component, which in turn unidirectionally interfaces with the cloud security management component. The cloud security management component establishes data transmission connections with multiple collaborative interaction output components, comprehensively demonstrating the end-to-end hardware and cloud component hierarchy and data transmission logic for kitchen equipment acquisition, secure encrypted uploading, unified cloud scheduling, and multi-terminal collaborative distribution.

[0031] In step 102, when transmitting control commands, the device engine segments the load of the control commands into segments according to the maximum transmission unit. Based on the comprehensive score ratio of each link, it allocates the segments carried by each link. Each segment is attached with an encrypted verification header containing the segment sequence number and a checksum, and then sent to the cloud in parallel through the corresponding link.

[0032] In some embodiments, the device-side engine can fragment the control command payload according to the maximum transmission unit by the following steps: The device-side engine obtains the total length of the control command payload and the maximum transmission unit of the kitchen equipment transmission link, and then obtains the total number of fragments; Data blocks of length equal to the maximum transmission unit (MTU) are sequentially extracted from the control command payload as valid fragments, and the remaining data that is less than the MTU length is taken as the last valid fragment. Assign an incrementing sequence number starting from zero to each valid shard, and write the total number of shards into the header field of each shard to obtain multiple shards.

[0033] It should be noted that, in this application, the control instruction payload is a binary data block carrying the original content of the control instruction; the maximum transmission unit is a preset byte value that limits the maximum length of a single fragment; the total number of fragments is an integer indicating the number of fragments obtained after the control instruction payload is split; the valid fragment is a data block of equal or unequal length carrying a portion of the data extracted from the control instruction payload; the header field is a fixed-length area storing the fragment sequence number and the total number of fragments; and a fragment is a complete data block containing the header field and the valid fragment for subsequent allocation of link carrying.

[0034] In practice, the device-side engine first receives control commands from the upper-layer business module, stores the binary content of the control commands as the control command payload in the memory buffer, calls the memory operation function to obtain the byte length of the control command payload, and records it as the total payload length. The engine reads the value of the maximum transmission unit from the local configuration file. The value of the maximum transmission unit is 1500 bytes, which is pre-written into the configuration file by the operation and maintenance personnel during device deployment. The engine divides the total payload length by the maximum transmission unit value of 1500, and rounds the result up to obtain the total number of fragments.

[0035] Then, in the specific implementation, the engine declares an empty shard list to store all the shards generated subsequently. Starting from the beginning byte position of the control instruction payload, the engine truncates a data block of 1500 bytes in length as a valid shard each time, reduces the length of the remaining data after truncation by 1500 bytes, and repeats the above truncation operation until the remaining data length is less than or equal to 1500 bytes. Then, all the remaining data is taken as the last valid shard, and the truncation process ends after adding the last valid shard to the shard list.

[0036] Finally, in the specific implementation, the engine declares an integer variable as a sequence counter, sets the initial value of the sequence counter to 0, retrieves the first valid fragment from the fragment list in the order of generation, writes the current value of the sequence counter into the first 4 bytes of the header field of the valid fragment, writes the total number of fragments into the next 4 bytes of the header field of the valid fragment, increments the sequence counter by 1, retrieves the next valid fragment and repeats the above writing operation until the header fields of all valid fragments in the fragment list have been written with the sequence number and the total number of fragments. The engine outputs all valid fragments whose header fields have been written as fragments. The header field of each fragment is 8 bytes long, and the valid data part is arranged immediately after the header field.

[0037] In some embodiments, allocating fragments carried by each link based on the comprehensive score ratio of each link can be achieved by the following steps: The allocation ratio of each link is determined by the comprehensive score of the main link and backup links at all levels; Link bearer allocation is performed based on the allocation ratio of each link and the total number of fragments to obtain the baseline number of fragments for each link; The remaining fragments after allocation are sequentially assigned to the links with the largest fractional part of the allocation ratio, until all fragments are allocated, thus obtaining the fragments carried by each link.

[0038] It should be noted that, in this application, the allocation ratio is a weighted value that determines the proportion of the number of fragments that each link should carry relative to the total number of fragments; the baseline fragment number represents the initial integer value of the number of fragments that each link should carry after calculation according to the allocation ratio; the decimal part of the allocation ratio is a comparison value used to determine whether a link has priority in obtaining the remaining fragments after the baseline fragment number is allocated; and the fragments carried by a link indicate the set of fragments that each link is actually responsible for transmitting.

[0039] In practice, the device-side engine first reads the comprehensive scores of the primary link, the first-level backup link, and the second-level backup link from the local cache table. The engine adds the comprehensive scores of the primary link, the first-level backup link, and the second-level backup link to obtain the total score. The engine divides the comprehensive score of the primary link by the total score and uses the result as the allocation ratio of the primary link. The engine divides the comprehensive score of the first-level backup link by the total score and uses the result as the allocation ratio of the first-level backup link. The engine divides the comprehensive score of the second-level backup link by the total score and uses the result as the allocation ratio of the second-level backup link. The engine stores the allocation ratios of the three links in a memory array, where array index 0 corresponds to the primary link, index 1 corresponds to the first-level backup link, and index 2 corresponds to the second-level backup link.

[0040] Then, in the specific implementation, the engine reads the total number of shards, multiplies the total number of shards by the allocation ratio of the primary link, rounds the product down, and uses the rounded result as the base number of shards for the primary link. The engine multiplies the total number of shards by the allocation ratio of the primary backup link, rounds the product down, and uses the rounded result as the base number of shards for the primary backup link. The engine multiplies the total number of shards by the allocation ratio of the secondary backup link, rounds the product down, and uses the rounded result as the base number of shards for the secondary backup link. The engine stores the base number of shards for the three links in a memory array, where array index 0 corresponds to the primary link, index 1 corresponds to the primary backup link, and index 2 corresponds to the secondary backup link.

[0041] Finally, in the specific implementation, the engine subtracts the baseline number of shards for the main link from the allocation ratio of the main link, dividing the base number of shards by the total number of shards. The difference is used as the decimal part of the allocation ratio for the main link. The engine calculates the decimal parts of the allocation ratios for the primary and secondary backup links using the same method. The engine subtracts the sum of the baseline shard numbers for the main link, primary backup, and secondary backup links from the total number of shards, using the difference as the remaining shard number. The engine compares the decimal parts of the allocation ratios for the three links and allocates the first remaining shard to the link with the largest decimal part. For large links, the engine increments the number of allocated shards for that link by 1, decrements the number of remaining shards by 1, and re-compares the relationship between the fractional part of the allocation ratio of the three links and the number of additional allocated shards. The next shard is assigned to the link with the largest difference between the fractional part of the current allocation ratio and the number of additional allocated shards. This process is repeated until the number of remaining shards equals 0. The engine adds the base number of shards for each link to the number of remaining shards allocated to each link, and uses the sum as the final number of shards carried by each link. Each link and its corresponding number of shards are associated and stored in the memory allocation table.

[0042] In some embodiments, each fragment, after being appended with an encrypted verification header containing a fragment sequence number and a verification code, is sent to the cloud in parallel via its corresponding link. This can be achieved using the following steps: The device-side engine calculates a cyclic redundancy check value for each shard as a check code, and then concatenates the shard sequence number, the total number of shards, and the check code into a check header; The hardware security module is invoked to perform symmetric encryption on the entire assembly consisting of the verification header and the valid fragment using the current session key, thereby obtaining the encrypted fragment; Each encrypted shard is published to the cloud in parallel according to the allocation result via the message queue telemetry transmission protocol topic of the corresponding link.

[0043] It should be noted that in this application, the Cyclic Redundancy Check (CR) value is a check code that verifies whether errors have occurred in the transmission of fragmented data; the check header is a fixed-length plaintext header that stores the fragment sequence number, the total number of fragments, and the check code; the current session key is the key for this communication session that performs symmetric encryption; the encrypted fragment is a complete encrypted data block that is securely transmitted on the link; and the message queue telemetry transmission protocol subject is a protocol label that identifies the destination of data publication on different links.

[0044] In practice, the device-side engine first retrieves a fragment from the fragment list in sequence, reads the valid data portion of the fragment, and inputs each byte of the valid data into the Cyclic Redundancy Check (CRBC) calculator. The calculator uses a 32-bit CRBC algorithm, and after calculation, outputs a 4-byte check value as the CRBC value of the fragment. The engine reads the fragment sequence number and the total number of fragments from the header field of the fragment. The engine writes the fragment sequence number to the beginning of a 4-byte temporary buffer, writes the total number of fragments to the next 4 bytes, and writes the CRBC value to the last 4 bytes. The 12 bytes of data arranged sequentially in the temporary buffer serve as the check header of the fragment. The engine repeats the above operations for each fragment in the fragment list until all fragments have generated corresponding check headers.

[0045] Then, in the specific implementation, the engine calls the symmetric encryption interface provided by the hardware security module to merge the verification header and the valid data of the corresponding fragment into a continuous input byte stream in sequence. The starting position of the input byte stream is the first byte of the verification header, and the ending position is the last byte of the valid data. The engine passes the current session key to the encryption interface, which uses a symmetric encryption algorithm to perform encryption operations on the entire input byte stream. The encryption operation is performed in 16-byte blocks. If the last block is less than 16 bytes, it is padded to 16 bytes according to the standard padding method before encryption. The encryption interface outputs the encrypted byte stream, the length of which is equal to the length of the input byte stream padded to a multiple of 16 bytes. The engine uses the encrypted byte stream as the encrypted fragment corresponding to the fragment.

[0046] Finally, in the specific implementation, the engine reads the number of shards carried by the main link, the first-level backup link, and the second-level backup link from the memory allocation table. Based on the shard sequence number in ascending order, the engine allocates the number of encrypted shards carried by the first-level backup link to the main link, the number of encrypted shards carried by the first-level backup link to the first-level backup link, and the number of encrypted shards carried by the last second-level backup link to the second-level backup link. For each encrypted shard allocated to the main link, the engine uses the encrypted shard as the message payload, uses the message queue telemetry transmission protocol topic corresponding to the main link as the publication target, and calls the protocol stack sending interface to publish it to the cloud in parallel. For the encrypted shards allocated to the first-level backup link and the second-level backup link, the engine uses their respective message queue telemetry transmission protocol topics as publication targets and executes the publication operation simultaneously. The publication operation of the three links starts in parallel at the same time.

[0047] In step 103, the cloud receiver caches the fragments received from each link. The same fragment sequence number is retained when it arrives for the first time on any link, and subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all checksums pass, the payload is reassembled according to the fragment sequence numbers and an acknowledgment message is sent back to the device.

[0048] It should be noted that in this application, a fragment is an encrypted data block that carries a portion of the control command load after it has been split; a fragment sequence number is a numerical number that identifies the position of the fragment in the load; a checksum is a cyclic redundancy check value that verifies the integrity of the fragment data; the load is a complete binary data block that carries the original content of the control command; and an acknowledgment message is a cloud-transmitted data packet that notifies the device-side engine that the load has been successfully restored.

[0049] In practice, the cloud receiver first maintains independent receive buffers for each of the three links. Each buffer uses the fragment sequence number as the key and the fragment data as the storage content. The cloud receiver continuously receives encrypted fragments from the message queue telemetry transmission protocol topic corresponding to the main link, calls the hardware security module to decrypt them with the current session key to obtain plaintext fragments, reads the fragment sequence number and checksum from the plaintext fragment's checksum header, and checks whether the fragment sequence number already exists in the main link buffer. If it already exists, the current fragment is discarded; if it does not exist, the decrypted plaintext fragment is stored in the corresponding sequence number position in the main link buffer. The cloud receiver simultaneously receives encrypted fragments from the message queue telemetry transmission protocol topics corresponding to the primary backup link and the secondary link, decrypts them in the same way, and checks whether the fragment sequence number already exists in their respective buffers. If it already exists, it is discarded; if it does not exist, it is stored in the corresponding buffer.

[0050] Secondly, in the specific implementation, after the cloud receiver stores a new fragment into any link buffer, it merges the fragment sequence numbers stored in the three link buffers into a global received sequence number set. During the merging, only one of the same sequence number is kept. The cloud receiver checks whether the sequence numbers in the global received sequence number set are continuously incremented from 0 until the total number of fragments is reduced by 1. If there are missing sequence numbers, it continues to wait for the subsequent fragments to arrive. If the global received sequence number set is still incomplete within the preset timeout period of 5 seconds, the cloud receiver discards all the cached fragments received this time and sends a failure notification message back to the device engine.

[0051] Then, in the specific implementation, after the global sequence number set is complete, the cloud receiver retrieves the plaintext fragments with corresponding sequence numbers from each link buffer in order of fragment sequence number from 0 to the total number of fragments minus 1. The cloud receiver recalculates the cyclic redundancy check value for each retrieved fragment and compares it with the checksum stored in the checksum header. If all comparisons pass, the valid data of all fragments are concatenated into a continuous binary byte stream in sequence number order, and the concatenated result is used as the restored payload. If any fragment's checksum fails the comparison, the cloud receiver discards the fragment and waits for the arrival of a new fragment with the same sequence number.

[0052] Finally, in the specific implementation, after the load restoration is completed, the cloud receiver calculates the message digest algorithm hash value of the restored load as a whole, combines the hash value with the current timestamp to form the payload of the confirmation message, and calls the hardware security module to perform symmetric encryption on the confirmation message payload with the current session key to obtain the encrypted confirmation message. The cloud receiver sends the encrypted confirmation message back to the device engine through 3 links at the same time as a notification that the load has been successfully restored.

[0053] In step 104, if the device-side engine does not receive an acknowledgment message within a preset time, it will upgrade the primary backup link to the new primary link, thereby triggering a link switching event and pushing it to the cloud receiver.

[0054] It should be noted that in this application, the acknowledgment message is a cloud-based data packet notifying the device-side engine that its load has been successfully restored. Specifically, when the device-side engine sends the last encrypted fragment in parallel across three links, it simultaneously reads the timeout field value from its local configuration file. The timeout field value is 3 seconds, pre-written into the configuration file by maintenance personnel during device deployment, and the engine stores this value as a preset time in a memory variable. The engine starts a hardware timer when sending the last encrypted fragment, with the timer's timeout value set to the preset 3 seconds. The engine continuously monitors the hardware timer's status and listens to the message queue telemetry transmission protocol topics on the three links, waiting for the acknowledgment message from the cloud receiver. If the engine receives an acknowledgment message from any link before the hardware timer triggers a timeout interrupt, it stops the hardware timer and clears the timer interrupt flag. If the engine has not received any acknowledgment message by the time the hardware timer triggers a timeout interrupt, it determines that the current main link has failed and records this timeout event in its local cache as a trigger condition for link switching operations.

[0055] In some embodiments, promoting a primary backup link to a new primary link, thereby triggering a link switching event and pushing it to the cloud receiver, can be achieved through the following steps: The device-side engine writes the address of the current first-level backup link into the primary link address register, and downgrades the original primary link to the last-level backup link; Read the current timestamp and the switching reason field, and combine them with the new primary link to form a switching event message; The switching event message is sent to the switching event subscription topic at the cloud receiving end via the main link.

[0056] It should be noted that in this application, the primary link address register is a hardware storage unit that stores the current primary link network address; the last-level backup link is the backup link with the lowest priority in the link ranking and is only activated when all higher-level backup links fail; the handover event message is a notification data packet that informs the cloud receiver that the primary link has changed; and the handover event subscription topic is the protocol label for receiving the handover event message.

[0057] In practice, firstly, the device-side engine reads the network address of the primary backup link from the local cache table and writes it into the primary link address register, overwriting the original primary link address in the register. The engine then removes the network address of the original primary link from the link sorting in the local cache table, places the original primary link after the secondary backup link as the last-level backup link, and marks the comprehensive score of the original primary link as invalid. Subsequent detection processes will recalculate the comprehensive score for this link and restore its sorting position. The engine then synchronously updates the primary link address field in the local cache table with the network address of the new primary link.

[0058] Then, in the specific implementation, the engine reads the current time value of the device's real-time clock as the switching timestamp. The switching timestamp is accurate to milliseconds. The engine reads the switching reason field from the local cache table. The switching reason field is a preset integer value. A value of 1 indicates that the switching is triggered because no acknowledgment message was received within a timeout period. A value of 2 indicates that the switching is triggered because the comprehensive score of the main link is continuously lower than the threshold. In this case, the switching reason field is set to a value of 1. The engine concatenates the new main link address, the switching timestamp, and the switching reason field into a binary message payload. The first 4 bytes of the message payload store the integer value of the new main link address, the next 8 bytes store the long integer value of the switching timestamp, and the last 1 byte stores the integer value of the switching reason field. This binary message payload serves as the switching event message.

[0059] Finally, in the specific implementation, the engine calls the hardware security module to perform symmetric encryption on the entire handover event message using the current session key, obtaining the encrypted handover event message. The engine reads the name of the handover event subscription topic from the local cache table. The name of the handover event subscription topic is a fixed string, which is pre-written into the configuration file by the operation and maintenance personnel during device deployment. The engine uses the encrypted handover event message as the message payload, with the handover event subscription topic as the publishing target, and sends the handover event message to the cloud receiving end through the message queue telemetry transmission protocol client corresponding to the new main link. After sending, the engine writes a copy of the handover event message to the local log file as a persistent record of the handover operation.

[0060] Furthermore, in another aspect of this application, in some embodiments, this application provides a cloud-based secure collaborative transmission system for kitchen equipment based on national cryptographic algorithms, referencing... Figure 4The figure is a schematic diagram of the structure of a cloud-based secure collaborative transmission system for kitchen equipment based on national cryptographic algorithms, according to some embodiments of this application. This system includes a startup module 201, a processing module 202, and an execution module 203, which are described below: The startup module 201 in this application is mainly used to send encrypted detection packets concurrently to multiple detection nodes pre-set in the cloud after the engine of the kitchen equipment is started, record the round-trip delay, packet loss rate and jitter value of each detection path, and then calculate the comprehensive score, with the detection path with the highest comprehensive score as the main link, and the rest set as multi-level backup links in descending order of comprehensive score. In this application, when the processing module 202 is used to transmit control commands, the device-side engine segments the load of the control commands into segments according to the maximum transmission unit, allocates the segments carried by each link according to the comprehensive score ratio of each link, and after attaching an encrypted verification header containing the segment sequence number and the verification code to each segment, they are sent to the cloud in parallel through the corresponding links. It should be noted that the processing module 202 is also used to cache the fragments received by each link at the cloud receiving end. When the same fragment sequence number arrives for the first time on any link, it is retained. Subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all check codes pass, the payload is reassembled according to the fragment sequence number and an acknowledgment message is sent back to the device. The execution module 203 in this application is mainly used to upgrade the primary backup link to the new primary link if the device engine does not receive an acknowledgment message within a preset time, thereby triggering a link switching event and pushing it to the cloud receiving end.

[0061] The foregoing detailed examples of a secure cloud-based collaborative transmission method and system for kitchen equipment based on national cryptographic algorithms provided in this application. It is understood that the corresponding apparatus, in order to achieve the above functions, includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0062] In some embodiments, this application also provides a computer device, the computer device including a memory and a processor, the memory for storing a computer program, and the processor for calling and running the computer program from the memory, so that the computer device executes the above-described secure collaborative transmission method for kitchen equipment in the cloud based on national cryptographic algorithms.

[0063] In some embodiments, reference Figure 5 The dashed lines in the figure indicate that the unit or module is optional. This figure is a structural schematic diagram of a computer device implementing a cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms, according to an embodiment of this application. The cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms described in the above embodiments can... Figure 5 The computer device shown is used to implement this, and the computer device includes at least one processor 301, a memory 302 and at least one communication unit 305. The computer device may be a terminal device, a server or a chip.

[0064] Processor 301 can be a general-purpose processor or a special-purpose processor. For example, processor 301 can be a central processing unit (CPU), which can be used to control computer devices, execute software programs, and process data from software programs. The computer device may also include a communication unit 305 for inputting (receiving) and outputting (transmitting) signals.

[0065] For example, the computer device may be a chip, and the communication unit 305 may be the input and / or output circuit of the chip, or the communication unit 305 may be the communication interface of the chip, which may be a component of a terminal device, network device or other device.

[0066] For example, the computer device may be a terminal device or a server, and the communication unit 305 may be a transceiver of the terminal device or the server, or the communication unit 305 may be a transceiver circuit of the terminal device or the server.

[0067] The computer device may include one or more memories 302 storing a program 304. The program 304 can be executed by a processor 301 to generate instructions 303, causing the processor 301 to execute the method described in the above method embodiments according to the instructions 303. Optionally, the memory 302 may also store data (such as a target audit model). Optionally, the processor 301 may also read data stored in the memory 302, which may be stored at the same storage address as the program 304, or it may be stored at a different storage address than the program 304.

[0068] The processor 301 and memory 302 can be configured separately or integrated together, for example, integrated on the system on chip (SOC) of the terminal device.

[0069] It should be understood that each step of the above method embodiment can be completed by hardware logic circuits or software instructions in the processor 301. The processor 301 can be a CPU, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, such as discrete gate, transistor logic devices, or discrete hardware components.

[0070] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0071] For example, in some embodiments, this application also provides a computer-readable storage medium storing instructions or code that, when executed on a computer, cause the computer to implement the above-described secure collaborative transmission method for kitchen equipment in the cloud based on national cryptographic algorithms.

[0072] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0073] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms, characterized in that, Includes the following steps: After the kitchen equipment engine starts, it concurrently sends encrypted detection packets to multiple detection nodes pre-set in the cloud, records the round-trip latency, packet loss rate and jitter value of each detection path, and then calculates the comprehensive score. The detection path with the highest comprehensive score is the main link, and the rest are set as multi-level backup links in descending order of comprehensive score. When transmitting control commands, the device engine segments the load of the control commands into segments according to the maximum transmission unit. Based on the comprehensive score ratio of each link, it allocates the segments carried by each link. Each segment is attached with an encrypted verification header containing the segment sequence number and the verification code, and then sent to the cloud in parallel through the corresponding link. The cloud receiver caches the fragments received from each link. When the same fragment sequence number arrives for the first time on any link, it is retained. Subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all checksums are passed, the payload is reconstructed according to the fragment sequence numbers and an acknowledgment message is sent back to the device. If the device-side engine does not receive an acknowledgment message within a preset time, it will promote the primary backup link to the new primary link, thereby triggering a link switching event and pushing it to the cloud receiver.

2. The method as described in claim 1, characterized in that, Record the round-trip delay, packet loss rate, and jitter value of each detection path, and then calculate the comprehensive score, which specifically includes: The device-side engine extracts timestamps from the encrypted probe packets returned by each probe path, calculates the difference between the current time and the timestamp, and obtains the round-trip delay of each probe path. The packet loss rate of each probe path is obtained by calculating the ratio of the number of probe packets that did not return within a preset period to the total number of packets sent. Calculate the mean square error of multiple round-trip delays for each detection path to obtain the jitter value for each detection path; The round-trip delay, packet loss rate, and jitter value of each detection path are weighted and summed to obtain a comprehensive score for each detection path.

3. The method as described in claim 1, characterized in that, The device-side engine will fragment the control command payload according to the maximum transmission unit, specifically including: The device-side engine obtains the total length of the control command payload and the maximum transmission unit of the kitchen equipment transmission link, and then obtains the total number of fragments; Data blocks of length equal to the maximum transmission unit (MTU) are sequentially extracted from the control command payload as valid fragments, and the remaining data that is less than the MTU length is taken as the last valid fragment. Assign an incrementing sequence number starting from zero to each valid shard, and write the total number of shards into the header field of each shard to obtain multiple shards.

4. The method as described in claim 1, characterized in that, The allocation of fragments to each link based on the comprehensive score ratio of each link specifically includes: The allocation ratio of each link is determined by the comprehensive score of the main link and backup links at all levels; Link bearer allocation is performed based on the allocation ratio of each link and the total number of fragments to obtain the baseline number of fragments for each link; The remaining fragments after allocation are sequentially assigned to the links with the largest fractional part of the allocation ratio, until all fragments are allocated, thus obtaining the fragments carried by each link.

5. The method as described in claim 1, characterized in that, Each fragment, after being appended with an encrypted verification header containing a fragment sequence number and a checksum, is sent to the cloud in parallel via its corresponding link. Specifically, this includes: The device-side engine calculates a cyclic redundancy check value for each shard as a check code, and then concatenates the shard sequence number, the total number of shards, and the check code into a check header; The hardware security module is invoked to perform symmetric encryption on the entire assembly consisting of the verification header and the valid fragment using the current session key, thereby obtaining the encrypted fragment; Each encrypted shard is published to the cloud in parallel according to the allocation result via the message queue telemetry transmission protocol topic of the corresponding link.

6. The method as described in claim 1, characterized in that, Upgrading the primary backup link to the new primary link, thereby triggering a link switchover event and pushing it to the cloud receiver, specifically includes: The device-side engine writes the address of the current first-level backup link into the primary link address register, and downgrades the original primary link to the last-level backup link; Read the current timestamp and the switching reason field, and combine them with the new primary link to form a switching event message; The switching event message is sent to the switching event subscription topic at the cloud receiving end via the main link.

7. The method as described in claim 1, characterized in that, After the kitchen equipment engine starts, it also includes: After the device-side engine starts, it reads the list of probe nodes in the local configuration file. The list of probe nodes contains the network addresses and port numbers of at least three cloud-preset nodes. The device-side engine periodically executes the entire process of detection, scoring, and link switching, with the period length specified by the interval field in the local configuration file; After each handover, the device-side engine writes the primary link address before and after the handover, as well as the handover timestamp, to the local log file.

8. A cloud-based secure collaborative transmission system for kitchen equipment based on national cryptographic algorithms, characterized in that, include: The startup module is used to send encrypted detection packets concurrently to multiple detection nodes pre-set in the cloud after the engine of the kitchen equipment is started. It records the round-trip latency, packet loss rate and jitter value of each detection path, and then calculates the comprehensive score. The detection path with the highest comprehensive score is the main link, and the rest are set as multi-level backup links in descending order of comprehensive score. The processing module is used when transmitting control commands. The device-side engine segments the load of the control commands into segments according to the maximum transmission unit. Based on the comprehensive score ratio of each link, it allocates the segments carried by each link. Each segment is attached with an encrypted verification header containing the segment sequence number and the verification code, and then sent to the cloud in parallel through the corresponding link. The processing module is also used to cache the fragments received by each link at the cloud receiver. When the same fragment sequence number arrives for the first time on any link, it is retained. Subsequent duplicate fragments are discarded. After all fragment sequence numbers are complete and all check codes pass, the payload is reconstructed according to the fragment sequence number and an acknowledgment message is sent back to the device. The execution module is used to upgrade the primary backup link to the new primary link if the device-side engine does not receive an acknowledgment message within a preset time, thereby triggering a link switching event and pushing it to the cloud receiver.

9. A computer device, characterized in that, The computer device includes a memory and a processor. The memory is used to store computer programs, and the processor is used to call and run the computer programs from the memory, so that the computer device executes the cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions or code that, when executed on a computer, cause the computer to implement the cloud-based secure collaborative transmission method for kitchen equipment based on national cryptographic algorithms as described in any one of claims 1 to 7.

Images