Peer-to-peer database synchronization based on transmission protocol

Abstract

A mechanism includes receiving a Hello message at a local node, the Hello message including an application identifier (AppId) and a target link between a target port of the local node and a target port of an adjacent node. The local node determines that the AppId is associated with an application for performing database synchronization. The local node establishes a local database in a memory of the local node for use by the application as part of a database pair, the database pair including an adjacent database of the adjacent node. The local node associates the database pair with the target link. The local node controls synchronization of the local database with the adjacent database via the target link.

Description

[0001] Cross-application of related applications

[0002] This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 655,625, filed by Dean Cheng et al. on April 10, 2018, entitled “Point-to-Point Database Synchronization Over a Transport Protocol,” and U.S. Provisional Patent Application No. 62 / 782,993, filed by Dean Cheng et al. on December 20, 2018, entitled “Point-to-Point Database Synchronization Over a Transport Protocol,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates generally to database management and, more particularly, to a communication protocol for managing peer-to-peer database synchronization. Background Art

[0004] Database synchronization is the process of establishing consistency between multiple database systems. The purpose of database synchronization is to ensure that changes to a first database are updated synchronously to one or more corresponding database systems. Database synchronization may involve creating complex application-specific implementations that may not be implemented in conjunction with other implementations. Some applications may need to implement communication resource management mechanisms to ensure consistency and verify that information is actually received by other database systems. In addition, database synchronization may fail if the connection is interrupted. For example, retransmitting all database files after reestablishing the connection may result in poor utilization of communication resources in some cases. Summary of the invention

[0005] In one embodiment, the present disclosure includes a method implemented in a local node. The method includes: a receiver of the local node receives a Hello message, the Hello message includes an application identifier (AppId) and a target link between a target port of the local node and a target port of a neighbor node; a processor of the local node determines that the AppId is associated with an application for performing database synchronization; a local database is established in a memory of the local node as part of a database pair for use by the application, the database pair includes a neighbor database of the neighbor node; the processor associates the database pair with the target link; and the synchronization of the local database with the neighbor database is controlled through the target link. This method allows a communication protocol to automatically establish one or more database pairs for synchronization over a network. The protocol obtains the target link and the AppId from the Hello message. Then, the protocol can associate the application with the target link and establish a database for synchronization on behalf of the application. In this way, database establishment can be performed without performing database establishment in the application, so that database synchronization is established and maintained without direct management by the application. This in turn enables applications to perform database synchronization without having direct knowledge of the underlying network messaging used to achieve such synchronization.

[0006] Optionally, in any of the above aspects, another implementation of the aspect includes that controlling the synchronization of the local database with the adjacent database includes: the transmitter of the local node sends record information to the adjacent database in a Link-Local Registration Protocol Data Unit (LRPDU) message via the target link. Database information is stored in the form of records. Record version information (e.g., control information) is exchanged via the LRPDU sent on the target link. Therefore, the LRPDU message can be used as a mechanism to indicate to adjacent nodes that database records have been updated, and vice versa. Similarly, the LRPDU message can be used to manage database synchronization.

[0007] Optionally, in any of the above aspects, another implementation of the aspect includes: the local database includes an applicant database to store local records, which are sent to a registrar database in the adjacent database.

[0008] Optionally, in any of the above aspects, another implementation of the aspect includes: the local database includes a registrant database to receive adjacent records from an applicant database in the adjacent database. The database pair includes an applicant and a registrant. The applicant contains records to be uploaded, and the registrant receives copies of the applicant records. The local node and the adjacent node may include an applicant database and a registrant database, respectively, for two-way synchronization. In addition, the applicant database may be located on the local node, and the registrant database may be located on the adjacent node, or vice versa, for one-way synchronization.

[0009] Optionally, in any of the above aspects, another implementation of the aspect includes: the Hello message is a Hello LRPDU, and the Hello LRPDU represents the target link as a local chassis (MyChassis) identifier (identifier, ID) identifying the local node, a local port (My Port) ID identifying the destination port on the local node, a neighbor chassis (Neighbor Chassis) ID identifying the neighboring node, and a neighbor port (Neighbor Port) ID identifying the target port on the neighboring node. The target link can be specified by a chassis ID and a port ID, and the port ID represents a target port at each end of the target link. This method allows the target link to be uniquely identified, thereby indicating to the local node and the neighboring node respectively, wherein the corresponding node can be located for LRPDU communication.

[0010] In one embodiment, the present disclosure includes a method implemented in a local node. The method includes: a transmitter of the local node sends one or more record link local registration protocol data unit (Link-Local Registration Protocol Data Unit, LRPDU) messages to the registrar database of the adjacent node, and the record LRPDU message indicates that the record stored in the applicant database of the local node is updated; the receiver of the local node receives one or more LRPDU messages confirming the record LRPDU message; at least one updated record in the applicant database is marked as confirmed by the registrar database in the memory of the local node; and the processor notifies the application that the applicant database and the registrar database are synchronized. This mechanism allows the network communication protocol to monitor database communications and determine when to synchronize the database. Then, the network protocol can notify the application that the synchronization is complete. In this way, the application does not need to know each record exchange and associated communication. The application can make changes to the local applicant database and allow the network protocol to manage the synchronization and notify the application after the synchronization is completed.

[0011] Optionally, in any of the above aspects, another implementation of the aspect includes, the method further includes: the processor of the local node determines that all update records in the applicant database are confirmed by the registrant database through an LRPDU message, wherein the notification to the application that the applicant database and the registrant database have been synchronized is initiated based on the determination result that all update records in the applicant database are confirmed by the registrant database through an LRPDU message. The applicant can determine when to confirm each record and notify the application when all records are confirmed, thereby completing the synchronization between the applicant database and the registrant database.

[0012] Optionally, in any of the above aspects, another implementation of the aspect includes, the LRPDU message confirming the record LRPDU message includes a partial list (Partial List) LRPDU message, and the partial list LRPDU message includes at least one record header confirming the at least one update record. The partial list LRPDU message serves as a confirmation message. The partial list LRPDU message is sent by the registrant and indicates to the applicant that the registrant has performed the update requested by the record LRPDU message.

[0013] Optionally, in any of the above aspects, another implementation of the aspect includes that the record header includes a record number indicating the update record and a sequence number identifying the update contained in the update record. This information may indicate a certain record update that the registrant has received.

[0014] Optionally, in any of the above aspects, another implementation of the aspect includes that the method further includes: when the record LRPDU message timer times out and the corresponding partial list LRPDU message is not received, generating a failure notification to the application. This mechanism enables the application to receive notification of potential record communication failures. The record LRPDU message may not be automatically resent because a large amount of communication may exceed the registrant's receive buffer (for example, may cause more record synchronization failures).

[0015] Optionally, in any of the above aspects, another implementation of the aspect includes that the LRPDU message confirming the record LRPDU message includes a complete list LRPDU message, and the complete list LRPDU message includes record headers corresponding to all records in the registrant database. The complete list LRPDU message can be sent by the registrant at predetermined intervals. The complete list LRPDU message includes the current status of the registrant database. Therefore, the applicant can use the complete list LRPDU message to determine when the registrant receives the record, when to discard the confirmation message, and when the registrant does not receive the record update. Then, the applicant can recover from synchronization errors by sending other record LRPDU messages based on the content of the complete list LRPDU message.

[0016] Optionally, in any of the above aspects, another implementation of the aspect includes that the complete list LRPDU message includes a first record number field indicating the first record stored in the registrant database and a last record number field indicating the last record stored in the registrant database, and the record header includes a record number indicating the record stored in the registrant database and a serial number identifying the updates contained in the record stored in the registrant database.

[0017] Optionally, in any of the above aspects, another implementation of the aspect includes that the record LRPDU message includes one or more record numbers indicating the records updated in the applicant database and one or more sequence numbers identifying the updates contained in the records updated in the applicant database.

[0018] Optionally, in any of the above aspects, another implementation of the aspect includes that the method further includes: the transmitter sends a request complete list (Request Complete List) LRPDU message to the registrant database; the receiver receives a complete list LRPDU message from the registrant database in response to the request complete list LRPDU message. By adopting this mechanism, the applicant can request a complete list LRPDU message on demand without having to wait for periodic complete list LRPDU messages.

[0019] In one embodiment, the present disclosure includes a method implemented in a local node. The method includes: a processor of the local node generates a disconnect code for an application, the disconnect code indicating that the exchange of a Hello link-local registration protocol data unit (Link-Local Registration Protocol Data Unit, LRPDU) message failed; the processor receives a command from the application to maintain the applicant database in the memory of the local node in the presence of the disconnect code; after successfully exchanging the Hello LRPDU message, the receiver of the local node receives a complete list LRPDU message from the registrar database of the adjacent node, the complete list LRPDU message including the record headers corresponding to all records in the registrar database; the processor compares the record header in the complete list LRPDU message with the record header in the applicant database to resynchronize the applicant database with the registrar database. This mechanism can still maintain the database pair in the event of a connection interruption. When a connection interruption occurs, the applicant is notified and allowed to choose whether to reset synchronization (e.g., by resending all records) when the connection is reestablished or to resume synchronization when the connection is reestablished. The registrar sends a complete list message when reconnecting through the Hello exchange, so that the database pair can be maintained. The applicant database can then compare the record headers in the registrant database with the record headers of the applicant database to determine which updates, if any, were lost due to the connection interruption. The applicant database can then resend only the lost updates without resending the complete applicant database record list to the registrant. This approach can reduce network resource usage and synchronization recovery time when a network connection between the applicant and the registrant is established.

[0020] Optionally, in any of the above aspects, another implementation of the aspect includes that the method further includes: after the Hello message is unsuccessfully exchanged, resetting the notification timer in the applicant database so as not to send the record LRPDU message before receiving the complete list LRPDU message. This enables the applicant database to stop attempting to synchronize the database before the connection is restored, thereby saving network resources and processing resources.

[0021] Optionally, in any of the above aspects, another implementation of the aspect includes that the method further includes: the processor determines that there is a mismatch between one or more record headers in the applicant database and one or more record headers in the complete list LRPDU message; sends a record LRPDU message to the registrant database, and the record LRPDU message includes an updated record header that handles the mismatch. If a mismatch occurs, an updated record can be sent from the applicant to the registrant. The reason for this situation is that the previous record LRPDU message is lost when the connection is interrupted.

[0022] Optionally, in any of the above aspects, another implementation of the aspect includes that the method further includes: the processor determines that there is a match between the record header in the applicant database and the record header in the registrant database; based on the determination result of the match, notifying the application through the processor that the applicant database and the registrant database have been synchronized. This allows the network protocol to manage synchronization on behalf of the application, so that the application may not be aware of communication details related to database synchronization.

[0023] In one embodiment, the present disclosure includes a local node, including a memory, a transmitter, a receiver, and a processor, wherein the processor is coupled to the memory, the transmitter, and the receiver, and the local node is configured to execute the method according to the above aspects.

[0024] In one embodiment, the present disclosure includes a non-transitory computer-readable medium, including a computer program product for use in a local node, the computer program product including computer executable instructions stored on the non-transitory computer-readable medium, and the computer executable instructions, when executed by a processor, cause the local node to perform the method according to the above aspects.

[0025] In one embodiment, the present disclosure includes a local node, including: a receiving module, used to receive a Hello message, the Hello message including an application identifier (AppId) and a target link between the local node and an adjacent node; a determining module, used to determine that the AppId is associated with an application for performing database synchronization; a database pair establishing module, used to establish a local database in the local node for use by the application as part of a database pair, the database pair including an adjacent database of the adjacent node; an associating module, used to associate the database pair with the target link; and a synchronization control module, used to control the synchronization of the local database with the adjacent database through the target link.

[0026] In one embodiment, the present disclosure includes a local node, including: a sending module, used to send one or more record link local registration protocol data unit (Link-Local Registration Protocol Data Unit, LRPDU) messages to the registrar database of an adjacent node, the record LRPDU message indicating an update to a record in an applicant database storing the local node; a receiving module, used to receive one or more LRPDU messages confirming the record LRPDU message; a memory module, used to mark at least one update record in the applicant database as confirmed by the registrar database; a determination module, used to determine that all update records in the applicant database have been confirmed by the registrar database through the LRPDU message; a notification module, used to notify an application that the applicant database and the registrar database have been synchronized based on a determination result that all update records in the applicant database have been confirmed by the registrar database through the LRPDU message.

[0027] In one embodiment, the present disclosure includes a local node, including: a disconnect module, used to generate a disconnect code for an application, the disconnect code indicating a failure in the exchange of a Hello link-local registration protocol data unit (Link-Local Registration Protocol Data Unit, LRPDU) message; a command module, used to receive a command from the application to still maintain the applicant database in the memory of the local node in the presence of the disconnect code; a receiving module, used to receive a complete list LRPDU message from the registrar database of an adjacent node after successfully exchanging Hello messages, the complete list LRPDU message including record headers corresponding to all records in the registrar database; a record comparison module, used to compare the record header in the complete list LRPDU message with the record header in the applicant database to resynchronize the applicant database with the registrar database.

[0028] Optionally, in any of the above-mentioned local nodes, another implementation of the local node includes that the local node also includes a module for executing the method described in any of the above-mentioned aspects.

[0029] For clarity, any of the above-described embodiments may be combined with any of the above-described or more of the other embodiments to produce new embodiments within the scope of the present disclosure.

[0030] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] For a more complete understanding of the present disclosure, reference is now made to the following brief description taken in conjunction with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0032] Figure 1 A schematic diagram of an exemplary native system implementation of a database synchronization network.

[0033] Figure 2 A schematic diagram of an exemplary proxy system implementation for a database synchronization network.

[0034] Figure 3 is a schematic diagram of an exemplary database system for database synchronization.

[0035] Figure 4 A protocol diagram for an exemplary method for managing database synchronization.

[0036] Figure 5 An exemplary encoding of a Hello Link-Local Registration Protocol Data Unit (LRPDU) message is shown.

[0037] Figure 6 An exemplary encoding of a log LRPDU message is shown.

[0038] Figure 7 An exemplary encoding of a partial list LRPDU message is shown.

[0039] Figure 8 An exemplary encoding of a Complete List LRPDU message is shown.

[0040] Fig. 9 A flowchart of an exemplary method for establishing a database pair.

[0041] Fig.10 A flow chart of an exemplary method for managing synchronization of a pair of databases.

[0042] Fig.11 A flowchart of an example method for maintaining database synchronization in the event of a loss of connectivity.

[0043] Fig.12 A schematic diagram of an exemplary network element for managing database synchronization.

[0044] Fig.13 A schematic diagram of an exemplary apparatus for establishing a database pair.

[0045] Fig.14 A schematic diagram of an exemplary device for managing synchronization of database pairs.

[0046] Fig.15A diagram of an example row device for maintaining database synchronization in the event of a loss of connectivity. DETAILED DESCRIPTION

[0047] First, it should be understood that although illustrative implementations of one or more embodiments are provided below, the disclosed systems and / or methods may be implemented using any number of techniques, whether currently known or in existence. The present disclosure should in no way be limited to the illustrative implementations, drawings, and techniques described below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0048] Standardized communication protocols can be used to implement database synchronization. These communication protocols can be configured to maintain database consistency in a standardized manner. For example, Link-local Registration Protocol (LRP) is a standard that specifies protocols, processes, and managed objects to replicate a registration database from one end of a point-to-point link to the other end and replicate changes to portions of the database. LRP can be used for database optimization, up to the order of 1 megabyte. LRP Database Synchronization (LRP-DS) can be used to establish communication between databases. LRP-DS uses Hello messages to establish node adjacencies in a manner similar to the Intermediate System to Intermediate System (IS-IS) protocol. LR Database Transport (LRP-DT) can be used to transmit data carried in Record messages provided by LRP-DS in a manner similar to Link State Advertisement (LSA) messages carried by IS-IS. Therefore, LRP-DS manages database synchronization on behalf of relevant applications.

[0049] This article discloses a mechanism for improving the functionality of LRP-DS. For example, LRP-DS can be optimized to automatically establish a synchronized database pair. The database pair includes an applicant database of a first node and a registrant database of a second node. For clarity of discussion, these nodes may also be referred to as local nodes and adjacent nodes, respectively. When the applicant database is updated, the LRP-DS protocol sends these updates to the registrant database to maintain synchronization. For one-way communication, the local node includes an applicant database, and the adjacent node includes a registrant database. For two-way communication, the local node includes an applicant database that is synchronized with the registrant database of the adjacent node, and the adjacent node includes an applicant database that is synchronized with the registrant database of the local node. In either case, the database pair can be automatically established after exchanging Hello Link-Local Registration Protocol Data Unit (LRPDU) messages. The HelloLRPDU message contains the application identifier (AppId) of the corresponding application and the target link, which is represented by the local chassis (My Chassis) identifier (identifier, ID) identifying the local node, the local port (My Port) ID identifying the target port on the local node, the neighbor chassis (Neighbor Chassis) ID identifying the neighbor node, and the neighbor port (Neighbor Port) ID identifying the target port on the neighbor node. After exchanging Hello messages, the local node and the neighbor node can automatically create a paired applicant database and a registrant database for the identified application, and associate these database pairs with each other according to the target link.

[0050] LRP-DS runs in a component called a portal and can also be used to automatically notify applications when the database is synchronized after one or more updates. For example, when there is an update to the applicant database, a record LRPDU message is sent to the registrant database to indicate the database records that have been updated and the sequence numbers (e.g., version numbers) of these updated records. The registrant database responds with a partial list (Partial List) LRPDU message that confirms that the updated records are known and can be sent through LRP-DT. When the partial list LRPDU message is received, the portal marks the records with the indication in the applicant database as confirmed. Multiple record LRPDU messages and multiple partial list LRPDU messages can be exchanged. When all records in the applicant database are marked as confirmed, the portal can send an indication to the application that the database has been synchronized.

[0051] As another example, LRP-DS can be used to maintain synchronization between databases in the event of a connection interruption. Hello LRPDU messages can be exchanged periodically. When the exchange of Hello LRPDU messages fails, the portal can notify the application. The applicant can choose to delete the pairing and create a new database pair when reconnected by re-uploading the database records to the new registrant database. The applicant can also choose to maintain the current database pair. When the portal receives an indication that the database pairing needs to be maintained, the portal stops exchanging more record LRPDU messages. When the Hello LRPDU message exchange is reestablished, the registrant sends a complete list LRPDU message to the applicant. The complete list LRPDU message contains the record headers corresponding to all records in the registrant database. The applicant database can compare the record headers in the complete list LRPDU message with the record headers stored in the applicant database to determine whether there is a record mismatch. This operation can be performed when the record LRPDU message is lost due to a connection loss. The applicant database can then send a record LRPDU message containing any record updates made since entering the record state contained in the complete list LRPDU message. Typically, this allows fewer record LRPDUs to be transmitted, rather than quickly transmitting a full list LRPDU. The portal can also notify the application after the database has been synchronized. These and other exemplary embodiments are described in more detail below with reference to the figures.

[0052] Figure 1 Schematic diagram of an exemplary local system implementation of a database synchronization network 100. The database synchronization network 100 includes a local system 110 and a local system 130 coupled via an Internet Protocol (IP) network 171. The local system 110 and the local system 130 include one or more databases 120 and 122 that need to be synchronized, respectively. For clarity of discussion, in this article, the local system 110 or 130 is referred to as a local system relative to a source operation performed in a first system, and is referred to as an adjacent system relative to a destination operation performed in a second system. Therefore, the local systems 110 and 130 can be local systems, adjacent systems, or local systems and adjacent systems, depending on the context. It should also be noted that the terms "local" and "adjacent" used in this article are relative, in order to clearly distinguish between the first node and the second node, and can be used interchangeably when discussing the same network from different perspectives.

[0053] The local system 110 is a computing component including an application 111, a portal 113, a target port 141, and a database 120. The application 111 is a computer program that can be used to distribute information between at least the local system 110 and / or the proxy system and the local system 130 and / or the proxy system. The proxy system is hereinafter referred to as Figure 2 For example, application 111 may include a user-operable program that saves files synchronized with a cloud storage system. Application 111 uploads data to application 131 and / or downloads data from application 131. For simplicity, only two applications 111 and 131 are shown, but application 111 can be synchronized with any number of other applications.

[0054] Portal 113 is an instance of a portal interface and is also an instance of an applicant and / or registrant state machine and database 120 associated with an application 111. For example, portal 113 runs LRP (e.g., LRP-DS and LRP-DT) on behalf of application 111. Portal 113 receives notifications from application 111 and / or database 120, performs corresponding LRP operations, and provides responsive notifications to application 111 and / or database 120. For example, portal 113 runs LRP-DS through communication management of LRPDU messages. Portal 113 sends data, such as records in database 120, to corresponding portal 133 via transmission control protocol (TCP) connection 170, etc., and then runs LRP-DT. In some examples, application 111 on local system 110 maintains an independent portal 113 and corresponding database 120 on each of many target ports 141 in local system 110.

[0055] The local system 110 may also run a Link Layer Discovery Protocol (LLDP) 161 on the target port 141. Alternatively, the local system 110 maintains an information repository controlled by a system administrator that contains data equivalent to that generated by the LLDP 161.

[0056] The database 120 includes one or more file repositories corresponding to the application 111. The files in the database 120 are stored as records. A record is a subset of the database 120, which is transmitted from the applicant to the registrant in a unit through the LRP running in the portal 113. Each record includes data, a record number identifying the data, and a primary sequence number. The sequence number identifies the current version of the record. For example, the sequence number can be implemented as a counter indicating the number of times the record is updated. The database 120 can be an applicant database or a registrant database or an applicant database and a registrant database. The applicant is one of the two roles (applicant and registrant) that the application 111 can play relative to the portal 113. The applicant controls the database 120 that the LRP copies to the registrant in the adjacent portal 133. The registrant is one of the two roles (registrant and applicant) that the application 111 can play relative to the portal 113. The registrant receives a copy of the database 122 copied by the LRP from the applicant in the adjacent portal 133. Thus, the database 120 may be a requestor database for uploading records to the database 122 or a registrant database for downloading records from the database 122 or both a requestor database and a registrant database for bidirectional record communication with the database 122 .

[0057] Target port 141 is a communication port on local system 110. Portal 113 and associated applicant and registrant databases 120 are associated with one target port 141. If more than one portal 113 serves different applications 111, target ports 141 may be associated with those portals 113. Target port 141 may access links to one or more other target ports 151 (e.g., in other systems).

[0058] Native system 130 is substantially similar to native system 110. Native system 130 includes portal 133, application 131, database 122, and target port 151, which are substantially similar to portal 113, application 111, database 120, and target port 141, respectively.

[0059] After the local systems 110 and 130 discover each other, they establish paired databases 120 and 122 through LLDP 161. LLDP 161 is a link layer protocol used by network devices to announce their identities, capabilities, and network neighbors on the network, as described in the Institute of Electrical and Electronics Engineers (IEEE) standard document 802.1AB. Specifically, the local systems 110 and 130 can mutually announce their applications 111 and 131, LRP-DS, and LRPDT capabilities via target ports 141 and 151 by using LLDP 161. Through LLDP 161 and determining whether to use Edge Control Protocol (ECP) 160 or Transmission Control Protocol (TCP) to carry LRPDU messages, the address used by LRP-DT when carrying these LRPDU messages can be determined. ECP 160 is a network protocol defined in IEEE standard 802.1Q-2014. TCP 170 is defined in the Internet Engineering Task Force (IETF) document Request For Comment (RFC) 793. Either ECP 160 or TCP 170 can be used to carry the LRPDU message. If ECP 160 is used, the ECP message passes through the destination ports 141 and 151. If TCP 170 is used, the LRPDU message can pass through the destination ports 141, 151 or through any other port on the two local systems 110 and 130.

[0060] LRPDU messages are used as control messages to indicate record updates, confirmations, and other management information related to database synchronization in databases 120 and / or 122. LRPDU messages discussed herein include Hello LRPDU messages, Record LRPDU messages, Partial List LRPDU messages, Complete List LRPDU messages, and Request Complete List LRPDU messages. However, other LRPDU messages can be used as needed to achieve synchronization of databases 120 and 122. By using LRPDU messages, portals 113 and 133 can exchange records in databases 120 and 122 to synchronize databases 120 and 122. For example, the record LRPDUs in databases 120 and 122 can be exchanged via TCP connection 170. TCP connection 170 is a point-to-point communication session used when exchanging data. TCP connection 170 can be routed between target ports 141 and 151 or between other ports, depending on the example. TCP connection 170 can traverse one or more IP networks 171, which can be Open Systems Interconnection (OSI) model layer 3 networks that support point-to-point communications. As described below with reference to the various figures, portals 113 and / or 133 can manage the synchronization of databases 120 and 122 through target ports 141 and 151 using the above components on behalf of applications 111 and / or 131.

[0061] Figure 2 Schematic diagram of an exemplary proxy system implementation of a database synchronization network 200. Database synchronization network 200 includes proxy 210, proxy 230, slave node 240, and slave node 250. Database synchronization network 200 is similar to database synchronization network 100, but target ports 241 and 251 have been moved from a local system to slave nodes 240 and 250, respectively. As used herein, proxy 210 and / or 230 is a computing component that includes at least an application 211, which is substantially similar to application 111. For example, proxy 210 includes at least application 211 that can be used to distribute information between proxy 210 and a local system and / or proxy system 230. Proxy 210 may also include portal 213 and / or database 220, both of which are substantially similar to portal 113 and database 120, respectively.

[0062] The slave node 240 may be a communication component, such as a router, a switch, etc., or may be an end station, such as a camera, a mechanical actuator, or a personal computer. The slave node 240 is coupled to the agent 210 via a network connection. The slave node includes at least one target port 241 that is substantially similar to the target port 141. A communication component includes multiple target ports 241. The agent 210 and the slave node 240 operate together in a manner substantially similar to the native system 110. By placing the target port 241 in the slave node 240 instead of the agent 210, the application 211, the portal 213, and / or the database 220 may be transferred to a device (agent 210) that may be located in an independent network instead of in the slave node 240. This implementation has flexibility while the functions are substantially the same.

[0063] Proxy 230 is substantially similar to proxy 210 and includes a portal 233, an application 231, and a database 222, which may be substantially similar to portal 213, application 211, and database 220, respectively. Slave node 250 is coupled to proxy 230 and includes a target port 251 substantially similar to target port 241. Slave nodes 240 and 250 exchange LLDP messages between target ports 241 and 251 using LLDP 261 in a manner similar to LLDP 161. Slave nodes 250 and 240 may forward these messages to portal 233 and portal 213, respectively. The record information in the LLDP message may be used to establish communication between records in databases 220 and / or 222 for synchronization via IP network 271. IP network 271 may be substantially similar to IP network 171. These records may be sent via TCP connection 270, which may be substantially similar to TCP connection 170.

[0064] It should be noted that various combinations of database synchronization networks 100 and 200 may also be used within the scope of the present disclosure. For example, the local system 110 may be used to synchronize the database 120 through the agent 230 and the slave node 250. In addition, the local system 130 may be used to synchronize the database 122 through the agent 210 and the slave node 240. Various relay systems (e.g., routers and / or bridges) may be used to route communications between local systems, agents, and / or slave nodes. These components may include various capabilities as described below. On any communication device, the applications 111, 131, 211, and / or 231 may exchange information between applicants and registrants of databases 120, 122, 220, and 222 on different target ports 141, 151, 241, and 251 belonging to the same system.

[0065] Figure 3Schematic diagram of an exemplary database system 300 for database synchronization. Database system 300 can be used to implement local system 110, local system 130, agent 210 and / or agent 230. Database system 300 includes application 311 substantially similar to application 111, 131, 211 and / or 231. Specifically, application 311 is a program that uses data to synchronize with a remote system such as an adjacent database. The application is an instance of portal 313, which is substantially similar to portal 113, 133, 213 and / or 233. Portal 313 runs LRP (e.g., LRP-DS and LRP-DT) on behalf of application 311. Therefore, in addition to other processes, portal 313 manages LRPDU messages and recorded communications for synchronization. Portal 313 interacts with application 311 and database 320, which is substantially similar to database 120, 122, 220 and / or 222. The database 320 may include a requester 321 and / or a registrant 325 .

[0066] The applicant 321 is a state machine and corresponding memory space for uploading a copy of locally stored data to a registrant of an adjacent database. The registrant 325 is a state machine and corresponding memory space for receiving a copy of remotely stored data from an applicant of an adjacent database. Therefore, the database 320 may include an applicant 321 for uploading synchronization data, a registrant 325 for downloading synchronization data, or an applicant 321 and a registrant 325 for bidirectional synchronization. The applicant 321 and the registrant 325 are respectively associated with the portal 313 to ensure that control messages and data reach their intended destinations. The portal 313 is also associated with a target port to ensure that messages are received at their intended portal (e.g., portal 313).

[0067] The data in the database 320 is stored in records. A record is the smallest unit of data sent for synchronization. The record size can be configured by the application 311. The smaller the record, the more complex it is, but the larger the record, the more data needs to be sent when updating a portion of the record.

[0068] The applicant 321 includes a local record 323 and a local record header 324. The local record 323 is a record containing data used locally by the application 311. The record header is a set of predefined status information related to the corresponding record. For example, the local record header 324 contains a record number, a sequence number and / or a checksum corresponding to the local record 323. The record number indicates the corresponding record. The sequence number includes version information. For example, the sequence number may include a counter indicating the number of times the corresponding record has been modified. The checksum is error checking information and may include a number representing the sum of multiple correct numbers in the corresponding data set being transmitted. For example, the checksum may indicate the sum of multiple correct numbers in the record number and the sequence number. Therefore, when the local record 323 is updated, the corresponding local record header 324 may be identified to indicate the updated record and the updated version (e.g., sequence number).

[0069] Registry 325 contains neighbor record 326 and neighbor record header 327. Neighbor record 326 and neighbor record header 327 are similar to local record 323 and local record header 324, respectively, but are related to data used by applications in neighbor nodes / systems.

[0070] Therefore, the local database 320 may include a database of an applicant 321 to store local records 323 so as to be sent to a registrant database in an adjacent database. The local database 320 may also include a database of a registrant 325 to receive adjacent records 326 from an applicant database in an adjacent database. This record transmission may be accomplished using an LRPDU message. For example, when a local record 323 is modified, the portal 313 may send a record LRPDU message. The record LRPDU message includes a corresponding local record header 324 to notify the registrant of the adjacent database of the updated local record 323 and the updated current sequence number. The portal 313 may receive a responsive partial record list from the adjacent database, which confirms that the update of the local record is known. The portal 313 may also establish a data transmission with the portal of the adjacent node to transmit the updated local record 323. Similarly, the applicant of the adjacent database may send a record LRPDU message to the portal 313 through the adjacent portal to indicate the change to the adjacent record 326. The record LRPDU message from the adjacent database includes an updated adjacent record header 327. Registrant 325 may then respond via portal 313 with a partial list LRPDU message that includes an updated neighbor record header 327 to indicate awareness of the neighbor database update. Portal 313 may also manage the data transmission of updated neighbor records 326 from the neighbor database to registrant 325. These and other message transmission schemes for exchanging records and record headers for synchronization between supplicant 321 and registrant 325 are discussed below with reference to the various figures.

[0071] Figure 4 A protocol diagram of an exemplary method 400 for managing database synchronization. The method 400 may be implemented by the local system 110 and / or 130, the agent 210 and / or 230 in conjunction with the slave node 240 and / or 250 and / or the database system 300. The method 400 provides a mechanism for creating and maintaining a database pair including an applicant and a registrant. Managing the database pair includes maintaining synchronization between the applicant database and the registrant database. The method 400 is implemented by an application, a local portal controlling the applicant database of a local node, and an adjacent portal controlling the registrant database of an adjacent node.

[0072] In some examples, the local portal and the adjacent portal are pre-configured with the ports and addresses of the adjacent nodes related to the application. In other examples, the local portal and the adjacent portal discover the ports and addresses of the adjacent nodes related to the application through other discovery protocols. In either case, the local portal will forward the Hello LRPDU message 401 to the adjacent portal, and the adjacent portal will forward the Hello LRPDU message 403 to the local portal. This may also be referred to as the Hello LRPDU message exchange. Hello LRPDU messages 401 and 403 include an application identifier (AppId) and identify the target link between the target port of the local node and the target port of the adjacent node. AppId indicates an application, so it indicates that the sender is associated with the application that wishes to synchronize data. The target link in Hello LRPDU messages 401 and 403 indicates that the communication attempt is successful and synchronization can be started.

[0073] Accordingly, when the local portal receives the Hello LRPDU message 403, the local portal determines that the AppId is associated with the application for performing database synchronization. Then, the local portal establishes a local database in the memory of the local node as part of the database pair for use by the application. In this example, the local database includes the applicant. In addition, when the adjacent portal receives the Hello LRPDU message 401, the adjacent portal determines that the AppId is associated with the application for performing database synchronization. Then, the adjacent portal establishes an adjacent database in the memory of the adjacent node as part of the database pair. In this example, the adjacent database includes the registrant. The local portal and the adjacent portal associate the database pair with the target link respectively. Then, the local portal can control the synchronization of the local applicant database with the adjacent registrant database through the target link. Controlling the synchronization of the local applicant database with the adjacent registrant database includes sending the record information to the adjacent database in the LRPDU message through the target link, as described below. It should be noted that the LRPDU message can always be forwarded through the target link to ensure that these messages can reach the appropriate portal.

[0074] Once the Hello LRPDU message exchange has occurred and the database has been established, the application can make a record change 405 to the applicant database through the local portal. The record change 405 includes updating at least one bit of data in the corresponding record. When a record is updated, the sequence number in the corresponding record header is changed (e.g., incremented) to indicate the change. Records affected by the record change 405 can also be marked as unconfirmed by using a flag in the applicant database to indicate that the registrant is not aware of the change.

[0075] The local portal may send a record LRPDU message 407 to the registrant database of the adjacent node through the adjacent portal. The record LRPDU message 407 indicates that the record stored in the applicant database is updated. Specifically, the record LRPDU message 407 includes a record header corresponding to the record updated in the applicant database through the record change 405. These record headers include a record number and a sequence number for each updated record. In some examples, the record LRPDU message 407 also includes an update record. In other examples, the update record is transmitted between the applicant and the registrant via an independent communication method and / or via an independent protocol, such as TCP and / or LRP-DT. It should be noted that the local portal may continue to send other record LRPDU messages because the record has been updated without waiting for confirmation.

[0076] The neighboring portal, i.e., the registrant, receives the record LRPDU message 407 and updates the registrant database with the included record header and / or record. The neighboring portal may then generate a partial list LRPDU message 409 on behalf of the registrant. The partial list LRPDU message 409 serves as an acknowledgment of the record LRPDU message 407. The partial list LRPDU message 409 includes the record header included in the record LRPDU message 407, thereby indicating that the registrant is aware of and / or has received updates to these records, depending on the example. The neighboring portal sends the partial list LRPDU message 409 to the applicant database. The local portal receives the partial list LRPDU message 409 acknowledging the record LRPDU message 407. The local portal may then mark the updated record in the applicant database as confirmed by the registrant database by using a flag.

[0077] As described above, the local portal can send more record LRPDU messages 407 without waiting for the corresponding partial list LRPDU messages 409. Therefore, even if some partial list LRPDU messages 409 are received, various record updates may still not be confirmed. However, in some cases, for example, due to the suspension of updates by the applicant, all partial list LRPDU messages 409 corresponding to all record LRPDU messages 407 can be received. When this happens, the applicant database and the registrant database are synchronized. Each time a partial list LRPDU message 409 is received, the local portal will check the confirmation status of the record in the applicant database. Therefore, when the database is synchronized, the local portal can determine that all updated records in the applicant database have been confirmed by the registrant database through LRPDU messages. Based on the determination result that all updated records in the applicant database have been confirmed by the registrant database through LRPDU messages, the local portal can send all record confirmations 411 to notify the application that the applicant database and the registrant database have been synchronized. All record confirmations 411 can be instructions sent to the application in the form of a predetermined code to verify synchronization.

[0078] Optionally, the local portal may be used to maintain a timer for each record LRPDU message 407. In this case, when the timer corresponding to the record LRPDU message 407 times out and the corresponding partial list LRPDU message 409 is not received, the local portal may generate a failure notification 412 to the application. The local portal may not automatically resend the unconfirmed record LRPDU message 407. The neighboring portal and / or the corresponding target port may include a limited receive buffer. Automatic retransmission may cause the buffer to exceed the limit due to the presence of other record LRPDU messages 407. Accordingly, the application can determine how to proceed by resending the unconfirmed record LRPDU message 407, waiting for a longer time, rolling back the corresponding record update to the applicant database, etc.

[0079] The neighboring portal sends a complete list LRPDU message 413 on behalf of the registrant. The complete list LRPDU message 413 includes record headers corresponding to all records in the registrant's database (but not the records themselves). The complete list LRPDU message 413 can be sent periodically and received by the applicant through the local portal. The complete list LRPDU message 413 can serve as an acknowledgment of one or more previously sent record LRPDU messages 407, for example, when the local portal / applicant has not received the partial list LRPDU message 409. In addition, the applicant can also use the complete list LRPDU message 413 to determine when the registrant has not received the record LRPDU message 407. For example, the applicant can compare the record header in the complete list LRPDU message 413 with the record header in the applicant's database. When the record header in the applicant's database matches the record header in the complete list LRPDU message 413, the applicant can determine that the registrant has received all record updates and then send an all record confirmation 411. When the record headers in the supplicant's database do not match the record headers in the complete list LRPDU message 413, the supplicant may determine that the registrant did not receive certain record updates and may retransmit these record updates.

[0080] Method 400 also manages other situations. For example, a connection interruption 415 may occur. The connection interruption 415 may be due to a failure of a node or link between the target port of the local portal and the target port of the adjacent portal. The connection interruption 415 may also be due to the occurrence of data traffic congestion. Hello LRPDU messages are exchanged regularly, such as Hello LRPDU messages 401 and 403, and if this exchange fails, the portal will know that a connection interruption 415 has occurred. When the exchange of Hello messages fails, the local portal generates a disconnect code 416 for the application. The disconnect code 416 indicates to the application that the exchange of Hello LRPDU messages has failed and a connection interruption 415 has occurred. The applicant can then determine the action to take in response to the connection interruption 415. For example, the application may decide to reset the database pair after reestablishing the connection, in which case the method 400 starts over once the Hello LRPDU messages 401 and 403 have been exchanged.

[0081] For another example, the application may decide to retain the database pair and reestablish the connection. If successful, this method avoids the need to resend all records in the applicant database to the registrant database. The application may send a maintain database command 417 to the local portal. Therefore, the local portal may receive a maintain database command 417 from the application to maintain the applicant database in the memory of the local node in the presence of a disconnect code 416. When the local portal receives the command to maintain the database pair, the local portal stops sending the record LRPDU message 407 before receiving a complete list LRPDU message 418 from the registrant database through an adjacent portal. For example, the local portal may reset the notification of the applicant database after an unsuccessful exchange of Hello LRPDU messages (e.g., a connection interruption 415 occurs) so that the timer does not send a record LRPDU message before receiving a complete list LRPDU message 418.

[0082] The neighboring portal performs a similar process with the application in the neighboring node. After successfully exchanging the Hello LRPDU message, the registrant sends a complete list LRPDU message 418 through the neighboring portal. The complete list LRPDU message 418 is substantially similar to the complete list LRPDU message 413, and therefore contains all the record headers in the registrant database. If any application in the local node or the remote node chooses to reset the database pair, the method 400 restarts. For example, if the neighboring portal resets the registrant database, and the local portal does not reset the applicant database, the complete list LRPDU message 418 is empty, and the applicant resends all records. For another example, if the neighboring portal does not reset the registrant database, and the local portal does not reset the applicant database, the complete list LRPDU message 418 contains record headers that do not match the applicant database, and the database pair is reset. However, if both applications choose to maintain the database pair, the record headers contained in the complete list LRPDU message 418 are the same or similar to the record headers in the applicant database (for example, due to the omission of the record LRPDU message 407). In this case, the requestor may determine the necessary steps to resynchronize the database pair.

[0083] Accordingly, after successfully exchanging the Hello message, the local portal may receive a complete list LRPDU message 418 from the registrar database of the neighboring node. The complete list LRPDU message 418 includes record headers corresponding to all records in the registrar database. Then, the local portal and / or the applicant database may compare the record headers in the complete list LRPDU message 418 with the record headers in the applicant database to resynchronize the applicant database with the registrar database. In the first case, the local portal may determine that there is a match between the record header in the applicant database and the record header in the registrar database included in the complete list LRPDU message 418. In this case, the database pair is synchronized. Therefore, based on the determination result of the match, the portal may notify the application that the applicant database is synchronized with the registrar database by sending all record confirmations 411, etc. In the second case, the local portal may determine that there is a mismatch between one or more record headers in the applicant database and one or more record headers in the complete list LRPDU message 418. This occurs when the record LRPDU message 407 is lost during the connection interruption 415. The portals may compare the record headers to determine which records were not sent to the registrant database. The local portal may then send a record LRPDU message 407 to the registrant database via the neighboring portal. The record LRPDU message 407 includes updated record headers as needed to handle the mismatch. In either case, the database pair is synchronized without resetting the database pair and without resending all records in the applicant database.

[0084] Optionally, the local portal may also request a complete list LRPDU message 421 on behalf of the applicant. This enables the applicant to check database synchronization on demand. In this case, the local portal sends a request complete list LRPDU message 419 to the registrant database through the neighboring portal. The neighboring portal and / or the registrant receives the request complete list LRPDU message 419 and sends a complete list LRPDU message 421 to the applicant through the local portal. The complete list LRPDU message 421 is substantially similar to the complete list LRPDU messages 418 and 413. The local portal, that is, the applicant, may receive the complete list LRPDU message 421 from the registrant database in response to the request complete list LRPDU message 419. Therefore, the applicant may compare the record headers in the complete list LRPDU message 421 with the record headers in the applicant database to determine whether the database pair is synchronized and / or determine which records need to be sent to the registrant to synchronize the database pair.

[0085] It should be noted that the LRPDU messages and notifications in method 400 are shown in sequence to illustrate various exemplary functions of the present disclosure. These messages / notifications can be used in combination. For example, Hello LRPDU messages 401 and 403 and complete list LRPDU messages 413, 418 and 421 are exchanged regularly according to predefined timers and trigger events as described above. In addition, during normal operation of the applicant database with or without intervention actions, record changes 405 and the resulting record LRPDU messages 407 and partial list LRPDU messages 409 can be repeatedly exchanged. In addition, all record confirmations 411, failure notifications 412, disconnect codes 416 and maintain database commands 417 can be triggered whenever the corresponding situation occurs. Therefore, Figure 4 The order of LRPDU messages and notifications in are exemplary and should not be considered limiting unless otherwise specified herein.

[0086] In addition, any number of LRPDUs can be concatenated in one LRP-DT Edge Control Protocol Data Unit (ECPDU), up to the maximum size of a layer 2 frame. An LRPDU cannot be split across multiple LPR-DT ECP ECPDUs. When using TCP, the size of the LRPDU is limited to a 16-bit length field.

[0087] Figure 5An exemplary encoding of a Hello LRPDU message 500 is shown. The Hello LRPDU message 500 may implement the Hello LRPDU messages 401 and / or 403. Therefore, the Hello LRPDU message 500 may be used to maintain synchronization of databases in the local system 110 and / or 130, the proxy 210 and / or 230, the slave node 240 and / or 250, and / or the database system 300.

[0088] The Hello LRPDU message 500 is encoded in a TLV format. For example, the TLV format used herein can support up to 65535 octets of data fields. The Hello LRPDU message 500 includes a type field 501. The length of the type field 501 is 1 octet and the offset is 0 octets. The value of the type field 501 can be set to 1 to indicate the Hello LRPDU message 500. The Hello LRPDU message 500 also includes a length field 503. The length field 503 has a length of 2 octets and an offset of 1 octet. The length field 503 can include a 2-octet integer, the first byte (offset 1) including the 8 most significant bits. The 2-octet integer includes the length of the data field (e.g., the rest of the message). Therefore, a TLV length field 503 of 0 indicates that there is no data field. The length field 503 (first octet and second octet, indicated by the type field) of the Hello LRPDU message 500 contains the length of all fixed length fields plus all TLVs in the data field.

[0089] The remaining data is 0 to 65535 octets in length and is offset by 3 octets at the first data field. The data field of the Hello LRPDU message 500 contains information sent by an instance of the Send Hello state machine of the applicant, registrant, and / or corresponding portal. The Hello LRPDU message 500 contains some fixed-size fields followed by a series of TLVs in the data field. That is, the tenth octet after the TLV length field 503 can be another LRPDU type field.

[0090] The Hello LRPDU message 500 also includes an AppId field 505. The AppId field 505 includes an AppId that identifies the application associated with the sender portal. The AppId field 505 includes an Organizationally Unique Identifier (OUI) or a Company Identifier (CID) that is 3 octets in length and an Application Sub-ID that is 1 octet in length and 3 octets in offset, for a total of 4 octets. It should be noted that the OUI or CID owner is responsible for managing the use of the Application Sub-ID. It should also be noted that the AppId is used in multiple contexts including state machine variables, not just in the Hello LRPDU message 500.

[0091] The Hello LRPDU message 500 also includes a Hello Status field 507. The Hello Status field 507 is a 4-bit enumerated field located in the most significant bit of an octet and includes one of the following values: Hello Status Looking (hsLooking), Hello Status Connecting (hsConnecting), Hello Status Connected (hsConnected). The value of hsLooking can be set to indicate that the corresponding portal has not received a successful Complete Portal creation request. The value of hsConnecting can be set to indicate that the corresponding portal has received a successful Complete Portal creation request and a Hello LRPDU message 500 with an hsLooking status. In this case, the portal is ready to receive all LRPDU messages. The value of hsConnected can be set to indicate that the corresponding portal is ready to transmit application data. In this case, the portal is allowed to send all LRPDU messages. The Hello Status field 507 can also include an Error Status field 508. The Error Status field 508 can include the lowest 4 bits of information in a byte and can indicate errors such as database overflow.

[0092] The Hello LRPDU message 500 also includes a local portal number (My Portal Number) field 509. The local portal number field 509 includes a 4-octet number that identifies the sender's portal. The identification number is unique among all portals that share the same LRP-DT instance. The length of this field is 4 octets because the proxy system can proxy any number of slave systems, each of which can have a large number of target ports. In addition, the proxy system can establish a TCP connection with another similar proxy system. Each proxy system uses a value of the local portal number for each target port that the proxy system proxy. The local portal number field 509 is used in other LRPDU messages to identify which pair of target ports 141, 151, 241 and 251, which pair of portals 113, 133, 213 and 233, and which database 120, 122, 220, and 222 are associated with a given record LRPDU, a partial list LRPDU, a complete list LRPDU, or a request for a complete list LRPDU.

[0093] The Hello LRPDU message 500 also includes a Hello Time field 511. The Hello Time field 511 includes 2 octets representing the lifetime of the Hello LRPDU message 500. The first octet of the Hello Time field 511 is the most significant octet of the 16-bit number of seconds (0 to 65535 or 30 to 65535) that makes the Hello LRPDU message 500 valid. This field cannot be sent when the value is between 1 and 29 (1 and 29 are inclusive).

[0094] The first four TLVs in the Hello LRPDU message 500 are one of the Local Chassis ID TLV 513, Local Port ID TLV 515, Neighbor Chassis ID TLV 517, and Neighbor Port ID TLV 519, in any order. Next comes 0 or 1 Application Information TLV 521.

[0095] The type field of the Local Chassis ID TLV 513 is set to the value of typeMyChassisId. The data field of the Local Chassis ID TLV 513 contains the value sent in the LLDP Chassis ID TLV specified by the LLDP instance named in the complete portal creation request that creates the portal that sends the Local Chassis ID TLV 513. Specifically, the value contained in the Local Chassis ID TLV 513 identifies the local node (e.g., machine) that serves as the sender of the Hello LRPDU message 500. Such a local node includes a local system or a slave system (e.g., including or coupled to a local registrar or a local supplicant or a local registrar and a local supplicant) for establishing and / or maintaining a database pair.

[0096] The type field of the Local Port ID TLV 515 is set to the value of typeMyPortId. The data field of the Local Port ID TLV 515 contains the same value as the value sent in the LLDP Portal ID TLV specified by the LLDP instance named in the complete portal creation request that creates the portal that sends the Local ID TLV 515. Specifically, the value contained in the Local Port ID TLV 515 identifies the target port on the local node (e.g., the local system or a slave node) that is attempting to establish and / or maintain a database pair. The chassis ID and port ID together uniquely represent the local portion of the target link for the LRPDU message transmission.

[0097] The type field of the neighbor chassis ID TLV 517 is set to a value of typeNeighborChassisId. The data field of the neighbor chassis ID TLV 517 has the same format as the local chassis ID TLV 513 and contains the chassis ID of the neighbor portal associated with the local portal. Specifically, the value contained in the neighbor chassis ID TLV 517 identifies the neighbor node (e.g., machine) that serves as the destination of the Hello LRPDU message 500. The neighbor node includes a local system or a slave system (e.g., including or coupled to a neighbor registrar or a neighbor supplicant or a neighbor registrar and a neighbor supplicant) for establishing and / or maintaining a database pair.

[0098] The type field of the neighbor port ID TLV 519 is set to the value of typeNeighborPortId. The data field of the neighbor port ID TLV 519 has the same format as the local port ID TLV 515 and contains the port ID of the neighbor portal associated with the local portal. Specifically, the value contained in the neighbor port ID TLV 519 identifies the target port on the neighboring node (e.g., the local system or the slave node) used to establish and / or maintain the database pair. The neighbor chassis ID and the neighbor port ID together uniquely represent the neighboring portion of the target link for the LRPDU message transmission. Therefore, the Hello LRPDU 500 represents the target link as a local chassis ID identifying the local node, a local port ID identifying the target port on the local node, a neighbor chassis ID identifying the neighboring node, and a neighbor port ID identifying the target port on the neighboring node.

[0099] The Application Information TLV 521 field is set to the value of typeAppInfo. The data field of the Application Information TLV 521 contains the information provided through the Enable Portal Creation Request. The data is provided to the application on the destination side through the portal status indication on the destination side of the LRP-DT connection. This data may be opaque and cannot be interpreted by the LRP. Application Information TLV 521 is optional.

[0100] Accordingly, the type field 501 is 1 octet and the offset is 0 octets; the length field 503 is 2 octets and the offset is 1 octet; the AppId field 505 is 4 octets and the offset is 3 octets; the Hello status field 507 is 1 octet and the offset is 7 octets; the local portal number field 509 is 4 octets and the offset is 8 octets; the Hello time field 511 is 2 octets and the offset is 12 octets; and the remaining TLVs 513 to 521 are variable length and start at an offset of 14 octets.

[0101] Figure 6 An exemplary encoding of a record LRPDU message 600 is shown. The record LRPDU message 600 may implement the record LRPDU message 407. Thus, the record LRPDU message 600 may be used to maintain synchronization of database pairs in the local system 110 and / or 130, the agent 210 and / or 230, the slave node 240 and / or 250, and / or the database system 300. The record LRPDU message 600 includes a type field 601 and a length field 603, which are similar to the type field 501 and the length field 503, respectively. The type field 601 may contain a value of 2, indicating a record LRPDU message 600 (e.g., typeRecordLRPDU), while the length field 603 contains the length of the record LRPDU message 600. The first 2 octets of the data field of the record LRPDU message 600 are a local portal number field 609. The local portal number field 609 encodes the chassis ID, port ID, and appId of the sender portal. This is the same value sent in the Hello LRPDU message 500 for the same portal. Next are zero or more records in the Record field 630.

[0102] Each record includes a record number field 631, a sequence number field 633, a checksum field 635, and optionally a data length field 637 and an application data field 639. The record number field 631 contains data indicating the record in the applicant database that has been updated. The sequence number field 633 contains data indicating the version number and / or the number of changes associated with the corresponding record. The checksum field 635 includes error correction data, such as a 2-octet value calculated based on the values ​​contained in the corresponding record (e.g., the record number field 631, the sequence number field 633, the data length field 637, and / or the value in the application data field 639). If present, the data length field 637 indicates the length of the data in the corresponding record and / or the length of the application data field 639. If present, the application data field 639 contains the update record sent from the applicant database to the registrant database.

[0103] Accordingly, the record LRPDU message 600 may include one or more record numbers indicating the records updated in the applicant database and one or more sequence numbers identifying the updates included in the records updated in the applicant database. In addition, the type field 601 is 1 octet and the offset is 0 octets; the length field 603 is 2 octets and the offset is 1 octet; the local portal number field 609 is 4 octets and the offset is 3 octets; the record field 630 is variable length and the offset is 7 octets. Furthermore, each record contains a record number field 631 of 4 octets at an offset of 0 octets, a sequence number field 633 of 4 octets at an offset of 4 octets, a checksum field 635 of 8 octets at an offset of 2 octets, a data length field 637 of 10 octets at an offset of 2 octets, and an application data field 639 of 12 octets at an offset of 0 to 65520 octets, where the record offset is measured from the beginning of the record.

[0104] Figure 7 An exemplary encoding of a partial list LRPDU message 700 is shown. The partial list LRPDU message 700 may implement the partial list LRPDU message 409. Thus, the partial list LRPDU message 700 may be used to maintain synchronization of database pairs in the local system 110 and / or 130, the agent 210 and / or 230, the slave node 240 and / or 250, and / or the database system 300. The partial list LRPDU message 700 includes a type field 701 and a length field 703, which are similar to the type field 501 and the length field 503, respectively. The similar field 701 may include a value of 3, indicating a partial list LRPDU message 700 (e.g., typePartialListLRPDU), and the length field 703 includes the length of the partial list LRPDU message 700.

[0105] The first 2 octets of the data field of the partial list LRPDU message 700 are the local portal number field 709. The local portal number field 709 encodes the chassis ID, port ID, and appId of the sender portal. This is the same value sent in the Hello LRPDU message 500 for the same portal. Next are 0 or more record headers 730, which are substantially similar to the record 630, but do not contain record data. Specifically, each record header 730 includes a record number field 731, a sequence number field 733, and a checksum field 735, which are substantially similar to the record number field 631, the sequence number field 633, and the checksum field 635, respectively. In addition, the values ​​included in the record number field 731 and the sequence number field 733 are added by the registrant and match the corresponding values ​​of the corresponding record 630 in the record LRPDU message 600 (for example, contained in the record LRPDU message 600 of the applicant). Therefore, the record header 730 confirms the receipt of the record 630.

[0106] Thus, the partial list LRPDU message 700 acknowledges the record LRPDU message 600, which includes at least one record header 730 acknowledging at least one update record 630. In addition, the record header 730 includes a record number in a record number field 731 indicating an update record (e.g., record 630) and a sequence number in a sequence number field 733 identifying an update contained in the update record (e.g., record 630).

[0107] Figure 8 An exemplary encoding of a complete list LRPDU message 800 is shown. The complete list LRPDU message 800 may implement the complete list LRPDU messages 413, 418, and / or 421. Thus, the complete list LRPDU message 800 may be used to maintain synchronization of database pairs in the local system 110 and / or 130, the agent 210 and / or 230, the slave node 240 and / or 250, and / or the database system 300. The complete list LRPDU message 800 includes a type field 801 and a length field 803, which are similar to the type field 501 and the length field 503, respectively. The type field 801 may include a value of 4, indicating a complete list LRPDU message 800 (e.g., typeCompleteListLRPDU), and the length field 803 includes the length of the complete list LRPDU message 800.

[0108] The first 2 octets of the data field of the Complete List LRPDU message 800 are the Local Portal Number field 809. The Local Portal Number field 809 encodes the chassis ID, port ID, and appId of the sending portal. This is the same value sent in the Hello LRPDU message 500 for the same portal. Next are the First Record Number field 823 and the Last Record Number field 825, both of which are 4 octets long and include the minimum and maximum record number values ​​included in the Complete List LRPDU message 800. For example, the First Record Number field 823 and the Last Record Number field 825 contain the first record and the last record, respectively, stored in the registrant.

[0109] Next are zero or more record headers 830, which are substantially similar to record header 730. However, record header 830 includes all record headers in the registrant database, rather than just the record headers corresponding to the confirmed update record. Each record header 830 includes a record number field 831, a sequence number field 833, and a checksum field 835, which are substantially similar to record number field 731, sequence number field 733, and checksum field 735, respectively.

[0110] Each record number 831 sent in the complete list LRPDU message 800 contains a value that is greater than or equal to the value in the first record number field 823 and less than or equal to the value in the last record number field 825. The first record number field 823 and the last record number field 825 allow the complete list of records known to the registrant to be split between more than one complete list LRPDU message 800. The pairs of first record number and last record number in all complete list LRPDU messages 800 comprise a complete list of records that can cover all possible record numbers from 0 to 4294967295.

[0111] Fig. 9 The flowchart of an exemplary method 900 for establishing a database pair in the local system 110 and / or 130, the proxy 210 and / or 230, the slave node 240 and / or 250, and / or the database system 300. The method 900 uses the signaling in the method 400, such as the Hello LRPDU message 401, 403, and / or 500. For clarity of discussion, the method 900 is discussed from the perspective of the local node operating the applicant database, but the method 900 may also be performed in whole or in part on a node operating the registrant (e.g., a local node or a neighboring node).

[0112] When the local node wishes to establish a database pair to synchronize with the adjacent node, method 900 begins. At step 901, the local node receives a Hello message. The Hello message includes AppId and a target link between the target port of the local node and the target port of the adjacent node. When the local node is a native system, the target port is located on the local node. When the local node is an agent, the target port is located on the slave node. The Hello message can be a Hello LRPDU message, such as Hello LRPDU messages 401, 403 and / or 500. In addition, the Hello LRPDU message can represent the target link as a local frame ID that identifies the local node or the corresponding slave node, a local port ID that identifies the target port on the local node or the corresponding slave node, an adjacent frame ID that identifies the adjacent node or the corresponding slave node, and an adjacent port ID that identifies the target port on the adjacent node or the corresponding slave node. In order to complete the Hello message exchange, the local node also sends a corresponding Hello message to the adjacent node. This Hello message can be substantially similar to the Hello message with different local portal numbers received by the local node. For example, a Hello message sent by a local node contains a local portal number associated with the local node, and a Hello message received by the local node contains a local portal number associated with a neighboring node. These messages can be sent in any order.

[0113] In step 903, the local node and / or the corresponding portal determines that AppId is associated with the application for performing database synchronization. Based on the determination result of the association between AppId and database synchronization, in step 905, a local database is established in the memory of the local node. The local database is used as part of a database pair for application use. The database pair includes an adjacent database established in an adjacent node (for example, through a portal of an adjacent node). In some examples, the local database may include an applicant database to store local records sent to a registrant database in an adjacent database. In some examples, the local database includes a registrant database to receive adjacent records from an applicant database in an adjacent database. In some examples, the local database includes both an applicant database and a registrant database.

[0114] In step 907, the database pair is associated with the target link (e.g., the slave node corresponding to the local system and / or the agent). This association ensures that the LRPDU message forwarded to the applicant / registrant reaches the correct portal because the portal is located on the local node of the target port, or because the target port is located on a slave node that forwards these messages to the agent containing the portal and running on the local node.

[0115] In step 909, the local node / portal starts to control / manage the synchronization of the local database with the adjacent database through the target link. This control can be realized by the target link in the LRPDU message to generate the record information to the adjacent database. These record information can include records, record headers or combinations thereof. For example, these LRPDU messages can include more Hello LRPDU messages 500, record LRPDU messages 600, partial list LRPDU messages 700, complete list LRPDU messages 800 and / or any LRPDU message in method 400.

[0116] Fig.10 Flowchart of an exemplary method 1000 for managing database pair synchronization after completing method 900. Method 1000 may be performed on local system 110 and / or 130, agent 210 and / or 230, slave node 240 and / or 250, and / or database system 300. Method 1000 employs the signaling in method 400. In addition, method 1000 may employ LRPDU messages, such as Hello LRPDU message 500, record LRPDU message 600, partial list LRPDU message 700, complete list LRPDU message 800, and / or combinations thereof. For clarity of discussion, method 1000 is discussed from the perspective of a local node operating an applicant database, but method 1000 may also be performed in whole or in part on a node operating a registrant (e.g., a local node or a neighboring node).

[0117] In step 1001, the application changes one or more records in the applicant database. Accordingly, the portal of the local node sends one or more record LRPDU messages to the registrant database of the adjacent node, for example, through the adjacent portal. The record LRPDU message indicates that the records stored in the applicant database of the local node are updated, and may also include these updated records. For example, the record LRPDU message may include one or more record numbers indicating the records updated in the applicant database and one or more sequence numbers identifying the updates contained in the records updated in the applicant database. The updated record may also be marked as unconfirmed in the applicant database.

[0118] In step 1003, the portal receives one or more LRPDU messages confirming the record LRPDU message in step 1001. In some examples, the LRPDU message confirming the record LRPDU message includes a partial list LRPDU message. The partial list LRPDU message includes at least one record header confirming at least one update record in step 1001. The at least one record header includes a record number indicating the update record in step 1001 and a serial number of updates contained in the update record in step 1001. In some examples, the LRPDU message confirming the record LRPDU message may include a complete list LRPDU message. The complete list LRPDU message includes record headers corresponding to all records in the registrant database. In addition, the complete list LRPDU message includes a first record number field indicating the first record stored in the registrant database and a last record number field indicating the last record stored in the registrant database. Moreover, the record header includes a record number indicating the record stored in the registrant database and a serial number identifying the updates contained in the record stored in the registrant database.

[0119] In step 1005 , at least one update record in the applicant database is marked as confirmed by the registrant database according to the record header in the partial list LRPDU message and / or the complete list LRPDU message in step 1003 .

[0120] In step 1007, the portal / applicant may determine that all update records in the applicant database are confirmed by the registrant database through the LRPDU message. Based on the result of the determination in step 1007 that all update records in the applicant database are confirmed by the registrant database through the LRPDU message, in step 1009, the portal / applicant notifies the application that the applicant database and the registrant database are synchronized.

[0121] In some cases, the record LRPDU message may not reach the registrant, and / or the partial list LRPDU message may be discarded on the way back to the applicant. In these cases, in optional step 1011, when the record LRPDU message timer expires and the corresponding partial list LRPDU message is not received, the portal generates a failure notification to the application.

[0122] Step 1013 is also optional. In some examples, the portal / applicant may be configured to send a request complete list LRPDU message to the registrant database. The registrant / neighboring portal responds with a complete list LRPDU message. Thus, the portal / applicant on the local node receives a complete list LRPDU message from the registrant database in response to the request complete list LRPDU message.

[0123] Fig.11 Flowchart of an exemplary method 1100 for managing database synchronization in the event of a connection interruption after executing method 900 and during / after executing method 1000. Method 1100 may be executed on local system 110 and / or 130, agent 210 and / or 230, slave node 240 and / or 250, and / or database system 300. Method 1100 employs the signaling in method 400. In addition, method 1100 may employ LRPDU messages, such as Hello LRPDU message 500, record LRPDU message 600, partial list LRPDU message 700, complete list LRPDU message 800, and / or combinations thereof. For clarity of discussion, method 1100 is discussed from the perspective of a local node operating an applicant database, but method 1100 may also be executed in whole or in part on a node operating a registrant (e.g., a local node or a neighboring node).

[0124] When the exchange of Hello LRPDU messages fails, indicating that there is a connection interruption, method 1100 begins. In step 1101, a disconnect code is generated for the application. The disconnect code indicates that the exchange of Hello LRPDU messages failed. This also indicates that it is unlikely that more messages sent to the neighboring node / registrant will be received, and previously unacknowledged messages may not have reached the registrant.

[0125] The applicant may determine to reset the database pair when the connection is reestablished. In this case, method 900 is used. However, the applicant may also determine to resynchronize the current applicant database with the registrant database when the connection is reestablished. In this case, in step 1103, the portal receives a command from the application to maintain the applicant database in the memory of the local node even if there is a disconnect code.

[0126] In step 1105, the portal resets the notification timer in the applicant database after the unsuccessful exchange of Hello messages. This enables not to send the record LRPDU message until the complete list LRPDU message is received after the connection is reestablished.

[0127] Hello LRPDU messages may be sent periodically to attempt to reestablish the connection. When the registrant database receives a Hello LRPDU message after the connection is broken, the registrant responds with a Complete List LRPDU message. Accordingly, in step 1107, after successfully exchanging the Hello LRPDU messages, the applicant / portal receives a Complete List LRPDU message from the registrant database of the neighboring node. The Complete List LRPDU message includes record headers corresponding to all records in the registrant database.

[0128] In step 1109, the portal / applicant compares the record header in the complete list LRPDU message with the record header stored in the applicant database to resynchronize the applicant database with the registrant database. Specifically, in step 1111, the portal / application determines whether there is a record mismatch between the record header in the complete list LRPDU message and the record header in the applicant database.

[0129] When the portal / applicant determines that there is a mismatch between one or more record headers in the applicant database and one or more record headers in the complete list LRPDU message, the method 1100 proceeds to step 1113. The mismatch indicates that at least one previous record LLRPDU message is lost. Therefore, the applicant determines which record updates are not represented in the complete list LRPDU message. At step 1113, the applicant / portal sends one or more record LRPDU messages to the registrant database. The record LRPDU message contains the updated record header as needed to handle the mismatch and synchronize the database pair.

[0130] When the portal / applicant determines that there is a match between the record header in the applicant database and the record header in the registrant database, method 1100 proceeds to step 1115. Based on the determination result of the match, in step 1115, the portal / applicant may notify the application that the applicant database and the registrant database are synchronized.

[0131] Fig.12 1 is a schematic diagram of an exemplary network node 1200 for managing database synchronization according to an embodiment of the present disclosure. The network node 1200 is suitable for implementing the disclosed examples / embodiments described herein. For example, the network node 1200 can be used to implement the local system 110 / 130, the agent 210 / 230, the slave node 240 / 250, its combination and / or any local node and / or neighboring node described herein. For example, the network node 1200 can implement the database system 300.

[0132] The network node 1200 includes a downlink port 1220, an uplink port 1250 and / or a transceiver unit (Tx / Rx) 1210, and the transceiver unit 1210 includes a transmitter and / or a receiver for communicating data in an uplink and / or downlink direction through a network. The network node 1200 also includes a processor 1230 and a memory 1232. The processor 1230 includes a logic unit and / or a central processing unit (CPU) for processing data, and the memory 1232 is used to store data. The network node 1200 may also include an optical-to-electrical (OE) component, an electric-to-optical (EO) component and / or a wireless communication component coupled to the uplink port 1250 and / or the downlink port 1220 for communicating data through an optical communication network or a wireless communication network. The network node 1200 may also include an input and / or output (I / O) device for sending data to and receiving data from a user. These I / O devices may include output devices, such as a display for displaying video data, a speaker for outputting audio data, etc. I / O devices may also include input devices, such as a keyboard, a mouse, a trackball, etc., and / or corresponding interfaces for interacting with these output devices.

[0133] Processor 1230 is implemented by hardware and software. Processor 1230 can be implemented as one or more CPU chips, cores (e.g., multi-core processors), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). Processor 1230 communicates with downstream port 1220, Tx / Rx 1210, upstream port 1250, and memory 1232. Processor 1230 includes LRP-DS module 1214. LRP-DS module 1214 implements the above-mentioned disclosed embodiments, such as methods 400, 900, 1000, 1100, and / or any other methods / mechanisms described herein. In addition, LRP-DS module 1214 can send, receive, and / or process LLPDU messages, such as Hello LRPDU messages 500, record LRPDU messages 600, partial list LRPDU messages 700, complete list LRPDU messages 800, and / or combinations thereof. For example, the LRP-DS module 1214 can be used to establish a connection through a Hello LRPDU message and establish a database pair that needs to be synchronized. For another example, the LRP-DS module 1214 can be used to notify the application when all records of the applicant have been confirmed by the registrant and / or notify the application when the registrant cannot confirm the record update. For another example, the LRP-DS module 1214 can be used to resynchronize the database pair after the connection is disconnected without sending all records of the applicant to the registrant. Therefore, the LRP-DS module 1214 improves the function of the network node 1200. In addition, the LRP-DS module 1214 solves the memory management problem specific to the computer field. Moreover, the DS module 1214 affects the conversion of the network node 1200 to different states. The LRP-DS module 1214 can be implemented with instructions stored in the memory 1232 and executed by the processor 1230 (for example, with a computer program product stored on a non-transient medium).

[0134] The memory 1232 includes one or more memory types, such as a disk, a tape drive, a solid-state drive (SSD), a read only memory (ROM), a random access memory (RAM), a flash memory, a ternary content addressable memory (TCAM), a static random access memory (SRAM), etc. The memory 1232 can be used as an overflow data storage device to store programs when they are selected for execution and to store instructions and data read during program execution.

[0135] Fig.13 Schematic diagram of an exemplary device 1300 for establishing a database pair. Device 1300 can be used to implement method 400 and / or method 900. Device 1300 includes a receiving module 1301 for receiving a Hello message. The Hello message includes an AppId and a target link between a local node and an adjacent node. Device 1300 also includes a determining module 1303 for determining that the AppId is associated with an application for performing database synchronization. Device 1300 also includes a database pair establishing module 1305 for establishing a local database in a local node for use by an application as part of a database pair. The database pair includes adjacent databases of adjacent nodes. Device 1300 also includes an associating module 1307 for associating a database pair with a target link. The device also includes a synchronization control module 1309 for controlling the synchronization of a local database with an adjacent database through a target link.

[0136] Fig.14Schematic diagram of an exemplary device 1400 for managing database pair synchronization. Device 1400 can be used to implement method 400 and / or method 1000. Device 1400 includes a sending module 1401, which is used to send one or more record LRPDU messages to the registrant database of the adjacent node. The record LRPDU message indicates that the record stored in the applicant database of the local node is updated. Device 1400 also includes a receiving module 1403, which is used to receive one or more LRPDU messages that confirm the record LRPDU message. Device 1400 also includes a memory module 1405, which is used to mark at least one update record in the applicant database as confirmed by the registrant database. Device 1400 also includes a determination module 1407, which is used to determine that all update records in the applicant database have been confirmed by the registrant database through the LRPDU message. Device 1400 also includes a notification module 1409, which is used to notify the application that the applicant data has been synchronized with the registrant database according to the determination result that all update records in the applicant database have been confirmed by the registrant database through the LRPDU message.

[0137] Fig.15 Schematic diagram of an exemplary device 1500 for maintaining database synchronization in the event of a connection interruption. Device 1500 can be used to implement method 400 and / or method 1100. Device 1500 includes a disconnect module 1501, which is used to generate a disconnect code for an application. The disconnect code indicates that the exchange of the Hello LRPDU message fails. Device 1500 also includes a command module 1503, which is used to receive a command from the application to maintain the applicant database in the memory of the local node in the presence of the disconnect code. Device 1500 also includes a receiving module 1505, which is used to receive a complete list LRPDU message from the registrant database of the adjacent node after successfully exchanging the Hello message. The complete list LRPDU message includes record headers corresponding to all records in the registrant database. Device 1500 also includes a record comparison module 1507, which is used to compare the record header in the complete list LRPDU message with the record header in the applicant database to resynchronize the applicant database with the registrant database.

[0138] In one embodiment, a node or element includes: a sending module, which is used to send one or more record link local registration protocol data unit (Link-Local Registration Protocol Data Unit, LRPDU) messages to the registrar database of an adjacent node, wherein the record LRPDU message indicates an update to a record in an applicant database storing the local node; and a receiving module, which is used to receive one or more LRPDU messages confirming the record LRPDU message. The node or element also includes: a memory module, which is used to mark at least one update record in the applicant database as confirmed by the registrar database. The node or element also includes: a determination module, which is used to determine that all update records in the applicant database have been confirmed by the registrar database through LRPDU messages; a notification module, which is used to notify an application that the applicant database and the registrar database have been synchronized based on the determination result that all update records in the applicant database have been confirmed by the registrar database through LRPDU messages.

[0139] A first component is directly coupled to a second component when there is no intermediate component other than a line, track, or other medium between the first component and the second component. A first component is indirectly coupled to a second component when there is an intermediate component other than a line, track, or other medium between the first component and the second component. The term "coupled" and its variations include direct coupling and indirect coupling. Unless otherwise specified, the use of the term "about" refers to ±10% of the number described below.

[0140] Although the present disclosure provides a plurality of specific embodiments, it should be understood that the disclosed systems and methods may also be embodied in a variety of other specific forms without departing from the spirit or scope of the present invention. The examples disclosed herein should be considered illustrative rather than restrictive, and the present disclosure is not limited to the details given herein. For example, various elements or components may be combined or integrated in another system, or certain features may be omitted or not implemented.

[0141] In addition, without departing from the scope of the present disclosure, the techniques, systems, subsystems and methods described and illustrated as discrete or separate in various embodiments may be combined or merged with other systems, components, techniques or methods. Other changes, substitutions and replacement examples are obvious to those skilled in the art and do not depart from the spirit and scope of the present disclosure.

Claims

1. A method implemented in a local node, characterized in that: The method comprises: Generate a disconnect code for the application, the disconnect code indicating that an exchange of a Hello link local registration protocol data unit LRPDU message failed; receiving a command from the application to maintain a requestor database in a local node despite the presence of the disconnect code; receiving a complete list LRPDU message from a registrant database of a neighboring node, wherein the complete list LRPDU message includes record headers corresponding to all records in the registrant database; The record headers in the Complete List LRPDU message are compared with the record headers in the requestor database.

2. The method according to claim 1, characterized in that: Also includes: A notification timer in the applicant database is reset.

3. The method according to claim 1, characterized in that Also includes: determining that there is a mismatch between one or more record headers in the requestor database and one or more record headers in the complete list LRPDU message; A record LRPDU message is sent to the registrant database, wherein the record LRPDU message includes an updated record header that handles the mismatch.

4. The method according to claim 1, characterized in that: Also includes: Determining that there is a match between a record header in the applicant database and a record header in the registrant database; According to the determination result of the match, the application is notified that the applicant database and the registrant database are synchronized.

5. The method according to claim 1, characterized in that The applicant database is associated with the registrant database.

6. The method according to claim 1, characterized in that The complete list LRPDU message includes an application identifier AppId.

7. The method according to claim 1, characterized in that The complete list LRPDU message includes a local chassis identifier ID, a local port ID identifying a target port on the local node, a neighbor chassis ID identifying the neighbor node, and a neighbor port ID identifying a target port on the neighbor node.

8. The method according to claim 1, characterized in that Also includes: Sending one or more record LRPDU messages to the registrant database, the record LRPDU messages indicating updates to records stored in the applicant database; Receiving and confirming one or more LRPDU messages in the recorded LRPDU message; marking at least one update record in the applicant database as confirmed by the registrant database; The application is notified that the applicant database and the registrant database are synchronized.

9. The method according to claim 8, characterized in that Also includes: Determine that all update records in the applicant database are confirmed by the registrant database through the LRPDU message, wherein the notification application that the applicant database and the registrant database are synchronized is initiated based on the result that all update records in the applicant database are confirmed by the registrant database through the LRPDU message.

10. The method according to claim 8, characterized in that The LRDPU message confirming the record LRPDU message includes a partial list LRPDU message.

11. The method according to claim 1, characterized in that: Also includes: The local node receives a Hello message, where the Hello message includes an application identifier AppId and a target link between a target port of the local node and a target port of an adjacent node; The local node determines that the AppId is associated with an application for performing database synchronization; Establishing a local database at the local node for use by the application as part of a database pair, the database pair comprising a neighboring database of the neighboring node; associating the database pair with the target link; The synchronization of the local database with the neighboring database is controlled through the target link.

12. The method according to claim 1, characterized in that Also includes: The local node sends one or more link local registration protocol data unit (LRPDU) messages to a registrant database of an adjacent node, wherein the LRPDU messages indicate that a record stored in an applicant database of the local node is to be updated; The local node receives one or more LRPDU messages confirming the recorded LRPDU message; marking, at the local node, at least one update record in the applicant database as confirmed by the registrant database; The application is notified that the applicant database and the registrant database are synchronized.

13. A local node, characterized in that: The local node comprises a transmitter and a processor coupled to the transmitter, wherein the local node is configured to: Generate a disconnect code for the application, the disconnect code indicating that an exchange of a Hello link local registration protocol data unit LRPDU message failed; receiving a command from the application to maintain a requestor database in the local node despite the presence of the disconnect code; receiving a complete list LRPDU message from a registrant database of a neighboring node, wherein the complete list LRPDU message includes record headers corresponding to all records in the registrant database; The record headers in the Complete List LRPDU message are compared with the record headers in the requestor database.

14. The local node according to claim 13, characterized in that: The local node is configured to reset a notification timer in the applicant database.

15. The local node according to claim 13, characterized in that: The local node is configured as: determining that there is a mismatch between one or more record headers in the requestor database and one or more record headers in the complete list LRPDU message; A record LRPDU message is sent to the registrant database, wherein the record LRPDU message includes an updated record header that handles the mismatch.

16. The local node according to claim 13, characterized in that: The local node is configured as: Determining that there is a match between a record header in the applicant database and a record header in the registrant database; According to the determination result of the match, the application is notified that the applicant database and the registrant database are synchronized.

17. A communication system, characterized in that: The method comprises a first local node and a first neighboring node communicating with the first local node, wherein the first local node is configured as follows: Generate a disconnect code for the application, the disconnect code indicating that an exchange of a Hello link local registration protocol data unit LRPDU message failed; receiving a command from the application to maintain a requestor database in the local node despite the presence of the disconnect code; receiving a complete list LRPDU message from a registrant database of a neighboring node, wherein the complete list LRPDU message includes record headers corresponding to all records in the registrant database; The record headers in the Complete List LRPDU message are compared with the record headers in the requestor database.

18. A local node, characterized in that: The local node comprises a transmitter, a receiver and a processor, wherein the processor is coupled to the transmitter and the receiver, and is configured to execute the method according to any one of claims 1 to 12.

19. A computer readable medium, characterized in that A computer program product for use in a local node is included, the computer program product comprising computer executable instructions stored on the computer readable medium, and when the computer executable instructions are executed by a processor, the local node performs the method according to any one of claims 1 to 12.

20. A local node, characterized in that: include: A disconnect module, configured to generate a disconnect code for the application, wherein the disconnect code indicates that an exchange of a Hello link local registration protocol data unit LRPDU message fails; a command module for receiving a command from the application to maintain the applicant database in the memory of the local node in the presence of the disconnection code; A receiving module, configured to receive a complete list LRPDU message from a registrant database of an adjacent node after successfully exchanging the Hello message, wherein the complete list LRPDU message includes record headers corresponding to all records in the registrant database; A record comparison module is used to compare the record header in the complete list LRPDU message with the record header in the applicant database to resynchronize the applicant database with the registrant database.

Images