A method and apparatus for synchronizing execution of events

Abstract

The embodiment of the present specification discloses a method and device for executing a synchronization event, comprising: when initiating a synchronization event, if it is determined that a first token is not occupied, sending an application token command to other nodes, the application token command being used to apply for the first token; judging whether a transfer token command sent by other nodes is received, the transfer token command being used to send the first token to the current node; if the transfer token command sent by other nodes is not received, creating a second token; if the second token is successfully created, executing the synchronization event according to the second token. The synchronization event execution method of the embodiment of the present specification can effectively solve the data synchronization problem between the Internet of Things sub-device and the server by introducing a token mechanism and a dynamic coordination mechanism, and adapts to the higher requirements of the Internet of Things application on timeliness and synchronization.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method and device for executing synchronous events. Background Technology

[0002] With the development of IoT technology, various IoT base stations are needed between IoT sub-devices and servers to handle protocol conversion between data. However, data synchronization remains a challenge among these self-organizing IoT base stations. Ordinary self-organizing network algorithms can only guarantee the validity of data transmission, but may not guarantee timeliness and synchronization. This is acceptable in situations where data synchronization requirements are not so stringent. However, current IoT applications place higher demands on data timeliness and synchronization. Summary of the Invention

[0003] This specification provides one or more embodiments of a method and apparatus for executing synchronous events, which are used to solve the technical problems mentioned in the background art.

[0004] One or more embodiments of this specification employ the following technical solutions:

[0005] This specification provides one or more embodiments of a method for executing a synchronization event, comprising:

[0006] When initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, and the token request command is used to request the first token;

[0007] Determine whether a token transfer command has been received from another node, wherein the token transfer command is used to send the first token to the current node;

[0008] If no token delivery command is received from another node, a second token is created.

[0009] If the second token is successfully created, the synchronization event is executed based on the second token.

[0010] This specification provides one or more embodiments of a device for executing synchronous events, comprising:

[0011] At least one processor; and,

[0012] A memory communicatively connected to the at least one processor; wherein,

[0013] The memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0014] When initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, and the token request command is used to request the first token;

[0015] Determine whether a token transfer command has been received from another node, wherein the token transfer command is used to send the first token to the current node;

[0016] If no token delivery command is received from another node, a second token is created.

[0017] If the second token is successfully created, the synchronization event is executed based on the second token.

[0018] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0019] This specification's embodiments introduce a token mechanism, using tokens for coordination during synchronization events. This helps solve the data synchronization problem between various IoT base stations in ad hoc networks.

[0020] In the embodiments described in this specification, when a synchronization event is initiated, the current node determines whether it holds the first token. If it does not hold the token, it sends a request for tokens to other nodes. This dynamic request mechanism helps to dynamically acquire tokens when synchronization is needed, avoiding the resource waste that may be caused by static allocation.

[0021] The embodiments in this specification achieve data synchronization by transmitting token commands, allowing other nodes to send the first token to the current node, thereby maintaining token synchronization. This mechanism is highly responsive to requirements for timeliness and synchronization.

[0022] When no token transfer command is received from other nodes, the embodiments in this specification ensure that a second token can be created for synchronization even in the absence of a first token by creating a second token.

[0023] When the second token is successfully created, the embodiments of this specification can execute a synchronization event based on the information of the second token. This helps to ensure that the data between the nodes is synchronized, thereby improving the timeliness and synchronization of data synchronization.

[0024] In summary, the synchronous event execution method in the embodiments of this specification, by introducing a token mechanism and a dynamic coordination mechanism, can effectively solve the data synchronization problem between IoT sub-devices and servers, and adapt to the higher requirements of IoT applications for timeliness and synchronization. Attached Figure Description

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

[0026] Figure 1 A flowchart illustrating a method for executing a synchronization event provided in one or more embodiments of this specification;

[0027] Figure 2 A flowchart for initiating a synchronization event provided in one or more embodiments of this specification;

[0028] Figure 3 This is a schematic diagram of the structure of a device for executing synchronous events, provided for one or more embodiments of this specification. Detailed Implementation

[0029] This specification provides a method and device for executing synchronous events through its embodiments.

[0030] With the development of IoT technology, various IoT base stations are needed between IoT devices and servers to handle protocol conversion between data and network data. This involves various wireless communication technologies such as Wi-Fi, LoRa, BLE, ZigBee, GPS, UWB, 5G, NB-IoT, and RFID. These different wireless communication technologies are categorized by coverage distance into far-field communication (hundreds of meters), mid-field communication (tens of meters), and near-field communication (meters). Furthermore, some frequency bands overlap between different wireless communication technologies, and the frequency range varies from hundreds of MHz to several GHz, requiring different antennas. To reduce EMC interference between these wireless communication technologies, they also need to be differentiated based on their characteristics. Ultimately, this necessitates the targeted design of various IoT base stations to meet different functional requirements. Therefore, it is impossible to integrate all wireless technologies onto a single base station, nor can a single IoT base station achieve large-scale wireless signal coverage. The wireless coverage distance of a single IoT base station varies among different types, resulting in different deployment densities in various scenarios, especially indoors where walls obstruct the communication, significantly reducing the communication distance compared to outdoors.

[0031] Whether deploying the same type of IoT base stations or coordinating different types of IoT base stations, many need to be deployed to collaboratively achieve coverage of various wireless signals within a given area. These IoT base stations need to communicate with each other due to functional or business requirements. Currently, the common approach is a client-server (CS) architecture, where all IoT base stations interface with a server, which then facilitates data exchange. However, this requires additional data exchange servers, a cost that device users are unwilling to bear. Furthermore, this method has relatively low reliability; if the server fails, the entire IoT system is paralyzed. Moreover, the installation and deployment process is complex, and subsequent management and configuration of the data exchange server are also necessary. Therefore, there is an urgent need for a convenient, reliable, and low-cost networking method that allows multiple IoT devices to network and communicate with each other.

[0032] Currently, many IoT base stations with self-organizing network capabilities communicate via wireless signals, such as using the wireless air interface of Wi-Fi chips for data transmission. However, not all wireless chips have an air interface. If a dedicated channel is not available and data is transmitted through a user-supplied channel, it will congest user channel resources and negatively impact user experience. Furthermore, wireless transmission is inevitably hindered by walls in indoor environments, leading to increased deployment density and the potential for signal isolation, ultimately causing self-organizing network failure or increased costs. Therefore, we can leverage wired network communication technologies such as multicast, broadcast, and unicast to assist IoT base stations in self-organizing networks and data exchange. Wired networks themselves do not suffer from signal obstruction issues; regardless of the distance the base stations are deployed, data exchange can ultimately be achieved through the network. Because wired networks have generally been upgraded to support transmission rates of at least 100Mbps, they fully meet the self-organizing network requirements of various IoT base stations without affecting user data transmission.

[0033] However, even after establishing a self-organizing network, the various IoT base stations still face the challenge of data synchronization. Ordinary self-organizing network algorithms can only guarantee the validity of data transmission, but not necessarily its timeliness and synchronization. This is acceptable in situations where data synchronization requirements are not so stringent. However, with the continuous rise of various IoT applications, higher demands are being placed on data timeliness and synchronization. Therefore, a token mechanism can be introduced during the self-organizing network setup to ensure the timeliness and synchronization of data between multiple IoT base stations.

[0034] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0035] Figure 1 This diagram illustrates a flowchart of a method for executing a synchronous event, provided in one or more embodiments of this specification. This process can be executed by the current node in a synchronous event execution system. Certain input parameters or intermediate results within the process can be manually adjusted to help improve accuracy.

[0036] The method flow steps of the embodiments in this specification are as follows:

[0037] S102, when initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, the token request command being used to request the first token.

[0038] This specification's embodiments introduce a token mechanism in an IoT ad hoc network to ensure the timeliness and synchronization of data among multiple IoT base stations. Specifically, when a synchronization event needs to be initiated, the system executes the following steps:

[0039] Checking if the first token is held: Before initiating a synchronization event, the system first checks whether the current node already holds the first token. If it does, synchronization can proceed directly. If it does not, a token acquisition operation is required.

[0040] Sending a request token command to other nodes: When it is determined that it does not possess the first token, the node will send a request token command to other IoT base station nodes. The purpose of this command is to request control of the first token in order to perform synchronization operations.

[0041] The content and format of the token request command: The token request command needs to include relevant information, such as the requester's identity and the type of synchronization event. This information helps other nodes determine whether to agree to give the first token to the current node.

[0042] Waiting for responses from other nodes: After issuing a request for a token, the node needs to wait for responses from other nodes. Other nodes can determine whether to grant the token to the requesting node based on the rules agreed upon by the system.

[0043] Acquiring the first token: If other nodes agree to the request, the current node will gain control of the first token and can then execute synchronization events.

[0044] This process ensures that when a synchronization event is initiated, the system first attempts to acquire control of the first token to ensure the timeliness and synchronization of data among the various IoT base stations in the ad hoc network. This token mechanism can effectively coordinate the behavior of multiple nodes, prevent conflicts and chaos, and thus improve the overall performance and efficiency of the system.

[0045] S104, determine whether a token transfer command has been received from another node, the token transfer command being used to send the first token to the current node.

[0046] S106, if no token transfer command is received from another node, a second token is created.

[0047] In the embodiments of this specification, if the transmission token command sent by another node is received, the synchronization event can be executed based on the first token.

[0048] To determine whether a token transmission command has been received from another node, the current node can perform the following steps when performing a synchronization event:

[0049] Determine if a token delivery command has been received: When a node is preparing to perform a synchronization event, it can first check whether it has received a token delivery command sent by other nodes.

[0050] Handling the case where no token delivery command has been received: If no token delivery command has been received from other nodes, it means that the current node is likely the first node to execute the synchronization event. In this case, a second token needs to be created. Since the first token was not received, the node can create a second token and begin executing the synchronization event.

[0051] It should be noted that the second token is used to distinguish it from the first token. Both the first and second tokens are used for data synchronization and are essentially the same.

[0052] Handling the case of receiving a token transmission command: If a node receives a token transmission command from another node, it means that the other node has already executed the synchronization event, and the current node is the next node to execute the synchronization event. In this case, the node can execute the corresponding synchronization event based on the first token received.

[0053] Execute synchronization event: If the current node receives a token-passing command, it indicates that it is the node's turn to execute the synchronization event. The node can execute the synchronization event based on the first token received, ensuring the timeliness and synchronization of data.

[0054] It's important to note that this process ensures that in a self-organizing network, nodes can determine whether it's their turn to execute a synchronization event based on the token's transmission status. If it's the first node, it will create a second token; if it's a subsequent node, it will execute the synchronization event based on the first token it receives. This mechanism helps ensure synchronization between nodes throughout the entire IoT system.

[0055] Furthermore, in the embodiments described above, before creating the second token, it can be determined whether a first token presentation command sent by another node has been received. The first token presentation command is used by a node to broadcast to other nodes that it has received the first token after receiving it. If a first token presentation command sent by another node has been received, it is determined whether the token application chain contains the current node identifier, where the token application chain is a token application list. If the current node identifier is contained in the token application chain, the process returns to determine whether a token transfer command sent by another node has been received.

[0056] It should be noted that, based on the above information regarding determining whether the first token presentation command has been received from other nodes, the following implementation steps can be derived:

[0057] Determining if the first token presentation command has been received: Before creating the second token, the current node can determine whether it has received the first token presentation command from other nodes. The purpose of the first token presentation command is for the node to broadcast the information that it has received the first token to other nodes after receiving it.

[0058] Handling the case where the first token presentation command has been received: If a node has already received the first token presentation command from another node, it means that another node has already executed a synchronization event and broadcast the first token information. In this case, the node will perform the following sub-steps:

[0059] Determine if the query token request chain contains the current node's identifier: The query token request chain can be a list of token requests that record the chain of requests to other nodes. The node will check if the query token request chain contains the current node's identifier.

[0060] Handling cases where the query token request chain contains the current node's identifier: If the query token request chain contains the current node's identifier, it means that the current node has already expressed its intention in the token request chain. In this case, the node will return to determine whether it has received a token transfer command from another node, and proceed with subsequent steps.

[0061] It should be noted that the above process ensures that before creating a second token, the current node must first determine whether it has received the first token offer command from other nodes, and if it has received the command, whether it has expressed its intention in the token request chain. This mechanism helps to coordinate the token transfer between nodes and ensure the orderly execution of synchronization events.

[0062] Furthermore, if the current node identifier is not included in the query token application chain, it is determined whether a first time threshold has been exceeded; if the first time threshold has been exceeded, the process returns to executing the command to send a request token to other nodes; if the first time threshold has not been exceeded, the process returns to executing the command to determine whether a token transfer command has been received from other nodes.

[0063] It should be noted that, based on the above content, the following specific implementation steps can be provided:

[0064] If the current node's identifier is not found in the token request chain, it means the current node has not yet expressed its token request intention to other nodes. The current node further determines whether a first time threshold has been exceeded. The first time threshold can be a specified period of time during which the node needs to decide whether to send a token request command to other nodes. If the first time threshold has not been exceeded, it means the specified time has not yet arrived, and the node will return to check whether it has received a token transfer command from another node. If the first time threshold has been exceeded, it means no valid request has been made within the specified time, resulting in the absence of the current node's information in the token request chain. In this case, the current node can return to send a token request command to other nodes to request control of the first token.

[0065] It should be noted that the above design ensures that if a node does not have its current node identifier in the query token request chain, it can determine its subsequent operation by judging whether the first time threshold has been exceeded. This includes whether to send a request token command to other nodes or continue to judge whether a token transfer command has been received from other nodes.

[0066] Furthermore, if no first token presentation command is received from other nodes, it is determined whether a second time threshold has been exceeded; if the second time threshold has been exceeded, the creation of a second token is performed; if the second time threshold has not been exceeded, the process returns to determining whether a token transfer command has been received from other nodes.

[0067] This document explains the relevant content regarding the absence of a first token presentation command from other nodes and provides specific implementation steps:

[0068] In the case where the node has not received a first token presentation command from another node (i.e., the current node has not yet received a broadcast message from another node indicating receipt of the first token), the node will further determine whether a second time threshold has been exceeded. If the second time threshold has not been exceeded, it means the specified time has not yet arrived, and the node will return to the operation of determining whether a token transmission command has been received from another node, i.e., proceeding to subsequent steps. If the second time threshold has been exceeded, it means that a first token presentation command from another node has not been received within the specified time. In this case, the node will return to the operation of creating a second token. If the second time threshold has been exceeded, the current node will perform the creation of the second token. This may include generating the identifier of the second token, initializing the token state, etc. Furthermore, if the second time threshold is exceeded on the first check, it can be repeated a preset number of times until the preset number of checks are completed before the current node performs the creation of the second token. The preset number of checks can be set according to actual conditions; for example, the preset number is 3, and can be adjusted later according to actual conditions.

[0069] It should be noted that the above design ensures that if the current node has not received the first token presentation command from other nodes, it can determine whether to perform subsequent operations by judging whether the second time threshold has been exceeded, whether to execute the creation of the second token or to continue to judge whether the token transmission command has been received from other nodes.

[0070] Furthermore, in the embodiments of this specification, when creating the second token, a second token presentation command can be sent to other nodes. The second token presentation command is used by the current node to broadcast the second token information to other nodes. It is then determined whether a third token presentation command has been received from other nodes. The third token presentation command is used by other nodes to broadcast the third token information to the current node. If the third token presentation command has been received from other nodes, it is determined whether the second token has been successfully created based on the second token information and the third token information.

[0071] The following explains the relevant content regarding the creation of the second token and provides specific implementation steps:

[0072] Send a second token to other nodes: When creating a second token, the current node can send a second token to other nodes to broadcast the information that the current node has created a second token.

[0073] Determining if a third token presentation command has been received from another node: While waiting for a response from another node, the current node can determine if it has received a third token presentation command from another node. A third token presentation command can be a command from another node broadcasting third token information to the current node.

[0074] Handling cases where a third token presentation command has been received: If a third token presentation command has been received from another node, it means that the other node has already received the second token information sent by the current node. The current node will then further compare the second token information with the third token information to determine whether the second token was created successfully.

[0075] Determining if the second token was created successfully: Upon receiving a command to present the third token, the current node compares the information of the second token with that of the third token to determine if the second token was created successfully. This comparison may involve checking information such as identifiers and status to ensure the correctness of the second token.

[0076] This design ensures that after a node broadcasts its second token information to other nodes, it determines whether the second token was successfully created by checking if it has received a third token presentation command from another node and by comparing the second and third token information. This mechanism helps ensure that token creation and synchronization are effective.

[0077] In this embodiment of the specification, the second token information may include the number of the second token and the number of the current node, and the third token information may include the number of the third token and the number of the node that sent the third token presentation command. When determining whether the second token was successfully created, it can be determined whether the number of the second token is equal to the number of the third token; if the number of the second token is equal to the number of the third token, it is determined whether the number of the current node is less than the number of the node that sent the third token presentation command; if the number of the current node is less than the number of the node that sent the third token presentation command, the process returns to executing the command to send the second token presentation to other nodes.

[0078] This document explains the process of determining whether the second token has been successfully created and provides specific implementation steps.

[0079] To determine if the number of the second token is equal to the number of the third token: In the process of determining whether the second token was successfully created, first compare whether the number of the second token is equal to the number of the third token.

[0080] It should be noted that the token number can indicate the validity of the token. In order to ensure the orderly execution of synchronization events, only tokens with larger numbers can be selected as valid tokens. Since the second token is newly created, the number of the second token is the initial minimum number.

[0081] If the number of the second token is equal to the number of the third token: If the number of the second token is equal to the number of the third token, it can be further determined whether the number of the current node is less than the number of the node that sent the third token presentation command.

[0082] It should be noted that the node's number can also indicate the validity of the token. To distinguish different nodes, the node's number is unique. The smaller the node's number, the higher its priority.

[0083] If the current node's ID is less than the ID of the node that sent the third token presentation command: If the current node's ID is less than the ID of the node that sent the third token presentation command, it means that the current node's ID is smaller, and the second token is successfully created. In this case, the node will return to execute the operation of sending the second token presentation command to other nodes to broadcast the information of the second token.

[0084] This design ensures that when determining whether a second token has been successfully created, the token's number can be compared with the node's number to determine the validity of the newly created second token. This mechanism helps coordinate the behavior between nodes and ensures the correctness of token synchronization.

[0085] In this embodiment of the specification, if no third token presentation command is received from another node, it is determined whether a third time threshold has been exceeded; if the third time threshold has been exceeded, the number of the second token is increased by a preset value, and the second token is successfully created; if the third time threshold has not been exceeded, the process returns to determining whether a third token presentation command has been received from another node.

[0086] Based on the above information regarding the absence of a third token presentation command from other nodes, the specific implementation steps are as follows:

[0087] Determine whether a third token presentation command has been received from another node: If no third token presentation command has been received from another node, that is, the current node has not yet received the third token information broadcast by another node.

[0088] Handling situations where a third token presentation command has not been received: If a third token presentation command has not been received from other nodes, it can be concluded that other nodes do not currently hold tokens, and it can be further determined whether the third time threshold has been exceeded.

[0089] Determine if the third time threshold has been exceeded: If the third time threshold has been exceeded, it means that no third token presentation command has been received from other nodes within the specified time. In this case, the node will perform the operation of incrementing the second token number by a preset value, indicating that the second token has been successfully created. If the third time threshold has not been exceeded, it means that there may still be a chance to receive a third token presentation command from other nodes within the specified time. In this case, the node will return to the operation of determining whether a third token presentation command has been received from other nodes, i.e., proceed to the subsequent steps.

[0090] It should be noted that the above design ensures that the node waits for a third token presentation command from other nodes within a specified time. If the specified time is exceeded, the node will increment the second token number, indicating that the second token has been successfully created. This mechanism helps to ensure that the token synchronization process can adapt to different network conditions and response times, and waits for token broadcasts from other nodes when possible.

[0091] In the embodiments of this specification, if the number of the second token is not equal to the number of the third token, or if the number of the current node is greater than the number of the node that sent the third token presentation command, the request for token is resent to other nodes after a preset time.

[0092] It should be noted that if the second token number is not equal to the third token number, or if the current node's number is greater than the number of the node that sent the third token-presenting command, it means that the current node has not successfully acquired the token. In this case, the current node can wait for a preset time to resend the token request command. After waiting for the preset time, the current node can resend the token request command to other nodes to re-request control of acquiring the token.

[0093] This design ensures that when determining whether the second token has been successfully created, if the number of the second token is not equal to the number of the third token, or if the number of the current node is greater than the number of the node that sent the third token-presenting command, the node will wait for a period of time and then resend a token request command to other nodes to attempt to acquire control of the token. This mechanism helps to handle potential competition and conflicts that may occur during token synchronization.

[0094] It should be noted that the first, second, and third time thresholds can be set according to the actual situation. The first time threshold can be 10,000 ms, the second time threshold can be 500 ms, and the third time threshold can be 2,500 ms.

[0095] S108, if the second token is successfully created, execute the synchronization event based on the second token.

[0096] In the embodiments described in this specification, if it is determined that the second token was successfully created, the current node can execute a synchronization event based on the information carried by the second token. The specific operation of the synchronization event will depend on the application scenario and may involve data transmission, state updates, etc.

[0097] It should be noted that the above design ensures that, upon successful creation of the second token, the current node can execute a synchronization event based on the second token, thus ensuring that the data or state among all nodes is synchronized. This mechanism helps guarantee collaborative work and data consistency in the Internet of Things (IoT).

[0098] The above technical solutions can be found in [reference]. Figure 2 The flowchart shown illustrates the process of initiating a synchronization event.

[0099] The tokens in the embodiments of this specification have the following characteristics:

[0100] 1) The token number ranges from 0 to 9999, with newly created tokens having a number of 0 and tokens being passed on having a number greater than 0;

[0101] 2) The token number being passed is incremented by 1 each time, and becomes 2 after exceeding the maximum value, then the loop restarts;

[0102] 3) The purpose of token grabbing is mainly to coordinate the synchronous operation of multiple devices;

[0103] 4) All synchronization events are processed by the node that initiates them.

[0104] 5) All nodes that want to execute a synchronization event must first acquire the token before they have the right to execute;

[0105] 6) Synchronous events are a set of time-sequential logical events that require multiple devices to coordinate their operation, similar to the "master" in a "master-distribute" topology.

[0106] 7) If a "Show Token" command is received during token creation or when the token holder is operating normally, token arbitration will occur;

[0107] 8) Token Arbitration Principles:

[0108] (1) When there is only one non-zero number, the token with the non-zero number shall prevail;

[0109] (2) If there are multiple non-zero tokens, the token with the latest token number shall prevail;

[0110] (3) If the token numbers are the same, the token with the smallest device ID shall prevail;

[0111] 9) Token growth time explanation:

[0112] (1). The token holder maintains this time with a heartbeat of 1 second, which automatically increments by 1 every second;

[0113] (2) Used to fill in the ID of the data module, which is automatically incremented by 1 each time it is used;

[0114] (3) When "transferring the token", the token growth time needs to be included and automatically incremented by 1;

[0115] (4) Its essence is to provide all group members with a unified timing function that is independent of real-time;

[0116] The procedure for initiating a synchronization event as described in this specification is as follows:

[0117] Step 1: The IoT base station initiates a synchronization event; (Start)

[0118] Step 2: If the IoT base station does not possess a token, it begins requesting a token; if the IoT base station possesses a token, it directly jumps to Step 6 to execute the synchronization event.

[0119] Step 3: If the token application is successful, proceed to Step 6 to execute the synchronization event; if the token application fails, create the token yourself.

[0120] Step 4: The IoT base station creates its own token; token arbitration may occur during the token creation process.

[0121] Step 5: If token creation is successful, proceed to Step 6 to execute the synchronization event; if token creation fails, proceed to Step 2 to re-apply for a token.

[0122] Step 6: Execute the synchronization event; (End)

[0123] Figure 3 A schematic diagram of the structure of a device for executing synchronous events provided for one or more embodiments of this specification, including:

[0124] At least one processor; and,

[0125] A memory communicatively connected to the at least one processor; wherein,

[0126] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0127] When initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, and the token request command is used to request the first token;

[0128] Determine whether a token transfer command has been received from another node, wherein the token transfer command is used to send the first token to the current node;

[0129] If no token delivery command is received from another node, a second token is created.

[0130] If the second token is successfully created, the synchronization event is executed based on the second token.

[0131] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0132] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0133] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for executing synchronous events, characterized in that, The method includes: When initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, and the token request command is used to request the first token; Determine whether a token transfer command has been received from another node, wherein the token transfer command is used to send the first token to the current node; If no token delivery command is received from another node, a second token is created. If the second token is successfully created, the synchronization event is executed based on the second token; Before creating the second token, the method further includes: Determine whether a first token presentation command has been received from another node. The first token presentation command is used by a node to broadcast to other nodes that it has received the first token after receiving the first token. If a first token presentation command has been received from another node, determine whether the token request chain contains the current node's identifier. The token request chain is the token request list. If the query token application chain contains the current node identifier, return to determine whether a token transfer command has been received from another node; The method further includes: If the current node identifier is not included in the query token application chain, determine whether the first time threshold has been exceeded; If the first time threshold is exceeded, return to executing the command to send a request token to other nodes; If the first time threshold is not exceeded, return to the step of determining whether a token transmission command has been received from another node; The method further includes: If no first token presentation command is received from another node, determine whether the second time threshold has been exceeded. If the second time threshold is exceeded, the creation of the second token will be performed. If the second time threshold is not exceeded, return to the previous step of determining whether a token transmission command has been received from another node; The creation of the second token includes: Send a second token presentation command to other nodes. The second token presentation command is used by the current node to broadcast the second token information to other nodes. Determine whether a third token presentation command has been received from another node, wherein the third token presentation command is a third token information broadcast by another node to the current node; If the third token presentation command has been received from another node, determine whether the second token has been successfully created based on the second token information and the third token information; The second token information includes the number of the second token and the number of the current node, and the third token information includes the number of the third token and the number of the node that sent the third token presentation command; The determination of whether the second token was created successfully includes: Determine whether the number of the second token is equal to the number of the third token; If the number of the second token is equal to the number of the third token, determine whether the number of the current node is less than the number of the node that sent the third token presentation command; If the current node's number is less than the number of the node that sent the third token presentation command, return to execute the second token presentation command to other nodes; The method further includes: If no third token presentation command is received from other nodes, determine whether the third time threshold has been exceeded. If the third time threshold is exceeded, the number of the second token is incremented by a preset value, and the second token is successfully created; If the third time threshold is not exceeded, return to the previous step to determine whether a third token presentation command has been received from another node.

2. The method according to claim 1, characterized in that, The method further includes: If the transmission token command is received from another node, the synchronization event is executed based on the first token.

3. The method according to claim 1, further comprising: If the number of the second token is not equal to the number of the third token, or if the number of the current node is greater than the number of the node that sent the third token presentation command, the request for a token will be resent to other nodes after a preset time.

4. A device for executing synchronous events, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: When initiating a synchronization event, if it is determined that the first token is not held, a token request command is sent to other nodes, and the token request command is used to request the first token; Determine whether a token transfer command has been received from another node, wherein the token transfer command is used to send the first token to the current node; If no token delivery command is received from another node, a second token is created. If the second token is successfully created, the synchronization event is executed based on the second token; Before the creation of the second token, the following steps are also included: Determine whether a first token presentation command has been received from another node. The first token presentation command is used by a node to broadcast to other nodes that it has received the first token after receiving the first token. If a first token presentation command has been received from another node, determine whether the token request chain contains the current node's identifier. The token request chain is the token request list. If the query token application chain contains the current node identifier, return to determine whether a token transfer command has been received from another node; Also includes: If the current node identifier is not included in the query token application chain, determine whether the first time threshold has been exceeded; If the first time threshold is exceeded, return to executing the command to send a request token to other nodes; If the first time threshold is not exceeded, return to the step of determining whether a token transmission command has been received from another node; Also includes: If no first token presentation command is received from another node, determine whether the second time threshold has been exceeded. If the second time threshold is exceeded, the creation of the second token will be performed. If the second time threshold is not exceeded, return to the previous step of determining whether a token transmission command has been received from another node; The creation of the second token includes: Send a second token presentation command to other nodes. The second token presentation command is used by the current node to broadcast the second token information to other nodes. Determine whether a third token presentation command has been received from another node, wherein the third token presentation command is a third token information broadcast by another node to the current node; If the third token presentation command has been received from another node, determine whether the second token has been successfully created based on the second token information and the third token information; The second token information includes the number of the second token and the number of the current node, and the third token information includes the number of the third token and the number of the node that sent the third token presentation command; The determination of whether the second token was created successfully includes: Determine whether the number of the second token is equal to the number of the third token; If the number of the second token is equal to the number of the third token, determine whether the number of the current node is less than the number of the node that sent the third token presentation command; If the current node's number is less than the number of the node that sent the third token presentation command, return to execute the second token presentation command to other nodes; Also includes: If no third token presentation command is received from other nodes, determine whether the third time threshold has been exceeded. If the third time threshold is exceeded, the number of the second token is incremented by a preset value, and the second token is successfully created; If the third time threshold is not exceeded, return to the previous step to determine whether a third token presentation command has been received from another node.

Images