A state synchronization method and device in an edge computing scenario

Abstract

The present application mainly relates to the field of edge computing, and particularly relates to a state synchronization method and device in an edge computing scenario, wherein a record table is configured at the cloud side and the edge side, each piece of information of the record table comprises last record check code information, type information of current record information, state or operation information of the current record information, time information and check code information; the check code information in the record table generated by the cloud side or the edge side is a check code with singularity; when the cloud side or the edge side sends the latest piece of information in the record table to the other side, the cloud side or the edge side matches the last record check code information in the received latest piece of information with the check code information of the last piece of information in the record table, if the matching is successful, the cloud side or the edge side records; if the matching is not successful, the information which is not matched successfully is sent to the other side and the record table information is synchronized.

Description

Technical Field

[0001] This invention relates primarily to the field of edge computing, and more particularly to a state synchronization method and apparatus for edge computing scenarios. Background Technology

[0002] In existing edge networks, edge nodes are typically heterogeneous and distributed across different locations. The networks hosting edge nodes are usually constrained (bandwidth, latency, reliability, etc.). A common approach is to manage edge nodes uniformly using a reliable cloud management plane. Users can manage and view the status of edge nodes (or applications running on them) through this cloud management plane. Common methods for ensuring consistency between the cloud and edge node states include cloud-initiated requests (operation / status synchronization, etc.) awaiting responses from edge nodes, edge nodes periodically reporting their status, and retransmission of lost packets (without a response). Industry-standard solutions are primarily based on these methods, or variations thereof, and are essentially not significantly different.

[0003] The existing solution has the following drawbacks:

[0004] 1. The status of cloud storage comes from multiple sources, making its status unreliable.

[0005] The cloud can infer the status based on the response messages from edge nodes, or on the periodically reported messages from edge nodes. However, status transitions cannot be directly overwritten. For example, a report message with an older status might arrive at the cloud later than the response message for an operation. Directly overwriting this would lead to inconsistencies. For instance, in Example 1: at timestamp 1665370515000, the edge reports message A, a periodically reported node status message, with the content "Running." At timestamp 1665370516000, the edge reports message B, a status change synchronization message, with the content "Shutting down." Due to network issues, message B arrives at the cloud before message A, and the cloud's status changes from "Shutting down" to "Running," which is clearly inconsistent with reality. Inferring status based on sending time and existing status can only solve single-scenario problems. For example, in Example 1, the later-arriving message A might be discarded. Similarly, the loss of the operation response message might prevent the cloud's stored status from being updated in a timely manner. For instance, in Example 1, if message B is lost, the status will remain "Running." Intensive message interactions, such as retransmission requests when the cloud doesn't receive a response from the edge node and repeated user operations, exacerbate the unreliability of cloud storage status. For example, in Example 2: the cloud sends a task execution command (training a model, running an application) to the edge, but doesn't receive a response. Retransmission from the cloud will cause duplicate execution, and the edge may also perform duplicate executions. If the user then repeatedly deletes and executes tasks on the front end, there will be intensive message interactions between the cloud and the edge. The actual operation on the edge may differ from expectations, and the state stored in the cloud may also differ from that on the edge.

[0006] 2. High network overhead and heavy cloud pressure.

[0007] Frequent edge status reporting and packet loss retransmission, among other intensive operations, can increase network load and put pressure on the cloud. For example, in Example 3, edge nodes synchronize their own status (and the status of applications running on them) every 5 minutes, and immediately report the latest status when either changes. When there are many edge nodes in the system (e.g., reaching millions), the number of status synchronization packets in the network is enormous, potentially causing network congestion and placing significant processing pressure on the cloud.

[0008] 3. Prone to errors

[0009] Unreliable status is highly likely to trigger users to perform repeated operations. When some operations are repeatedly executed, the actual situation may differ from the expectation, potentially leading to more serious errors. The resend mechanism will also be affected in this way. For example, in Example 4: A user needs to run an nginx program on edge node A. When the user checks through the cloud platform, they find that the nginx program on edge node A is in a stopped state (when it is actually running). The user then creates another nginx program on edge node A through the cloud platform. Due to port listening issues, the second nginx program cannot run properly, and the user is likely to perform multiple deletion and creation operations.

[0010] 5. Operations and status are difficult to trace.

[0011] Relying solely on cloud-based storage of status and operation records is unreliable, failing to reflect actual operational conditions and offering little assistance in tracing and locating later problems. The cloud typically only stores the latest status and operation records, and these are stored separately, making it difficult to correlate operations with status. For example, in Example 5: a user runs an nginx program on an edge node and needs to modify the nginx configuration file and restart it for the changes to take effect. Before the restart, nginx's running status is "running," and after the restart, it remains "running." It's difficult for the user to determine whether the restart has taken effect based on nginx's running status. Tracing the correspondence between the current status and operations is very cumbersome. Summary of the Invention

[0012] To address the aforementioned technical problems, this invention provides a state synchronization method and apparatus for edge computing scenarios. This invention is achieved through the following technical solution:

[0013] A state synchronization method for edge computing scenarios.

[0014] Record tables are configured on both the cloud and edge sides. Each record in the record table includes the verification code information of the previous record, the type information of the current record, the status or operation information of the current record, the time information, and the verification code information.

[0015] The checksum information in the record table generated in the cloud or edge is a unique checksum.

[0016] When the latest record in the record table is sent from the cloud or edge to the other side, the cloud or edge matches the checksum of the previous record in the latest record with the checksum of the most recent record in the record table. If the match is successful, the cloud or edge records the record; if the match is unsuccessful, the unmatched record is sent to the other side and the record table information is synchronized.

[0017] Preferably, when synchronizing record table information,

[0018] If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received message with the check code information already recorded on that side. If the edge side fails to match, it will send the message that failed to match again to the cloud and send the most recent message in the record table before the edge side received the latest message to the cloud. The cloud will generate new instruction information based on the check code information in the most recent message in the record table received from the edge side and send the instruction information to the edge side.

[0019] Preferably, if the receiving end is the edge side, the edge side will sequentially match the previous record check code information in the latest received information with the check code information already recorded on the edge side. If the match is successful on the edge side, the edge side will record the latest received information and send the latest received information and the information between the latest received information and the successfully matched record in the edge side's record table to the cloud, where the cloud will also record it.

[0020] Preferably, when synchronizing record table information,

[0021] If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If no match is found in the cloud, the cloud will send the unmatched message to the edge side and send the most recent message in the record table before the latest message received by the cloud to the edge side. The edge side will then match the previous record checksum information in the most recent message in the cloud's record table with the information in its own record table. The edge side will then send all the information in its record table up to the one that matches the previous record checksum information in the most recent message in the cloud's record table to the cloud for recording.

[0022] Preferably, when synchronizing record table information,

[0023] The receiving end will match the previous record's checksum information in the latest received message with the checksum information already recorded on that side. If the match is successful in the cloud, the latest received message will be saved in the cloud.

[0024] This invention also provides a state synchronization device for edge computing scenarios, including a cloud side and an edge side.

[0025] Record tables are configured on both the cloud and edge sides. Each record in the record table includes the verification code information of the previous record, the type information of the current record, the status or operation information of the current record, the time information, and the verification code information.

[0026] The checksum information in the record table generated in the cloud or edge is a unique checksum.

[0027] When the latest record in the record table is sent from the cloud or edge to the other side, the cloud or edge matches the checksum of the previous record in the latest record with the checksum of the most recent record in the record table. If the match is successful, the cloud or edge records the record; if the match is unsuccessful, the unmatched record is sent to the other side and the record table information is synchronized.

[0028] Preferably, when synchronizing record table information,

[0029] If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received message with the check code information already recorded on that side. If the edge side fails to match, it will send the message that failed to match again to the cloud and send the most recent message in the record table before the edge side received the latest message to the cloud. The cloud will generate new instruction information based on the check code information in the most recent message in the record table received from the edge side and send the instruction information to the edge side.

[0030] Preferably, when synchronizing record table information,

[0031] If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received information with the check code information already recorded on the edge side. If the match is successful on the edge side, the edge side will record the latest received information and send the latest received information and all information between the latest received information and the successfully matched record in the edge side's record table to the cloud, where the cloud will also record it.

[0032] Preferably, when synchronizing record table information,

[0033] If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If no match is found in the cloud, the cloud will send the unmatched message to the edge side and send the most recent message in the record table before the latest message received by the cloud to the edge side. The edge side will then match the previous record checksum information in the most recent message in the cloud's record table with the information in its own record table. The edge side will then send all the information in its record table up to the one that matches the previous record checksum information in the most recent message in the cloud's record table to the cloud for recording.

[0034] Preferably, when synchronizing record table information,

[0035] The receiving end matches the checksum information of the previous record in the latest received message with the checksum information already recorded on that side. If a match is found in the cloud, the latest received message is saved there.

[0036] The beneficial effects of this invention are as follows:

[0037] The state synchronization method and apparatus for edge computing scenarios provided by this invention link with the previous instruction or data by using the previous record check code information and the added check code information in each message. This increases the reliability of the cloud storage state. At the same time, mutual information confirmation is only performed at the receiving end, eliminating the need for frequent data interaction, reducing network overhead, lowering cloud pressure, making operations and states traceable, and improving system reliability. Detailed Implementation

[0038] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0039] This invention mainly comprises a cloud management plane (hereinafter referred to as the cloud) and edge nodes (hereinafter referred to as the edge side). State synchronization includes, but is not limited to, the state of nodes and the application states on the nodes.

[0040] A state synchronization method for edge computing scenarios, specifically,

[0041] Record tables are configured on both the cloud and edge sides. Each record in the table includes the verification code information of the previous record, the type information of the current record, the status or operation information of the current record, the time information, and the verification code information; as shown in Table 1 below:

[0042] Table 1

[0043] Previous record verification Record type Status / Operation Timestamp check

[0044] Previous record verification: This is the verification code information for the previous record. Initially, the current field in the first record is empty.

[0045] Record type: status, operation, etc., used to identify the type of the current information record;

[0046] Status / Operation: Used to record current status information or operation instructions;

[0047] Timestamp: Used to record the time when the current state changes or an operation reaches the edge;

[0048] Verification: This is the verification code information for this entry, used to prevent tampering and also as an identifier for the current record.

[0049] When generating a new message, the cloud or edge side extracts the checksum information of the previous message from the record table and places it in the header of the message to be generated, i.e., the checksum information of the previous record. At the same time, the cloud or edge side generates a unique checksum in the newly generated message, which is different from other checksum information. When the cloud or edge side sends the message, the message is recorded at the corresponding end, so the checksum information in the record table is a unique checksum.

[0050] This creates a linked list within the record table that can be traced backwards (data is generated from bottom to top, with the initial data at the bottom), as shown in Table 2:

[0051] Table 2

[0052]

[0053] When the generated data fails to be received due to reasons such as reception failure, the chain within the record table is as shown in Table 3 below:

[0054] Table 3

[0055]

[0056] The specific reasons for the formation of Table 3 will be described below.

[0057] Because the cloud and edge have different functions, the cloud generally sends control commands to the edge and receives feedback and status change information sent by the edge, while the edge receives instructions from the cloud and generally only sends status information to the cloud.

[0058] When the latest record in the record table is sent from the cloud or edge to the other side, the cloud or edge matches the check code information of the previous record in the latest received record with the check code information of the most recent record in the record table. If the match is successful, the cloud or edge records the record.

[0059] Since each new message is sent to the other side, barring unforeseen circumstances, the checksum information of the previous record in each message in the record table will be the same as the checksum information of the preceding message. Specifically,

[0060] For example, initialization records are generated on the edge side. The edge side and cloud records are as follows:

[0061] Edge-side recording:

[0062] Previous record verification Record type Status / Operation Timestamp check operate create 1665370520000 6ac8o877abdc

[0063] Cloud records:

[0064] Previous record verification Record type Status / Operation Timestamp check

[0065] The edge device initiates a registration request and carries the initialization record. The cloud executes the processing logic and saves the edge device's initialization record. The edge device and cloud records are as follows:

[0066] Edge-side recording:

[0067] Previous record verification Record type Status / Operation Timestamp check operate create 1665370520000 6ac8o877abdc

[0068] Cloud records:

[0069] Previous record verification Record type Status / Operation Timestamp check operate create 1665370520000 6ac8o877abdc

[0070] Upon receiving the registration response from the cloud, the edge device generates status change information based on the verification code information from the previous entry, and generates new verification code information, which is then recorded and stored. At this point, the records from the edge device and the cloud are as follows:

[0071] Edge-side recording:

[0072] Previous record verification Record type Status / Operation Timestamp check 6ac8o877abdc state running 1665370525000 0a1c5324d45c operate create 1665370520000 6ac8o877abdc

[0073] Cloud records:

[0074] Previous record verification Record type Status / Operation Timestamp check operate create 1665370520000 6ac8o877abdc

[0075] The edge device sends the latest record to the cloud. After receiving the information, the cloud checks if the checksum of the previous record in the received information matches the checksum of the previously recorded information. At this point, the received information is saved. The records on the edge device and the cloud are as follows:

[0076] Edge-side recording:

[0077] Previous record verification Record type Status / Operation Timestamp check 6ac8o877abdc state running 1665370525000 0a1c5324d45c operate create 1665370520000 6ac8o877abdc

[0078] Cloud records:

[0079] Previous record verification Record type Status / Operation Timestamp check 6ac8o877abdc state running 1665370525000 0a1c5324d45c operate create 1665370520000 6ac8o877abdc

[0080] When a state transition occurs, the information generation process is similar to the initial process. A state transition refers to any state changes and operations other than the first record. State transitions can be initiated from the edge or the cloud. At the edge, it is common to report state changes, such as when an application exits abnormally or a node experiences a network failure. At the cloud, it is common to initiate operations, such as restarting or stopping.

[0081] When an application is created, its initial state is "creating." This process involves necessary preparations (such as program download, image download, and configuration download). Once ready, the application can run successfully, and its state will be "running." The normal information exchange process between the edge and the cloud is as follows:

[0082] The edge side generates a new record based on the information in the record table. At this point, the record table is:

[0083] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0084] Cloud records:

[0085] Previous record verification Record type Status / Operation Timestamp check 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0086] The edge side records and sends newly generated information to the cloud. The cloud checks if the checksum information of the previous record reported by the edge side matches the already recorded checksum information. The cloud then saves the information reported by the edge side. At this point, the edge side and cloud records are as follows:

[0087] Edge-side recording:

[0088] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0089] Cloud records:

[0090] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0091] If the verification code information of the previous record received in the cloud or edge does not match the already recorded verification code information, the unmatched information is sent to the other side, and the record table information is synchronized simultaneously. During the record table information synchronization, the other side can perform corresponding processing according to its settings.

[0092] If the receiving end is an edge side, the edge side will sequentially match the checksum information of the previous record in the latest received message with the checksum information already recorded on that side. If a match fails at the edge side, the edge side will send the unmatched message to the cloud and also send the most recent message in the record table before the latest message received by the edge side to the cloud. The cloud will generate a new instruction message based on the checksum information of the most recent message in the record table received from the edge side and send the instruction message to the edge side. The edge side will then match the received previous record checksum information with the checksum information of the most recent message in the record table. The record table is a cascaded record structure, where the most recent message refers to the record closest to the latest message in time, not necessarily the initial record.

[0093] When the record table on the edge side is missing, for example, if the cloud generates an operation to restart the edge side, the cloud generates new information based on the checksum information in the record table and records it. At this time, the records on the edge side and the cloud are as follows:

[0094] Edge-side recording:

[0095] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0096] Cloud records:

[0097] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0098] Due to network issues, the restart information did not reach the edge side. Since the cloud typically sends operation commands to the edge side, if the command arrives, the edge side will generate status change information and return it to the cloud. Therefore, if the cloud does not receive feedback within a given time, it will regenerate the restart command information for the edge side, and record the restart operation information again. At this point, the records from the edge side and the cloud are as follows:

[0099] Edge-side recording:

[0100] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0101] Cloud records:

[0102] Previous record verification Record type Status / Operation Timestamp check 73ba9oa9o0d4 operate restart 1665771685000 oa9o0d473ba9 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0103] If the edge receives a resent message (the previous record's checksum is 73ba9oa9o0d4, and the checksum is oa9o0d473ba9), the edge will match the checksum of the previous record of the latest received message (73ba9oa9o0d4). If the match fails, it means that the edge is missing the message and will not record it. In this case, the edge will send the unmatched message to the cloud and send the most recent message in the record table before the latest message was received by the edge, i.e., the previous record's checksum is ba324d45c1c5, and the checksum is 3ba9o24d45c1, to the cloud.

[0104] The cloud generates a new instruction based on the checksum information 3ba9o24d45c1 in the most recent message received from the edge side in the record table, and sends the instruction to the edge side. At this time, the records of the edge side and the cloud are as follows:

[0105] Edge-side recording:

[0106] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0107] Cloud records:

[0108] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 73ba9oa9o0d4 operate restart 1665771685000 oa9o0d473ba9 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0109] The structure of the record table in the cloud at this time is shown in Table 4 below:

[0110] Table 4

[0111]

[0112] The link forks in the dashed boxes in Table 4 caused by missing edge sides will not be added after matching, meaning that new instructions will not be added to the forked links. However, these forked parts can be used as a basis for information analysis.

[0113] The edge device receives information from the cloud. The checksum of the previous record in this information matches the checksum of the most recent record in the edge device's record table. The edge device records this information and performs the corresponding operation. The records from both the edge device and the cloud are as follows:

[0114] Edge-side recording:

[0115] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0116] Cloud records:

[0117] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 73ba9oa9o0d4 operate restart 1665771685000 oa9o0d473ba9 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0118] If a state change occurs at the edge, the process continues as normal, as follows:

[0119] Once the edge operation is complete, it returns status information to the cloud. At this point, the edge generates new information based on the checksum information in the record table, records it, and sends it to the cloud. The records from the edge and the cloud at this time are as follows:

[0120] Edge-side recording:

[0121]

[0122]

[0123] Cloud records:

[0124] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 73ba9oa9o0d4 operate restart 1665771685000 oa9o0d473ba9 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0125] The cloud receives information from the edge and matches the checksum of the previous record with the checksum of the most recent record in the record table. If the match is successful, the cloud records the information. The records from the edge and the cloud are as follows:

[0126] Edge-side recording:

[0127] Previous record verification Record type Status / Operation Timestamp check ba9oa9o730d4 state running 1665771687000 83ba924d45c0 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0128] Cloud records:

[0129] Previous record verification Record type Status / Operation Timestamp check ba9oa9o730d4 state running 1665771687000 83ba924d45c0 3ba9o24d45c1 operate restart 1665771686000 ba9oa9o730d4 73ba9oa9o0d4 operate restart 1665771685000 oa9o0d473ba9 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0130] When the receiving end is at the edge and the sending end is in the cloud, during the synchronization of record table information,

[0131] If the receiving end is the edge side, the edge side will sequentially match the previous record check code information in the latest received message with the check code information already recorded on that side. If the edge side is successful in matching, it is equivalent to successfully matching the previous record check code information of the latest received message in the middle position of the record table (for information synchronization, it must be different from the previous record check code information in the record table or the previous record check code information in the header of the table). Then the edge side records the latest message and sends the content between the successfully matched information in the record table and the latest message to the cloud, where it is recorded.

[0132] For example, if an application on the edge crashes after running for a period of time and then immediately restarts, the edge device detects the change and generates a new record. Due to network issues, the state is not synchronized to the cloud. In this case, the records on the edge and the cloud are as follows:

[0133] Edge-side recording:

[0134] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0135] Cloud records:

[0136] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0137] Since the edge sends informational commands, no feedback is generally required. Therefore, if there is no information exchange between the two parties, the records on both the edge and the cloud will remain unchanged until the next piece of information is generated. For example:

[0138] The cloud generates and records the application command to restart the edge side. Simultaneously, the cloud sends this command information to the edge side. At this point, the edge side and the cloud record the following:

[0139] Edge-side recording:

[0140] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0141] Cloud records:

[0142]

[0143]

[0144] The edge side receives the latest information generated by the cloud (the previous record's checksum information is 3ba9o24d45c1, and the checksum information is 73ba9oa9o0d4) and checks whether the previous record's checksum information in this information matches the checksum of the already recorded previous record (24d070ba9o24). The edge side continues to match the previous record's checksum information (3ba9o24d45c1) downwards. If a match is found, the edge side's record will have the previous record's checksum information of 3ba9o24d45c1 and checksum information of a324d073b454. If the cloud operation finds a conflict, it proves that the cloud's record table is missing. The edge side then sends the unmatched information to the cloud. The edge side sends the information in the record table up to and including the information matching the previous record's checksum information in the latest received message. Specifically, the information in the edge side's record table with previous record checksum information a324d073b454 and checksum 24d070ba9o24, and the information with previous record checksum information 3ba9o24d45c1 and checksum a324d073b454, are sent to the cloud. At this point, the records on the edge side and in the cloud are as follows:

[0145] Edge-side recording:

[0146] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0147] Cloud records:

[0148] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0149] Edge-side recording:

[0150] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0151] Cloud records:

[0152] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 3ba9o24d45c1 operate restart 1665771682000 73ba9oa9o0d4 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0153] The cloud can regenerate instruction information based on the previous record check code information in the information sent by the edge side and send it to the edge side. At this time, the generated information is the same as the previous record check code information in the record table of the edge side.

[0154] When synchronizing record table information

[0155] If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If no match is found in the cloud, the cloud will send the unmatched message to the edge side and send the most recent message in the record table before the latest message received by the cloud to the edge side. The edge side will then match the previous record checksum information in the most recent message in the record table received from the cloud with the information in its own record table. The edge side will send the information in its record table up to the one that matches the previous record checksum information in the most recent message in the record table of the cloud to the cloud for recording. In other words, the edge side sends the range of previous record checksum information received from the cloud, including the latest message generated by the edge side, to the cloud (excluding the most recent message in the record table of the cloud, as it has already been recorded by both the edge side and the cloud). In this way, the cloud can record the latest message generated by the cloud and other relevant information in sequence.

[0156] For example, if an application on the edge side experiences an abnormal restart after running for a period of time, the edge side will detect the change and generate a new record. Due to network issues, the state may not be synchronized to the cloud. In this case, the edge side and cloud records will look like the following:

[0157] Edge-side recording:

[0158] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0159] Cloud records:

[0160]

[0161]

[0162] Due to a communication issue, the cloud did not receive the previous record's verification code information 3ba9o24d45c1 and a324d073b454 until the edge side resent the information. For example, after the application on the edge side successfully restarted, the edge side received the changes sent by the edge side and generated a new record. At this point, the records on the edge side and the cloud are as follows:

[0163] Edge-side recording:

[0164] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0165] Cloud records:

[0166] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0167] The edge device synchronizes the latest records to the cloud. The cloud receives the latest information (the previous record's checksum is a324d073b454, and the checksum is 24d070ba9o24) and checks if the checksum of the previous record in this information matches the checksum of the already recorded previous information (3ba9o24d45c1) or any other checksum in the cloud's record table. This conflict indicates a missing record in the cloud's record table. The cloud then sends the checksum of the most recent record before the received information (ba324d45c1c5) and the checksum of the latest information's previous record (a324d073b454) as the record intervals ba324d45c1c5 and a324d073b454 to the edge device to retrieve the missing record.

[0168] The edge device receives the missing record intervals ba324d45c1c5 and a324d073b454 from the cloud. It searches its local records and finds records matching these intervals. The edge device then sends these records to the cloud. The cloud receives and saves the records. At this point, the records on the edge device and in the cloud are as follows:

[0169] Edge-side recording:

[0170]

[0171]

[0172] Cloud records:

[0173] Previous record verification Record type Status / Operation Timestamp check a324d073b454 state running 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0174] After receiving the information, the cloud modifies the identifier to point to the latest record, and the cloud and edge devices complete the information synchronization.

[0175] When synchronizing record table information

[0176] If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If the cloud finds a match, it means that the edge side is missing. Since the edge side generally receives instruction information, and if the cloud sends information to the edge side, it will affect the operation of the edge side, the cloud only saves the latest message received from the edge side. Whether the cloud needs to send information to change the operating status of the edge side is determined by the control system or the operator. Thus, when the cloud generates a new instruction or receives new status information, the new information will still generate a chain record based on the previous record checksum information of the edge side.

[0177] Initially, the edge side did not receive the two operation messages sent by the cloud. At this time, the edge side and the cloud recorded the following:

[0178] Edge-side recording:

[0179] Previous record verification Record type Status / Operation Timestamp check ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0180] Cloud records:

[0181] Previous record verification Record type Status / Operation Timestamp check a324d073b454 operate config 1665770579500 24d070ba9o24 3ba9o24d45c1 operate config 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0182] When the edge-side status changes, the previous record's checksum information is generated as 3ba9o24d45c1, and the checksum information is generated as 204a5675b353. At this time, the records on the edge side and the cloud are as follows:

[0183] Edge-side recording:

[0184] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 state exit 1665770579000 204a5675b353 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0185] Cloud records:

[0186] Previous record verification Record type Status / Operation Timestamp check a324d073b454 operate config 1665770579500 24d070ba9o24 3ba9o24d45c1 operate config 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0187] At this point, since the checksum of the previous record for the latest message received by the cloud is 3ba9o24d45c1, which cannot match the already recorded checksum of the previous record a324d073b454, the search continues downwards and finds 3ba9o24d45c1 in the cloud's record table. This indicates that the information sent by the cloud after this message was not received at the edge. Therefore, the received information sent by the edge should be recorded. The records at the edge and cloud are as follows:

[0188] Edge-side recording:

[0189] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 state exit 1665770579000 204a5675b353 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0190] Cloud records:

[0191] Previous record verification Record type Status / Operation Timestamp check 3ba9o24d45c1 operate config 1665770579000 204a5675b353 a324d073b454 operate config 1665770579500 24d070ba9o24 3ba9o24d45c1 state exit 1665770579000 a324d073b454 ba324d45c1c5 state running 1665770532000 3ba9o24d45c1 073ba9o7a1dc state creating 1665770531000 ba324d45c1c5 operate create 1665770520000 073ba9o7a1dc

[0192] When new information is generated in the cloud or at the edge, the checksum of the previous record is 204a5675b353, ensuring the integrity of the record table link.

Claims

1. A state synchronization method in an edge computing scenario, characterized in that: Record tables are configured on both the cloud and edge sides. Each record in the record table includes the verification code information of the previous record, the type information of the current record, the status or operation information of the current record, the time information, and the verification code information. The checksum information in the record table generated in the cloud or edge is a unique checksum. When the latest record in the record table is sent from the cloud or edge to the other side, the cloud or edge matches the checksum of the previous record in the latest record with the checksum of the most recent record in the record table before the latest record was received. If the match is successful, the cloud or edge records the record; if the match is unsuccessful, the unmatched record is sent to the other side and the record table information is synchronized.

2. The state synchronization method in the edge computing scenario according to claim 1, characterized in that: When synchronizing record table information If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received message with the check code information already recorded on that side. If the edge side fails to match, it will send the message that failed to match again to the cloud and send the most recent message in the record table before the edge side received the latest message to the cloud. The cloud will generate new instruction information based on the check code information in the most recent message in the record table received from the edge side and send the instruction information to the edge side.

3. The state synchronization method in the edge computing scenario according to claim 1, characterized in that: If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received information with the check code information already recorded on the edge side. If the match is successful on the edge side, the edge side will record the latest received information and send the latest received information and the information between the latest received information and the successfully matched record in the edge side's record table to the cloud, and the cloud will record it.

4. The state synchronization method in the edge computing scenario according to claim 1, characterized in that: When synchronizing record table information If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If no match is found in the cloud, the cloud will send the unmatched message to the edge side and send the most recent message in the record table before the latest message received by the cloud to the edge side. The edge side will then match the previous record checksum information in the most recent message in the cloud's record table with the information in its own record table. The edge side will then send all the information in its record table up to the one that matches the previous record checksum information in the most recent message in the cloud's record table to the cloud for recording.

5. The state synchronization method in the edge computing scenario according to claim 4, characterized in that: When synchronizing record table information The receiving end will match the previous record's checksum information in the latest received message with the checksum information already recorded on that side. If the match is successful in the cloud, the latest received message will be saved in the cloud.

6. A state synchronization device for edge computing scenarios, characterized in that: Including the cloud and edge sides, Record tables are configured on both the cloud and edge sides. Each record in the record table includes the verification code information of the previous record, the type information of the current record, the status or operation information of the current record, the time information, and the verification code information. The checksum information in the record table generated in the cloud or edge is a unique checksum. When the latest record in the record table is sent from the cloud or edge to the other side, the cloud or edge matches the checksum of the previous record in the latest record with the checksum of the most recent record in the record table before the latest record was received. If the match is successful, the cloud or edge records the record; if the match is unsuccessful, the unmatched record is sent to the other side and the record table information is synchronized.

7. The state synchronization device for edge computing scenarios according to claim 6, characterized in that: When synchronizing record table information If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received message with the check code information already recorded on that side. If the edge side fails to match, it will send the message that failed to match again to the cloud and send the most recent message in the record table before the edge side received the latest message to the cloud. The cloud will generate new instruction information based on the check code information in the most recent message in the record table received from the edge side and send the instruction information to the edge side.

8. The state synchronization device for edge computing scenarios according to claim 6, characterized in that: When synchronizing record table information If the receiving end is the edge side, the edge side will match the previous record check code information in the latest received information with the check code information already recorded on the edge side. If the match is successful on the edge side, the edge side will record the latest received information and send the latest received information and all information between the latest received information and the successfully matched record in the edge side's record table to the cloud, where the cloud will also record it.

9. The state synchronization device for edge computing scenarios according to claim 6, characterized in that: When synchronizing record table information If the receiving end is the cloud, the cloud will sequentially match the previous record checksum information in the latest received message with the checksum information already recorded on that side. If no match is found in the cloud, the cloud will send the unmatched message to the edge side and send the most recent message in the record table before the latest message received by the cloud to the edge side. The edge side will then match the previous record checksum information in the most recent message in the cloud's record table with the information in its own record table. The edge side will then send all the information in its record table up to the one that matches the previous record checksum information in the most recent message in the cloud's record table to the cloud for recording.

10. The state synchronization device for edge computing scenarios according to claim 9, characterized in that: When synchronizing record table information The receiving end will match the previous record's checksum information in the latest received message with the checksum information already recorded on that side. If the match is successful in the cloud, the latest received message will be saved in the cloud.

Images