実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードの受信機において、アプリケーション識別子(AppId)と、ローカルノードのターゲットポートと隣接ノードのターゲットポートとの間のターゲットリンクとを含むハロー(Hello)メッセージを受信するステップと、ローカルノードのプロセッサにより、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するステップと、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードのメモリにローカルデータベースを設定するステップであり、データベース対は隣接ノードの隣接データベースを含む、ステップと、プロセッサにより、データベース対をターゲットリンクに関連付けるステップと、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するステップとを含む。この手法は、通信プロトコルがネットワーク上で同期のために1つ以上のデータベース対を自動的に設定することを可能にする。プロトコルは、ハローメッセージからターゲットリンク及びAppIdを取得する。次いで、プロトコルは、アプリケーションをターゲットリンクに互いに関連付け、アプリケーションの代わりに同期のためのデータベースを設定できる。このように、データベース設定がアプリケーションからオフロードでき、これは、アプリケーションによる直接の管理なしに、データベース同期が設定されて維持されることを可能にする。次に、これは、アプリケーションがこのような同期を達成するために基礎となるネットワークメッセージングを直接認識することなく、データベース同期を成立させることを可能にする。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、隣接データベースとのローカルデータベースの同期を制御するステップが、ローカルノードの送信機により、リンクローカル登録プロトコルデータユニット(Link-Local Registration Protocol Data Unit, LRPDU)メッセージにおいてターゲットリンクを介してレコード情報を隣接データベースに送信するステップを含むことを含む。データベース情報は、レコードに記憶される。レコードバージョン情報(例えば、制御情報)は、ターゲットリンク上で送信されるLRPDUを介して交換される。したがって、LRPDUメッセージは、データベースレコードが更新されたことを隣接ノードに示すためのメカニズムとして機能でき、その逆も可能である。したがって、LRPDUメッセージは、データベース同期を管理するために使用できる。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルデータベースが、隣接データベース内の登録側データベースへの送信のために、ローカルレコードを記憶するための申請側データベースを含むことを含む。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルデータベースが、隣接データベース内の申請側データベースから隣接レコードを受信するための登録側データベースを含むことを含む。データベース対は、アップロードされるべきレコードを含む申請側と、申請側レコードのコピーを受信する登録側とを含む。ローカルノード及び隣接ノードは、双方向同期のために申請側データベースと登録側データベースとの双方をそれぞれ含むことができる。さらに、一方向同期のために、申請側データベースはローカルノードに配置でき、登録側データベースは隣接ノードに配置でき、或いはその逆も同様である。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ハローメッセージがハローLRPDUであり、ハローLRPDUが、ローカルノードを識別するマイシャーシ(My Chassis)識別子(ID)、ローカルノード上のターゲットポートを識別するマイポート(My Port)ID、隣接ノードを識別する隣接シャーシ(Neighbor Chassis)ID、及び隣接ノード上のターゲットポートを識別する隣接ポート(Neighbor Port)IDとして、ターゲットリンクを表すことを含む。ターゲットリンクは、シャーシID及びポートIDにより指定でき、これは、ターゲットリンクの各端のターゲットポートを表す。この手法は、ターゲットリンクの一意の識別を可能にし、したがって、対応するノードがLRPDU通信目的のために配置できる場合、ローカルノード及び隣接ノードのそれぞれへの指示を可能にする。
実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードの送信機により、1つ以上のレコード(Record)LRPDUメッセージを隣接ノードの登録側データベースに送信するステップであり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、ステップと、ローカルノードの受信機により、レコードLRPDUメッセージを確認応答する1つ以上のLRPDUメッセージを受信するステップと、ローカルノードのメモリにおいて、登録側データベースによる確認応答済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするステップと、プロセッサを介して、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップとを含む。このメカニズムは、ネットワーク通信プロトコルがデータベース通信を監視してデータベースがいつ同期されるかを決定することを可能にする。次いで、ネットワークプロトコルは、同期が完了したことをアプリケーションに警告できる。このように、アプリケーションは、各レコード交換及び関連する通信を認識する必要がない。アプリケーションは、ローカル申請側データベースに変更を加え、ネットワークプロトコルが同期を管理して同期が完了したときにアプリケーションに警告することを可能にすることができる。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、ローカルノードのプロセッサにより、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたと決定するステップを更に含み、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップは、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたという決定に基づいて開始されることを含む。申請側は、各レコードがいつ確認応答されるかを決定し、全てのレコードが確認応答されたときにアプリケーションに通知でき、したがって、申請側データベースと登録側データベースとの間の同期が完了する。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージを確認応答するLRPDUメッセージが、部分リスト(Partial List)LRPDUメッセージを含み、部分リストLRPDUメッセージが、少なくとも1つの更新されたレコードを確認応答する少なくとも1つのレコードヘッダを含むことを含む。部分リストLRPDUメッセージは、確認応答メッセージとして機能する。部分リストLRPDUメッセージは、登録側から送信され、登録側がレコードLRPDUメッセージにより要求された更新を行ったことを申請側に示す。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードヘッダが、更新されたレコードを示すレコード番号と、更新されたレコードに含まれる更新を識別するシーケンス番号とを含むことを含む。このような情報は、登録側により受信された特定のレコード更新を示すことができる。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、対応する部分リストLRPDUメッセージを受信することなく、レコードLRPDUメッセージタイマが満了したとき、アプリケーションへの障害通知を生成するステップを更に含むことを含む。このメカニズムは、申請側が潜在的なレコード通信障害について通知されることを可能にする。レコードLRPDUメッセージは、大量の通信が登録側の受信バッファを溢れさせる可能性がある(例えば、より多くのレコード同期障害を潜在的に引き起こす)ので、自動的に再送されなくてもよい。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージを確認応答するLRPDUメッセージが、完了リスト(Complete List)LRPDUメッセージを含み、完了リストLRPDUメッセージが、登録側データベースの全てのレコードのレコードヘッダを含むことを含む。完了リストLRPDUメッセージは、登録側により所定の間隔で送信できる。完了リストLRPDUメッセージは、登録側データベースの現在の状態を含む。したがって、申請側は、いつレコード更新が登録側により受信されなかったかということに対して、いつレコードが登録側により受信されて確認応答メッセージが欠落したかということを決定するために、完了リストLRPDUメッセージを使用できる。次いで、申請側は、完了リストLRPDUメッセージの内容に基づいて更なるレコードLRPDUメッセージを送信することにより、同期エラーから回復できる。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、完了リストLRPDUメッセージが、登録側データベースに記憶された最初のレコードを示す先頭レコード番号フィールドと、登録側データベースに記憶された最後のレコードを示す最終レコード番号フィールドとを含み、レコードヘッダが、登録側データベースに記憶されたレコードを示すレコード番号と、登録側データベースに記憶されたレコードに含まれる更新を識別するシーケンス番号とを含むことを含む。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、レコードLRPDUメッセージが、申請側データベースで更新されたレコードを示す1つ以上のレコード番号と、申請側データベースで更新されたレコードに含まれる更新を識別する1つ以上のシーケンス番号とを含むことを含む。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、送信機により、要求完了リスト(Request Complete List)LRPDUメッセージを登録側データベースに送信するステップと、受信機により、要求完了リストLRPDUメッセージに応じて登録側データベースから完了リストLRPDUメッセージを受信するステップとを更に含むことを含む。このメカニズムを使用することにより、申請側は、周期的な完了リストLRPDUメッセージを待機するのではなく、オンデマンドで完了リストLRPDUメッセージを要求できる。
実施形態では、当該開示は、ローカルノードにおいて実装される方法を含み、当該方法は、ローカルノードのプロセッサにより、アプリケーションのための切断コードを生成するステップであり、切断コードは、ハロー(Hello)リンクローカル登録プロトコルデータユニット(Link-Local Registration Protocol Data Unit, LRPDU)メッセージの交換が失敗したことを示す、ステップと、プロセッサにおいて、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するステップと、ローカルノードの受信機により、ハローLRPDUメッセージの成功した交換の後に、隣接ノードの登録側データベースから完了リストLRPDUメッセージを受信するステップであり、完了リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む、ステップと、プロセッサにより、申請側データベースを登録側データベースと再同期させるために、完了リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するステップとを含む。このメカニズムは、接続喪失にもかかわらず、データベース対を維持することを可能にする。接続喪失が発生したとき、申請側は通知され、(例えば、全てのレコードを再送することにより)接続再確立のときに同期をリセットするか、接続再確立のときに同期を回復するかを選択することが可能になる。データベース対は、ハロー交換を介して再接続したとき、登録側から完了リストメッセージを送信することにより維持できる。次いで、申請側データベースは、存在する場合にはどの更新が接続喪失により失われたかを決定するために、登録側データベースからのレコードヘッダを申請側データベースのレコードヘッダと比較できる。次いで、申請側データベースは、申請側データベースレコードの全体リストを登録側に再送する代わりに、失われた更新のみを再送できる。このような手法は、申請側と登録側との間のネットワーク接続が発生したとき、ネットワークリソース使用及び同期回復時間を減少させてもよい。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、完了リストLRPDUメッセージが受信されるまでレコードLRPDUメッセージの送信を防止するために、ハローメッセージの失敗した交換の後に、申請側データベースにおいて通知タイマをリセットするステップを更に含むことを含む。これは、接続が復元されるまで申請側データベースがデータベースを同期させるのを試みることを停止させ、したがって、ネットワーク及び処理リソースを節約する。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、プロセッサにより、申請側データベース内の1つ以上のレコードヘッダと完了リストLRPDUメッセージからの1つ以上のレコードヘッダとの間の不一致を決定するステップと、レコードLRPDUメッセージを登録側データベースに送信するステップであり、レコードLRPDUメッセージは、不一致に対処する更新されたレコードヘッダを含む、ステップとを更に含むことを含む。不一致の場合、更新されたレコードが申請側から登録側に送信できる。これは、以前のレコードLRPDUメッセージが接続喪失で失われたために発生する可能性がある。
任意選択で、上記の態様のいずれかにおいて、当該態様の他の実装は、プロセッサにより、申請側データベース内のレコードヘッダと登録側データベースからのレコードヘッダとの間の不一致がないことを決定するステップと、不一致がないことの決定に基づいて、プロセッサを介して、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するステップとを更に含むことを含む。これは、ネットワークプロトコルがアプリケーションの代わりに同期を管理することを可能にし、したがって、アプリケーションがデータベース同期に関する通信仕様を認識しないことを可能にする。
実施形態では、当該開示は、メモリと、送信機と、受信機と、メモリ、送信機、受信機に結合されたプロセッサとを含むローカルノードを含み、ローカルノードは、上記の態様の方法を実行するように構成される。
実施形態では、当該開示は、ローカルノードによる使用のためのコンピュータプログラム製品を含む非一時的なコンピュータ読み取り可能媒体を含み、コンピュータプログラム製品は、プロセッサにより実行されたとき、ローカルノードに上記の態様の方法を実行させるように、非一時的なコンピュータ読み取り可能媒体に記憶されたコンピュータ実行可能命令を含む。
実施形態では、当該開示は、ローカルノードを含み、アプリケーション識別子(AppId)と、ローカルノードと隣接ノードとの間のターゲットリンクとを含むハローメッセージを受信するための受信モジュールと、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するための決定モジュールと、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードにローカルデータベースを設定するためのデータベース対設定モジュールであり、データベース対は隣接ノードの隣接データベースを含む、データベース対設定モジュールと、データベース対をターゲットリンクに関連付けるための関連付けモジュールと、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するための同期制御モジュールとを含む。
実施形態では、当該開示は、ローカルノードを含み、1つ以上のレコードリンクローカル登録プロトコルデータユニット(LRPDU)メッセージを隣接ノードの登録側データベースに送信するための送信モジュールであり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、送信モジュールと、レコードLRPDUメッセージを確認応答する1つ以上のLRPDUメッセージを受信するための受信モジュールと、登録側データベースによる確認応答済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリモジュールと、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたと決定するための決定モジュールと、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知モジュールとを含む。
実施形態では、当該開示は、ローカルノードを含み、アプリケーションのための切断コードを生成するための切断モジュールであり、切断コードは、ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの交換が失敗したことを示す、切断モジュールと、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するためのコマンドモジュールと、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完了リストLRPDUメッセージを受信するための受信モジュールであり、完了リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む、受信モジュールと、申請側データベースを登録側データベースと再同期させるために、完了リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するためのレコード比較モジュールとを含む。
任意選択で、上記のローカルノードのいずれかにおいて、ローカルノードの他の実装は、上記の態様のいずれかの方法を実行するためのモジュールを更に含むことを含む。
明確性の目的で、上記の実施形態のいずれか1つは、本開示の範囲内の新たな実施形態を作成するために、他の上記の実施形態のいずれか1つ以上と組み合わされてもよい。
これら及び他の特徴は、添付の図面及び特許請求の範囲に関して行われる以下の詳細な説明から、より明確に理解される。
最初に、1つ以上の実施形態の例示的な実装が以下に提供されるが、開示のシステム及び/又は方法は、現在既知であるか存在するかを問わず、いずれかの数の技術を使用して実装されてもよいことが理解されるべきである。当該開示は、ここに図示及び記載される例示的な設計及び実装を含む、以下に示す例示的な実装、図面及び技術に決して限定されるべきではなく、添付の特許請求の範囲の範囲内で、これらの均等物の全範囲と共に修正されてもよい。
データベース同期をサポートするために、標準化された通信プロトコルが使用されてもよい。このような通信プロトコルは、標準化された方法でデータベースの一貫性を維持するように構成できる。例えば、リンクローカル登録プロトコル(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は、関係するアプリケーションの代わりにデータベース同期を管理する。
ここに開示されるのは、LRP-DSの機能を改良するためのメカニズムである。例えば、LRP-DSは、同期のためにデータベース対を自動的に設定するように改良できる。データベース対は、第1のノードの申請側データベースと、第2のノードの登録側データベースとを含む。このようなノードはまた、説明の明確性のため、それぞれローカルノード及び隣接ノードと呼ばれてもよい。申請側データベースに対して更新が行われたとき、LRP-DSプロトコルは、同期を維持するために、このような更新を登録側データベースに通信する。一方向通信については、ローカルノードは申請側データベースを含み、隣接ノードは登録側データベースを含む。双方向通信については、ローカルノードは、隣接ノードの登録側データベースとの同期のための申請側データベースを含み、隣接ノードは、ローカルノードの登録側データベースとの同期のための申請側データベースを含む。いずれの場合も、データベース対は、ハローリンクローカル登録プロトコルデータユニット(LRPDU)メッセージの交換のときに自動的に設定できる。ハローLRPDUメッセージは、対応するアプリケーションのアプリケーション識別子(AppId)と、ローカルノードを識別するマイシャーシ識別子(ID)、ローカルノードのターゲットポートを識別するマイポートID、隣接ノードを識別する隣接シャーシID、及び隣接ノードのターゲットポートを識別する隣接ポートIDに関して示されるターゲットリンクとを含む。ハローメッセージの交換のとき、ローカルノード及び隣接ノードは、識別されたアプリケーションのための申請側及び登録側データベース対を自動的に作成し、ターゲットリンクに基づいてこのようなデータベース対を互いに関連付けることができる。
ポータルと呼ばれるコンポーネントで動作するLRP-DSはまた、1つ以上の更新の後にデータベースが同期したとき、アプリケーションに自動的に通知するために使用できる。例えば、申請側データベースで更新が行われたとき、更新されたデータベースレコードと、このような更新されたレコードのシーケンス番号(例えば、バージョン番号)とを示すために、レコードLRPDUメッセージが登録側データベースに送信される。登録側データベースは、更新されたレコードの認識を確認応答する部分リストLRPDUメッセージで応答し、これはLRP-DTを介して通信できる。部分リストLRPDUメッセージが受信されたとき、ポータルは、申請側データベース内の指示されたレコードを確認応答済みとしてマーキングさせる。複数のレコードLRPDU及び部分リストLRPDUが交換できる。申請側データベース内の全てのレコードが確認応答済みとしてマーキングされたとき、ポータルは、データベースが同期しているという指示をアプリケーションに送信できる。
他の例では、LRP-DSは、接続中断にもかかわらずデータベースの間の同期を維持するために使用できる。ハローLRPDUメッセージは、周期的に交換されてもよい。ハローLRPDUメッセージ交換が失敗したとき、ポータルはアプリケーションに通知できる。申請側は、データベースレコードを新たな登録側データベースに再アップロードすることにより、ペアリングを削除して再接続のときに新たなデータベース対を作成するように選択できる。申請側はまた、現在のデータベース対を維持することを選択できる。データベースペアリングが維持されるべきであるという指示をポータルが受信したとき、ポータルは更なるレコードLRPDUメッセージを中断する。ハローLRPDUメッセージ交換を再確立したとき、登録側は、完了リストLRPDUメッセージを申請側に送信する。完了リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。申請側データベースは、いずれかのレコード不一致を決定するために、完了リストLRPDUメッセージ内のレコードヘッダを、申請側データベースに記憶されたレコードヘッダと比較できる。これは、接続喪失のためレコードLRPDUメッセージが失われたときに生じてもよい。次いで、申請側データベースは、完了リストLRPDUメッセージに含まれるレコード状態以降に行われたいずれかのレコード更新を含むレコードLRPDUメッセージを送信できる。典型的には、結果は、迅速な完了リストLRPDU送信のない場合よりも少ないレコードLRPDUの送信である。ポータルはまた、データベースが同期したときにアプリケーションに通知できる。これら及び他の例示的な実施形態について、以下の図面に関してより詳細に説明する。
図1は、データベース同期ネットワーク100の例示的なネイティブシステムの概略図である。データベース同期ネットワーク100は、インターネットプロトコル(Internet Protocol, IP)ネットワーク171により結合されたネイティブシステム110及びネイティブシステム130を含む。ネイティブシステム110及びネイティブシステム130は、同期のために、それぞれ1つ以上のデータベース120及び122を含む。説明の明確性のため、ネイティブシステム110又は130は、ここでは、第1のシステムで発生する送信元動作に関して説明するときにはローカルと呼ばれ、第2のシステムで発生する宛先動作に関して説明するときには隣接と呼ばれる。したがって、ネイティブシステム110及び130は、コンテキストに依存して、ローカル、隣接又はこれらの双方になり得る。また、ここで使用されるローカル及び隣接という用語は相対的なものであり、第1のノードと第2のノードとの間を明確に区別するために使用され、異なる観点から同じネットワークを説明するときに交換可能に使用されてもよい点に留意すべきである。
ネイティブシステム110は、アプリケーション111と、ポータル113と、ターゲットポート141と、データベース120とを含む計算コンポーネントである。アプリケーション111は、少なくともネイティブシステム110及び/又はプロキシシステムとネイティブシステム130及び/又はプロキシシステムとの間で情報を配信するように動作可能なコンピュータプログラムである。プロキシシステムについて、以下の図2に関して説明する。例えば、アプリケーション111は、クラウド記憶システムと同期した保存ファイルを有するユーザ操作可能なプログラムを含んでもよい。アプリケーション111は、データをアプリケーション131にアップロードし、及び/又はアプリケーション131からデータをダウンロードする。簡潔性の目的で、2つのアプリケーション111及び131のみが示されているが、アプリケーション111は、いずれかの数の他のアプリケーションと同期できる。
ポータル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を維持する。
ネイティブシステム110はまた、ターゲットポート141上でリンク層ディスカバリプロトコル(Link Layer Discovery Protocol ,LLDP)161を動作させることができる。代替として、ネイティブシステム110は、LLDP161により生成されたものと同等のデータを含む、システム管理者により制御される情報のリポジトリを維持する。
データベース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とのレコードの双方向通信のための双方を含むことができる。
ターゲットポート141は、ネイティブシステム110上の通信ポートである。ポータル113及び関連する申請側及び登録側データベース120は、単一のターゲットポート141に関連付けられる。ターゲットポート141は、1つより多くのポータル113が異なるアプリケーション111にサービス提供する場合、このようなポータル113に関連付けられることができる。ターゲットポート141は、(例えば、他のシステム内の)1つ以上の他のターゲットポート151に接続するリンクへのアクセスを提供する。
ネイティブシステム130は、ネイティブシステム110と実質的に同様である。ネイティブシステム130は、ポータル133、アプリケーション131、データベース122及びターゲットポート151を含み、これらは、それぞれポータル113、アプリケーション111、データベース120及びターゲットポート141と実質的に同様でもよい。
ネイティブシステム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上のいずれかの他のポートを通過できる。
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により使用できる。
図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と実質的に同様である。
スレーブ240は、ルータ、スイッチ等のような通信コンポーネントとすることができ、或いは、カメラ、機械式アクチュエータ又はパーソナルコンピュータのようなエンドステーションとすることができる。スレーブ240は、ネットワーク接続によりプロキシ210に結合される。スレーブは、少なくとも1つのターゲットポート241を含み、これは、ターゲットポート141と実質的に同様である。通信コンポーネントは、複数のターゲットポート241を含む。プロキシ210及びスレーブ240は、ネイティブシステム110と実質的に同様の方式で一緒に機能する。プロキシ210の代わりにターゲットポート241をスレーブ240に配置することにより、アプリケーション211、ポータル213及び/又はデータベース220は、スレーブ240とは別のネットワークにあってもよいデバイス(プロキシ210)にオフロードできる。これは、実質的に同じ機能を提供しつつ、実装の柔軟性を提供する。
プロキシ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と実質的に同様である。
データベース同期ネットワーク100及び200の様々な組み合わせもまた、この開示の範囲内で使用されてもよい点に留意すべきである。例えば、ネイティブシステム110は、データベース120をプロキシ230及びスレーブ250と同期させるために使用できる。さらに、ネイティブシステム130は、データベース122をプロキシ210及びスレーブ240と同期させるために使用できる。様々な中継システム(例えば、ルータ及び/又はブリッジ)が、ネイティブシステム、プロキシ及び/又はスレーブの間の通信をルーティングするために使用できる。このようなコンポーネントは、以下に説明するように、様々な能力を含んでもよい。いずれかの通信デバイスにおいて、アプリケーション111、131、211及び/又は231は、同じシステムに属する異なるターゲットポート141、151、241及び251上で、データベース120、122、220及び222において申請側と登録側との間で情報を交換できる。
図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を含んでもよい。
申請側321は、ローカルに記憶されたデータのコピーを隣接データベースの登録側にアップロードするように構成された状態機械及び対応するメモリ空間である。登録側325は、隣接データベースにおいて申請側からリモートに記憶されたデータのコピーを受信するように構成された状態機械及び対応するメモリ空間である。したがって、データベース320は、同期のためにデータをアップロードするための申請側321、同期のためにデータをダウンロードするための登録側325、又は双方向同期のためのこれらの双方を含むことができる。申請側321及び登録側325は、制御メッセージ及びデータがこれらの意図した宛先に到達することを確保するために、ポータル313にそれぞれ関連付けられる。ポータル313は、メッセージがこれらの意図したポータル(例えば、ポータル313)で受信されることを確保するために、ターゲットポートに更に関連付けられる。
データベース320内のデータは、レコードに記憶される。レコードは、同期のために通信できるデータの最小単位である。レコードサイズは、アプリケーション311により構成できる。より小さいレコードは複雑さを作るが、より大きいレコードは、レコードの一部が更新されたときにより多くのデータの転送を生じる。
申請側321は、ローカルレコード323及びローカルレコードヘッダ324を含む。ローカルレコード323は、アプリケーション311によりローカルに使用されるデータを含むレコードである。レコードヘッダは、対応するレコードに関する状態情報の事前定義のグループである。例えば、ローカルレコードヘッダ324は、対応するローカルレコード323のレコード番号、シーケンス番号及び/又はチェックサムを含む。レコード番号は、対応するレコードを示す。シーケンス番号は、バージョン情報を含む。例えば、シーケンス番号は、対応するレコードが修正された回数を示すカウンタを含んでもよい。チェックサムは、エラー検査情報であり、送信のための対応するデータのセットにおける正しい数の数字の和を表す数字を含んでもよい。例えば、チェックサムはレコード番号及びシーケンス番号における正しい数の数字の和を示してもよい。したがって、ローカルレコード323が更新されたとき、対応するローカルレコードヘッダ324は、更新されたレコード及び更新のバージョン(例えば、シーケンス番号)を示すためにシグナリングできる。
登録側325は、隣接レコード326及び隣接レコードヘッダ327を含む。隣接レコード326及び隣接レコードヘッダ327は、それぞれローカルレコード323及びローカルレコードヘッダ324と同様であるが、隣接ノード/システムのアプリケーションにより使用されるデータに関する。
したがって、ローカルデータベース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との間でレコード及びレコードヘッダを交換するためのこれらの及び他のメッセージング方式について、以下の図面に関して説明する。
図4は、データベース同期を管理する例示的な方法400のプロトコル図である。方法400は、ネイティブシステム110及び/又は130、スレーブ240及び/又は250と共にプロキシ210及び/又は230、及び/又はデータベースシステム300により実装されてもよい。方法400は、申請側及び登録側を含むデータベース対を作成して維持するメカニズムを提供する。データベース対の管理は、申請側データベースと登録側データベースとの間の同期を維持することを含む。方法400は、アプリケーション、ローカルノードで申請側データベースを制御するローカルポータル、及び隣接ノードで登録側データベースを制御する隣接ポータルにより実装される。
いくつかの例では、ローカルポータル及び隣接ポータルは、アプリケーションに関する隣接ノードのポート及びアドレスで事前構成される。他の例では、ローカルポータル及び隣接ポータルは、他の発見プロトコルを介してアプリケーションに関する隣接ノードのポート及びアドレスを発見する。いずれの場合も、ローカルポータルは、ハローLRPDUメッセージ401を隣接ポータルに転送し、隣接ポータルは、ハローLRPDUメッセージ403をローカルポータルに転送する。これはまた、ハローLRPDUメッセージの交換とも呼ばれてもよい。ハローLRPDUメッセージ401及び403は、アプリケーション識別子(AppId)を含み、ローカルノードのターゲットポートと隣接ノードのターゲットポートとの間のターゲットリンクを識別する。AppIdはアプリケーションを示し、したがって、送信者がデータを同期させることを望むアプリケーションに関連付けられることを示す。ハローLRPDUメッセージ401及び403内のターゲットリンクは、通信する試みが成功し、同期が開始できることを示す。
したがって、ローカルポータルがハローLRPDUメッセージ403を受信したとき、ローカルポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。次いで、ローカルポータルは、アプリケーションによる使用のためのデータベース対の一部として、ローカルノードのメモリにローカルデータベースを設定する。この例では、ローカルデータベースは申請側を含む。さらに、隣接ポータルがハローLRPDUメッセージ401を受信したとき、隣接ポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。次いで、隣接ポータルは、データベース対の一部として、隣接ノードのメモリに隣接データベースを設定する。この例では、隣接データベースは登録側を含む。ローカルポータル及び隣接ポータルは、それぞれデータベース対をターゲットリンクに関連付ける。次いで、ローカルポータルは、ターゲットリンクを介して、隣接登録側データベースとのローカル申請側データベースの同期を制御できる。隣接登録側データベースとのローカル申請側データベースの同期を制御することは、以下に説明するように、LRPDUメッセージにおいてターゲットリンクを介してレコード情報を隣接データベースに送信することを含む。LRPDUメッセージは、このようなメッセージが適切なポータルに到達することを確保するために、ターゲットリンクを介して常に転送されてもよい点に留意すべきである。
一旦ハローLRPDUメッセージ交換が発生してデータベースが設定されると、アプリケーションは、ローカルポータルを介して申請側データベースへのレコード変更405を行うことができる。レコード変更405は、対応するレコード内のデータの少なくとも1つのビットを更新することを含む。レコードが更新されたとき、変更を示すために、対応するレコードヘッダ内でシーケンス番号が変更される(例えば、インクリメントされる)。レコード変更405により影響を受けるレコードはまた、登録側が変更を認識していないことを示すために、申請側データベースにおいてフラグを使用することにより未確認応答としてマーキングできる。
ローカルポータルは、隣接ポータルを介してレコードLRPDUメッセージ407を隣接ノードの登録側データベースに送信できる。レコードLRPDUメッセージ407は、申請側データベースに記憶されたレコードへの更新を示す。具体的には、レコードLRPDUメッセージ407は、レコード変更405により申請側データベース内で更新されるレコードのレコードヘッダを含む。このようなレコードヘッダは、それぞれの更新されるレコードのレコード番号及びシーケンス番号を含む。いくつかの例では、レコードLRPDUメッセージ407はまた、更新されるレコードも同様に含む。他の例では、更新されたレコードは、TCP及び/又はLRP-DTのような別の通信を介して及び/又は別のプロトコルを介して、申請側から登録側に転送される。確認応答を待機することなくレコードが更新されるので、ローカルポータルは、更なるレコードLRPDUメッセージを送信し続けてもよい点に留意すべきである。
隣接ポータル、したがって、登録側は、レコードLRPDUメッセージ407を受信し、含まれているレコードヘッダ及び/又はレコードで登録側データベースを更新する。次いで、隣接ポータルは、登録側の代わりに部分リストLRPDUメッセージ409を生成できる。部分リストLRPDUメッセージ409は、レコードLRPDUメッセージ407の確認応答として機能する。部分リストLRPDUメッセージ409は、レコードLRPDUメッセージ407に含まれるレコードヘッダを含み、したがって、例に依存して、登録側がこれらのレコードへの更新を認識していること及び/又は受信したことを示す。隣接ポータルは、部分リストLRPDUメッセージ409を申請側データベースに送信する。レコードLRPDUメッセージ407を確認応答する部分リストLRPDUメッセージ409は、ローカルポータルにおいて受信される。次いで、ローカルポータルは、フラグを使用することにより、登録側データベースによる確認応答済みとして、申請側データベース内の更新されたレコードをマーキングできる。
上記のように、ローカルポータルは、対応する部分リストLRPDUメッセージ409を待機することなく、更なるレコードLRPDUメッセージ407を送信してもよい。したがって、特定の部分リストLRPDUメッセージ409が受信されたときであっても、様々なレコード更新は、未確認応答のままでもよい。しかし、いくつかの場合、例えば、申請側への更新の一時停止のため、全ての対応するレコードLRPDUメッセージ407について全ての部分リストLRPDUメッセージ409が受信される可能性がある。これが発生したとき、申請側データベース及び登録側データベースは同期している。ローカルポータルは、部分リストLRPDUメッセージ409を受信する毎に、申請側データベース内のレコードの確認応答状態を検査できる。したがって、データベースが同期したとき、ローカルポータルは、申請側データベース内の全ての更新されたレコードが、LRPDUメッセージを介して登録側データベースにより確認応答されたと決定できる。申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたという決定に基づいて、ローカルポータルは、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するために、全レコード確認応答411を送信できる。全レコード確認応答411は、同期を検証するためにアプリケーションに送信される所定のコードの形式の指示でもよい。
任意選択で、ローカルポータルは、各レコードLRPDUメッセージ407のタイマを維持するように構成できる。このような場合、対応する部分リストLRPDUメッセージ409を受信することなく、レコードLRPDUメッセージ407タイマが満了したとき、ローカルポータルは、アプリケーションへの障害通知412を生成できる。未確認応答のレコードLRPDUメッセージ407は、ローカルポータルにより自動的に再送されなくてもよい。隣接ポータル及び/又は対応するターゲットポートは、限られた受信バッファを含んでもよい。自動再送は、他のレコードLRPDUメッセージ407のため、バッファ溢れを生じる可能性がある。したがって、アプリケーションは、例えば、未確認応答のレコードLRPDUメッセージ407を再送すること、より長く待機すること、申請側データベースへの対応するレコード更新をロールバックすること等により、どのように処理するかを決定できる。
隣接ポータルは、登録側の代わりに完了リストLRPDUメッセージ413を送信する。完了リストLRPDUメッセージ413は、登録側データベースの全てのレコードのレコードヘッダを含む(しかし、レコード自体は含まない)。完了リストLRPDUメッセージ413は、周期的に送信され、ローカルポータルを介して申請側により受信されてもよい。完了リストLRPDUメッセージ413は、例えば、部分リストLRPDUメッセージ409がローカルポータル/申請側により受信されない場合、1つ以上の以前に送信されたレコードLRPDUメッセージ407の確認応答として機能してもよい。さらに、完了リストLRPDUメッセージ413はまた、いつレコードLRPDUメッセージ407が登録側により受信されなかったかを決定するために、申請側により使用されてもよい。例えば、申請側は、完了リストLRPDUメッセージ413内のレコードヘッダを申請側データベース内のレコードヘッダと比較できる。申請側データベース内のレコードヘッダが完了リストLRPDUメッセージ413内のレコードヘッダと一致するとき、申請側は、全てのレコード更新が登録側により受信されたと決定し、全レコード確認応答411を送信できる。申請側データベース内のレコードヘッダが完了リストLRPDUメッセージ413内のレコードヘッダと一致しないとき、申請側は、特定のレコード更新が登録側で受信されていないと決定し、これらを再送できる。
方法400はまた、他の場合も管理する。例えば、接続中断415が発生する可能性がある。接続中断415は、ローカルポータル及び隣接ポータルのターゲットポートの間のノード又はリンクの障害から生じる可能性がある。接続中断415はまた、データトラフィック輻輳のために発生する可能性がある。ハローLRPDUメッセージ401及び403のようなハローLRPDUメッセージは周期的に交換され、このような交換が失敗したとき、ポータルは接続中断415を認識するようになる。ハローメッセージ交換が失敗したとき、ローカルポータルは、アプリケーションのための切断コード416を生成する。切断コード416は、ハローLRPDUメッセージの交換が失敗して接続中断415が発生したことをアプリケーションに示す。次いで、申請側は、接続中断415に応じて取るべきアクションを決定できる。例えば、アプリケーションは、接続を再確立したときにデータベース対をリセットすることを判断でき、この場合、一旦ハローLRPDUメッセージ401及び403が交換されると、方法400が再開する。
他の例として、アプリケーションは、データベース対を保持して接続を再確立することを判断できる。成功したとき、この手法は、申請側データベース内の全てのレコードを登録側データベースに再送する必要性を回避する。アプリケーションは、維持データベースコマンド417をローカルポータルに送信できる。したがって、ローカルポータルは、切断コード416にもかかわらずローカルノードのメモリにおいて申請側データベースを維持するために、アプリケーションから維持データベース417コマンドを受信できる。ローカルポータルがデータベース対を維持するためのコマンドを受信したとき、ローカルポータルは、完了リストLRPDUメッセージ418が隣接ポータルを介して登録側データベースから受信されるまで、レコードLRPDUメッセージ407を送信するのを中止する。例えば、ローカルポータルは、完了リストLRPDUメッセージ418が受信されるまで、レコードLRPDUメッセージの送信を防止するために、ハローLRPDUメッセージの失敗した交換(例えば、接続中断415)の後に、申請側データベースにおいて通知タイマをリセットできる。
隣接ポータルは、隣接ノードのアプリケーションと同様のプロセスを実行する。成功したハローLRPDUメッセージ交換の後に、登録側は、隣接ポータルを介して、完了リストLRPDUメッセージ418を送信する。完了リストLRPDUメッセージ418は、完了リストLRPDUメッセージ413と実質的に同様であり、したがって、登録側データベースの全てのレコードヘッダを含む。ローカルノード又はリモートノードのアプリケーションのいずれかがデータベース対をリセットすることを選択した場合、方法400は再開する。例えば、隣接ポータルが登録側データベースをリセットし、ローカルポータルが申請側データベースをリセットしない場合、完了リストLRPDUメッセージ418は空であり、申請側は全てのレコードを再送する。他の例として、隣接ポータルが登録側データベースをリセットせず、ローカルポータルが申請側データベースをリセットする場合、完了リストLRPDUメッセージ418は、申請側データベースと一致しないレコードヘッダを含み、データベース対はリセットされる。しかし、双方のアプリケーションがデータベース対を維持することを選択した場合、完了リストLRPDUメッセージ418は、申請側データベース内のレコードヘッダと同一又は同様(例えば、失われたレコードLRPDUメッセージ407のため)のレコードヘッダを含む。この場合、申請側は、データベース対の間の同期を回復するために必要なステップを決定できる。
したがって、ローカルポータルは、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完了リストLRPDUメッセージ418を受信できる。完了リストLRPDUメッセージ418は、登録側データベースの全てのレコードのレコードヘッダを含む。次いで、ローカルポータル及び/又は申請側データベースは、申請側データベースを登録側データベースと再同期させるために、完了リストLRPDUメッセージ418からのレコードヘッダを申請側データベース内のレコードヘッダと比較できる。第1の場合、ローカルポータルは、申請側データベース内のレコードヘッダと完了リストLRPDUメッセージ418に含まれる登録側データベースからのレコードヘッダとの間に不一致がないと決定できる。このような場合、データベース対は同期している。したがって、不一致がないという決定に基づいて、ポータルは、例えば、全レコード確認応答411を送信することにより、申請側データベースが登録側データベースと同期していることをアプリケーションに通知できる。第2の場合、ローカルポータルは、申請側データベース内の1つ以上のレコードヘッダと完了リストLRPDUメッセージ418からの1つ以上のレコードヘッダとの間の不一致を決定できる。これは、接続中断415の間にレコードLRPDUメッセージ407が失われた場合に発生する可能性がある。ポータルは、どのレコードが登録側データベースに送信されていないかを決定するために、レコードヘッダを比較できる。次いで、ローカルポータルは、隣接ポータルを介して、レコードLRPDUメッセージ407を登録側データベースに送信できる。レコードLRPDUメッセージ407は、不一致に対処するために、必要に応じて更新されたレコードヘッダを含む。いずれの場合も、データベース対をリセットして申請側データベース内の全てのレコードを再送することなく、データベース対が同期することになる。
任意選択で、ローカルポータルはまた、申請側の代わりに、完了リストLRPDUメッセージ421を要求できる。これは、申請側がオンデマンドでデータベース同期を検査することを可能にする。このような場合、ローカルポータルは、隣接ポータルを介して要求完了リストLRPDUメッセージ419を登録側データベースに送信する。隣接ポータル及び/又は登録側は、要求完了リストLRPDUメッセージ419を受信し、ローカルポータルを介して完了リストLRPDUメッセージ421を申請側に送信する。完了リストLRPDUメッセージ421は、完了リストLRPDUメッセージ418及び413と実質的に同様である。次いで、ローカルポータル、したがって、申請側は、要求完了リストLRPDUメッセージ419に応じて、登録側データベースから完了リストLRPDUメッセージ421を受信できる。したがって、申請側は、データベース対が同期しているか否かを決定し、及び/又はデータベース対を同期させるためにどのレコードが登録側に送信されるべきかを決定するために、完了リストLRPDUメッセージ421からのレコードヘッダを申請側データベース内のレコードヘッダと比較できる。
方法400のLRPDUメッセージ及び通知は、本開示の様々な例示的な機能を記述するために順に示されている点に留意すべきである。このようなメッセージ/通知は、様々な組み合わせで使用できる。例えば、ハローLRPDUメッセージ401及び403並びに完了リストLRPDUメッセージ413、418及び421のハロー交換は、事前定義のタイマに基づいて且つ上記のトリガイベントに基づいて、周期的に発生してもよい。さらに、結果のレコードLRPDUメッセージ407及び部分リストLRPDUメッセージ409でのレコード変更405は、介在するアクションの有無にかかわらず、申請側データベースの通常の動作中に繰り返し発生してもよい。さらに、全レコード確認応答411、障害通知412、切断コード416及び維持データベースコマンド417は、対応する状況が発生したときに常にトリガーできる。したがって、図4におけるLRPDUメッセージ及び通知の順序は例示的なものであり、ここで別段の指定がない限り、限定として考えられるべきではない。
さらに、いずれかの数のLRPDUは、レイヤ2フレームの最大サイズまで、単一のLRP-DTエッジ制御プロトコルデータユニット(Edge Control Protocol Data Unit, ECPDU)内で連続的に一緒に繋ぎ合わされることができる。単一のLRPDUは、複数のLRP-DT ECP ECPDUの間に分割されなくてもよい。TCPを使用するとき、LRPDUのサイズは、16ビット長のフィールドにより制限されてもよい。
図5は、ハローLRPDUメッセージ401及び/又は403を実装してもよいハローLRPDUメッセージ500の例示的な符号化を示す。したがって、ハローLRPDUメッセージ500は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300におけるデータベース対の同期を維持するために使用されてもよい。
ハロー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を加えた長さを含む。
残りのデータは、最初のデータフィールドにおいて3オクテットのオフセットを有する0から65,535オクテットの長さを含む。ハローLRPDUメッセージ500のデータフィールドは、申請側、登録側及び/又は対応するポータルにおいて、送信ハロー(Send Hello)状態機械の単一のインスタンスにより送信される情報を含む。ハローLRPDUメッセージ500は、いくつかの固定サイズのフィールドを含み、その後にデータフィールド内の一連のTLVが続く。すなわち、TLV長フィールド503に続く第10オクテットは、他のLRPDUタイプフィールドでもよい。
ハロー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だけでなく、状態機械変数を含む多数のコンテキストで使用される点に留意すべきである。
ハロー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ビットの情報を含んでもよく、データベースオーバーフローのようなエラーを示してもよい。
ハロー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メッセージで使用される。
ハローLRPDUメッセージ500はまた、ハロー時間(Hello Time)フィールド511を含む。ハロー時間フィールド511は、ハローLRPDUメッセージ500の生存時間を表す2オクテットを含む。ハロー時間フィールド511の最初のオクテットは、ハローLRPDUメッセージ500が有効である16ビットの数の秒(0から65,535又は30から65,535)の最上位オクテットである。このフィールドは、1以上29以下の値では送信されなくてもよい。
ハローLRPDUメッセージ500内の最初の4つのTLVは、いずれかの順序でのマイシャーシID TLV513、マイポートID TLV515、隣接シャーシID TLV517及び隣接ポートID TLV519のそれぞれ1つである。これらに続いて、0又は1つのアプリケーション情報(Application Information)TLV521のいずれかが来る。
マイシャーシID TLV513のタイプフィールドは、typeMyChassisIdの値に設定される。マイシャーシID TLV513のデータフィールドは、マイシャーシID TLV513を送信するポータルを作成した完了ポータル作成要求で示されるLLDPインスタンスによるLLDPシャーシID(LLDP Chassis ID)TLVにおける送信のために指定された値を含む。具体的には、マイシャーシID TLV513は、ハローLRPDUメッセージ500の送信者として機能するローカルノード(例えば、機械)を識別する値を含む。このようなローカルノードは、データベース対を設定及び/又は維持するために使用されるネイティブシステム又はスレーブシステムを含む(例えば、ローカル登録側、ローカル申請側又はこれらの双方を含むか或いはそれに結合される)。
マイポートID TLV515のタイプフィールドは、typeMyPortIdの値に設定される。マイポートID TLV515のデータフィールドは、マイポートID TLV515を送信するポータルを作成した完了ポータル作成要求で示されるLLDPインスタンスによるLLDPポートID(LLDP Port ID)TLVにおける送信のために指定された同じ値を含む。具体的には、マイポートID TLV515は、データベース対(例えば、ネイティブシステム又はスレーブ)を設定及び/又は維持するのを試みるローカルノード上でターゲットポートを識別する値を含む。シャーシID及びポートIDは共に、LRPDUメッセージの通信のためのターゲットリンクのローカルの半分を一意に表す。
隣接シャーシID TLV517のタイプフィールドは、typeNeighborChassisIdの値に設定される。隣接シャーシID TLV517のデータフィールドは、マイシャーシID TLV513と同じフォーマットであり、ローカルポータルが関連する隣接ポータルのシャーシIDを含む。具体的には、隣接シャーシID TLV517は、ハローLRPDUメッセージ500の宛先として機能する隣接ノード(例えば、機械)を識別する値を含む。隣接ノードは、データベース対を設定及び/又は維持するために使用されるネイティブシステム又はスレーブシステムを含む(例えば、隣接登録側、隣接申請側又はこれらの双方を含むか或いはそれに結合される)。
隣接ポートID TLV519のタイプフィールドは、typeNeighborPortIdの値に設定される。隣接ポートID TLV519のデータフィールドは、マイポートID TLV515と同じフォーマットであり、ローカルポータルが関連する隣接ポータルのポートIDを含む。具体的には、隣接ポートID TLV519はデータベース対(例えば、ネイティブシステム又はスレーブ)を設定及び/又は維持するために使用される隣接ノード上でターゲットポートを識別する値を含む。隣接シャーシID及び隣接ポートIDは共に、LRPDUメッセージの通信のためのターゲットリンクの隣接の半分を一意に表す。したがって、ハローLRPDU500は、ローカルノードを識別するマイシャーシID、ローカルノード上のターゲットポートを識別するマイポートID、隣接ノードを識別する隣接シャーシID、及び隣接ノード上のターゲットポートを識別する隣接ポートIDとしてターゲットリンクを表す。
アプリケーション情報TLV521は、typeAppInfoの値に設定される。アプリケーション情報TLV521のデータフィールドは、イネーブルポータル作成要求により供給される情報を含む。データは、LRP-DT接続の宛先端のポータル状態指示を通じて宛先のアプリケーションに提示される。データは不明瞭でもよく、LRPにより解釈されなくてもよい。アプリケーション情報TLV521は任意選択である。
したがって、タイプフィールド501は、0オクテットのオフセットを有する1オクテットであり、長さフィールド503は、1オクテットのオフセットを有する2オクテットであり、AppIdフィールド505は、3オクテットのオフセットを有する4オクテットであり、ハロー状態フィールド507は、7オクテットのオフセットを有する1オクテットであり、マイポータル番号フィールド509は、8オクテットのオフセットを有する4オクテットであり、ハロー時間フィールド511は、12オクテットのオフセットを有する2オクテットであり、残りのTLV513~521は14オクテットの開始オフセットを有する可変長である。
図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以上のレコードがある。
各レコードは、レコード番号フィールド631、シーケンス番号フィールド633、チェックサムフィールド635、並びに、任意選択でデータ長フィールド637及びアプリケーションデータフィールド639を含む。レコード番号フィールド631は、更新された申請側データベースのレコードを示すデータを含む。シーケンス番号フィールド633は、対応するレコードに関連するバージョン番号及び/又は変更の数を示すデータを含む。チェックサムフィールド635は、対応するレコードに含まれる値(例えば、レコード番号フィールド631、シーケンス番号フィールド633、データ長フィールド637及び/又はアプリケーションデータフィールド639内の値)に基づいて計算された2オクテットの値のようなエラー訂正データを含む。データ長フィールド637は、存在する場合、対応するレコード内のデータの長さ及び/又はアプリケーションデータフィールド639の長さを示す。アプリケーションデータフィールド639は、存在する場合、申請側データベースから登録側データベースへの送信中の更新されたレコードを含む。
したがって、レコード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とを含み、レコードオフセットは、レコードの開始から測定される。
図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の長さを含む。
部分リスト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の受信を確認応答する。
したがって、部分リストLRPDUメッセージ700は、レコードLRPDUメッセージ600を確認応答し、部分リストLRPDUメッセージ700は、少なくとも1つの更新されたレコード630を確認応答する少なくとも1つのレコードヘッダ730を含む。さらに、レコードヘッダ730は、更新されたレコード(例えば、レコード630)を示すレコード番号フィールド731内のレコード番号と、更新されたレコード(例えば、レコード630)に含まれる更新を識別するシーケンス番号フィールド733内のレコード番号とを含む。
図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の長さを含む。
完了リストLRPDUメッセージ800のデータフィールドの最初の2オクテットは、送信ポータルのシャーシID、ポートID及びappIdを符号化するマイポータル番号フィールド809である。これは、同じポータルについてハローLRPDUメッセージ500で送信される同じ値である。これに続いて、先頭レコード番号フィールド823及び最終レコード番号フィールド825があり、これらは、それぞれ4オクテットの長さであり、この完了リストLRPDUメッセージ800に含まれるそれぞれ最低のレコード番号値及び最高のレコード番号値を含む。例えば、先頭レコード番号フィールド823及び最終レコード番号フィールド825は、それぞれ登録側に記憶された最初のレコード及び最後のレコードを含む。
これに続いて、レコードヘッダ730と実質的に同様の0以上のレコードヘッダ830がある。しかし、レコードヘッダ830は、確認応答済みの更新されたレコードのレコードヘッダのみとは対照的に、登録側データベースにおける全てのレコードヘッダを含む。各レコードヘッダ830は、それぞれレコード番号フィールド731、シーケンス番号フィールド733及びチェックサムフィールド735と実質的に同様のレコード番号フィールド831、シーケンス番号フィールド833及びチェックサムフィールド835を含む。
完了リストLRPDUメッセージ800で送信される各レコード番号831は、先頭レコード番号フィールド823の値以上且つ最終レコード番号フィールド825の値以下の値を含む。先頭レコード番号フィールド823及び最終レコード番号フィールド825は、登録側に既知のレコードの完全なリストが1つより多くの完了リストLRPDUメッセージ800の間で分割されることを可能にする。完了リストLRPDUメッセージ800の全ての先頭及び最終レコード番号の対は、0から4,294,967,295までの全ての可能なレコード番号にわたることができるレコードの完全なリストを含む。
図9は、例えば、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300においてデータベース対を確立する例示的な方法900のフローチャートである。方法900は、ハローLRPDUメッセージ401、403及び/又は500のような方法400からのシグナリングを使用する。方法900について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。
方法900は、ローカルノードが隣接ノードとの同期のためにデータベース対を確立することを望むときに始まる。ブロック901において、ハローメッセージがローカルノードにおいて受信される。ハローメッセージは、AppIdと、ローカルノードのターゲットポートと隣接ノードのターゲットポートの間のターゲットリンクとを含む。ローカルノードがネイティブシステムであるとき、ターゲットポートはローカルノードに配置される。ローカルノードがプロキシであるとき、ターゲットポートはスレーブに配置される。ハローメッセージは、ハローLRPDUメッセージ401、403及び/又は500のようなハローLRPDUメッセージとすることができる。さらに、ハローLRPDUメッセージは、ローカルノード又は対応するスレーブノードを識別するマイシャーシID、ローカルノード又は対応するスレーブノード上のターゲットポートを識別するマイポートID、隣接ノード又は対応するスレーブノードを識別する隣接シャーシID、及び隣接ノード又は対応するスレーブノード上のターゲットポートを識別する隣接ポートIDとして、ターゲットリンクを表すことができる。ハロー交換を完了するために、対応するハローメッセージもまた、ローカルノードから隣接ノードに送信される。このようなハローメッセージは、ローカルノードで受信したハローメッセージと実質的に同様でもよいが、異なるマイポータル番号を有する。例えば、ローカルノードから送信されるハローメッセージは、ローカルノードに関連するマイポータル番号を含み、ローカルノードで受信されるハローメッセージは、隣接ノードに関連するマイポータル番号を含む。このようなメッセージは、いずれかの順序で送信されてもよい。
ブロック903において、ローカルノード及び/又は対応するポータルは、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定する。AppIdがデータベース同期に関連付けられるという決定に基づいて、ブロック905において、ローカルデータベースがローカルノードのメモリに設定される。ローカルデータベースは、アプリケーションによる使用のためのデータベース対の一部である。データベース対は、隣接ノードでの(例えば、隣接ノードのポータルによる)隣接データベース設定を含む。いくつかの例では、ローカルデータベースは、隣接データベース内の登録側データベースへの送信のために、ローカルレコードを記憶するための申請側データベースを含むことができる。いくつかの例では、ローカルデータベースは、隣接データベース内の申請側データベースから隣接レコードを受信するための登録側データベースを含む。いくつかの例では、ローカルデータベースは、申請側データベース及び登録側データベースの双方を含む。
ブロック907において、データベース対は、(例えば、ネイティブシステムにおいて及び/又はプロキシへのスレーブにおいて)ターゲットリンクに関連付けられる。ポータルがターゲットポートと共にローカルノード上にあるため、或いは、ポータルを含み且つローカルノードで動作するプロキシにこのようなメッセージを転送するように構成されたスレーブ上にターゲットポートがあるため、このような関連付けは、申請側/登録側に転送されたLRPDUメッセージが正しいポータルに到達することを確保する。
ブロック909において、ローカルノード/ポータルは、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期の制御/管理を開始する。このような制御は、LRPDUメッセージ内のターゲットリンクを介して、レコード情報を隣接データベースに送信することにより発生する可能性がある。このようなレコード情報は、レコード、レコードヘッダ又はこれらの組み合わせを含んでもよい。例えば、このようなLRPDUメッセージは、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完了リストLRPDUメッセージ800及び/又は方法400からのいずれかのLRPDUメッセージを更に含んでもよい。
図10は、例えば、方法900の完了のときにデータベース対の同期を管理する例示的な方法1000のフローチャートである。方法1000は、ネイティブシステム110及び/又は130、プロキシ210及び/又は230、スレーブ240及び/又は250、及び/又はデータベースシステム300上で動作されてもよい。方法1000は、方法400からのシグナリングを使用する。さらに、方法1000は、ハローLRPDUメッセージ500、レコードLRPDUメッセージ600、部分リストLRPDUメッセージ700、完了リストLRPDUメッセージ800及び/又はこれらの組み合わせのようなLRPDUメッセージを使用してもよい。方法1000について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。
ブロック1001において、アプリケーションは、申請側データベースにおいて1つ以上のレコードを変更する。したがって、ローカルノードのポータルは、例えば、隣接ポータルを介して、1つ以上のレコードLRPDUメッセージを隣接ノードの登録側データベースに送信する。レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示し、また、このような更新されたレコードを含んでもよい。例えば、レコードLRPDUメッセージは、申請側データベースで更新されたレコードを示す1つ以上のレコード番号と、申請側データベースで更新されたレコードに含まれる更新を識別する1つ以上のシーケンス番号とを含んでもよい。更新されたレコードはまた、申請側のデータベースにおいて未確認応答としてマーキングされることもできる。
ブロック1003において、ポータルは、ブロック1001のレコードLRPDUメッセージを確認応答する1つ以上のLRPDUメッセージを受信する。いくつかの例では、レコードLRPDUメッセージを確認応答するLRPDUメッセージは、部分リストLRPDUメッセージを含む。部分リストLRPDUメッセージは、ブロック1001の少なくとも1つの更新されたレコードを確認応答する少なくとも1つのレコードヘッダを含む。少なくとも1つのレコードヘッダは、ブロック1001の更新されたレコードを示すレコード番号と、ブロック1001の更新されたレコードに含まれる更新を識別するシーケンス番号とを含む。いくつかの例では、レコードLRPDUメッセージを確認応答するLRPDUメッセージは、完了リストLRPDUメッセージを含むことができる。完了リストLRPDUメッセージは、登録側データベースにおける全てのレコードのレコードヘッダを含む。さらに、完了リストLRPDUメッセージは、登録側データベースに記憶された最初のレコードを示す先頭レコード番号フィールドと、登録側データベースに記憶された最後のレコードを示す最終レコード番号フィールドとを含む。また、レコードヘッダは、登録側データベースに記憶されたレコードを示すレコード番号と、登録側データベースに記憶されたレコードに含まれる更新を識別するシーケンス番号とを含む。
ブロック1005において、少なくとも1つの更新されたレコードは、ブロック1003の部分リスト及び/又は完了リストLRPDUメッセージのレコードヘッダに基づいて、登録側データベースによる確認応答済みとして、申請側データベースにおいてマーキングされる。
ブロック1007において、ポータル/申請側は、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたと決定してもよい。申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたというブロック1007の決定に基づいて、ブロック1009において、ポータル/申請側は、申請側データベースが登録側データベースと同期していることをアプリケーションに通知する。
いくつかの場合、レコードLRPDUメッセージは、登録側に到達しない可能性があり、及び/又は、部分リストLRPDUメッセージが申請側に戻る途中で欠落する可能性がある。このような場合、任意選択のブロック1011において、ポータルは、対応する部分リストLRPDUメッセージを受信することなく、レコードLRPDUメッセージタイマが終了したとき、アプリケーションへの障害通知を生成する。
ブロック1013もまた任意選択である。いくつかの例では、ポータル/申請側は、要求完了リストLRPDUメッセージを登録側データベースに送信するように構成できる。登録側/隣接ポータルは、完了リストLRPDUメッセージで応答する。したがって、ローカルノード上のポータル/申請側は、要求完了リストLRPDUメッセージに応じて、登録側データベースから完了リストLRPDUメッセージを受信する。
図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について、説明の明確性のため、申請側データベースを動作するローカルノードの観点から説明するが、登録側を動作するノード(例えば、ローカルノード又は隣接ノード)上で全体的に或いは部分的に動作されてもよい。
方法1100は、ハローLRPDUメッセージの交換が失敗したときに始まり、これは接続中断を示す。ブロック1101において、切断コードがアプリケーションについて生成される。切断コードは、ハローLRPDUメッセージの交換が失敗したことを示す。これはまた、隣接ノード/登録側への更なるメッセージが受信されない可能性があり、前の未確認応答のメッセージが登録側に到達していない可能性があることを示す。
申請側は、接続の再確立のときにデータベース対をリセットすることを決定できる。このような場合、方法900が使用される。しかし、申請側はまた、接続が再確立されたとき、現在の申請側データベースを登録側データベースと再同期させることを決定してもよい。このような場合、ブロック1103において、ポータルは、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信する。
ブロック1105において、ポータルは、ハローメッセージの失敗した交換の後に、申請側データベースにおいて通知タイマをリセットする。これは、接続が再確立された後に、完了リストLRPDUメッセージが受信されるまで、レコードLRPDUメッセージの送信を防止する。
ハローLRPDUメッセージは、接続を再確立することを試みて、周期的に送信できる。登録側データベースが切断の後にハローLRPDUメッセージを受信したとき、登録側は、完了リストLRPDUメッセージで応答する。したがって、ブロック1107において、隣接ノードの登録側データベースからの完了リストLRPDUメッセージは、ハローLRPDUメッセージの成功した交換の後に、申請側/ポータルにより受信される。完了リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。
ブロック1109において、ポータル/申請側は、申請側データベースを登録側データベースと再同期させるために、完了リストLRPDUメッセージからのレコードヘッダを申請側データベースに記憶されたレコードヘッダと比較する。具体的には、ブロック1111において、ポータル/アプリケーションは、完了リストLRPDUメッセージ内のレコードヘッダと申請側データベース内のレコードヘッダとの間にレコードの不一致が存在するか否かを決定する。
ポータル/申請側が、申請側データベース内の1つ以上のレコードヘッダと完了リストLRPDUメッセージからの1つ以上のレコードヘッダとの間の不一致を決定したとき、方法1100はブロック1113に進む。不一致は、少なくとも1つの前のレコードLLRPDUメッセージが失われたことを示す。したがって、申請側は、どのレコード更新が完了リストLRPDUメッセージにおいて表されていないかを決定する。ブロック1113において、申請側/ポータルは、1つ以上のレコードLRPDUメッセージを登録側データベースに送信する。レコードLRPDUメッセージは、不一致に対処してデータベース対を同期させるために、必要に応じて更新されたレコードヘッダを含む。
ポータル/申請側が、申請側データベース内のレコードヘッダと登録側データベースからのレコードヘッダとの間に不一致が存在しないと決定したとき、方法1100はブロック1115に進む。不一致がないという決定に基づいて、ブロック1115において、ポータル/申請側は、申請側データベースが登録側データベースと同期していることをアプリケーションに通知できる。
図12は、当該開示の実施形態によるデータベース同期を管理するための例示的なネットワークノード1200の概略図である。ネットワークノード1200は、ここに記載されるような開示の例/実施形態を実装するのに適している。例えば、ネットワークノード1200は、ネイティブシステム110/130、プロキシ210/230、スレーブ240/250、これらの組み合わせ、及び/又はここに記載のいずれかのローカルノード及び/又は隣接ノードを実装するために使用されてもよい。例えば、ネットワークノード1200は、データベースシステム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デバイスはまた、キーボード、マウス、トラックボール等のような入力デバイス、及び/又はこのような出力デバイスと相互作用するための対応するインタフェースを含んでもよい。
プロセッサ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により(例えば、非一時的な媒体に記憶されたコンピュータプログラム製品として)実行できる。
メモリ1232は、ディスク、テープドライブ、ソリッドステートドライブ、読み取り専用メモリ(read only memory, ROM)、ランダムアクセスメモリ(random access memory, RAM)、フラッシュメモリ、三値連想メモリ(ternary content-addressable memory, TCAM)、スタティックランダムアクセスメモリ(static random-access memory, SRAM)等のような1つ以上のメモリタイプを含む。メモリ1232は、プログラムが実行のために選択されたときにこのようなプログラムを記憶し、プログラム実行中に読み取られる命令及びデータを記憶するために、オーバーフローデータ記憶デバイスとして使用されてもよい。
図13は、データベース対を確立するための例示的なデバイス1300の概略図である。デバイス1300は、方法400及び/又は方法900を実装するために使用できる。デバイス1300は、AppIdと、ローカルノードと隣接ノードとの間のターゲットリンクとを含むハローメッセージを受信するための受信モジュール1301を含む。デバイス1300はまた、AppIdがデータベース同期を実行するためのアプリケーションに関連付けられると決定するための決定モジュール1303を含む。デバイス1300はまた、アプリケーションによる使用のためにデータベース対の一部として、ローカルノードにローカルデータベースを設定するためのデータベース対設定モジュール1305を含み、データベース対は隣接ノードの隣接データベースを含む。デバイス1300はまた、データベース対をターゲットリンクに関連付けるための関連付けモジュール1307を含む。デバイスはまた、ターゲットリンクを介して、隣接データベースとのローカルデータベースの同期を制御するための同期制御モジュール1309を含む。
図14は、データベース対の同期を管理するための例示的なデバイス1400の概略図である。デバイス1400は、方法400及び/又は方法1000を実装するために使用できる。デバイス1400は、1つ以上のレコードLRPDUメッセージを隣接ノードの登録側データベースに送信するための送信モジュール1401を含み、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す。デバイス1400はまた、レコードLRPDUメッセージを確認応答する1つ以上のLRPDUメッセージを受信するための受信モジュール1403を含む。デバイス1400はまた、登録側データベースによる確認応答済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリモジュール1405を含む。デバイス1400はまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたことを決定するための決定モジュール1407を含む。デバイス1400はまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知モジュール1409を含む。
図15は、接続中断にもかかわらずデータベース同期を維持するための例示的なデバイス1500の概略図である。デバイス1500は、方法400及び/又は方法1100を実装するために使用できる。デバイス1500は、アプリケーションのための切断コードを生成するための切断モジュール1501を含み、切断コードは、ハローLRPDUメッセージの交換が失敗したことを示す。デバイス1500はまた、アプリケーションから、切断コードにもかかわらずローカルノードのメモリにおいて申請側データベースを維持するためのコマンドを受信するためのコマンドモジュール1503を含む。デバイス1500はまた、ハローメッセージの成功した交換の後に、隣接ノードの登録側データベースから完了リストLRPDUメッセージを受信するための受信モジュール1505を含み、完了リストLRPDUメッセージは、登録側データベースの全てのレコードのレコードヘッダを含む。デバイス1500はまた、申請側データベースを登録側データベースと再同期させるために、完了リストLRPDUメッセージからのレコードヘッダを申請側データベース内のレコードヘッダと比較するためのレコード比較モジュール1507を含む。
一実施形態では、ノード又はエレメントは、1つ以上のレコードリンクローカル登録プロトコルデータユニット(LRPDU)メッセージを隣接ノードの登録側データベースに送信するための送信手段であり、レコードLRPDUメッセージは、ローカルノードの申請側データベースに記憶されたレコードへの更新を示す、送信手段と、レコードLRPDUメッセージを確認応答する1つ以上のLRPDUメッセージを受信するための受信手段とを含む。ノード又はエレメントは、登録側データベースによる確認応答済みとして、申請側データベース内の少なくとも1つの更新されたレコードをマーキングするためのメモリ手段を更に含む。ノード又はエレメントはまた、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたと決定するための決定手段と、申請側データベース内の全ての更新されたレコードがLRPDUメッセージを介して登録側データベースにより確認応答されたという決定に基づいて、申請側データベースが登録側データベースと同期していることをアプリケーションに通知するための通知手段とを含む。
第1のコンポーネントと第2のコンポーネントとの間のライン、トレース又は他の媒体を除いて、介在するコンポーネントが存在しないとき、第1のコンポーネントは第2のコンポーネントに直接的に結合される。第1のコンポーネントと第2のコンポーネントとの間にライン、トレース又は他の媒体以外の介在するコンポーネントが存在するとき、第1のコンポーネントは第2のコンポーネントに間接的に結合される。用語「結合される」及びその変形は、直接的に結合されること及び間接的に結合されることの双方を含む。用語「約」の使用は、別段の指定のない限り、以降の数の±10%を含む範囲を意味する。
いくつかの実施形態が本開示において提供されているが、開示のシステム及び方法は、本開示の真意又は範囲から逸脱することなく、多くの他の具体的な形式で実現されてもよいことが理解され得る。本例は、例示的なものであり、限定的なものではないと考えられるべきであり、その意図は、ここに与えられる詳細に限定されるものではない。例えば、様々なエレメント又はコンポーネントは、他のシステムに組み合わされても或いは統合されてもよく、或いは、特定の特徴が省略されても或いは実装されなくてもよい。
さらに、様々な実施形態において個別のもの又は別個のものとして記載及び図示された技術、システム、サブシステム及び方法は、本開示の範囲から逸脱することなく、他のシステム、コンポーネント、技術又は方法と組み合わされても或いは統合されてもよい。変更、置換及び代替の他の例は、当業者により確かめられることができ、ここに開示された真意及び範囲から逸脱することなく行われてもよい。