RU2783595C2 - Method for synchronization of databases between two points, using transport protocol - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: invention relates to database control. The method contains reception, in a local node receiver, of a welcome message containing an application identifier (hereinafter – AppId) and an indication of a target communication line between a target port of the local node and a target port of a neighboring node, determination, by a processor in the local node, of AppId identifier associated with the application for synchronization of databases, establishment of a local database in a storage device in the local node as a part of a pair of databases for being used by the specified application, this pair of databases contains a neighboring database located in the neighboring node, association, by the processor, of the considered pair of databases with the target communication line, and synchronization of the local database with the neighboring database, using the target communication line.

EFFECT: provision of a possibility of synchronization of databases between two points, using a transport protocol.

26 cl, 15 dwg

Description

Cross-references to related applications

This patent application claims the priority of U.S. Provisional Application No. 62/655,625, filed April 10, 2018 by Dean Cheng, et al., “Point-to-Point Database synchronization Over a Transport Protocol, ”) U.S. Provisional Application No. 62/782,993 filed December 20, 2018 by Dean Cheng, et al., “Point-to-Point Database synchronization Over a Transport Protocol, ”), which are incorporated here by reference.

The field of technology to which the invention belongs

The present invention generally relates to database management and, in particular, relates to communication protocols for managing database synchronization between two locations.

State of the art

Database synchronization is the process of establishing consistency between multiple database systems. The purpose of database synchronization is to ensure that changes to the first database propagate to one or more of the appropriate database systems. The database synchronization procedure may involve the creation of complex, application-specific implementations that may not be capable of interoperability with other implementations. Such applications may be required to implement mechanisms for managing communication resources to ensure consistency and verify that the information is actually received by other database systems. Also, keeping the databases in sync can be problematic if the connection is lost. For example, retransferring all database files after a connection is restored can in some cases lead to inefficient use of communication resources.

The essence of the invention

In one embodiment, the present invention provides a method implemented at a local host, this method comprising: receiving, at a local host receiver, a hello message containing an application identifier (AppId) and specifying a target link between a target port for the local host and a target port for neighboring node; determining, by the processor at the local node, that this AppId is associated with an application for performing database synchronization; establishing a local database in the storage device of the local node as part of a pair of databases for use by this application, this pair of databases also contains a neighboring (or remote) database located in a neighboring node; associating, by said processor, a pair of databases with a target link; and managing synchronization of the local database with the neighboring database using the target link. This approach allows the communication protocol to automatically set up one or more pairs of databases for synchronization across the communication network. This protocol obtains the target link indication and AppId from hello messages. This protocol can then correlate this application with the target link and set up databases to synchronize on behalf of this application. This approach allows the application to be offloaded from the database installer function, allowing the installation and maintenance of database installation without direct control from the application. This, in turn, allows the application to direct database synchronization to take place without being directly aware of the messaging on the communication network being used to perform such synchronization.

As an option for any of the preceding aspects, another implementation of this aspect comprises, while controlling synchronization of the local database with the neighboring database, transmitting, by means of a transmitter at the local node, entry information to the neighboring database over the target link in messages in Link-Local Registration Protocol Data Unit (LRPDU) units. Database information is stored in records. Record version information (eg, control information) is exchanged via LRPDUs transmitted over the target link. Therefore, messages in LRPDUs can act as a mechanism to indicate to a neighbor that database records have been updated, and vice versa. In such a case, messages in units of LRPDUs can be used to control database synchronization.

As an option for any of the preceding aspects, in another implementation of this aspect, the local database contains an applicant database for storing local records to be transferred to a registrar database located in an adjacent database.

As an option for any of the preceding aspects, in another implementation of this aspect, the local database includes a registrar database for receiving neighboring records from an applicant database located in the neighboring database. Each such pair of databases contains an "applicant" that has records to be loaded into another database, and a "registrar" that receives copies of the applicant's records. Each of the nodes, both the local node and the neighboring node, may contain both a local database and a registrar database for two-way synchronization. In addition, the local database may be located in the local node and the registrar database may be located in a neighboring node, or vice versa for one-way synchronization.

Optionally, for any of the preceding aspects, in another implementation of this aspect, the hello message is a hello LRPDU, and this hello LRPDU represents the target link and is in the form of a My Chassis identifier (ID), identifying the local node, and the My Port ID identifying the target port in the local node, the Neighbor Chassis ID identifying the neighbor node, and the Neighbor Port ID, identifying the target port in the neighbor node. This target link may be specified by a chassis identifier (ID) and a port identifier (ID) that represents the target port at each end of the target link. This approach makes it possible to uniquely identify the target link, and therefore to indicate each of the nodes - the local node and the neighboring node - where the corresponding node can be located for the purposes of transmitting and receiving LRPDUs.

In one embodiment, the present invention comprises a method implemented at a local node, this method comprising: transmitting, by means of a transmitter from the local node, one or more write messages in LRPDUs towards a registrar database located at a neighboring node, these write messages to LRPDUs indicate updates to records stored in the local database; receiving, by a receiver at the local node, one or more LRPDU messages acknowledging (acknowledging) said LRPDU entry messages; marking, in a storage device at the local node, at least one updated entry in the local database as acknowledged (acknowledged) by the registrar database; and telling, via the processor, to the application that the local database is synchronized with the registrar database. This mechanism allows the communication network protocol to monitor communication between databases and determine when the databases are synchronized. This communication network protocol can then notify the application that synchronization is complete. With this approach, the application does not need to know about each exchange of records and the transfers associated with it. The application can make changes to the local database and let the communication network protocol keep the synchronization and notify the application when the synchronization is complete.

As an option, for any of the preceding aspects, another implementation of this aspect further comprises, determining, by a processor in the local node, that all updated records in the local database are acknowledged (acknowledged) by the registrar database via messages in LRPDUs, where the notification applications that the local database is in sync with the registrar's database are triggered based on the determination that all updated records in the local database have been acknowledged by the registrar's database via messages in LRPDUs. The applicant can determine that each entry has been acknowledged and inform the application when all entries have been acknowledged and therefore synchronization between the local database and the registrar's database is complete.

As an option, for any of the preceding aspects, in another implementation of this aspect, the set of messages in units of LRPDU, acknowledging messages of entries in units of LRPDU, contains a message with a partial list (Partial List) in units of LRPDU, this message with a partial list in units The LRPDU contains at least one entry header acknowledging at least one updated entry. The partial list message in LRPDUs acts as an acknowledgment message. Such a partial list message in LRPDUs is sent by the registrar and indicates to the applicant that the registrar has completed the update requested by the write LRPDU message.

Optionally, for any of the preceding aspects, in another implementation of this aspect, the record header contains a record number indicating the updated record and a sequence number identifying the update included in the updated record. Such information may indicate specific update(s) of the record(s) that may be accepted by the registrar.

As an option for any of the preceding aspects, another implementation of this aspect further comprises generating a fault notification to be sent to the application when the LRPDU write message timer expires without receiving a corresponding LRPDU partial list message. This mechanism allows the application to be aware of potential write transfer failures. The write message in LRPDUs may not be automatically retransmitted because large volumes of transmissions can overflow the receive buffers at the registrar (eg, potentially causing more write synchronization failures).

As an option, for any of the preceding aspects, in another implementation of this aspect, the set of messages in LRPDUs acknowledging messages of entries in LRPDUs contains a Complete List message in LRPDUs, this message is a complete list in units The LRPDU contains the entry headers relating to all entries in the registrar database. This full list message in units of LRPDUs may be sent by the registrar at specified intervals. The full list message, in LRPDU units, contains information about the current state of the registrar's database. Therefore, the applicant can use the full list message in LRPDUs to determine when records were accepted by the registrar and the acknowledgment message was skipped, and when record updates were not accepted by the registrar. The applicant can then eliminate timing errors by sending additional LRPDU entry messages based on the content of the full list messages in LRPDUs.

As an option for any of the preceding aspects, in another implementation of that aspect, the full list message in LRPDUs contains a first entry number field indicating the first entry stored in the registrar database and a last entry number field indicating the last the record stored in the registrar's database, as well as the record headers, contain record numbers indicating records stored in the registrar's database and sequence numbers identifying updates made to records stored in the registrar's database.

As an option for any of the preceding aspects, in another implementation of this aspect, the set of record messages in LRPDUs contains one or more record numbers indicating records updated in the local database and one or more sequence numbers identifying updates maintained in records updated in local databases.

As an option for any of the preceding aspects, another implementation of this aspect further comprises: transmitting, by the transmitter, a complete list request message in LRPDUs to the registrar database address; and receiving, by the receiver, a complete LRPDU list message from the registrar database in response to said complete LRPDU list request message. Using this mechanism, an applicant can request a full list message in LRPDUs at the right time on its request, instead of waiting for a periodic full list message in LRPDUs.

In one embodiment, the present invention comprises a method performed at a local node, the method comprising: generating, by a processor at the local node, a release code for the application, this release code indicates that the exchange of hello messages in local link registration protocol data units (in units LRPDU) did not take place; receiving, at the processor, an instruction from the application to maintain the local database in the local node's storage device despite the disconnect code; receiving, by the receiver at the local node, a full list message in LRPDUs from the registrar database from a neighbor node after a successful exchange of hello LRPDU messages, this full list message in LRPDUs contains headers for all entries in the registrar database; and comparing, by the processor, the record headers from the full list message in LRPDUs with the record headers in the applicant database to resynchronize the applicant database with the registrar database. This mechanism allows a pair of databases to be saved and maintained despite the loss of a connection. When a connection loss occurs, the claimant is informed and allowed to choose whether it will re-sync after the connection is re-established (eg, by retransmitting all records), or if it will re-sync after the connection is re-established. A pair of databases can be maintained by sending a message with a complete list after reconnecting through the exchange of hellos. The applicant database can then compare the record headers from the registrar database with the record headers from the applicant database to determine which, if any, updates were lost due to the loss of connection. The applicant database can then retransmit only the lost updates instead of retransmitting the entire list of applicant database records to the registrar. This approach can reduce the use of communication network resources and reduce the time to restore synchronization when a connection appears between the applicant and the registrar.

As an option to any of the preceding aspects, another implementation of this aspect further comprises initializing (resetting) the notification timers in the applicant's database after an unsuccessful attempt to exchange hello messages, in order to prevent transmission of record messages in LRPDUs until a message with a complete list in units of LRPDUs will not be received. As a result, the database of the applicant stops trying to synchronize the databases until the connection is restored, and therefore saves communication network resources and processor resources.

As an option, for any of the preceding aspects, another implementation of this aspect further comprises: determining, by the processor, a mismatch between one or more record headers in the applicant's database and one or more record headers included in the message with a complete list in units LRPDU; and transmitting the LRPDU entry message to the registrar database, where the LRPDU entry message contains updated entry headers related to the specified mismatch. In case of disagreement, updated records may be transferred from the applicant to the registrar. This may occur in cases where the previous write message in LRPDUs was lost due to loss of connection.

As an option for any of the preceding aspects, another implementation of this aspect further comprises: determining, by the processor, that there is no mismatch between the record headers in the applicant's database and the record headers from the registrar's database; and based on the determination that there is no mismatch, reporting by the processor to the application that the applicant's database is synchronized with the registrar's database. This allows the communication network protocol to manage synchronization on behalf of this application, and therefore allows the application to remain ignorant of communications and transfers specific to database synchronization.

In one embodiment, the present invention encompasses a local node comprising a storage device, a transmitter, a receiver, and a processor connected to the storage device, transmitter, and receiver, such a local node configured to implement the method according to the preceding aspects.

In one embodiment, the present invention comprises a non-volatile computer-readable storage medium having a computer program product for use by a local node, the computer program product having computer-executable instructions stored on the non-volatile computer-readable storage medium such that when these instructions are executed by the processor, the local node executes the method according to the preceding aspects.

In one embodiment, the present invention encompasses a local node, comprising: a receiving module for receiving a hello message that includes an application identifier (AppId) and an indication of a target link between the local node and a neighbor node; a decision module for determining that the AppId is associated with an application for performing database synchronization; a database pair setting module for setting up a local database at the local node as part of the database pair for use by said application, the database pair also containing a neighbor database at the neighbor node; an association module for associating the database pair with the target link; and a synchronization control module for controlling synchronization of the local database with the neighboring database via the target link.

In one embodiment, the present invention comprises a local node, which includes: a transmitting module for transmitting one or more record messages in local link registration protocol data units (LRPDUs) to a registrar database located in a neighboring one, where these record messages are in LRPDUs represent updates to records stored in the applicant's database located at the local node; a receiving module for receiving one of the plurality of LRPDU messages acknowledging the LRPDU entry messages; a memory module for marking at least one updated entry in the applicant's database as confirmed (acknowledged) by the registrar's database; a decision module for determining that all updated entries in the database of the applicant are acknowledged by the database of the registrar through messages in units of LRPDU; and a notification generation module for notifying the application that the applicant database is synchronized with the registrar database based on determining that all updated entries in the applicant database are acknowledged by the registrar database via LRPDU messages.

In one embodiment, the present invention comprises a local node that includes: a release notification module for generating a release code for the application, this release code indicates that the exchange of hello messages in local link registration protocol data units (in LRPDUs) has failed success (did not take place); a command module for receiving a command from the application to maintain the database of the applicant in a storage device in the local node, despite the disconnect code; a receiving module for receiving a full list message in LRPDUs from a registrar database located at a neighboring node, after a successful exchange of hello messages, such a full list message in LRPDUs contains record headers for all records in the registrar database; and a record comparison module for comparing record headers from the full list message in LRPDUs with record headers in the applicant database to restore synchronization of the applicant database with the registrar database.

As an option for any of the preceding aspects, another implementation of this aspect further comprises modules for implementing the method according to any of the previous aspects.

For purposes of clarity, any of the above options may be combined with any one or more of the other options to create a new option within the scope of the present invention.

These and other variations will be better understood from the following detailed description, taken in conjunction with the accompanying drawings and the claims.

Brief description of the drawings

For a more complete understanding of the present invention, reference is made herein to the following brief description, taken in conjunction with the accompanying drawings, and a detailed description where like reference numerals represent like parts.

Fig. 1 is a simplified diagram of an example implementation of a proprietary system for a database synchronization network.

Fig. 2 is a simplified diagram of an example implementation of a proxy system for a database synchronization network.

Fig. 3 is a simplified diagram of an example database system for database synchronization.

Fig. 4 is a protocol diagram for an example of a database synchronization control method.

Fig. 5 illustrates an example of encoding a Hello message in Local Link Registration Protocol Data Units (in LRPDUs).

Fig. 6 illustrates an example of encoding a write message in LRPDUs.

Fig. 7 illustrates an example of encoding a partial list message in LRPDUs.

Fig. 8 illustrates an example of encoding a full list message in LRPDUs.

Fig. 9 is a flow diagram of an example of a method for establishing a database pair.

Fig. 10 is a logic diagram of an example method for managing the synchronization of a pair of databases.

Fig. 11 is a flowchart of an example of a way to keep databases in sync despite connection interruptions.

Fig. 12 is a simplified diagram of an example communication network element for managing database synchronization.

Fig. 13 is a simplified diagram of an example of an apparatus for establishing a database pair.

Fig. 14 is a simplified diagram of an exemplary apparatus for controlling the synchronization of a pair of databases.

Fig. 15 is a simplified diagram of an example device for maintaining database synchronization despite connection interruptions.

Detailed description

It should first be understood that while an exemplary implementation of one or more embodiments is provided below, the systems and/or methods described herein may be implemented using any number of technologies currently known or currently in existence. The present invention should not be limited in any way by the illustrative implementations, drawings, and techniques illustrated below, including the example designs and implementations illustrated and described herein, but these variations may be modified within the scope of the appended Claims, along with the full scope of equivalents.

Standardized communication protocols can be used to support database synchronization. Such communication protocols can be configured to maintain database consistency in a standardized manner. For example, the Link-local Registration Protocol (LRP) is a standard that specifies protocols, procedures, and managed entities for copying a registration database from one end to the other end of a link between two points, and for copying changes in part Database. The LRP protocol can be optimized for databases on the order of one Megabyte. The LRP Database Synchronization (LRP-DS) protocol can be used to establish communication between databases. The LRP-DS protocol uses hello messages in a manner similar to the Intermediate System to Intermediate System (IS-IS) communication protocol to establish neighborship between nodes. The LRP Database Transport (LRP-DT) protocol can then be used to transfer (transport) the data that carry the record messages generated by the LRP-DS protocol in a manner similar to the Link State Advertisement ( LSA)) transmitted over the IS-IS protocol. The LRP-DS protocol thus manages database synchronization on behalf of the respective applications.

Mechanisms for enhancing the functionality of the LRP-DS protocol are discussed here. For example, the LRP-DS protocol can be enhanced to automatically set up database pairs for synchronization. Such a database pair contains an applicant database located at the first node and a registrar database located at the second node. Such nodes may also be referred to as a local node and a neighbor node, respectively, for clarity of discussion. When updates are made to the applicant's database, the LRP-DS protocol sends those updates to the registrar's database to maintain synchronization. For unidirectional communication, the local node contains the applicant database and the neighboring node contains the registrar database. For two-way communication, the local node contains the applicant database for synchronization with the registrar database located in the neighboring node, and the neighboring node contains the applicant database for synchronization with the registrar database located in the local node. In either case, the database pair(s) can be established automatically by exchanging hello messages in Local Link Registration Protocol Data Units (LRPDUs). These hello messages in units of LRPDUs contain the identifier (AppId) of the corresponding application and an indication of the target link, indicated by the My Chassis ID identifying the local node, the My Port ID identifying the target port in the local node, the Neighbor Chassis ID an ID identifying the neighbor, and a Neighbor Port ID identifying the target port in the neighbor. After exchanging hello messages, the local node and the neighbor node can automatically create an applicant database and registrar database pair for the identified application and correlate such database pairs based on the target link.

The LRP-DS protocol running in a component called the portal can also be used to automatically inform the application when the databases are in sync after one or more updates. For example, when an update is made to the applicant's database, a record message in LRPDU units is sent to the registrar's database to indicate the record(s) in the database that has been updated and the sequence number(s) (e.g. version numbers) such updated entry(s). The registrar database responds with a partial list message in LRPDUs that acknowledges awareness of the updated records and that can be sent over the LRP-DT protocol. When a message with a partial list in LRPDUs is received, the portal initiates marking the specified entries in the applicant database as acknowledged. Here you can exchange multiple record LRPDUs and partial list LRPDUs. When all entries in the applicant's database are marked as acknowledged, the portal can provide an indication to the application that the databases are synchronized.

In another example, the LRP-DS protocol can be used to maintain synchronization between databases despite communication interruptions. Hello messages in units of LRPDUs may be exchanged periodically. When the exchange of hello messages in units of LRPDUs did not take place (turned out to be unsuccessful), the portal can notify the application about this. The applicant may choose to terminate the pairing and create a new database pair upon reconnection by reloading the database records into the new registrar database. The applicant may also choose to maintain the current pair of databases. When the portal receives an indication that the database pairing should be maintained and retained, the portal aborts further transmission of write messages in LRPDUs. After the exchange of Hello messages in LRPDUs is restored, the registrar sends a message with a complete list in LRPDUs to the applicant. The full list message in LRPDUs contains the entry headers for all entries in the registrar database. The applicant's database may compare the titles of the records included in this message, with the full list in LRPDUs, with the titles of the records stored in the applicant's database to determine any record inconsistencies. This can happen when LRPDU write messages are lost due to connection loss. The applicant's database may then send LRPDU entry messages containing any entries updates made since the state of the entries included in the full list LRPDU message was committed. Typically, the result is that fewer entries are sent in LRPDUs than without the full list being sent quickly in LRPDUs. This portal can also notify the application when the databases are synchronized. These and other example options are discussed in more detail with reference to the following drawings.

On FIG. 1 is a simplified diagram of an example implementation of a native system for a communications network 100 for database synchronization. The database synchronization communication network 100 comprises a home system 110 and a home system 130 connected by an Internet Protocol (IP) communication network 171 . These home system 110 and home system 130 contain one or more databases 120 and 122, respectively, for synchronization. For clarity of discussion, one of the native systems 110 or 130 is referred to here as local when referring to source operations taking place in the first system, and the other is referred to here as neighbor when referring to destination operations taking place in the second system. Therefore, each of home systems 110 and 130 may be local, neighboring, or both, depending on the context. It should also be noted that the terms "local" and "neighbor" as used here are relative and used to clearly distinguish between a first node and a second node, and can also be used interchangeably when discussing the operation of the same communication network from different points of view.

Home system 110 is a computing component containing an application 111, a portal 113, a target port 141, and databases 120. Application 111 is a computer program operable to distribute information between at least home system 110 and/or proxy system and home system 130 and/or proxy system. Proxy systems are discussed with respect to FIG. 2 below. For example, application 111 may include a user-operated program with a backup file synchronized with the 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.

Portal 113 is a portal interface instance that, along with applicant and/or registrar state machine instances and databases 120, is associated with a single application 111. For example, this portal 113 runs an LRP protocol (e.g., LRP-DS protocol and/or DT) on behalf of the application 111. This portal 113 receives notifications from the application 111 and/or the databases 120, performs the corresponding LRP protocol operations, and sends the appropriate notifications of these operations to the application 111 and/or the databases 120. For example, portal 113 executes the LRP-DS protocol by controlling the transmission of messages in LRPDUs. This portal 113 executes the LRP-DT protocol by transmitting and receiving data, such as database records 120, in exchange with the corresponding portal 133, for example, via a Transmission Control Protocol (TCP) connection 170). In some examples, application 111 on home system 110 maintains a separate portal 113 and associated databases 120 on each of multiple target ports 114 on home system 110.

Home system 110 may also use a Link Layer Discovery Protocol (LLDP) discovery protocol 161 at target port 141. Alternatively, home system 110 maintains an administrator-managed information store containing data equivalent to that generated by LLDP. 161.

Databases 120 contain one or more information stores that store files for application 111. Files in databases 120 are stored as records. A record is a subset of information from the database 120 transmitted as a single block from the applicant to the registrar in accordance with the LRP protocol running in the portal 113. Each record contains data, a record number that identifies this data, and a sequence number. This sequence number identifies the current version of the entry. For example, the sequence number may be implemented as a counter indicating the number of times the corresponding entry has been updated. The set of databases 120 may contain an applicant database, a registrar database, or both. "Applicant" is one of two roles (along with "registrar") that application 111 can play in relation to portal 113. The applicant manages the database 120, which the LRP protocol copies to the registrar database in the neighboring portal 133. "Registrar" is one of two roles (together with "applicant") that application 111 can play in relation to portal 113. The registrar receives a copy of the database 122, which the LRP protocol copies from the database of the applicant, in the adjacent portal 133. In such a situation, the collection of databases 120 may contain an applicant database for uploading records to database 122, a registrar database for downloading records from database 122, or both such databases for two-way transfer and exchange of records with databases 122.

Target port 141 is a communication port in home system 110. Portal 113 and its associated applicant and registrar databases 120 are associated with a single target port 141. Target port 141 may be associated with more than one portal 113 if such portals 113 serve different application 111. Target port 141 provides access to a link that connects to one or more other target ports 151 (eg, in other systems).

Home system 130 is substantially the same as home system 110. Home system 130 includes portal 133, application 131, database 122, and target port 151, which may be similar to portal 113, application 111, database 120, and target port 141, respectively.

Home systems 110 and 130 discover each other to establish database pairs 120 and 122 via LLDP 161. This LLDP 161 is a link layer protocol described in the 802.1AB standard developed by the Institute of Electrical and Electronics Engineers. Electronics Engineers (IEEE)) and used by network devices to advertise their identity, functionality, and neighbors in a communications network. In particular, home systems 110 and 130 may advertise to each other their applications 111 and 131, as well as the functionality of the LRP-DS protocol and the LRP-DT protocol, through the target ports 141 and 151 using the LLDP protocol 161. Addresses for use by the protocol LRP-DTs when sending messages in LRPDUs can be defined by LLDP 161 along with preferences for using either Edge Control Protocol (ECP) 160 or Transmission Control Protocol (TCP) to send these messages in LRPDUs. The ECP 160 protocol is a communications network protocol defined by the IEEE Standard 802.1Q-2014. TCP 170 is defined in Request For Comment (RFC) 793 issued by the Internet Engineering Task Force (IETF). Any of these protocols can be used to send messages in LRPDUs. If ECP 160 is used, ECP packets go through destination ports 141 and 151. If TCP 170 is used, LRPDUs can go through destination ports 141, 151, or through any other ports of the two native systems 110 and 130.

Messages in LRPDUs act as control messages indicating updates to records in databases 120 and/or data, acknowledgments, and other control information related to database synchronization. The set of LRPDU messages discussed here includes hello messages in LRPDUs, entry messages in LRPDUs, partial list messages in LRPDUs, full list messages in LRPDUs, and complete list request messages in LRPDUs. However, other LRPDU messages may be used as needed to force databases 120 and 122 to synchronize. Using messages in LRPDU units, portals 113 and 133 can exchange records of data bases 120 and 122 in order to synchronize these data bases 120 and 122. For example, the exchange of records between the databases 120 and 122 data in units of LRPDU can be carried out through the connection 170 protocol TCP. Such a TCP connection 170 is a communication session between two points for use in order to exchange data. TCP connection 170 may be between target ports 141 and 151, or between other ports, depending on the example. The TCP connection 170 may traverse one or more IP communication networks 171, which are three Open Systems Interconnection (OSI) layer communication networks that communicate between two points. As discussed below with reference to the drawings, the components listed above can be used by the portals 113 and/or 133 to manage the synchronization of the data bases 120 and 122 on behalf of the applications 111 and/or 131, in part through the target ports 141 and 151.

On FIG. 2 is a simplified diagram of an example implementation of a proxy system for communication network 200 for database synchronization. The database synchronization communication network 200 includes a proxy system 210, a proxy system 230, a slave system 240, and a slave system 250. Such a database synchronization communication network 200 is similar to the database synchronization communication network 100, however, the target ports 241 and 251 are moved from own systems to slave systems 240 and 250, respectively. As used herein, proxy system 210 and/or 230 is a computing component that includes at least an application 211 that is substantially similar to application 111. For example, proxy system 210 includes at least an application 211 that operates to distribute information between proxies. system 210 and a native system and/or proxy system 230. Proxy system 210 may also include a portal 213 and/or databases 220 that are essentially the same as portal 113 and database 120, respectively.

The slave system 240 may be a communication component such as a router, switch, or the like, and may be an end station such as a video camera, a mechanical drive, or a personal computer. The slave system 240 is connected to the proxy system 210 via a network connection. The slave system contains at least one target port 241, which is essentially the same as the target port 141. The communication component contains several target ports 241. The proxy system 210 and the slave system 240 operate together in a manner essentially similar to the native system 110. Due to the location of the target port 241 in the slave system 240, instead of the proxy system 210, the application 211, the portal 213 and/or the databases 220 may be uploaded to a device (the proxy system 210), which may be located on a communication network separate from the communication network where the slave system is located. 240. This creates flexibility in implementation while providing essentially the same functionality.

Proxy system 230 is essentially the same as proxy system 210 and includes portal 233, application 231, and databases 222, which may be essentially the same as portal 213, application 211, and databases 220, respectively. Slave system 250 is connected to proxy system 230 and contains target port 251, which may be substantially the same as target port 241. Slave systems 240 and 250 use LLDP 261 to exchange an LLDP message between target ports 241 and 251 in a manner similar to LLDP. 161. These slave systems 250 and 240 may transmit such messages to portals 233 and 213, respectively. The information about the records included in the LLDP messages can be used to establish transmissions and receptions of records from the databases 220 and/or 222 for the purpose of synchronization over the IP network 271 . This IP network 271 may be substantially similar to the IP network 171 . Such records may be transmitted over a TCP connection 270 substantially similar to a TCP connection 170 .

It should be noted that within the scope of the present invention, various combinations of communication networks 100 and 200 may also be used to synchronize databases. For example, home system 110 can be used to synchronize databases 120 with proxy system 230 and slave system 250. Further, home system 130 can be used to synchronize databases 122 with proxy system 210 and slave system 240. To route communication between a variety of relay systems (eg, routers and/or bridges) may be used by home systems, proxy systems, and/or slave systems. Such components may have different functionality, as discussed below. In any communication device, applications 111, 131, 211 and/or 231 can exchange information between the applicant and the registrar in data bases 120, 122, 220 and 222 through different target ports 141, 151, 241 and 251 belonging to the same system.

On FIG. 3 is a simplified diagram of an example database system 300 for database synchronization. Database system 300 may be used to implement home system 110, home system 130, proxy system 210, and/or proxy system 230. Database system 300 includes an application 311 that is 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 a neighboring database. This application organizes a portal 313, which is essentially the same as portal 113, 133, 213 and/or 233. This portal 313 runs an LRP protocol (eg, LRP-DS protocol and/or LRP-DT protocol) on behalf of application 311. Therefore, the portal 313, among other procedures, manages the transmission of LRPDUs and records for synchronization purposes. Portal 313 interacts with application 311 and databases 320, which are essentially the same as databases 120, 122, 220 and/or 222 data. The set of databases 320 may include an applicant database 321 and/or a registrar database 325.

Applicant 321 is a state machine and associated storage space configured to load copies of logically stored data into a registrar located in an adjacent database. Registrar 325 is a state machine and associated storage space configured to receive copies of remotely stored data from an applicant located in a nearby database. Therefore, the database 320 may include a submitter 321 for downloading data for synchronization purposes, a registrar 325 for downloading data for synchronization purposes, or both downloading and downloading in the case of two-way synchronization. Applicant 321 and registrar 325 are each associated with portal 313 to ensure control messages and data reach their intended destinations. Portal 313 is further associated with a target port to ensure that said messages are received at their intended destination portals (eg, portal 313).

The data in the databases 320 is stored as records. A record is the smallest unit of data that can be sent and received for synchronization purposes. Record sizes can be configured by application 311. Smaller records create complexity, but larger records result in more data being transferred when the record is updated.

Applicant 321 contains local records 323 and headers 324 of local records. Local records 323 are records containing data used locally by the application 311. Record headers constitute a predetermined group of status information related to the respective records. For example, each of the local entry headers 324 contains an entry number, a sequence number, and/or a checksum for the corresponding local entries 323. The entry number designates the corresponding entry 323. The sequence number contains version information. For example, the sequence number may contain a counter indicating the number of times the corresponding entry has been modified. The checksum is error checking information and may contain a number representing the sum of the correct number of digits in the corresponding data set to be transmitted. For example, the checksum may be the sum of the correct number of digits in the entry number and in the sequence number. In such a situation, when a local entry 323 is updated, a corresponding local entry header 324 may be signaled to indicate the entry that has been updated and the version (eg, sequence number) of that update.

The registrar 325 contains neighboring records 326 and headers 327 of neighboring records. These neighboring entries 326 and neighboring entry headers 327 are similar to the local entries 323 and local entry headers 324, respectively, but refer to the data used by the application in the neighboring node/system.

Accordingly, the local database 320 may contain an applicant database 321 for storing local records 323 for transfer to a registrar database in a neighboring database. The local database 320 may also include a registrar database 325 for receiving neighboring records 326 from an applicant database located in the neighboring database. Such transfer of records can be done using messages in units of LRPDU. For example, an LRPDU entry message may be sent from the portal 313 when local entries 323 are updated. An LRPDU entry message contains appropriate headers 324 to notify a registrar located in a neighboring database that local entries 323 have been updated, and about the current update sequence number. The portal 313 may receive an appropriate partial list of records from the neighbor, which (the list) acknowledges (acknowledges) awareness of updates to local records. Portal 313 may also establish a communication with a portal located at a neighbor to send updated local records 323. Similarly, a claimant at a neighbor may send a record message in units of LRPDUs to portal 313, via a neighbor portal, to indicate changes to the neighboring entry 326. The LRPDU entry message from the neighbor contains the updated neighbor record headers 327. The registrar 325 can then respond through the portal 313 with a partial list LRPDU message containing the updated neighbor record headers 327 to indicate awareness of updates in the neighbor database . The portal 313 may also manage the transmission of updated neighbor records 326 from the neighbor to the registrar 325. These and other messaging schemes for exchanging records and record headers between applicants 321 and registrars 325 for the purpose of database synchronization are discussed below with reference to the drawings.

On FIG. 4 is a protocol diagram for an example method 400 for managing database synchronization. Method 400 may be implemented by native system 110 and/or 130, proxy system 210 and/or 230 in conjunction with slave system 240 and/or 250, and/or database system 300. Method 400 represents mechanisms for creating and maintaining a database pair containing an applicant and a registrar. The database pair management procedure comprises maintaining synchronization between the applicant's database and the registrar's database. Method 400 is performed by an application, a local portal managing an applicant database located at the local node, and a neighboring portal managing a registrar database located at the neighboring node.

In some examples, the local portal and the neighbor portal are preconfigured with the ports and addresses of the neighbors related to the application. In other examples, the local portal and the neighbor portal discover ports and neighbor addresses related to the application in question through other discovery protocols. In either case, the local portal sends a hello message 401 in LRPDUs to the neighbor portal, and that neighbor portal sends a hello message 403 in LRPDUs to the local portal. This may also be referred to as an exchange of hello messages in LRPDUs. Hello messages 401 and 403 contain an application identifier (AppId) in LRPDUs and identify the target link between the target port for the local host and the target port for the neighbor. The AppId designates an application and therefore indicates that the sender is associated with an application that wishes to synchronize data. The indication of the target link in hello messages 401 and 403 in units of LRPDUs indicates that the attempt to establish and establish communication was successful and synchronization can be started.

Accordingly, when the local portal receives hello messages 403 in LRPDUs, the local portal determines that the AppId is associated with the application to perform database synchronization. The local portal then installs the local database on a storage device located on the local host as part of the database pair for use by the application. In this example, the local database contains the applicant. Further, when a neighbor portal receives hello messages 401 in LRPDUs, that neighbor portal determines that the AppId is associated with the database synchronization application. The neighbor portal then installs the neighbor database in the storage device located at the neighbor node as part of the database pair. In this example, the neighbor database contains the logger. Each of the portals, a local portal and a neighboring portal, associates a pair of databases with a target link. The local portal can then manage the synchronization of the applicant's local database with a neighboring registrar database via the target link. The procedure for controlling synchronization of the local database of the applicant with the neighboring database of the registrar comprises the transfer of information of records to the neighboring database via the target link in messages in units of LRPDUs, as discussed below. It should be noted that messages in units of LRPDUs can always be transmitted on the target link in order to ensure that such messages reach the appropriate portal.

Once the LRPDU hello messages have been exchanged and the databases have been established, the application in question can update 405 records in the applicant's database via the local portal. This record change 405 includes an update of at least one bit of data that is included in the corresponding record. When an entry is updated, the sequence number (eg, increment) in the corresponding entry header is changed to indicate that change. An entry affected by said entry change 405 may also be marked as an unacknowledged (unacknowledged) entry using a flag in the applicant's database to indicate that the registrar is not aware of the change.

The local portal may send the write message 407 in LRPDUs to the registrar database located at the neighbor node via the neighbor portal. This LRPDU entry message 407 indicates an update of an entry stored in the applicant's database. In particular, the entry message 407 in LRPDUs contains entry headers relating to entries in the applicant's database updated by the entry change 405 . These record headers contain the record number and sequence number for each updated record. In some examples, the LRPDU entry message 407 also contains updated entries. In other examples, updated records are transmitted from the applicant to the registrar via a separate session and/or using a separate communication protocol such as TCP and/or LRP-DT. It should be noted that the local portal MAY continue to send additional entry messages in LRPDUs as entries are updated without waiting for an acknowledgment to be received.

The neighboring portal, and therefore the registrar, receives the entry message 407 in LRPDUs and updates the registrar's database according to the entry headers and/or entries included in the message. The neighbor portal may then generate a partial list message 409 in LRPDUs on behalf of the registrar. The LRPDU partial list message 409 serves as an acknowledgment of the LRPDU entry message 407 . The LRPDU entry list message 409 contains the headers of the entries included in the LRPDU entry message 407 and therefore indicates that the registrar is aware of updates and/or has accepted updates for these entries, depending on the example. The neighboring portal sends a message 409 with a partial list in LRPDUs to the database of the applicant. This LRPDU partial list message 409 acknowledging the LRPDU entry message 407 is received in the local portal. The local portal can then mark the updated entries in the applicant's database as having been acknowledged by the registrar's database using a flag.

As noted above, the local portal may send further entry messages 407 in LRPDUs without waiting for the corresponding partial list messages 409 in LRPDUs to be received. Therefore, various record updates may remain unacknowledged (unacknowledged) even if particular list partial messages 409 in LRPDUs have been received. However, in some cases, all LRPDU partial list messages 409 may be received for all corresponding LRPDU entry messages 407, for example, due to an update pause at the applicant. When this happens, the applicant database and the registrar database are synchronized. The local portal may check the acknowledgment status of entries in the database of the applicant each time a message 409 is received with a partial list in LRPDUs. Therefore, when the databases are synchronized, the local portal can determine that all updated entries in the applicant database have been acknowledged (acknowledged) by the registrar database via LRPDU messages. Based on the determination that all updated entries in the applicant database have been acknowledged by the registrar database via LRPDU messages, the local port may send an acknowledgment 411 for all entries to notify the application that the applicant database is synchronized with the registrar database. This receipt 411 for all records may be an indication in the form of a predetermined code passed to the application to verify the synchronization.

As an option, the local portal can be configured to maintain a wait timer for each write message 407 in LRPDUs. In such a case, the local portal may generate a failure notification 412 to the application when the timeout period for the write LRPDU message 407 expires and the corresponding partial list LRPDU message 409 is not received. The unacknowledged (unacknowledged) write message 407 in LRPDUs may not be automatically retransmitted by the local portal. A neighboring portal and/or corresponding target port may have a limited receive buffer. Automatic retransmission may result in a buffer overflow due to the presence of other LRPDU 407 record messages in it. Accordingly, the application may determine how to continue, for example, retransmit an unacknowledged LRPDU record message 407, continue waiting, " rollback" back to the corresponding update of records in the database of the applicant, etc.

The neighboring portal sends messages 413 with a complete list in units of LRPDU on behalf of the registrar. Such full list messages 413 in LRPDUs contain the entry headers for all entries in the registrar database (but not the entries themselves). Full list messages 413 in LRPDUs may be sent periodically and received by the applicant via the local portal. The full LRPDU list message 413 may serve as an acknowledgment to acknowledge one or more previously transmitted LRPDU record messages 407, for example, if the LRPDU partial list message 409 was not accepted by the local portal/applicant. In addition, the full list message 413 in LRPDUs can also be used by the applicant to determine if the write message 407 in LRPDUs was not received by the registrar. For example, the applicant may compare the entry titles included in the full list message 413 in LRPDUs with the entry titles in the applicant's database. When the record headers in the applicant database match the record headers included in the full list message 413 in LRPDUs, the applicant can determine that all record updates have been accepted by the registrar and send a receipt 411 for all records. If the record headers in the applicant's database do not match the record headers included in the full list message 413 in LRPDUs, the applicant can determine that certain record updates were not accepted by the registrar and retransmit them.

Method 400 also handles other cases. For example, a connection abort 415 may occur. Such a connection interruption 415 may be the result of a node or link failure between the target ports for the local portal and the neighboring portal. Connection interruption 415 may also occur as a result of data traffic congestion. The exchange of hello messages in LRPDUs, such as hello messages 401 and 403 in LRPDUs, occurs periodically so that the portals become aware of the connection abort 415 when no such exchange occurs. When the hello message exchange fails (failure), the local portal generates a release code 416 for the application. This disconnect code 416 indicates to the application that the exchange of hello messages in units of LRPDUs did not take place, and that a connection abort 415 occurred. The applicant can then determine the action to be taken in response to connection abort 415 . For example, an application may decide to re-establish a pair of databases upon reconnection, in which case the implementation of method 400 starts again after exchanging hello messages 401 and 403 in LRPDUs.

As another example, an application may decide to keep the old database pair and re-establish the connection. If successful, this approach avoids the need to retransmit all records from the applicant's database to the registrar's database. The application may send command 417 to maintain databases to the local portal. Therefore, the local portal may receive this maintain database command 417 from the application to maintain the database of the applicant in storage at the local node despite the disconnect code 416 . When a local portal receives a command to support a pair of databases, that local portal stops transmitting LRPDU entry messages 407 until a full list LRPDU message 418 is received from the registrar database through a neighboring portal. For example, the local portal may initialize (reset) the notification timers in the applicant database after an unsuccessful (failed) exchange of hello LRPDU messages (e.g., connection abort 415) to prevent transmission of write LRPDU messages until until message 418 is received with the complete list in LRPDUs.

The neighboring portal performs a similar procedure using the application in the neighboring site. After a successful exchange of hello messages in units of LRPDU, the registrar, through a neighboring portal, sends message 418 with a complete list in units of LRPDU. This LRPDU list message 418 is essentially the same as the LRPDU list message 413, and therefore contains all of the record headers for the registrar database. If the application at either the local node or the remote node chooses to re-install the database pair, then execution of method 400 starts again. For example, if the neighbor portal bootstrap (reset) the registrar database and the local portal does not bootstrap the applicant database, then LRPDU full list message 418 is empty and the applicant retransmits all entries. As another example, if the neighbor portal does not initialize (reset) the registrar database, but the local portal initializes (resets) the applicant database, then the LRPDU full list message 418 contains record headers that are inconsistent with the database. applicant data, and the initial installation (reset) of a pair of databases occurs. However, if both applications choose to maintain a pair of databases, then the full list LRPDU message 418 contains record headers that are the same or similar (eg, due to lost LRPDU record messages 407) to the record headers in the applicant's database. In this case, the applicant may determine the necessary steps to resume synchronization between the pair's databases.

Accordingly, the local portal may receive message 418 with the full list in LRPDUs from the registrar database located at the neighbor node after a successful volume of hello messages. The full list message 418 in LRPDUs contains the entry headers for all entries in the registrar database. The local portal and/or the applicant database may then compare the titles of the entries included in the full list message 418 in LRPDUs with the titles of the entries in the applicant database to resume synchronization of the applicant database with the registrar database. In the first case, the local portal may determine that there is no mismatch between the record headers in the applicant database and the record headers from the registrar database as they appear in the full list message 418 in LRPDUs. In this case, the pair of databases is synchronized. In such a case, based on the determination that there are no mismatches, the portal may notify the application that the applicant's database is synchronized with the registrar's database, for example, by transmitting a receipt 411 for all entries. In the second case, the local portal may determine a mismatch between one or more entry headers in the applicant database and one or more entry headers included in message 418 with the complete list in LRPDUs. This can happen if the write message 407 in LRPDUs is lost during connection abort 415 . This portal can compare record headers to determine which records have not been submitted to the registrar's database. The local portal can then send the write message 407 in LRPDUs to the registrar database via the neighboring portal. This LRPDU entry message 407 contains the updated entry headers as needed for mismatch processing. In either case, the database pair becomes synchronized without first setting up (resetting) the database pair and retransmitting all applicant database records.

As an option, the local portal may also request, on behalf of the applicant, message 421 with the complete list in LRPDUs. This allows the applicant to verify the synchronization of the databases on demand. In such a case, the local portal sends a message 419 requesting the complete list in LRPDUs to the registrar database via the neighboring portal. The neighboring portal and/or registrar receives this LRPDU full list request message 419 and sends the full LRPDU list message 421 to the applicant via the local portal. This LRPDU full list message 421 is essentially the same as LRPDU full list messages 418 and 413. The local portal, and hence the applicant, may then receive a message 421 with the complete list in LRPDUs from the registrar database in response to a message 419 requesting the complete list in LRPDUs. In such a case, the applicant can compare the headers of the records included in the full list message 421 in LRPDUs with the headers of the records in the applicant's database to determine if the database pair is synchronized and/or determine which records to send to the registrar for synchronization. database pairs.

It should be noted that the LRPDU messages and method notifications 400 are illustrated for the purpose of describing various examples of the functionality of the present invention. Such messages/notifications can be used in various combinations. For example, the exchange of hello messages 401 and 403 in LRPDUs, as well as messages 413, 418 and 421 with a complete list in LRPDUs, can occur periodically based on predetermined timer signals, as well as based on trigger events, as discussed above. Further, record changes 405, together with the LRPDU record messages 407 and LRPDU partial list messages 409 transmitted as a result of such changes, can occur multiple times during normal operation of the applicant database with or without outside intervention. In addition, transmission of a receipt 411 for all records, a failure notification 412, a disconnect code 416, and a command 417 to maintain databases can be triggered when appropriate circumstances arise. In such a situation, the order of LRPDU messages and notifications shown in FIG. 4 is merely an example and should not be considered limiting unless otherwise noted.

In addition, any number of LRPDUs may be concatenated in a single LRP-DT in an Edge Control Protocol Data Unit (ECPDU) system, up to a maximum size of two layers per frame. One LRPDU may not be split across multiple LRP-DT ECP ECPDUs. When using the TCP protocol, the size of the LRPDU unit can be limited to a field of sixteen bits.

Fig. 5 illustrates an example encoding of hello message 500 in LRPDUs that can implement hello message 401 and/or 403 in LRPDUs. In such a situation, a hello message 500 in units of LRPDUs can be used to keep the pair of databases synchronized in the home system 110 and/or 130, in the proxy system 210 and/or 230, in the slave system 240 and/or 250 and/or in the system 300 databases.

The hello message 500 is encoded in LRPDUs in TLV format. For example, the TLV format used here can support data fields up to sixty-five thousand five hundred and thirty-five octets in size. Hello message 500 in LRPDU units contains the field "Type" (Type) 501 type. This Type field 501 is one octet long and offset zero octets. The Type field 501 may be set to one to indicate hello message 500 in units of LRPDUs. The Hello message 500 also contains a Length field 503 in LRPDU units. This Length field 503 is two octets long and offset by one octet. The Length field 503 may contain an integer of length two octets, with the most significant eight bits in the first octet (offset 1) containing the length of the data field (eg, the rest of the message). Thus, when zero is written in the Length field 503 in the TLV format, it means that there is no data field. The Length field 503 in the Hello Message 500 in units of LRPDUs (octets one and two after the type field) contains an indication of the length of all fixed length fields plus all TLV values in the data field.

The rest of the data is from zero to sixty-five thousand five hundred and thirty-five octets in length, offset by three octets for the first data field. The data field of the hello message 500, in units of LRPDUs, contains the information transmitted by one instance of the hello transmission state machine at the applicant, at the registrar, and/or at the corresponding portal. This hello message 500 in units of LRPDU contains several fields of a fixed size, followed by a number of TLV values within the data field. In other words, the tenth octet after the Length field 503 in the TLV format may be a different LRPDU type field.

The hello message 500 in LRPDUs also contains an AppId field 505. This field 505 contains an AppId identifying the application associated with the emitting portal. The AppId field contains an Organizationally Unique Identifier (OUI) or Company Identifier (CID) of three octets and an Application Sub-ID of one octet and offset three octets out of a total of four octets. It should be noted that the owner of the OUI or CID is responsible for managing the use of the Application Sub-ID. It should also be noted that the AppId is used in a variety of contexts, including state machine variables, and not just in the 500 hello message in LRPDUs.

The hello message 500 in LRPDUs also contains a Hello Status field 507 (Hello Status). This Hello Status field 507 is a four-bit number field located in the high bits of an octet and contains one of the following values: hello status looking (hsLooking) hello status connecting (hsConnecting)) and the hello status is connected (hello status connected (hsConnected)). The hsLooking value may be set to indicate that the corresponding portal has not yet received a successful request to create a full portal. The value hsConnecting may be set to indicate that the corresponding portal has received a successful request to create a full portal and a hello message 500 in units of LRPDU 500 with status hsLooking. In this case, the portal is ready to receive all LRPDUs. The hsConnected value can be set to indicate that the corresponding portal is "open" (enabled) and ready to transfer application data. In this case, the portal is allowed to send all LRPDUs. The Hello Status field 507 may also contain an Error Status field 508 (Error Status). This Error Status field 508 may contain four bits of information located in the least significant bits of an octet and may indicate errors such as a database overflow.

The hello message 500 in LRPDUs also contains a "My Portal Number" field 509 (My Portal Number) This "My Portal Number" field 509 contains a four octet number identifying the outgoing portal. The ID number is unique across all portals sharing the same instance of the LRP-DT protocol. This field is four octets long because the proxy system can perform trusted (proxy) functions for any number of slave systems, each containing a large number of target ports. Further, the proxy system can create a TCP connection with another, similar proxy system. Each proxy system uses one My Portal Number value for each target port for which that proxy system is a trusted representative. The My Portal Number field 509 is used in other messages in LRPDUs to identify which pair of target ports 141, 151, 241, and 251, and thus which portal 113, 133, 213, and 233, and ultimately which database 120, 122, 220, and 222 any particular record LRPDU, partial list LRPDU, full list LRPDU, or full list request LRPDU is associated with.

The hello message 500 in LRPDUs also contains a "Hello Time" field 511 (Hello Time). This "Hello Time" field 511 contains two octets representing the "time to live" of the hello message in units of LRPDUs. The first octet of the Hello Time field 511 is the most significant octet of the sixteen-bit number of seconds (zero to sixty-five thousand five hundred thirty-five or thirty to sixty-five thousand five hundred and thirty-five) during which the hello message 500 is in units of LRPDUs. This field may not be transmitted with a value between one and twenty-nine inclusive.

The set of the first four TLVs in the Hello500 message, in LRPDU units, contains one identifier of each type from the group of identifiers My Chassis ID TLV 513, My Port ID TLV 515, Neighbor Chassis ID TLV 517, and Neighbor Port ID TLV 519, in any order. This is followed by either zero or one of the Application Information TLV 521 values.

The type field for the My Chassis ID TLV 513 is set to typeMyChassisId. The data field for this My Chassis ID TLV 513 contains the value specified for the LLDP Chassis ID TLV transmission using the LLDP protocol instance named in the Full Portal Creation Request that created the portal transmitting the My Chassis ID TLV 513. Specifically, My Chassis ID TLV 513 contains a value identifying the local node (eg, machine) acting as the transmitter for hello message 500 in units of LRPDUs. Such a local node contains its own system or a slave system used to establish and/or maintain a pair of databases (eg, containing or associated with a local registrar, a local applicant, or both).

The type field for the identifier "My Port" ID TLV 515 is set equal to the value typeMyPortId. The data field for this My Port ID TLV 515 contains the same value as was specified for the LLDP Port ID TLV port ID transmission using the LLDP protocol instance named in the Full Portal Creation Request that created the Portal sending the My Port ID TLV. port" ID TLV 515. In particular, the identifier "My port" ID TLV 515 contains a value that identifies the target port in the local node trying to install and/or maintain a pair of databases (for example, in its own system or in a slave system). The Chassis ID and the Port ID together uniquely represent the local half of the target link for messaging in LRPDUs.

The type field for the Neighbor Chassis ID TLV 517 is set to typeNeighborChassisId. The data field for this Neighbor Chassis ID TLV 517 has the same format as the data field for the My Chassis ID TLV 513 and contains the chassis ID for the neighbor portal with which the local portal is associated. In particular, the Neighbor Chassis ID TLV 517 contains a value identifying the neighbor (eg, machine) acting as the destination of hello message 500 in units of LRPDUs. Such a neighbor contains its own system or a slave system used to establish and/or maintain a pair of databases (eg, containing or associated with a neighboring registrar, a neighboring applicant, or both).

The type field for the Neighbor Port ID TLV 519 is set to typeNeighborPortId. The data field for this Neighbor Port ID TLV 519 has the same format as the data field for the My Port ID TLV 515 and contains the port ID of the neighbor portal with which the specified local portal is associated. In particular, the Neighbor Port ID TLV 519 contains a value identifying the target port on the network node used to establish and/or maintain the database pair (eg, on the home system or on the slave system). The Neighbor Chassis ID and Neighbor Port ID together uniquely represent the adjacent half of the target link for message transmission in LRPDUs. Therefore, hello message 500 in LRPDUs represents the target link as a combination of My Chassis ID identifying the local node, My Port ID identifying the target port at the local node, Neighbor Chassis ID identifying the neighbor node , and a Neighbor Port ID identifying the target port at the neighbor.

The Application Information parameter of TLV 521 is set to typeAppInfo. The data field for "Application Information" TLV 521 contains information coming from the request to create an active portal. This data is presented to the application at the destination via a portal status indication on the destination end of the LRP-DT connection. This data may be opaque and non-interpretable by the LRP protocol. "Application Information" TLV 521 is an option.

Accordingly, the Type field 501 is one octet offset by zero octets, the Length field 503 is two octets offset by one octet, the AppId field 505 is four octets offset by three octets, the Hello Status field 507 is one octet offset by seven octets, the My Portal Number field 509 is four octets offset by eight octets, the Hello Time field 511 is two octets offset by twelve octets, and the remaining fields of TLV 513-521 are variable length with a starting offset fourteen octets.

Fig. 6 illustrates an example of encoding a write message 600 in LRPDUs that can implement a write message 407 in LRPDUs. In such a situation, an LRPDU write message 600 can be used to maintain synchronization of a pair of databases in the home system 110 and/or 130, the proxy system 210 and/or 230, the slave system 240 and/or 250, and/or in the system 300 databases. The LRPDU write message 600 contains a Type field 601 and a Length field 603, similar to the Type fields 501 and Length 503, respectively. The Type field 601 may contain a value of two to indicate the record message 600 in LRPDU units (eg, typeRecordLRPDU), and the Length field 603 contains an indication of the length of the record message 600 in LRPDU units. The first two octets in the data field in the LRPDU record message are the My Portal Number field 609 and encode the chassis ID, port ID, and appId for the emitting portal. The field has the same value as the corresponding field sent in hello message 500 in LRPDUs for the same portal. This is followed by zero (none) or more entries in the Record field 630.

Each record contains 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 an entry in the applicant's database that has been updated. The Sequence Number field 633 contains data indicating the version number and/or number of changes associated with the corresponding entry. The "Checksum" field 635 contains data for error correction, such as a two-octet value calculated from the values included in the corresponding record (for example, the values in the "Record number" field 631, in the "Sequence number" field 633, in the field "Data Length" 637 and/or in the "Application Length" field 639). The Data Length field 637, when present, indicates the length of the data in the corresponding record and/or the length of the Application Data field 639. The Application Length field 639, when present, contains the updated record when transferred from the applicant's database to the database. recorder data.

Accordingly, the entry message 600 in LRPDUs may contain one or more entry numbers identifying updated entries in the applicant's database and one or more sequence numbers identifying updates included in the updated entries in the applicant's database. Further, the Type field 601 occupies one octet offset by zero octets, the Length field 603 occupies two octets offset by one octet, the My Portal Number field 609 occupies four octets offset by three octets, and the Record field » 630 has a variable length offset of seven octets. In addition, each record contains a Record Number field 631 of four octets with a zero-shift octet, a Sequence Number field 633 of four octets with a four-octet shift, a Checksum field 635 of two octets with a shift of eight octets , a "Data Length" field 637 of two octets, offset by ten octets, and an "Application Data" field 639 of zero to sixty-five thousand, five hundred and thirty-five or thirty to sixty-five thousand, five hundred and twenty octets, and offset by twelve octets, where offsets in the record are measured from the beginning of the record.

Fig. 7 illustrates an example encoding of an LRPDU partial list message 700 that can implement an LRPDU list partial message 409. In such a case, a partial list message 700 in LRPDUs can be used to keep the pair of databases in sync on the home system 110 and/or 130, on the proxy system 210 and/or 230, on the slave system 240 and/or 250, and /or 300 databases in the system. The LRPDU partial list message 700 contains a Type field 701 and a Length field 703, which are the same as the Type field 501 and the Length field 503, respectively. The Type field 701 may contain a value of three to indicate the partial list message 700 in LRPDU units (eg, typePartialListLRPDU), and the Length field 703 contains the length of the partial list message 700 in LRPDU units.

The first two octets in the data field of the LRPDU partial list message 700 make up the My Portal Number field 709, which encodes the chassis ID, port ID, and application appId for the emitting portal. This is the same value as the value sent in Hello message 500 in LRPDUs for the same portal. Thereafter, zero or more Record header fields 730 are present, which are essentially the same as the Record fields 630, but contain no record data. In particular, each Record Header field 730 contains a Record Number field 731, a Sequence Number field 733, and a Checksum field 735, which are essentially the same as the Record Number field 631, the Serial Number field 633, and field "Checksum" 635, respectively. Further, the Record Number field 731 and the Sequence Number field 733 contain the values added by the registrar negotiating the values of the corresponding Record field 630 in the record message 600 in units of the LRPDU 600 (for example, as included in the message 600 records in units LRPDU Applicant). Therefore, the Record Header fields 730 acknowledge receipt of the Record fields 630.

Therefore, LRPDU list partial message 700 acknowledges LRPDU entry message 600, and this LRPDU list partial message 700 contains at least one Record Header field 730 acknowledging at least one updated record 630. Next the Record Title field 730 contains the record number in the Record Number field 731 indicating the updated record (for example, in the Record field 630) and the sequence number in the Sequence Number field 733 identifying the update included in the updated record (for example , in the "Record" field 630).

Fig. 8 illustrates an example encoding of a full list message 800 in LRPDUs that can implement a full list message 413, 418 and/or 421 in LRPDUs. In such a case, the full list message 800 in LRPDUs can be used to keep the pair of databases in sync on the home system 110 and/or 130, on the proxy system 210 and/or 230, on the slave system 240 and/or 250, and /or 300 databases in the system. The LRPDU listing message 800 contains a Type field 801 and a Length field 803, which are the same as the Type field 501 and the Length field 503, respectively. The Type field 801 may contain a value of four to indicate the complete list message 800 in LRPDU units (eg, typeCompleteListLRPDU), and the Length field 803 contains an indication of the length of the complete list message 800 in LRPDU units.

The first two octets in the data field of the full list message 800 in LRPDU units are the My Portal Number field 809, which encodes the chassis ID, port ID, and application appId for the emitting portal. This is the same value as the value sent in Hello message 500 in LRPDUs for the same portal. This is followed by a "First Entry Number" field 823 and a "Last Entry Number" field 825, each of which is four octets long, and these fields contain the lowest entry number and the highest entry number, respectively, covered by the message 800 in question with a complete list in units LRPDU. For example, the First Record Number field 823 and the Last Record Number field 825 contain the first record number and the last record number stored by the registrar.

This is followed by zero or more Record Title fields 830, which are essentially the same as the Record Title fields 730. However, the Record Title fields 830 contain the titles of all records present in the registrar's database, as opposed to the case where only the titles are involved. entries for acknowledged updated entries. Each Record Header field 830 contains a Record Number field 8731, a Sequence Number field 833, and a Checksum field 835, which are essentially the same as the Record Number field 731, the Sequence Number field 733, and the Checksum field. sum” 735, respectively.

Each Entry Number field 831 carried in the LRPDU Complete List Message 800 contains a value that is not less than the value in the First Entry Number field 823 and not greater than the value in the Last Entry Number field 825. The No. first entry" 823 and the "Last entry number" field 825 allow the complete list of entries known to the registrar to be split between more than one full list message 800 in LRPDUs. Pairs of the first and last entry numbers in all LRPDU-full list messages 800 contain the complete list of entries, which may cover all possible entry numbers from zero to four billion two hundred ninety-four million nine hundred sixty-seven thousand two hundred ninety-five.

Fig. 9 is a flow diagram of an exemplary method 900 for establishing a pair of databases, for example, on a native system 110 and/or 130, on a proxy system 210 and/or 230, on a slave system 240 and/or 250, and/or on a database system 300 data. Method 900 uses signaling from method 400, such as hello messages 401, 403, and/or 500 in LRPDUs. The method 900 is discussed in terms of the local node operating the applicant's database for clarity of discussion, but may also be performed wholly or partly at the node operating the registrar (eg, the local node or a neighboring node).

Method 900 begins when a local node wishes to set up a database pair to synchronize with a neighbor node. In block 901, the local node receives a hello message. This hello message contains an AppId and an indication of the target link between the target port for the local host and the target port for the neighbor. When the local host is the home system, the target port is located on the local host. When the local host is a proxy system, the target port is located on the slave system. The hello message may be a hello message in LRPDUs, such as hello message 401, 403, and/or 500 in LRPDUs. Further, the hello message in units of LRPDUs may represent the target link by a "My Chassis" ID identifying the local node or corresponding slave node, a "My Port" ID identifying a target port in the local node or corresponding slave node, a "Neighbor Chassis" ID identifying the neighbor node or the corresponding slave node, and the identifier "Neighbour Port" ID identifying the target port in the neighbor node or the corresponding slave node. To complete the hello exchange, a corresponding hello message is also sent from the local node to the neighboring node. Such a hello message may be essentially the same as a hello message received by a local node with a different "My Portal Number". For example, a hello message sent from the local node contains a "My Portal Number" field associated with the local node, and a hello message received at the local node contains a "My Portal Number" field associated with a neighbor node. Such messages may be transmitted in any order.

In block 903, the local node and/or the corresponding portal determines that the AppId is associated with the application to perform database synchronization. Based on this determination that the AppId is associated with database synchronization, a local database is set in storage at the local node in block 905. This local database is part of a pair of databases for use by the specified application. The database pair in question comprises a neighbor database installed at a neighbor node (eg, via a portal at a neighbor node). In some examples, the local database may be an applicant database for storing local records for transfer to a registrar database in a neighboring database. In some examples, the local database contains a registrar database for receiving neighboring records from an applicant database located in the neighboring database. In some examples, the local database contains both the applicant database and the registrar database.

At block 907, the database pair is associated with the target link (eg, in the home system and/or from the slave system to the proxy system). This association ensures that LRPDU messages directed to the applicant/registrar reach the correct portal, either because the portal is on the local node with the target port, or because the target port is on a slave configured to forward such messages to the proxy. - the system containing the specified portal and running in the local node.

In block 909, the local node/portal begin to manage synchronization of the local database with a neighboring database via the target link. Such control may be performed by transmitting entry information to the neighboring database over the target link in messages in units of LRPDUs. Such entry information may comprise entries, entry titles, or a combination of entries and titles. For example, such LRPDU messages may be other LRPDU hello messages 500, LRPDU write messages 600, LRPDU partial list messages 700, LRPDU full list messages 800, and/or any messages in LRPDUs. LRPDUs from method 400.

On FIG. 10 is a flow chart of an exemplary method 1000 for managing the synchronization of a pair of databases, for example, after execution of method 900 has completed. /or 250, and/or in the system 300 databases. Method 1000 uses signaling from method 400. Further, method 1000 can use messages in LRPDUs, such as hello messages 500 in LRPDUs, write messages 600 in LRPDUs, partial list messages 700 in LRPDUs, full list messages 800 in LRPDUs, units of LRPDU and/or a combination of such messages. Method 1000 is discussed in terms of the local node operating the applicant's database for clarity of discussion, but may also operate wholly or partly in the node operating the registrar (eg, local node or neighbor node).

At block 1001, the application replaces one or more entries in the applicant's database. Accordingly, the portal at the local site sends one or more write messages in units of LRPDUs to the registrar database located at the neighboring site, for example, through the neighboring portal. Record messages in LRPDUs indicate updates to records stored in the applicant's database located at the local node and may also contain such updated records. For example, the LRPDU entry messages may contain one or more entry numbers indicating updated entries in the applicant's database and one or more sequence numbers identifying updates in the updated entries in the applicant's database. Updated records may also be marked as unconfirmed (not acknowledged) in the applicant's database.

At block 1003, the portal receives one or more LRPDU messages acknowledging LRPDU entry messages from block 1001. In some examples, the set of LRPDU messages acknowledging LRPDU entry messages contains a partial list message in LRPDUs. This LRPDU partial list message contains at least one entry header acknowledging at least one updated entry from block 1001. This at least one entry header contains an entry number indicating the updated entry(s) from block 1001 and a sequence number , identifying the update(s) included in the updated entry from block 1001. In some examples, the set of LRPDU messages acknowledging the LRPDU write messages may contain a complete LRPDU list message. This full list message in LRPDUs contains the record headers for all records stored in the registrar database. Further, this LRPDU listing message contains a first entry number field indicating the first entry stored in the registrar database and a last entry number field indicating the last entry stored in the registrar database. In addition, record headers contain record numbers identifying records stored in the registrar's database and sequence numbers identifying updates included in records stored in the registrar's database.

At block 1005, at least one updated entry is marked in the applicant database as acknowledged by the registrar database based on the headers of the entries included in the partial list and/or full list message(s) in LRPDUs from block 1003.

In block 1007, the portal/applicant may determine all updated entries in the applicant database acknowledged by the registrar database via LRPDU messages. Based on the determination at block 1007 that all updated entries in the applicant database have been acknowledged by the registrar database via messages in LRPDUs, the portal/applicant notifies the application that the applicant database has been synchronized with the registrar database at block 1009.

In some cases, the LRPDU write message may not reach the registrar and/or the LRPDU partial list message may be dropped on the way back to the applicant. In such cases, at an optional block 1011, the portal generates a failure notification when the LRPDU write message timer expires without receiving a corresponding LRPDU partial list message for transmission to the application.

Block 1013 is also an option. In some examples, this portal/applicant may be configured to send a message to the registrar database requesting a complete list in LRPDUs. The registrar/neighbor portal responds with a full list message in LRPDUs. For this reason, the portal/applicant at the local site receives a full LRPDU list message from the registrar database in response to a full LRPDU list request message.

On FIG. 11 is a flow chart of an exemplary method 1100 of maintaining database synchronization despite a connection interruption, for example, after method 900 is performed and during/after method 1000 is performed. 210 and/or 230, in the slave system 240 and/or 250, and/or in the database system 300. Method 1100 uses the signaling from method 400. Further, method 1100 may use messages in LRPDUs, such as hello messages 500 in LRPDUs, entry messages 600 in LRPDUs, partial list messages 700 in LRPDUs, full list messages 800 in LRPDUs, units of LRPDU and/or a combination of such messages. Method 1100 is discussed in terms of the local node operating the applicant database for clarity of discussion, but may also be performed in whole or in part at the node operating the registrar (eg, local node or neighbor node).

Method 1100 begins when the exchange of hello messages in LRPDUs fails (failed), indicating a connection abort. In block 1101, a release code is generated for the application. This disassociation code indicates that the exchange of hello messages in units of LRPDUs was unsuccessful (did not take place). It also indicates that additional messages to the neighbor/registrar address are likely not to be received, and that previously unacknowledged (unacknowledged) messages may not reach the registrar.

The applicant may specify that a database pair should be reset (reset) after the connection is reestablished. In such a case, method 900 is used. However, the applicant may also specify that the applicant's current database needs to be resynchronized with the registrar's database when the connection is re-established. In such a case, at block 1103, the portal receives a command from the application to maintain the database of the applicant in the storage device located at the local node, despite the disconnect code.

In block 1105, the portal initializes (resets) the alert timers in the applicant database after an unsuccessful exchange of hello messages. This prevents the write message in LRPDUs from being transmitted until a full list message in LRPDUs has been received after the connection is re-established.

Hello messages in units of LRPDUs may be sent periodically in attempts to re-establish a connection. When the registrar database receives a hello message in LRPDUs after disconnection, the registrar responds with a message with a complete list in LRPDUs. Accordingly, at block 1107, the applicant/portal, after successfully exchanging hello LRPDUs, receives a message with the complete list in LRPDUs from the registrar database located at the neighboring node. This full list message in LRPDUs contains the entry headers for all entries in the registrar database.

In block 1109, the portal/applicant compares the entry headers from the full list message in LRPDUs with the entry headers stored in the applicant database to restore synchronization of the applicant database with the registrar database. In particular, at block 1111, the portal/applicant determines whether there is a record mismatch between the headers of the records included in the full list messages in LRPDUs and the headers of the records in the applicant database.

When the portal/applicant determines a mismatch between one or more record headers in the applicant database and one or more record headers from the full list message in LRPDUs, method 1100 proceeds to block 1113. The mismatch indicates that at least one previous write message in units of LRPDU were lost. Therefore, the applicant determines which record updates are not present in the full list message in LRPDUs. In block 1113, the applicant/portal sends one or more write messages in LRPDUs to the registrar database address. These write messages, in units of LRPDUs, contain the headers of the updated writes, which is necessary to deal with the misalignment and synchronization of the database pair.

When the portal/applicant determines that there is no mismatch between the record headers in the applicant database and the record headers in the registrar database, method 1100 proceeds to block 1115. Based on this determination that there is no mismatch, at block 1115, the portal/applicant may notify the application that the applicant's database is synchronized with the registrar's database.

On FIG. 12 is a simplified diagram of an example of a communications network node 1200 for managing database synchronization in accordance with one embodiment of the present invention. This node 1200 of the communication network is suitable for implementing the considered examples/options, as described here. For example, a communication network node 1200 may be used to implement a native system 110/130, a proxy system 210/230, a slave system 240/250, combinations of such systems, and/or any local node and/or neighbor node described here. . For example, such a communication network node 1200 may implement a database system 300 .

Communication network node 1200 includes downlink ports 1220, uplink ports 1250, and/or transceiver modules (Tx/Rx) 1210 having transmitters and/or receivers for transmitting data in the uplink and/or downlink over the communication network. The communication network node 1200 also includes a processor 1230 having a logic module and/or a central processing unit (CPU) for processing data, and a storage device 1232 for storing data. Communication network node 1200 may also contain opto-electrical (optical-to-electrical (OE)) components, electro-optical components (electrical-to-optical (EO)) and/or radio components connected to uplink ports 1250 and/or ports 1220 downlink for data transmission over optical or radio communication networks. Communication network node 1200 may also include input and/or output (I/O) devices for transmitting data to and from a user. Input/output (I/O) devices may include output devices such as a display for presenting video data, speakers for outputting audio data, and so on. Input/output (I/O) devices may also include input devices such as a keyboard, mouse, trackball, etc., and/or appropriate interfaces for interfacing with such output devices.

Processor 1230 is implemented in hardware and software. This processor 1230 may be implemented as one or more CPU dies, cores (such as in a multi-core processor), field-programmable gate array (FPGA), application specific integrated circuit (ASIC )) and digital signal processors (DSP). Processor 1230 is in communication with downlink ports 1220, Tx/Rx modules 1210, uplink ports 1250, and memory 1232. This processor 1230 includes an LRP-DS protocol module 1214. Such LRP-DS protocol module 1214 implements embodiments of the invention described here, such as methods 400, 900, 1000, 1100, and/or any other method/mechanism described here. Further, the LRP-DS protocol module 1214 may send, receive, and/or process messages in LLPDUs, such as hello messages 500 in LRPDUs, entries messages 600 in LRPDUs, partial list messages 700 in LRPDUs, full list messages 800 list in units of LRPDU and/or a combination of such messages. For example, LRP-DS protocol module 1214 may be used to establish a connection using hello messages in LRPDUs and establish a database pair for synchronization. As another example, the LRP-DS protocol module 1214 may be used to notify an application when all entries in an applicant have been acknowledged by the registrar and/or to notify the application when the registrar is unable to acknowledge any record update. As yet another example, LRP-DS protocol module 1214 can be used to resume synchronization of a database pair after disconnection without having to transfer all records from the applicant to the registrar. Therefore, this LRP-DS protocol module 1214 improves the functionality of the node 1200 of the communication network. Further, the LRP-DS protocol module 1214 solves computer-specific storage management problems. In addition, the LRP-DS protocol module 1214 converts the communication network node 1200 to another state. This LRP-DS protocol module 1214 may be implemented as instructions stored in memory 1232 and executed by processor 1230 (eg, as a computer program product stored on a non-volatile storage medium).

The storage device 1232 contains storage devices of one or more types, such as disks, tape devices, solid state disks, read only memory (ROM))), random access memory (RAM) (RAM))), flash memory, ternary content-addressable memory (TCAM), static random-access memory (SRAM), etc. Memory 1232 may be used as a data overflow memory for storing programs when those programs are selected for execution and for storing instructions and data read when programs are executed.

On FIG. 13 is a simplified diagram of an example device 1300 for establishing a database pair. This device 1300 may be used to implement method 400 and/or method 900. Device 1300 includes a receiving module 1301 for receiving a hello message containing an AppId and an indication of a target link between a local node and a neighbor node. This device 1300 also includes a decision module 1303 for determining that an AppId is associated with a database synchronization application. Apparatus 1300 also includes a database pair installer 1305 for establishing a local database on a local node as part of a database pair for use by an application, this database pair containing a neighbor database located at a neighbor node. Device 1300 also includes an association module 1307 for associating a pair of databases with a target link. The device also includes a synchronization control module 1309 that synchronizes the local database with a neighboring database using the target link.

On FIG. 14 is a simplified diagram of an example device 1400 for managing the synchronization of a pair of databases. This device 1400 may be used to implement method 400 and/or method 1000. Device 1400 includes a transmitter module 1401 for transmitting one or more LRPDU write messages to a registrar database address at a neighbor node, where those LRPDU write messages indicate updates. for records stored in the applicant's database at the local node. The device 1400 also includes a receiving module 1403 for receiving one or more LRPDU messages acknowledging the write LRPDU messages. The device 1400 also includes a memory module 1405 for marking at least one updated entry in the applicant's database as acknowledged by the registrar's database. This device 1400 also includes a decision module 1407 for determining that all updated entries from the applicant database have been acknowledged by the registrar database via LRPDU messages. The device 1400 also includes a notification generation module 1409 to notify the application that the applicant database is synchronized with the registrar database based on a determination that all updated entries in the applicant database have been acknowledged by the registrar database via LRPDU messages.

Fig. 15 is a simplified diagram of an exemplary device 1500 for maintaining database synchronization despite connection interruptions. This device 1500 may be used to implement method 400 and/or method 1100. Device 1500 includes a release notification module 1501 for generating a release code for the application, where the release code indicates that the exchange of hello messages in LRPDUs did not take place (was unsuccessful). . This device 1500 also includes a command module 1503 for receiving a command from the application to maintain the database of the applicant in the storage device at the local node, despite the disconnect code. The device 1500 also includes a receiving module 1505 for receiving a full list message in LRPDUs from a registrar database located at a neighboring node after a successful exchange of a hello message, where such a full list message in LRPDUs contains the record headers for all records stored in registrar database. This device 1500 also includes a record comparison module 1507 for comparing the headers of the records included in the full list message in LRPDUs with the headers of the records stored in the applicant database in order to restore synchronization of the applicant database with the registrar database.

In one embodiment, the node or element comprises a transmitter for transmitting one or more Local Link Registration Protocol Data Unit (LRPDU) record messages to a registrar database address located at a neighboring node, where the LRPDU record messages denote updates to records stored in the applicant's database located at the local node, as well as a receiver to receive one or more LRPDU messages acknowledging the LRPDU write messages. Said node or element further comprises a storage device for marking at least one updated entry in the applicant's database as confirmed (acknowledged) by the registrar's database. Said node or element also includes a decision device for determining that all updated entries in the applicant database have been acknowledged by the registrar database through messages in units of LRPDUs, and a notifying device for notifying the application that the applicant database is synchronized with the registrar database based on determining that all updated entries in the applicant's database are acknowledged by the registrar's database via messages in LRPDUs.

The first component is considered to be directly connected to the second component when there are no intermediate components between these first and second components, except for a link, track or other medium. A first component is considered to be indirectly associated with a second component when there are intermediate components other than a link, track, or other medium between those first and second components. The term "coupled" and its variants cover both direct communication and indirect communication. The term "about" means a range covering ±10% of the following number, unless specifically stated otherwise.

While several variations are provided herein, it may be understood that the systems and methods contemplated may be implemented in a variety of other specific forms without departing from the spirit or scope of the present invention. The examples presented here are to be considered illustrative only and not exhaustive, so the present description is not intended to limit the invention to the details discussed here. For example, various elements or components may be combined or integrated into another system, or some features may be omitted or not implemented.

In addition, technologies, systems, subsystems and methods, described and illustrated in various ways as discrete or separate, can be combined or integrated with other systems, components, technologies or methods without deviating from the scope of the present invention. A person skilled in the art can understand other examples of substitutions, substitutions and changes and implement them without deviating from the meaning and scope described here.

Claims (57)

1. The method of database synchronization, carried out in the local node, the method contains: receiving, at the local node receiver, a hello message containing an application identifier (AppId) and an indication of the target link between the target port of the local node and the target port of the neighbor node; determining, by the processor at the local node, an AppId associated with the application for performing database synchronization; establishing a local database in storage at the local node as part of a database pair for use by said application, the database pair containing a neighbor database located at the neighbor node; association, by the processor, of the database pair in question with the target link; and synchronization of the local database with a neighboring database using the target link. 2. The method according to claim. 1, characterized in that the procedure for managing synchronization of the local database with the neighboring database comprises transmitting, by means of a transmitter from the local node, information of records to the address of the neighboring database over the target communication line in messages in data units of the local registration protocol. communication lines (link-local registration protocol data unit (in units of LRPDU)). 3. The method according to any of paragraphs. 1, 2, characterized in that the local database contains the applicant's database for saving local records in order to transfer them to the address of the registrar's database located in the neighboring database. 4. The method according to any of paragraphs. 1-3, characterized in that the local database contains a registrar database for receiving neighboring records from the applicant's database located in the neighboring database. 5. The method according to any one of paragraphs. 1-4, characterized in that the hello message is a hello LRPDU and that the hello LRPDU represents the target link by means of a My Chassis Identifier (ID) identifying the local node, a My Port ID identifying the target port at the local node, the Neighbor Chassis ID identifying the neighbor, and the Neighbor Port ID identifying the target port at the neighbor. 6. The method of database synchronization carried out in the local node, the method includes: transmission, by the transmitter from the local node, of one or more Local Link Registration Protocol Data Unit (LRPDU) record messages to the address of the registrar database located at the neighbor node, where these LRPDU record messages indicate updates to the records stored in the database of the applicant, located in the local node; receiving, at the local node receiver, one or more LRPDU messages acknowledging the LRPDU entry messages; marking, in a storage device located in the local node, at least one updated entry in the database of the applicant as acknowledged by the database of the registrar. 7. The method according to any one of paragraphs. 1-6, further comprising determining, by the processor at the local node, that all updated entries in the applicant database have been acknowledged by the registrar database via messages in LRPDUs, where notification to the application that the applicant database is synchronized with the registrar database is initiated at on the basis of determining that all updated records in the applicant database are acknowledged by the registrar database via messages in LRPDUs. 8. The method according to any one of paragraphs. 1-7, characterized in that the set of messages in LRPDUs acknowledging record messages in LRPDUs contains a message with a partial list in LRPDUs, where this message with a partial list in LRPDUs contains at least one record header acknowledging the specified by at least one updated entry. 9. The method according to any one of paragraphs. 1-8, characterized in that the entry header contains an entry number indicating the updated entry and a sequence number identifying the update included in this updated entry. 10. The method according to any one of paragraphs. 1-9, further comprising generating a failure notification to be sent to the application when the timer for the write LRPDU message expires without receiving a corresponding LRPDU partial list message. 11. The method according to any of paragraphs. 1-10, characterized in that the set of messages in units of LRPDU, acknowledging messages of entries in units of LRPDU, contains a message with a complete list in units of LRPDU, where this message with a full list in units of LRPDU contains the headers of records regarding all records in the database registrar. 12. The method according to any of paragraphs. 1-11, characterized in that the specified message with a complete list in LRPDU units contains a field with the first record number, indicating the first record stored in the registrar database, and a field with the last record number, indicating the last record stored in the registrar database, and in that the record headers contain record numbers identifying records stored in the registrar's database and sequence numbers identifying updates included in those records stored in the registrar's database. 13. The method according to any of paragraphs. 1-12, characterized in that the record messages in LRPDUs contain one or more record numbers indicating updated records in the database of the applicant, and one or more sequence numbers identifying updates included in these updated records in the database of the applicant. 14. The method according to any of paragraphs. 1-13, additionally containing: transmitting, by said transmitter, a message requesting a complete list in units of LRPDUs to the registrar database address; and receiving, via the specified receiver, a message with a complete list in LRPDUs from the registrar database in response to a message requesting a complete list in LRPDUs. 15. The method of database synchronization, carried out in the local node, the method contains: generating, by the processor located at the local node, a release code for the application, where the release code indicates that the exchange of hello messages in local link registration data units (LRPDUs) was unsuccessful (did not take place); receiving, at said processor, an instruction from the application in question to maintain the applicant's database in storage at the local node despite the disconnect code; receiving, at the receiver at the local node, a full list message in LRPDUs from a registrar database located in a neighboring node, after a successful exchange of hello LRPDU messages, a full list message in LRPDUs containing the record headers for all records, stored in the registrar's database; and comparing, as indicated by the processor, the record headers from the message with the full list in LRPDUs with the record headers stored in the applicant database in order to restore synchronization of the applicant database with the registrar database. 16. The method according to any one of paragraphs. 1-15, further comprising initializing (resetting) the notification timers in the applicant database after an unsuccessful exchange of hello messages to prevent the transmission of write messages in LRPDUs until a message with a complete list in LRPDUs is received. 17. The method according to any one of paragraphs. 1-16, further comprising: determining, by said processor, a mismatch between one or more entry headers stored in the applicant's database and one or more entry headers from the full list message in LRPDUs; and sending an LRPDU write message to the registrar database address, where the LRPDU write message contains the headers of the updated records associated with the mismatch. 18. The method according to any one of paragraphs. 1-17, additionally containing: determining, by said processor, that there is no mismatch between the titles of the records stored in the applicant's database and the titles of the records stored in the registrar's database; and based on the determination that there is no mismatch, notifying, via said processor, the application that the applicant's database is synchronized with the registrar's database. 19. The method according to p. 1, additionally containing the method according to any one of paragraphs. 6 and 15. 20. The method of claim 6, further comprising the method of claim 15. 21. A local node, further comprising a storage device, a transmitter, a receiver and a processor connected to this storage device, where these transmitter, receiver, local node are configured to implement the method according to any one of paragraphs. 1-20. 22. A non-volatile computer-readable storage medium containing a computer program product for use by a local node, this computer program product contains computer-executable instructions stored on the specified non-volatile computer-readable storage medium, so that when executed by the processor, these instructions control the local node to implement the method by which - either from paragraphs. 1-20. 23. Local node containing: a receiving device for receiving a hello message containing an application identifier (AppId) and an indication of a target link between the local node and the neighboring node; a decision device for determining that the specified AppId is associated with an application for performing database synchronization; a device for establishing a database pair for establishing a local database in the local node as part of the database pair for use by the specified application, where this pair of databases also contains a neighboring database located in the neighboring node; an association device for associating the database pair with the target link; and a synchronization control device for controlling synchronization of the local database with the neighboring database via the target link. 24. Local node containing: a transmitting device for transmitting one or more record messages in local link registration protocol data units (in LRPDUs) to the address of the registrar database located at the neighbor node, where these record messages in LRPDUs indicate updates of records stored in the database of the applicant, located in the local node; a receiving device for receiving one or more LRPDU messages acknowledging said LRPDU write messages; a storage device for marking at least one updated entry stored in the applicant's database as acknowledged by the registrar's database; a resolver for determining that all updated records stored in the applicant's database have been acknowledged by the registrar's database via messages in LRPDUs. 25. Local node containing: a release device for generating a release code for the application, this release code indicates that the exchange of hello messages in local link registration data units (in units of LRPDU) did not take place (was not successful); a command device for receiving a command from said application to maintain the database of the applicant in a storage device located at the local node despite the disconnect code; a receiving device to receive a full list message in LRPDUs from the registrar database located in the neighbor node after a successful exchange of hello messages, where the full list message in LRPDUs contains the record headers related to all records stored in the registrar database ; and a record comparison device for comparing the record headers from the full list message in LRPDUs with the record headers stored in the applicant database to restore synchronization of the applicant database with the registrar database. 26. Local node according to any one of paragraphs. 23-25, further comprising a device for implementing the method according to any one of paragraphs. 1-20.

Images