(57)【要約】【課題】例示の側面において、クロック・オフセットの判断に適した方法、装置、及びプログラム製品を提供する。【解決手段】一方法は、少なくとも単一バイトの、いくつかのやり取りを、別のネットワーク・ノードと実行するステップを含み、単一バイトの値は、やり取りそれぞれに関して異なる。本方法はさらに、ネットワーク・ノード上で実行される該いくつかのやり取りそれぞれのタイムスタンプを獲得及び記憶するステップを含む。第２の方法は、一組のタイミング・メッセージのうち、別のネットワーク・ノードから受信されるいくつかのタイミング・メッセージそれぞれの到着タイムスタンプを獲得及び保存するステップを含む。この第２の方法はさらに、一組のタイミング・メッセージの完了に応答して、少なくとも該別のノードに、タイムスタンプを送信するステップを含む。【選択図】図２
2013509814.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク・ノード上で実行される方法であって、
少なくとも単一バイトの、複数のやり取りを、別のネットワーク・ノードと実行するステップであって、前記単一バイトの値は、前記やり取りそれぞれに関して異なる、前記ステップと、
前記ネットワーク・ノード上で実行される前記複数のやり取りそれぞれのタイムスタンプを獲得及び記憶するステップと、
を含む方法。
【請求項２】
前記別のネットワーク・ノード上で実行された前記複数のやり取りそれぞれに対応するタイムスタンプを、前記別のネットワーク・ノードから受信するステップをさらに含む、請求項１に記載の方法。
【請求項３】
少なくとも部分的に前記タイムスタンプに基づいて、前記ネットワーク・ノード間の複数の移送時間を測定するステップと、少なくとも前記移送時間に基づいて、前記ネットワーク・ノードのクロック・オフセットを判断するステップとをさらに含む、請求項１に記載の方法。
【請求項４】
前記ネットワーク・ノードは、クライアントを含み、前記別のネットワーク・ノードは、サーバを含む、請求項３に記載の方法。
【請求項５】
前記やり取り毎に、前記単一バイトの前記値を変更するステップをさらに含む、請求項１に記載の方法。
【請求項６】
一組の前記複数のやり取りの完了を示す所定値を有する単一バイトを受信することに応答して、前記記憶されたタイムスタンプすべてを前記別のネットワーク・ノードに送るステップをさらに含む、請求項１に記載の方法。
【請求項７】
所定期間中に単一バイトが受信されないことに応答して、タイムアウトが発生したと判断するステップと、前記タイムアウトを示す所定値を有する単一バイトを前記別のネットワーク・ノードに送るステップとをさらに含む、請求項１に記載の方法。
【請求項８】
前記複数のやり取りの所定数があり、前記タイムアウトは、前記所定数に満たないやり取りが発生している状態で発生し、前記方法は、前記タイムスタンプを前記別のネットワーク・ノードに送るステップ、又は前記別のネットワーク・ノード上で実行された前記複数のやり取りそれぞれのタイムスタンプを前記別のネットワーク・ノードから受信するのを待つステップのうちの１つをさらに含む、請求項７に記載の方法。
【請求項９】
前記単一バイトの前記値は、各やり取りの最中に、又は、各やり取りの合間に変更される、請求項１に記載の方法。
【請求項１０】
少なくとも単一バイトの、複数のやり取りを、別のネットワーク・ノードと実行するように構成されているネットワーク・ノードであって、前記単一バイトの値は、前記やり取りそれぞれに関して異なり、前記ネットワーク・ノードは、前記ネットワーク・ノード上で実行される前記複数のやり取りそれぞれのタイムスタンプを獲得及び記憶するように構成されている、ネットワーク・ノード。
【請求項１１】
前記ネットワーク・ノードは、前記別のネットワーク・ノード上で実行された前記複数のやり取りそれぞれに対応するタイムスタンプを、前記別のネットワーク・ノードから受信するようにさらに構成されている、請求項１０に記載のネットワーク・ノード。
【請求項１２】
前記ネットワーク・ノードは、少なくとも部分的に前記タイムスタンプに基づいて、前記ネットワーク・ノード間の複数の移送時間を測定し、少なくとも前記移送時間に基づいて、前記ネットワーク・ノードのクロック・オフセットを判断するようにさらに構成されている、請求項１１に記載のネットワーク・ノード。
【請求項１３】
前記ネットワーク・ノードは、クライアントを含み、前記別のネットワーク・ノードは、サーバを含む、請求項１２に記載のネットワーク・ノード。
【請求項１４】
前記ネットワーク・ノードは、前記やり取り毎に、前記単一バイトの前記値を変更するようにさらに構成されている、請求項１０に記載のネットワーク・ノード。
【請求項１５】
前記ネットワーク・ノードは、一組の前記複数のやり取りの完了を示す所定値を有する単一バイトを受信することに応答して、前記記憶されたタイムスタンプすべてを前記別のネットワーク・ノードに送るようにさらに構成されている、請求項１０に記載のネットワーク・ノード。
【請求項１６】
前記ネットワーク・ノードは、所定期間中にバイトが受信されないことに応答して、タイムアウトが発生したと判断し、前記タイムアウトを示す所定値を有するバイトを前記別のネットワーク・ノードに送るようにさらに構成されている、請求項１０に記載のネットワーク・ノード。
【請求項１７】
前記複数のやり取りの所定数があり、前記タイムアウトは、前記所定数に満たないやり取りが発生している状態で発生し、前記ネットワーク・ノードは、前記タイムスタンプを前記別のネットワーク・ノードに送ること、又は前記別のネットワーク・ノード上で実行された前記複数のやり取りそれぞれのタイムスタンプを前記別のネットワーク・ノードから受信するのを待つことのうちの１つを実行するようにさらに構成されている、請求項１６に記載のネットワーク・ノード。
【請求項１８】
前記ネットワーク・ノードは、前記単一バイトの前記値を、各やり取りの最中に、又は、各やり取りの合間に変更するようにさらに構成されている、請求項１０に記載のネットワーク・ノード。
【請求項１９】
ネットワーク・ノード上で実行される方法であって、
一組のタイミング・メッセージのうち、別のネットワーク・ノードから受信される複数のタイミング・メッセージそれぞれの到着タイムスタンプを獲得及び保存するステップと、
前記一組のタイミング・メッセージの完了に応答して、前記タイムスタンプを少なくとも前記別のノードに送信するステップと、
を含む方法。
【請求項２０】
前記方法は、単一バイトを有するタイミング・メッセージの、複数のやり取りを、前記別のネットワーク・ノードと実行するステップをさらに含み、前記単一バイトの値は、前記やり取りそれぞれに関して異なり、前記獲得及び保存は、前記ネットワーク・ノードにて受信される前記単一バイトそれぞれに関して発生する、請求項１９に記載の方法。
【請求項２１】
タイミング・メッセージ内で受信される単一バイトは、値の変更はされずに前記別のノードに送り返される、請求項２０に記載の方法。
【請求項２２】
所定値を有する単一バイトをタイミング・メッセージが含むと判断することによって、前記一組のタイミング・メッセージの完了を判断するステップをさらに含む、請求項１９に記載の方法。
【請求項２３】
一組のタイミング・メッセージのうち、別のネットワーク・ノードから受信される複数のタイミング・メッセージそれぞれの到着タイムスタンプを、獲得及び保存するように構成されているネットワーク・ノードであって、前記一組のタイミング・メッセージの完了に応答して、前記タイムスタンプを少なくとも前記別のノードに送信するように構成されている、ネットワーク・ノード。
【請求項２４】
前記ネットワーク・ノードは、単一バイトを有するタイミング・メッセージの、複数のやり取りを、前記別のネットワーク・ノードと実行するようにさらに構成されており、前記単一バイトの値は、前記やり取りそれぞれに関して異なり、前記ネットワーク・ノードは、前記ネットワーク・ノードにて受信される前記単一バイトそれぞれに関して、前記獲得及び保存が発生するように構成されている、請求項２３に記載のネットワーク・ノード。
【請求項２５】
前記ネットワーク・ノードは、タイミング・メッセージ内で受信される単一バイトが値の変更はされずに前記別のノードに送り返されることを生じさせるように構成されている、請求項２４に記載のネットワーク・ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的に、ネットワークに関し、特に、ネットワーク・ノードのクロック・オフセットを測定することに関する。
【背景技術】
【０００２】
クロック同期に対するソフトウェアのみのソリューションが、避けられない「システム・ノイズ」（プロセス・ディスパッチング、割り込み処理など）の影響を受け、これが精度を１０マイクロ秒以上に制限することは、広く認識されている。マイクロ秒レベルの同期が必要な場合は、例えば通信リンクの両端にありＩＥＥＥ  １５８８（高精度時間プロトコル）サポートを備えるネットワーク・アダプタなど、ハードウェア・ソリューションが採用される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
図１に示されているように、典型的なソフトウェア・タイムスタンプのやり取り（ｅｘｃｈａｎｇｅ）は、クライアント・ノードＡに、タイムスタンプＴ１をサーバ・ノードＢへ送信させ、それをサーバ・ノードＢが時間Ｔ２に受信する。続いて、サーバ・ノードＢは、時間Ｔ３に応答を送信し、それをクライアント・ノードＡが時間Ｔ４に受信する。Ｔ１及びＴ４は、クライアント・ノードＡのクロックを使用して測定され、Ｔ２及びＴ３は、サーバ・ノードＢのクロックに基づいて測定される。この情報から、クライアントＡ及びサーバＢのクロック間のオフセットを判断できるが、ソフトウェア並びにハードウェア遅延が、高ジッタの一因となる。ＩＥＥＥ  １５８８は、ハードウェア・レベルでのタイムスタンプを利用し、それらのタイムスタンプを収集するインターフェイスを提供する。しかし、ＩＥＥＥ  １５８８のようなハードウェア実装は、ソフトウェア実装よりも高価であり、変更がより難しい。
【０００４】
したがって、こうした制限を打開する技術を提供することが望ましいと考えられる。
【課題を解決するための手段】
【０００５】
本発明の例示の側面では、ネットワーク・ノード上で実行される方法が開示される。方法は、少なくとも単一バイト（ｓｉｎｇｌｅ  ｂｙｔｅ）の、いくつかのやり取りを、別のネットワーク・ノードと実行するステップを含み、単一バイトの値は、やり取りそれぞれに関して異なる。方法はさらに、ネットワーク・ノード上で実行される該いくつかのやり取りそれぞれのタイムスタンプを獲得及び記憶するステップを含む。
【０００６】
別の例示の側面では、少なくとも単一バイトの、いくつかのやり取りを、別のネットワーク・ノードと実行するように構成されているネットワーク・ノードが開示され、単一バイトの値は、やり取りそれぞれに関して異なる。ネットワーク・ノードはさらに、ネットワーク・ノード上で実行される該いくつかのやり取りそれぞれのタイムスタンプを獲得及び記憶するように構成されている。
【０００７】
別の側面では、ネットワーク・ノード上で実行される方法が開示される。方法は、一組のタイミング・メッセージ（ｔｉｍｉｎｇ  ｍｅｓｓａｇｅ）のうち、別のネットワーク・ノードから受信されるいくつかのタイミング・メッセージそれぞれの到着タイムスタンプを獲得及び保存するステップを含む。本方法はさらに、一組のタイミング・メッセージの完了に応答して、少なくとも該別のノードにタイムスタンプを送信するステップを含む。
【０００８】
さらなる例示の側面では、一組のタイミング・メッセージのうち、別のネットワーク・ノードから受信されるいくつかのタイミング・メッセージそれぞれの到着タイムスタンプを獲得及び保存するように構成されており、一組のタイミング・メッセージの完了に応答して、タイムスタンプを少なくとも該別のノードに送信するように構成されている、ネットワーク・ノードが開示される。
【０００９】
本発明の実施形態の前述した側面及びその他の側面は、以下の例示の実施形態の詳細な説明を添付の図面と併せて読むことで、より明確になる。
【図面の簡単な説明】
【００１０】
【図１】タイムスタンプをやり取りする既存の方法を示す。
【図２】２つのネットワーク・ノード間の通信を示すハードウェア・ブロック図を示す。
【図３】通常動作のもとでの、クロック・オフセット測定を実行する例示のプロトコルを示す。
【図４】クライアントがタイムアウトする場合の、クロック・オフセット測定を実行する例示のプロトコルを示す。
【図５】サーバがタイムアウトする場合の、クロック・オフセット測定を実行する例示のプロトコルを示す。
【図６】サーバがタイムアウトする場合の、クロック・オフセット測定を実行する例示のプロトコルを示す。
【図７】通常動作のもとでの、クライアントの状態及びアクションの図である。
【図８】例外動作のもとでの、クライアントの状態及びアクションの図である。
【図９】通常動作のもとでの、サーバの状態及びアクションの図である。
【図１０】例外動作のもとでの、サーバの状態及びアクションの図である。
【図１１】クロック・オフセット測定を実行する例示のフロー図である。
【発明を実施するための形態】
【００１１】
例示の実施形態では、絶対最小限まで減らされた「ｐｉｎｇ  ｐｏｎｇ」の一連のやり取りを使用する、クロック・オフセット測定の新たな技術が開示される。各やり取りは、単一バイトを含み、単一バイトは、各やり取りに関して異なり（例えば、デクリメントする残メッセージ数）、その単一バイトが一連のやり取りの中の最後のやり取りであるかどうかを判断するために使用され得る。やり取りの各側のネットワーク・ノードは、個別に到着及び発信タイムスタンプを記録し、収集されたタイムスタンプは、やり取りの終わりに、例えば非タイム・クリティカル・メッセージ内でもう一方の側に返される（ネットワーク・ノードの１つ又は両方に関して）。実施形態では、タイムアウト後にまだ別のパケットが予想されるかどうかがバイトのやり取りの各側に分かるよう、さらにそのような遅延したパケットが１つしかあり得ないよう、プロトコル実装によって保証される。これは、タイムアウト回復を大きく単純化し、タイムアウト後に不確実性によりリンクの再初期化（唯一ではないが、最も単純な回復方法）が必要とされることがなくなる。
【００１２】
単一バイトのやり取り（例示の実施形態における）のさらなる利点には、次に限定はされないが、こうしたやり取りが、リモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ：Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）のケースにおいて、単純なデータ駆動型のスピン・ループの使用を可能にするということがある。ターゲット・バイトが変化するとすぐに、応答バイトを送信することができ、完了ステータスのポーリングを最初に行う必要がない。これは、ＩｎｆｉｎｉＢａｎｄ（ＴＭ）（主として高性能コンピューティングで使用される通信リンク）の例示のケースでは、既に低いレイテンシを少なくともマイクロ秒は削減できる。
【００１３】
以下、図２を参照する。この図面は、２つのネットワーク・ノード、クライアント１００及びサーバ２００のハードウェア・ブロック図を示す。図のように、クライアント１００は、１つ以上のメモリ１０３にアクセスするよう構成された１つ以上のプロセッサ１０１を含み、メモリ１０３は、コンピュータ・プログラム１０２を含む。さらに、クライアント１００はクロック１０９を含む。同じく、サーバ２００は、１つ以上のメモリ２０３にアクセスするよう構成された１つ以上のプロセッサ２０１を含み、メモリ２０３は、コンピュータ・プログラム２０２を含む。サーバ２００は、クロック２０９を含む。クライアント及びサーバは、各側にあるリンク・アダプタ１０４／２０４によって制御される物理リンク３００上で、ネットワーク３１０を介して通信する。例示の実施形態では、メモリ１０３／２０３内の情報は、ダイレクト・メモリ・アクセス（ＤＭＡ：Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）によって各メモリ１０３／２０３間で伝達可能であり、リンク３００を介した２つのメモリ間の相互作用が、本発明の特定の実施形態に有用なプロトコルであるリモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）プロトコルを可能にする。なお、リンク３００上でデータをやり取りするために他のプロトコルが使用されてもよい。クライアント１００のクロック１０９と、サーバ２００のクロック２０９との間のクロック・オフセットが、本願明細書の例示の実施形態において判断される。なお、本発明の各側面は、任意の２つのネットワーク・ノードに有効であり、サーバ２００及びクライアント１００に限定されない。
【００１４】
さらに、１つ以上のメモリ１０３は、この非限定的な例では、移送時間（ｔｒａｎｓｐｏｒｔ  ｔｉｍｅ）１０５、移送遅延、及びクロック・オフセット１０７を表すデータを含む。これらは、下記にさらに詳しく記載される。さらに、サーバ２００は、その１つ以上のメモリ２０３内に、移送時間１０５、移送遅延、及びクロック・オフセット１０７を表すデータ（図２には示されていない）を含むとよい。下記にさらに詳しく記載するように、タイムスタンプもメモリ１０３／２０３内に存在するとよい。
【００１５】
プログラム１０２／２０２は、その個別の１つ以上のプロセッサ１０１／２０１によって実行されると、本願明細書に記載されているアクションを実行するようクライアント１００及びサーバ２００を構成する。具体的には、図３〜１０のアクションの何れかが、個別のプログラム１０２／２０２によって構成される、構成されたクライアント１００／サーバ２００によって実行されるとよい。
【００１６】
本発明の例示の実施形態は、サーバ２００上で実行されるプログラム２０２を含み、これはクライアント１００上で実行されているプログラム１０２と通信している。サーバ２００及びクライアント１００は、クライアント・オフセット測定プロセスを開始するよう協調する。一実施形態では、この協調には、ｐｉｎｇ  ｐｏｎｇメッセージのやり取り中にタイムスタンプ測定を収集するやり取りのシーケンスを開始するための、クライアント１００からの「ドアベル」（又は「ｉｎｉｔ」）要求を、サーバ・プログラム２０２が待つことが含まれる。実施形態は、サーバ２００が要求の受信通知を行う（ＡＣＫ：ａｃｋｎｏｗｌｅｄｇｅ）ことを求めても、求めなくてもよい。サーバ２００並びにクライアント１００の両方からのこれらのタイムスタンプが、クライアント及びサーバのクロック間の相対スキュー及びオフセットを推定するために使用される。この例では、クライアント・プログラム１０２が、ｐｉｎｇ  ｐｏｎｇメッセージのやり取りを開始する。ｐｉｎｇ  ｐｏｎｇやり取り中、クライアントとサーバとの間の各メッセージ内で、１つの単一バイトが送信される。図面に示されている実施形態では、バイトの値は、やり取りされる残りのパケットよりも１大きく、零は、別個の意味を有し、送信側がタイムアウトとなったため厳密にもう１つの応答が予想されることを示す。なお、本発明は、これに限定されない。例示の実施形態では、クライアント・プログラム１０２が、各往復の後にバイトをデクリメントすることを担当する。サーバ２００（例えばプログラム２０２）は、サーバ２００が単一バイトを受信するたびにタイムスタンプを記録する。一実施形態では、サーバ２００は、同じバイトをクライアントに返送する。バイトが１（一）又は０（零）と等しければ、サーバ２００は、現在のｐｉｎｇ  ｐｏｎｇやり取り中にサーバ２００が収集したすべてのタイムスタンプを、すぐに（例えば）返送する。クライアント１００が１の値を有するバイトを送信した後、クライアント１００は、サーバ２００からの次のメッセージが、単一バイトではなくすべてのタイムスタンプを含むと予想する。
【００１７】
例示の実施形態では、実装は、リンク３００を使用する信頼性のある通信チャネルの上に構築される通信プロトコルとしてもたらされる。例示のプロトコル（及びフロー図）が、図３に示されている。すべてのメッセージは、送信される順序で配送され、配送には遅延がある可能性がある。メッセージ配送の遅延の可能性があるため、例示の実施形態では、クライアント及びサーバ・プログラムの両方がタイムアウト・メカニズムを使用して、過度に長いｐｉｎｇ  ｐｏｎｇやり取りを防ぐ。例示のタイムアウト・メカニズムは、下記に記載されている。
【００１８】
図３は、上記の例示のシナリオを示す。図３の例では、４つのｐｉｎｇ  ｐｏｎｇやり取りがスケジュールされている。クライアント１００は、４（四）つのｐｉｎｇ  ｐｏｎｇやり取りを要求することによって、サーバ２００と協調してクロック・オフセット測定プロセスを開始し、この例では、サーバ２００は、受信通知（ＡＣＫ）を用いて応答する。
【００１９】
続いて、クライアント１００とサーバ２００との間のタイミング・メッセージの第１のやり取りを行うことによって、クロック・オフセット測定プロセスが開始する。やり取りは、クライアント１００が、４（四）の値を有するバイト３１０−１を送信すること、及びこのバイト３１０−１をサーバ２００が受信することを含む。クライアント１００は、クライアント・タイムスタンプＴ１を獲得及び記憶し、サーバは、サーバ・タイムスタンプＴ２を獲得及び記憶する。やり取りは、サーバ２００が、バイト３１０−１をクライアント１００に返送することで完結する。クライアント１００は、クライアント・タイムスタンプＴ３を獲得及び記憶し、続いて第２のやり取りに移る。クライアント・タイムスタンプＴ３の獲得及び記憶は、第１又は第２のやり取りの一部と見なされ得る。
【００２０】
第２のやり取りは、３（三）の値を有するバイト３１０−２をまず送信、続いて受信すること、サーバ・タイムスタンプＴ４を獲得及び記憶すること、バイト３１０−２を送信及び受信すること、並びにクライアント・タイムスタンプＴ５を獲得及び記憶することを含む。第３及び第４のやり取りは、２（二）及び１（一）の値をそれぞれ有するバイト３１０−３及び３１０−４のやり取り、並びにタイムスタンプＴ６、Ｔ７、Ｔ８及びＴ９の記憶を含む。
【００２１】
所定数のやり取りの完了に応答して、サーバ２００は、サーバ・タイムスタンプＴ２、Ｔ４、Ｔ６、及びＴ８をクライアント１００に送信する。図３の例では、完了は、１（一）の値を有するバイト３１０の受信及び送信によって、サーバ２００により判断される。
【００２２】
なお、やり取りされる単一バイトは、単一バイト・データ・ペイロードを含むタイミング・メッセージであり、タイミング・メッセージを含むパケットは、追加の情報を有してもよい。さらに、少なくとも、場合により生じ得る一部の追加処理が単一バイトによってなくなることが理由で、単一バイトの単一要素を送信することは有益である。例えば、メッセージが１つのコンピュータから別のコンピュータへ送信されるとき、例えば「エンディアンネス」が理由で、コンピュータの１つがメッセージ内のバイトの順序を変更しなければならないこともある。当該技術分野で既知であるように、「エンディアンネス」は、データを表すために使用されるバイトの（又はより大きなメモリ要素）の順序付けである。例えば、Ａ及びＢの２バイト（したがって１ワードを構成する）は、ＡＢとして、又はＢＡとして記憶され得る。ＢＡを受信するネットワーク・ノードは、その特定のネットワーク・ノード上で使用するために、バイトがＡＢに入れ替えられる必要があると判断しなければならないことになる。単一バイトのみがある場合、コンピュータそれぞれがどのエンディアンネスを使用するかは問題にならない。したがって、ワード又はダブル・ワードなどの単一メモリ要素を送信すると、エンディアンネスへの対処が求められる。とはいえ、実装がこの処理を行うことができるのであれば、ワード及びダブル・ワードの別の単一要素が使用されてもよい。ＴＣＰ／ＩＰ（ｔｒａｎｓｍｉｓｓｉｏｎ  ｃｏｎｔｒｏｌ  ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ：伝送制御プロトコル／インターネット・プロトコル）を使用するネットワークに関しては、エンディアンネスの問題を回避する利点は、主として単純さであり、性能影響は、典型的にはごくわずかである。エンディアンネスは、ｐｉｎｇ  ｐｏｎｇやり取りの最後にタイムスタンプを送るときには考慮されなければならないため、この問題を完全に回避することはできない。しかし、ＲＤＭＡを使用するネットワークに関しては、単一バイト・スピン・ループ能力は、技術的観点からはるかに重要であり、測定可能な性能改善につながる可能性がある。
【００２３】
なお、図３のプロトコルは、単なる例示であり、多数の変更がこのプロトコルに加えられることが考えられ、それでも本発明の例示の実施形態の範囲内である。さらなる例示の実施形態では、クライアント１００は、やり取りと、やり取りとの間に、バイト３１０内の数をデクリメントする。別の実施形態では、クライアント１００は、前のバイト３１０を送信するのに応答して、伝送する次の数を用意する。例えば、バイト３１０−１が送信された後、クライアント１００は、サーバ２００からバイト３１０−１が受信されるとすぐに送信できるよう、値３（三）を備える別のバイトを準備することができるであろう。別の例では、クライアント１００は、適切な値を備えた４つのバイトを準備して、続いてこれらをバイト３１０として伝達することができるであろう。さらに、クライアント１００は、バイト３１０内の数の値をインクリメントすること、又はバイトを準備するために他の何らかの数学的若しくは論理的演算（例えばシフト）を使用することができるであろう。
【００２４】
決定されるバイト３１０内の値にかかわらず、各やり取りに関してバイト３１０の値が異なると有益である。そうでなければ、バイト３１０の受信の順序が分からないと考えられる。図３の例示の実施形態では、各バイト３１０が、１つのやり取りにおいて同じ値を有するが、これも、クライアント１００及びサーバ２００が、各バイトの受信の順序を認識できるような形で変更されることが可能である。例えば、クライアント１００は、８（八）の値を有するバイト３１０を送信することが可能であり、サーバ２００が、このバイトをデクリメントして、７（七）の値を有するバイト３１０をクライアント１００に返送する。次のやり取りは、６（六）（クライアント１００から）及び５（五）（サーバ２００から）の値を伴うことになる。バイト３１０の値は、やはり各やり取りの間で異なる。異なるバイトの値は、（１）通常のやり取りと、リモート・タイムアウトとを区別すること、及び（２）バイトの変化を検出するスピン・ループを可能にすることの２つの目的に役立つ。提示されるプロトコルは、順序どおりの配送を前提とするため、順序の狂った配送は、典型的には問題とならない。
【００２５】
図３に示されているプロトコルの使用は、特定の例示の実施形態において、限定はされないが以下の利点を含む。
１）より低いレイテンシにより、クロック・スキュー及びオフセットの推定が改善し、同期精度の向上につながる。
２）両ノードで同時に実行が発生する間にネットワーク・メッセージがやり取りされる。
３）単一バイト・パケット・ペイロードのみを使用することによって、タイミングやり取りのメッセージが単純化され、ネットワーク・バイト順序又は一貫性に関連する問題がなくなる。これはさらに、ＲＤＭＡネットワークの場合、時間依存のメッセージのやり取り中に受信完了通知を待つ必要をなくす。
４）タイミング・メッセージのやり取りが、タイムスタンプの収集から切り離される。各ネットワーク・ノードは、単一バイト・メッセージの到着及び発信時間を記録し、一連の単一バイト・メッセージのやり取りの完了時に、もう一方のノードと到着／発信時間がやり取りされる。
５）この手法のソフトウェア実装は、他のハードウェア時間同期手法と比較して、費用の削減、並びにインストール、アップグレード、及びメンテナンスの容易さという、さらなる利点を有する。
【００２６】
したがって、図３のプロトコルの例では、タイミング・メッセージのやり取りは、クライアント及びサーバ・ノードの間でタイムスタンプ収集から切り離される。さらに、タイミング・メッセージは、もう一方のノードからの到着タイムスタンプを含まない。集中的なやり取りでは、応答は即時のはずであるため、１つのタイムスタンプが、バイトの到着及び応答の発信を表すことができる。集中的な単一バイト・タイミング・メッセージが、クライアントとサーバ・ノードとの間で送信され、やり取りの最後のバイト以外のすべてに対し即時応答される。集中的なタイミング・メッセージのやり取りが完了した後、各タイミング・メッセージの、一組の到着時間がやり取りされる。
【００２７】
上記のように、例示の通信プロトコルは、信頼性のある通信チャネルの上に構築される。すべてのメッセージは、送信された順序で配送され、配送には遅延がある可能性がある。メッセージ配送の遅延の可能性があるため、クライアント及びサーバ・プログラムの両方がタイムアウト・メカニズムを使用して、過度に長いｐｉｎｇ  ｐｏｎｇやり取りを防ぐ。以下、例示のタイムアウト・メカニズムについて説明する。
【００２８】
もう一方の側からのｐｉｎｇ  ｐｏｎｇ応答を待っている（例えば、この待ち状態のノードは１より大きい値を備えるバイトを送信した）間にクライアント１００又はサーバ２００がタイムアウトすると、この待ち状態のノードは、所定値を備えるバイト（この例では、零の値を備えるバイト）を送信してタイムアウトを示し、現在のｐｉｎｇ  ｐｏｎｇやり取りを終了する。タイムアウトは、単一バイトが所定期間内にネットワーク・ノードに到着しなかったときに発生する状態である。
【００２９】
図４を参照する。この図面は、クライアントがタイムアウトする場合の、クロック・オフセット測定を実行する例示のプロトコルを示す。値１を有するバイトがサーバ２００から返るのを待っているクライアント１００が、タイムアウトする。クライアント１００は、０（零）の値を有するバイトをサーバ２００に送信することによって、タイムアウトに応答する。その結果、タイムアウトしたクライアント１００は、サーバ２００からの次のメッセージは、未処理の単一バイトであり、さらにそれに、収集されたタイムスタンプを備えるメッセージが続くことを予想する。なお、クライアント１００がバイト＝１（一）を発送した場合は、クライアント１００は、サーバ２００からの次のメッセージが各タイムスタンプを含むことを予想する。クライアント１００は、タイムスタンプを待ち続ける。
【００３０】
図５及び６を参照する。これらの図面は、サーバ２００がタイムアウトする場合の、クロック・オフセット測定を実行する例示のプロトコルを示す。タイムアウトしたサーバ２００は、バイト＝０（零）を発送し、さらにそれに、サーバ２００がそれまでに収集したタイムスタンプが続く。これらのケースでは、クライアント１００は、バイト＝＊（アスタリスク）メッセージを発送する前にサーバ２００がタイムアウトしたことを知らないため、サーバは、バイト＝＊（アスタリスク）メッセージ（例えば、任意の値を備えるバイトを有するメッセージ）が向かっていることを予想するべきである。こうしたケースでは、サーバ２００は、バイト＝＊（アスタリスク）メッセージを破棄するべきである。
【００３１】
図７は、通常動作のもとでの、クライアントの状態及びアクションの図である。図８は、例外動作のもとでの、クライアントの状態及びアクションの図である。なお、信頼性のある接続のためには、すべてのメッセージが、メッセージが送信された順序で配送されるべきである。
【００３２】
図９は、通常動作のもとでの、サーバの状態及びアクションの図である。図１０は、例外動作のもとでの、サーバの状態及びアクションの図である。なお、サーバ２００は、バイト＝０（零）の送信と、タイムスタンプの送信との間に、何も受信するべきではない。
【００３３】
図１１を参照する。この図面は、クロック・オフセット測定を実行する例示のフロー図を示す。フロー図内のアクションは、例示の実施形態では個別のプログラム１０２、２０２によって、アクションを実行するようにそれぞれ構成された、クライアント１００及びサーバ２００によって実行されることになるであろう。さらに、図１１のフロー図内のアクションは、ハードウェア又はソフトウェアの任意の組み合わせによって実行されてもよい。
【００３４】
アクションＡでは、ネットワーク・ノードが協調して、クロック・オフセット測定プロセスを開始する。典型的には、この協調は、クライアント１００にいくつかの単一バイトのｐｉｎｇ  ｐｏｎｇやり取りを要求させ、サーバ２００に受信通知メッセージの送信を行わせる（例えば図３に示されているように）が、これに限定はされない。やり取りの数は、一般に、４〜１０の間となるが、より少ない、又はより多い数が使用されてもよい。
【００３５】
アクションＢにおいて、ネットワーク・ノードは、単一バイトを所定回数やり取りし、単一バイトの値は、やり取りそれぞれに関して異なる（例えば、図３に示し、それを参照して上記に記載されたように）。例示の実施形態では、プログラム１０２／２０２は、アクションＢのバイトのやり取りのために、リモート・ダイレクト・メモリ・アクセス（ＲＤＭＡ）アクセスを実装する。これらのやり取りは、ＲＤＭＡのケースにおいて、単純なデータ駆動型のスピン・ループの使用を可能にする。ターゲット・バイトが変化するとすぐに、応答バイトを送信することができ、完了ステータスのポーリングを最初に行う必要がない。これは、ＩｎｆｉｎｉＢａｎｄの例示のケースでは、既に低いレイテンシを少なくともマイクロ秒は削減することができる。
【００３６】
アクションＣでは、各ノードが、ノード上で実行されるやり取りの各部分のタイムスタンプを獲得及び記憶する。例えば（図３参照）、クライアント１００は、タイムスタンプＴ１、Ｔ３、Ｔ５、及びＴ７を獲得及び記憶し、サーバ２００は、タイムスタンプＴ２、Ｔ４、Ｔ６、及びＴ８を獲得及び記憶する。なお、図１１は、通常の処理のフロー図を示す。例外処理は、図４〜６、８、及び１０に示されている。
【００３７】
アクションＤでは、ノードのうちの少なくとも１つが、記憶されているタイムスタンプをもう一方のノード又はさらなるノードに伝達する。典型的には、サーバ２００が、その記憶されているタイムスタンプをクライアント１００に送信すると考えられ、その結果、クライアント１００が、アクションＥ、Ｆ及びＧを実行することになるであろう。なお、クライアント１００が、その記憶されているタイムスタンプをサーバ２００に送信することも可能であり、その場合、サーバ２００が、アクションＥ、Ｆ及びＧを実行することになるであろう。クライアント１００及びサーバ２００が、その記憶されているタイムスタンプをやり取りすることもできると考えられ、さらに一方又は両方が、タイムスタンプを別のネットワーク・ノードに送信することもできると考えられる。
【００３８】
アクションＥでは、タイムスタンプ（図３に示されているタイムスタンプＴ１〜Ｔ８など）を使用して移送時間１０５が判断される。順方向移送時間が、隣接したタイムスタンプ間の差、Ｔｅｖｅｎ−Ｔｏｄｄ（例えばＴ２−Ｔ１）を使用して判断され、逆方向移送時間が、Ｔｏｄｄ−Ｔｅｖｅｎ間の差（例えばＴ３−Ｔ２）を使用して判断される。続いてアクションＦでは、アクションＥにおいて判断された最小値（各方向の）に少なくとも基づいて、見かけの順方向及び逆方向移送遅延１０６が選択される。凸包フィルタリングなどの他の技術も使用され得る。凸包フィルタリング技術を用いると、順方向及び逆方向移送遅延１０６を別々に収集でき有利であり、任意のシステム・ノイズが除去されるであろう。
【００３９】
アクションＧでは、ノード（典型的にはクライアント１００）が、アクションＦで判断された見かけの順方向及び逆方向遅延に基づき、クライアント又はサーバ・クロック・オフセット１０７を判断する。アクションＨでは、クロック・オフセット１０７が、ネットワーク・ノードのクロックを同期させるために使用される。典型的には、これは、クライアントのクロック（例えば図２のクライアント１００のクロック１０９）が、サーバのクロック（例えば、図２のサーバ２００のクロック２０９）と同期させられることを意味する。
【００４０】
例えば、クライアント１００が、サーバ２００のクロックを追跡したい場合、クライアント１００は、現在のクロック・オフセットを測定するために、タイムスタンプのやり取りを繰り返し要求し、続いてクライアント１００は、そのクロック１０９を、そのような測定の履歴及び適切なフィルタリング技術から、サーバ２００のクロックと一致するよう操作することができる。これは、毎秒数回行われてもよく、その結果、ローカル発振器の周波数が例えば１又は２ｐｐｍ（パーツ・パー・ミリオン：ｐａｒｔｓ  ｐｅｒ  ｍｉｌｌｉｏｎ）に安定していれば、クロック・オフセットをマイクロ秒レベルで制御可能である。
【００４１】
本発明の例示の一実装は、ネットワーク・ノードのクラスタにおいてクロックをよりよく同期するために使用され、それによって、ネットワークのノードからノードへと処理されるトランザクションの正確な遅延測定をユーザが得られるようにする。本発明の実施形態における技術は、ノード間で集中的に送信される非常に小さなパケット、及び密結合のｐｉｎｇ  ｐｏｎｇプロセスにより、クロック間のオフセット及びスキューのより正確な測定を提供する。
【００４２】
当業者であれば当然のことであるが、本発明の側面は、システム、方法又はコンピュータ・プログラム製品として具現化され得る。したがって、本発明の側面は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、又は本願明細書においてすべて概して「回路」、「モジュール」若しくは「システム」と呼ばれ得る、ソフトウェア及びハードウェアの側面を兼ね備えた実施形態の形態をとり得る。さらに、本発明の側面は、コンピュータ可読プログラム・コードが具現化された１つ以上のコンピュータ可読媒体（単数又は複数）において具現化されたコンピュータ・プログラム製品の形態をとることもできる。
【００４３】
１つ以上のコンピュータ可読媒体（単数又は複数）の任意の組み合わせが利用され得る。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体とされ得る。コンピュータ可読記憶媒体は、例えば、限定はされないが、電子、磁気、光学、電磁気、赤外線、若しくは半導体システム、装置、若しくはデバイス、又は前述のものの任意の適切な組み合わせとされ得る。コンピュータ可読記憶媒体のより具体的な例（包括的でないリスト）には、１つ以上のワイヤを有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ）、読み出し専用メモリ（ＲＯＭ：ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、消去可能プログラム可能読み出し専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ  ｐｒｏｇｒａｍｍａｂｌｅ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み出し専用メモリ（ＣＤ−ＲＯＭ：ｃｏｍｐａｃｔ  ｄｉｓｃ  ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ）、光学式記憶デバイス、磁気記憶デバイス又は前述のものの任意の適切な組み合わせが含まれるであろう。この文書の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置若しくはデバイスによって、又はそれに関連して使用されるプログラムを含むこと、又は記憶することができる任意の有形の媒体であればよい。
【００４４】
コンピュータ可読信号媒体は、例えば、ベースバンドに、又は搬送波の一部として、コンピュータ可読プログラム・コードが具現化された伝播データ信号を含み得る。そのような伝播信号は、電磁気、光学、又はその任意の適切な組み合わせを含むがこれらに限定はされない、様々な形態の何れかをとってよい。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体でなく、命令実行システム、装置若しくはデバイスによって、又はそれに関連して使用されるプログラムを伝達すること、伝播させること、又は移送することができる、任意のコンピュータ可読媒体としてよい。
【００４５】
コンピュータ可読媒体上に具現化されたプログラム・コードは、無線、有線、光ファイバ・ケーブル、ＲＦなど、又は前述のものの任意の適切な組み合わせを含むがこれらに限定はされない、任意の適切な媒体を使用して送られてもよい。
【００４６】
本発明の側面の動作を実行するコンピュータ・プログラム・コードは、Ｊａｖａ（Ｒ）、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋又は同様のものなどのオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語などの従来の手続きプログラミング言語、又はアセンブリ言語、又は同様のプログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれていてよい。そのようなコンピュータ・プログラム・コードは、さらに、ＶＨＤＬ（Ｖｅｒｙ−ｈｉｇｈ−ｓｐｅｅｄ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ  Ｈａｒｄｗａｒｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｌａｎｇｕａｇｅ：超高速集積回路ハードウェア記述言語）などのフィールド・プログラマブル・ゲート・アレイのコードを含んでもよい。
【００４７】
本発明の側面は、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図若しくはブロック図又はその両方を参照して上記に記載されている。当然のことながら、フローチャート図若しくはブロック図又はその両方の各ブロック、及びフローチャート図若しくはブロック図又はその両方の複数ブロックの組み合わせは、コンピュータ・プログラム命令により実装可能である。マシンを生じるよう、当該コンピュータ・プログラム命令が、汎用コンピュータ、専用コンピュータ、又はその他のプログラム可能データ処理装置のプロセッサに提供されて、この命令が、コンピュータ又はその他のプログラム可能データ処理装置のプロセッサにより実行されて、フローチャート若しくはブロック図又はその両方のブロック若しくは複数ブロックにおいて指定された機能／動作を実装する手段を生じるようにすることもできる。
【００４８】
さらに、特定の形で機能するようコンピュータ、その他のプログラム可能データ処理装置、又はその他のデバイスに指示することができる当該コンピュータ・プログラム命令は、コンピュータ可読媒体に記憶されて、コンピュータ可読媒体に記憶されたこの命令が、フローチャート若しくはブロック図又はその両方のブロック若しくは複数ブロックにおいて指定された機能／動作を実施する命令を含む製品を生じるようにすることもできる。
【００４９】
さらに、コンピュータ・プログラム命令は、コンピュータ、その他のプログラム可能データ処理装置、又はその他のデバイスにロードされて、コンピュータ、その他のプログラム可能装置、又はその他のデバイス上で一連の動作ステップが実行されるようにしてコンピュータに実装されるプロセスを生じさせ、コンピュータ又はその他のプログラム可能装置上で実行される命令が、フローチャート若しくはブロック図又はその両方のブロック若しくは複数ブロックにおいて指定された機能／動作を実装するためのプロセスを提供するようにすることもできる。
【００５０】
各図面のフローチャート及びブロック図は、本発明の様々な実施形態によるシステム、方法及びコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性及び動作を示す。この関連で、フローチャート又はブロック図内の各ブロックは、指定の論理機能（単数又は複数）を実装する１つ以上の実行可能命令を含むモジュール、セグメント、又はコードの一部を表すこともできる。なお、さらに、一部の代わりの実装では、ブロック内に示されている機能が、図面に示されているのとは異なる順序で発生してもよい。例えば、関連する機能性次第で、連続して示されている２つのブロックが実際には事実上同時に実行されてもよく、又は、各ブロックが逆順で実行されることがあってもよい。なお、さらに、ブロック図若しくはフローチャート図又はその両方の各ブロック、及びブロック図若しくはフローチャート図又はその両方の複数ブロックの組み合わせは、指定の機能若しくは動作を実行する専用ハードウェア・ベース・システム、又は専用ハードウェア及びコンピュータ命令の組み合わせにより実装することができる。
【００５１】
前述の説明は、本発明の実施形態を実施するための、現時点において発明者が意図する最良の技術について、十分且つ有益な説明を、例示的であり非限定的である例によって提供した。なお、当業者であれば、前述の説明を添付の図面及び添付の特許請求の範囲と併せて読み考慮することで、様々な変更及び適応がすぐに分かるであろう。本発明の教示の上記の変更及び類似の変更は、やはりすべて本発明の範囲内に入る。
【００５２】
さらに、本発明の例示の実施形態の特徴の一部を、他の特徴の対応する使用を伴わずに役立てるよう使用することも可能であろう。よって、前述の説明は本発明の実施形態を制限するものではなく、その原理を説明するだけのものとして見なされる必要がある。
【図１】
2013509814.tif 000003
【図２】
2013509814.tif 000004
【図３】
2013509814.tif 000005
【図４】
2013509814.tif 000006
【図５】
2013509814.tif 000007
【図６】
2013509814.tif 000008
【図７】
2013509814.tif 000009
【図８】
2013509814.tif 000010
【図９】
2013509814.tif 000011
【図１０】
2013509814.tif 000012
【図１１】
2013509814.tif 000013
【国際調査報告】
2013509814.tif 000014