JP7128288B2 - Point-to-point database synchronization over transport protocol - Google Patents

Point-to-point database synchronization over transport protocol Download PDF

Info

Publication number
JP7128288B2
JP7128288B2 JP2020555332A JP2020555332A JP7128288B2 JP 7128288 B2 JP7128288 B2 JP 7128288B2 JP 2020555332 A JP2020555332 A JP 2020555332A JP 2020555332 A JP2020555332 A JP 2020555332A JP 7128288 B2 JP7128288 B2 JP 7128288B2
Authority
JP
Japan
Prior art keywords
database
lrpdu
record
local
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020555332A
Other languages
Japanese (ja)
Other versions
JP2021520554A (en
Inventor
チュヨン,ディーン
フィン,ノーマン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2021520554A publication Critical patent/JP2021520554A/en
Priority to JP2022130560A priority Critical patent/JP2022172168A/en
Priority to JP2022130561A priority patent/JP7479427B2/en
Application granted granted Critical
Publication of JP7128288B2 publication Critical patent/JP7128288B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • H04L45/026Details of "hello" or keep-alive messages
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1004Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's to protect a block of data words, e.g. CRC or checksum
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/235Update request formulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Quality & Reliability (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

[関連出願への相互参照]
この特許出願は、Dean Chengらにより2018年4月10日に出願された「Point-to-Point Database Synchronization Over a Transport Protocol」という名称の米国仮特許出願第62/655,625号と、Dean Chengらにより2018年12月20日に出願された「Point-to-Point Database Synchronization Over a Transport Protocol」という名称の米国仮特許出願第62/782,993号との優先権を主張し、これらを参照により援用する。
[Cross reference to related application]
This patent application is based on U.S. Provisional Patent Application No. 62/655,625, entitled "Point-to-Point Database Synchronization Over a Transport Protocol," filed April 10, 2018 by Dean Cheng et al. No. 62/782,993, entitled "Point-to-Point Database Synchronization Over a Transport Protocol," filed December 20, 2018, is hereby incorporated by reference.

[技術分野]
本開示は、一般的にデータベース管理に関し、具体的にはポイント・ツー・ポイント・データベース同期を管理するための通信プロトコルに関する。
[Technical field]
TECHNICAL FIELD This disclosure relates generally to database management, and specifically to communication protocols for managing point-to-point database synchronization.

データベース同期は、複数のデータベースシステムの間の一貫性を確立するプロセスである。データベース同期の目的は、第1のデータベースへの変更が1つ以上の対応するデータベースシステムに伝搬されることを確保することである。データベース同期は、他の実装と相互運用可能でない可能性がある複雑なアプリケーション特有の実装を作成することを含む可能性がある。このようなアプリケーションは、一貫性を確保して情報が他のデータベースシステムにより実際に受信されることを検証するために、通信リソースを管理するためのメカニズムを実装する必要がある可能性がある。さらに、データベース同期を維持することは、接続の喪失の場合に問題となる可能性がある。例えば、接続を再確立したときに全てのデータベースファイルを再送することは、いくつかの場合に通信リソースの非効率的な使用になる可能性がある。 Database synchronization is the process of establishing consistency between multiple database systems. The purpose of database synchronization is to ensure that changes to a first database are propagated to one or more corresponding database systems. Database synchronization can involve creating complex application-specific implementations that may not be interoperable with other implementations. Such applications may need to implement mechanisms for managing communication resources to ensure consistency and verify that information is actually received by other database systems. Furthermore, maintaining database synchronization can be problematic in case of connection loss. For example, retransmitting all database files when a connection is reestablished can be an inefficient use of communication resources in some cases.

実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードの受信機において、アプリケーション識別子(AppId)と、ローカルノードのターゲットポートと隣接ノードのターゲットポートとの間のターゲットリンクとを含むハロー(Hello)メッセージを受信するステップと、ローカルノードのプロセッサにより、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するステップと、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードのメモリにローカルデータベースを設定するステップであり、データベース対は隣接ノードの隣接データベースを含む、ステップと、プロセッサにより、データベース対をターゲットリンクに関連付けるステップと、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するステップとを含む。この手法は、通信プロトコルがネットワーク上で同期のために1つ以上のデータベース対を自動的に設定することを可能にする。プロトコルは、ハローメッセージからターゲットリンク及びAppIdを取得する。次いで、プロトコルは、アプリケーションをターゲットリンクに互いに関連付け、アプリケーションの代わりに同期のためのデータベースを設定できる。このように、データベース設定がアプリケーションからオフロードでき、これは、アプリケーションによる直接の管理なしに、データベース同期が設定されて維持されることを可能にする。次に、これは、アプリケーションがこのような同期を達成するために基礎となるネットワークメッセージングを直接認識することなく、データベース同期を成立させることを可能にする。 In an embodiment, the disclosure includes a method implemented at a local node, wherein at a receiver of the local node, an application identifier (AppId) and an receiving a Hello message containing a target link of and determining, by the processor of the local node, that the AppId is associated with an application for performing database synchronization; setting up a local database in the memory of the local node, the database pair comprising adjacent databases of adjacent nodes; associating, by the processor, the database pair with the target link; and controlling the synchronization of the local database with neighboring databases. This approach allows a communication protocol to automatically set up one or more database pairs for synchronization over a network. The protocol gets the target link and AppId from the hello message. The protocol can then associate the application with the target link and set up the database for synchronization on behalf of the application. In this way, database configuration can be offloaded from the application, which allows database synchronization to be set and maintained without direct management by the application. This in turn allows the application to achieve database synchronization without direct knowledge of the underlying network messaging to achieve such synchronization.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、隣接データベースとのローカルデータベースの同期を制御するステップが、ローカルノードの送信機により、リンクローカル登録プロトコルデータユニット(Link-Local Registration Protocol Data Unit, LRPDU)メッセージにおいてターゲットリンクを介してレコード情報を隣接データベースに送信するステップを含むことを含む。データベース情報は、レコードに記憶される。レコードバージョン情報(例えば、制御情報)は、ターゲットリンク上で送信されるLRPDUを介して交換される。したがって、LRPDUメッセージは、データベースレコードが更新されたことを隣接ノードに示すためのメカニズムとして機能でき、その逆も可能である。したがって、LRPDUメッセージは、データベース同期を管理するために使用できる。 Optionally, in any of the above aspects, other implementations of the aspect, wherein the step of controlling synchronization of the local database with a neighboring database comprises a link-local registration protocol data unit (Link-Local Registration Protocol Data Unit) sent by the transmitter of the local node sending the record information to the neighbor database over the target link in a Local Registration Protocol Data Unit (LRPDU) message. Database information is stored in records. Record version information (eg, control information) is exchanged via LRPDUs sent on the target link. Thus, LRPDU messages can serve as a mechanism to indicate to neighboring nodes that database records have been updated, and vice versa. Therefore, LRPDU messages can be used to manage database synchronization.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルデータベースが、隣接データベース内の登録側データベースへの送信のために、ローカルレコードを記憶するための申請側データベースを含むことを含む。 Optionally, in any of the above aspects, another implementation of the aspect is that the local database includes an applicant database for storing local records for transmission to an enroller database in a neighboring database Including.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルデータベースが、隣接データベース内の申請側データベースから隣接レコードを受信するための登録側データベースを含むことを含む。データベース対は、アップロードされるべきレコードを含む申請側と、申請側レコードのコピーを受信する登録側とを含む。ローカルノード及び隣接ノードは、双方向同期のために申請側データベースと登録側データベースとの双方をそれぞれ含むことができる。さらに、一方向同期のために、申請側データベースはローカルノードに配置でき、登録側データベースは隣接ノードに配置でき、或いはその逆も同様である。 Optionally, in any of the above aspects, another implementation of the aspect includes the local database includes a registration database for receiving neighbor records from the applicant database in the neighbor database. A database pair includes an applicant that contains the records to be uploaded and a registrant that receives copies of the applicant records. The local node and neighboring nodes can each contain both an applicant database and a subscriber database for two-way synchronization. Further, for one-way synchronization, the applicant database can be located on the local node and the registering database can be located on the adjacent node, or vice versa.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ハローメッセージがハローLRPDUであり、ハローLRPDUが、ローカルノードを識別するマイシャーシ(My Chassis)識別子(ID)、ローカルノード上のターゲットポートを識別するマイポート(My Port)ID、隣接ノードを識別する隣接シャーシ(Neighbor Chassis)ID、及び隣接ノード上のターゲットポートを識別する隣接ポート(Neighbor Port)IDとして、ターゲットリンクを表すことを含む。ターゲットリンクは、シャーシID及びポートIDにより指定でき、これは、ターゲットリンクの各端のターゲットポートを表す。この手法は、ターゲットリンクの一意の識別を可能にし、したがって、対応するノードがLRPDU通信目的のために配置できる場合、ローカルノード及び隣接ノードのそれぞれへの指示を可能にする。 Optionally, in any of the above aspects, another implementation of that aspect is that the hello message is a hello LRPDU, and the hello LRPDU is a My Chassis Identifier (ID) that identifies the local node, the local node A target link is defined as a My Port ID that identifies the target port on the top, a Neighbor Chassis ID that identifies the adjacent node, and a Neighbor Port ID that identifies the target port on the adjacent node. Including representing. A target link can be specified by a chassis ID and a port ID, which represent the target ports at each end of the target link. This approach allows for unique identification of the target link and therefore indication to each of the local and neighboring nodes if the corresponding node can be located for LRPDU communication purposes.

実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードの送信機により、1つ以上のレコード(Record)LRPDUメッセージを隣接ノードの登録側データベースに送信するステップであり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、ステップと、ローカルノードの受信機により、レコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信するステップと、ローカルノードのメモリにおいて、登録側データベースによる承認済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするステップと、プロセッサを介して、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップとを含む。このメカニズムは、ネットワーク通信プロトコルがデータベース通信を監視してデータベースがいつ同期されるかを決定することを可能にする。次いで、ネットワークプロトコルは、同期が完了したことをアプリケーションに警告できる。このように、アプリケーションは、各レコード交換及び関連する通信を認識する必要がない。アプリケーションは、ローカル申請側データベースに変更を加え、ネットワークプロトコルが同期を管理して同期が完了したときにアプリケーションに警告することを可能にすることができる。 In an embodiment, the disclosure includes a method implemented at a local node, the method comprising sending, by a transmitter at the local node, one or more Record LRPDU messages to a registrant database of a neighboring node. and the record LRPDU message indicates an update to a record stored in an applicant database of the local node; and receiving, by a receiver of the local node, one or more LRPDU messages acknowledging the record LRPDU message. marking, in the memory of the local node, at least one updated record in the applicant database as approved by the applicant database; and, via the processor, synchronizing the applicant database with the applicant database. and notifying the application that the This mechanism allows network communication protocols to monitor database communications to determine when databases are synchronized. The network protocol can then alert the application that synchronization is complete. In this way, applications need not be aware of each record exchange and associated communication. An application can make changes to the local applicant database and allow the network protocol to manage the synchronization and alert the application when the synchronization is complete.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルノードのプロセッサにより、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたと決定するステップを更に含み、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップは、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたという決定に基づいて開始されることを含む。申請側は、各レコードがいつ承認されるかを決定し、全てのレコードが承認されたときにアプリケーションに通知でき、したがって、申請側データベースと登録側データベースとの間の同期が完了する。 Optionally, in any of the above aspects, another implementation of that aspect causes the processor of the local node to indicate that all updated records in the applicant database have been approved by the registrant database via LRPDU messages. The step of notifying the application that the applicant database is synchronized with the registrant database determines that all updated records in the applicant database have been acknowledged by the registrant database via LRPDU messages. including being initiated on the basis of a determination that The applicant can determine when each record is approved and notify the application when all records have been approved, thus completing synchronization between the applicant and subscriber databases.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージを承認するLRPDUメッセージが、部分リスト(Partial List)LRPDUメッセージを含み、部分リストLRPDUメッセージが、少なくとも1つの更新されたレコードを承認する少なくとも1つのレコードヘッダを含むことを含む。部分リストLRPDUメッセージは、承認メッセージとして機能する。部分リストLRPDUメッセージは、登録側から送信され、登録側がレコードLRPDUメッセージにより要求された更新を行ったことを申請側に示す。 Optionally, in any of the above aspects, another implementation of that aspect is that the LRPDU message acknowledging the record LRPDU message comprises a Partial List LRPDU message, the Partial List LRPDU message comprising at least one Containing at least one record header authorizing the updated record. Partial list LRPDU messages act as acknowledgment messages. The Partial List LRPDU message is sent by the registrant to indicate to the applicant that the registrant has made the updates requested by the record LRPDU message.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードヘッダが、更新されたレコードを示すレコード番号と、更新されたレコードに含まれる更新を識別するシーケンス番号とを含むことを含む。このような情報は、登録側により受信された特定のレコード更新を示すことができる。 Optionally, in any of the above aspects, another implementation of that aspect is that the record header includes a record number indicating the updated record and a sequence number identifying the update contained in the updated record Including. Such information can indicate specific record updates received by the registrant.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、対応する部分リストLRPDUメッセージを受信することなく、レコードLRPDUメッセージタイマが満了したとき、アプリケーションへの障害通知を生成するステップを更に含むことを含む。このメカニズムは、申請側が潜在的なレコード通信障害について通知されることを可能にする。レコードLRPDUメッセージは、大量の通信が登録側の受信バッファを溢れさせる可能性がある(例えば、より多くのレコード同期障害を潜在的に引き起こす)ので、自動的に再送されなくてもよい。 Optionally, in any of the above aspects, another implementation of that aspect generates a failure notification to the application when a record LRPDU message timer expires without receiving a corresponding partial list LRPDU message. further comprising This mechanism allows applicants to be notified of potential record communication failures. Record LRPDU messages may not be resent automatically, as a large amount of communication could overwhelm the registrant's receive buffer (eg, potentially causing more record sync failures).

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージを承認するLRPDUメッセージが、完全リスト(Complete List)LRPDUメッセージを含み、完全リストLRPDUメッセージが、登録側データベースの全てのレコードのレコードヘッダを含むことを含む。完全リストLRPDUメッセージは、登録側により所定の間隔で送信できる。完全リストLRPDUメッセージは、登録側データベースの現在の状態を含む。したがって、申請側は、いつレコード更新が登録側により受信されなかったかということに対して、いつレコードが登録側により受信されて承認メッセージが欠落したかということを決定するために、完全リストLRPDUメッセージを使用できる。次いで、申請側は、完全リストLRPDUメッセージの内容に基づいて更なるレコードLRPDUメッセージを送信することにより、同期エラーから回復できる。 Optionally, in any of the above aspects, another implementation of that aspect is that the LRPDU message acknowledging the record LRPDU message comprises a Complete List LRPDU message, and the Complete List LRPDU message including record headers for all records in A complete list LRPDU message can be sent at predetermined intervals by the registrant. The Complete List LRPDU message contains the current state of the registrant database. Therefore, the Applicant must send a Complete List LRPDU message to determine when a Record has been received by the Registrar and an Acknowledgment message is missing versus when a Record Update has not been received by the Registrant. can be used. The applicant can then recover from the synchronization error by sending further Record LRPDU messages based on the contents of the Complete List LRPDU message.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、完全リストLRPDUメッセージが、登録側データベースに記憶された最初のレコードを示す先頭レコード番号フィールドと、登録側データベースに記憶された最後のレコードを示す最終レコード番号フィールドとを含み、レコードヘッダが、登録側データベースに記憶されたレコードを示すレコード番号と、登録側データベースに記憶されたレコードに含まれる更新を識別するシーケンス番号とを含むことを含む。 Optionally, in any of the above aspects, another implementation of the aspect is that the complete list LRPDU message includes a first record number field indicating the first record stored in the registrant database and a record stored in the registrant database. a last record number field indicating the last record stored in the registering database, the record header including a record number indicating the record stored in the registering database and a sequence number identifying the update contained in the record stored in the registering database; including including

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージが、申請側データベースで更新されたレコードを示す1つ以上のレコード番号と、申請側データベースで更新されたレコードに含まれる更新を識別する1つ以上のシーケンス番号とを含むことを含む。 Optionally, in any of the above aspects, another implementation of that aspect is that the record LRPDU message includes one or more record numbers indicating records updated in the requesting database and and one or more sequence numbers that identify updates contained in the record.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、送信機により、要求完全リスト(Request Complete List)LRPDUメッセージを登録側データベースに送信するステップと、受信機により、要求完全リストLRPDUメッセージに応じて登録側データベースから完全リストLRPDUメッセージを受信するステップとを更に含むことを含む。このメカニズムを使用することにより、申請側は、周期的な完全リストLRPDUメッセージを待機するのではなく、オンデマンドで完全リストLRPDUメッセージを要求できる。 Optionally, in any of the above aspects, another implementation of the aspect includes, by the transmitter, sending a Request Complete List LRPDU message to the registrant database; receiving a complete list LRPDU message from the registrant database in response to the list LRPDU message. By using this mechanism, applicants can request complete list LRPDU messages on demand, rather than waiting for periodic complete list LRPDU messages.

実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードのプロセッサにより、アプリケーションのための切断コードを生成するステップであり、切断コードは、ハロー(Hello)リンクローカル登録プロトコルデータユニット(Link-Local Registration Protocol Data Unit, LRPDU)メッセージの交換が失敗したことを示す、ステップと、プロセッサにおいて、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するステップと、ローカルノードの受信機により、ハローLRPDUメッセージの成功した交換の後に、隣接ノードの登録側データベースから完全リストLRPDUメッセージを受信するステップであり、完全リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む、ステップと、プロセッサにより、申請側データベースを登録側データベースと再同期させるために、完全リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するステップとを含む。このメカニズムは、接続喪失にもかかわらず、データベース対を維持することを可能にする。接続喪失が発生したとき、申請側は通知され、(例えば、全てのレコードを再送することにより)接続再確立のときに同期をリセットするか、接続再確立のときに同期を回復するかを選択することが可能になる。データベース対は、ハロー交換を介して再接続したとき、登録側から完全リストメッセージを送信することにより維持できる。次いで、申請側データベースは、存在する場合にはどの更新が接続喪失により失われたかを決定するために、登録側データベースからのレコードヘッダを申請側データベースのレコードヘッダと比較できる。次いで、申請側データベースは、申請側データベースレコードの全体リストを登録側に再送する代わりに、失われた更新のみを再送できる。このような手法は、申請側と登録側との間のネットワーク接続が発生したとき、ネットワークリソース使用及び同期回復時間を減少させてもよい。 In an embodiment, the disclosure includes a method implemented at a local node, the method comprising generating, by a processor of the local node, a disconnect code for an application, the disconnect code being a Hello link indicating that a Link-Local Registration Protocol Data Unit (LRPDU) message exchange failed; receiving a complete list LRPDU message from a neighboring node's registrant database after successful exchange of a hello LRPDU message by a receiver of the local node; includes the record headers of all records in the registrant database; and causing the processor to convert the record headers from the complete list LRPDU message to the records in the applicant database to resynchronize the applicant database with the registrant database. and comparing with the header. This mechanism allows database pairs to be maintained despite connection loss. When a connection loss occurs, the applicant is notified and chooses to reset synchronization upon connection re-establishment (e.g., by resending all records) or to restore synchronization upon connection re-establishment. it becomes possible to A database pair can be maintained by sending complete list messages from registrants when reconnected via the hello exchange. The requesting database can then compare the record headers from the registering database with those of the requesting database to determine which, if any, updates were lost due to the loss of connectivity. The applicant database can then resend only the missing updates instead of resending the entire list of applicant database records to the registrant. Such an approach may reduce network resource usage and synchronization recovery time when network connectivity between applicants and registrants occurs.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、完全リストLRPDUメッセージが受信されるまでレコードLRPDUメッセージの送信を防止するために、ハローメッセージの失敗した交換の後に、申請側データベースにおいて通知タイマをリセットするステップを更に含むことを含む。これは、接続が復元されるまで申請側データベースがデータベースを同期させるのを試みることを停止させ、したがって、ネットワーク及び処理リソースを節約する。 Optionally, in any of the above aspects, other implementations of that aspect apply after a failed exchange of hello messages to prevent transmission of record LRPDU messages until a complete list LRPDU message has been received. Further comprising resetting a notification timer at the side database. This stops the requesting database from trying to synchronize the databases until connectivity is restored, thus saving network and processing resources.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、プロセッサにより、申請側データベース内の1つ以上のレコードヘッダと完全リストLRPDUメッセージからの1つ以上のレコードヘッダとの間の不一致を決定するステップと、レコードLRPDUメッセージを登録側データベースに送信するステップであり、レコードLRPDUメッセージは、不一致に対処する更新されたレコードヘッダを含む、ステップとを更に含むことを含む。不一致の場合、更新されたレコードが申請側から登録側に送信できる。これは、以前のレコードLRPDUメッセージが接続喪失で失われたために発生する可能性がある。 Optionally, in any of the above aspects, another implementation of that aspect causes the processor to determine between one or more record headers in the applicant database and one or more record headers from the Complete List LRPDU message. and sending a record LRPDU message to the registrant database, the record LRPDU message including an updated record header that addresses the discrepancy. In the event of a mismatch, an updated record can be sent from the applicant to the applicant. This may occur because previous record LRPDU messages were lost due to connection loss.

任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、プロセッサにより、申請側データベース内のレコードヘッダと登録側データベースからのレコードヘッダとの間の不一致がないことを決定するステップと、不一致がないことの決定に基づいて、プロセッサを介して、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップとを更に含むことを含む。これは、ネットワークプロトコルがアプリケーションの代わりに同期を管理することを可能にし、したがって、アプリケーションがデータベース同期に関する通信仕様を認識しないことを可能にする。 Optionally, in any of the above aspects, another implementation of that aspect comprises determining, by the processor, that there is no mismatch between record headers in the applicant database and record headers from the enrollee database. and, based on the determination that there are no discrepancies, notifying the application, via the processor, that the applicant database is in sync with the enrollee database. This allows the network protocol to manage synchronization on behalf of the application, thus allowing the application to be unaware of the communication specifications for database synchronization.

実施形態では、当該開示は、メモリと、送信機と、受信機と、メモリ、送信機、受信機に結合されたプロセッサとを含むローカルノードを含み、ローカルノードは、上記の態様の方法を実行するように構成される。 In embodiments, the disclosure includes a local node including a memory, a transmitter, a receiver, and a processor coupled to the memory, transmitter, and receiver, the local node performing the methods of the above aspects. configured to

実施形態では、当該開示は、ローカルノードによる使用のためのコンピュータプログラム製品を含む非一時的なコンピュータ読み取り可能媒体を含み、コンピュータプログラム製品は、プロセッサにより実行されたとき、ローカルノードに上記の態様の方法を実行させるように、非一時的なコンピュータ読み取り可能媒体に記憶されたコンピュータ実行可能命令を含む。 In embodiments, the disclosure includes a non-transitory computer-readable medium containing a computer program product for use by a local node, the computer program product, when executed by a processor, causing the local node to perform the aspects described above. It includes computer-executable instructions stored on a non-transitory computer-readable medium to cause the method to be performed.

実施形態では、当該開示は、ローカルノードを含み、アプリケーション識別子(AppId)と、ローカルノードと隣接ノードとの間のターゲットリンクとを含むハローメッセージを受信するための受信モジュールと、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するための決定モジュールと、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードにローカルデータベースを設定するためのデータベース対設定モジュールであり、データベース対は隣接ノードの隣接データベースを含む、データベース対設定モジュールと、データベース対をターゲットリンクに関連付けるための関連付けモジュールと、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するための同期制御モジュールとを含む。 In embodiments, the disclosure includes a local node, a receiving module for receiving a hello message that includes an application identifier (AppId) and a target link between the local node and a neighboring node; a determination module for determining to be associated with an application for execution; and a database pair configuration module for configuring the local database on the local node as part of the database pair for use by the application, wherein the database pair is a database pair configuration module containing adjacent databases of adjacent nodes; an association module for associating database pairs with target links; and a synchronization control module for controlling synchronization of the local database with the adjacent database via the target link. including.

実施形態では、当該開示は、ローカルノードを含み、1つ以上のレコードリンクローカル登録プロトコルデータユニット(LRPDU)メッセージを隣接ノードの登録側データベースに送信するための送信モジュールであり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、送信モジュールと、レコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信するための受信モジュールと、登録側データベースによる承認済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリモジュールと、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたと決定するための決定モジュールと、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知モジュールとを含む。 In embodiments, the disclosure includes a local node, a transmission module for transmitting one or more Record Link Local Registration Protocol Data Unit (LRPDU) messages to a registrant database of a neighboring node, the Record LRPDU messages comprising: a sending module for receiving one or more LRPDU messages acknowledging the record LRPDU messages indicating updates to records stored in the local node's applicant database; and as approved by the registrant database, A memory module for marking at least one updated record in the applicant database and a determination for determining that all updated records in the applicant database have been approved by the registrant database via LRPDU messages. Based on the module and the determination that all updated records in the requesting database have been acknowledged by the registering database via LRPDU messages, notify the application that the requesting database is in sync with the registering database. and a notification module for

実施形態では、当該開示は、ローカルノードを含み、アプリケーションのための切断コードを生成するための切断モジュールであり、切断コードは、ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの交換が失敗したことを示す、切断モジュールと、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するためのコマンドモジュールと、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完全リストLRPDUメッセージを受信するための受信モジュールであり、完全リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む、受信モジュールと、申請側データベースを登録側データベースと再同期させるために、完全リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するためのレコード比較モジュールとを含む。 In an embodiment, the disclosure includes a local node and a disconnection module for generating a disconnection code for an application, the disconnection code indicating a failure to exchange a hello link local registration protocol data unit (LRPDU) message. a command module for receiving a command from the application to maintain the requesting database in the memory of the local node despite the disconnection code, and after successful exchange of the hello message, the adjacent node a receiving module for receiving complete-list LRPDU messages from the registrant database of the registrant database, the complete-list LRPDU messages containing record headers of all records of the registrant database; a record comparison module for comparing the record headers from the Complete List LRPDU message with the record headers in the applicant database for resynchronization.

任意選択で、上記のローカルノードのいずれかにおいて、ローカルノードの他の実装は、上記の態様のいずれかの方法を実行するためのモジュールを更に含むことを含む。 Optionally, in any of the local nodes above, other implementations of the local node further comprise modules for performing the method of any of the aspects above.

明確性の目的で、上記の実施形態のいずれか1つは、本開示の範囲内の新たな実施形態を作成するために、他の上記の実施形態のいずれか1つ以上と組み合わされてもよい。 For purposes of clarity, any one of the above embodiments may be combined with any one or more of the other above embodiments to create new embodiments within the scope of the present disclosure. good.

これら及び他の特徴は、添付の図面及び特許請求の範囲に関して行われる以下の詳細な説明から、より明確に理解される。 These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims.

この開示のより完全な理解のために、添付の図面及び詳細な説明に関連して、ここで以下の簡単な説明に参照が行われ、同様の参照符号は同様の部分を表す。
データベース同期ネットワークの例示的なネイティブシステム実装の概略図である。 データベース同期ネットワークの例示的なプロキシシステム実装の概略図である。 データベース同期のための例示的なデータベースシステムの概略図である。 データベース同期を管理する例示的な方法のプロトコル図である。 ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの例示的な符号化を示す。 レコードLRPDUメッセージの例示的な符号化を示す。 部分リストLRPDUメッセージの例示的な符号化を示す。 完全リストLRPDUメッセージの例示的な符号化を示す。 データベース対を確立する例示的な方法のフローチャートである。 データベース対の同期を管理する例示的な方法のフローチャートである。 接続中断にもかかわらずデータベース同期を維持する例示的な方法のフローチャートである。 データベース同期を管理するための例示的なネットワークエレメントの概略図である。 データベース対を確立するための例示的なデバイスの概略図である。 データベース対の同期を管理するための例示的なデバイスの概略図である。 接続中断にもかかわらずデータベース同期を維持するための例示的なデバイスの概略図である。
For a more complete understanding of this disclosure, reference is now made to the following brief description, like reference numerals referring to like parts, in conjunction with the accompanying drawings and detailed description.
1 is a schematic diagram of an exemplary native system implementation of a database synchronization network; FIG. 1 is a schematic diagram of an exemplary proxy system implementation of a database synchronization network; FIG. 1 is a schematic diagram of an exemplary database system for database synchronization; FIG. FIG. 4 is a protocol diagram of an exemplary method of managing database synchronization; 4 shows an exemplary encoding of a Hello Link Local Registration Protocol Data Unit (LRPDU) message. 4 shows an exemplary encoding of a record LRPDU message; 4 shows an exemplary encoding of a partial list LRPDU message. 4 shows an exemplary encoding of a Complete List LRPDU message. 4 is a flow chart of an exemplary method of establishing a database pair; 4 is a flowchart of an exemplary method of managing synchronization of database pairs; 4 is a flowchart of an exemplary method for maintaining database synchronization despite connection interruptions; 1 is a schematic diagram of exemplary network elements for managing database synchronization; FIG. 1 is a schematic diagram of an exemplary device for establishing a database pair; FIG. 1 is a schematic diagram of an exemplary device for managing synchronization of database pairs; FIG. 1 is a schematic diagram of an exemplary device for maintaining database synchronization despite connection interruptions; FIG.

最初に、1つ以上の実施形態の例示的な実装が以下に提供されるが、開示のシステム及び/又は方法は、現在既知であるか存在するかを問わず、いずれかの数の技術を使用して実装されてもよいことが理解されるべきである。当該開示は、ここに図示及び記載される例示的な設計及び実装を含む、以下に示す例示的な実装、図面及び技術に決して限定されるべきではなく、添付の特許請求の範囲の範囲内で、これらの均等物の全範囲と共に修正されてもよい。 Initially, exemplary implementations of one or more embodiments are provided below, although the disclosed systems and/or methods may employ any number of techniques, whether currently known or in existence. It should be understood that it may be implemented using In no way should the disclosure be limited to the example implementations, drawings and techniques shown below, including the example designs and implementations shown and described herein, within the scope of the appended claims. , may be modified along with their full range of equivalents.

データベース同期をサポートするために、標準化された通信プロトコルが使用されてもよい。このような通信プロトコルは、標準化された方法でデータベースの一貫性を維持するように構成できる。例えば、リンクローカル登録プロトコル(Link-local Registration Protocol, LRP)は、登録側データベースをポイント・ツー・ポイント・リンクの一端から他端に複製し、そのデータベースの一部に変更を複製するためのプロトコル、手順及び管理オブジェクトを指定する標準である。LRPは、1メガバイトのオーダーのデータベースに対して最適化されてもよい。LRPデータベース同期(LRP Database Synchronization, LRP-DS)は、データベースの間の通信を設定するために使用できる。LRP-DSは、インターミディエイトシステム・ツー・インターミディエイト・システム(Intermediate System to Intermediate System, IS-IS)プロトコルと同様に、ノード隣接を確立するためにハローメッセージを使用する。次いで、LRPデータベーストランスポート(LRP Database Transport, LRP-DT)は、IS-ISにより搬送されたリンク状態アドバタイズメント(Link State Advertisement, LSA)メッセージと同様に、LRP-DSにより提供されたレコードメッセージで搬送されたデータを転送するために使用できる。したがって、LRP-DSは、関係するアプリケーションの代わりにデータベース同期を管理する。 A standardized communication protocol may 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 protocol for replicating a registration database from one end of a point-to-point link to the other, and replicating changes to portions of that database. , procedures and management objects. LRP may be optimized for databases on the order of one megabyte. LRP Database Synchronization (LRP-DS) can be used to set up communication between databases. LRP-DS uses hello messages to establish node adjacencies, similar to the Intermediate System to Intermediate System (IS-IS) protocol. The LRP Database Transport (LRP-DT) then uses record messages provided by LRP-DS as well as Link State Advertisement (LSA) messages carried by IS-IS. Can be used to transfer conveyed data. Therefore, LRP-DS manages database synchronization on behalf of participating applications.

ここに開示されるのは、LRP-DSの機能を改良するためのメカニズムである。例えば、LRP-DSは、同期のためにデータベース対を自動的に設定するように改良できる。データベース対は、第1のノードの申請側データベースと、第2のノードの登録側データベースとを含む。このようなノードはまた、説明の明確性のため、それぞれローカルノード及び隣接ノードと呼ばれてもよい。申請側データベースに対して更新が行われたとき、LRP-DSプロトコルは、同期を維持するために、このような更新を登録側データベースに通信する。一方向通信については、ローカルノードは申請側データベースを含み、隣接ノードは登録側データベースを含む。双方向通信については、ローカルノードは、隣接ノードの登録側データベースとの同期のための申請側データベースを含み、隣接ノードは、ローカルノードの登録側データベースとの同期のための申請側データベースを含む。いずれの場合も、データベース対は、ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの交換のときに自動的に設定できる。ハローLRPDUメッセージは、対応するアプリケーションのアプリケーション識別子(AppId)と、ローカルノードを識別するマイシャーシ識別子(ID)、ローカルノードのターゲットポートを識別するマイポートID、隣接ノードを識別する隣接シャーシID、及び隣接ノードのターゲットポートを識別する隣接ポートIDに関して示されるターゲットリンクとを含む。ハローメッセージの交換のとき、ローカルノード及び隣接ノードは、識別されたアプリケーションのための申請側及び登録側データベース対を自動的に作成し、ターゲットリンクに基づいてこのようなデータベース対を互いに関連付けることができる。 Disclosed herein are mechanisms for improving the function of LRP-DS. For example, LRP-DS can be enhanced to automatically configure database pairs for synchronization. A database pair includes an applicant database of a first node and a registration database of a second node. Such nodes may also be referred to as local and neighboring nodes, respectively, for clarity of description. When updates are made to the applicant database, the LRP-DS protocol communicates such updates to the registrant database to maintain synchronization. For one-way communication, the local node contains the applicant database and the neighboring node contains the registration database. For two-way communication, the local node includes an applicant database for synchronization with a neighboring node's registration database, and the adjacent node includes an applicant database for synchronization with the local node's registration database. In either case, the database pair can be set up automatically during the exchange of Hello Link Local Registration Protocol Data Unit (LRPDU) messages. The Hello LRPDU message contains the Application Identifier (AppId) of the corresponding application, the My Chassis Identifier (ID) that identifies the local node, the My Port ID that identifies the target port of the local node, the Neighbor Chassis ID that identifies the adjacent node, and and a target link indicated on the adjacent port ID that identifies the target port of the adjacent node. Upon exchanging hello messages, the local node and the neighboring node can automatically create applicant and registrant database pairs for the identified application and associate such database pairs with each other based on the target link. can.

ポータルと呼ばれるコンポーネントで動作するLRP-DSはまた、1つ以上の更新の後にデータベースが同期したとき、アプリケーションに自動的に通知するために使用できる。例えば、申請側データベースで更新が行われたとき、更新されたデータベースレコードと、このような更新されたレコードのシーケンス番号(例えば、バージョン番号)とを示すために、レコードLRPDUメッセージが登録側データベースに送信される。登録側データベースは、更新されたレコードの認識を承認する部分リストLRPDUメッセージで応答し、これはLRP-DTを介して通信できる。部分リストLRPDUメッセージが受信されたとき、ポータルは、申請側データベース内の指示されたレコードを承認済みとしてマーキングさせる。複数のレコードLRPDU及び部分リストLRPDUが交換できる。申請側データベース内の全てのレコードが承認済みとしてマーキングされたとき、ポータルは、データベースが同期しているという指示をアプリケーションに送信できる。 LRP-DS, which operates on a component called a portal, can also be used to automatically notify applications when databases are synchronized after one or more updates. For example, when an update is made in the applicant database, a record LRPDU message is sent to the subscriber database to indicate the database record that was updated and the sequence number (e.g., version number) of such updated record. sent. The registrant database responds with a Partial List LRPDU message acknowledging acknowledgment of the updated record, which can be communicated via the LRP-DT. When a Partial List LRPDU message is received, the Portal causes the indicated record in the applicant database to be marked as approved. Multiple record LRPDUs and partial list LRPDUs can be exchanged. When all records in the requesting database have been marked as approved, the portal can send an indication to the application that the database is in sync.

他の例では、LRP-DSは、接続中断にもかかわらずデータベースの間の同期を維持するために使用できる。ハローLRPDUメッセージは、周期的に交換されてもよい。ハローLRPDUメッセージ交換が失敗したとき、ポータルはアプリケーションに通知できる。申請側は、データベースレコードを新たな登録側データベースに再アップロードすることにより、ペアリングを削除して再接続のときに新たなデータベース対を作成するように選択できる。申請側はまた、現在のデータベース対を維持することを選択できる。データベースペアリングが維持されるべきであるという指示をポータルが受信したとき、ポータルは更なるレコードLRPDUメッセージを中断する。ハローLRPDUメッセージ交換を再確立したとき、登録側は、完全リストLRPDUメッセージを申請側に送信する。完全リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。申請側データベースは、いずれかのレコード不一致を決定するために、完全リストLRPDUメッセージ内のレコードヘッダを、申請側データベースに記憶されたレコードヘッダと比較できる。これは、接続喪失のためレコードLRPDUメッセージが失われたときに生じてもよい。次いで、申請側データベースは、完全リストLRPDUメッセージに含まれるレコード状態以降に行われたいずれかのレコード更新を含むレコードLRPDUメッセージを送信できる。典型的には、結果は、迅速な完全リストLRPDU送信のない場合よりも少ないレコードLRPDUの送信である。ポータルはまた、データベースが同期したときにアプリケーションに通知できる。これら及び他の例示的な実施形態について、以下の図面に関してより詳細に説明する。 In another example, LRP-DS can be used to maintain synchronization between databases despite connection interruptions. Hello LRPDU messages may be exchanged periodically. The portal can notify the application when the hello LRPDU message exchange fails. The applicant can choose to delete the pairing and create a new database pair upon reconnection by re-uploading the database records to the new enroller database. Applicants may also choose to maintain their current database pairs. When the Portal receives an indication that the database pairing should be maintained, the Portal discontinues further Record LRPDU messages. Upon re-establishing the Hello LRPDU message exchange, the registrant sends a Complete List LRPDU message to the applicant. The Complete List LRPDU message contains record headers for all records in the subscriber database. The applicant database can compare the record headers in the Complete List LRPDU message with the record headers stored in the applicant database to determine any record discrepancies. This may occur when record LRPDU messages are lost due to connection loss. The requesting database can then send a record LRPDU message containing any record updates made since the record state contained in the complete list LRPDU message. Typically, the result is transmission of fewer record LRPDUs than without rapid complete list LRPDU transmission. The portal can also notify the application when the database is synchronized. These and other exemplary embodiments are described in more detail with respect to the following drawings.

図1は、データベース同期ネットワーク100の例示的なネイティブシステムの概略図である。データベース同期ネットワーク100は、インターネットプロトコル(Internet Protocol, IP)ネットワーク171により結合されたネイティブシステム110及びネイティブシステム130を含む。ネイティブシステム110及びネイティブシステム130は、同期のために、それぞれ1つ以上のデータベース120及び122を含む。説明の明確性のため、ネイティブシステム110又は130は、ここでは、第1のシステムで発生する送信元動作に関して説明するときにはローカルと呼ばれ、第2のシステムで発生する宛先動作に関して説明するときには隣接と呼ばれる。したがって、ネイティブシステム110及び130は、コンテキストに依存して、ローカル、隣接又はこれらの双方になり得る。また、ここで使用されるローカル及び隣接という用語は相対的なものであり、第1のノードと第2のノードとの間を明確に区別するために使用され、異なる観点から同じネットワークを説明するときに交換可能に使用されてもよい点に留意すべきである。 FIG. 1 is a schematic diagram of an exemplary native system of database synchronization network 100 . Database synchronization network 100 includes native system 110 and native system 130 coupled by Internet Protocol (IP) network 171 . Native system 110 and native system 130 include one or more databases 120 and 122, respectively, for synchronization. For clarity of explanation, a native system 110 or 130 is referred to herein as local when discussing source operations occurring on a first system, and adjacent when discussing destination operations occurring on a second system. called. Therefore, native systems 110 and 130 can be local, adjacent, or both, depending on the context. Also, the terms local and adjacent as used herein are relative and are used to clearly distinguish between a first node and a second node, describing the same network from different perspectives. It should be noted that the terms may sometimes be used interchangeably.

ネイティブシステム110は、アプリケーション111と、ポータル113と、ターゲットポート141と、データベース120とを含む計算コンポーネントである。アプリケーション111は、少なくともネイティブシステム110及び/又はプロキシシステムとネイティブシステム130及び/又はプロキシシステムとの間で情報を配信するように動作可能なコンピュータプログラムである。プロキシシステムについて、以下の図2に関して説明する。例えば、アプリケーション111は、クラウド記憶システムと同期した保存ファイルを有するユーザ操作可能なプログラムを含んでもよい。アプリケーション111は、データをアプリケーション131にアップロードし、及び/又はアプリケーション131からデータをダウンロードする。簡潔性の目的で、2つのアプリケーション111及び131のみが示されているが、アプリケーション111は、いずれかの数の他のアプリケーションと同期できる。 Native system 110 is a computational component that includes application 111 , portal 113 , target port 141 and database 120 . Application 111 is a computer program operable to distribute information at least between native system 110 and/or proxy system and native system 130 and/or proxy system. The proxy system is described with respect to FIG. 2 below. For example, application 111 may include a user-operable program that has saved files synchronized with a cloud storage system. Application 111 uploads data to and/or downloads data from application 131 . For simplicity, only two applications 111 and 131 are shown, but application 111 can synchronize with any number of other applications.

ポータル113は、単一のアプリケーション111に関連するデータベース120及び申請側及び/又は登録側状態機械のインスタンスと共に、ポータルインタフェースのインスタンス化である。例えば、ポータル113は、アプリケーション111の代わりにLRP(例えば、LRP-DS及びLRP-DT)を動作させる。ポータル113は、アプリケーション111及び/又はデータベース120から通知を受信し、対応するLRP動作を実行し、応答通知をアプリケーション111及び/又はデータベース120に提供する。例えば、ポータル113は、LRPDUメッセージの通信を管理することによりLRP-DSを動作させる。ポータル113は、例えば、伝送制御プロトコル(Transmission Control Protocol ,TCP)接続170を介して、データベース120のレコードのようなデータを対応するポータル133と通信することによりLRP-DTを動作させる。いくつかの例では、ネイティブシステム110上のアプリケーション111は、ネイティブシステム110内の多くのターゲットポート141のそれぞれにおいて別々のポータル113及び対応するデータベース120を維持する。 A portal 113 is an instantiation of the portal interface along with instances of database 120 and applicant and/or subscriber state machines associated with a single application 111 . For example, portal 113 runs LRPs (eg, LRP-DS and LRP-DT) on behalf of application 111 . Portal 113 receives notifications from application 111 and/or database 120 , performs corresponding LRP operations, and provides response notifications to application 111 and/or database 120 . For example, portal 113 operates LRP-DS by managing the communication of LRPDU messages. Portals 113 operate LRP-DTs by communicating data, such as records in database 120 , with corresponding portals 133 , eg, via Transmission Control Protocol (TCP) connections 170 . In some examples, application 111 on native system 110 maintains a separate portal 113 and corresponding database 120 at each of many target ports 141 within native system 110 .

ネイティブシステム110はまた、ターゲットポート141上でリンク層ディスカバリプロトコル(Link Layer Discovery Protocol ,LLDP)161を動作させることができる。代替として、ネイティブシステム110は、LLDP161により生成されたものと同等のデータを含む、システム管理者により制御される情報のリポジトリを維持する。 Native system 110 can also run Link Layer Discovery Protocol (LLDP) 161 on target port 141 . Alternatively, native system 110 maintains a system administrator-controlled repository of information containing data equivalent to that generated by LLDP 161 .

データベース120は、アプリケーション111のための1つ以上のファイル記憶リポジトリを含む。データベース120内のファイルは、レコードとして記憶される。レコードは、ポータル113内で動作するLRPにより申請側から登録側に単一の単位として転送されるデータベース120のサブセットである。各レコードは、データと、データを識別するレコード番号と、シーケンス番号とを含む。シーケンス番号は、レコードの現在のバージョンを識別する。例えば、シーケンス番号は、レコードが更新された回数を示すカウンタとして実装されてもよい。データベース120は、申請側データベース、登録側データベース又はこれらの双方を含んでもよい。申請側は、アプリケーション111がポータル113に関して有することができる(登録側との)2つの役割のうち1つである。申請側は、LRPが隣接ポータル133内の登録側に複製するデータベース120を制御する。登録側は、アプリケーション111がポータル113に関して有することができる(申請側との)2つの役割のうち1つである。登録側は、隣接ポータル133においてLRPが申請側から複製するデータベース122のコピーを受信する。したがって、データベース120は、レコードをデータベース122にアップロードするための申請側データベース、データベース122からレコードをダウンロードするための登録側データベース、又はデータベース122とのレコードの双方向通信のための双方を含むことができる。 Database 120 contains one or more file storage repositories for applications 111 . Files in database 120 are stored as records. A record is a subset of the database 120 transferred as a single unit by the LRP operating within the portal 113 from the applicant to the registrant. Each record contains data, a record number identifying the data, and a sequence number. The sequence number identifies the current version of the record. For example, the sequence number may be implemented as a counter that indicates the number of times the record has been updated. Database 120 may include an applicant database, a registration database, or both. Applicant is one of two roles that application 111 can have with respect to portal 113 (with registrant). Applicants control the database 120 that the LRP replicates to registrants in neighboring portals 133 . A registrant is one of two roles that an application 111 can have with respect to a portal 113 (with an applicant). The registrant receives a copy of the database 122 that the LRP replicates from the applicant at a neighboring portal 133 . Thus, database 120 may include an applicant database for uploading records to database 122, a registrant database for downloading records from database 122, or both for bi-directional communication of records with database 122. can.

ターゲットポート141は、ネイティブシステム110上の通信ポートである。ポータル113及び関連する申請側及び登録側データベース120は、単一のターゲットポート141に関連付けられる。ターゲットポート141は、1つより多くのポータル113が異なるアプリケーション111にサービス提供する場合、このようなポータル113に関連付けられることができる。ターゲットポート141は、(例えば、他のシステム内の)1つ以上の他のターゲットポート151に接続するリンクへのアクセスを提供する。 Target port 141 is a communication port on native system 110 . Portal 113 and associated applicant and subscriber databases 120 are associated with a single target port 141 . A target port 141 can be associated with more than one portal 113 if such portal 113 serves different applications 111 . Target port 141 provides access to links that connect to one or more other target ports 151 (eg, in other systems).

ネイティブシステム130は、ネイティブシステム110と実質的に同様である。ネイティブシステム130は、ポータル133、アプリケーション131、データベース122及びターゲットポート151を含み、これらは、それぞれポータル113、アプリケーション111、データベース120及びターゲットポート141と実質的に同様でもよい。 Native system 130 is substantially similar to native system 110 . Native system 130 includes portal 133, application 131, database 122 and target port 151, which may be substantially similar to portal 113, application 111, database 120 and target port 141, respectively.

ネイティブシステム110及び130は、LLDP161を介してデータベース120及び122の対を設定するために、互いに発見する。LLDP161はリンク層プロトコルであり、米国電気電子技術者協会(Institute of Electrical and Electronics Engineers, IEEE)標準文書802.1ABにより記述されており、ネットワークデバイスによりネットワーク上でこれらのアイデンティティ、能力及び隣接をアドバタイズするために使用される。特に、ネイティブシステム110及び130は、LLDP161を使用することにより、ターゲットポート141及び151を介して、これらのアプリケーション111及び131、LRP-DS及びLRPDT能力を互いにアドバタイズできる。LRPDUメッセージを搬送するときにLRP-DTにより使用されるアドレスは、これらのLRPDUメッセージを搬送するためにエッジ制御プロトコル(Edge Control Protocol, ECP)160又は伝送制御プロトコル(TCP)のいずれかを使用するプリファレンスと共に、LLDP161を通じて決定できる。ECP160は、IEEE標準802.1Q-2014により定義されたネットワークプロトコルである。TCP170は、インターネット技術特別調査委員会(Internet Engineering Task Force, IETF)文書のリクエストフォーコメント(Request For Comment, RFC)793により定義される。どちらも、LRPDUメッセージを搬送するために使用できる。ECP160が使用される場合、ECPパケットはターゲットポート141及び151を通過する。TCP170が使用される場合、LRPDUパケットは、ターゲットポート141、151、又は2つのネイティブシステム110及び130上のいずれかの他のポートを通過できる。 Native systems 110 and 130 discover each other through LLDP 161 to set up database 120 and 122 pairs. LLDP161 is a link layer protocol, described by the Institute of Electrical and Electronics Engineers (IEEE) standard document 802.1AB, for advertising their identities, capabilities and adjacencies on the network by network devices. used for In particular, native systems 110 and 130 can advertise their LRP-DS and LRPDT capabilities to each other over target ports 141 and 151 using LLDP 161 . The address used by the LRP-DT when carrying LRPDU messages uses either Edge Control Protocol (ECP) 160 or Transmission Control Protocol (TCP) to carry these LRPDU messages. Can be determined through LLDP161, along with preferences. ECP160 is a network protocol defined by IEEE standard 802.1Q-2014. TCP 170 is defined by Internet Engineering Task Force (IETF) document Request For Comment (RFC) 793. Both can be used to carry LRPDU messages. When ECP 160 is used, ECP packets pass through target ports 141 and 151 . When TCP 170 is used, LRPDU packets can pass through target ports 141, 151, or any other port on the two native systems 110 and 130.

LRPDUメッセージは、データベース120及び/又は122におけるレコード更新、承認及びデータベース同期に関する他の管理情報を示す制御メッセージとして機能する。ここで説明するLRPDUメッセージは、ハローLRPDUメッセージと、レコードLRPDUメッセージと、部分リストLRPDUメッセージと、完全リストLRPDUメッセージと、要求完全リストLRPDUメッセージとを含む。しかし、データベース120及び122の同期を実施するために、他のLRPDUメッセージが必要に応じて使用できる。LRPDUメッセージを使用して、ポータル113及び133は、データベース120及び122を同期させるためにデータベース120及び122のレコードを交換できる。例えば、データベース120及び122のレコードLRPDUは、TCP接続170を介して交換できる。TCP接続170は、データを交換するために使用されるポイント・ツー・ポイント通信セッションである。TCP接続170は、例に依存して、ターゲットポート141及び151の間又は他のポートの間でルーティングできる。TCP接続170は1つ以上のIPネットワーク171を横断でき、これらはポイント・ツー・ポイント通信をサポートするオープンシステム相互接続(Open Systems Interconnection, OSI)モデルのレイヤ3ネットワークである。以下に図面に関して説明するように、上記のコンポーネントは、部分的にターゲットポート141及び151を介して、アプリケーション111及び/又は131の代わりにデータベース120及び122の同期を管理するために、ポータル113及び/又は133により使用できる。 LRPDU messages serve as control messages that indicate record updates in databases 120 and/or 122, acknowledgments, and other administrative information regarding database synchronization. The LRPDU messages described herein include hello LRPDU messages, record LRPDU messages, partial list LRPDU messages, complete list LRPDU messages, and request complete list LRPDU messages. However, other LRPDU messages can be used as needed to effect synchronization of databases 120 and 122. FIG. Using LRPDU messages, portals 113 and 133 can exchange records in databases 120 and 122 to keep databases 120 and 122 in sync. For example, database 120 and 122 record LRPDUs can be exchanged over TCP connection 170 . A TCP connection 170 is a point-to-point communication session used to exchange data. TCP connection 170 can be routed between target ports 141 and 151 or between other ports depending on the example. A TCP connection 170 can traverse one or more IP networks 171, which are Layer 3 networks of the Open Systems Interconnection (OSI) model that support point-to-point communications. As described below with respect to the figures, the above components are partly responsible for managing the synchronization of databases 120 and 122 on behalf of applications 111 and/or 131 over target ports 141 and 151, portal 113 and / or can be used by 133.

図2は、データベース同期ネットワーク200の例示的なプロキシシステムの実装の概略図である。データベース同期ネットワーク200は、プロキシ210、プロキシ230、スレーブ240及びスレーブ250を含む。データベース同期ネットワーク200は、データベース同期ネットワーク100と同様であるが、ターゲットポート241及び251は、ネイティブシステムからスレーブ240及び250にそれぞれ動かされている。ここで使用されるプロキシ210及び/又は230は、アプリケーション211を少なくとも含む計算コンポーネントであり、これは、アプリケーション111と実質的に同様である。例えば、プロキシ210は、プロキシ210とネイティブシステム及び/又はプロキシシステム230との間で情報を配信するように動作可能なアプリケーション211を少なくとも含む。プロキシ210はまた、ポータル213及び/又はデータベース220を含んでもよく、これらは、それぞれポータル113及びデータベース120と実質的に同様である。 FIG. 2 is a schematic diagram of an exemplary proxy system implementation of database synchronization network 200 . Database synchronization network 200 includes proxy 210 , proxy 230 , slave 240 and slave 250 . Database synchronization network 200 is similar to database synchronization network 100, but target ports 241 and 251 have been moved from the native system to slaves 240 and 250, respectively. Proxies 210 and/or 230, as used herein, are computational components that include at least application 211, which is substantially similar to application 111; For example, proxy 210 includes at least application 211 operable to distribute information between proxy 210 and native and/or proxy system 230 . Proxy 210 may also include portal 213 and/or database 220, which are substantially similar to portal 113 and database 120, respectively.

スレーブ240は、ルータ、スイッチ等のような通信コンポーネントとすることができ、或いは、カメラ、機械式アクチュエータ又はパーソナルコンピュータのようなエンドステーションとすることができる。スレーブ240は、ネットワーク接続によりプロキシ210に結合される。スレーブは、少なくとも1つのターゲットポート241を含み、これは、ターゲットポート141と実質的に同様である。通信コンポーネントは、複数のターゲットポート241を含む。プロキシ210及びスレーブ240は、ネイティブシステム110と実質的に同様の方式で一緒に機能する。プロキシ210の代わりにターゲットポート241をスレーブ240に配置することにより、アプリケーション211、ポータル213及び/又はデータベース220は、スレーブ240とは別のネットワークにあってもよいデバイス(プロキシ210)にオフロードできる。これは、実質的に同じ機能を提供しつつ、実装の柔軟性を提供する。 Slaves 240 can be communication components such as routers, switches, etc., or can be end stations such as cameras, mechanical actuators, or personal computers. Slave 240 is coupled to proxy 210 by a network connection. A slave includes at least one target port 241 , which is substantially similar to target port 141 . The communications component includes multiple target ports 241 . Proxy 210 and slave 240 work together in a manner substantially similar to native system 110 . By placing target port 241 on slave 240 instead of proxy 210, application 211, portal 213 and/or database 220 can be offloaded to a device (proxy 210) that may be on a different network than slave 240. . This provides implementation flexibility while providing substantially the same functionality.

プロキシ230は、プロキシ210と実質的に同様であり、ポータル233、アプリケーション231及びデータベース222を含み、これらは、それぞれポータル213、アプリケーション211及びデータベース220と実質的に同様でもよい。スレーブ250は、プロキシ230に結合され、ターゲットポート251を含み、これは、ターゲットポート241と実質的に同様でもよい。スレーブ240及び250は、LLDP161と同様にターゲットポート241及び251の間でLLDPメッセージを交換するためにLLDP261を使用する。スレーブ250及び240は、このようなメッセージをそれぞれポータル233及び213に転送できる。LLDPメッセージからのレコード情報は、IPネットワーク271にわたる同期のためにデータベース220及び/又は222のレコードの通信を設定するために使用できる。IPネットワーク271は、IPネットワーク171と実質的に同様でもよい。このようなレコードはTCP接続270を介して通信でき、これは、TCP接続170と実質的に同様である。 Proxy 230 is substantially similar to proxy 210 and includes portal 233, application 231 and database 222, which may be substantially similar to portal 213, application 211 and database 220 respectively. Slave 250 is coupled to proxy 230 and includes target port 251 , which may be substantially similar to target port 241 . Slaves 240 and 250 use LLDP261 to exchange LLDP messages between target ports 241 and 251 as well as LLDP161. Slaves 250 and 240 can forward such messages to portals 233 and 213, respectively. Record information from LLDP messages can be used to set up communication of records in database 220 and/or 222 for synchronization across IP network 271 . IP network 271 may be substantially similar to IP network 171 . Such records can be communicated over TCP connection 270 , which is substantially similar to TCP connection 170 .

データベース同期ネットワーク100及び200の様々な組み合わせもまた、この開示の範囲内で使用されてもよい点に留意すべきである。例えば、ネイティブシステム110は、データベース120をプロキシ230及びスレーブ250と同期させるために使用できる。さらに、ネイティブシステム130は、データベース122をプロキシ210及びスレーブ240と同期させるために使用できる。様々な中継システム(例えば、ルータ及び/又はブリッジ)が、ネイティブシステム、プロキシ及び/又はスレーブの間の通信をルーティングするために使用できる。このようなコンポーネントは、以下に説明するように、様々な能力を含んでもよい。いずれかの通信デバイスにおいて、アプリケーション111、131、211及び/又は231は、同じシステムに属する異なるターゲットポート141、151、241及び251上で、データベース120、122、220及び222において申請側と登録側との間で情報を交換できる。 It should be noted that various combinations of database synchronization networks 100 and 200 may also be used within the scope of this disclosure. For example, native system 110 can be used to synchronize database 120 with proxy 230 and slave 250 . Additionally, native system 130 can be used to synchronize database 122 with proxy 210 and slave 240 . Various relay systems (eg, routers and/or bridges) can be used to route communications between native systems, proxies and/or slaves. Such components may include various capabilities, as described below. In any communication device, applications 111, 131, 211 and/or 231 can be applied and registered in databases 120, 122, 220 and 222 on different target ports 141, 151, 241 and 251 belonging to the same system. can exchange information with

図3は、データベース同期のための例示的なデータベースシステム300の概略図である。データベースシステム300は、ネイティブシステム110、ネイティブシステム130、プロキシ210及び/又はプロキシ230を実装するために使用されてもよい。データベースシステム300は、アプリケーション311を含み、これは、アプリケーション111、131、211及び/又は231と実質的に同様である。具体的には、アプリケーション311は、隣接データベースのようなリモートシステムとの同期のためのデータを使用するプログラムである。アプリケーションは、ポータル313をインスタンス化し、これは、ポータル113、133、213及び/又は233と実質的に同様である。ポータル313は、アプリケーション311の代わりにLRP(例えば、LRP-DS及びLRP-DT)を動作させる。したがって、ポータル313は、他のプロセスの中でも、同期目的のためにLRPDUメッセージ及びレコードの通信を管理する。ポータル313は、アプリケーション311及びデータベース320と相互作用し、これらは、データベース120、122、220及び/又は222と実質的に同様である。データベース320は、申請側321及び/又は登録側325を含んでもよい。 FIG. 3 is a schematic diagram of an exemplary database system 300 for database synchronization. Database system 300 may be used to implement native system 110 , native system 130 , proxy 210 and/or proxy 230 . Database system 300 includes application 311 , which is substantially similar to applications 111 , 131 , 211 and/or 231 . Specifically, application 311 is a program that uses data for synchronization with remote systems, such as neighboring databases. The application instantiates portal 313, which is substantially similar to portals 113, 133, 213 and/or 233. Portal 313 runs LRPs (eg, LRP-DS and LRP-DT) on behalf of application 311 . Portal 313 thus manages, among other processes, the communication of LRPDU messages and records for synchronization purposes. Portal 313 interacts with application 311 and database 320 , which are substantially similar to databases 120 , 122 , 220 and/or 222 . Database 320 may include applicants 321 and/or registrants 325 .

申請側321は、ローカルに記憶されたデータのコピーを隣接データベースの登録側にアップロードするように構成された状態機械及び対応するメモリ空間である。登録側325は、隣接データベースにおいて申請側からリモートに記憶されたデータのコピーを受信するように構成された状態機械及び対応するメモリ空間である。したがって、データベース320は、同期のためにデータをアップロードするための申請側321、同期のためにデータをダウンロードするための登録側325、又は双方向同期のためのこれらの双方を含むことができる。申請側321及び登録側325は、制御メッセージ及びデータがこれらの意図した宛先に到達することを確保するために、ポータル313にそれぞれ関連付けられる。ポータル313は、メッセージがこれらの意図したポータル(例えば、ポータル313)で受信されることを確保するために、ターゲットポートに更に関連付けられる。 The applicant side 321 is a state machine and corresponding memory space configured to upload a locally stored copy of the data to the registration side of the adjacent database. The registrant 325 is a state machine and corresponding memory space configured to receive a copy of remotely stored data from the applicant in a neighboring database. Thus, database 320 can include applicants 321 for uploading data for synchronization, registrants 325 for downloading data for synchronization, or both for two-way synchronization. Applicant 321 and registrant 325 are each associated with portal 313 to ensure that control messages and data reach their intended destinations. Portals 313 are further associated with target ports to ensure that messages are received at their intended portal (eg, portal 313).

データベース320内のデータは、レコードに記憶される。レコードは、同期のために通信できるデータの最小単位である。レコードサイズは、アプリケーション311により構成できる。より小さいレコードは複雑さを作るが、より大きいレコードは、レコードの一部が更新されたときにより多くのデータの転送を生じる。 Data in database 320 is stored in records. A record is the smallest unit of data that can be communicated for synchronization. The record size is configurable by application 311 . Smaller records create complexity, but larger records result in more data transfer when part of the record is updated.

申請側321は、ローカルレコード323及びローカルレコードヘッダ324を含む。ローカルレコード323は、アプリケーション311によりローカルに使用されるデータを含むレコードである。レコードヘッダは、対応するレコードに関する状態情報の事前定義のグループである。例えば、ローカルレコードヘッダ324は、対応するローカルレコード323のレコード番号、シーケンス番号及び/又はチェックサムを含む。レコード番号は、対応するレコードを示す。シーケンス番号は、バージョン情報を含む。例えば、シーケンス番号は、対応するレコードが修正された回数を示すカウンタを含んでもよい。チェックサムは、エラー検査情報であり、送信のための対応するデータのセットにおける正しい数の数字の和を表す数字を含んでもよい。例えば、チェックサムはレコード番号及びシーケンス番号における正しい数の数字の和を示してもよい。したがって、ローカルレコード323が更新されたとき、対応するローカルレコードヘッダ324は、更新されたレコード及び更新のバージョン(例えば、シーケンス番号)を示すためにシグナリングできる。 Requester 321 includes local record 323 and local record header 324 . Local records 323 are records containing data used locally by application 311 . A record header is a predefined group of state information about the corresponding record. For example, local record header 324 includes the record number, sequence number and/or checksum of corresponding local record 323 . The record number indicates the corresponding record. The sequence number contains version information. For example, a sequence number may include a counter that indicates the number of times the corresponding record has been modified. A checksum is error checking information and may include a number representing the sum of the correct number of digits in the corresponding set of data for transmission. For example, the checksum may indicate the sum of the correct number of digits in the record number and sequence number. Thus, when a local record 323 is updated, the corresponding local record header 324 can be signaled to indicate the updated record and the version (eg, sequence number) of the update.

登録側325は、隣接レコード326及び隣接レコードヘッダ327を含む。隣接レコード326及び隣接レコードヘッダ327は、それぞれローカルレコード323及びローカルレコードヘッダ324と同様であるが、隣接ノード/システムのアプリケーションにより使用されるデータに関する。 Registration side 325 includes adjacency record 326 and adjacency record header 327 . Adjacent record 326 and adjacent record header 327 are similar to local record 323 and local record header 324, respectively, but relate to data used by applications in adjacent nodes/systems.

したがって、ローカルデータベース320は、隣接データベース内の登録側データベースへの送信のためのローカルレコード323を記憶するための申請側321データベースを含むことができる。ローカルデータベース320はまた、隣接データベース内の申請側データベースから隣接レコード326を受信するための登録側325データベースを含むことができる。このレコードの転送は、LRPDUメッセージを使用することにより達成できる。例えば、ローカルレコード323が修正されたとき、レコードLRPDUメッセージがポータル313から送信できる。レコードLRPDUメッセージは、更新されたローカルレコード323及び更新の現在のシーケンス番号を隣接データベースの登録側に通知するために、対応するローカルレコードヘッダ324を含む。ポータル313は、隣接から、ローカルレコードへの更新の認識を承認する応答の部分レコードリストを受信できる。ポータル313はまた、更新されたローカルレコード323を転送するために、隣接ノードのポータルとのデータ転送を設定できる。同様に、隣接の申請側は、隣接レコード326への変更を示すために、隣接ポータルを介して、レコードLRPDUメッセージをポータル313に送信できる。隣接からのレコードLRPDUメッセージは、更新された隣接レコードヘッダ327を含む。次いで、登録側325は、隣接データベースにおける更新の認識を示すために、ポータル313を介して、更新された隣接レコードヘッダ327を含む部分リストLRPDUメッセージで応答できる。ポータル313はまた、隣接から登録側325への更新された隣接レコード326のデータ転送を管理できる。同期のために申請側321と登録側325との間でレコード及びレコードヘッダを交換するためのこれらの及び他のメッセージング方式について、以下の図面に関して説明する。
Thus, the local database 320 can include an applicant 321 database for storing local records 323 for transmission to a registrant database in a neighboring database. The local database 320 can also include a registrant 325 database for receiving adjacency records 326 from applicant databases in the adjacency database. Transfer of this record can be accomplished using LRPDU messages. For example, a record LRPDU message can be sent from portal 313 when local record 323 is modified. The record LRPDU message includes a corresponding local record header 324 to notify the neighbor database registrant of the updated local record 323 and the current sequence number of the update. Portal 313 can receive partial record lists in response from neighbors acknowledging the recognition of updates to local records. Portals 313 can also set up data transfers with portals of neighboring nodes to forward updated local records 323 . Similarly, a neighbor applicant can send a record LRPDU message to portal 313 via the neighbor portal to indicate changes to neighbor records 326 . Record LRPDU messages from neighbors include updated neighbor record headers 327 . The registrant 325 can then respond via the portal 313 with a partial list LRPDU message containing the updated neighbor record header 327 to indicate awareness of the update in the neighbor database. Portal 313 can also manage data transfer of updated neighbor records 326 from neighbors to registrants 325 . These and other messaging schemes for exchanging records and record headers between applicants 321 and registrants 325 for synchronization are described with respect to the following figures.

図4は、データベース同期を管理する例示的な方法400のプロトコル図である。方法400は、ネイティブシステム110及び/又は130、スレーブ240及び/又は250と共にプロキシ210及び/又は230、及び/又はデータベースシステム300により実装されてもよい。方法400は、申請側及び登録側を含むデータベース対を作成して維持するメカニズムを提供する。データベース対の管理は、申請側データベースと登録側データベースとの間の同期を維持することを含む。方法400は、アプリケーション、ローカルノードで申請側データベースを制御するローカルポータル、及び隣接ノードで登録側データベースを制御する隣接ポータルにより実装される。 FIG. 4 is a protocol diagram of an exemplary method 400 for managing database synchronization. Method 400 may be implemented by native systems 110 and/or 130, proxies 210 and/or 230 with slaves 240 and/or 250, and/or database system 300. Method 400 provides a mechanism for creating and maintaining database pairs containing applicants and registrants. Database pair management includes maintaining synchronization between the applicant database and the enrollee database. The method 400 is implemented by an application, a local portal controlling the applicant database at the local node, and a neighboring portal controlling the registering database at the neighboring node.

いくつかの例では、ローカルポータル及び隣接ポータルは、アプリケーションに関する隣接ノードのポート及びアドレスで事前構成される。他の例では、ローカルポータル及び隣接ポータルは、他の発見プロトコルを介してアプリケーションに関する隣接ノードのポート及びアドレスを発見する。いずれの場合も、ローカルポータルは、ハローLRPDUメッセージ401を隣接ポータルに転送し、隣接ポータルは、ハローLRPDUメッセージ403をローカルポータルに転送する。これはまた、ハローLRPDUメッセージの交換とも呼ばれてもよい。ハローLRPDUメッセージ401及び403は、アプリケーション識別子(AppId)を含み、ローカルノードのターゲットポートと隣接ノードのターゲットポートとの間のターゲットリンクを識別する。AppIdはアプリケーションを示し、したがって、送信者がデータを同期させることを望むアプリケーションに関連付けられることを示す。ハローLRPDUメッセージ401及び403内のターゲットリンクは、通信する試みが成功し、同期が開始できることを示す。 In some examples, the local portal and neighboring portals are pre-configured with ports and addresses of neighboring nodes for the application. In another example, the local portal and neighboring portals discover ports and addresses of neighboring nodes for applications via other discovery protocols. In either case, the local portal forwards the hello LRPDU message 401 to the neighboring portal, and the neighboring portal forwards the hello LRPDU message 403 to the local portal. This may also be referred to as exchanging Hello LRPDU messages. Hello LRPDU messages 401 and 403 contain an application identifier (AppId) and identify the target link between the local node's target port and the neighboring node's target port. The AppId indicates the application and thus is associated with the application with which the sender wishes to synchronize the data. The target link in hello LRPDU messages 401 and 403 indicates that the communication attempt was successful and synchronization can begin.

したがって、ローカルポータルがハローLRPDUメッセージ403を受信したとき、ローカルポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。次いで、ローカルポータルは、アプリケーションによる使用のためのデータベース対の一部として、ローカルノードのメモリにローカルデータベースを設定する。この例では、ローカルデータベースは申請側を含む。さらに、隣接ポータルがハローLRPDUメッセージ401を受信したとき、隣接ポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。次いで、隣接ポータルは、データベース対の一部として、隣接ノードのメモリに隣接データベースを設定する。この例では、隣接データベースは登録側を含む。ローカルポータル及び隣接ポータルは、それぞれデータベース対をターゲットリンクに関連付ける。次いで、ローカルポータルは、ターゲットリンクを介して、隣接登録側データベースとのローカル申請側データベースの同期を制御できる。隣接登録側データベースとのローカル申請側データベースの同期を制御することは、以下に説明するように、LRPDUメッセージにおいてターゲットリンクを介してレコード情報を隣接データベースに送信することを含む。LRPDUメッセージは、このようなメッセージが適切なポータルに到達することを確保するために、ターゲットリンクを介して常に転送されてもよい点に留意すべきである。 Therefore, when the Local Portal receives the Hello LRPDU message 403, the Local Portal determines that the AppId is associated with the application for performing database synchronization. The local portal then sets up the local database in the local node's memory as part of the database pair for use by the application. In this example, the local database contains applicants. Additionally, when the neighboring portal receives the Hello LRPDU message 401, the neighboring portal determines that the AppId is associated with the application for performing database synchronization. The neighbor portal then sets up the neighbor database in the neighbor node's memory as part of the database pair. In this example, the neighbor database contains registrations. Local portals and neighboring portals each associate a database pair with a target link. The local portal can then control the synchronization of the local applicant database with the neighboring registrant database via the target link. Controlling the synchronization of the local applicant database with the neighboring registrant database involves sending record information to the neighboring database over the target link in LRPDU messages, as described below. Note that LRPDU messages may always be forwarded over the target link to ensure that such messages reach the proper portal.

一旦ハローLRPDUメッセージ交換が発生してデータベースが設定されると、アプリケーションは、ローカルポータルを介して申請側データベースへのレコード変更405を行うことができる。レコード変更405は、対応するレコード内のデータの少なくとも1つのビットを更新することを含む。レコードが更新されたとき、変更を示すために、対応するレコードヘッダ内でシーケンス番号が変更される(例えば、インクリメントされる)。レコード変更405により影響を受けるレコードはまた、登録側が変更を認識していないことを示すために、申請側データベースにおいてフラグを使用することにより未承認としてマーキングできる。 Once the Hello LRPDU message exchange has occurred and the database has been set up, the application can make record changes 405 to the requesting database via the local portal. Record change 405 includes updating at least one bit of data in the corresponding record. When a record is updated, the sequence number is changed (eg, incremented) in the corresponding record header to indicate the change. Records affected by record change 405 can also be marked as unapproved by using a flag in the applicant database to indicate that the registrant is unaware of the change.

ローカルポータルは、隣接ポータルを介してレコードLRPDUメッセージ407を隣接ノードの登録側データベースに送信できる。レコードLRPDUメッセージ407は、申請側データベースに記憶されたレコードへの更新を示す。具体的には、レコードLRPDUメッセージ407は、レコード変更405により申請側データベース内で更新されるレコードのレコードヘッダを含む。このようなレコードヘッダは、それぞれの更新されるレコードのレコード番号及びシーケンス番号を含む。いくつかの例では、レコードLRPDUメッセージ407はまた、更新されるレコードも同様に含む。他の例では、更新されたレコードは、TCP及び/又はLRP-DTのような別の通信を介して及び/又は別のプロトコルを介して、申請側から登録側に転送される。承認を待機することなくレコードが更新されるので、ローカルポータルは、更なるレコードLRPDUメッセージを送信し続けてもよい点に留意すべきである。 The local portal can send a record LRPDU message 407 to the neighboring node's registrar database via the neighboring portal. A record LRPDU message 407 indicates an update to a record stored in the requesting database. Specifically, the record LRPDU message 407 contains the record header of the record updated in the requesting database by record change 405 . Such record headers contain the record number and sequence number of each updated record. In some examples, the record LRPDU message 407 also includes updated records as well. In other examples, updated records are transferred from the applicant to the registrant via another communication such as TCP and/or LRP-DT and/or via another protocol. Note that the local portal may continue to send further record LRPDU messages as the record is updated without waiting for acknowledgment.

隣接ポータル、したがって、登録側は、レコードLRPDUメッセージ407を受信し、含まれているレコードヘッダ及び/又はレコードで登録側データベースを更新する。次いで、隣接ポータルは、登録側の代わりに部分リストLRPDUメッセージ409を生成できる。部分リストLRPDUメッセージ409は、レコードLRPDUメッセージ407の承認として機能する。部分リストLRPDUメッセージ409は、レコードLRPDUメッセージ407に含まれるレコードヘッダを含み、したがって、例に依存して、登録側がこれらのレコードへの更新を認識していること及び/又は受信したことを示す。隣接ポータルは、部分リストLRPDUメッセージ409を申請側データベースに送信する。レコードLRPDUメッセージ407を承認する部分リストLRPDUメッセージ409は、ローカルポータルにおいて受信される。次いで、ローカルポータルは、フラグを使用することにより、登録側データベースによる承認済みとして、申請側データベース内の更新されたレコードをマーキングできる。 Neighboring portals, and therefore registrants, receive the record LRPDU message 407 and update the registrant database with the included record headers and/or records. Neighboring portals can then generate a partial list LRPDU message 409 on behalf of the registrant. Part list LRPDU message 409 serves as an acknowledgment of record LRPDU message 407 . The partial list LRPDU message 409 includes the record headers included in the record LRPDU message 407, thus indicating that the registrant is aware of and/or has received updates to these records, depending on the example. Neighboring portals send a partial list LRPDU message 409 to the requesting database. A partial list LRPDU message 409 acknowledging the record LRPDU message 407 is received at the local portal. The local portal can then mark the updated record in the applicant database as approved by the registrant database by using a flag.

上記のように、ローカルポータルは、対応する部分リストLRPDUメッセージ409を待機することなく、更なるレコードLRPDUメッセージ407を送信してもよい。したがって、特定の部分リストLRPDUメッセージ409が受信されたときであっても、様々なレコード更新は、未承認のままでもよい。しかし、いくつかの場合、例えば、申請側への更新の一時停止のため、全ての対応するレコードLRPDUメッセージ407について全ての部分リストLRPDUメッセージ409が受信される可能性がある。これが発生したとき、申請側データベース及び登録側データベースは同期している。ローカルポータルは、部分リストLRPDUメッセージ409を受信する毎に、申請側データベース内のレコードの承認状態を検査できる。したがって、データベースが同期したとき、ローカルポータルは、申請側データベース内の全ての更新されたレコードが、LRPDUメッセージを介して登録側データベースにより承認されたと決定できる。申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたという決定に基づいて、ローカルポータルは、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するために、全レコード承認411を送信できる。全レコード承認411は、同期を検証するためにアプリケーションに送信される所定のコードの形式の指示でもよい。 As noted above, the local portal may send further record LRPDU messages 407 without waiting for corresponding partial list LRPDU messages 409 . Therefore, various record updates may remain unacknowledged even when a particular partial list LRPDU message 409 is received. However, in some cases, all partial list LRPDU messages 409 may be received for all corresponding record LRPDU messages 407, eg, due to suspension of updates to the applicant. When this happens, the applicant database and the enrollment database are in sync. Each time the Local Portal receives a Part List LRPDU message 409, it can check the approval status of the record in the applicant's database. Therefore, when the databases are synchronized, the Local Portal can determine that all updated records in the requesting database have been approved by the subscribing database via LRPDU messages. Upon determining that all updated records in the applicant database have been approved by the registrant database via LRPDU messages, the Local Portal notifies the application that the applicant database is in sync with the registrant database. A full record approval 411 can be sent for notification. Acknowledge all records 411 may be an instruction in the form of a predetermined code sent to the application to verify synchronization.

任意選択で、ローカルポータルは、各レコードLRPDUメッセージ407のタイマを維持するように構成できる。このような場合、対応する部分リストLRPDUメッセージ409を受信することなく、レコードLRPDUメッセージ407タイマが満了したとき、ローカルポータルは、アプリケーションへの障害通知412を生成できる。未承認のレコードLRPDUメッセージ407は、ローカルポータルにより自動的に再送されなくてもよい。隣接ポータル及び/又は対応するターゲットポートは、限られた受信バッファを含んでもよい。自動再送は、他のレコードLRPDUメッセージ407のため、バッファ溢れを生じる可能性がある。したがって、アプリケーションは、例えば、未承認のレコードLRPDUメッセージ407を再送すること、より長く待機すること、申請側データベースへの対応するレコード更新をロールバックすること等により、どのように処理するかを決定できる。 Optionally, the local portal can be configured to maintain a timer for each record LRPDU message 407. In such a case, when the record LRPDU message 407 timer expires without receiving a corresponding partial list LRPDU message 409, the local portal can generate a failure notification 412 to the application. Unacknowledged record LRPDU messages 407 may not be automatically resent by the local portal. Neighboring portals and/or corresponding target ports may include limited receive buffers. Automatic retransmission may result in buffer overflow due to other record LRPDU messages 407 . Accordingly, the application decides how to proceed, e.g., by resending the unacknowledged record LRPDU message 407, waiting longer, rolling back the corresponding record update to the requesting database, etc. can.

隣接ポータルは、登録側の代わりに完全リストLRPDUメッセージ413を送信する。完全リストLRPDUメッセージ413は、登録側データベースの全てのレコードのレコードヘッダを含む(しかし、レコード自体は含まない)。完全リストLRPDUメッセージ413は、周期的に送信され、ローカルポータルを介して申請側により受信されてもよい。完全リストLRPDUメッセージ413は、例えば、部分リストLRPDUメッセージ409がローカルポータル/申請側により受信されない場合、1つ以上の以前に送信されたレコードLRPDUメッセージ407の承認として機能してもよい。さらに、完全リストLRPDUメッセージ413はまた、いつレコードLRPDUメッセージ407が登録側により受信されなかったかを決定するために、申請側により使用されてもよい。例えば、申請側は、完全リストLRPDUメッセージ413内のレコードヘッダを申請側データベース内のレコードヘッダと比較できる。申請側データベース内のレコードヘッダが完全リストLRPDUメッセージ413内のレコードヘッダと一致するとき、申請側は、全てのレコード更新が登録側により受信されたと決定し、全レコード承認411を送信できる。申請側データベース内のレコードヘッダが完全リストLRPDUメッセージ413内のレコードヘッダと一致しないとき、申請側は、特定のレコード更新が登録側で受信されていないと決定し、これらを再送できる。 A neighboring portal sends a complete list LRPDU message 413 on behalf of the registrant. The complete list LRPDU message 413 contains the record headers of all records in the subscriber database (but not the records themselves). A complete list LRPDU message 413 may be sent periodically and received by the applicant via the local portal. A complete list LRPDU message 413 may serve as an acknowledgment of one or more previously sent record LRPDU messages 407, for example, if a partial list LRPDU message 409 is not received by the local portal/applicant. Additionally, the complete list LRPDU message 413 may also be used by the applicant to determine when a record LRPDU message 407 was not received by the registrant. For example, the applicant can compare the record headers in the complete list LRPDU message 413 with the record headers in the applicant's database. When the record headers in the applicant's database match the record headers in the Complete List LRPDU message 413, the applicant determines that all record updates have been received by the registrant and can send an Acknowledge All Records 411. When the record headers in the applicant's database do not match the record headers in the complete list LRPDU message 413, the applicant can determine that certain record updates have not been received by the registrant and resend them.

方法400はまた、他の場合も管理する。例えば、接続中断415が発生する可能性がある。接続中断415は、ローカルポータル及び隣接ポータルのターゲットポートの間のノード又はリンクの障害から生じる可能性がある。接続中断415はまた、データトラフィック輻輳のために発生する可能性がある。ハローLRPDUメッセージ401及び403のようなハローLRPDUメッセージは周期的に交換され、このような交換が失敗したとき、ポータルは接続中断415を認識するようになる。ハローメッセージ交換が失敗したとき、ローカルポータルは、アプリケーションのための切断コード416を生成する。切断コード416は、ハローLRPDUメッセージの交換が失敗して接続中断415が発生したことをアプリケーションに示す。次いで、申請側は、接続中断415に応じて取るべきアクションを決定できる。例えば、アプリケーションは、接続を再確立したときにデータベース対をリセットすることを判断でき、この場合、一旦ハローLRPDUメッセージ401及び403が交換されると、方法400が再開する。 Method 400 also manages other cases. For example, a connection interruption 415 may occur. A connection interruption 415 can result from a node or link failure between the target ports of the local portal and neighboring portals. Connection disruption 415 can also occur due to data traffic congestion. Hello LRPDU messages such as hello LRPDU messages 401 and 403 are exchanged periodically, and when such exchanges fail, the portal becomes aware of the connection interruption 415 . When the hello message exchange fails, the local portal generates a disconnect code 416 for the application. Disconnect code 416 indicates to the application that the exchange of hello LRPDU messages has failed resulting in connection interruption 415 . The applicant can then decide what action to take in response to the connection interruption 415 . For example, the application may decide to reset the database pair upon re-establishing the connection, in which case the method 400 resumes once the hello LRPDU messages 401 and 403 have been exchanged.

他の例として、アプリケーションは、データベース対を保持して接続を再確立することを判断できる。成功したとき、この手法は、申請側データベース内の全てのレコードを登録側データベースに再送する必要性を回避する。アプリケーションは、維持データベースコマンド417をローカルポータルに送信できる。したがって、ローカルポータルは、切断コード416にもかかわらずローカルノードのメモリにおいて申請側データベースを維持するために、アプリケーションから維持データベース417コマンドを受信できる。ローカルポータルがデータベース対を維持するためのコマンドを受信したとき、ローカルポータルは、完全リストLRPDUメッセージ418が隣接ポータルを介して登録側データベースから受信されるまで、レコードLRPDUメッセージ407を送信するのを中止する。例えば、ローカルポータルは、完全リストLRPDUメッセージ418が受信されるまで、レコードLRPDUメッセージの送信を防止するために、ハローLRPDUメッセージの失敗した交換(例えば、接続中断415)の後に、申請側データベースにおいて通知タイマをリセットできる。 As another example, the application may decide to keep the database pair and re-establish the connection. When successful, this approach avoids the need to resend all records in the applicant database to the applicant database. Applications can send maintenance database commands 417 to the local portal. Thus, the local portal can receive maintenance database 417 commands from the application to maintain the requesting database in the local node's memory despite the disconnect code 416 . When the Local Portal receives a command to maintain the database pair, the Local Portal ceases sending Record LRPDU messages 407 until a Complete List LRPDU message 418 is received from the registrant database via a neighboring Portal. do. For example, the Local Portal notifies in the applicant database after a failed exchange of Hello LRPDU messages (e.g., connection abort 415) to prevent transmission of Record LRPDU messages until a Complete List LRPDU message 418 has been received. You can reset the timer.

隣接ポータルは、隣接ノードのアプリケーションと同様のプロセスを実行する。成功したハローLRPDUメッセージ交換の後に、登録側は、隣接ポータルを介して、完全リストLRPDUメッセージ418を送信する。完全リストLRPDUメッセージ418は、完全リストLRPDUメッセージ413と実質的に同様であり、したがって、登録側データベースの全てのレコードヘッダを含む。ローカルノード又はリモートノードのアプリケーションのいずれかがデータベース対をリセットすることを選択した場合、方法400は再開する。例えば、隣接ポータルが登録側データベースをリセットし、ローカルポータルが申請側データベースをリセットしない場合、完全リストLRPDUメッセージ418は空であり、申請側は全てのレコードを再送する。他の例として、隣接ポータルが登録側データベースをリセットせず、ローカルポータルが申請側データベースをリセットする場合、完全リストLRPDUメッセージ418は、申請側データベースと一致しないレコードヘッダを含み、データベース対はリセットされる。しかし、双方のアプリケーションがデータベース対を維持することを選択した場合、完全リストLRPDUメッセージ418は、申請側データベース内のレコードヘッダと同一又は同様(例えば、失われたレコードLRPDUメッセージ407のため)のレコードヘッダを含む。この場合、申請側は、データベース対の間の同期を回復するために必要なステップを決定できる。 Neighboring portals perform similar processes to the applications of neighboring nodes. After a successful hello LRPDU message exchange, the registrant sends a complete list LRPDU message 418 via the neighbor portal. The complete list LRPDU message 418 is substantially similar to the complete list LRPDU message 413 and thus contains all record headers of the registrant database. If either the local node or the remote node's application chooses to reset the database pair, the method 400 resumes. For example, if the neighboring portal resets the registrant database and the local portal does not reset the applicant database, the complete list LRPDU message 418 will be empty and the applicant will resend all records. As another example, if the neighboring portal does not reset the registering database and the local portal resets the requesting database, the complete list LRPDU message 418 will contain record headers that do not match the requesting database and the database pair will be reset. be. However, if both applications choose to maintain a database pair, the complete list LRPDU message 418 will contain records with the same or similar (eg, due to lost record LRPDU message 407) record headers in the requesting database. Contains headers. In this case, the applicant can determine the steps necessary to restore synchronization between the database pair.

したがって、ローカルポータルは、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完全リストLRPDUメッセージ418を受信できる。完全リストLRPDUメッセージ418は、登録側データベースの全てのレコードのレコードヘッダを含む。次いで、ローカルポータル及び/又は申請側データベースは、申請側データベースを登録側データベースと再同期させるために、完全リストLRPDUメッセージ418からのレコードヘッダを申請側データベース内のレコードヘッダと比較できる。第1の場合、ローカルポータルは、申請側データベース内のレコードヘッダと完全リストLRPDUメッセージ418に含まれる登録側データベースからのレコードヘッダとの間に不一致がないと決定できる。このような場合、データベース対は同期している。したがって、不一致がないという決定に基づいて、ポータルは、例えば、全レコード承認411を送信することにより、申請側データベースが登録側データベースと同期していることをアプリケーションに通知できる。第2の場合、ローカルポータルは、申請側データベース内の1つ以上のレコードヘッダと完全リストLRPDUメッセージ418からの1つ以上のレコードヘッダとの間の不一致を決定できる。これは、接続中断415の間にレコードLRPDUメッセージ407が失われた場合に発生する可能性がある。ポータルは、どのレコードが登録側データベースに送信されていないかを決定するために、レコードヘッダを比較できる。次いで、ローカルポータルは、隣接ポータルを介して、レコードLRPDUメッセージ407を登録側データベースに送信できる。レコードLRPDUメッセージ407は、不一致に対処するために、必要に応じて更新されたレコードヘッダを含む。いずれの場合も、データベース対をリセットして申請側データベース内の全てのレコードを再送することなく、データベース対が同期することになる。 Thus, the Local Portal can receive a Complete List LRPDU message 418 from the neighboring node's registrant database after a successful exchange of Hello messages. The complete list LRPDU message 418 contains record headers for all records in the subscriber database. The local portal and/or applicant database can then compare the record headers from the complete list LRPDU message 418 with the record headers in the applicant database in order to resynchronize the applicant database with the registration database. In the first case, the Local Portal can determine that there is no mismatch between the record headers in the applicant database and the record headers from the registrant database contained in the complete list LRPDU message 418. In such cases, the database pair is in sync. Therefore, based on the determination that there are no discrepancies, the portal can notify the application that the requesting database is in sync with the registering database, for example, by sending an Approve All Records 411 . In the second case, the Local Portal can determine discrepancies between one or more record headers in the requesting database and one or more record headers from the Complete List LRPDU message 418 . This can occur if a record LRPDU message 407 is lost during connection disruption 415 . The portal can compare record headers to determine which records have not been submitted to the subscribing database. The local portal can then send a record LRPDU message 407 to the registrant database via neighboring portals. The record LRPDU message 407 contains updated record headers as necessary to address discrepancies. In either case, the database pair will be synchronized without resetting the database pair and resending all the records in the requesting database.

任意選択で、ローカルポータルはまた、申請側の代わりに、完全リストLRPDUメッセージ421を要求できる。これは、申請側がオンデマンドでデータベース同期を検査することを可能にする。このような場合、ローカルポータルは、隣接ポータルを介して要求完全リストLRPDUメッセージ419を登録側データベースに送信する。隣接ポータル及び/又は登録側は、要求完全リストLRPDUメッセージ419を受信し、ローカルポータルを介して完全リストLRPDUメッセージ421を申請側に送信する。完全リストLRPDUメッセージ421は、完全リストLRPDUメッセージ418及び413と実質的に同様である。次いで、ローカルポータル、したがって、申請側は、要求完全リストLRPDUメッセージ419に応じて、登録側データベースから完全リストLRPDUメッセージ421を受信できる。したがって、申請側は、データベース対が同期しているか否かを決定し、及び/又はデータベース対を同期させるためにどのレコードが登録側に送信されるべきかを決定するために、完全リストLRPDUメッセージ421からのレコードヘッダを申請側データベース内のレコードヘッダと比較できる。 Optionally, the Local Portal can also request a complete list LRPDU message 421 on behalf of the applicant. This allows applicants to check database synchronization on demand. In such case, the local portal sends a request complete list LRPDU message 419 to the registrant database via the neighboring portal. Neighboring portals and/or registrants receive the Request Complete List LRPDU message 419 and send a Complete List LRPDU message 421 to the applicant via the local portal. Complete list LRPDU message 421 is substantially similar to complete list LRPDU messages 418 and 413 . The Local Portal, and hence the applicant, can then receive a complete list LRPDU message 421 from the registrant database in response to the request complete list LRPDU message 419 . Therefore, the applicant uses the Complete List LRPDU message to determine whether the database pair is in sync and/or which records should be sent to the registrant to synchronize the database pair. You can compare the record headers from the 421 with the record headers in the applicant's database.

方法400のLRPDUメッセージ及び通知は、本開示の様々な例示的な機能を記述するために順に示されている点に留意すべきである。このようなメッセージ/通知は、様々な組み合わせで使用できる。例えば、ハローLRPDUメッセージ401及び403並びに完全リストLRPDUメッセージ413、418及び421のハロー交換は、事前定義のタイマに基づいて且つ上記のトリガイベントに基づいて、周期的に発生してもよい。さらに、結果のレコードLRPDUメッセージ407及び部分リストLRPDUメッセージ409でのレコード変更405は、介在するアクションの有無にかかわらず、申請側データベースの通常の動作中に繰り返し発生してもよい。さらに、全レコード承認411、障害通知412、切断コード416及び維持データベースコマンド417は、対応する状況が発生したときに常にトリガーできる。したがって、図4におけるLRPDUメッセージ及び通知の順序は例示的なものであり、ここで別段の指定がない限り、限定として考えられるべきではない。 It should be noted that the LRPDU messages and notifications of method 400 are shown in order to describe various exemplary functions of this disclosure. Such messages/notifications can be used in various combinations. For example, hello exchanges of hello LRPDU messages 401 and 403 and complete list LRPDU messages 413, 418 and 421 may occur periodically based on predefined timers and based on the triggering events described above. Additionally, record changes 405 in resulting record LRPDU messages 407 and partial list LRPDU messages 409 may occur repeatedly during normal operation of the requesting database, with or without intervening actions. Additionally, Approve All Records 411, Notify Failure 412, Disconnect Code 416, and Maintain Database Commands 417 can be triggered whenever the corresponding situation occurs. Accordingly, the order of LRPDU messages and notifications in FIG. 4 is exemplary and should not be considered limiting unless otherwise specified herein.

さらに、いずれかの数のLRPDUは、レイヤ2フレームの最大サイズまで、単一のLRP-DTエッジ制御プロトコルデータユニット(Edge Control Protocol Data Unit, ECPDU)内で連続的に一緒に繋ぎ合わされることができる。単一のLRPDUは、複数のLRP-DT ECP ECPDUの間に分割されなくてもよい。TCPを使用するとき、LRPDUのサイズは、16ビット長のフィールドにより制限されてもよい。 Additionally, any number of LRPDUs may be contiguously strung together within a single LRP-DT Edge Control Protocol Data Unit (ECPDU), up to the maximum size of a Layer 2 frame. can. A single LRPDU may not be split between multiple LRP-DT ECP ECPDUs. When using TCP, the LRPDU size may be limited by a 16-bit long field.

図5は、ハローLRPDUメッセージ401及び/又は403を実装してもよいハローLRPDUメッセージ500の例示的な符号化を示す。したがって、ハローLRPDUメッセージ500は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300におけるデータベース対の同期を維持するために使用されてもよい。 FIG. 5 shows an exemplary encoding of a hello LRPDU message 500 in which hello LRPDU messages 401 and/or 403 may be implemented. Thus, hello LRPDU message 500 may be used to maintain synchronization of database pairs in native systems 110 and/or 130, proxies 210 and/or 230, slaves 240 and/or 250, and/or database system 300. good.

ハローLRPDUメッセージ500は、TLVフォーマットで符号化される。例えば、ここで使用されるTLVフォーマットは、65,535オクテットまでのデータフィールドをサポートしてもよい。ハローLRPDUメッセージ500はタイプ(Type)フィールド501を含む。タイプフィールド501は、1オクテットの長さと0オクテットのオフセットとを含む。タイプフィールド501は、ハローLRPDUメッセージ500を示すために1の値に設定されてもよい。ハローLRPDUメッセージ500はまた、長さ(Length)フィールド503を含む。長さフィールド503は、2オクテットの長さと1オクテットのオフセットとを含む。長さフィールド503は、データフィールド(例えば、メッセージの残り)の長さを含む最初のオクテット(オフセット1)内の最上位8ビットを有する2オクテットの整数を含んでもよい。したがって、0のTLV長フィールド503は、データフィールドが存在しないことを示す。ハローLRPDUメッセージ500の長さフィールド503(タイプフィールドに続くオクテット1及び2)は、固定長フィールドの全てにデータフィールド内の全てのTLVを加えた長さを含む。 Hello LRPDU message 500 is encoded in TLV format. For example, the TLV format used here may support data fields up to 65,535 octets. Hello LRPDU message 500 includes a Type field 501 . The type field 501 contains a length of 1 octet and an offset of 0 octets. Type field 501 may be set to a value of 1 to indicate a hello LRPDU message 500 . Hello LRPDU message 500 also includes a Length field 503 . Length field 503 contains a length of 2 octets and an offset of 1 octet. Length field 503 may contain a 2-octet integer with the 8 most significant bits in the first octet (offset 1) containing the length of the data field (eg, the rest of the message). Therefore, a TLV length field 503 of 0 indicates that there is no data field. The length field 503 (octets 1 and 2 following the type field) of the Hello LRPDU message 500 contains the length of all of the fixed length fields plus all TLVs in the data field.

残りのデータは、最初のデータフィールドにおいて3オクテットのオフセットを有する0から65,535オクテットの長さを含む。ハローLRPDUメッセージ500のデータフィールドは、申請側、登録側及び/又は対応するポータルにおいて、送信ハロー(Send Hello)状態機械の単一のインスタンスにより送信される情報を含む。ハローLRPDUメッセージ500は、いくつかの固定サイズのフィールドを含み、その後にデータフィールド内の一連のTLVが続く。すなわち、TLV長フィールド503に続く第10オクテットは、他のLRPDUタイプフィールドでもよい。 The remaining data contains a length of 0 to 65,535 octets with an offset of 3 octets in the first data field. The data field of the Hello LRPDU message 500 contains information sent by a single instance of the Send Hello state machine at the applicant, registrant and/or corresponding portal. A hello LRPDU message 500 includes a number of fixed-size fields followed by a series of TLVs in the data field. That is, the 10th octet following the TLV length field 503 could be another LRPDU type field.

ハローLRPDUメッセージ500はまた、AppIdフィールド505を含む。AppIdフィールド505は、送信ポータルに関連するアプリケーションを識別するAppIdを含む。AppIdフィールド505は、3オクテットの長さを有する管理組織識別子(Organizationally Unique Identifier, OUI)又は会社識別子(Company Identifier, CID)と、合計4オクテットの1オクテットの長さ及び3オクテットのオフセットを有するアプリケーションサブID(Sub-ID)とを含む。OUI又はCID所有者は、アプリケーションサブIDの使用を管理することを担う点に留意すべきである。また、AppIdは、ハローLRPDUメッセージ500だけでなく、状態機械変数を含む多数のコンテキストで使用される点に留意すべきである。 Hello LRPDU message 500 also includes an AppId field 505 . AppId field 505 contains an AppId that identifies the application associated with the submission portal. The AppId field 505 contains an Organizationally Unique Identifier (OUI) or Company Identifier (CID) with a length of 3 octets and an application ID with a length of 1 octet for a total of 4 octets and an offset of 3 octets. Includes Sub-ID. It should be noted that the OUI or CID owner is responsible for managing the use of Application Sub-IDs. Also note that AppId is used in many contexts, including state machine variables, not just in the Hello LRPDU message 500 .

ハローLRPDUメッセージ500はまた、ハロー状態(Hello Status)フィールド507を含む。ハロー状態フィールド507は、オクテットの最上位ビットにおける4ビットの列挙フィールドであり、以下の値、すなわち、ハロー状態ルッキング(hello status looking, hsLooking)、ハロー状態接続中(hello status connecting, hsConnecting)及びハロー状態接続済み(hello status connected, hsConnected)のうち1つを含む。hsLooking値は、対応するポータルがまだ成功した完全ポータル(Complete Portal)作成要求を受信していないことを示すために設定できる。hsConnecting値は、対応するポータルが成功した完全ポータル作成要求と、hsLooking状態を有するハローLRPDUメッセージ500とを受信したことを示すために設定できる。この場合、ポータルは全てのLRPDUを受信する準備ができている。hsConnected値は、対応するポータルがアップしており、アプリケーションデータを転送する準備ができていることを示すために設定できる。この場合、ポータルは全てのLRPDUを送信することが許可される。ハロー状態フィールド507はまた、エラー状態(Error Status)フィールド508を含むことができる。エラー状態フィールド508は、オクテットの最下位ビットにおいて4ビットの情報を含んでもよく、データベースオーバーフローのようなエラーを示してもよい。 Hello LRPDU message 500 also includes a Hello Status field 507 . Hello status field 507 is a 4-bit enumerated field in the most significant bit of the octet with the following values: hello status looking (hsLooking), hello status connecting (hsConnecting) and hello status connecting (hsConnecting). Contains one of the states hello status connected, hsConnected. The hsLooking value can be set to indicate that the corresponding portal has not yet received a successful Complete Portal create request. The hsConnecting value can be set to indicate that the corresponding portal received a successful complete portal create request and a hello LRPDU message 500 with hsLooking state. In this case the portal is ready to receive all LRPDUs. The hsConnected value can be set to indicate that the corresponding portal is up and ready to transfer application data. In this case the portal is allowed to send all LRPDUs. Hello status field 507 may also include Error Status field 508 . The error status field 508 may contain 4 bits of information in the least significant bits of the octet and may indicate an error such as database overflow.

ハローLRPDUメッセージ500はまた、マイポータル番号(My Portal Number)フィールド509を含む。マイポータル番号フィールド509は、送信ポータルを識別する4オクテットの番号を含む。識別番号は、この同じLRP-DTインスタンスを共有するポータルの全てで一意である。このフィールドは4オクテットの長さであり、この理由は、プロキシシステムがいずれかの数のスレーブシステムをプロキシでき、これらのそれぞれが多数のターゲットポートを有することができるからである。さらに、プロキシシステムは、他の同様のプロキシシステムへのTCP接続を行うことができる。各プロキシシステムは、プロキシシステムがプロキシしているターゲットポートのそれぞれに、マイポータル番号の1つの値を使用する。マイポータル番号フィールド509は、ターゲットポート141、151、241及び251、したがって、ポータル113、133、213及び233のどの対と、最終的にはどのデータベース120、122、220及び222と、所与のレコードLRPDU、部分リストLRPDU、完全リストLRPDU又は要求完全リストLRPDUが関連付けられるかを識別するために、他のLRPDUメッセージで使用される。 Hello LRPDU message 500 also includes a My Portal Number field 509 . My portal number field 509 contains a 4-octet number that identifies the sending portal. The identification number is unique across all portals sharing this same LRP-DT instance. This field is 4 octets long, because a proxy system can proxy any number of slave systems, each of which can have multiple target ports. In addition, proxy systems can make TCP connections to other similar proxy systems. Each proxy system uses one value of MyPortalNumber for each target port that the proxy system is proxying to. The My Portal Number field 509 specifies which pair of target ports 141, 151, 241 and 251, and thus portals 113, 133, 213 and 233, and ultimately which databases 120, 122, 220 and 222, and a given Used in other LRPDU messages to identify whether a Record LRPDU, Partial List LRPDU, Complete List LRPDU or Request Complete List LRPDU is associated.

ハローLRPDUメッセージ500はまた、ハロー時間(Hello Time)フィールド511を含む。ハロー時間フィールド511は、ハローLRPDUメッセージ500の生存時間を表す2オクテットを含む。ハロー時間フィールド511の最初のオクテットは、ハローLRPDUメッセージ500が有効である16ビットの数の秒(0から65,535又は30から65,535)の最上位オクテットである。このフィールドは、1以上29以下の値では送信されなくてもよい。 Hello LRPDU message 500 also includes a Hello Time field 511 . Hello time field 511 contains two octets representing the time to live of hello LRPDU message 500 . The first octet of the hello time field 511 is the most significant octet of the 16-bit number of seconds (0 to 65,535 or 30 to 65,535) for which the hello LRPDU message 500 is valid. This field MAY NOT be sent with values between 1 and 29 inclusive.

ハローLRPDUメッセージ500内の最初の4つのTLVは、いずれかの順序でのマイシャーシID TLV513、マイポートID TLV515、隣接シャーシID TLV517及び隣接ポートID TLV519のそれぞれ1つである。これらに続いて、0又は1つのアプリケーション情報(Application Information)TLV521のいずれかが来る。 The first four TLVs in Hello LRPDU message 500 are one each of My Chassis ID TLV 513, My Port ID TLV 515, Neighbor Chassis ID TLV 517, and Neighbor Port ID TLV 519 in any order. Following these come either 0 or 1 Application Information TLV 521 .

マイシャーシID TLV513のタイプフィールドは、typeMyChassisIdの値に設定される。マイシャーシID TLV513のデータフィールドは、マイシャーシID TLV513を送信するポータルを作成した完全ポータル作成要求で示されるLLDPインスタンスによるLLDPシャーシID(LLDP Chassis ID)TLVにおける送信のために指定された値を含む。具体的には、マイシャーシID TLV513は、ハローLRPDUメッセージ500の送信者として機能するローカルノード(例えば、機械)を識別する値を含む。このようなローカルノードは、データベース対を設定及び/又は維持するために使用されるネイティブシステム又はスレーブシステムを含む(例えば、ローカル登録側、ローカル申請側又はこれらの双方を含むか或いはそれに結合される)。 The type field of My Chassis ID TLV 513 is set to the value of typeMyChassisId. The My Chassis ID TLV513 data field contains the value specified for transmission in the LLDP Chassis ID TLV by the LLDP instance indicated in the complete portal creation request that created the portal transmitting My Chassis ID TLV513. . Specifically, My Chassis ID TLV 513 contains a value that identifies the local node (eg, machine) acting as the sender of Hello LRPDU message 500 . Such local nodes include native systems or slave systems used to set up and/or maintain database pairs (e.g., including or coupled to local registrants, local applicants, or both). ).

マイポートID TLV515のタイプフィールドは、typeMyPortIdの値に設定される。マイポートID TLV515のデータフィールドは、マイポートID TLV515を送信するポータルを作成した完全ポータル作成要求で示されるLLDPインスタンスによるLLDPポートID(LLDP Port ID)TLVにおける送信のために指定された同じ値を含む。具体的には、マイポートID TLV515は、データベース対(例えば、ネイティブシステム又はスレーブ)を設定及び/又は維持するのを試みるローカルノード上でターゲットポートを識別する値を含む。シャーシID及びポートIDは共に、LRPDUメッセージの通信のためのターゲットリンクのローカルの半分を一意に表す。 The type field of the MyPort ID TLV 515 is set to the value of typeMyPortId. The My Port ID TLV515 data field shall contain the same value specified for transmission in the LLDP Port ID TLV by the LLDP instance indicated in the complete portal creation request that created the portal transmitting My Port ID TLV515. include. Specifically, My Port ID TLV 515 contains a value that identifies the target port on the local node attempting to set up and/or maintain the database pair (eg, native system or slave). Together, the chassis ID and port ID uniquely represent the local half of the target link for communication of LRPDU messages.

隣接シャーシID TLV517のタイプフィールドは、typeNeighborChassisIdの値に設定される。隣接シャーシID TLV517のデータフィールドは、マイシャーシID TLV513と同じフォーマットであり、ローカルポータルが関連する隣接ポータルのシャーシIDを含む。具体的には、隣接シャーシID TLV517は、ハローLRPDUメッセージ500の宛先として機能する隣接ノード(例えば、機械)を識別する値を含む。隣接ノードは、データベース対を設定及び/又は維持するために使用されるネイティブシステム又はスレーブシステムを含む(例えば、隣接登録側、隣接申請側又はこれらの双方を含むか或いはそれに結合される)。 The type field of the Neighbor Chassis ID TLV 517 is set to the value of typeNeighborChassisId. The Neighbor Chassis ID TLV 517 data field has the same format as My Chassis ID TLV 513 and contains the Chassis ID of the neighboring portal with which the local portal is associated. Specifically, neighbor chassis ID TLV 517 contains a value that identifies the neighbor node (eg, machine) that serves as the destination of hello LRPDU message 500 . Neighboring nodes include native systems or slave systems used to establish and/or maintain database pairs (eg, including or coupled to adjacent registrants, adjacent applicants, or both).

隣接ポートID TLV519のタイプフィールドは、typeNeighborPortIdの値に設定される。隣接ポートID TLV519のデータフィールドは、マイポートID TLV515と同じフォーマットであり、ローカルポータルが関連する隣接ポータルのポートIDを含む。具体的には、隣接ポートID TLV519はデータベース対(例えば、ネイティブシステム又はスレーブ)を設定及び/又は維持するために使用される隣接ノード上でターゲットポートを識別する値を含む。隣接シャーシID及び隣接ポートIDは共に、LRPDUメッセージの通信のためのターゲットリンクの隣接の半分を一意に表す。したがって、ハローLRPDU500は、ローカルノードを識別するマイシャーシID、ローカルノード上のターゲットポートを識別するマイポートID、隣接ノードを識別する隣接シャーシID、及び隣接ノード上のターゲットポートを識別する隣接ポートIDとしてターゲットリンクを表す。 The type field of the Neighbor Port ID TLV 519 is set to the value of typeNeighborPortId. The Neighbor Port ID TLV 519 data field has the same format as My Port ID TLV 515 and contains the port ID of the neighboring portal with which the local portal is associated. Specifically, Neighbor Port ID TLV 519 contains a value that identifies the target port on the adjacent node used to set up and/or maintain the database pair (eg, native system or slave). Together, the Neighbor Chassis ID and Neighbor Port ID uniquely represent the adjacent half of the target link for communication of the LRPDU message. Thus, the Hello LRPDU 500 contains a My Chassis ID that identifies the local node, a My Port ID that identifies the target port on the local node, an Adjacent Chassis ID that identifies the adjacent node, and an Adjacent Port ID that identifies the target port on the adjacent node. represents the target link as .

アプリケーション情報TLV521は、typeAppInfoの値に設定される。アプリケーション情報TLV521のデータフィールドは、イネーブルポータル作成要求により供給される情報を含む。データは、LRP-DT接続の宛先端のポータル状態指示を通じて宛先のアプリケーションに提示される。データは不明瞭でもよく、LRPにより解釈されなくてもよい。アプリケーション情報TLV521は任意選択である。 Application information TLV 521 is set to the value of typeAppInfo. The data fields of Application Information TLV 521 contain information supplied with the Create Enabled Portal request. Data is presented to the destination application through the portal state indication at the destination end of the LRP-DT connection. The data may be ambiguous and may not be interpreted by the LRP. Application Information TLV521 is optional.

したがって、タイプフィールド501は、0オクテットのオフセットを有する1オクテットであり、長さフィールド503は、1オクテットのオフセットを有する2オクテットであり、AppIdフィールド505は、3オクテットのオフセットを有する4オクテットであり、ハロー状態フィールド507は、7オクテットのオフセットを有する1オクテットであり、マイポータル番号フィールド509は、8オクテットのオフセットを有する4オクテットであり、ハロー時間フィールド511は、12オクテットのオフセットを有する2オクテットであり、残りのTLV513~521は14オクテットの開始オフセットを有する可変長である。 Thus, the Type field 501 is 1 octet with an offset of 0 octets, the Length field 503 is 2 octets with an offset of 1 octet, and the AppId field 505 is 4 octets with an offset of 3 octets. , the hello state field 507 is 1 octet with an offset of 7 octets, the My Portal Number field 509 is 4 octets with an offset of 8 octets, and the hello time field 511 is 2 octets with an offset of 12 octets. and the remaining TLVs 513-521 are variable length with a starting offset of 14 octets.

図6は、レコードLRPDUメッセージ407を実装してもよいレコードLRPDUメッセージ600の例示的な符号化を示す。したがって、レコードLRPDUメッセージ600は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300におけるデータベース対の同期を維持するために使用されてもよい。レコードLRPDUメッセージ600は、それぞれタイプフィールド501及び長さフィールド503と同様のタイプフィールド601及び長さフィールド603を含む。タイプフィールド601は、レコードLRPDUメッセージ600(例えば、typeRecordLRPDU)を示すために2つの値を含んでもよく、長さフィールド603は、レコードLRPDUメッセージ600の長さを含む。レコードLRPDUメッセージ600のデータフィールドの最初の2オクテットは、送信ポータルのシャーシID、ポートID及びappIdを符号化するマイポータル番号フィールド609である。これは、同じポータルについてハローLRPDUメッセージ500で送信される同じ値である。これに続いて、レコードフィールド630内の0以上のレコードがある。 FIG. 6 shows an exemplary encoding of a record LRPDU message 600 that may implement record LRPDU message 407 . Therefore, record LRPDU message 600 may be used to maintain synchronization of database pairs in native system 110 and/or 130, proxy 210 and/or 230, slave 240 and/or 250, and/or database system 300. good. Record LRPDU message 600 includes type field 601 and length field 603 similar to type field 501 and length field 503, respectively. Type field 601 may contain two values to indicate record LRPDU message 600 (eg, typeRecordLRPDU), and length field 603 contains the length of record LRPDU message 600 . The first two octets of the data field of the record LRPDU message 600 are the My Portal Number field 609 which encodes the sending portal's chassis ID, port ID and appId. This is the same value sent in the Hello LRPDU message 500 for the same portal. Following this are zero or more records in record field 630 .

各レコードは、レコード番号フィールド631、シーケンス番号フィールド633、チェックサムフィールド635、並びに、任意選択でデータ長フィールド637及びアプリケーションデータフィールド639を含む。レコード番号フィールド631は、更新された申請側データベースのレコードを示すデータを含む。シーケンス番号フィールド633は、対応するレコードに関連するバージョン番号及び/又は変更の数を示すデータを含む。チェックサムフィールド635は、対応するレコードに含まれる値(例えば、レコード番号フィールド631、シーケンス番号フィールド633、データ長フィールド637及び/又はアプリケーションデータフィールド639内の値)に基づいて計算された2オクテットの値のようなエラー訂正データを含む。データ長フィールド637は、存在する場合、対応するレコード内のデータの長さ及び/又はアプリケーションデータフィールド639の長さを示す。アプリケーションデータフィールド639は、存在する場合、申請側データベースから登録側データベースへの送信中の更新されたレコードを含む。 Each record includes a record number field 631 , a sequence number field 633 , a checksum field 635 and optionally a data length field 637 and an application data field 639 . Record number field 631 contains data indicating the record in the applicant database that has been updated. Sequence number field 633 contains data indicating the version number and/or number of changes associated with the corresponding record. The checksum field 635 is a two-octet length calculated based on the values contained in the corresponding record (e.g., the values in the record number field 631, sequence number field 633, data length field 637 and/or application data field 639). Contains error correction data such as values. Data length field 637 indicates the length of the data in the corresponding record and/or the length of application data field 639, if present. Application data field 639, if present, contains the updated record in transit from the applicant database to the enrollment database.

したがって、レコードLRPDUメッセージ600は、申請側データベースで更新されたレコードを示す1つ以上のレコード番号と、申請側データベースで更新されたレコードに含まれる更新を識別する1つ以上のシーケンス番号とを含んでもよい。さらに、タイプフィールド601は、0オクテットのオフセットを有する1オクテットであり、長さフィールド603は、1オクテットのオフセットを有する2オクテットであり、マイポータル番号フィールド609は、3オクテットのオフセットを有する4オクテットであり、レコードフィールド630は、7オクテットのオフセットを有する可変長である。また、各レコードは、0オクテットのオフセットを有する4オクテットのレコード番号フィールド631と、4オクテットのオフセットを有する4オクテットのシーケンス番号フィールド633と、8オクテットのオフセットを有する2オクテットのチェックサムフィールド635と、10オクテットのオフセットを有する2オクテットのデータ長フィールド637と、12オクテットのオフセットを有する0から65520オクテットのアプリケーションデータフィールド639とを含み、レコードオフセットは、レコードの開始から測定される。 Accordingly, the record LRPDU message 600 includes one or more record numbers that indicate the records updated in the requesting database and one or more sequence numbers that identify the updates contained in the updated records in the requesting database. It's okay. Further, the type field 601 is 1 octet with an offset of 0 octet, the length field 603 is 2 octets with an offset of 1 octet, and the MyPortalNumber field 609 is 4 octets with an offset of 3 octets. and record field 630 is variable length with an offset of 7 octets. Each record also has a 4-octet record number field 631 with a 0-octet offset, a 4-octet sequence number field 633 with a 4-octet offset, and a 2-octet checksum field 635 with an 8-octet offset. , a 2-octet data length field 637 with an offset of 10 octets, and an application data field 639 of 0 to 65520 octets with an offset of 12 octets, where the record offset is measured from the start of the record.

図7は、部分リストLRPDUメッセージ409を実装してもよい部分リストLRPDUメッセージ700の例示的な符号化を示す。したがって、部分リストLRPDUメッセージ700は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300におけるデータベース対の同期を維持するために使用されてもよい。部分リストLRPDUメッセージ700は、それぞれタイプフィールド501及び長さフィールド503と同様のタイプフィールド701及び長さフィールド703を含む。タイプフィールド701は、部分リストLRPDUメッセージ700(例えば、typePartialListLRPDU)を示すために3の値を含んでもよく、長さフィールド703は、部分リストLRPDUメッセージ700の長さを含む。 FIG. 7 shows an exemplary encoding of a partial list LRPDU message 700 that may implement the partial list LRPDU message 409. FIG. Partial list LRPDU message 700 is therefore used to maintain synchronization of database pairs in native systems 110 and/or 130, proxies 210 and/or 230, slaves 240 and/or 250, and/or database system 300. good too. Partial list LRPDU message 700 includes type field 701 and length field 703 similar to type field 501 and length field 503, respectively. Type field 701 may contain a value of 3 to indicate a partial list LRPDU message 700 (eg, typePartialListLRPDU), and length field 703 contains the length of partial list LRPDU message 700 .

部分リストLRPDUメッセージ700のデータフィールドの最初の2オクテットは、送信ポータルのシャーシID、ポートID及びappIdを符号化するマイポータル番号フィールド709である。これは、同じポータルについてハローLRPDUメッセージ500で送信される同じ値である。これに続いて、レコード630と実質的に同様であるがレコードデータを含まない0以上のレコードヘッダ730がある。具体的には、各レコードヘッダ730は、それぞれレコード番号フィールド631、シーケンス番号フィールド633及びチェックサムフィールド635と実質的に同様のレコード番号フィールド731、シーケンス番号フィールド733及びチェックサムフィールド735を含む。さらに、レコード番号フィールド731及びシーケンス番号フィールド733は、レコードLRPDUメッセージ600内の対応するレコード630の対応する値に一致する(例えば、申請側によるレコードLRPDUメッセージ600に含まれるような)登録側により追加される値を含む。したがって、レコードヘッダ730は、レコード630の受信を承認する。 The first two octets of the data field of the Partial List LRPDU message 700 are the My Portal Number field 709 which encodes the sending portal's chassis ID, port ID and appId. This is the same value sent in the Hello LRPDU message 500 for the same portal. Following this are zero or more record headers 730 that are substantially similar to record 630 but contain no record data. Specifically, each record header 730 includes a record number field 731, a sequence number field 733 and a checksum field 735 substantially similar to record number field 631, sequence number field 633 and checksum field 635, respectively. Additionally, a record number field 731 and a sequence number field 733 are added by the registrant (eg, as included in the record LRPDU message 600 by the applicant) that match the corresponding values of the corresponding record 630 in the record LRPDU message 600. contains the value to be Thus, record header 730 acknowledges receipt of record 630 .

したがって、部分リストLRPDUメッセージ700は、レコードLRPDUメッセージ600を承認し、部分リストLRPDUメッセージ700は、少なくとも1つの更新されたレコード630を承認する少なくとも1つのレコードヘッダ730を含む。さらに、レコードヘッダ730は、更新されたレコード(例えば、レコード630)を示すレコード番号フィールド731内のレコード番号と、更新されたレコード(例えば、レコード630)に含まれる更新を識別するシーケンス番号フィールド733内のレコード番号とを含む。 Thus, partial list LRPDU message 700 acknowledges record LRPDU message 600 and partial list LRPDU message 700 includes at least one record header 730 acknowledging at least one updated record 630 . Additionally, the record header 730 includes a record number in a record number field 731 that indicates the record that was updated (eg, record 630) and a sequence number field 733 that identifies the update contained in the updated record (eg, record 630). , including the record number in the .

図8は、完全リストLRPDUメッセージ413、418及び/又は421を実装してもよい完全リストLRPDUメッセージ800の例示的な符号化を示す。したがって、完全リストLRPDUメッセージ800は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300におけるデータベース対の同期を維持するために使用されてもよい。完全リストLRPDUメッセージ800は、それぞれタイプフィールド501及び長さフィールド503と同様のタイプフィールド801及び長さフィールド803を含む。タイプフィールド801は、完全リストLRPDUメッセージ800(例えば、typeCompleteListLRPDU)を示すために4の値を含んでもよく、長さフィールド803は、完全リストLRPDUメッセージ800の長さを含む。 FIG. 8 shows an exemplary encoding of a complete list LRPDU message 800 that may implement complete list LRPDU messages 413, 418 and/or 421. FIG. Thus, complete list LRPDU message 800 is used to maintain database pair synchronization in native system 110 and/or 130, proxy 210 and/or 230, slave 240 and/or 250, and/or database system 300. good too. Complete list LRPDU message 800 includes type field 801 and length field 803 similar to type field 501 and length field 503, respectively. The type field 801 may contain a value of 4 to indicate a complete list LRPDU message 800 (eg, typeCompleteListLRPDU) and the length field 803 contains the length of the complete list LRPDU message 800.

完全リストLRPDUメッセージ800のデータフィールドの最初の2オクテットは、送信ポータルのシャーシID、ポートID及びappIdを符号化するマイポータル番号フィールド809である。これは、同じポータルについてハローLRPDUメッセージ500で送信される同じ値である。これに続いて、先頭レコード番号フィールド823及び最終レコード番号フィールド825があり、これらは、それぞれ4オクテットの長さであり、この完全リストLRPDUメッセージ800に含まれるそれぞれ最低のレコード番号値及び最高のレコード番号値を含む。例えば、先頭レコード番号フィールド823及び最終レコード番号フィールド825は、それぞれ登録側に記憶された最初のレコード及び最後のレコードを含む。 The first two octets of the data field of the Complete List LRPDU message 800 are the My Portal Number field 809 which encodes the sending portal's chassis ID, port ID and appId. This is the same value sent in the Hello LRPDU message 500 for the same portal. Following this are the first record number field 823 and the last record number field 825, each four octets long, representing the lowest and highest record number values, respectively, contained in this complete list LRPDU message 800. Contains a number value. For example, first record number field 823 and last record number field 825 contain the first record and last record, respectively, stored at the registry.

これに続いて、レコードヘッダ730と実質的に同様の0以上のレコードヘッダ830がある。しかし、レコードヘッダ830は、承認済みの更新されたレコードのレコードヘッダのみとは対照的に、登録側データベースにおける全てのレコードヘッダを含む。各レコードヘッダ830は、それぞれレコード番号フィールド731、シーケンス番号フィールド733及びチェックサムフィールド735と実質的に同様のレコード番号フィールド831、シーケンス番号フィールド833及びチェックサムフィールド835を含む。 Following this are zero or more record headers 830 substantially similar to record header 730 . However, record headers 830 include all record headers in the registering database, as opposed to only the record headers of approved updated records. Each record header 830 includes a record number field 831, a sequence number field 833 and a checksum field 835 substantially similar to record number field 731, sequence number field 733 and checksum field 735, respectively.

完全リストLRPDUメッセージ800で送信される各レコード番号831は、先頭レコード番号フィールド823の値以上且つ最終レコード番号フィールド825の値以下の値を含む。先頭レコード番号フィールド823及び最終レコード番号フィールド825は、登録側に既知のレコードの完全なリストが1つより多くの完全リストLRPDUメッセージ800の間で分割されることを可能にする。完全リストLRPDUメッセージ800の全ての先頭及び最終レコード番号の対は、0から4,294,967,295までの全ての可能なレコード番号にわたることができるレコードの完全なリストを含む。 Each record number 831 sent in complete list LRPDU message 800 contains a value greater than or equal to the value of first record number field 823 and less than or equal to the value of last record number field 825 . The first record number field 823 and last record number field 825 allow the complete list of records known to the registrant to be split among more than one complete list LRPDU message 800 . Every first and last record number pair in the complete list LRPDU message 800 contains a complete list of records that can span all possible record numbers from 0 to 4,294,967,295.

図9は、例えば、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300においてデータベース対を確立する例示的な方法900のフローチャートである。方法900は、ハローLRPDUメッセージ401、403及び/又は500のような方法400からのシグナリングを使用する。方法900について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。 FIG. 9 is a flowchart of an exemplary method 900 for establishing a database pair in native systems 110 and/or 130, proxies 210 and/or 230, slaves 240 and/or 250, and/or database system 300, for example. Method 900 uses signaling from method 400 such as hello LRPDU messages 401 , 403 and/or 500 . Method 900 is described from the perspective of the local node operating the applicant database for clarity of explanation, but may be wholly or partially on the node (e.g., local node or adjacent node) operating the registrar. may be operated.

方法900は、ローカルノードが隣接ノードとの同期のためにデータベース対を確立することを望むときに始まる。ブロック901において、ハローメッセージがローカルノードにおいて受信される。ハローメッセージは、AppIdと、ローカルノードのターゲットポートと隣接ノードのターゲットポートの間のターゲットリンクとを含む。ローカルノードがネイティブシステムであるとき、ターゲットポートはローカルノードに配置される。ローカルノードがプロキシであるとき、ターゲットポートはスレーブに配置される。ハローメッセージは、ハローLRPDUメッセージ401、403及び/又は500のようなハローLRPDUメッセージとすることができる。さらに、ハローLRPDUメッセージは、ローカルノード又は対応するスレーブノードを識別するマイシャーシID、ローカルノード又は対応するスレーブノード上のターゲットポートを識別するマイポートID、隣接ノード又は対応するスレーブノードを識別する隣接シャーシID、及び隣接ノード又は対応するスレーブノード上のターゲットポートを識別する隣接ポートIDとして、ターゲットリンクを表すことができる。ハロー交換を完了するために、対応するハローメッセージもまた、ローカルノードから隣接ノードに送信される。このようなハローメッセージは、ローカルノードで受信したハローメッセージと実質的に同様でもよいが、異なるマイポータル番号を有する。例えば、ローカルノードから送信されるハローメッセージは、ローカルノードに関連するマイポータル番号を含み、ローカルノードで受信されるハローメッセージは、隣接ノードに関連するマイポータル番号を含む。このようなメッセージは、いずれかの順序で送信されてもよい。 Method 900 begins when a local node wishes to establish a database pair for synchronization with neighboring nodes. At block 901, a hello message is received at a local node. The hello message contains the AppId and the target link between the local node's target port and the neighboring node's target port. When the local node is the native system, the target port is located on the local node. When the local node is a proxy, the target port is placed on the slave. A hello message may be a hello LRPDU message, such as hello LRPDU messages 401 , 403 and/or 500 . In addition, the Hello LRPDU message contains a My Chassis ID that identifies the local node or a corresponding slave node, a My Port ID that identifies a target port on the local node or the corresponding slave node, a Neighbor ID that identifies the adjacent node or the corresponding slave node. A target link can be represented as a chassis ID and a neighbor port ID that identifies the target port on the neighbor node or the corresponding slave node. A corresponding hello message is also sent from the local node to the neighboring node to complete the hello exchange. Such hello messages may be substantially similar to hello messages received at the local node, but with a different My Portal number. For example, hello messages sent from the local node include My Portal numbers associated with the local node, and hello messages received at the local node include My Portal numbers associated with neighboring nodes. Such messages may be sent in any order.

ブロック903において、ローカルノード及び/又は対応するポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。AppIdがデータベース同期に関連付けられるという決定に基づいて、ブロック905において、ローカルデータベースがローカルノードのメモリに設定される。ローカルデータベースは、アプリケーションによる使用のためのデータベース対の一部である。データベース対は、隣接ノードでの(例えば、隣接ノードのポータルによる)隣接データベース設定を含む。いくつかの例では、ローカルデータベースは、隣接データベース内の登録側データベースへの送信のために、ローカルレコードを記憶するための申請側データベースを含むことができる。いくつかの例では、ローカルデータベースは、隣接データベース内の申請側データベースから隣接レコードを受信するための登録側データベースを含む。いくつかの例では、ローカルデータベースは、申請側データベース及び登録側データベースの双方を含む。 At block 903, the local node and/or corresponding portal determines that the AppId is associated with the application for performing database synchronization. Based on the determination that the AppId is associated with database synchronization, at block 905 a local database is set up in the local node's memory. A local database is part of a database pair for use by an application. A database pair includes adjacent database settings (eg, by the adjacent node's portal) at the adjacent node. In some examples, a local database may include an applicant database for storing local records for transmission to a registration database in a neighboring database. In some examples, the local database includes a registration database for receiving adjacent records from applicant databases in the adjacent database. In some examples, the local database includes both the applicant database and the enrollment database.

ブロック907において、データベース対は、(例えば、ネイティブシステムにおいて及び/又はプロキシへのスレーブにおいて)ターゲットリンクに関連付けられる。ポータルがターゲットポートと共にローカルノード上にあるため、或いは、ポータルを含み且つローカルノードで動作するプロキシにこのようなメッセージを転送するように構成されたスレーブ上にターゲットポートがあるため、このような関連付けは、申請側/登録側に転送されたLRPDUメッセージが正しいポータルに到達することを確保する。 At block 907, a database pair is associated with the target link (eg, in the native system and/or slave to the proxy). Such an association either because the portal is on the local node with the target port, or because the target port is on a slave that contains the portal and is configured to forward such messages to a proxy running on the local node. ensures that LRPDU messages forwarded to the applicant/registrant reach the correct portal.

ブロック909において、ローカルノード/ポータルは、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期の制御/管理を開始する。このような制御は、LRPDUメッセージ内のターゲットリンクを介して、レコード情報を隣接データベースに送信することにより発生する可能性がある。このようなレコード情報は、レコード、レコードヘッダ又はこれらの組み合わせを含んでもよい。例えば、このようなLRPDUメッセージは、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完全リストLRPDUメッセージ800及び/又は方法400からのいずれかのLRPDUメッセージを更に含んでもよい。 At block 909, the local node/portal begins controlling/managing synchronization of the local database with neighboring databases via the target link. Such control may occur by sending record information to the neighbor database via the target link in LRPDU messages. Such record information may include records, record headers, or combinations thereof. For example, such LRPDU messages may further include hello LRPDU message 500, record LRPDU message 600, partial list LRPDU message 700, complete list LRPDU message 800 and/or any LRPDU message from method 400.

図10は、例えば、方法900の完了のときにデータベース対の同期を管理する例示的な方法1000のフローチャートである。方法1000は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300上で動作されてもよい。方法1000は、方法400からのシグナリングを使用する。さらに、方法1000は、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完全リストLRPDUメッセージ800及び/又はこれらの組み合わせのようなLRPDUメッセージを使用してもよい。方法1000について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。 FIG. 10 is a flowchart of an exemplary method 1000 for managing database pair synchronization upon completion of method 900, for example. Method 1000 may operate on native systems 110 and/or 130, proxies 210 and/or 230, slaves 240 and/or 250, and/or database system 300. Method 1000 uses signaling from method 400 . Additionally, method 1000 may use LRPDU messages such as hello LRPDU message 500, record LRPDU message 600, partial list LRPDU message 700, complete list LRPDU message 800, and/or combinations thereof. Method 1000 is described in terms of the local node operating the applicant database for clarity of explanation, but may be wholly or partially on the node (e.g., local node or adjacent node) operating the registrar. may be operated.

ブロック1001において、アプリケーションは、申請側データベースにおいて1つ以上のレコードを変更する。したがって、ローカルノードのポータルは、例えば、隣接ポータルを介して、1つ以上のレコードLRPDUメッセージを隣接ノードの登録側データベースに送信する。レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示し、また、このような更新されたレコードを含んでもよい。例えば、レコードLRPDUメッセージは、申請側データベースで更新されたレコードを示す1つ以上のレコード番号と、申請側データベースで更新されたレコードに含まれる更新を識別する1つ以上のシーケンス番号とを含んでもよい。更新されたレコードはまた、申請側のデータベースにおいて未承認としてマーキングされることもできる。 At block 1001, the application modifies one or more records in the applicant database. Thus, the local node's portal sends one or more record LRPDU messages to the neighboring node's registrar database, eg, via the neighboring portal. Record LRPDU messages indicate updates to records stored in the local node's requesting database and may also include such updated records. For example, a record LRPDU message may contain one or more record numbers that indicate the records that were updated in the requesting database, and one or more sequence numbers that identify the updates contained in the updated records in the requesting database. good. The updated record can also be marked as unapproved in the applicant's database.

ブロック1003において、ポータルは、ブロック1001のレコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信する。いくつかの例では、レコードLRPDUメッセージを承認するLRPDUメッセージは、部分リストLRPDUメッセージを含む。部分リストLRPDUメッセージは、ブロック1001の少なくとも1つの更新されたレコードを承認する少なくとも1つのレコードヘッダを含む。少なくとも1つのレコードヘッダは、ブロック1001の更新されたレコードを示すレコード番号と、ブロック1001の更新されたレコードに含まれる更新を識別するシーケンス番号とを含む。いくつかの例では、レコードLRPDUメッセージを承認するLRPDUメッセージは、完全リストLRPDUメッセージを含むことができる。完全リストLRPDUメッセージは、登録側データベースにおける全てのレコードのレコードヘッダを含む。さらに、完全リストLRPDUメッセージは、登録側データベースに記憶された最初のレコードを示す先頭レコード番号フィールドと、登録側データベースに記憶された最後のレコードを示す最終レコード番号フィールドとを含む。また、レコードヘッダは、登録側データベースに記憶されたレコードを示すレコード番号と、登録側データベースに記憶されたレコードに含まれる更新を識別するシーケンス番号とを含む。 At block 1003 the portal receives one or more LRPDU messages that acknowledge the record LRPDU message of block 1001 . In some examples, an LRPDU message acknowledging a record LRPDU message includes a partial list LRPDU message. The partial list LRPDU message includes at least one record header acknowledging at least one updated record of block 1001 . At least one record header includes a record number indicating an updated record of block 1001 and a sequence number identifying updates contained in the updated record of block 1001 . In some examples, an LRPDU message acknowledging a Record LRPDU message can include a Complete List LRPDU message. The Complete List LRPDU message contains record headers for all records in the subscriber database. Additionally, the Complete List LRPDU message includes a First Record Number field that indicates the first record stored in the registrant database and a Last Record Number field that indicates the last record stored in the registrant database. The record header also includes a record number indicating the record stored in the registration database and a sequence number identifying the update contained in the record stored in the registration database.

ブロック1005において、少なくとも1つの更新されたレコードは、ブロック1003の部分リスト及び/又は完全リストLRPDUメッセージのレコードヘッダに基づいて、登録側データベースによる承認済みとして、申請側データベースにおいてマーキングされる。 At block 1005 , at least one updated record is marked in the applicant database as approved by the registrant database based on the record headers of the partial list and/or full list LRPDU message of block 1003 .

ブロック1007において、ポータル/申請側は、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたと決定してもよい。申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたというブロック1007の決定に基づいて、ブロック1009において、ポータル/申請側は、申請側データベースが登録側データベースと同期していることをアプリケーションに通知する。 At block 1007, the portal/applicant may determine that all updated records in the applicant database have been approved by the registrant database via LRPDU messages. Based on the determination in block 1007 that all updated records in the applicant database have been acknowledged by the registrant database via LRPDU messages, at block 1009 the portal/applicant confirms that the applicant database is the registrant database. Notifies the application that it is synchronizing with

いくつかの場合、レコードLRPDUメッセージは、登録側に到達しない可能性があり、及び/又は、部分リストLRPDUメッセージが申請側に戻る途中で欠落する可能性がある。このような場合、任意選択のブロック1011において、ポータルは、対応する部分リストLRPDUメッセージを受信することなく、レコードLRPDUメッセージタイマが終了したとき、アプリケーションへの障害通知を生成する。 In some cases, the record LRPDU message may never reach the registrant and/or the partial list LRPDU message may be lost on the way back to the applicant. In such a case, at optional block 1011, the portal generates a failure notification to the application when the record LRPDU message timer expires without receiving a corresponding partial list LRPDU message.

ブロック1013もまた任意選択である。いくつかの例では、ポータル/申請側は、要求完全リストLRPDUメッセージを登録側データベースに送信するように構成できる。登録側/隣接ポータルは、完全リストLRPDUメッセージで応答する。したがって、ローカルノード上のポータル/申請側は、要求完全リストLRPDUメッセージに応じて、登録側データベースから完全リストLRPDUメッセージを受信する。 Block 1013 is also optional. In some examples, the Portal/Applicant can be configured to send Request Complete List LRPDU messages to the Registrant database. The registrant/neighbor Portal responds with a Complete List LRPDU message. Thus, the portal/applicant on the local node receives a complete list LRPDU message from the registrant database in response to the request complete list LRPDU message.

図11は、例えば、方法900の後且つ方法1000の間/後に、接続中断にもかかわらずデータベース同期を維持する例示的な方法1100のフローチャートである。方法1100は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300上で動作されてもよい。方法1100は、方法400からのシグナリングを使用する。さらに、方法1100は、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完全リストLRPDUメッセージ800及び/又はこれらの組み合わせのようなLRPDUメッセージを使用してもよい。方法1100について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。 FIG. 11 is a flow chart of an exemplary method 1100 of maintaining database synchronization despite connection interruptions, eg, after method 900 and during/after method 1000 . Method 1100 may operate on native systems 110 and/or 130, proxies 210 and/or 230, slaves 240 and/or 250, and/or database system 300. Method 1100 uses signaling from method 400 . Additionally, method 1100 may use LRPDU messages such as hello LRPDU message 500, record LRPDU message 600, partial list LRPDU message 700, complete list LRPDU message 800, and/or combinations thereof. Method 1100 is described in terms of the local node operating the applicant database for clarity of explanation, but may be wholly or partially on the node (e.g., local node or adjacent node) operating the registrar. may be operated.

方法1100は、ハローLRPDUメッセージの交換が失敗したときに始まり、これは接続中断を示す。ブロック1101において、切断コードがアプリケーションについて生成される。切断コードは、ハローLRPDUメッセージの交換が失敗したことを示す。これはまた、隣接ノード/登録側への更なるメッセージが受信されない可能性があり、前の未承認のメッセージが登録側に到達していない可能性があることを示す。 Method 1100 begins when the exchange of Hello LRPDU messages fails, indicating a connection disruption. At block 1101, a disconnect code is generated for the application. A disconnect code indicates that the exchange of Hello LRPDU messages has failed. This also indicates that further messages to the neighbor/registrant may not be received and previous unacknowledged messages may not have reached the registrant.

申請側は、接続の再確立のときにデータベース対をリセットすることを決定できる。このような場合、方法900が使用される。しかし、申請側はまた、接続が再確立されたとき、現在の申請側データベースを登録側データベースと再同期させることを決定してもよい。このような場合、ブロック1103において、ポータルは、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信する。 The applicant can decide to reset the database pair upon re-establishment of the connection. In such cases, method 900 is used. However, the applicant may also decide to resynchronize the current applicant database with the enrollment 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 applicant database in the local node's memory despite the disconnect code.

ブロック1105において、ポータルは、ハローメッセージの失敗した交換の後に、申請側データベースにおいて通知タイマをリセットする。これは、接続が再確立された後に、完全リストLRPDUメッセージが受信されるまで、レコードLRPDUメッセージの送信を防止する。 At block 1105, the portal resets the notification timer at the applicant database after the failed exchange of hello messages. This prevents transmission of record LRPDU messages until a complete list LRPDU message is received after the connection is re-established.

ハローLRPDUメッセージは、接続を再確立することを試みて、周期的に送信できる。登録側データベースが切断の後にハローLRPDUメッセージを受信したとき、登録側は、完全リストLRPDUメッセージで応答する。したがって、ブロック1107において、隣接ノードの登録側データベースからの完全リストLRPDUメッセージは、ハローLRPDUメッセージの成功した交換の後に、申請側/ポータルにより受信される。完全リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。 A Hello LRPDU message can be sent periodically in an attempt to re-establish the connection. When the registrant database receives a Hello LRPDU message after disconnection, the registrant responds with a Complete List LRPDU message. Thus, at block 1107, the Complete List LRPDU message from the neighbor's registrant database is received by the applicant/portal after the successful exchange of the Hello LRPDU message. The Complete List LRPDU message contains record headers for all records in the subscriber database.

ブロック1109において、ポータル/申請側は、申請側データベースを登録側データベースと再同期させるために、完全リストLRPDUメッセージからのレコードヘッダを申請側データベースに記憶されたレコードヘッダと比較する。具体的には、ブロック1111において、ポータル/アプリケーションは、完全リストLRPDUメッセージ内のレコードヘッダと申請側データベース内のレコードヘッダとの間にレコードの不一致が存在するか否かを決定する。 At block 1109, the Portal/Applicant compares the record headers from the Complete List LRPDU message with the record headers stored in the Applicant database to resynchronize the Applicant database with the Enrollment database. Specifically, at block 1111, the portal/application determines if there is a record mismatch between the record headers in the Complete List LRPDU message and the record headers in the applicant database.

ポータル/申請側が、申請側データベース内の1つ以上のレコードヘッダと完全リストLRPDUメッセージからの1つ以上のレコードヘッダとの間の不一致を決定したとき、方法1100はブロック1113に進む。不一致は、少なくとも1つの前のレコードLLRPDUメッセージが失われたことを示す。したがって、申請側は、どのレコード更新が完全リストLRPDUメッセージにおいて表されていないかを決定する。ブロック1113において、申請側/ポータルは、1つ以上のレコードLRPDUメッセージを登録側データベースに送信する。レコードLRPDUメッセージは、不一致に対処してデータベース対を同期させるために、必要に応じて更新されたレコードヘッダを含む。 The method 1100 proceeds to block 1113 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 complete list LRPDU message. A mismatch indicates that at least one previous record LLRPDU message was lost. Therefore, the applicant determines which record updates are not represented in the Complete List LRPDU message. At block 1113, the applicant/portal sends one or more record LRPDU messages to the registrant database. Record LRPDU messages contain updated record headers as needed to address discrepancies and synchronize database pairs.

ポータル/申請側が、申請側データベース内のレコードヘッダと登録側データベースからのレコードヘッダとの間に不一致が存在しないと決定したとき、方法1100はブロック1115に進む。不一致がないという決定に基づいて、ブロック1115において、ポータル/申請側は、申請側データベースが登録側データベースと同期していることをアプリケーションに通知できる。 The method 1100 proceeds to block 1115 when the portal/applicant side determines that there is no mismatch between the record headers in the requesting side database and the record headers from the registering side database. Based on the determination that there are no discrepancies, at block 1115 the Portal/Applicant can notify the application that the Applicant database is in sync with the Enrollment database.

図12は、当該開示の実施形態によるデータベース同期を管理するための例示的なネットワークノード1200の概略図である。ネットワークノード1200は、ここに記載されるような開示の例/実施形態を実装するのに適している。例えば、ネットワークノード1200は、ネイティブシステム110/130、プロキシ210/230、スレーブ240/250、これらの組み合わせ、及び/又はここに記載のいずれかのローカルノード及び/又は隣接ノードを実装するために使用されてもよい。例えば、ネットワークノード1200は、データベースシステム300を実装できる。 FIG. 12 is a schematic diagram of an exemplary network node 1200 for managing database synchronization according to embodiments of the disclosure. Network node 1200 is suitable for implementing examples/embodiments of the disclosure as described herein. For example, network node 1200 may be used to implement native systems 110/130, proxies 210/230, slaves 240/250, combinations thereof, and/or any local and/or adjacent nodes described herein. may be For example, network node 1200 may implement database system 300 .

ネットワークノード1200は、ダウンストリームポート1220、アップストリームポート1250、及び/又はネットワーク上でアップストリーム及び/又はダウンストリームにデータを通信するための送信機及び/又は受信機を含むトランシーバユニット(Tx/Rx)1210を含む。ネットワークノード1200はまた、データを処理するための論理ユニット及び/又は中央処理装置(central processing unit, CPU)を含むプロセッサ1230と、データを記憶するためのメモリ1232とを含む。ネットワークノード1200はまた、光又は無線通信ネットワークを介したデータの通信のために、アップストリームポート1250及び/又はダウンストリームポート1220に結合された光対電気(optical-to-electrical, OE)コンポーネント、電気対光(electrical-to-optical, EO)コンポーネント及び/又は無線通信コンポーネントを含んでもよい。ネットワークノード1200はまた、データをユーザに通信し且つユーザからデータを通信するための入力及び/又は出力(input and/or output, I/O)デバイスを含んでもよい。このようなI/Oデバイスは、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカ等のような出力デバイスを含んでもよい。I/Oデバイスはまた、キーボード、マウス、トラックボール等のような入力デバイス、及び/又はこのような出力デバイスと相互作用するための対応するインタフェースを含んでもよい。 Network node 1200 includes a downstream port 1220, an upstream port 1250, and/or a transceiver unit (Tx/Rx) that includes a transmitter and/or receiver for communicating data upstream and/or downstream over a network. ) 1210 included. Network node 1200 also includes processor 1230, which includes a logic unit and/or central processing unit (CPU) for processing data, and memory 1232 for storing data. Network node 1200 also includes optical-to-electrical (OE) components coupled to upstream port 1250 and/or downstream port 1220 for communication of data over an optical or wireless communication network; It may include electrical-to-optical (EO) components and/or wireless communication components. Network node 1200 may also include input and/or output (I/O) devices for communicating data to and from users. Such I/O devices may include output devices such as displays for displaying video data, speakers for outputting audio data, and the like. I/O devices may also include input devices such as keyboards, mice, trackballs, etc., and/or corresponding interfaces for interacting with such output devices.

プロセッサ1230は、ハードウェア及びソフトウェアにより実装される。プロセッサ1230は、1つ以上のCPUチップ、(例えば、マルチコアプロセッサとしての)コア、フィールドプログラマブルゲートアレイ(field-programmable gate array, FPGA)、特定用途向け集積回路(application specific integrated circuit, ASIC)及びデジタルシグナルプロセッサ(digital signal processor, DSP)として実装されてもよい。プロセッサ1230は、ダウンストリームポート1220、Tx/Rx1210、アップストリームポート1250及びメモリ1232と通信する。プロセッサ1230は、LRP-DSモジュール1214を含む。LRP-DSモジュール1214は、方法400、900、1000、1100及び/又はここに記載のいずれかの他の方法/メカニズムのような、上記の開示の実施形態を実装する。さらに、LRP-DSモジュール1214は、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完全リストLRPDUメッセージ800及び/又はこれらの組み合わせのようなLLPDUメッセージを送信、受信及び/又は処理してもよい。例えば、LRP-DSモジュール1214は、ハローLRPDUメッセージを介して接続を確立し、同期のためにデータベース対を設定するために使用できる。他の例として、LRP-DSモジュール1214は、申請側の全てのレコードが登録側により承認されたときにアプリケーションに通知するために、及び/又は、登録側がレコード更新を承認しなかったときにアプリケーションに通知するために使用できる。更に他の例として、LRP-DSモジュール1214は、レコードの全てを申請側から登録側に再送することなく、切断後にデータベース対を再同期させるために使用できる。したがって、LRP-DSモジュール1214は、ネットワークノード1200の機能を改良する。さらに、LRP-DSモジュール1214は、コンピュータ技術に特有のメモリ管理問題を解決する。また、LRP-DSモジュール1214は、異なる状態へのネットワークノード1200の変換もたらす。LRP-DSモジュール1214は、メモリ1232に記憶された命令として実装され、プロセッサ1230により(例えば、非一時的な媒体に記憶されたコンピュータプログラム製品として)実行できる。 Processor 1230 is implemented in hardware and software. Processor 1230 may include one or more CPU chips, cores (e.g., as a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital It may also be implemented as a digital signal processor (DSP). Processor 1230 communicates with downstream port 1220 , Tx/Rx 1210 , upstream port 1250 and memory 1232 . Processor 1230 includes LRP-DS module 1214 . The LRP-DS module 1214 implements embodiments of the above disclosure, such as methods 400, 900, 1000, 1100 and/or any other method/mechanism described herein. Additionally, the LRP-DS module 1214 may transmit, receive and/or process LLPDU messages such as hello LRPDU messages 500, record LRPDU messages 600, partial list LRPDU messages 700, complete list LRPDU messages 800 and/or combinations thereof. may For example, the LRP-DS module 1214 can be used to establish connections and set up database pairs for synchronization via Hello LRPDU messages. As another example, the LRP-DS module 1214 can be used to notify the application when all of the applicant's records have been approved by the registrant and/or to notify the application when the registrant has not approved the record update. can be used to notify As yet another example, the LRP-DS module 1214 can be used to resynchronize the database pair after disconnection without retransmitting all of the records from the applicant to the registrant. LRP-DS module 1214 thus improves the functionality of network node 1200 . Additionally, the LRP-DS module 1214 solves memory management problems inherent in computer technology. The LRP-DS module 1214 also effects the transformation of the network node 1200 to different states. The LRP-DS module 1214 may be implemented as instructions stored in memory 1232 and executed by processor 1230 (eg, as a computer program product stored on non-transitory media).

メモリ1232は、ディスク、テープドライブ、ソリッドステートドライブ、読み取り専用メモリ(read only memory, ROM)、ランダムアクセスメモリ(random access memory, RAM)、フラッシュメモリ、三値連想メモリ(ternary content-addressable memory, TCAM)、スタティックランダムアクセスメモリ(static random-access memory, SRAM)等のような1つ以上のメモリタイプを含む。メモリ1232は、プログラムが実行のために選択されたときにこのようなプログラムを記憶し、プログラム実行中に読み取られる命令及びデータを記憶するために、オーバーフローデータ記憶デバイスとして使用されてもよい。 Memory 1232 includes disks, tape drives, solid state drives, read only memory (ROM), random access memory (RAM), flash memory, ternary content-addressable memory (TCAM). ), static random-access memory (SRAM), etc. Memory 1232 may be used as an overflow data storage device to store programs when such programs are selected for execution, and to store instructions and data read during program execution.

図13は、データベース対を確立するための例示的なデバイス1300の概略図である。デバイス1300は、方法400及び/又は方法900を実装するために使用できる。デバイス1300は、AppIdと、ローカルノードと隣接ノードとの間のターゲットリンクとを含むハローメッセージを受信するための受信モジュール1301を含む。デバイス1300はまた、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するための決定モジュール1303を含む。デバイス1300はまた、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードにローカルデータベースを設定するためのデータベース対設定モジュール1305を含み、データベース対は隣接ノードの隣接データベースを含む。デバイス1300はまた、データベース対をターゲットリンクに関連付けるための関連付けモジュール1307を含む。デバイスはまた、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するための同期制御モジュール1309を含む。 FIG. 13 is a schematic diagram of an exemplary device 1300 for establishing database pairs. Device 1300 can be used to implement method 400 and/or method 900 . Device 1300 includes a receiving module 1301 for receiving a hello message containing an AppId and a target link between a local node and a neighboring node. Device 1300 also includes a determination module 1303 for determining that AppId is associated with an application for performing database synchronization. The device 1300 also includes a database pair configuration module 1305 for configuring a local database on the local node as part of a database pair for use by an application, the database pair including neighboring databases of neighboring nodes. Device 1300 also includes an association module 1307 for associating database pairs with target links. The device also includes a synchronization control module 1309 for controlling synchronization of the local database with neighboring databases over the target link.

図14は、データベース対の同期を管理するための例示的なデバイス1400の概略図である。デバイス1400は、方法400及び/又は方法1000を実装するために使用できる。デバイス1400は、1つ以上のレコードLRPDUメッセージを隣接ノードの登録側データベースに送信するための送信モジュール1401を含み、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す。デバイス1400はまた、レコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信するための受信モジュール1403を含む。デバイス1400はまた、登録側データベースによる承認済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリモジュール1405を含む。デバイス1400はまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたことを決定するための決定モジュール1407を含む。デバイス1400はまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知モジュール1409を含む。 FIG. 14 is a schematic diagram of an exemplary device 1400 for managing database pair synchronization. Device 1400 can be used to implement method 400 and/or method 1000 . Device 1400 includes a sending module 1401 for sending one or more record LRPDU messages to a neighboring node's registrant database, the record LRPDU messages indicating updates to records stored in the local node's applicant database. . Device 1400 also includes a receiving module 1403 for receiving one or more LRPDU messages acknowledging record LRPDU messages. Device 1400 also includes a memory module 1405 for marking at least one updated record in the applicant database as approved by the registrant database. Device 1400 also includes a determination module 1407 for determining that all updated records in the applicant database have been approved by the registrant database via LRPDU messages. The device 1400 also indicates to the application that the applicant database is in sync with the registrant database based on the determination that all updated records in the applicant database have been approved by the registrant database via LRPDU messages. includes a notification module 1409 for notifying the

図15は、接続中断にもかかわらずデータベース同期を維持するための例示的なデバイス1500の概略図である。デバイス1500は、方法400及び/又は方法1100を実装するために使用できる。デバイス1500は、アプリケーションのための切断コードを生成するための切断モジュール1501を含み、切断コードは、ハローLRPDUメッセージの交換が失敗したことを示す。デバイス1500はまた、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するためのコマンドモジュール1503を含む。デバイス1500はまた、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完全リストLRPDUメッセージを受信するための受信モジュール1505を含み、完全リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。デバイス1500はまた、申請側データベースを登録側データベースと再同期させるために、完全リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するためのレコード比較モジュール1507を含む。 FIG. 15 is a schematic diagram of an exemplary device 1500 for maintaining database synchronization despite connection interruptions. Device 1500 can be used to implement method 400 and/or method 1100 . Device 1500 includes a disconnect module 1501 for generating a disconnect code for an application, the disconnect code indicating that the exchange of hello LRPDU messages has failed. Device 1500 also includes a command module 1503 for receiving commands from an application to maintain the applicant database in memory of the local node despite the disconnect code. The device 1500 also includes a receiving module 1505 for receiving a complete list LRPDU message from the registrant database of the neighboring node after successful exchange of hello messages, the complete list LRPDU message for all records of the registrant database. Contains record headers. Device 1500 also includes a record comparison module 1507 for comparing record headers from the complete list LRPDU message with record headers in the applicant database to resynchronize the applicant database with the registrant database.

一実施形態では、ノード又はエレメントは、1つ以上のレコードリンクローカル登録プロトコルデータユニット(LRPDU)メッセージを隣接ノードの登録側データベースに送信するための送信手段であり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、送信手段と、レコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信するための受信手段とを含む。ノード又はエレメントは、登録側データベースによる承認済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリ手段を更に含む。ノード又はエレメントはまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたと決定するための決定手段と、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより承認されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知手段とを含む。 In one embodiment, a node or element is a sending means for sending one or more Record Link Local Registration Protocol Data Unit (LRPDU) messages to a neighboring node's registrar database, the Record LRPDU messages being sent to the local node's Sending means for indicating updates to records stored in the applicant database, and receiving means for receiving one or more LRPDU messages acknowledging the record LRPDU messages. The node or element further includes memory means for marking at least one updated record in the applicant database as approved by the applicant database. The node or element also has determining means for determining that all updated records in the requesting database have been approved by the registering database via LRPDU messages; and notification means for notifying the application that the applicant database is synchronizing with the registering database based on the determination that it has been approved by the registering database via the LRPDU message.

第1のコンポーネントと第2のコンポーネントとの間のライン、トレース又は他の媒体を除いて、介在するコンポーネントが存在しないとき、第1のコンポーネントは第2のコンポーネントに直接的に結合される。第1のコンポーネントと第2のコンポーネントとの間にライン、トレース又は他の媒体以外の介在するコンポーネントが存在するとき、第1のコンポーネントは第2のコンポーネントに間接的に結合される。用語「結合される」及びその変形は、直接的に結合されること及び間接的に結合されることの双方を含む。用語「約」の使用は、別段の指定のない限り、以降の数の±10%を含む範囲を意味する。 A first component is directly coupled to a second component when there are no intervening components other than lines, traces or other medium between the first and second components. A first component is indirectly coupled to a second component when there are intervening components other than lines, traces, or other media between the first component and the second component. The term "coupled" and variations thereof includes both directly and indirectly coupled. Use of the term "about" means a range including ±10% of the following number, unless otherwise specified.

いくつかの実施形態が本開示において提供されているが、開示のシステム及び方法は、本開示の真意又は範囲から逸脱することなく、多くの他の具体的な形式で実現されてもよいことが理解され得る。本例は、例示的なものであり、限定的なものではないと考えられるべきであり、その意図は、ここに与えられる詳細に限定されるものではない。例えば、様々なエレメント又はコンポーネントは、他のシステムに組み合わされても或いは統合されてもよく、或いは、特定の特徴が省略されても或いは実装されなくてもよい。 Although several embodiments are provided in this disclosure, it is understood that the disclosed systems and methods may be embodied in many other specific forms without departing from the spirit or scope of this disclosure. can be understood. The examples are to be considered illustrative and not restrictive, and the intent is not to be limited to the details given herein. For example, various elements or components may be combined or integrated into other systems, or certain features may be omitted or not implemented.

さらに、様々な実施形態において個別のもの又は別個のものとして記載及び図示された技術、システム、サブシステム及び方法は、本開示の範囲から逸脱することなく、他のシステム、コンポーネント、技術又は方法と組み合わされても或いは統合されてもよい。変更、置換及び代替の他の例は、当業者により確かめられることができ、ここに開示された真意及び範囲から逸脱することなく行われてもよい。 Furthermore, techniques, systems, subsystems and methods described and illustrated as separate or separate in various embodiments may be combined with other systems, components, techniques or methods without departing from the scope of the present disclosure. may be combined or integrated. Other examples of modifications, substitutions and alternatives can be ascertained by those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims (10)

ローカルノードにおいて実装される方法であって、
前記ローカルノードの受信機において、アプリケーション識別子(AppId)と、ローカルノードのターゲットポートと隣接ノードのターゲットポートとの間のターゲットリンクとを含むハローメッセージを受信するステップと、
前記ローカルノードのプロセッサにより、前記AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するステップと、
前記アプリケーションによる使用のためにデータベース対の一部として、前記ローカルノードのメモリにローカルデータベースを設定するステップであり、前記データベース対は前記隣接ノードの隣接データベースを含む、ステップと、
前記プロセッサにより、前記データベース対を前記ターゲットリンクに関連付けるステップと、
前記ターゲットリンクを介して、前記隣接データベースとの前記ローカルデータベースの同期を制御するステップと
を含む方法。
A method implemented at a local node, comprising:
receiving, at the receiver of the local node, a hello message containing an application identifier (AppId) and a target link between a target port of the local node and a target port of a neighboring node;
determining, by the processor of the local node, that the AppId is associated with an application for performing database synchronization;
setting up a local database in the memory of the local node as part of a database pair for use by the application, the database pair comprising a neighboring database of the neighboring node;
associating, by the processor, the database pair with the target link;
and controlling synchronization of said local database with said neighboring database over said target link.
前記隣接データベースとの前記ローカルデータベースの同期を制御するステップは、前記ローカルノードの送信機により、リンクローカル登録プロトコルデータユニット(LRPDU)メッセージにおいて前記ターゲットリンクを介してレコード情報を前記隣接データベースに送信するステップを含む、請求項1に記載の方法。 Controlling synchronization of the local database with the neighbor database includes transmitting record information to the neighbor database over the target link in link-local registration protocol data unit (LRPDU) messages by the transmitter of the local node. 2. The method of claim 1, comprising steps. 前記ローカルデータベースは、前記隣接データベース内の登録側データベースへの送信のために、ローカルレコードを記憶するための申請側データベースを含む、請求項1乃至2のうちいずれか1項に記載の方法。 3. The method of any one of claims 1-2, wherein the local database includes an applicant database for storing local records for transmission to a registration database in the adjacent database. 前記ローカルデータベースは、前記隣接データベース内の申請側データベースから隣接レコードを受信するための登録側データベースを含む、請求項1乃至3のうちいずれか1項に記載の方法。 4. The method of any one of claims 1-3, wherein the local database comprises a registration database for receiving neighbor records from an applicant database in the neighbor database. 前記ハローメッセージはハローLRPDUであり、前記ハローLRPDUは、前記ローカルノードを識別するマイシャーシ識別子(ID)、前記ローカルノード上のターゲットポートを識別するマイポートID、前記隣接ノードを識別する隣接シャーシID、及び前記隣接ノード上のターゲットポートを識別する隣接ポートIDとして、前記ターゲットリンクを表す、請求項1乃至4のうちいずれか1項に記載の方法。 The hello message is a hello LRPDU, and the hello LRPDU includes a my chassis identifier (ID) that identifies the local node, a my port ID that identifies a target port on the local node, and a neighbor chassis ID that identifies the adjacent node. , and a neighboring port ID identifying a target port on the neighboring node. 記ローカルノードの送信機により、1つ以上のレコードリンクローカル登録プロトコルデータユニット(LRPDU)メッセージを前記隣接ノードの登録側データベースに送信するステップであり、前記レコードLRPDUメッセージは、前記ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、ステップと、
前記ローカルノードの受信機により、前記レコードLRPDUメッセージを承認する1つ以上のLRPDUメッセージを受信するステップと、
前記ローカルノードのメモリにおいて、前記登録側データベースによる承認済みとして、前記申請側データベース内の少なくとも1つの更新されたレコードをマーキングするステップと、
前記プロセッサを介して、前記申請側データベースが前記登録側データベースと同期していることをアプリケーションに通知するステップと
更に含む、請求項1に記載の方法。
sending, by a transmitter of the local node, one or more Record Link Local Registration Protocol Data Unit (LRPDU) messages to a registrar database of the neighboring node, wherein the Record LRPDU messages correspond to the local node's application indicating an update to a record stored in a side database;
receiving, by a receiver of the local node, one or more LRPDU messages acknowledging the record LRPDU message;
marking in the memory of the local node at least one updated record in the applicant database as approved by the registrant database;
2. The method of claim 1, further comprising : notifying an application, via the processor, that the requesting database is in sync with the registering database.
記ローカルノードの前記プロセッサにより、アプリケーションのための切断コードを生成するステップであり、前記切断コードは、ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの交換が失敗したことを示す、ステップと、
前記プロセッサにおいて、前記アプリケーションから、前記切断コードにもかかわらず前記ローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するステップと、
前記ローカルノードの前記受信機により、ハローLRPDUメッセージの成功した交換の後に、隣接ノードの登録側データベースから完全リストLRPDUメッセージを受信するステップであり、前記完全リストLRPDUメッセージは、前記登録側データベースの全てのレコードのレコードヘッダを含む、ステップと、
前記プロセッサにより、前記申請側データベースを前記登録側データベースと再同期させるために、前記完全リストLRPDUメッセージからの前記レコードヘッダを前記申請側データベース内のレコードヘッダと比較するステップと
更に含む、請求項1に記載の方法。
generating, by the processor of the local node, a disconnect code for an application, the disconnect code indicating a hello link local registration protocol data unit (LRPDU) message exchange failure;
receiving, at the processor, a command from the application to maintain an applicant database in memory of the local node despite the disconnect code;
receiving, by the receiver of the local node, a Complete List LRPDU message from a registrant database of a neighboring node after a successful exchange of Hello LRPDU messages, wherein the Complete List LRPDU message contains all of the registrant databases; a step including record headers for the records of
comparing, by the processor, the record headers from the complete list LRPDU messages to record headers in the applicant database to resynchronize the applicant database with the registrant database. 1. The method according to 1.
メモリと、送信機と、受信機と、前記メモリ、前記送信機、前記受信機に結合されたプロセッサとを含むローカルノードであって、
前記ローカルノードは、請求項1乃至のうちいずれか1項に記載の方法を実行するように構成される、ローカルノード。
A local node comprising a memory, a transmitter, a receiver, and a processor coupled to the memory, the transmitter and the receiver,
A local node, wherein the local node is configured to perform the method according to any one of claims 1-7 .
ローカルノードによる使用のためのコンピュータプログラム製品を含む非一時的なコンピュータ読み取り可能記憶媒体であって、
前記コンピュータプログラム製品は、プロセッサにより実行されたとき、前記ローカルノードに請求項1乃至のうちいずれか1項に記載の方法を実行させるように、前記非一時的なコンピュータ読み取り可能記憶媒体に記憶されたコンピュータ実行可能命令を含む、非一時的なコンピュータ読み取り可能記憶媒体。
A non-transitory computer-readable storage medium containing a computer program product for use by a local node,
The computer program product is stored on the non-transitory computer readable storage medium so as to cause the local node to perform the method of any one of claims 1 to 7 when executed by a processor. A non-transitory computer-readable storage medium containing computer-executable instructions.
ローカルノードであって、
アプリケーション識別子(AppId)と、ローカルノードと隣接ノードとの間のターゲットリンクとを含むハローメッセージを受信するための受信手段と、
前記AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するための決定手段と、
前記アプリケーションによる使用のためにデータベース対の一部として、前記ローカルノードにローカルデータベースを設定するためのデータベース対設定手段であり、前記データベース対は前記隣接ノードの隣接データベースを含む、データベース対設定手段と、
前記データベース対を前記ターゲットリンクに関連付けるための関連付け手段と、
前記ターゲットリンクを介して、前記隣接データベースとの前記ローカルデータベースの同期を制御するための同期制御手段と
を含むローカルノード。
the local node and
receiving means for receiving a hello message including an application identifier (AppId) and a target link between a local node and a neighboring node;
determining means for determining that the AppId is associated with an application for performing database synchronization;
database pair setting means for setting up a local database on said local node as part of a database pair for use by said application, said database pair comprising a neighboring database of said neighboring node; ,
association means for associating said database pair with said target link;
synchronization control means for controlling synchronization of said local database with said neighboring database over said target link.
JP2020555332A 2018-04-10 2019-04-06 Point-to-point database synchronization over transport protocol Active JP7128288B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2022130560A JP2022172168A (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocol
JP2022130561A JP7479427B2 (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocols

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862655625P 2018-04-10 2018-04-10
US62/655,625 2018-04-10
US201862782993P 2018-12-20 2018-12-20
US62/782,993 2018-12-20
PCT/CN2019/081640 WO2019196760A1 (en) 2018-04-10 2019-04-06 Point-to-point database synchronization over a transport protocol

Related Child Applications (2)

Application Number Title Priority Date Filing Date
JP2022130560A Division JP2022172168A (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocol
JP2022130561A Division JP7479427B2 (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocols

Publications (2)

Publication Number Publication Date
JP2021520554A JP2021520554A (en) 2021-08-19
JP7128288B2 true JP7128288B2 (en) 2022-08-30

Family

ID=68163912

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2020555332A Active JP7128288B2 (en) 2018-04-10 2019-04-06 Point-to-point database synchronization over transport protocol
JP2022130560A Pending JP2022172168A (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocol
JP2022130561A Active JP7479427B2 (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocols

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2022130560A Pending JP2022172168A (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocol
JP2022130561A Active JP7479427B2 (en) 2018-04-10 2022-08-18 Point-to-point database synchronization over transport protocols

Country Status (10)

Country Link
US (2) US11805193B2 (en)
EP (1) EP3776933A4 (en)
JP (3) JP7128288B2 (en)
CN (1) CN111937327A (en)
AU (1) AU2019251120B9 (en)
BR (1) BR112020020799A2 (en)
CA (3) CA3096411A1 (en)
MX (1) MX2020010658A (en)
SG (1) SG11202009781SA (en)
WO (1) WO2019196760A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112260923B (en) * 2019-07-22 2023-05-02 中兴通讯股份有限公司 Bridge network information notification method and device
CN113259182B (en) * 2021-07-02 2021-09-24 北京华云安信息技术有限公司 Communication path monitoring method and device based on autonomous decision

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049517A (en) 2000-05-25 2002-02-15 Hitachi Ltd Storage system
US20100228866A1 (en) 2008-02-18 2010-09-09 Kepeng Li Method for synchronizing data, system, and apparatus thereof

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428645A (en) * 1992-11-03 1995-06-27 International Business Machines Corporation Anonymous time synchronization method
US6477543B1 (en) * 1998-10-23 2002-11-05 International Business Machines Corporation Method, apparatus and program storage device for a client and adaptive synchronization and transformation server
KR100471567B1 (en) * 2000-07-29 2005-03-07 엘지전자 주식회사 Transaction Management Method For Data Synchronous In Dual System Environment
US6606694B2 (en) * 2000-12-22 2003-08-12 Bull Hn Information Systems Inc. Write logging in mirrored disk subsystems
US7707175B1 (en) * 2002-05-02 2010-04-27 Palmsource Inc. Single ended synchronization agents
US7515600B1 (en) * 2003-01-28 2009-04-07 Cisco Technology, Inc. Synchronizing portions of a database with different databases on different nodes of a network
US8009696B2 (en) * 2004-08-06 2011-08-30 Ipeak Networks Incorporated System and method for achieving accelerated throughput
US7542432B2 (en) * 2005-10-27 2009-06-02 Alcatel Lucent Resource matched topology database synchronization in communications networks having topology state routing protocols
CN101425961B (en) * 2007-10-31 2012-04-04 华为技术有限公司 Method for implementing link state database synchronization, router, circuit board and main control board
US20100174863A1 (en) * 2007-11-30 2010-07-08 Yahoo! Inc. System for providing scalable in-memory caching for a distributed database
JP2009163640A (en) * 2008-01-09 2009-07-23 Ricoh Co Ltd Information providing device, information providing method, program, and recording medium
JP2011034175A (en) * 2009-07-30 2011-02-17 Yamatake Corp Transaction control device, transaction processing method, and program
US20160246711A9 (en) * 2010-01-28 2016-08-25 Hewlett-Packard Development Company, L. P. Interface methods and apparatus for memory devices
JP5470148B2 (en) * 2010-04-20 2014-04-16 日本放送協会 Node device and computer program
EP2572473B1 (en) * 2010-05-19 2014-02-26 Telefonaktiebolaget L M Ericsson (PUBL) Methods and apparatus for use in an openflow network
FR2975560B1 (en) 2011-05-17 2013-06-14 Sagem Defense Securite COMMUNICATION SYSTEM, AND METHOD, COMPUTER PROGRAM, AND CORRESPONDING STORAGE MEANS
CN102546427B (en) * 2012-02-02 2015-04-29 杭州华三通信技术有限公司 OSPF (Open Shortest Path First) protocol-based graceful restart (GR) method and router
CN102546426B (en) * 2012-02-02 2014-09-24 杭州华三通信技术有限公司 Route generation method and route generation device for achieving fiber channel over Ethernet
CN102831223A (en) * 2012-08-23 2012-12-19 大唐移动通信设备有限公司 Management method and system of distributed databases
JP2014116688A (en) * 2012-12-06 2014-06-26 Fujitsu Ltd Network management system including shared data synchronization function
CN105359466B (en) * 2013-03-15 2019-08-27 华为技术有限公司 It is shared automatically for carrying out information between small group of users, synchronous and collaboration system and method
US10594604B1 (en) * 2013-10-08 2020-03-17 Juniper Networks, Inc. End to end application identification and analytics of tunnel encapsulated traffic in the underlay
JP2015108927A (en) * 2013-12-04 2015-06-11 日本電気株式会社 Information processing apparatus, data synchronizing method and program
US9743367B2 (en) * 2014-09-18 2017-08-22 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Link layer discovery protocol (LLDP) on multiple nodes of a distributed fabric
US11310350B2 (en) * 2017-01-04 2022-04-19 Futurewei Technologies, Inc. Network bridge between different network communication protocols

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002049517A (en) 2000-05-25 2002-02-15 Hitachi Ltd Storage system
US20100228866A1 (en) 2008-02-18 2010-09-09 Kepeng Li Method for synchronizing data, system, and apparatus thereof

Also Published As

Publication number Publication date
BR112020020799A2 (en) 2021-01-12
CA3159273A1 (en) 2019-10-17
US11805193B2 (en) 2023-10-31
WO2019196760A1 (en) 2019-10-17
CA3159276A1 (en) 2019-10-17
AU2019251120B9 (en) 2023-08-03
AU2019251120B2 (en) 2023-07-13
EP3776933A4 (en) 2021-04-21
MX2020010658A (en) 2020-10-28
JP2022167943A (en) 2022-11-04
AU2019251120A1 (en) 2020-11-12
JP7479427B2 (en) 2024-05-08
CN111937327A (en) 2020-11-13
JP2021520554A (en) 2021-08-19
US20210029228A1 (en) 2021-01-28
CA3096411A1 (en) 2019-10-17
US20240048645A1 (en) 2024-02-08
EP3776933A1 (en) 2021-02-17
SG11202009781SA (en) 2020-10-29
JP2022172168A (en) 2022-11-15

Similar Documents

Publication Publication Date Title
US7929422B2 (en) Method of moving a transport connection among network hosts
JP7479427B2 (en) Point-to-point database synchronization over transport protocols
US7801135B2 (en) Transport protocol connection synchronization
KR100990415B1 (en) Method for synchronizing connection state in data communication, and communication node using the same
US8098589B2 (en) System and method for exchanging awareness information in a network environment
JP6679498B2 (en) Method and apparatus for reducing packet storm duration in wireless mesh networks
WO2009067865A2 (en) Method, router, line card and active master card for realizng a link state database synchronization
TWI740210B (en) Method for terminal device management and server
WO2018149408A1 (en) High availability using multiple network elements
TWI638550B (en) Tree recovery method, controller and recording medium for software-defined network
CN110771117B (en) Session layer communication using ID-oriented network
RU2783595C2 (en) Method for synchronization of databases between two points, using transport protocol
JP2002199013A (en) Multicasting method
CN113395740B (en) Wireless network construction method
CN115022345A (en) Method, device and equipment for switch data synchronization and readable medium
CN116633996A (en) Network connection optimization method, device, equipment and readable storage medium
JP4044006B2 (en) Route control method, data aggregation device, and route control system
CN118509359A (en) Ad hoc network method, data access method, network equipment and storage medium
JP2014003700A (en) Relay device and communication system
WO2017000759A1 (en) Mobility management method and network device

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20201207

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201207

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20211216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220118

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220412

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220719

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220818

R150 Certificate of patent or registration of utility model

Ref document number: 7128288

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150