(57)【要約】  同期した時間情報の転送が不要なネットワーク環境でネットワークリソースを共有する固有の時間基準を具備した時間認識ネットワークが提供される。ＧＰＳ信号から抽出された時間座標である絶対時間値を使用して内部時間基準が確立される。絶対時間値やクロックパラメータブロックは、時間認識装置による内部時間基準の使用法を調整し、ネットワーク・クロックドメインを確立する。ネットワーク・クロックドメインには、そのドメインのタイミング要件を満足する能力を有する装置が参加可能である。クライアントは、ネットワーク・クロックドメインに参加することで、共有リソースのデータの一貫性を維持するロッキング・オーソリティを通じて共有リソースへのアクセスが可能である。クライアント、ロッキング・オーソリティおよび共有リソースのいずれも、内部時間基準を使用して通信する同一のネットワーク・クロックドメインに参加する時間認識装置である。
2007518159.tif 000002
【特許請求の範囲】
【請求項１】
複数の時間認識装置を備えており、前記複数の時間認識装置のそれぞれは、絶対時間値を有し、それぞれの時間認識装置と関連した前記絶対時間値が、定義されているタイミングパラメータを満足している場合に、固有の時間基準が生成され、これによって、前記複数の時間認識装置間において時間情報を同期させる必要性を除去していることを特徴とする時間認識ネットワーク。
【請求項２】
前記固有の時間基準は、伝送されかつ受信されたメッセージの厳密なシーケンシングを必要とする任意の通信システムにおいて利用される請求項１記載の時間認識ネットワーク。
【請求項３】
前記複数の時間認識装置は、前記固有の時間基準を使用して同期した方式で通信するべく構成されている請求項１記載の時間認識ネットワーク。
【請求項４】
前記複数の時間認識装置のそれぞれの前記絶対時間値は、ＧＰＳ信号から抽出された時間座標である請求項１記載の時間認識ネットワーク。
【請求項５】
前記時間認識装置は、クライアント装置である請求項１記載の時間認識ネットワーク。
【請求項６】
前記クライアント装置は、ワークステーション、サーバー、ＣＰＵ、または無線装置の中のいずれか一つである請求項５記載の時間認識ネットワーク。
【請求項７】
前記時間認識装置は、ロッキング・オーソリティである請求項１記載の時間認識ネットワーク。
【請求項８】
前記時間認識装置は、共有ネットワークリソースである請求項１記載の時間認識ネットワーク。
【請求項９】
前記時間認識装置は、ルーターである請求項１記載の時間認識ネットワーク。
【請求項１０】
前記の定義されているタイミングパラメータは、クロックパラメータブロックであり、前記クロックパラメータブロックは、前記固有の時間基準を使用してその他の時間認識装置と通信するために前記複数の時間認識装置のそれぞれが満足する能力を有していなければならない要件を記述するべく構成されている請求項１記載の時間認識ネットワーク。
【請求項１１】
前記ロッキング・オーソリティは、ネットワーク・クロックドメインを生成する請求項７記載の時間認識ネットワーク。
【請求項１２】
前記ネットワーク・クロックドメインは、前記クロックパラメータブロックを使用して確立される請求項１１記載の時間認識ネットワーク。
【請求項１３】
前記クロックパラメータブロックは、共有リソースのタイミング要件に基づいている請求項１１記載の時間認識ネットワーク。
【請求項１４】
前記クライアントは、ネットワーク・クロックドメインに参加して共有リソースにアクセスする請求項１１記載の時間認識ネットワーク。
【請求項１５】
前記ロッキング・オーソリティは、前記共有リソースに対する前記クライアントのアクセスを制御する請求項１４記載の時間認識ネットワーク。
【請求項１６】
前記ロッキング・オーソリティは、前記共有リソースに対するアクセスを制御することにより、データの一貫性を提供する請求項１５記載の時間認識ネットワーク。
【請求項１７】
前記ロッキング・オーソリティは、複数のロッキングシナリオを使用して前記共有リソースに対するアクセスを制御する請求項１５記載の時間認識ネットワーク。
【請求項１８】
前記ロッキング・オーソリティは、伝送タイムスタンプに基づいて受信メッセージを再順序付けするべく構成されている請求項１６記載の時間認識ネットワーク。
【請求項１９】
前記ロッキング・オーソリティは、第１クライアントに対してロックを許可すると共に、第２クライアントから受信した要求を再キューイングするべく、さらに構成されている請求項１７記載の時間認識ネットワーク。
【請求項２０】
前記共有リソースは、ネットワークリソースである請求項８記載の時間認識ネットワーク。
【請求項２１】
前記共有リソースは、マスストレージメカニズムである請求項８記載の時間認識ネットワーク。
【請求項２２】
前記マスストレージメカニズムは、データベースである請求項２１記載の時間認識ネットワーク。
【請求項２３】
前記マスストレージメカニズムは、ディスクアレイである請求項２１記載の時間認識ネットワーク。
【請求項２４】
前記共有リソースは、マスメモリシステムである請求項２０記載の時間認識ネットワーク。
【請求項２５】
前記共有リソースは、ストリーミングメディアシステムである請求項２０記載の時間認識ネットワーク。
【請求項２６】
前記固有の時間基準は、前記クロックパラメータブロックおよび前記絶対時間値を使用して前記ロッキング・オーソリティにより生成される擬似クロックである請求項１記載の時間認識ネットワーク。
【請求項２７】
前記固有の時間基準を使用して通信するべく、前記時間認識装置および共有リソースは、同一の前記ネットワーク・クロックドメインに属している請求項１１記載の時間認識ネットワーク。
【請求項２８】
クライアントは、前記ネットワーク・クロックドメイン内の前記共有リソースにアクセスするべく、前記ネットワーク・クロックドメインに参加しなければならない請求項１１記載の時間認識ネットワーク。
【請求項２９】
前記受信メッセージの再度のシーケンシングは、前記メッセージが伝送された時間を通知するタイムスタンプに基づいている請求項２記載の時間認識ネットワーク。
【請求項３０】
固有のネットワーク時間基準において、
ＧＰＳ信号から抽出された時間座標である絶対時間値と、
タイミング要件を定義しているパラメータブロックとを有しており、
前記絶対時間値が、前記パラメータブロックにより定義されている前記タイミング要件を満足している場合に、前記固有のネットワーク時間基準が確立され、前記絶対時間値を有する装置が時間情報の同期化を伴うことなしに通信可能となることを特徴とする固有のネットワーク時間基準。
【請求項３１】
前記固有の時間基準は、伝送されかつ受信されたメッセージの厳密なシーケンシングを必要とする任意の通信システムにおいて利用される請求項３０記載の固有のネットワーク時間基準。
【請求項３２】
前記装置は、時間認識装置である請求項３０記載の固有のネットワーク時間基準。
【請求項３３】
前記固有のネットワーク時間基準は、時間認識装置用の擬似クロックとして機能する請求項３０記載の固有のネットワーク時間基準。
【請求項３４】
前記時間認識装置は、前記タイミング座標を抽出するＧＰＳ受信機を含む請求項３２記載の固有のネットワーク時間基準。
【請求項３５】
前記タイミング要件は、共有リソースによって規定されている請求項３２記載の固有のネットワーク時間基準。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、コンピュータネットワークに関するものであり、さらに詳しくは、同期時間情報の転送が不要な分散ネットワーク環境においてネットワークリソースの共有を実現するための固有のネットワーク時間基準の生成に関するものである。
【背景技術】
【０００２】
現在までのところ、コンピュータネットワークは、スタンドアロン型コンピュータシステムにおいて通常実現されている複合的な通信およびリソース共有の能力を遂行することができていない。コンピュータネットワークに固有の問題を提示している２つの領域は、未解決のクロック配信の問題と、共有リソース間においてデータの一貫性を維持することができない点とを含んでいる。コンピュータネットワークの設計者に大きな問題を提示している上記の領域は、かつては、コンピュータの設計者に対しても問題を提示していた。ただし、コンピュータに関しては、これらの問題に対する解決策が数十年も前に開発されているが、残念ながら、コンピュータに関しては機能した上記の解決策は、ネットワークレベルにおける実施において成功を収めてはいない。
【０００３】
（ａ．クロック配信問題）
コンピュータシステム内における中央集中化された共通時間基準に対する必要性を否定することはできない。正しく機能するためには、すべてのサブシステムおよびコンポーネントが同一のクロック信号を遵守しなければならないため、コンピュータ設計にとって、クロックの配信は不可欠である。これは、スタンドアロン型コンピュータとコンピュータネットワークのいずれにも当てはまる。クロックは、すべてのサブシステムおよびコンポーネント間におけるハイレベルな調整を決定している。したがって、すべてのコンポーネントは、動作するために、コンピュータクロックと同期しなければならない。
【０００４】
従来のコンピュータは、タイムサーバーを使用してタイミングをネットワークに導入し、ネットワーク上のコンピュータ間において時間を調整および同期化することにより、クロック配信の問題を解決するべく試みている。しかしながら、ネットワークはレイテンシーの問題を本質的に有しているため、タイムサーバーは、コンピュータネットワーク内のすべてのコンポーネントが依存可能な正確かつ高精度な時間基準を提供することが不可能である。
【０００５】
コンピュータネットワーク上におけるデータ伝送は、セルフクロッキング波形を利用している。この結果、伝送信号を受信機において正確に再構築することが可能であるが、ネットワーク上における伝送の際の伝送クロックの位相タイミング、位相シフト、または遅延に関する情報を判定する方法は存在していない。このため、レイテンシーが未知数となる。レイテンシーに関するなんらかの知識をも有することなしに、コンピュータネットワーク上において高精度な時間基準を提供することは不可能である。したがって、ネットワーククロックの配信問題に対する大部分の解決策は、ネットワーク上におけるそれぞれのクライアントおよびリソースに対する時間の転送に関連した帯域幅およびレイテンシーの問題により、本質的に制限されている。このため、「時間の同期化」または「時間の調整」を最終的に必要とする解決策は、上記のようなネットワークに固有の制限の結果として機能しないとみなされている。
【０００６】
（ｂ．リソースの共有）
複数のＣＰＵを利用しているコンピュータシステムは、選択されたリソースに対する排他的かつ制御されたアクセスをそれぞれのＣＰＵに許容することにより、Ｉ／Ｏリソースおよびメモリリソースを共有する能力を有している。この排他的なアクセスは、ロックと呼ばれている。このロックを行うロッキングのプロセスは、ＣＰＵが共有リソースにアクセスしている最中に、リソースに対する排他的なアクセスまたはそのロックを具備するＣＰＵ以外のその他のＣＰＵによってリソースのデータが変更されないようにしている。ロッキングの概念による排他的なアクセスを許可することにより、共有リソースのデータの一貫性が保証される。
【０００７】
現在までのところ、ネットワークレベルにおいてリソース共有の概念を利用する試みは失敗している。具体的には、一つのネットワークコンピュータ内のＣＰＵによる別のネットワークコンピュータ上に配置されているリソースおよびサブシステムの共有を実現する試みは、多数の理由から成功しないことが立証されている。これらの理由は、ネットワーク環境と単一のコンピュータの環境の違いを強調するものである。例えば、ネットワークは、データ供給の観点において信頼性が低くなる傾向を有しており、高率のデータ伝送エラーを検出することができず、かつ、データ伝送障害を補正することができない。このような欠点により、リソース共有の際にデータの一貫性を保証することが困難になる。さらには、同期状態で動作しているコンピュータとは異なり、コンピュータネットワークは、非同期方式で動作している。したがって、サブシステム、コンポーネント、およびソフトウェアの設計者は、その他のネットワークコンポーネントから伝送されるメッセージのシーケンスまたは順序について想定することができない。さらには、ネットワークが受信メッセージの順序を優先順位付けすることができないことにより、ネットワーク上において共有されているリソースに対するロックを正確に確立、許可、および解放するネットワークの能力が妨げられている。
【０００８】
コンピュータネットワークには、高精度な時間同期が欠如していることから、コンピュータネットワークは、複雑なハンドシェークを使用したリソース共有を余儀なくされている。ハンドシェークは、共有リソースの状態（すなわち、ロックされているか、またはアンロックされているか）をその他のクライアントに通知しつつ、共有リソースに対する制限されたまたは制限されていない最小形態のアクセスを一つのクライアントに提供する。しかしながら、共有リソースに対するアクセスが許可される際には、すべてのクライアントが協働しなければならない。一つのクライアントとの通信が消失または遅延した場合には、共有ネットワークリソースに対するアクセスがすべてのクライアントに対して拒絶されるため、ハンドシェーキング法は本質的に脆弱である。したがって、コンピュータレベルのリソース共有は、非常に有益であることが立証されているが、コンピュータとコンピュータネットワークとの間の違いに起因し、データの一貫性を維持した状態でのリソース共有のネットワークレベルにおける実施が妨げられている。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
最終的には、ネットワークも、スタンドアロン型コンピュータによって現在実現されている能力に相当する方式で稼動する必要がある。したがって、ネットワーククロックの配信問題を除去することにより、共有リソース間におけるデータの一貫性を維持しつつ、多数のクライアント間におけるコンピュータリソースの効果的な共有を実現するシステムおよび方法が求められている。以下に詳述するように、本発明は、固有のネットワーク時間基準を確立する方法を提示すると共に、時間情報の転送を必要としないネットワークリソースを共有するシステムを提示することにより、上記の問題点を解決することを目的としている。
【課題を解決するための手段】
【００１０】
上記の問題点を解決するために、本願明細書に記述されているシステムおよび方法は、通信するために時間認識装置間において同期時間情報を転送する必要性を除去する時間認識装置用の固有のネットワーク時間基準を提供している。さらに詳しくは、この固有のネットワーク時間基準は、定義されているタイミング要件を時間認識装置と関連した絶対時間値が満足している場合に生成される。具体的には、時間認識装置は、受信したＧＰＳ信号から時間座標を抽出することにより、絶対時間値を取得する。この絶対時間値が、パラメータブロック内に記述された定義されているタイミング要件を満足している場合に、時間認識装置間において生成されかつ配信された共通クロックを具備しているかのようにやり取りする能力を有する時間認識装置を生成する合成または擬似ネットワーククロックが確立される。
【００１１】
本発明の別の実施例においては、本願明細書に記述されているシステムおよび方法は、時間認識ネットワークをも提供している。具体的には、時間認識ネットワークは、それぞれの時間認識装置と関連した絶対時間値を使用することにより、コンピュータクロックに相当する時間基準を生成している。基本時間認識ネットワークを構築している時間認識装置は、クライアント、ルーター、ロッキング・オーソリティ（locking authority）、および共有リソースを含んでいる（ただし、これらに限定されない）。ロッキング・オーソリティは、ネットワーク・クロックドメインを生成しかつ維持する責任を担っており、ネットワーク・クロックドメインは、制御されたロッキングサービスをクライアントと共有リソースとの間で提供している。具体的には、ロッキング・オーソリティは、クロックパラメータブロックを使用してネットワーク時間ドメインを生成する。そして、クロックパラメータブロックと絶対時間値とを使用して擬似クロック（Pseudo-clock）を生成する。クロックパラメータブロックは、参加するためにクライアントが保証しなければならないタイミング要件と絶対時間値の高精度な値を定義している。クライアントは、ネットワーク・クロックドメインへの参加が完了すると、擬似クロックを使用してドメイン内のその他の時間認識装置と通信する。具体的には、クライアントが、共有リソースに対するアクセスを要求し、ロッキング・オーソリティが、伝送に基づいたタイムスタンプに基づいて、クライアントに対して排他的なロックを許可する。
【００１２】
さらに別の実施例においては、共有リソースと関連したデータの完全性および一貫性を保証しつつ、スケールフリーネットワーク内において共有リソースを制御する方法が提供されている。
【００１３】
別の実施例においては、伝送時間に基づいた時間スタンプに基づいて、到来したパケットに対するシーケンシング（Sequencing）、順序付け、およびソーティング（Sorting）を行う方法が提供される。同様に、絶対時間値を使用して受信パケットに対するシーケンシングおよび順序付けを行う方法も提供される。また一方で、絶対時間値を使用して伝送タイムスタンプを生成するシステムおよび方法も提供される。
【００１４】
さらに別の実施例においては、多数の装置間におけるネットワークリソースのアクセス、ロッキング、および共有のための安定したネットワークを実施するシステムおよび方法が提供される。
【００１５】
さらに別の実施例においては、時間認識装置と関連した絶対時間値を使用してネットワーク・クロックドメインを確立する方法が提供される。
【発明を実施するための最良の形態】
【００１６】
本願明細書に開示されている本発明の好適な実施例は、一例として添付の図面に示されており、これは、本発明の限定を意図するものではない。
【００１７】
以下の実施例の説明においては、様々なタイプのシステムに関係する実施形態の相違点や固有の懸念事項について可能な範囲において指摘している。ただし、本願明細書に記述されているシステムおよび方法は、あらゆるタイプのネットワークシステムに適用可能であることを理解されたい。
【００１８】
（Ｉ．絶対時間基準）
ＧＰＳ（全地球測位システム：Global Positioning System）は、ナビゲーションのために容易に使用可能な衛星の巨大なネットワークである。ＧＰＳは、通常、三角測量または三次元空間の概念に基づいたものとして説明されている。しかしながら、ＧＰＳは、実際には、四次元において三角測量を実行している。すなわち、ＧＰＳ対応装置は、経度座標、緯度座標、高度座標、および時間座標という４つの座標を使用してその場所を認知している。それぞれのＧＰＳ受信機は、その航行位置を時間座標を使用して演算しているため、ＧＰＳは、地球上のあらゆる場所に存在するすべての装置が利用可能な絶対時間値を本質的に生成している。
【００１９】
好都合なことに、このＧＰＳ信号によって実現されている固有の時間基準が、困難なネットワーククロックの配信問題を基本的に解決する。さらには、ＧＰＳは、その存在を無視することにより、この問題を解決する。クロックの配信と時間の同期化に焦点を合わせる代わりに、ＧＰＳを使用することにより、ある種の時間認識装置を定義することが可能である。それぞれの時間認識装置は、受信したＧＰＳ信号から時間座標を抽出するべく使用するその独自のＧＰＳ受信機および時間デコーディング回路を含んでいる。それぞれの時間認識装置が、ＧＰＳ受信機から導出されたその独自の内部時間値を具備しているため、共通時間基準を確立する必要がない。基本的に、ＧＰＳシステムは、必要な時間プラットフォームを既に提供している。したがって、時間認識装置が、受信したＧＰＳ信号から時間座標を抽出することによってその独自の「擬似クロック（Pseudo-clock）」を生成した際に、絶対時間値が確立される。この絶対時間値が、従来の中央クロックまたはタイムサーバーの必要性を除去する。
【００２０】
それにもかかわらず、時間認識装置は、それらの間において共通クロックが生成されかつ配信されているかのようにやり取りする能力を有している。時間情報の転送と同期化を伴うことなしに通信するべく、個々の時間認識装置は、その内部において生成される「擬似クロック」の使用法に関する確立されたプロトコルを遵守している。後程詳述するように、ネットワーク・クロックドメインと共に時間認識装置を使用することにより、時間認識装置がその内部において生成された「擬似クロック」を使用してその他の時間認識装置とやり取りすると共に共有ネットワークリソースにアクセスする方法を調整している。
【００２１】
（ＩＩ．時間認識装置）
一般に、時間認識装置は、ＧＰＳ受信機を含む任意の装置であってよい。位置情報に基づいて時間座標を判定する際には、任意選択により、ロジックを使用することが可能である。当然のことながら、これらの要素は、限定を意図するものではなく、したがって、ＧＰＳ信号から時間座標を抽出する際には、任意のハードウェアまたはソフトウェア法を使用することが可能である。ＧＰＳ信号から高精度な時間座標を抽出する装置を様々な製造者が製造している。したがって、ＧＰＳ信号から高精度な時間を抽出する手法については、当業者にとって周知である。したがって、これらの手法のいずれかのものを使用して時間座標を取得することが可能である。さらには、アンテナやＲＦ部等のＧＰＳ受信機の一部を装置の外に配置したり、あるいは、場合によっては、通常、ＧＰＳシステムの関連するエラーレンジ内に配置されているいくつかの装置によって上記ＧＰＳ受信機の一部を共有したりすることも可能である。
【００２２】
時間認識装置に関していえば、それぞれの装置は、完全に独立していると共に、その他の装置と調整または同期化して共通時間基準を確立する必要がないという点を強調しておくことが重要である。それぞれの時間認識装置は、抽出されたＧＰＳ信号座標に基づいて時間を維持する能力を有しており、既知の最悪のケースにおける正確度と、信号の完全性、エラー計測値、および装置の能力に基づいて導出される現在時間の正確度を有している。
【００２３】
あるいは、この代わりに、正確な既知の遅延を有するＧＰＳ信号を取得できるようにする専用のバスインターフェイスを具備するように、時間認識装置を構築することも可能である。遅延を補償するためのアルゴリズムによる調節を使用し、バス上において受信されたＧＰＳ信号から高精度なタイミング座標を抽出することが可能である。このバスは、ブロードキャストバスまたは要求／応答システムであってよい。さらに詳しくは、このバスは、いくつかの時間認識装置を単一の装置に組み合わせる方法を提供している。これは、共通シャーシに挿入されたいくつかのインターフェイスカードによって実現可能である。この場合には、ＧＰＳ受信機は、バスに接続されているそれぞれのインターフェイスカード用の絶対時間値をバスに供給することになろう。好ましくは、バスの電気およびタイミング特性を厳格に制御する必要がある。さらには、本装置は、物理的に近接した状態で配置されることが可能である。さらには、バスが完全な同期状態となるように、コンピュータクロック等の内部時間基準を既に具備しているコンピュータまたはルーターシャーシ等の装置内に本装置を一纏めにする必要もあろう。あるいは、この代わりに、コストおよびスペース要件を軽減するべく、装置のグループが単一のＧＰＳ受信機を共有することも可能である。
【００２４】
（ＩＩＩ．時間認識ネットワーク）
ＧＰＳが絶対時間値を取得する手段を提供しているため、様々なコンピュータおよびネットワーク周辺機器間において時間を同期化または調整する必要はない。この絶対時間基準の確立により、時間認識装置は、リソースを共有し、この共有リソースの完全性を維持することができる。これは、時間認識ネットワークを使用して実現される。
【００２５】
図１は、本発明による基本的な時間認識ネットワーク１０１を示している。具体的には、後述するように、時間認識ネットワーク１０１は、クライアント１０３、リソース１０９、時間認識ルーター１０５、および時間認識ロッキング・オーソリティ１１１を含む（ただし、これらに限定されない）時間認識装置を備えている。
【００２６】
（ａ．クライアント）
クライアント１０３は、時間認識ネットワーク１０１内のその他の時間認識装置と通信する能力を有する時間認識装置である。クライアント１０３の代表的かつ非限定的な実施例は、ワークステーション、サーバー、中央処理装置、および任意の無線装置を含んでいる。さらには、時間認識ネットワークは、使用するネットワークトランスポートの実際のタイプとは無関係であるため、衛星伝送を使用する装置によってクライアントを構成することも可能である。ソフトウェアドライバをクライアント１０３に読み込むことにより、クライアント１０３は、図１に示されている時間認識ルーター１０５を含むその他の時間認識装置と通信することが可能である。クライアント１０３は、後述するように、標準的なネットワークトランスポート１０７を通じて時間認識ルーター１０５に接続されている。
【００２７】
（ｂ．ネットワークトランスポート）
図１に示されているように、クライアント１０３は、ネットワークトランスポート１０７を介して時間認識ルーター１０５に接続されている。このネットワークトランスポート自体は、任意のタイプのネットワークトランスポートであってよい。例えば、ネットワークトラスポート１０７は、ファイバチャネルネットワーク等の物理的および論理的トランスポートレイヤの両方を包含するトランスポート規格であってよい。あるいは、この代わりに、ネットワークトランスポート１０７は、Ｅｔｈｅｒｎｅｔ（登録商標）（イーサネット（登録商標））およびＡＴＭ物理ネットワークトポロジーを含む（ただし、これらに限定されない）様々な物理トランスポートレイヤによってサポートされている論理的レイヤ（ＴＣＰ／ＩＰ）を含むＴＣＰ／ＩＰネットワークトランスポートであってもよい。
【００２８】
要約すれば、あらゆるデータ伝送ネットワークが、時間認識装置間において伝達されるタイムスタンプが付与されたデータ用のトランスポートとして機能することが可能である。また一方で、このトランスポートには、接続のために衛星伝送を利用しているネットワークも含まれている。したがって、本願明細書に記述されている方法および手法は、伝送媒体とは無関係であり、この結果、無線、有線、または光ファイバを含む任意のネットワークトランスポートを使用することが可能である。
【００２９】
（ｃ．時間認識ルーター）
図示のように、ネットワークトランスポート１０７上においてクライアント１０３から伝送されるパケットは、時間認識ルーター１０５を通じてルーティングされる。時間認識ルーター１０５を通じて伝送されるパケットには、前述のように時間認識クライアント１０３によってＧＰＳ信号から導出された絶対時間値により、タイムスタンプが付与されている。従来のルーターとは異なり、時間認識ルーター１０５は、接続されている装置間における時間情報の通信、同期化、または交換を行わない。むしろ、時間認識ルーター１０５は、それぞれの時間認識クライアント装置１０３内においてローカルに入手可能な絶対時間値に依存している。あるいは、この代わりに、時間認識ルーター１０５は、それぞれの時間認識ルーター１０５がＧＰＳ受信機を具備しているため、その独自の絶対時間値を使用し、伝送パケットにスタンプを付与することが可能である。
【００３０】
さらに詳しくは、時間認識ルーター１０５が使用するタイムスタンプは、パケットがクライアント１０３から伝送される時点と関連付けられている。伝送時間に基づいた時間値のタイムスタンプを使用することにより、時間認識ルーター１０５および受信者は、受信時間ではなく伝送時間に基づいて、シーケンスまたは順序を判定することが可能である。これは、共有ネットワークリソース内におけるデータの一貫性の維持に極めて重要な要素である。
【００３１】
時間認識ルーター１０５は、ネットワークトランスポート上におけるパケットのルーティングに影響を与えない方式により、標準的なネットワークパケットを受け付け、パケットに対してタイムスタンプを付加する。このパケットに対するタイムスタンプの付加は、物理レイヤのレベル、または、さらに上位のネットワークプロトコルレベルにおいて実施することが可能である。
【００３２】
（１．ネットワークレイヤにおけるタイムスタンプの付加）
タイムスタンプの付加は、ＴＣＰレイヤヘッダまたはＩＰレイヤヘッダを標準の２０バイトを超過して拡張し、タイムスタンプを収容することにより、実現可能である。ネットワークの構成に応じて、タイムスタンプは、ＴＣＰ（Transmission Control Protocol）、ＩＣＭＰ（Internet Control Message Protocol）、ＵＤＰ（User Datagram Protocol）、またはその他のパケットプロトコルを使用したパケットの伝送に影響を及ぼさないように、ＩＰレイヤにおいて挿入することが可能である。
【００３３】
当然のことながら、ＴＣＰレイヤにタイムスタンプを挿入した場合にも、ＨＴＴＰ（Hypertext Transfer Protocol）、ＦＴＰ（File Transfer Protocol）、Ｔｅｌｎｅｔ（テルネット）等の上位レイヤプロトコルを使用可能である。ただし、ＴＣＰレイヤにタイムスタンプを挿入した場合には、時間認識ネットワーク内の指定されたＴＣＰポートによる参加のみが可能であり、したがって、その他のポートは、時間認識機能を欠いた状態に残される。当然のことながら、システム管理者は、個々のニーズに従ってタイムスタンプおよび時間認識機能を提供するべく、ネットワークを構成することが可能である。インターネット上で構成されている時間認識パケットおよびネットワークの場合には、タイムスタンプは、ＩＰレイヤに挿入され、したがって、すべてのＴＣＰポートの参加が可能である。
【００３４】
（２．物理レイヤにおけるタイムスタンプの付加）
いくつかのケースにおいては、タイムスタンプを収容するようにＭＡＣ（Media Access Control）レイヤヘッダを構成することが可能である。タイムスタンプが付加されたＭＡＣレイヤヘッダは、任意選択のネットワークヘッダを具備したファイバチャネルネットワークによって利用されることが可能である。ネットワークの構成に応じて、それぞれのフレームまたはシーケンスごとにタイムスタンプを保持するべく、ＭＡＣレイヤヘッダを構成することが可能である。
【００３５】
Ｅｔｈｅｒｎｅｔ（登録商標）  ＭＡＣヘッダに関していえば、ビットパターンに対するサイドバンド変調を使用することにより、タイムスタンプエンコーディングを提供することが可能である。サイドバンド変調は、トランスポートの帯域幅を犠牲にすることなしに、パケットごとのタイムスタンプを提供するため、新しいハードウェアを利用している時間認識ネットワークは、サイドバンド変調によるタイムスタンプのエンコードを選択することが可能である。
【００３６】
（ｄ．ロッキング・オーソリティ）
ロッキングは、指定された期間にわたってリソースに対する排他的なアクセスを一つのクライアントに付与することにより、共有リソースに伴うトランザクションの同期と一貫性を保証している。単一のクライアントに付与する排他性は、短時間であるのが最適であり、これによって、共有リソースに対する排他的な連続的アクセスを具備した外観をそれぞれのクライアントに提供することが可能である。ロッキング機能は、クライアントが共有リソースにアクセスしている最中には、そのリソースの状態がそのクライアントの排他的な制御下にあるという保証をそれぞれのクライアントに提供している。
【００３７】
図１に示されているように、時間認識ネットワーク１０１は、ロッキング・オーソリティ１１１をさらに含んでいる。ロッキング・オーソリティ１１１は、共有リソース１０９に対するクライアント１０３のアクセスを順番に並べて同期させるべく構成されている。共有リソース１０９は、一つまたは複数のクライアントからアクセス可能な任意のコンポーネントまたは装置であってよい。例えば、図１は、ディスクアレイおよびデータベース等のマスストレージメカニズム、マスメモリシステム、およびストリーミングメディア（ビデオおよびサウンド）システムを含む（ただし、これらに限定されない）多数の共有リソース１０９を示している。ロッキング・オーソリティ１１１も時間認識装置であることを理解することが重要である。なお、ロッキング・オーソリティと、データの完全性を維持しつつ共有リソースに対するアクセスを実現するその個々のロッキングシナリオについては、後程詳述する。
【００３８】
要約すれば、図１に示されている時間認識ネットワーク１０１は、それぞれのネットワーク要素（すなわち、クライアント１０３、ルーター１０５、ロッキング・オーソリティ１１１、および共有リソース１０９）と関連する絶対時間値を使用してコンピュータクロックに相当する時間基準を生成することにより、ネットワーク要素間において時間情報を同期化する必要性を除去している。したがって、クライアント１０３が、ネットワークトランスポート１０７上においてパケットを伝送すると、このパケットは、伝送時間を示すタイムスタンプを具備する時間認識ルーター１０５に到来する。時間認識ルーターは、このパケットをネットワーク１０１上においてロッキング・オーソリティ１１１に転送する。ロッキング・オーソリティ１１１は、伝送時間に基づいたタイムスタンプを使用することにより、受信したパケットを優先順位付けする。正確な順序が確立されると、ロッキング・オーソリティ１１１は、共有リソース１０９に対するアクセスを単一のクライアント１０３に対して許可する。
【００３９】
ネットワーククロックおよび装置間における時間情報の交換を伴わない同期化は、ネットワーク・クロックドメインを生成することによって実現される。後程詳述するように、ネットワーク・クロックドメインは、ネットワーク・クロックドメイン内における通信およびリソースへのアクセスのために、それぞれの時間認識装置がその絶対時間値を利用する方法を定義しているパラメータのセットを使用して確立されている。
【００４０】
（ＩＶ．ネットワーク・クロックドメイン）
時間認識ネットワーク内において、ロッキング・オーソリティは、ネットワーク・クロックドメインの生成とネットワーク・クロックドメインの初期化の責任を担っている。さらには、ロッキング・オーソリティは、ネットワーク・クロックドメインを使用することにより、ネットワーク上における共有リソースに対するアクセスを制御している。好ましくは、ロッキング・オーソリティは、複数のネットワークドメインを生成かつ制御することが可能である。
【００４１】
従来のロッキング・オーソリティは、受信される第１のパケットに基づいて共有リソースに対するアクセスを単純に調節しており、したがって、どのパケットが最初に伝送されたのかを判定する能力を欠いている。この結果、クライアント要求が異常な状態において処理されるようになっていた。これとは対照的に、本願明細書に記述されているロッキング・オーソリティは、時間認識ネットワーク上の様々な時間認識クライアントから受信されるパケットのタイムスタンプをチェックするべく構成されている。ロッキング・オーソリティは、パケットの伝送タイムスタンプと、ロッキング・オーソリティ内のバッファメモリの利用可能性に基づいて、パケットを再順序付けする。次いで、最早の伝送タイムスタンプを有しているパケットを共有リソースに対して供給する。また一方で、このロッキング・オーソリティは、異常な状態において受信されるパケットに対してフラグを付与する。
【００４２】
ロッキング・オーソリティは、クライアントと共有リソース間においてロッキングサービスを提供する前に、ネットワーク・クロックドメインを生成する。ロッキング・オーソリティは、異なる能力を有するクライアントを処理するべく、複数のネットワーク・クロックドメインを生成かつサポートすることが可能であることに留意されたい。例えば、いくつかのクライアントは、高性能なネットワーク・クロックドメインが必要としている時間精度の能力を有していない。しかし、その同一のクライアントは、最小限の精度およびレイテンシー要件を具備したネットワーク・クロックドメインには参加することが可能であろう。さらには、クライアントは、ロッキング・オーソリティによって誤った順序で受信されたパケットに応答し、これらを再順序付けする様々な方法を利用することができる。したがって、類似した能力を有するすべてのクライアントを、それらのクライアントの能力に適合したネットワーク・クロックドメイン内にグループ化することが望ましい。要約すれば、ネットワーク・クロックドメインは、共有リソースのタイミング要件に基づいたタイミングプロトコルであり、この場合に、（ルーター、ロッキング・オーソリティ、およびクライアントを含む（ただし、これらに限定されない））すべての装置は、互いの間において並びに共有リソースとやり取りするべく、タイミングプロトコルによって規定されているタイミング要件を満足する能力を有していなければならない。
【００４３】
ロッキング・オーソリティ、共有リソース、クライアント、およびネットワーク・クロックドメインを含む時間認識ネットワーク上の時間認識装置間における相互関係については、図２を参照することにより、明瞭に説明することが可能である。図２は、３つの個別のネットワーク・クロックドメイン２１０、２２０、および２３０を利用している時間認識ネットワーク２００を示している。それぞれのネットワーク・クロックドメイン２１０、２２０、および２３０は、ディスクアレイ２１４、２３４、ネットワークプロセッサ２２４、およびタワーボックス２３６を含む共有ネットワークリソースに対する同期したアクセスを提供している。時間認識ネットワーク２００は、一つのネットワーク・クロックドメイン当たり、少なくとも一つのロッキング・オーソリティをさらに含んでいる。図２に示されているように、ロッキング・オーソリティ２１２は、ネットワーク・クロックドメイン２１０を生成かつ維持している。同様に、ネットワーク・クロックドメイン２２０および２３０は、それぞれ、ロッキング・オーソリティ２２２／２３２によって維持されている。ロッキング・オーソリティは、ネットワーク・クロックドメイン２１０、２２０内に示されているように、時間認識ルーターと共に内蔵可能であることに留意することが重要である。あるいは、この代わりに、ロッキング・オーソリティは、ネットワーク・クロックドメイン２３０に示されているように、時間認識ルーターの外に存在することも可能である。
【００４４】
図２にさらに示されているように、それぞれのロッキング・オーソリティは、少なくとも一つの共有リソースと関連付けられている。例えば、ネットワーク・クロックドメイン２１０内のロッキング・オーソリティ２１２は、ディスクアレイ２１４に対するアクセスを制御している。また一方で、ネットワーク・クロックドメイン２３０を維持しているロッキング・オーソリティ２３２は、タワーボックス２３６とディスクアレイ２３４という２つの共有リソースに対するアクセスを制御している。
【００４５】
それぞれのロッキング・オーソリティ２１２、２２２、および２３２は、少なくとも一つの確立されたネットワークドメイン２１０、２２０、および２３０を維持する責任を担っている。クライアントは、ロッキング・オーソリティによって制御されている共有リソース（すなわち、ディスクアレイ２１４、２３４、ネットワークプロセッサ２２４、およびタワーボックス２３６）に対してアクセスするべく、ネットワーク・クロックドメインに参加する。なお、ロッキング・オーソリティは、複数のネットワーク・クロックドメインを確立することが可能であるが、わかりやすくするべく、図２には、一つのロッキング・オーソリティ当たり、一つのネットワーク・クロックドメインのみが示されている。
【００４６】
図２にさらに示されているように、ネットワーク・クロックドメイン２１０は、現在、このドメインに参加している２つのクライアント２１５、２１６を具備している。同様に、ネットワーク・クロックドメイン２２０も、このドメインに参加している２つのクライアント２１６、２２６を具備している。現在、２つのネットワーク・クロックドメイン２１０、２２０を利用しているクライアント２１６が示しているように、単一のクライアントが複数のネットワーク・クロックドメインに参加することが可能であることは明らかである。
【００４７】
（ａ．ネットワーク・クロックドメインの初期化）
簡単にいえば、ネットワーク・クロックドメインの初期化の際に、ロッキング・オーソリティは、ロッキング・オーソリティに接続されるネットワークリソースの数、接続されるリソースのタイプ、およびこれらのネットワークリソースのトランザクションロッキングに関する能力を判定しなければならない。図３は、ネットワーク・クロックドメインを初期化するべくロッキング・オーソリティによって実行される動的なプロセスを示すフローチャートである。
【００４８】
このプロセスは、ロッキング・オーソリティ自体の初期化から始まっている。ステップ３０１において、ロッキング・オーソリティは、ネットワーク管理者によって提供される構成パラメータを受け付ける。これらのパラメータには、サポートされるクロックドメインの数、制御されるリソースのタイプ、および、それぞれサポートされるネットワーク・クロックドメインの特性および能力が含まれている（ただし、これらに限定されない）。
【００４９】
ロッキング・オーソリティの初期化（ステップ３０１）が完了したら、ロッキング・オーソリティは、ループ動作をしつつ、ステップ３０３に示されているように、そのポートに問い合わせることにより、接続されているネットワークリソースを識別する。ステップ３０５において、接続されているネットワークリソースが発見されたかどうかを判定する。図５に関連してさらに詳細に説明するように、ステップ３０７は、ネットワークリソースの識別に成功した際には、ネットワークリソースが列挙されかつ検証されることを示している。また一方で、接続されたネットワークリソースが発見されない場合には、本プロセスは、ステップ３０３に戻り、この結果として、ロッキング・オーソリティは、可能な接続されているネットワークリソースについてポートに問い合わせることができる。ステップ３０７が完了すると、ロッキング・オーソリティは、ステップ３０９に示されているように、クライアントの問合せを待つアイドル状態に入る。
【００５０】
図５は、接続されているネットワークリソースをロッキング・オーソリティが識別した際に実行される列挙プロセスおよび検証プロセスを示すフローチャートである（図３のステップ３０７を参照されたい）。ステップ５０３において、ロッキング・オーソリティは、ポートに接続されている識別されたネットワークリソースに対してアドレス要求を送信する。この要求の形態は、基礎をなしているネットワークのタイプによって左右される。例えば、ＴＣＰ／ＩＰネットワークにおいては、ロッキング・オーソリティは、ＡＲＰ（Address Resolution Protocol）メッセージを装置に対して送信することが可能である。次いで、ステップ５０５に示されているように、要求されたアドレスの受信について判定する。要求されたアドレスをロッキング・オーソリティが受信する前に既定量の時間が経過した場合には、この要求は、ステップ５０６に示されているように、タイムアウトになる。次いで、ロッキング・オーソリティは、ステップ５０７に示されているように、列挙および検証プロセスを終了し、次のポートに移動する。しかしながら、要求されたアドレスが、接続されているネットワークリソースから受信された場合には、ロッキング・オーソリティは、ステップ５０９に示されているように、受信したアドレスを使用して追加情報要求をネットワークリソースに対して送信する。
【００５１】
図５に関し継続して説明すれば、接続されているネットワークリソースは、ステップ５１１において、追加情報要求を受信している。ステップ５１３において、接続されているネットワークリソースが、クライアント、サーバー、または専用のリソースとは対照的に、共有ネットワークリソースであるかどうかを判定する。接続されているネットワークリソースが共有ネットワークリソースである場合には、本プロセスは、ステップ５１５に継続し、そのネットワークリソースのタイプが、ロッキング・オーソリティによって制御可能であるかどうかを判定する。接続されている装置が共有リソースであり、かつ、接続されている装置がロッキング・オーソリティによって制御可能なリソースである場合には、本プロセスは、ステップ５１７に進む。ステップ５１３およびステップ５１５において否定的な判定が下された場合には、本プロセスは、列挙手順および検証手順を終了し、ステップ５０７に示されているように、次のポートに移動する。
【００５２】
ステップ５１７を再度参照すれば、接続されているネットワークリソースが共有されており、ロッキング・オーソリティによって制御可能であるという判定が下された際には、ロッキング・オーソリティは、接続されているネットワークリソースのトランザクション能力を評価する。接続されているネットワークリソースの能力の評価については、図６との関連において説明する。列挙プロセスおよび検証プロセスとネットワークリソースの能力判定のプロセスを通じて取得された情報を使用し、ロッキング・オーソリティは、ステップ５１８に示されているように、ネットワークリソース用のネットワーク・クロックドメインパラメータブロックを確立する。このクロックパラメータブロックの重要性と利用法については、後程、さらに詳細に説明する。
【００５３】
次に図６を参照すれば、ネットワークリソースのトランザクション能力を判定するプロセスを示すフローチャートが提供されている。ステップ６０１において、ロッキング・オーソリティは、試験トランザクションのセットを送信し、リソースのトランザクション応答時間能力を判定する。試験トランザクションは、ネットワークリソースのタイプに依存したものであってよい。例えば、ストレージネットワークリソースの場合には、試験は、問合せデータ命令、読み取り能力命令、これに続く試験ユニット準備完了命令であってよい。この後には、読み取りおよび書き込み命令のセットが続くことになろう。試験が完了すると、ステップ６０３において、ロッキング・オーソリティは、これらの試験トランザクションまたは命令に対する応答において、ネットワーク装置の平均、最小、および最大応答時間を判定する。応答時間の試験に使用される命令の数は、システム管理者によって構成可能であってよいが、通常は、１００トランザクションを範囲とするものとなるであろう。この結果、初期化プロセスを過度に遅延させることなしに、統計的な平均が得られる。ステップ６０５に示されているように、ネットワークリソースのトランザクション応答時間能力はメモリ内に保存される。
【００５４】
リソースのトランザクション応答時間能力の判定が完了したら、ロッキング・オーソリティは、ステップ６０７に示されているように、アンワインド（Unwind）試験トランザクションをネットワークリソースに対して送信する。アンワインド試験トランザクションは、ネットワークリソースがトランザクションのアンワインドを実行する能力を有しているかどうかを判定する。ネットワークリソースがアンワインド試験トランザクションを完了したら、ロッキング・オーソリティは、ステップ６０９に示されているように、トランザクションアンワインド命令をネットワークリソースに送信する。ステップ６１１において、ネットワークリソースがアンワインド命令を拒絶した場合には、ネットワークリソースは、リソースサイド・トランザクションアンワインドを実行する能力を有していないものと判定される（ステップ６１３を参照されたい）。ステップ６１３に示されているように、ネットワークリソースがリソースアンワインドを実行する能力を有していないと判定された際には、ロッキング・オーソリティは、ステップ６１７において、リソーストランザクション能力プロセスを終了し、すべてのトランザクションについて、ロッキング・オーソリティがクライアントサイドのアンワインドを使用するようにする。また一方で、ステップ６１５に示されているように、ネットワークリソースがアンワインド命令を受け入れ、試験トランザクションに対して正しくアンワインドを行った場合には、ロッキング・オーソリティは、リソースサイドのアンワインド処理を使用してクライアントのロッキング要求を再順序付けすることになる。リソーストランザクション能力の判定が肯定的および否定的のいずれの場合にも、本プロセスは、ステップ６１７に示されているように終了し、ステップ５１８に戻り、図５に関連して図示しかつ説明したように、リソースについてネットワーククロックパラメータブロックを確立する。
【００５５】
（ｂ．クロックパラメータブロックとネットワーク・クロックドメイン）
クロックパラメータブロックは、ネットワーク・クロックドメインに参加するためにクライアントが満足しなければならない要件を定義しており、ネットワーク・クロックドメインの生成とこれに対する参加の際に有用である。すなわち、これらのパラメータは、基本的に、クライアントおよびネットワークリソースが絶対時間値を使用して通信できるようにするネットワークリソースの要件を定義している。クロックパラメータブロック内に記述されるパラメータの例には、最小クロック正確度、最小クロック精度、クロック値（通常、単位はナノ秒（ｎｓｅｃ）である）、クロック位相の数、およびクロック時間の開始値が含まれている（ただし、これらに限定されない）。
【００５６】
クロックパラメータブロック内のパラメータは、ネットワーク通信の時間設定において使用する内部の「擬似クロック」をクライアントが生成する方法をさらに定義している。ネットワーク・クロックドメインを確立したロッキング・オーソリティは、マスタークロックソースの供給や実際のクロック情報または信号の交換を要することなしに、クライアントとロッキング・オーソリティが時間同期した動作を実行できるように、同一の擬似クロックを生成する。
【００５７】
図７は、ネットワーク・クロックドメインパラメータと絶対時間値とを使用して擬似クロックを生成する方法を示している。具体的には、ネットワーク・クロックドメインパラメータブロック７０１は、クロックパラメータブロック内に提供されているすべての時間クロックの単位（例えば、ナノ秒、ピコ秒）を定義している。換言すれば、クロックパラメータブロック内の第１パラメータは、クロックパラメータブロック内のその他のパラメータに使用する時間の単位を定義している。クロックパラメータブロックは、クライアントがその内部のＧＰＳ時間回復回路を使用して保証することを要する絶対時間値の最小正確度および精度値を含んでいる。これらの値を保証できない場合には、クライアントは、ネットワーク・クロックドメインに参加することができない。
【００５８】
クライアントは、ＧＰＳ絶対時間レジスタ７０３内に保存されている時間値をクロックパラメータ７１０に記述されている最小絶対時間更新レート以上のレートで更新する。この値は、更新されるたびに、クロックチック係数および位相０のクロックチック係数（クロックが複数位相を具備している場合）と比較される。係数値が、クロックパラメータブロック７０１内の絶対時間精度未満である場合には、クロック時間チック７０５が生成される。クロック時間チック７０５を使用して擬似クロックの次のエッジを定義している。この結果、一連のクロック時間チック７０５は、必要な正確度および精度の仕様を満足する擬似クロック７０７の一つまたは複数の位相を生成する。生成された擬似クロック７０７を監視することにより、クロックパラメータブロック７０１内に規定されている最大ジッタ未満のジッタによって擬似クロックが生成されることを保証する。生成される擬似クロック７０７のジッタを監視することにより、ロッキング・オーソリティを利用するのに必要な正確度および精度の提供を擬似クロックが継続することを保証する。
【００５９】
（ｃ．ネットワーク・クロックドメインへの参加）
クライアントは、動的に、または先験的な知識を使用することにより、ネットワーク・クロックドメインに参加することが可能である。クライアントは、ネットワーク・クロックドメインに参加するのに必要な能力および構成を見出すべくロッキング・オーソリティに要求を送信することにより、ネットワーク・クロックドメインに動的に参加する。換言すれば、クライアントは、ロッキング・オーソリティに対してクロックパラメータブロックを要求し、クロックパラメータブロックが、ロッキング・オーソリティからクライアントに送信される。
【００６０】
クライアントがクロックパラメータブロック内に記述されている要件を満足する能力を有している場合には、クライアントは、確認メッセージをクロッキング・オーソリティに対して伝送する。確認メッセージを伝送した際に、クライアントは、ネットワーク・クロックドメインに参加したものと見なされる。クライアントは、ネットワーク・クロックドメインに参加すると、ロッキング・オーソリティによって制御されているネットワークリソースのロックとこれに対する排他的なアクセスを得ることができる。
【００６１】
さらに詳しくは、図４および図４ａは、図３において初期化されたネットワーク・クロックドメインにクライアントが参加するプロセスを示すフローチャートである。具体的には、ネットワーク・クロックドメインに対するクライアントの追加は、そのクライアントによって起動される。クライアントは、ステップ４０１に示されているように、待機中のロッキング・オーソリティに対してネットワークリソース問合せメッセージを送信することにより、ネットワーク・クロックドメインに参加するプロセスを開始する。ステップ４０３において、クライアント問合せが受信されているかどうかについて判定される。要求が受信されていない場合には、本プロセスは、ステップ４０１によって表されているそのアイドル状態にロッキング・オーソリティを戻す。また一方で、クライアントの問合せの受信に成功している場合には、ステップ４０５において、ロッキング・オーソリティは、ステップ４０３において示されている要求されたタイプのリソースを自身が制御しているかどうかを判定する。要求されているリソースをロッキング・オーソリティが制御していない場合には、ステップ４０６において、拒絶メッセージが要求元のクライアントに伝送される。あるいは、この代わりに、要求されているリソースをロッキング・オーソリティが制御している場合には、本プロセスは、ステップ４０７に継続し、ロッキング・オーソリティは、問合せ応答メッセージにより、クライアントのメッセージに対して応答する。この問合せ応答メッセージには、そのクライアントがサポート可能なネットワーク・クロックドメインパラメータについて記述したクロックパラメータブロックの送信を求めるクライアントに対する要求が含まれている。
【００６２】
ステップ４０９において、ロッキング・オーソリティは、クライアントの能力について記述する問合せ応答メッセージに対する応答を受信する。ロッキング・オーソリティは、クライアントからの応答が受信されない場合には、ステップ４０８に示されているように、待機状態を維持する。ステップ４１１において、ロッキング・オーソリティは、クライアントの能力をネットワーク・クロックドメインの要件と比較する。クライアントの能力が、ネットワーク・クロックドメインに必要な要件の許容可能な範囲内にある場合には、クライアントは、ステップ４１３に示されているように、ネットワークドメインに参加することが許される。ネットワーク・クロックドメインへの参加が許された際には、ステップ４１５において、確認メッセージがクライアントに伝送され、この結果、クライアントは、同一のネットワーク・クロックドメインに参加している共有リソースに対するアクセスを要求できるようになる。また一方で、クライアントの能力が、ネットワーク・クロックドメインによって記述されている要件に適合しない場合には、ステップ４１７に示されているように、ドメインに参加するというクライアントの要求は拒絶される。
【００６３】
ネットワーク・クロックドメインに参加することにより、クライアントは、共有リソースに対するアクセスを要求すると共に、後述するロッキング方式に参加することができる。この間に、ロッキング・オーソリティは、制御されたリソースに対するその他のクライアントによるアクセス要求を待つ状態を継続しており、この要求が発生した場合には、図４に関連して説明したプロセスが反復される。
【００６４】
このネットワークドメインの一般的な原理は、すべてのクライアントに適用される。例えば、クライアントがネットワーク・クロックドメインに参加またはこれから離脱する時点は、ネットワーク・クロックドメインの動作に対して影響を与えない。さらには、ドメインから離脱するためにクライアントに要求されることはなにもない。複数のクライアントがドメインに参加することを所望している場合には、ロッキング・オーソリティは、パケットの伝送タイムスタンプによって判定される順番どおりに、受信したパケット要求を配列することになる。時間認識装置（または、クライアント）は、複数のネットワーク・クロックドメインに参加することが可能であるが、共有リースは、単一のネットワーク・クロックドメインにのみ参加することが可能であるということが重要である。
【００６５】
なお、先程簡単に説明したように、クライアントは、先験的な知識を介しても、ネットワーク・クロックドメインのメンバーとなることが可能である。クライアントが先験的な知識を介してメンバーとなる場合には、ドメインに参加するのに必要な知識は、単純に、ロッキング・オーソリティを構成する際にシステムまたはネットワーク管理者から提供される。
【００６６】
（Ｖ．ロッキング・オーソリティ）
クライアントは、ネットワーク・クロックドメインへの参加に成功したら、ロッキング・オーソリティを介して共有リソースに対するアクセスの要求を開始することが可能である。ロッキング・オーソリティは、リソースアクセスの順番どおりの配列および同期化がそれぞれのクライアントに対して提供されることを保証する不可欠な手段である。さらには、ロッキング機能は、パケットと関連した伝送タイムスタンプによる正しいシーケンスでパケット要求が処理されることを保証することにより、共有リソースのデータの一貫性を維持している。
【００６７】
（ａ．ロッキング・オーソリティの説明）
ロッキング・オーソリティは、多数の物理的に異なる形態において実現可能である。例えば、ロッキング・オーソリティは、ストレージ装置等のネットワークリソース内に内蔵することが可能である。これは、時間認識ルーター内に内蔵することも可能であり、あるいは、時間認識ネットワーク上の別個の独立した物理的ユニットとして存在することも可能である。
【００６８】
図８は、ロッキング・オーソリティの論理的な構造を示している。図示のように、ロッキング・オーソリティは、ネットワーク・クロックドメインロジック８０１、クライアントインターフェイスロジック８０３、リソースインターフェイスロジック８０５、およびトランザクション制御ロジック８０７という４つの主要なロジックブロックから構成されている。
【００６９】
（１．ネットワーク・クロックドメインロジック）
ネットワーク・クロックドメインロジック８０１は、ドメインパラメータ制御機能８０９とドメインメンバーシップ制御機能８１１という２つの主要な機能を実行する。第１の機能であるドメインパラメータ制御機能８０９は、リソースおよびネットワークの能力に適切なネットワーク・クロックドメインパラメータを確立する。さらには、ドメインパラメータ制御機能８０９は、複数のネットワーク・クロックドメインを確立するべく構成可能である。複数のネットワーク・クロックドメインを確立する主な理由は、異なる能力を有するクライアントが共有リソースにアクセスできるようにすることにある。例えば、いくつかのクライアントは、相対的に高いタイミングの正確度または精度の能力を有しており、その他のものは、ロック要求を実行可能な時間スロットを取得するべくポーリング法を使用している。したがって、ドメインパラメータ制御機能８０９は、ネットワーク・クロックドメインへの参加を試みるクライアントに必要な能力に加えて、ネットワーク・クロックドメインによってサポートされているロッキング法のタイプをも判定する。
【００７０】
ネットワーク・クロックドメインロジック８０１内の第２の機能は、ドメインメンバーシップ制御機能８１１である。この機能は、ネットワーク・クロックドメインパラメータに対するクライアント要求に応答すると共に、ネットワーク・クロックドメインに参加したいというクライアントからの要求を受信している。この機能は、ドメインへの参加を試みるクライアントが、参加するのに必須の能力を具備していることを保証するロジックを含んでいる。
【００７１】
（２．クライアントインターフェイスロジック）
クライアントインターフェイスロジック８０３は、時間認識ネットワークに対するインターフェイスとして機能している。このクライアントインターフェイスロジック８０３は、パケットがネットワーク上において様々なクライアントから到来した際に、タイムスタンプをチェックかつ比較するのに必要なロジックを含んでいる。また一方で、クライアントインターフェイスロジックは、クライアントのトランザクションアンワインド能力をそれぞれのクライアントから取得している。
【００７２】
（３．リソースインターフェイスロジック）
リソースインターフェイスロジック８０５は、制御されているリソースに対する専門的なインターフェイスを提供している。リソースインターフェイスは、アクセスされるリソースのタイプに固有のものである。また一方で、リソースインターフェイスロジックは、共有リソースのトランザクションのキューイングおよびアンワインド能力をも判定している。
【００７３】
（４．トランザクション制御ロジック）
トランザクション制御ロジック８０７は、ロック制御機能８１３、トランザクション制御機能８１５、およびトランザクションアンワイド機能８１７という３つの主要な機能から構成されている。これらの３つの機能は、協働し、後程詳述する図９〜図１２に図示されている様々なロッキングシナリオのラダー図（Ladder Diagrams）のロジックを構成している。
【００７４】
ロック制御機能８１３は、クロックドメインメンバーシップ制御機能８１１から、ネットワーク・クロックドメインに参加しているクライアントのリストを取得する。また一方で、クロック制御機能８１３は、クライアントインターフェイスロジック８０３から、ロック要求パケットの到着順序をも取得する。ロック制御機能は、この情報を使用することにより、リソースおよびクライアントの能力の現在の状態に応じて、クライアントのロック要求を許可、拒絶、またはキューイングする。
【００７５】
トランザクション制御機能８１５は、トランザクション要求と応答をクライアントから共有リソースに接続している。さらには、トランザクション制御機能８１５は、共有リソースから、共有リソースのロックを現在保持しているクライアントに戻るデータ経路を確立している。さらには、トランザクション制御機能８１５は、共有リソースの能力とロッキング・オーソリティの特定の構成に応じて、ロックの持続時間にわたってトランザクション履歴８１９を維持している。クライアントのリソースがアンワインドを行う能力を有している場合には、トランザクションアンワインドコントローラ８１７は、このトランザクション履歴８１５を使用してトランザクションに対するアンワインドを行うことが可能である。クライアントがデータおよびトランザクションの状態の一貫性を保持するように、ロックが拒絶または保留されているその他のクライアントに対してトランザクション履歴８１９を提供することも可能である。
【００７６】
（ｃ．ロッキングシナリオ）
時間認識装置から送信された到来パケットの伝送順序を再構築かつ保持する能力は、スケールフリーネットワーク内においてデータの一貫性を維持するための鍵である。パケットを順序付けすることにより、制御メッセージおよび状態メッセージに加えて、データシーケンスの順序に関する適切な情報がクライアントおよびサーバーの両方に提供される。この結果、ロッキング・オーソリティ等の複数ソースからの複数パケットの受信者は、伝送の順序に基づいてパケットをソーティングし、これに相応し、受信した命令を処理可能である。このパケットのシーケンシング、順序付け、およびソーティングの概念は、後程詳述する多数のロッキングシナリオを使用して実現される。なお、これらのロッキングシナリオは、複数のクライアントを伴うことが可能であるが、後述する代表的な実施例は、わかりやすくするべく、２つのクライアントに限定されていることに留意することが重要である。
【００７７】
後述するロッキングシナリオは、２つのクライアント、ロッキング・オーソリティ、および共有リソースを伴っており、これらは、いずれも、ロッキング・オーソリティによってセットアップされたネットワーク時間ドメインのメンバーである。時間ラダー図を使用することにより、左側のクライアントと、中間のロッキング・オーソリティと、右側のネットワークリソースとの間のトランザクションおよび通信のシーケンスと依存性を示している。
【００７８】
それぞれのロッキングシナリオは、クライアント要求が異常な状態において受信された際に、一つのクライアントに対してロックを許可すると共に、その同一のロックに関する別のクライアントからの要求を再順序付けするべく、クライアントとロッキング・オーソリティが使用する異なる方法を示している。これらの代表的なロッキングシナリオにおいては、ロック要求は、共有リソースに対する排他的なアクセスを目的としている。このような要求の一例は、読み取り／書き込みロックであってよい。読み取り専用ロック等のいくつかのロック要求は、排他的である必要はない。複数の読み取り専用ロックを複数のクライアントに同時に許可することができる。したがって、ロッキングの問題は、クライアントが読み取り／書き込みロック等の排他的なロックを要求した際に発生する。読み取りロックが許可された後に、読み取り／書き込みロック要求が送信されると、読み取り／書き込みロックは、読み取りロックが解放されるまで、保留中の要求として保持されることになる。また一方で、ラダー図に示されている応答という用語は、クライアントによって要求されているデータまたはトランザクション情報を意味している。一般に、この応答が完了すると、ネットワークリソースに対するロックが自動的に解放される。
【００７９】
（１．基本的な異常状態拒絶）
図８に示されているように、トランザクション制御機能は、クライアントからのトランザクション要求と応答を接続している。しかしながら、図９は、基本的な異常状態拒絶ロッキングシナリオを示す図である。さらに詳しくは、図９は、ロッキング・オーソリティが、クライアントからのロック要求の拒絶を使用することにより、クライアントの要求を再キューイングすると共に、データの一貫性の維持を保証する方法を示している。
【００８０】
図示のように、クライアント１が、ロッキング・オーソリティに対して共有リソースのロック要求９０１を発行する。次いで、クライアント２も、同一の共有リソースに関するロック要求９０３を発行する。
【００８１】
通常は、クライアント１が、ロックを受信し、そのトランザクションを実行することになるであろう。クライアント２からの要求９０３は、ロッキング・オーソリティによってキューイングされ、クライアント１が保持しているロックが解放された直後に、許可されることになるであろう。クライアント２は、要求がブロッキング要求であるかまたは非ブロッキング要求であるかに応じて、ロックの許可を待つ間、動作を一時停止してもよく、あるいは、一時停止しなくてもよい。
【００８２】
しかしながら、このシナリオにおいては、ロッキング・オーソリティは、クライアント１から伝送されたロッキング要求９０１を受信する前に、クライアント２から要求９０３を受信している。このクライアント１の要求９０１の遅延は、ネットワークトランスポートの遅延等のいくつかの要因によって発生することが可能である。要約すれば、ロッキング・オーソリティは、異常な状態において、これらの要求を受信しているのである。この時点において、ロッキング・オーソリティは、先行するロック要求をクライアント１が発行していることを認知しておらず、したがって、ロッキング・オーソリティは、共有ネットワークリソースのロック９０５をクライアント２に対して許可することになる。
【００８３】
クライアント１からのロック要求９０１が到来した際に、ロッキング・オーソリティは、要求パケット内の絶対タイムスタンプから、要求９０１が最初に発行されており、異常な状態で到着したことを判定する。ロッキング・オーソリティは、これらの要求と関連したクライアント１および２のトランザクションに関する情報を具備していないため、この要求を許可するかどうかについて判定することができない。
【００８４】
この結果、ネットワークリソースからロッキング・オーソリティに送信されている応答９０６と、クライアント２に送信されているロッキング・オーソリティの応答９０８に示されているように、トランザクション要求９０３が完了する。ロッキング・オーソリティは、クライアント１からの要求９０１を拒絶（９０７）することにより、この曖昧さを処理する。この結果、ロッキング・オーソリティが要求を許可しなかったことが、クライアント１に対して通知されることになる（９０７）。
【００８５】
この特定の構成においては、クライアント１には、要求が異常な状態において受信されたという事実を上回る拒絶の理由に関する情報は提供されない。この結果、クライアント１は、新しいタイムスタンプを有する新しい要求９０９を再キューイングし、新しい要求９０９をロッキング・オーソリティに対して発行する。この段階では、この要求は、クライアント２からの要求９０３の後に順序付けされるため、ロッキング・オーソリティは、クライアント２がそのトランザクションを完了させてロックを解放するまで（応答メッセージ９０６を参照されたい）、要求９０９を待機状態に保持する。そして、その時点において、クライアント１からのロック要求９０９を許可し（９１３）、これによって、リソースにおけるデータの一貫性と、クライアント１およびクライアント２の両方によって実行されるトランザクションの一貫性を保持する。このトランザクションが完了すると、クライアント１は、共有リソースに対するロックを解放する（９１５）。さらには、応答９１７が、ロッキング・オーソリティからクライアント１に伝送され、トランザクションの完了の結果としてのロックの解放が確認される。
【００８６】
（２．リソースアンワインドを有する基本的な再順序付け）
図１０は、要求が異常な状態において受信された際に、ロッキング・オーソリティがロック要求およびトランザクションを再順序付けする方法を示す図である。このロッキングシナリオにおいては、ロックされる共有リソースは、データの一貫性を保持するべくトランザクションに対するアンワインドを行う能力を有している。ただし、アンワインド能力は、トランザクションが完了した後に経過した時間量またはトランザクションのサイズおよびコンテンツによって左右されることになる。
【００８７】
いくつかのリソースアンワインドおよび再順序付けのケースにおいては、共有リソースがアンワインド要求を拒絶する場合がある。このような状況においては、ロッキング・オーソリティは、図９と関連して説明した異常状態におけるロック要求の基本的な拒絶の使用に戻ることになる。
【００８８】
ここで、図１０を参照すれば、クライアント１がロック要求１００１を発行する。次いで、クライアント２もロック要求１００３を発行する。ロッキング・オーソリティは、要求１００３を先に受信するため、クライアント２のロック要求１００３を認可する（１００５）。しかしながら、ネットワークの遅延およびレイテンシーに起因し、クライアント１からの要求１００１が、クライアント２からの要求１００３の後に受信される。ロッキング・オーソリティは、クライアント１のロック要求１００１内の伝送に基づいたタイムスタンプを使用することにより、要求１００１が異常な状態において受信されたことを判定する。
【００８９】
したがって、ロッキング・オーソリティは、クライアント２からの命令およびトランザクションの処理を一時停止する。次いで、ロッキング・オーソリティは、アンワインド要求１００７を共有リソースに送信する。共有リソースは、ロック１００５が許可された以降のクライアント２と関連するすべてのトランザクションおよび命令に対するアンワインドを行うことになる。ロッキング・オーソリティがトランザクション１００７のアンワインドを完了すると、ネットワークリソースに対するクライアント２のロックが解放される（１０１０）。アンワインドが不可能な場合には、時間量またはトランザクションの特性に起因し、リソースは、アンワインド要求を拒絶することになる（図示されてはいない）。
【００９０】
アンワインド要求１００７が成功したと仮定すれば、ロッキング・オーソリティは、クライアント２のロック要求とクライアント２に関連するすべてのトランザクションを再キューイングすることになる。次いで、ロッキング・オーソリティは、ロックをクライアント１に許可し（１０１１）、クライアント１は、その命令およびトランザクションによって処理を進行させることが可能である。トランザクションが完了すると、ネットワークリソースに対するロックが解放され（１０１３）、ロッキング・オーソリティは、完了したトランザクションについてクライアント１に通知する（１０１４）。また一方で、リソースは、クライアント２に対して再度ロックされ（１０１５）、クライアント２のトランザクションが進行することになる。クライアント２のトランザクションが完了すると、ネットワークリソースに対するロックが解放され（１０１６）、ロッキング・オーソリティは、完了したトランザクションについてクライアント２に通知する（１０１７）。
【００９１】
この手順の利点は、アンワインドおよび再許可がクライアント２に対してトランスペアレント（Transparent）であるという点にある。クライアント２は、自身のトランザクションを満足するのに通常予想されるものよりも長い時間を要したということに気付くのみである。ただし、データの一貫性および完全性を保持する方式によって、そのトランザクションに対するサービスを行うためにクライアント２に対して要求されるような、さらなるアクションや応答は存在しない。
【００９２】
（３．クライアントアンワインドを使用した再順序付け）
図１１は、クライアントが、既に進行中のトランザクションに対するアンワイドを行う能力を有する場合にロッキング・オーソリティが異常状態において受信した要求を再順序付けする方法を示している。この特定のロッキングシナリオにおいては、クライアント１が、ネットワークリソースを制御しているロッキング・オーソリティに対してロッキング要求１１０１を送信する。次いで、クライアント２が、この同一のリソースに対するロック要求１１０３を送信する。ネットワークの遅延およびレイテンシーに起因して、ロッキング・オーソリティは、まず、クライアント２からのロック要求１１０３を受信し、ロック要求１１０５を許可する。クライアント１からのロック要求１１０１が到着した際に、ロッキング・オーソリティは、クライアント１からのロック要求１１０１を搬送するパケット内に含まれている伝送に基づいたタイムスタンプをチェックすることにより、要求１１０１が異常な状態において受信されたことを判定する。また一方で、ネットワークリソースからロッキング・オーソリティ、そして、クライアント２に伝送されている応答１１０４によって示されているように、クライアント２の要求は、既に完了している。
【００９３】
応答１１０４は、クライアント１の要求１１０１の受信よりも前にクライアントによって受信されているため、クライアントサイドのアンワインドを実行することになる。ネットワーク・クロックドメインを構成する時点において、クライアント２は、それ自身が、進行中のトランザクションに対するアンワインドを行う能力を有していると通知している。したがって、ロッキング・オーソリティは、クライアント２のトランザクションを一時停止し、アンワインド要求１１０６をクライアント２に送信する。クライアント２は、要求を受け入れ（アンワインドアクノリジ）（１１０７）、ロッキング・オーソリティは、トランザクションに対するアンワインドを行う（１１０８）。次いで、ネットワークリソースは、メッセージ１１０９をロッキング・オーソリティに送信することにより、アンワインドトランザクションに対して応答する（アンワインドアクノリジ）。
【００９４】
次いで、ロッキング・オーソリティは、クライアント１のロック要求を許可し、クライアント１のトランザクションの処理を進める（１１１３）。完了すると、ロックが解放され（１１１４）、トランザクションが完了したことが、ロッキング・オーソリティによってクライアント１に通知される（１１１５）。次いで、ロッキング・オーソリティは、クライアント２に対してロックを許可し（１１１６）、クライアント２のトランザクションの処理を進める。同様に、ロックが最終的に解放され（１１１７）、トランザクションが完了したことが、ロッキング・オーソリティからクライアント２に対して通知される（１１１８）。
【００９５】
クライアントアンワインドを使用する利点は、トランザクションに対するアンワインドを行う方式に関する完全な制御をクライアントが保持しているという点にある。また一方で、クライアントは、クライアント１からのアンワイド動作および追加的な動作に基づいてトランザクションを変更または削除するべく判定可能である。クライアントアンワインドを使用する欠点は、相対的に大きなネットワークトラフィックが要求されると共に、相対的に高度なソフトウェアおよびトランザクションの維持管理をクライアントが具備する必要があるという点にある。
【００９６】
（４．クライアントアンワイド要求の拒絶）
図１２は、クライアントのアンワインド要求を拒絶するロッキングシナリオを示す図である。さらに詳しくは、図１２は、クライアントがロッキング・オーソリティからのアンワインド要求を拒絶した際に発生するイベントシーケンスを示している。
【００９７】
以前と同様に、クライアント１がロック要求１２０１を送信し、次いで、クライアント２がロック要求１２０３を送信する。クライアント２からのロック要求１２０３が、まず受信され、ロッキング・オーソリティによってロックが許可される（１２０５）。クライアント１からの要求１２０１が到着した際に、ロッキング・オーソリティは、クライアント１からのロック要求を搬送しているパケット内の伝送タイムスタンプをチェックすることにより、それが異常な状態において受信されたことを判定する。しかしながら、応答メッセージ１２０４によって示されているように、ロッキング・オーソリティがクライアント１から要求１２０１を受信する前に、既に応答がクライアント２に対して送信されている。この結果、ロッキング・オーソリティは、基本的に、ロッキング・オーソリティから送信された応答メッセージ１２０６を無視するようにクライアント２に対して要求することにより、クライアント２と関連したトランザクションに対するアンワインドを行うべく試みなければならない。
【００９８】
この場合には、クライアント２は、順序と一貫性を保持するべく、それ自身がトランザクションに対するアンワインドを行う能力を有していることを予め通知している。したがって、ロッキング・オーソリティは、クライアント２のトランザクションを一時停止し、クライアントに対してアンワインド要求１２０６を送信する。しかしながら、この場合には、クライアント２は、なんらかの理由により、トランザクションに対するアンワインドを行うことができない。この理由は、過剰な時間が経過したり、あるいは、クライアント２が既にその他の処理のためにトランザクションの結果を使用しているので、アンワインドがなされたトランザクションおよびデータの一貫性を保証することができなかったりするというものであるかもしれない。したがって、クライアント２は、ロッキング・オーソリティに対してアンワインド拒絶１２０９を送信する。この結果、ロッキング・オーソリティは、クライアント２のトランザクションを継続し、クライアント１に対してロック拒絶１２１３を送信することにより、クライアント１にその要求を再キューイングさせる（１２１５）。
【００９９】
クライアント２のトランザクションが完了し、ロックが解放された際に（１２１４）、クライアント１は、より最近のタイムスタンプを有する新しいロック要求１２１５をロッキング・オーソリティに送信する。この要求１２１５は、異常な状態にはないため、クライアント２のトランザクションが完了すると許可される（１２１６）。完了すると、ロックが解放され（１２１７）、ロッキング・オーソリティは、トランザクションの完了についてクライアント１に通知する（１２１８）。
【０１００】
（ｄ．ロッキングエラーの処理）
時間認識ネットワークおよびその関連するネットワーク・クロックドメインは、ネットワーク上において発生する様々なロッキングエラーの安定した簡単な処理を提供している。残念ながら、多数の状況に起因してエラー状態が発生する。例えば、エラー状態は、ネットワーク上においてパケットが消失したり、または過剰に遅延したりしたために発生する。遅延したパケットは、最終的に到着し、既に発生しているであろうデッドロック状態も解消されることになるため、最悪のケースはパケットの消失である。しかし、パケットが消失した場合にも、送信元の装置は、長いタイムアウト期間を除いて、消失を検証する方法を具備しておらず、したがって、パケットが受信されなかったことを認知する方法が存在していない。
【０１０１】
ロックを要求または保持しているクライアントが、クラッシュ（Crash）を起こしたり、あるいは、なんらかのその他のタイプの破局的な動作エラーを経験したりした際に、エラー状態の別の例が発生する。ロッキング・オーソリティと、ロックされているリソースは、クライアントがもはや正しく動作していないことを認知する方法を具備していない。クライアントがその時点においてロックを保持または要求している場合には、ロックを解放しなければならず、かつ、クライアントからのさらなる要求または保留中の要求を拒絶しなければならない（さもなければ、この結果として、デッドロック状態が発生することになる）。同様に、リソースまたはロッキング・オーソリティも、なんらかの破局的な動作上のエラーを経験する可能性がある。保留中のロックを有するクライアントは、この状況について通知を受ける方法を具備しておらず、このため、結果的にデッドロックが発生することになる。
【０１０２】
このような状況に対する解決策は、クライアントとロッキング・オーソリティとの間における時間の適切な管理である。既定のタイムアウト値を使用して、すべてのロック要求およびロック許可を実行するのである。これらのタイムアウト値は、ネットワーク・クロックドメインのパラメータを使用して絶対時間値を解釈した絶対時間に基づいているため、これらのタイムアウトは、ネットワーク内の固有の伝送遅延およびレイテンシーを考慮し、可能な限り短いものであってよい。ロックを要求または許可した後に、これを放棄することが可能であり、この結果として、この放棄を検出し、これを訂正して正常動作を回復する能力をシステムが有していないというシナリオは存在しない。
【図面の簡単な説明】
【０１０３】
【図１】本発明に従って使用される基本時間認識ネットワークを示す図である。
【図２】３つの個別のネットワーク・クロックドメインを利用して少なくとも３つのネットワークリソースに対する同期アクセスを提供する時間認識ネットワークを示す図である。
【図３】ネットワーク・クロックドメインを初期化するべくロッキング・オーソリティが実行するプロセスを示すフローチャートである。
【図４】ネットワーク・クロックドメインに参加するクライアントのプロセスを示すフローチャート（その１）である。
【図４ａ】ネットワーク・クロックドメインに参加するクライアントのプロセスを示すフローチャート（その２）である。
【図５】接続されているネットワークリソースをロッキング・オーソリティが識別した際に実行される列挙プロセスおよび検証プロセスを示すフローチャートである。
【図６】図５に示されている列挙プロセスにおいて識別されたネットワークリソースのトランザクション能力を判定するプロセスを示すフローチャートである。
【図７】ネットワーク・クロックドメインパラメータと絶対時間値とを使用した擬似クロックの生成を示すタイミング図である。
【図８】ロッキング・オーソリティの論理的な構造を示すブロック図である。
【図９】基本的な異常状態拒絶のロッキングシナリオを示す図である。
【図１０】要求が異常な状態において受信された際に、ロッキング・オーソリティがロック要求およびトランザクションを再順序付けするロッキングシナリオを示す図である。
【図１１】既に進行中のトランザクションのアンワインドを行う能力をクライアントが有している場合に、異常な状態において受信された要求をロッキング・オーソリティが再順序付けする方法を示す図である。
【図１２】クライアントのアンワインド要求を拒絶するロッキングシナリオを示す図である。
【図１】
2007518159.tif 000003
【図２】
2007518159.tif 000004
【図３】
2007518159.tif 000005
【図４】
2007518159.tif 000006
【図４ａ】
2007518159.tif 000007
【図５】
2007518159.tif 000008
【図６】
2007518159.tif 000009
【図７】
2007518159.tif 000010
【図８】
2007518159.tif 000011
【図９】
2007518159.tif 000012
【図１０】
2007518159.tif 000013
【図１１】
2007518159.tif 000014
【図１２】
2007518159.tif 000015
【国際調査報告】
2007518159.tif 000016
2007518159.tif 000017