JP3967758B2 - シーケンス番号によるデータ通信の調整 - Google Patents

Description

本発明は、クライアントとサーバの通信用に、データ通信プロトコルに組み込む等したシーケンス番号を使用して、クライアントによるサーバリソースの使用を制御することに関する。

今日でも依然として使用されているＳＭＢ（Ｓｅｒｖｅｒ Ｍｅｓｓａｇｅ Ｂｌｏｃｋ）プロトコル等の多くのデータ通信プロトコルは、たとえばネットワークの帯域幅が一般的に限られており、メモリが非常に貴重であったこと等、コンピューティングリソースが大きく異なっていた時代に開発されたものである。

現代のネットワークにおいてこのようなプロトコルを使用すると、全体的なパフォーマンスが制限されることがある。たとえば、メモリが限られていた時代に設計されたため、小さなバッファサイズが使用されており、大量のデータを通信するにはより多くの往復が必要となる。

さらに、既存のＳＭＢプロトコルには他の制限もあり、それらも時間の経過と共に明らかになってきている。たとえば既存のＳＭＢプロトコルは、サービス妨害の攻撃の影響を受けやすく、このプロトコルの設計によって、これらの攻撃に対抗することが困難になっている。同様に、パケットのセキュリティを確保する方法も煩雑である。また、現時点でサービスライクのオペレーションの質を達成するためのメカニズムもなく、たとえば信頼できるクライアントは、信頼できないクライアントと同じサーバリソースを得る。つまりＳＭＢの既存のバージョンは、依然として頻繁に使用され有用なプロトコルではあるが、現代のネットワークリソースと共に使用する上で理想的なものとは言えない。

本発明の様々な態様は、クライアントとサーバの通信用に、データ通信プロトコルに組み込む等したシーケンス番号を使用して、クライアントによるサーバリソースの使用を制御することに関する。様々な態様は、順序付けを重要としていないプロトコルにシーケンス番号の使用を導入し、サービスの質、サービス妨害への対抗、サーバリソースの分割、安全なメッセージへの署名、及びその他の多くの利点を提供する。

サーバは、クライアントにクレジット(credit)を与え、クライアントは、各コマンドをサーバへ送信するためにクレジットを使用する。各クレジットは、シーケンス番号に対応し、シーケンス番号の組み合わせによって、有効コマンドウィンドウが形成される。サーバは、受信した各コマンドに対して、そのコマンドが、有効コマンドウィンドウ内にある１つのシーケンス番号を含み、そのシーケンス番号が別のコマンドに使用されていない状態を強制(enforce)する。サーバは、最大ウィンドウサイズを保持し、これによって、クレジットを有するクライアントであっても、最大ウィンドウサイズに対応する最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信することはできない。

一般にサーバは、クライアントからコマンドを受信すると、そのシーケンス番号がウィンドウ内にあり、以前に使用されていないことを確認する。次いでサーバは、対応するシーケンス番号を、クライアントが使用できるシーケンス番号の中から削除し、これによってクレジットを１つ消費する。そしてサーバは、クライアントに１つ又は複数の他のクレジットを与えるかどうかを決定する。

したがって、クライアントに与えられる各クレジットを表す一意の番号を含む有効オペレーションウィンドウを介して、クライアントに与えられるクレジットの数を制御することによって、サーバリソースの使用を制限するメカニズムを提供する。強制メカニズム(enforcement mechanism)は、受信したコマンドに関してさらなるサーバオペレーションを認めるために、そのコマンドが、有効オペレーションウィンドウ内にある１つのシーケンス番号を含み、その一意の番号が別のコマンドに使用されていないことを保証する。割り当てメカニズム(allocation mechanism)は、クライアントに与えられるクレジット及び有効オペレーションウィンドウ内の一意の番号を制御する。

その他の利点は、以降の詳細な説明を図面と併せて理解すれば、明らかになるであろう。

本発明は、添付の図においては限定ではなく例として示されており、同様の参照番号は、類似した要素を指している。

（例示的な動作環境）
図１は、本発明を実装できる適切なコンピューティングシステム環境１００の一例を示している。このコンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用又は機能の範囲に対して何らかの限定を提示することを意図するものではない。またコンピューティング環境１００が、この例示的な動作環境１００内に示されているコンポーネントの任意の１つ又は組合せに関して何らかの依存性又は必要性を有すると解釈すべきでもない。

本発明は、他の多くの汎用又は専用のコンピューティングシステム環境又は構成と共に使用することができる。本発明と共に使用するのに適する可能性のあるよく知られたコンピューティングシステム、環境、及び／又は構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス又はラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステム又はデバイスのいずれかを含む分散コンピューティング環境等を含むが、これらには限定されない。

本発明については、コンピュータによって実行される、プログラムモジュール等のコンピュータ実行可能命令という一般的なコンテキストにおいて説明することができる。一般にプログラムモジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含むローカルコンピュータストレージ媒体及び／又はリモートコンピュータストレージ媒体に配置することができる。

図１を参照すると、本発明を実装するための例示的なシステムは、汎用コンピューティングデバイスをコンピュータ１１０の形態で含む。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含むさまざまなシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらには限定されない。システムバス１２１は、メモリバス又はメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこのようなアーキテクチャは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、及びメザニンバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含むが、これらには限定されない。

コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる利用可能な任意の媒体とすることができ、揮発性媒体及び不揮発性媒体、ならびに着脱式媒体及び固定式媒体の双方を含む。たとえばコンピュータ可読媒体は、コンピュータストレージ媒体及び通信媒体を含むことができるが、これらには限定されない。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータ等の情報を記憶するための任意の方法又は技術において実装される揮発性媒体及び不揮発性媒体、ならびに着脱式媒体及び固定式媒体を含む。コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又はその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、又はその他の磁気ストレージデバイス、あるいは希望の情報を保存するために使用可能で、コンピュータ１１０によってアクセス可能なその他の任意の媒体を含むが、これらには限定されない。通信媒体は通常、搬送波やその他の伝送メカニズム等の変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、又はその他のデータを具体化し、任意の情報伝達媒体を含む。「変調されたデータ信号」という用語は、情報をその信号内でコード化するような方法で設定又は変更されたその特性のうちの１つ又は複数を有する信号を意味する。たとえば通信媒体は、有線ネットワークや直接有線接続等の有線媒体と、音波媒体、ＲＦ媒体、赤外線媒体、その他の無線媒体等の無線媒体とを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。

システムメモリ１３０は、コンピュータストレージ媒体を、読み取り専用メモリ（ＲＯＭ）１３１及びランダムアクセスメモリ（ＲＡＭ）１３２等の揮発性メモリ及び／又は不揮発性メモリの形態で含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中等にコンピュータ１１０内の要素間における情報伝達を補助する基本ルーチンを含み、通常はＲＯＭ１３１内に格納されている。ＲＡＭ１３２は通常、処理装置１２０がすぐにアクセスできるか、かつ／又は処理装置１２０によってその時点で操作されているデータモジュール及び／又はプログラムモジュールを含む。図１は、例としてオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、及びプログラムデータ１３７を示しているが、これらには限定されない。

またコンピュータ１１０は、その他の着脱式／固定式、揮発性／不揮発性コンピュータストレージ媒体を含むこともできる。図１は、例示のみを目的として、固定式の不揮発性の磁気媒体との間で読み取りや書き込みを行うハードディスクドライブ１４１と、着脱式の不揮発性の磁気ディスク１５２との間で読み取りや書き込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭやその他の光媒体等の着脱式不揮発性の光ディスク１５６との間で読み取りや書き込みを行う光ディスクドライブ１５５とを示している。典型的な動作環境において使用できるその他の着脱式／固定式、揮発性／不揮発性コンピュータストレージ媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等があるが、これらには限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０等の固定式のメモリインターフェースを介してシステムバス１２１に接続されており、磁気ディスクドライブ１５１及び光ディスクドライブ１５５は通常、インターフェース１５０等の着脱式のメモリインターフェースによってシステムバス１２１に接続されている。

図１に示されている上述のドライブ及びそれらに関連するコンピュータストレージ媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、及びその他のデータの記憶を提供する。たとえば図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、及びプログラムデータ１４７を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、及びプログラムデータ１３７と同一とするか、又は異なっていてもよいという点に留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、及びプログラムデータ１４７が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、タブレットすなわち電子デジタイザ１６４、マイクロフォン１６３、キーボード１６２、及び通常はマウス、トラックボール、又はタッチパッドと呼ばれるポインティングデバイス１６１等の入力デバイスを介してコンピュータ１１０にコマンド及び情報を入力することができる。図１に示されていないその他の入力デバイスは、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナ等を含むことができる。これら及びその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理装置１２０に接続される場合が多いが、パラレルポート、ゲームポート、又はユニバーサルシリアルバス（ＵＳＢ）等のその他のインターフェース構造及びバス構造によって接続することもできる。またモニタ１９１やその他のタイプのディスプレイデバイスも、ビデオインターフェース１９０等のインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンパネル等と一体化することもできる。モニタ及び／又はタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータにおけるように、コンピューティングデバイス１１０が内蔵されている筐体に物理的に結合することができるという点に留意されたい。さらに、コンピューティングデバイス１１０等のコンピュータは、スピーカ１９５及びプリンタ１９６等のその他の周辺出力デバイスを含むこともでき、これらは周辺出力インターフェース１９４等を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０等の１つ又は複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、又はその他の一般的なネットワークノードとすることができ、図１にはメモリストレージデバイス１８１しか示されていないが、通常はコンピュータ１１０に関連する上述の要素の多く又は全てを含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１及びワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、及びインターネットにおいてよく見受けられる。

ＬＡＮネットワーキング環境において使用する場合、コンピュータ１１０は、ネットワークインターフェース又はアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用する場合、コンピュータ１１０は通常、モデム１７２、又はインターネット等のＷＡＮ１７３上で通信を確立するためのその他の手段を含む。モデム１７２は、内蔵型又は外付け型とすることができ、ユーザ入力インターフェース１６０又はその他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示されているプログラムモジュール、又はその一部をリモートメモリストレージデバイス内に格納することができる。図１は、例としてリモートアプリケーションプログラム１８５をメモリデバイス１８１上に常駐するものとして示しているが、この形態には限定されない。このネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立するその他の手段も使用できることが理解できるであろう。

（シーケンス番号によるデータ通信の調整(coordination)）
本明細書に記載されている技術のさまざまな態様は、ＳＭＢプロトコルの修正バージョン（２．ｘ以降）等のデータ通信プロトコル内で採用できるメカニズムを対象としている。本明細書で一般的に記載されている実装形態の一例では、このメカニズムは、Ｗｉｎｄｏｗｓ（登録商標）ベースのファイル共有用に使用されるこの改訂版のＳＭＢプロトコル内におけるデータ／コマンドの流れを制御する。しかし容易に理解できることだが、本発明は、Ｗｉｎｄｏｗｓ（登録商標）ベースのシステムやＳＭＢプロトコルに限定されるものではなく、むしろこの技術の例は、必ずしもファイルデータを取り扱うとは限らないプロトコル等の他のファイル共有プロトコル及びデータ通信プロトコル全般に適用することができる。たとえばプリンタ、ネームドデータパイプ(named data pipe)、ジェネリックデバイス(generic device)等との通信状態で使用すること等、本発明を実装する多くの方法を実現可能である。そのようなものとして、本発明は、本明細書で使用されている特定のファイルベースの又はその他の例のいずれにも限定されることはなく、むしろコンピューティング全般において利益及び利点を提供する多くの方法で使用することができる。

図２を参照すると、クライアント２０２が１つ又は複数の通信チャネルを介してサーバ２０４と通信するネットワーキング環境の一例を表すブロック図が示されている。クライアント２０２及びサーバ２０４の機能及びコンポーネントは、図１のメインコンピュータシステム１１０及びリモートコンピュータシステム１８０等の２つの別々のコンピュータに配置されるものとして説明する。しかし、これら２つのコンピュータのコンポーネントや、それらによって実行される機能は、１つのマシン上に提供することもでき、複数のコンピュータに分散させることもできる。たとえばコンピュータシステムは、プリントサーバやプリンタ、ならびにＮＡＳストレージデバイス等のさまざまなネットワーク機器デバイスの１つを備えることができる。

アプリケーションプログラム２０６からのネットワークファイルシステムコマンドは、クライアントリダイレクタコンポーネント(client redirector component)２０８によって処理され、クライアントリダイレクタコンポーネント２０８は、相手方の共通ネットワークモジュール（ＳＲＶＮＥＴ）２１０と通信して、ファイルシステム２１２上のコマンドを実行する。一般にクライアント２０２は、コネクションを確立し、次いでサーバ２０４とネゴシエートして、最終的にセッションを開始する。この一環として、ファイルシステムによって指示されたコマンドが処理される前に、クライアントとサーバは、通信プロトコルについて取り決めする。この例では、このコネクション／セッション用に取り決められたプロトコルはＳＭＢ２．０であり、ここではクライアント側のＳＭＢエンジン２２０は、サーバ２０４との通信用にＳＭＢ２．０ドライバを採用する。共通ネットワークモジュール（ＳＲＶＮＥＴ）２１０も同様に、このコネクション上でクライアント通信を処理するＳＭＢ２．０プロバイダ２２６を採用する。プロバイダ２２６は、後述するように、クライアントが適切なシーケンス番号を必ず使用するようにする強制メカニズム及びデータ構造を含むか、或いはそうした強制メカニズム及びデータ構造に関連付けられる。

シーケンス番号によるデータ通信の調整という概念に着目すると、シーケンス番号は、所定のクライアントがサーバに対して発行する作業の量をサーバが抑制(throttle)するメカニズムを提供する。これは、所定のコマンドを識別する際にクライアントが使用できる利用可能なシーケンス番号のウィンドウをサーバに提供させることによって達成される。シーケンス番号及び所望の動作を実施するために、クレジットという概念を採用し、１つのクレジットは、１つのオペレーションをバックアップするのに必要なメモリと、そのオペレーションが消費できるＣＰＵサイクル等の、サーバ側のリソースの一部を消費する権利をクライアントに与える。クライアントは、送信する各コマンドに対して１つのクレジットを消費し、及び、サーバの応答に応じて、ゼロ、１つ又は複数の追加のクレジットを与えられる。クライアントは、シーケンス番号を再使用することはできず、したがってクライアントが発行できるコマンドの数は制御される。便宜上、単調に増加するシーケンス番号を使用するが、（セッション／コネクションごとの）一意の番号は同等である。

たとえばサーバがクライアントに５つのクレジットを与える場合、そのサーバは、最大５つのオペレーションを同時に提起する権利をクライアントに与える。サーバは、クライアントを抑制する必要がある場合、そのクライアントが利用可能なクレジットを減らすことによって、その抑制を行う。サーバは、作業する上でのリソースをより多くクライアントに与えたい場合、クレジットを与えることによって、これを行う。

このことは、サーバに複数のオプションを与える。クライアントにゼロのクレジットを与えることによって、サーバは、そのクライアントに割り当てられるリソースを減らす。あるいは１つのクレジットを返すことによって、サーバは、これまでのウィンドウサイズを維持する。複数のクレジットを返すことによって、サーバは、コマンドを実行するためのリソースをより多くクライアントに割り当てる。１つの制約は、サーバが、そのプロトコルが厳密にコマンドレスポンスプロトコルであると仮定して、帯域外のクレジット(credit out of band)を与える方法を有していない限り、サーバがウィンドウサイズをゼロ（有効なシーケンス番号がない状態）にすることはできないということである。この方法を使用しているプロトコル内でクライアントがクレジットを要求することを必要としなくてもクライアントにクレジットを与える方法がある場合には、この制約は適用されない。

ネゴシエーション要求／応答は、ゼロのシーケンス番号（メッセージＩＤ又はＭＩＤとも呼ばれる）と、１のウィンドウサイズとを有する。ＳＭＢ２．０では、以下のヘッダがこの情報を渡すことを容易にする。

上記のヘッダ構造から分かるように、クライアントは、望むだけのクレジットを要求するが、サーバは、クライアントにクレジットを与えることを管理している。したがってサーバは、クライアントのＩＤ、動作、あるいはその他の任意の属性又は基準に基づいて、ウィンドウを縮小又は拡張することができる。シーケンス番号はまた、所定のコネクション毎にクライアントからサーバへ送信されたコマンドを一意に識別する方法を提供する。

クライアント及びサーバは、コマンドウィンドウを確立することによって開始する。コマンドウィンドウは、デフォルトの又はネゴシエーションされた初期シーケンス番号（ＩＳＮ）（初期メッセージＩＤ又はＭＩＤとも呼ばれる）と、サーバが所定のコマンドを識別するために受け入れる許容可能な番号の範囲を表すクレジット数（ＮｏＣ）とを使用することによって開始する。したがってコマンドウィンドウは、はじめに［ＩＳＮ，ＩＳＮ＋ＮｏＣ−ｌ］を含む。ほとんどのプロトコルにとって、デフォルトはＩＳＮ＝１、ＮｏＣ＝１とすることができ、したがって最初にネゴシエーションした際にコマンドウィンドウが単に［１，１］である場合、サーバがコマンドを識別するために受け入れる唯一のシーケンス番号は１であることを表す。

通信が進むにつれて、クライアントは、範囲内の番号を使い切ることによってウィンドウ内の番号を移動していく。１つの番号は、一度使用すると、再び使用することはできない。これは、サーバによってそのように強制されているためである。また同時にサーバは、より多くのクレジットをクライアントに与えることによって、自分が決めるようにウィンドウの終点を延ばすことができる。たとえばコマンドウィンドウが［Ａ，Ｂ］である場合、クライアントがコマンドＡを送信すると、有効コマンドウィンドウは、基本的に［Ａ＋１，Ｂ］となる。サーバは、コマンドＡに応答する際、ゼロから現実的な数までの任意のクレジットをクライアントに与えることができる。したがってサーバがＮ個のクレジットを返した場合、有効コマンドウィンドウは［Ａ＋１，Ｂ＋Ｎ］となる。

許容可能な範囲内でシーケンス番号を使用する際、順序どおりでなくてもよい。プロトコルは、使用されているシーケンス番号が有効な範囲内にある限り、シーケンス番号の非同期的な使用を容易にするようにセットアップされる。これによってネットワークプロトコルは、順序どおりの送信を強制しようとするのではなく、パケットが利用可能なときにそれらのパケットを送信することができる。したがって非常に大きなパケット用にシーケンス番号Ａが必要とされており、その一方でバッファがＡ＋１の送信用に準備されている間にＡ＋２が入ってきて、そのＡ＋２が非常に小さい場合、（ウィンドウの終点≧Ａ＋２である限り）Ａの送信が開始するのを待たずにＡ＋１とＡ＋２を送信するのが正当である。

［１，５］という有効コマンドウィンドウがあり、パケット２、３、４が送信される場合、サーバは逆にクレジットを与えて、｛２、３、４｝を除く［１，８］のウィンドウ（１から８の間で２から４を除く全ての番号を意味する）を認めることができる。最終的にサーバは、パケット１が送信されて、ウィンドウがスライドできるようになるまで、クレジットを与えるのを停止する可能性が高い。この時点でクライアントが１を送信し、サーバが応答してクレジットを与えると、ウィンドウは［５，９］になる。

有効コマンドウィンドウの強制は、サーバの側で行われる。このシステムによって、クライアント側の構造は、その時点におけるシーケンス番号と最大シーケンス番号を有すること、及びインターロックされた比較とインクリメント(interlocked compares and increments)を唯一必要な同期化の方法として使用することという単純なものにすることができる。

したがって有効コマンドウィンドウ（有効オペレーション又はＶａｌｉｄ Ｏｐウィンドウとも呼ばれる）は、サーバが受け入れる有効なＩＤのウィンドウを含む。クライアントは、次の有効なシーケンス番号を有する後続の各コマンドを（その有効なクレジットまで）送信し、有効ウィンドウのビューを維持する必要はない。クライアントは、（後述する）「最大ウィンドウサイズ」の概念を理解する必要がある。有効コマンド／オペレーションウィンドウを使用する例については、以降で説明する。

変更通知や、ネームドパイプ(named-pipe)の読み取り又は作成（オプロックブレイク(oplock break)上で未決の場合があるため）等、無限の時間にわたってブロックする可能性のある全てのオペレーションは、ブロッキングオペレーションとみなされる。このようなオペレーションを容易にするために、クライアントは、送信コマンド内に「オペレーションコンテキスト」の値、すなわちブロッキングフラグを提供することができる。そしてサーバは、首尾よくオペレーションを開始した時点で応答し、そのオペレーションがまだサーバ側で処理中であっても、シーケンス番号をインクリメントできるようにする。しかし、そのような長期継続オペレーションによって押さえられているリソースは、通常のコマンドに必要なリソースのサブセットである場合が多い。したがってサーバは、クライアントが消費できる「Ｂｌｏｃｋｉｎｇ Ｏｐ Ｃｒｅｄｉｔ」（ロングオペレーションクレジット又はＬＯＣとも呼ばれる）の最大数を決定することができる。シーケンス番号はまた、いくつのリソースをクライアントが消費できるかを制御することによって、長期継続コマンドと、サーバからの複数の応答を伴うコマンドとのバランスをとることができるようにする。

したがって有効コマンドウィンドウに対する１つの拡張は、そのウィンドウが引き続き通常どおりスライドできるようにし、無限の時間を要する可能性のあるオペレーションによって停滞しないようにすることである。この目的から、クライアントは、サーバによって所定の数のＢｌｏｃｋｉｎｇ Ｏｐクレジットを与えられ、Ｂｌｏｃｋｉｎｇ Ｏｐフラグを伴って発行されるオペレーションは全て、１つのＢｌｏｃｋｉｎｇ Ｏｐクレジットを消費する。サーバは、コマンドを受信すると、長期継続コマンドを受信したことを知らせるフラグセットと共に中間応答をクライアントに返信することができ、非同期ＩＤ（ＡｓｙｎｃＩＤ）とも呼ばれる長期継続コマンドＩＤを返す。この応答によって、有効コマンドウィンドウは、通常どおりスライドすることができる。長期継続コマンドが完了すると、新たな応答が、どのパケットに応答しているかを示すための長期継続コマンドＩＤを使用してクライアントに返信される。この送信−応答−応答のアーキテクチャによって、ウィンドウは移動を続けることができ、クレジットメカニズムによって、サーバは、いくつのリソースをクライアントが消費できるかに関する制御を保持することができる。サーバは、クライアントから多数の長期継続オペレーションが進行中である場合、有効コマンドウィンドウを縮小することさえできる。

代替実装形態は、長期継続コマンドが来る可能性があることをクライアントがサーバに示唆できるようにするプロトコルを含む。非同期的な概念の別の実装形態は、仮の(interim)「アクセプト」等をクライアントに発行させることもでき、これによって非同期／ブロッキングオペレーションは、単なる送信−応答−応答とは対照的に「送信−応答−送信−応答」の形態をとる。基礎をなすいくつかの移送（たとえばＴＣＰ）は、要求−応答のトラフィック用に調整されている場合が多く、これによって、要求−応答−応答の状況では遅延が生じることがある。

プロトコル及び移送の非同期的な性質のために、その時点の有効ウィンドウは、その時点の最小のシーケンスＩＤにクレジットを加えたものに直接等しくはならない。これは、いくつかの中間のコマンドが先に受信される場合があり、すなわち、たとえばシーケンスＩＤ＝１のコマンドを処理するのに長い時間を要する場合があるためである。しかしサーバは、この有効ウィンドウが拡張をやめる前にどこまで拡張できるかに関して制限を課すことができる。前述の例について続けると、サーバは、最大ウィンドウサイズを１０に指定することができる。つまりサーバが、パケット１を受信するか又はその処理を完了する前に、パケット２、３、４、５、及び６を受信して処理する場合、有効オペレーション（コマンド）ウィンドウは［１，１０］へと拡張する。したがって有効となるシーケンス番号は、１、７、８、９、１０である。しかし、次いでサーバがパケット７を受信して処理する場合、有効オペレーション（コマンド）ウィンドウは、［１，１１］へスライドせず、許容可能なシーケンス番号が１、８、９、１０の状態で［１，１０］にとどまる。コマンドＢに関する応答は、−１のクレジットを示して、クライアントがその許容可能な限度の終点に達していること、すなわちそのクレジットの値が現在４であることをそのクライアントに告げる。これは、クライアントがシーケンス内の所定の番号をスキップするのをサーバが妨げる１つの方法であり、これによって、ウィンドウは良好にスライドできなくなる。これはまた、長い時間を要するコマンド用にサーバに対して「Ｂｌｏｃｋｉｎｇ Ｏｐ」を発行する値を示す。

有効コマンドウィンドウをサーバ側でトラッキングすることは、交わるセットをサーバが追跡する必要があるため、計算の面で高くつく場合がある。これを簡略化するために、実装形態の一例では、前述の最大ウィンドウサイズを、サーバがコマンドウィンドウに対して認める最大のサイズとして確立する。これが確立されると、サーバは、このサイズを表すバッファを割り当て、コマンドが入ってくると、バッファ内のその場所の値が変更される。ウィンドウサイズが最大ウィンドウサイズ以下である限り、ウィンドウの始点が前に移動すると、サーバは、そのバッファポインタを前に移動させる。同様に、クレジットが与えられるにつれて終点が拡張すると、サーバは、その終点ポインタをバッファに沿って移動させる。計算は、バッファが最大ウィンドウサイズを「ラップ」(wraps)する状況を処理する。より大きなバッファを割り当て、現在の値をそこへコピーすることによって、最大ウィンドウサイズを動的に拡張することができる。ＡＶＡＩＬＡＢＬＥとして開始するインターロックしたオペレーションを使用して、ウィンドウ内の有効なコマンドのステータスを追跡する。クライアントからコマンドを受信すると、それらのインターロックしたオペレーションはＩＮ＿ＰＲＯＧＲＥＳＳへ移行し、応答（又は長期継続コマンドの場合の仮応答(interim response)）が送信されると、それはＵＳＥＤへ移行する。ＵＳＥＤへ移行する値がウィンドウ内の最初の値である場合、ウィンドウは、ＵＳＥＤではない値に出会うまで前にスライドされる。

別の代替実装形態では、サーバは、代わりのチャネル又は順序付けられていない通信(unsequenced communication)を介してクレジットを取り消すことができる。たとえばサーバがクライアントに１０のクレジットを与えたが、そのクライアントのクレジットを５に削りたいとすると、この状態は通常、クライアントが５つのコマンドを使用しない限り生じない。クライアントが休止状態にある場合、サーバは、次のＮ秒でクライアントは５つのクレジットを使用しなければならず、さもないと違反になり、終了させられる（又はクレジットを失う）ことになる旨をクライアントに示す。これによってサーバは、クライアントが自分自身のウィンドウを移動することに依存せずにクライアントを抑制することができる。

さまざまな例を使用した本発明のオペレーションの説明に移り、その時点の状態を次のフォーマットで説明する。

Ｍｉｎ列は、クライアントが使用できる最も低い未使用のクライアントシーケンス番号を示し、Ｃｕｒｒｅｎｔ Ｃｒｅｄｉｔｓは、いくつのクレジットがクライアントに与えられているかを（通常のクレジット、Ｂｌｏｃｋｉｎｇ Ｏｐクレジット）の形式で示している。クライアントは、送信に際してクレジットを１つ消費し、場合によっては（応答に応じて）受信に際して再びインクリメントを行う。単に「Ｃｒｅｄｉｔｓ」と書かれている次の列は、その時点でクライアントに認められるクレジットの最大数を示している。

Ｖａｌｉｄ及びＭａｘは、シーケンスＩＤを認証するためのサーバ側の構造を示している（クライアントは、これらに関してまったく関知する必要がない）。Ｖａｌｉｄは、Ｖａｌｉｄ Ｏｐ Ｗｉｎｄｏｗと、既に使用された（たとえばビットマップによって追跡されている）シーケンスＩＤの例外とを示しており、Ｍａｘは、クライアントが最初のオペレーションを完了する前に挿入できるＭａｘＣｏｍｍａｎｄＷｉｎｄｏｗ、すなわちウィンドウのシフトをもたらすことになるオペレーションを示している。

図３〜９は、有効オペレーション（Ｖａｌｉｄ Ｏｐ）ウィンドウ３３０_sがサーバ２０４において保持されている際にどのように拡張するかについての一例を表している（図３〜９においては、たとえば図３は、３３０_sというラベルの有効オペレーションウィンドウを有し、図４は、４３０_sというラベルの有効オペレーションウィンドウを有するといった具合に、有効オペレーションウィンドウが変わると、そのラベルの最初の数字が変わる）。

図３において、クライアントは、５つのクレジットと、先頭のシーケンス番号（すなわちＭＩＤ）として１を与えられている。割り当てコンポーネント３２２は、一般的に前述したいくつかの基準３２０、たとえばクライアントの種類を使用して、クライアントに与える量を決定する。したがってこの例では、その時点の有効オペレーションウィンドウは［１，５］であり、図３ではウィンドウ３３０_s内の個々の数字によって縦に表されている。したがってサーバ２０４は、シーケンス番号１、２、３、４、又は５を有するパケットをこのクライアント２０２から受け入れる。あるいはこれは、前述した次のようなフォーマットでも表される。

パケットを自明に拒否するために、Ｖａｌｉｄ Ｏｐウィンドウ３２０_sを使用する。それらのパケットがＶａｌｉｄ Ｏｐウィンドウ３２０_s内に存在する場合、サーバ２０４は、内部の例外マップをチェックし、シーケンス番号が既に使用されていないことを保証する。

通常の単調に増加する受信の場合、クライアントは、ＭＩＤ＝１のパケットを送信し、クライアント及びサーバは、図４及び下記のテーブルに示されている状態に移行する（［１，５］が有効とみなされるが、１は、サーバからの応答に対してのみ真に有効であり、クライアントからの別の受信に対しては有効ではなく、Ｍｉｎ＝２のチェックを先に行うと失敗することになる）。

図４においてサーバは、シーケンス番号＝１のコマンドを受信し、処理する。つまり１は、もはや後続のコマンドに対して有効なシーケンス番号ではなく、このことは、上記のテーブル内におけるＶａｌｉｄ／ｅｘｃｅｐｔ列内の括弧でくくられた｛１｝によって示され、また図４における４３０_sというラベルの有効オペレーションウィンドウ内に示されている。

図５及び下記のテーブルに示されているように、サーバは、応答する際にその応答上で＋１の追加クレジットをクライアントに与え、ウィンドウをスライドさせる。

すると、クライアントが有する有効ウィンドウは［２，６］となる。たとえば移送上で非同期的な送信があり、これによってサーバがコマンド２の前に（及びそれに応答する前に）コマンド３を受信した場合等、順序から外れた受信が発生したとする。すると、図６及び以降に示されているように、Ｖａｌｉｄ Ｏｐウィンドウ６３０_sが、概念上は存在することになる。

このテーブルでは、有効ウィンドウは拡張するが、最大ウィンドウはスライドしない。しかしサーバがコマンド２を受信して応答すると、ウィンドウ７３０_sは、図７及び下記の双方におけるようにスライドする。

次に、悪意あるクライアントが、コマンドを送信して応答を拒否することによってサーバ上のリソースを使い果たすことをもくろんでいるとする。ここではクライアントは、コマンド４及び５をサーバへ送信し、応答を拒否している。状態は、図８及び以降に示されているようになる。

６、７、８のシーケンスＩＤを有するコマンドが送信されると、クレジットの強制のために、図９及び下記のテーブルに示されているように、クライアントはクレジットがなくなり、全てのパケットが拒否される。

最大ウィンドウの強制の例に移り、図１０〜１３及び同様のテーブルを使用する。悪意あるクライアントが、パケットＮを送信せずにＮ＋１以降のパケットを送信しようと試みているとする。図１０〜１３の例は、最後の攻撃者の前の状態で開始する。すなわち図１０は、本質的に図７である。

クライアントはコマンド５、６、７、８、９、１０を送信し、サーバは応答するが、コマンド４は送信されない。この状態は、図１１及び下記のテーブルに示されている。

コマンドウィンドウ内には実行可能なスロットが依然として５つ存在するため、クライアントは依然として５つのクレジットを有しているという点に留意されたい。しかしクライアントがコマンド１１を送信し、サーバがこれに応答した場合、図１２及び下記のテーブルに示されている状態が生じる。

そしてクライアントは、１２、１３、１４について継続する。ＭａｘＷｉｎｄｏｗ内には利用可能なスロットがないため、クライアントが利用できるクレジット数は、各コマンドに対して１つ減少している。これは、コマンド１２、１３、１４についても継続する。

図１３に示されているように、サーバがクライアントから受け入れるコマンドは、コマンド４のみとなる。

容易に理解できることだが、シーケンス番号のウィンドウの属性は、複数の望ましいシナリオにおいて非常に有利である。これらのシナリオのいくつかは、サービス妨害を防止すること、サービスの質を可能にすること、所定のコネクションを介して実行されたコマンドをクライアントとサーバが参照するための共通の言語を提供すること、長期継続コマンドと、サーバからの複数の応答を伴うコマンドとを可能にし、その一方で、いくつのリソースをクライアントが消費できるかを制御することによってそのバランスをとること、及びセキュリティ署名を継続的に使用できるようにすることを含む。

サービス妨害を防止することに関しては、サーバは、自分が所定のクライアントを認証し、そのクライアントが正しく動作するまで、そのクライアントコネクションが消費できるリソースの量を制限することができる。たとえばクライアントに割り当てられるリソースをサーバが制御できるようにすることによって、サーバは、攻撃の疑いが検出された場合、「パニックモード」に入ることができ、そのクライアントにとって利用可能なリソースを最小限まで削り、それらのリソースを信頼に基づいた上で戻す。サーバは、作業が発生できるのに十分な小さいウィンドウを各クライアントに与え、その一方でいずれかの単一のクライアントがリソースの全てを本質的に占領することのないようにする。攻撃が終了するか、又は緩和されると、サーバは、信頼できることが証明されたクライアントに対して再びリソースを与えることを開始することができる。

サービスの質を可能にすることに関しては、変動可能なウィンドウのスキームによって、サーバは、クライアントに割り当てられるリソースの量をクライアントのＩＤ及び／又は動作に基づいて増減させることができる。たとえばサーバは、ファイルサーバにコネクションしているウェブサーバに対しては、個々のドキュメントにアクセスしている単独のユーザに対するよりも多くのリソースを割り当てることができる。別の例としては、別のサーバが、ファイルサーバにアクセスしているデータベースサーバである場合、そのファイルサーバは、与えられるクレジット数を、平均的なユーザに与えられるクレジット数よりも高く加重することができる。

さらに、サービスの質を制御する際、クライアントへのリソースの割り当てをクライアントのさまざまなニーズに基づいて動的に変更することができる。これによってサーバは、完全に公平な方法でクレジットを与えるか、あるいはその他の情報を考慮に入れることができる。管理者は、リソースの優先順位に基づいてマシンを構成することができ、これは、ユーザがコネクションを行い、そしてコネクションを切断するのに応じて動的に利用及び変更することができる。

シーケンス番号はまた、所定のコネクションを介して実行されたコマンドをクライアントとサーバが参照するための共通の言語を提供する。これは、永続的な処理を含むさまざまな機能を構築する際に役立つ。たとえば、コマンドが送信及び受信される際にそれらのコマンドを識別するための共通の言語、すなわちシーケンス番号メカニズムについてクライアントとサーバの双方が合意しているため、コネクションの切断が生じた場合、どのコマンドが受信され、どのコマンドが受信されなかったかをコネクションが回復した段階でサーバとクライアントが判断するための簡単な方法が存在する。このようなセットスキームがなければ、追跡することはさらに困難になり、コマンドＩＤがクライアントによって選択され、かつ再利用されている可能性がある場合は、特に困難になる。

シーケンス番号はさらに、現在のモデルの極端なパフォーマンスの問題を伴わずにセキュリティ署名を継続的に使用できるようにし、送信は順序どおりでなくてもよい（ただし全パケットのチェックサムは、依然として計算することが必要となるであろうし、パケット全体は、発行前に受信することが必要となるであろう）。パケットの署名に関しては、再生可能性は存在しえない。より詳細には、署名を行うネットワークプロトコルは、署名されたパケットの再生可能性を阻むためにインデックス番号をパケットに組み込む必要があり、さもないと、攻撃者は単にそのパケットを再発行し、そのパケットを断念する必要がなくなり、そのパケットは有効なままとなる。他の方法はタイムスタンプ等を含むが、これらは、クライアントとサーバの間で何らかの形態の同期を必要とする。インデックス番号を使用する場合、クライアントは、パケット２を送信する前にサーバがパケット１を必ず受信しているようにする必要があるため、クライアントとサーバの間のネットワークトラフィックは、往々にして順番に並べられたものになる。

コマンドＩＤとして組み込まれたシーケンス番号と、サーバ上でサポートされる有効ウィンドウによって、内部にシーケンス番号を伴う平行したコマンド送信が必然的に発生する。サーバが有効ウィンドウを強制するため、各コマンドは一度しか発行することができず、このことによって、署名に使用されるキーが、認証される各コネクションに対して一意であることがプロトコルによって保証される限り、再生可能性は問題にならない。コマンドＩＤが繰り返される場合は、再生可能性が問題となるおそれがあり、したがってこれを防止するために、約３２ビット又は６４ビットのシーケンス番号が望ましく、切断されたコネクションの回復が可能な場合は、おそらく６４ビットがより望ましいという。

本発明は、さまざまな修正及び代替構成を受け入れることができるが、その特定の例示的な実施形態について図示し、詳細に前述した。しかし開示された特定の形態に本発明を限定する意図はなく、むしろ本発明の趣旨及び範囲内に収まる全ての変更、代替構成、及び均等物を含むことを意図していることが理解できるはずである。

本発明のさまざまな態様を組み込むことができる汎用コンピューティング環境の１つの具体例を示す図である。 本発明のさまざまな態様に従ってクライアントがサーバと通信するネットワーク環境の一例を示すブロック図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。 本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。

Claims (20)

1. クライアントとサーバを有するネットワーク・コンピューティング環境において、
   前記サーバが、少なくとも1つのシーケンス番号からなる有効コマンドウィンドウを設けること、
   前記サーバが、サーバリソースを消費するコマンドであって、対応シーケンス番号を１つ含むコマンドを受信すること、
   前記サーバが、前記対応シーケンス番号が前記有効コマンドウィンドウの範囲内であるかを判定すること、
   前記サーバが、前記対応シーケンス番号が前に別のコマンドに含まれていたことがないかを判定すること、
   前記サーバが、前記対応シーケンス番号が前記有効コマンドウィンドウの範囲内であり、かつ、前に別のコマンドに含まれていたことがないと判定した場合、前記コマンドを許可すること
   を含むことを特徴とする方法。
2. 前記サーバが、前記対応シーケンス番号が最大シーケンス番号を超えないと判定した場合、前記コマンドを許可することを更に含むことを特徴とする請求項１記載の方法。
3. 前記サーバが、前記クライアントにクレジットを与えること、
   前記サーバが、未使用シーケンス番号を含むように前記有効コマンドウィンドウを調整すること
   を更に含むことを特徴とする請求項１記載の方法。
4. 前記サーバが、前記コマンドを受信すると、前記クライアントに追加のクレジットを与えること、
   前記サーバが、第２の未使用シーケンス番号を含むように前記有効コマンドウィンドウを調整すること
   を更に含むことを特徴とする請求項３記載の方法。
5. 前記サーバが前記コマンドを許可することは、前記クライアントに与えられたクレジットの一つが消費されることであることを特徴とする請求項３記載の方法。
6. 前記サーバが、前記クライアントに１つ又は複数のブロッキング・オペレーション・クレジットを与えること、
   前記サーバが、ブロッキング・オペレーション・クレジットの最大数を超えないブロッキングコマンドを前記クライアントから受信すると、ブロッキングオペレーションを実行すること
   を更に含むことを特徴とする請求項１記載の方法。
7. 前記サーバが、前記ブロッキングオペレーションの進展を示すデータを戻すこと、
   前記サーバが、前記ブロッキングオペレーションの識別子を戻すこと
   を更に含むことを特徴とする請求項６記載の方法。
8. 前記サーバが、前記クライアントに追加のクレジットを与えること、
   前記サーバが、前記ブロッキングコマンドを受信すると前記有効コマンドウィンドウを調整すること
   を更に含むことを特徴とする請求項７記載の方法。
9. 前記サーバが、前記クライアントから受け取った追加のクレジットを求めるリクエストを処理することを更に含むことを特徴とする請求項３記載の方法。
10. 前記サーバが、前記クライアントに既に与えられたクレジットのうちの少なくとも１つのクレジットを取り消すことを更に含むことを特徴とする請求項３記載の方法。
11. コンピュータに、
    サーバが、少なくとも１つのシーケンス番号からなる有効コマンドウィンドウを設けるステップと、
    前記サーバが、サーバリソースを消費するコマンドであって対応シーケンス番号を含むコマンドを受信するステップと、
    前記サーバが、前記対応シーケンス番号が前記有効コマンドウィンドウの範囲内であるかを判定するステップと、
    前記サーバが、前記対応シーケンス番号が前に別のコマンドに含まれていたことがないかを判定するステップと、
    前記サーバが、前記対応シーケンス番号が前記有効コマンドウィンドウの範囲内であり、かつ、別のコマンドに含まれていたことがないと判定した場合には、前記コマンドを許可し、それ以外の場合には、前記コマンドを拒否するステップと
    を実行させるためのコンピュータ実行可能命令を記録したコンピュータ読み取り可能な少なくとも１つの記録媒体。
12. 前記サーバが、前記クライアントにクレジットを与えるステップと、
    前記サーバが、未使用シーケンス番号を含むように前記有効コマンドウィンドウを調整するステップを
    実行させるためのコンピュータ実行可能命令を更に含むことを特徴とする請求項１１に記載のコンピュータ読み取り可能な記録媒体。
13. 前記サーバが前記クライアントにクレジットを与えるステップは、前記クライアントに既に与えられたクレジットを取り消さないと判定した場合に実行されることを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
14. 前記サーバが前記クライアントにクレジットを与えるステップは、前記有効コマンドウィンドウ内の前記シーケンス番号が最大ウィンドウサイズを超えない場合に実行されることを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
15. 前記サーバが、前記クライアントに既に与えられたクレジットのうちの少なくとも１つのクレジットを取り消すステップを実行させるためのコンピュータ実行可能命令を更に含むことを特徴とする請求項１２記載のコンピュータ読み取り可能な記録媒体。
16. 前記サーバが、前記クライアントに１つ又は複数のブロッキング・オペレーション・クレジットを与えるステップと、
    前記サーバが、ブロッキング・オペレーション・クレジットの最大数を超えないブロッキングコマンドを前記クライアントから受信すると、ブロッキングオペレーションを実行するステップとを
    実行させるためのコンピュータ実行可能命令を更に含むことを特徴とする請求項１１記載のコンピュータ読み取り可能な記録媒体。
17. クライアントとサーバを有するネットワーク・コンピューティング環境におけるサーバサイドシステムにおいて、
    前記クライアントに与えられるクレジットの数を制御することによってサーバリソースの使用を制限するサーバメカニズムであって、前記クレジットはサーバリソースを消費するコマンドを許可してもらう権利を前記クライアントに与える、サーバメカニズムを備え、
    前記サーバメカニズムは、
    前記クライアントに与えられる各クレジットに１つずつ対応する一意の番号を複数含む有効コマンドウィンドウと、
    前記コマンドに含まれる一意の番号が、前記有効コマンドウィンドウの範囲内であり、かつ、別のコマンドに含まれていたことがない場合に、前記コマンドによるサーバリソースの消費を前記クライアントに許可する強制メカニズムと、
    前記クライアントに与えられるクレジットと、前記有効コマンドウィンドウの範囲内の前記一意の番号とを制御する割り当てメカニズムと
    を備えることを特徴とするサーバサイドシステム。
18. サーバリソースの使用を制限する前記サーバメカニズムは、サーバメッセージブロックプロトコルドライバを含むことを特徴とする請求項１７記載のサーバサイドシステム。
19. サーバリソースの使用を制限する前記サーバメカニズムは、前記クライアントに既に与えられたクレジットのうちの少なくとも１つのクレジットを取り消す手段を含むことを特徴とする請求項１７記載のサーバサイドシステム。
20. 前記割り当てメカニズムは、前記クライアントから受信したコマンドがサーバリソースを使用することを前記強制メカニズムが許可するのに対応して、前記クライアントに追加のクレジットを与えることを特徴とする請求項１７記載のサーバサイドシステム。

Images