Ilink protocol-based cloud-edge bidirectional data synchronization method in internet of things operating system

Abstract

The application discloses a kind of cloud edge two-way data synchronization methods based on iLink protocol in Internet of Things operating system, comprising the following steps: step one, sender suspends service and sends synchronization request to receiver;Step two, after receiving the synchronization request;Step three, sender synchronization starts;Step four, receiver confirms synchronization start;Step five, sender enters synchronization state;Step six, receiver confirms to receive synchronization instruction;Step seven, receiver carries out transaction submission after receiving data;Step eight, receiver responds to synchronization success, completes sender and receiver synchronization operation.The data synchronization method of the application, through the setting of step one to step eight, can effectively realize the data synchronization between sender and receiver, and can effectively handle synchronization conflict operation.

Description

Technical Field

[0001] This invention relates to a cloud-edge synchronization method, and more specifically to a cloud-edge bidirectional data synchronization method based on the iLink protocol in an Internet of Things (IoT) operating system. Background Technology

[0002] Data synchronization typically refers to synchronization between master and slave nodes. For example, in Redis cluster mode, the master node synchronizes data to the slave node through the psync command, and MySQL synchronizes through Binlog. These synchronization methods can only perform one-way synchronization. They are more of a technical means and therefore cannot be directly used in business scenarios.

[0003] The closest scenario is a phone firmware update. The phone can be understood as an edge service with certain edge computing capabilities. Developers will push upgrade instructions to the phone through firmware updates to fix problems or add new features. During the upgrade process, the phone actively requests to download the upgrade package from the developer's server. However, this scenario is only a one-way process.

[0004] For example, patent number 2020108481289, entitled "A Cloud-Edge Collaboration Method and System," discloses steps S1 to S5. These steps aim to achieve edge-cloud synchronization. However, the data synchronization achieved by this method is primarily unidirectional, which cannot meet the needs of IoT scenarios requiring cloud-edge collaboration. A similar scenario involves mobile phone firmware updates, where the initiating end must be on a public network for the receiving end to download the upgrade package. Therefore, if this method is modified, the cloud server cannot solve the network problem of downloading data packets from the edge. Furthermore, mobile phone firmware updates are typically performed in a well-connected home Wi-Fi environment, while IoT edge service networks are often poor, typically only supporting 4G or even 3G signals. This can lead to data loss and is highly sensitive to data packet size. Summary of the Invention

[0005] To address the shortcomings of existing technologies, the present invention aims to provide a cloud-edge bidirectional data synchronization method based on the iLink protocol in an IoT operating system, thereby solving the aforementioned problems.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a cloud-edge bidirectional data synchronization method based on the iLink protocol in an IoT operating system, comprising the following steps:

[0007] Step 1: The sender pauses its service and sends a synchronization request to the receiver;

[0008] Step 2: After receiving the synchronization request, the receiver pauses the service and then responds that synchronization is ready.

[0009] Step 3: Synchronization begins on the sender side;

[0010] Step four: The receiver confirms the start of synchronization;

[0011] Step 5: The sender enters the synchronization state and transmits data to the receiver;

[0012] Step 6: The receiver confirms receipt of the synchronization instruction, begins synchronization, and sends a synchronization conflict instruction to the sender when a synchronization conflict occurs on the receiver. The sender then handles the synchronization conflict.

[0013] Step 7: After receiving the data, the receiver commits the transaction and resumes operation from the paused service state. The sender waits for the synchronization completion instruction and ends the synchronization after receiving the synchronization completion instruction and timeout.

[0014] Step 8: The receiver responds that synchronization is successful, completing the synchronization operation between the sender and receiver;

[0015] In the process of synchronization, if any anomaly occurs, whether on the sender or receiver, synchronization is terminated by sending a synchronization interruption command. The sender cannot send the next stage command until it receives a response. After the sender sends the synchronization interruption command, the synchronization task ends and it resumes from the paused state without waiting for a response. After the receiver sends the synchronization interruption command, it will respond to the interruption with other commands until it receives the synchronization end command, and finally resumes from the paused state. After the sender receives the synchronization interruption, it stops synchronization, immediately sends the synchronization end command, and resumes from the paused state. After the receiver receives the synchronization interruption, it ends the synchronization, rolls back the transaction, and resumes from the paused state.

[0016] As a further improvement of the present invention, the abnormal situations that occur during the synchronization include the sender not receiving a response after a timeout, the receiver not receiving an instruction after a timeout, the receiver receiving an incorrectly expected instruction, the sender receiving an incorrectly expected response, and the receiver being unable to process the synchronization task.

[0017] As a further improvement of the present invention, the basic format of communication between the sender and the receiver includes: the type of the current instruction, the unique ID of the current instruction, the version of the current instruction, the specific content of the current instruction, and the response characters.

[0018] As a further improvement of the present invention, the synchronous interrupt instruction format includes, in addition to the basic format, the ID of the currently ongoing synchronous task, the error code of the failure, and related prompts for the failure.

[0019] As a further improvement of the present invention, the synchronization request instruction sent by the sender includes the ID of the currently ongoing synchronization task in addition to the basic format.

[0020] As a further improvement of the present invention, the instruction format in the sender synchronization includes, in addition to the basic format, the name of the entity category to be synchronized, the current page number, the number of pages per page, the total number of pages, the total amount of data, and the specific data structure of the corresponding synchronization entity.

[0021] As a further improvement of the present invention, the instruction format for synchronization conflicts of the receiver includes, in addition to the basic format, the entity categories that need to resolve conflicts and the data indicating which IDs need to resolve conflicts. As a further improvement of the present invention, each instruction sent by the sender will have a corresponding response from the receiver. If the sender does not receive a response after the response timeout period, the sender retransmits the instruction. If the number of retransmissions exceeds the maximum number of retransmissions, synchronization is determined to have failed, indicating an abnormality in the sender's failure to receive a response within the timeout period. The sender then sends a synchronization interrupt instruction. After receiving the initial synchronization instruction, the receiver starts a timer for the current synchronization task. If, before receiving the synchronization task completion instruction, the receiver does not receive a synchronization instruction after the synchronization timeout period, synchronization is determined to have failed, indicating an abnormality in the receiver's failure to receive an instruction within the timeout period. The receiver then sends a synchronization interrupt instruction.

[0022] The beneficial effects of this invention are that, through the settings of steps one to eight, data synchronization between the sender and the receiver can be effectively achieved. When an anomaly occurs during synchronization, the sender cannot send the next stage instruction until a response is received. This allows the sender to have sufficient processing resources, and then the synchronization conflict can be effectively handled through subsequent processing. Compared with the methods in the prior art, data is less likely to be lost and is less sensitive to the size of the data packet. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system of this invention. Detailed Implementation

[0024] The present invention will now be described in further detail with reference to the embodiments shown in the accompanying drawings.

[0025] Terminology Explanation:

[0026] iLink: The iLink protocol is a data exchange protocol designed by Instruction Set Intelligent Technology Co., Ltd. for the Internet of Things (IoT) development field. It uses JSON format for bidirectional communication between devices and the IoT operating system. The device organizes data according to the specification and sends it to the iSysCore OS IoT operating system. iSysCore OS can directly process this data, enabling data interaction between the device and iSysCore OS.

[0027] Cloud-edge: Cloud refers to central computing services deployed on the public network or privately deployed within a local area network. It generally has large hardware resources and the ability to process massive amounts of data. In this invention, it specifically refers to the iSysCore OS IoT operating system. Edge refers to edge computing services deployed close to the device side to process data from the device. Generally speaking, hardware resources are limited and the network environment may fluctuate occasionally. In this invention, it specifically refers to the instruction set edge gateway.

[0028] Two-way data synchronization: In IoT application scenarios, it is often necessary to use cloud-edge collaboration capabilities to view, manage, and maintain edge devices in different regions on a central server. Since edge services are usually deployed on-site, a method is needed to synchronize the computing rules of the cloud to the edge services. In addition, valuable data on-site also needs to be synchronized to the cloud. This method is called two-way data synchronization.

[0029] Reference Figure 1 As shown in this embodiment, a cloud-edge bidirectional data synchronization method based on the iLink protocol in an IoT operating system includes the following steps:

[0030] Step 1: The sender pauses its service and sends a synchronization request to the receiver;

[0031] Step 2: After receiving the synchronization request, the receiver pauses the service and then responds that synchronization is ready.

[0032] Step 3: Synchronization begins on the sender side;

[0033] Step four: The receiver confirms the start of synchronization;

[0034] Step 5: The sender enters the synchronization state and transmits data to the receiver;

[0035] Step 6: The receiver confirms receipt of the synchronization instruction, begins synchronization, and sends a synchronization conflict instruction to the sender when a synchronization conflict occurs on the receiver. The sender then handles the synchronization conflict.

[0036] Step 7: After receiving the data, the receiver commits the transaction and resumes operation from the paused service state. The sender waits for the synchronization completion instruction and ends the synchronization after receiving the synchronization completion instruction and timeout.

[0037] Step 8: The receiver responds that synchronization is successful, completing the synchronization operation between the sender and receiver;

[0038] In this process, if any anomaly occurs during synchronization, whether on the sender or receiver side, synchronization is terminated by sending a synchronization interruption command. The sender cannot send the next stage command until it receives a response. After sending the synchronization interruption command, the synchronization task ends and resumes from the paused state without waiting for a response. After sending the synchronization interruption command, the receiver will respond to the interruption with other commands until it receives the synchronization end command, and finally resumes from the paused state. After receiving the synchronization interruption, the sender stops synchronization, immediately sends the synchronization end command, and resumes from the paused state. After receiving the synchronization interruption, the receiver ends synchronization, rolls back the transaction, and resumes from the paused state. In this embodiment, the sender and receiver can be either cloud services or edge services, and their roles can be interchanged. They use the same algorithm to implement the bidirectional data synchronization method. The only major difference is that when the sender of the synchronization is a cloud service, the synchronization process will not have conflicts because for edge computing services, it will only receive commands from one cloud service.

[0039] The iLink protocol ensures data packet compression during transmission between cloud services and edge services, achieving efficient communication. Meanwhile, the iSysCore OS operating system can also perform message tracking, facilitating message tracing.

[0040] The specific data structure of this embodiment is as follows:

[0041] Messages used for communication between the sender and receiver follow the basic format below, and the content is serialized in JSON format when the message is sent.

[0042]

[0043] The synchronization interruption command terminates synchronization if any exception occurs during the synchronization process, whether on the sender or receiver.

[0044]

[0045]

[0046] Sender Synchronization Request Command

[0047] The sender enters a pause state, and the receiver enters a pause state after receiving the data. If the data is being synchronized from the edge to the cloud, the edge device needs to obtain the synchronization ID from the cloud via the iLink protocol FETCH_SYNC_ID, and the cloud guarantees the uniqueness of the ID. If the data is being synchronized from the cloud to the edge device, this step is not required.

[0048]

[0049] Receiver responds to synchronization ready command

[0050] If synchronization cannot be processed at present, a synchronization interruption will be triggered, and the operatorId corresponds to SYNC_ASK.

[0051]

[0052] Sender Synchronization Start Command

[0053] The data contains the entity classes and quantities that need to be synchronized. The receiver begins the transaction upon receiving the data.

[0054]

[0055] The receiver confirms the synchronization start command.

[0056]

[0057] Sender Synchronization Command

[0058] It's important to control message body size and dependencies. Only one type of data can be sent at a time. `current`, `size`, `pages`, and `total` are fields to help understand the fragmentation process.

[0059]

[0060]

[0061] The receiver confirms that the received synchronization message instruction operatorId is the same as the corresponding SYNC_ING, or the same as SYNC_CONFIRM.

[0062]

[0063] Receiver Synchronization Conflict Command

[0064] The `operateId` is the same as the corresponding `SYNC_ING`. The logic for a conflict is that the business ID corresponding to the entity class already exists.

[0065]

[0066] Sender handles synchronization conflict instructions

[0067] The operateId is the same as the corresponding SYNC_CONFLICT (which is also the same as the initial SYNC_ING, meaning the operateId remains unchanged throughout the conflict handling process). The user chooses to modify the service ID or overwrite it. If an interruption and rollback are required, the sender sends an interruption message. The override set contains the IDs to be overwritten, and the update set contains the original primary key as the key and the new primary key to be modified as the value. If there are still conflicts after the response, the SYNC_CONFLICT and SYNC_CONFIRM processes are repeated.

[0068]

[0069] Sender Synchronization End Command

[0070] After receiving the data, the receiver commits the transaction and resumes operation from the paused state. The sender waits for SYNC_OK and terminates after a timeout.

[0071]

[0072] The receiver responds with a synchronization success command.

[0073] The operateId corresponds to SYNC_END. If the number does not match, the receiver rolls back and sends a synchronization interrupt. The syncId corresponds to the original SYNC_ASK.

[0074]

[0075] rule

[0076] 1. The sender must send instructions sequentially.

[0077] The sender cannot send the next stage command until it receives a response.

[0078] II. After the sender's synchronization is interrupted

[0079] End the synchronization task and resume from paused state without waiting for a response.

[0080] III. After the receiver sends a synchronization interruption

[0081] Until the SYNC_END command is received, all other messages respond to the interruption, and the system eventually resumes from the paused state.

[0082] IV. After the sender receives a synchronization interruption

[0083] Stop synchronization, immediately send SYNC_END to resume from the paused state.

[0084] V. After the receiver receives a synchronization interruption

[0085] End synchronization, roll back the transaction, and resume from the paused state.

[0086] Exception handling

[0087] Sender timed out without receiving response error

[0088] For every instruction sent by the sender, there is a corresponding response from the receiver. They have the same operatorId, and their correspondence is as follows:

[0089] SYNC_ASK SYNC_READY SYNC_START SYNC_ACK SYNC_ING SYNC_RECV or SYNC_CONFLICT SYNC_CONFIRM SYNC_RECV SYNC_END SYNC_OK

[0090] According to rule one, if no response is received within ACK_TIMEOUT (waiting timeout period), the sender will retransmit. If the number of retries exceeds MAX_RETRY (maximum number of retries), the synchronization is considered to have failed, and the sender will send a synchronization interrupt command.

[0091] Because of the retransmission mechanism, the receiver may encounter three situations each time. The first is the instruction for the next stage, which is the normal process. The second is the instruction for the current stage, which is the retransmission process. Therefore, the receiver needs to temporarily save the operatorId of the current stage for comparison. The third is the instruction for synchronization interruption, in which the sender actively terminates the synchronization process.

[0092] Receiver timed out and did not receive instruction.

[0093] Upon receiving the SYNC_ASK instruction (the initial synchronization instruction), the receiver starts a timer for the current synchronization task. If no synchronization instruction is received within SYNC_TIMEOUT before the synchronization task completes, synchronization is considered to have failed, and the receiver sends a synchronization interrupt instruction. Theoretically, SYNC_TIMEOUT should be greater than ACK_TIMEOUT * MAX_RETRY configured by the sender. If other instructions are encountered, the timer is reset.

[0094] If the receiver encounters a conflict, the user needs to manually decide how to handle it. That is, after responding to SYNC_CONFIRM, the timer should be extended to a longer value to give the user sufficient time to handle it. After the user has finished handling it, the receiver should send the SYNC_CONFIRM instruction to reset and resume the timer.

[0095] Since the only situation requiring user conflict resolution currently involves synchronization from the edge device to the cloud, if the edge device crashes or loses connection for other reasons while waiting for cloud user resolution, the cloud can detect the edge device's offline status and interrupt the synchronization task.

[0096] The receiver received an error indicating an incorrect expected instruction.

[0097] Because of Rule 1, this situation should not theoretically occur. It will only encounter the three situations listed in 6.4.1. If it does, the receiver cannot process it normally, so it can be discarded directly.

[0098] This anomaly is more likely to occur in the cloud, because the cloud may be processing multiple synchronous tasks at the same time. In this case, the instructions from different edge devices may be misallocated during logical processing. If the instructions are discarded, the edge device can simply resend them if it times out and does not receive a response.

[0099] The sender received an error in the expected response.

[0100] The error expectation mentioned here mainly refers to the situation where the operatorId of the response does not match the operatorId of the currently sent command, and the sender needs to consume retries to resend the current command.

[0101] Since it is a response from the receiver, it cannot be discarded directly and must be processed. Otherwise, the receiver will time out and terminate the synchronization task. Therefore, if the operations do not match, it is necessary to resend.

[0102] The receiver is unable to handle synchronization task exceptions.

[0103] The opposite of SYNC_READY, which allows synchronization to begin, is a relatively rare scenario. If the edge device is undergoing firmware updates or other processes, it may be unable to handle the synchronization task. In such cases, the receiver needs to send a synchronization interruption command to terminate the synchronization.

[0104] In summary, the cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system of this embodiment can handle synchronization conflicts during the data synchronization process, effectively solving the problems of easy data loss and sensitivity to data packet size in the prior art.

[0105] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A cloud-edge bidirectional data synchronization method based on an iLink protocol in an Internet of Things operating system, characterized in that: The iLink protocol is an IoT-specific data exchange protocol using JSON format, which supports message tracking and data compression. The sender and receiver are either the iSysCoreOS IoT operating system cloud service or the instruction set edge gateway, respectively. Their roles are interchangeable and they use the same synchronization algorithm. The method includes the following steps: Step 1: The sender suspends the corresponding business service, generates a unique synchronization task ID, and sends a SYNC_ASK synchronization request command containing the synchronization task ID to the receiver; if the sender is an edge gateway, it needs to obtain the globally unique synchronization task ID from the cloud through the iLink protocol first. Step 2: After receiving the synchronization request, the receiver suspends the corresponding business service and starts the synchronization transaction, responding to the sender with the SYNC_READY synchronization ready instruction; if the receiver cannot handle the synchronization task, it directly responds with the SYNC_INTERRUPT synchronization interruption instruction. Step 3: After receiving the synchronization ready instruction, the sender sends a SYNC_START synchronization start instruction to the receiver, which includes the type and number of entities to be synchronized. Step four: The receiver confirms the start of synchronization by responding to the sender with a SYNC_ACK confirmation command; Step 5: The sender enters the synchronization state and transmits the SYNC_ING synchronization command to the receiver using a paginated and fragmented method. Each command includes the entity category name, current page number, number of pages, total number of pages, total data volume, and corresponding entity data structure. The sender must wait for the receiver's response after sending each command before sending the next command. Step 6: The receiver acknowledges receipt of each synchronization instruction and responds to the sender with a SYNC_RECV instruction. If the receiver detects a data conflict, it sends a SYNC_CONFLICT synchronization conflict instruction to the sender, which includes the conflict entity category and a list of conflict IDs. After receiving the conflict instruction, the sender generates a SYNC_CONFIRM conflict handling instruction containing an ID modification mapping or overwrite flag according to a preset strategy and sends it to the receiver. This step is repeated until there are no conflicts. Step 7: After the receiver completes all data reception and conflict resolution, it commits the transaction and resumes business services, responding to the sender with a SYNC_OK synchronization success command; the sender waits for the synchronization success command, and if it does not receive it within a timeout, it determines that the synchronization has failed and sends a SYNC_END synchronization end command. Step 8: After receiving the synchronization success instruction, the sender sends the SYNC_END synchronization end instruction to complete the synchronization operation and restore service. In the event of any abnormality during the synchronization process, synchronization is terminated via the SYNC_INTERRUPT command: After the sender sends the synchronization interrupt command, it immediately ends the synchronization task and resumes business services without waiting for a response; after the receiver sends the synchronization interrupt command, it continues to respond to interrupt commands until it receives the SYNC_END command, and finally rolls back the transaction and resumes business services; after the sender receives the synchronization interrupt command, it immediately sends the SYNC_END command and resumes business services; after the receiver receives the synchronization interrupt command, it immediately rolls back the transaction and resumes business services.

2. The cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system according to claim 1, characterized in that: Abnormal situations that may occur during synchronization include the sender not receiving a response after a timeout, the receiver not receiving an instruction after a timeout, the receiver receiving an incorrect instruction, the sender receiving an incorrect response, and the receiver being unable to process the synchronization task.

3. The cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system according to claim 2, characterized in that: The basic format for communication between the sender and receiver includes: the type of the current instruction, the unique ID of the current instruction, the version of the current instruction, the specific content of the current instruction, and the response characters.

4. The cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system according to claim 3, characterized in that: The synchronous interrupt instruction format, in addition to the basic format, also includes the ID of the currently ongoing synchronous task, the error code for failure, and relevant failure prompts.

5. The cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system according to claim 3, characterized in that: The synchronization request instruction sent by the sender includes the ID of the currently ongoing synchronization task in addition to the basic format.

6. The cloud-edge bidirectional data synchronization method based on the iLink protocol in the IoT operating system according to claim 3, characterized in that: The receiver's synchronization conflict instruction format, in addition to the basic format, also includes the entity category that needs to resolve the conflict and which IDs of the data need to be resolved.

Images