CN116405149B - Method, equipment and storage medium for time synchronization between chain nodes based on block consensus - Google Patents
Method, equipment and storage medium for time synchronization between chain nodes based on block consensus Download PDFInfo
- Publication number
- CN116405149B CN116405149B CN202310665940.1A CN202310665940A CN116405149B CN 116405149 B CN116405149 B CN 116405149B CN 202310665940 A CN202310665940 A CN 202310665940A CN 116405149 B CN116405149 B CN 116405149B
- Authority
- CN
- China
- Prior art keywords
- time
- node
- synchronization
- view
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 37
- 238000001514 detection method Methods 0.000 claims abstract description 23
- 230000001360 synchronised effect Effects 0.000 claims description 26
- 238000012795 verification Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 8
- 238000012856 packing Methods 0.000 claims description 5
- 238000013459 approach Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04J—MULTIPLEX COMMUNICATION
- H04J3/00—Time-division multiplex systems
- H04J3/02—Details
- H04J3/06—Synchronising arrangements
- H04J3/0635—Clock or time synchronisation in a network
- H04J3/0676—Mutual
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
- H04L67/1044—Group management mechanisms
- H04L67/1046—Joining mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Theoretical Computer Science (AREA)
- Synchronisation In Digital Transmission Systems (AREA)
Abstract
The application discloses a method, equipment and a storage medium for time synchronization among link points based on block consensus, which comprise the following steps: a time synchronization flow, a time synchronization state detection flow and a time node switching flow; the time synchronization process enters a time synchronization process according to the time node and the time view in the initialization configuration, and completes the time synchronization of the synchronization node; the time synchronization state detection flow is responsible for detecting whether the time node normally and periodically transmits a message packet Clock, namely judging whether the time node is offline; the time node switching flow is used for switching the time node in the next time view when the offline fault occurs to the time node. The application can realize the time synchronization of the block chain link points without changing the time of the local server; the real-time node offline detection can be realized, the dynamic smooth switching of the time node is completed in real time, and the user operation is not needed; meanwhile, the original block consensus network is utilized to agree on time node switching, so that the method is strong in compatibility and easy to implement.
Description
Technical Field
The application relates to the technical field of block link point clock synchronization, in particular to a block consensus-based link point time synchronization method.
Background
Block link point time is a key factor for normal operation of block link points and is related to block out consensus and the like. The node time inconsistency among the block chains can cause verification to be difficult to pass, block consensus and the like to be stagnated. In the public chain, the nodes are in a public network and can be communicated with a time server (such as a window time server), and each node can synchronize the time of the time server, so that clock synchronization among the nodes of the block chain is achieved. For the federation chain, the nodes are mostly located in a local area network or an internal network and cannot communicate with a public network, so that time synchronization of each node through a time server is difficult. Therefore, the problem of link point clock synchronization of the alliance chain blocks needs to be solved. In the existing schemes, the clock synchronization is mostly dependent on the local clock synchronization of the servers where the nodes are located, for example, one node server is used as a time server, and the other node servers synchronize the time of the server at regular time. This method is not flexible enough and requires additional effort to calibrate the time. In addition, in the patent document 'block chain node time synchronization method based on network consensus combined with VRF algorithm', node segmentation is performed first, node election is proposed in each segment through VRF algorithm, then a time result after consensus is obtained by using intra-segment network consensus as a system time corresponding to the segment, and finally network consensus is performed again for the system time corresponding to each segment, so as to obtain the final system time of the whole P2P network. This approach is based on two network syncs that are suitable for public chains but too complex for federation chains.
Disclosure of Invention
The application provides a block consensus-based time synchronization method between link points, which can solve the problem of time consistency between alliance link nodes in an internal network.
In order to achieve the above purpose, the present application adopts the following technical scheme:
a link point-to-link point time synchronization method based on block consensus comprises the following steps:
a time synchronization flow, a time synchronization state detection flow and a time node switching flow;
the time synchronization process enters a time synchronization process according to the time node and the time view in the initialization configuration, and completes the time synchronization of the synchronization node;
the time synchronization state detection flow is responsible for detecting whether the time node normally and periodically sends a message packet Clock, namely judging whether the time node is offline;
the time node switching flow is used for switching the time node in the next time view when the offline fault occurs to the time node.
Further, the time synchronization process comprises an initialization sub-module and a node time synchronization sub-module;
the initialization submodule is used for dividing the blockchain nodes participating in time synchronization into time nodes and synchronization nodes, wherein the time nodes are time reference nodes relied on by all nodes in the current time view, and the synchronization nodes are other nodes for synchronizing the time of the time reference nodes;
after the program is started, reading a time database, if no time node and no time view exist, reading the time node and the time view in the chain configuration file, and writing the time database; initializing a time view to be 1, wherein the time nodes in the chain configuration file of each node are consistent with the time view, so that the consistency of initial data is ensured;
the node time synchronization sub-module is used for inquiring the current time view and the current time node in the time database, if the current time node is a local node, the local node/time node periodically constructs a UDP message packet { view, from, time stamp }, and sends the UDP message packet { view, from, time stamp }; view in the Clock message packet refers to the current view, from refers to the time node under the current view, and timestamp refers to the time of the current time node;
if the current time node is not a local node, not sending a message packet Clock, and waiting for receiving the message packet Clock; when the synchronous node receives a message packet Clock, whether view is a currently stored view or not needs to be verified a priori, and whether from is a time node under the current view or not; if the verification is not passed, ignoring the message packet Clock; if the verification is passed, continuing to compare the difference diff between the timestamp and the local time, namely diff=timestamp-local; the absolute value of the difference diff is in a tolerable time difference range set by the system, so that node updating time is not needed; otherwise, the difference diff is cached and written into a time database, and when the current time of the node is read again, the time difference is added to the local time, namely the local time' +the difference diff.
Further, the time synchronization state detection flow is divided into a synchronization state setting and maintaining sub-module and a synchronization state detection sub-module;
the synchronous state setting and maintaining sub-module is used for indicating that the time node is normally on line when the synchronous node regularly receives the effective message packet Clock, and indicating that the current time node may be off line when the synchronous node does not receive the message packet Clock within a set time;
in the module, a synchronization state flag wait is introduced to maintain the current time synchronization state, wherein wait=false indicates that the synchronization node normally receives a message packet Clock of the time node, and the time node normally works; wait=true indicates that the synchronization node does not receive the message packet Clock of the time node within a certain time, and the time node may be offline and needs to switch the time node;
the synchronous state detection sub-module is used for setting a countdown timer, and the time is t; each time the synchronization node receives a valid message packet Clock, a synchronization status flag wait=false is set, and a timer counts down from t; if t is 0, the synchronization node also receives a valid message packet Clock, then a synchronization status flag wait=true is set, and at this time, it is detected that an offline fault may occur in the current time node.
Further, the time node switching module is divided into a time node switching message writing block sub-module and a time node determining sub-module to be switched;
the time node switching message writing block submodule is used for checking a synchronous state flag wait when the synchronous node is used as a packing node for packing out a block; if wait=true, constructing a data switch { view, clock node } to fill in the extra field of the block; switch { view, clockNode } represents the time node in the proposed next view, where view is the current time view plus 1, clockNode is the synchronization node; the message is packaged and chained with the block;
the time node to be switched determines the submodule, is used for all to carry out the above-mentioned time node switching message to write into the block submodule after each synchronous node or consensus node detects wait=true, namely time node of the current view may be off-line, namely these nodes may all pack the next block; but eventually only one block is determined at the next height; each node checks whether the extra field of the finally determined block contains switch data; when the switch data exists, verifying whether the view is the next time view of the current time view and the clock node cannot be the current time node; after verification is passed, each node updates the current time view and the time node in the time database, sets wait=false, and enters a time synchronization flow module.
In another aspect, the application also discloses a computer device comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of the method as described above.
In yet another aspect, the application also discloses a computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform the steps of the method as described above.
According to the technical scheme, the time synchronization method between the chain nodes based on the block consensus comprises a time synchronization flow module, a time synchronization state detection module and a time node switching module. Further, the time synchronization flow module is divided into an initialization sub-module and a node time synchronization sub-module; the time synchronization state detection module is divided into a synchronization state setting and maintaining sub-module and a synchronization state detection sub-module; the time node switching module is divided into a time node switching message writing block sub-module and a time node determining sub-module to be switched.
Specifically, the application has the following advantages:
(1) The time of the local server is not changed, and the block chain link point time synchronization is realized;
(2) The real-time nodes are detected offline, and the dynamic smooth switching of the time nodes is completed in real time without user operation;
(3) The original block consensus network is utilized to agree on time node switching, so that the method has strong compatibility and is easy to implement.
Drawings
FIG. 1 is a synchronous flow diagram of an embodiment of the present application;
FIG. 2 is a detection flow chart of an embodiment of the present application;
fig. 3 is a switching flowchart of an embodiment of the present application.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present application more apparent, the technical solutions of the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments of the present application.
As shown in fig. 1, in the inter-link node time synchronization method based on block consensus according to the present embodiment, the main modules include a time synchronization flow module, a time synchronization state detection module, and a time node switching module. Further, the time synchronization flow module is divided into an initialization sub-module and a node time synchronization sub-module; the time synchronization state detection module is divided into a synchronization state setting and maintaining sub-module and a synchronization state detection sub-module; the time node switching module is divided into a time node switching message writing block sub-module and a time node determining sub-module to be switched.
The following are respectively specified:
time synchronization flow module
The module enters a time synchronization flow according to the time node and the time view in the initialization configuration, and completes the time synchronization of the synchronization node.
And the initialization submodule is used for dividing the blockchain nodes participating in time synchronization into time nodes and synchronization nodes, wherein the time nodes are time reference nodes relied on by all nodes in the current time view, and the synchronization nodes are other nodes for synchronizing the time of the time reference nodes. After the program is started, the time database is read, if the time node and the time view do not exist, the time node and the time view in the chain configuration file are read, and the time database is written. The initialization time view is 1, and the time nodes and the time view in the chain configuration file of each node are consistent, so that the consistency of the initial data is ensured.
And the node time synchronization sub-module queries the current time view and the current time node in the time database, and if the current time node is a local node, the local node/time node periodically constructs a UDP message packet { view, from, time stamp }, and sends the UDP message packet to the connected synchronization node of the node. View in the Clock message packet refers to the current view, from refers to the time node under the current view, and timestamp refers to the time of the current time node. If the current time node is not a local node, the message packet Clock is not sent and the message packet Clock is waited for being received. When the synchronization node receives the message packet Clock, it needs to verify a priori whether view is the currently stored view and from is the time node under the current view. If the verification is not passed, the message packet Clock is ignored. If the verification is passed, the comparison of the time stamp with the local time local difference diff is continued, i.e. diff=time stamp-local. The absolute value of diff is within the tolerable time difference range set by the system, so that node update time is not needed. Otherwise, diff is cached and written to the time database. When the current time of the node is read again, the local time is added with a time difference value, namely, local' +diff.
Time synchronization state detection module
The module is responsible for detecting whether the time node normally and periodically transmits a message packet Clock, i.e. judging whether the time node is offline.
The synchronous state setting and maintaining sub-module indicates that the time node is normally on line when the synchronous node regularly receives the valid message packet Clock, and indicates that the current time node may be off line when the synchronous node does not receive the message packet Clock within a set time. In this module, a synchronization status flag wait is introduced to maintain the current time synchronization status. wait=false indicates that the synchronization node normally receives the message packet Clock of the time node, and the time node normally works. wait=true indicates that the synchronization node does not receive the message packet Clock of the time node within a certain time, and the time node may be offline and needs to switch the time node.
And the synchronous state detection submodule is provided with a countdown timer, and the time is t. The synchronization status flag wait=false is set each time a valid message packet Clock is received by the synchronization node and the timer counts down from t. If t is 0, the synchronization node also receives a valid message packet Clock, then a synchronization status flag wait=true is set, and at this time, it is detected that an offline fault may occur in the current time node.
Time node switching module
The module mainly solves the problem of switching the time node in the next time view when the time node goes offline and other faults.
The time node switching message is written into the block submodule, and when the synchronous node is taken as a packing node to pack out the block, the synchronous state flag wait is checked. If wait=true, then construct data switch { view, clock node } to fill in extra field of the block. switch { view, clockNode } represents a time node in the proposal next view, where view is the current time view plus 1, clockNode is typically the synchronization node. The message is packed up-link with the block.
When each synchronization node (or consensus node) detects wait=true, that is, the time node of the current view may be offline, the time node switching message writing block submodule is executed, that is, the nodes may package the next block. But eventually only one block is determined at the next height. Each node checks whether the extra field of the block finally determined contains switch data. When the switch data exists, it is verified whether the view is the next time view to the current time view and the clock node cannot be the current time node. After verification is passed, each node updates the current time view and the time node in the time database, sets wait=false, and enters a time synchronization flow module.
Overall, the advantages of the application are as follows:
(1) The time of the local server is not changed, and the block chain link point time synchronization is realized;
(2) The real-time nodes are detected offline, and the dynamic smooth switching of the time nodes is completed in real time without user operation;
(3) The original block consensus network is utilized to agree on time node switching, so that the method has strong compatibility and is easy to implement.
In yet another aspect, the application also discloses a computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform the steps of any of the methods described above.
In yet another aspect, the application also discloses a computer device comprising a memory and a processor, the memory storing a computer program which, when executed by the processor, causes the processor to perform the steps of any of the methods described above.
In a further embodiment of the present application, there is also provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the steps of any of the methods of the above embodiments.
It may be understood that the system provided by the embodiment of the present application corresponds to the method provided by the embodiment of the present application, and explanation, examples and beneficial effects of the related content may refer to corresponding parts in the above method.
Those skilled in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by a computer program for instructing relevant hardware, where the program may be stored in a non-volatile computer readable storage medium, and where the program, when executed, may include processes in the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The above embodiments are only for illustrating the technical solution of the present application, and are not limiting; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application.
Claims (5)
1. The block consensus-based link point-to-link point time synchronization method is characterized by comprising the following steps of:
a time synchronization flow, a time synchronization state detection flow and a time node switching flow;
the time synchronization process enters a time synchronization process according to the time node and the time view in the initialization configuration, and completes the time synchronization of the synchronization node;
detecting whether the time node normally and periodically transmits a message packet Clock or not through a time synchronization state detection flow, namely judging whether the time node is offline or not;
the time node in the next time view is switched when the offline fault of the time node is solved through a time node switching flow;
the time synchronization process comprises an initialization sub-module for initialization and a node time synchronization sub-module for node time synchronization;
the initialization submodule is used for dividing the blockchain nodes participating in time synchronization into time nodes and synchronization nodes, wherein the time nodes are time reference nodes relied on by all nodes in the current time view, and the synchronization nodes are other nodes for synchronizing the time of the time reference nodes;
after the program is started, reading a time database, if no time node and no time view exist, reading the time node and the time view in the chain configuration file, and writing the time database; initializing a time view to be 1, wherein the time nodes in the chain configuration file of each node are consistent with the time view, so that the consistency of initial data is ensured;
the node time synchronization sub-module is used for inquiring the current time view and the current time node in the time database, and if the current time node is a local node, the local node/time node periodically constructs a message packet { view, from, time stamp }, and sends the message packet to the synchronous node connected with the node; view refers to the current view, from refers to the time node under the current view, and timestamp refers to the time of the current time node;
if the current time node is not a local node, not sending a message packet Clock, and waiting for receiving the message packet Clock; when the synchronous node receives a message packet Clock, whether view is a currently stored view or not needs to be verified a priori, and whether from is a time node under the current view or not; if the verification is not passed, ignoring the message packet Clock; if the verification is passed, continuing to compare the difference diff between the timestamp and the local time, namely diff=timestamp-local; the absolute value of the difference diff is in a tolerable time difference range set by the system, so that node updating time is not needed; otherwise, the difference diff is cached and written into a time database, and when the current time of the node is read again, the time difference is added to the local time, namely the local time' +the difference diff.
2. The inter-link node time synchronization method based on block consensus according to claim 1, wherein: the time synchronization state detection flow is divided into a synchronization state setting and maintaining sub-module for performing synchronization state setting and maintaining and a synchronization state detection sub-module for performing synchronization state detection;
the synchronous state setting and maintaining sub-module is used for indicating that the time node is normally on line when the synchronous node regularly receives the effective message packet Clock, and indicating that the current time node may be off line when the synchronous node does not receive the message packet Clock within a set time;
introducing a synchronization state flag wait to maintain the current time synchronization state, wherein wait=false indicates that the synchronization node normally receives a message packet Clock of the time node, and the time node normally works; wait=true indicates that the synchronization node does not receive the message packet Clock of the time node within a certain time, and the time node may be offline and needs to switch the time node;
the synchronous state detection sub-module is used for setting a countdown timer, and the time is t; each time the synchronization node receives a valid message packet Clock, a synchronization status flag wait=false is set, and a timer counts down from t; if t is 0, the synchronization node also receives a valid message packet Clock, then a synchronization status flag wait=true is set, and at this time, it is detected that an offline fault may occur in the current time node.
3. The inter-link node time synchronization method based on block consensus according to claim 1, wherein: the time node switching flow is divided into a time node switching message writing block submodule for writing the time node switching message into the block and a time node to be switched determining submodule for determining the time node to be switched;
the time node switching message writing block submodule is used for checking a synchronous state flag wait when the synchronous node is used as a packing node for packing out a block; if wait=true, constructing a data switch { view, clock node } to fill in the extra field of the block; switch { view, clockNode } represents the time node in the proposed next view, where view is the current time view plus 1, clockNode is the synchronization node; the message is packaged and chained with the block;
the time node to be switched determines the submodule, is used for all to carry out the above-mentioned time node switching message to write into the block submodule after each synchronous node or consensus node detects wait=true, namely time node of the current view may be off-line, namely these nodes may all pack the next block; but eventually only one block is determined at the next height; each node checks whether the extra field of the finally determined block contains switch data; when the switch data exists, verifying whether the view is the next time view of the current time view and the clock node cannot be the current time node; after verification is passed, each node updates the current time view and the time node in the time database, sets wait=false, and enters a time synchronization flow.
4. A computer device comprising a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the method of any of claims 1 to 3.
5. A computer readable storage medium storing a computer program which, when executed by a processor, causes the processor to perform the steps of the method of any one of claims 1 to 3.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310665940.1A CN116405149B (en) | 2023-06-07 | 2023-06-07 | Method, equipment and storage medium for time synchronization between chain nodes based on block consensus |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310665940.1A CN116405149B (en) | 2023-06-07 | 2023-06-07 | Method, equipment and storage medium for time synchronization between chain nodes based on block consensus |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116405149A CN116405149A (en) | 2023-07-07 |
| CN116405149B true CN116405149B (en) | 2023-10-10 |
Family
ID=87018345
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310665940.1A Active CN116405149B (en) | 2023-06-07 | 2023-06-07 | Method, equipment and storage medium for time synchronization between chain nodes based on block consensus |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116405149B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101123491A (en) * | 2007-09-21 | 2008-02-13 | 中兴通讯股份有限公司 | An implementation device and method for time synchronization of advanced telecom computer architecture |
| CN114048517A (en) * | 2022-01-14 | 2022-02-15 | 北京大学深圳研究生院 | Dual channel consensus system and method for blockchains, computer readable storage medium |
| CN114461438A (en) * | 2022-04-12 | 2022-05-10 | 北京易鲸捷信息技术有限公司 | Distributed database disaster recovery system and method of asymmetric center mode |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20200412603A1 (en) * | 2018-03-09 | 2020-12-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for managing transmission of probe messages for detection of failure |
| US20200145194A1 (en) * | 2018-05-11 | 2020-05-07 | Michael Alan Stollery | Blockchain infrastructure solutions |
| US20220044241A1 (en) * | 2020-08-08 | 2022-02-10 | Dan Lu | Achieving Decentralized Blockchain Consensus Using A State Function Driven Protocol |
| US11568384B2 (en) * | 2020-12-04 | 2023-01-31 | Code Inc. | Cryptocurrency transactions with synchronized images |
-
2023
- 2023-06-07 CN CN202310665940.1A patent/CN116405149B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101123491A (en) * | 2007-09-21 | 2008-02-13 | 中兴通讯股份有限公司 | An implementation device and method for time synchronization of advanced telecom computer architecture |
| CN114048517A (en) * | 2022-01-14 | 2022-02-15 | 北京大学深圳研究生院 | Dual channel consensus system and method for blockchains, computer readable storage medium |
| CN114461438A (en) * | 2022-04-12 | 2022-05-10 | 北京易鲸捷信息技术有限公司 | Distributed database disaster recovery system and method of asymmetric center mode |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116405149A (en) | 2023-07-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110798499B (en) | Distributed service coordination system and method | |
| CN108494828B (en) | Node data updating method, medium, device and computing equipment | |
| CN110176973B (en) | Method, system, computer device and storage medium for clock synchronization | |
| JP7401656B2 (en) | METHODS, APPARATUS AND SYSTEM AND STORAGE MEDIA FOR SELECTING CLOCK SOURCES | |
| CN110572287A (en) | data disaster tolerance method and device, computer equipment and storage medium | |
| CN112583512B (en) | Time synchronization device and method | |
| CN111026767A (en) | Data storage method and device of block chain and hardware equipment | |
| CN116405149B (en) | Method, equipment and storage medium for time synchronization between chain nodes based on block consensus | |
| CN105450682A (en) | Method, device, and system for data synchronous storage and synchronizing data to client | |
| CN105700962A (en) | Data update processing method and apparatus | |
| CN114518897A (en) | Remote upgrading method and system for communication module | |
| CN104102748A (en) | Method and device for file mapping and method and device for file recommendation | |
| CN113138880A (en) | Block chain system gray level release method, device, equipment and storage medium | |
| CN113190620A (en) | Method, device, equipment and storage medium for synchronizing data between Redis clusters | |
| CN112511341A (en) | Network automation fault positioning method, terminal and storage medium | |
| CN102904662A (en) | Cross-domain clock synchronization method and system based on PTP (Precision Time Protocol) | |
| CN112181562A (en) | Browser view loading method, device and system | |
| CN112291299B (en) | Synchronization method, device, equipment and storage medium based on AI Station inference platform | |
| CN111338848A (en) | Failure application copy processing method and device, computer equipment and storage medium | |
| CN112287348B (en) | Self-refreshing method and system of vehicle-mounted module | |
| CN101924747A (en) | Method and device for processing data collision, network side server and terminal | |
| CN111008166A (en) | Communication method, communication system and storage medium | |
| CN115495531B (en) | Block chain data synchronization method and system based on check point | |
| CN115221245B (en) | Intelligent data acquisition synchronization method, system and equipment | |
| CN112702269B (en) | SDN and non-SDN intercommunication method and intercommunication system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |