(57)【要約】【課題】クライアントによるサーバリソースの使用を制御するためのクライアントとサーバの通信用のシーケンス番号を提供する。【解決手段】サーバは、クライアントにクレジットを与え、クライアントは、各コマンドをサーバへ送信するためにクレジットを消費する。各クレジットは、１つのシーケンス番号に対応し、シーケンス番号のセットによって有効コマンドウィンドウを形成する。サーバは、受信した各コマンドに対して、そのコマンドが有効コマンドウィンドウ内にある１つのシーケンス番号を含み、そのシーケンス番号が別のコマンドに使用されていない状態を強制する。サーバは、最大ウィンドウサイズを保持することもでき、これによって、クレジットを有するクライアントでさえ、最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信することはできなくなる。【選択図】図３
2006333434.tif 000002
【特許請求の範囲】
【請求項１】
クライアント及びサーバを有するネットワークコンピューティング環境において、
前記クライアントに少なくとも１つのクレジットを与えることであって、各クレジットは、前記クライアントが前記サーバへコマンドを送信するために使用できるシーケンス番号に対応し、１つ又は複数のシーケンス番号のセットは有効コマンドウィンドウを形成することと、
受信される各コマンドに、前記コマンドが、前記有効コマンドウィンドウ内にあるシーケンス番号を含むこと、及び前記シーケンス番号が別のコマンドに使用されていないことを強制することを含むことを特徴とする方法。
【請求項２】
最大ウィンドウサイズを保持し、これによって、クレジットを有するクライアントは、前記最大ウィンドウサイズに対応する最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信できなくなることをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
コマンドを受信したことに応答して、前記ウィンドウを調整する未使用のシーケンス番号を前記クライアントに返すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記未使用のシーケンス番号は、前記有効コマンドウィンドウ内の最後の番号から単調に増加した値であることを特徴とする請求項３に記載の方法。
【請求項５】
各シーケンス番号は、３２ビット長以上の固定されたサイズの値であることを特徴とする請求項１に記載の方法。
【請求項６】
少なくとも１つのブロッキングオペレーションクレジットを前記クライアントに与えることと、前記クライアントが、使用されるブロッキングオペレーションクレジットの最大数を超えないことを前記サーバにおいて強制することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
ブロッキングオペレーションクレジットに対応するコマンドを受信することと、前記ブロッキングオペレーションが進行中であることを示すデータを、前記ブロッキングオペレーションの完了時に返されることになるそのオペレーション用のＩＤと共に返すこととをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記ブロッキングオペレーションコマンドを受信したことに応答して前記ウィンドウを調整する未使用のシーケンス番号を前記クライアントに返すことをさらに含むことを特徴とする請求項７に記載の方法。
【請求項９】
追加のクレジットを求める要求を前記クライアントから受信することと、前記要求を拒否して、前記クライアントにとって利用可能なクレジットの数を減らすことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１１】
取り消される前に使用しなければ、少なくとも１つのクレジットが取り消されることになる旨を前記クライアントに知らせることをさらに含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
実行されると、
クライアントに複数のクレジットを与えることであって、各クレジットは、前記クライアントがサーバへコマンドを送信するために使用するシーケンス番号に対応し、前記シーケンス番号は有効コマンドウィンドウを形成することと、
前記クライアントからコマンドを受信した際に、
前記シーケンス番号が前記ウィンドウ内にあり、以前に使用されていないことを確認することと、
前記対応するシーケンス番号を、前記クライアントが使用できるシーケンス番号の中から削除し、クレジットを１つ消費することと、
前記クライアントに少なくとも１つの他のクレジットを与えるかどうかを決定することを実行するコンピュータ実行可能命令を有することを特徴とする少なくとも１つのコンピュータ可読媒体。
【請求項１３】
前記サーバは、前記クライアントに少なくとも１つの他のクレジットを与えることを決定し、与えられる各クレジットに基づく対応するシーケンス番号によって前記有効コマンドウィンドウを調整することを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記サーバは、前記クライアントに別のクレジットを与えないことを決定し、それによって、前記クライアントにとって利用可能な前記クレジットを動的に減らすことを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記サーバは、最大ウィンドウサイズを評価することによって、前記クライアントに別のクレジットを与えないことを決定することを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１６】
予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すことを含むさらなるコンピュータ実行可能命令を有することを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１７】
取り消される前に使用しなければ、少なくとも１つのクレジットが取り消されることになる旨を前記クライアントに知らせることを含むさらなるコンピュータ実行可能命令を有することを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
クライアント及びサーバを有するネットワークコンピューティング環境において、
前記クライアントに与えられるクレジットの数を制御することによってサーバリソースの使用を制限するためのメカニズムを含むサーバ側のシステムであって、前記メカニズムは、
前記クライアントに与えられる各クレジットを表す一意の番号を含む有効オペレーションウィンドウと、
受信したコマンドに関してさらなるサーバオペレーションを認めるために、前記コマンドが、前記有効オペレーションウィンドウ内にある１つのシーケンス番号を含み、前記一意の番号が別のコマンドに使用されていないことを保証する強制メカニズムと、
前記クライアントに与えられるクレジット及び前記有効オペレーションウィンドウ内の前記一意の番号を制御する割り当てメカニズムを含むことを特徴とするシステム。
【請求項１９】
サーバリソースの使用を制限するための前記メカニズムは、サーバメッセージブロックプロトコルドライバに関連付けられていることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記メカニズムは、予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すための手段を含むことを特徴とする請求項１８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントとサーバの通信用に、データ通信プロトコルに組み込む等したシーケンス番号を使用して、クライアントによるサーバリソースの使用を制御することに関する。
【背景技術】
【０００２】
今日でも依然として使用されているＳＭＢ（Ｓｅｒｖｅｒ  Ｍｅｓｓａｇｅ  Ｂｌｏｃｋ）プロトコル等の多くのデータ通信プロトコルは、たとえばネットワークの帯域幅が一般的に限られており、メモリが非常に貴重であったこと等、コンピューティングリソースが大きく異なっていた時代に開発されたものである。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
現代のネットワークにおいてこのようなプロトコルを使用すると、全体的なパフォーマンスが制限されることがある。たとえば、メモリが限られていた時代に設計されたため、小さなバッファサイズが使用されており、大量のデータを通信するにはより多くの往復が必要となる。
【０００４】
さらに、既存のＳＭＢプロトコルには他の制限もあり、それらも時間の経過と共に明らかになってきている。たとえば既存のＳＭＢプロトコルは、サービス妨害の攻撃の影響を受けやすく、このプロトコルの設計によって、これらの攻撃に対抗することが困難になっている。同様に、パケットのセキュリティを確保する方法も煩雑である。また、現時点でサービスライクのオペレーションの質を達成するためのメカニズムもなく、たとえば信頼できるクライアントは、信頼できないクライアントと同じサーバリソースを得る。つまりＳＭＢの既存のバージョンは、依然として頻繁に使用され有用なプロトコルではあるが、現代のネットワークリソースと共に使用する上で理想的なものとは言えない。
【課題を解決するための手段】
【０００５】
本発明の様々な態様は、クライアントとサーバの通信用に、データ通信プロトコルに組み込む等したシーケンス番号を使用して、クライアントによるサーバリソースの使用を制御することに関する。様々な態様は、順序付けを重要としていないプロトコルにシーケンス番号の使用を導入し、サービスの質、サービス妨害への対抗、サーバリソースの分割、安全なメッセージへの署名、及びその他の多くの利点を提供する。
【０００６】
サーバは、クライアントにクレジット(credit)を与え、クライアントは、各コマンドをサーバへ送信するためにクレジットを使用する。各クレジットは、シーケンス番号に対応し、シーケンス番号の組み合わせによって、有効コマンドウィンドウが形成される。サーバは、受信した各コマンドに対して、そのコマンドが、有効コマンドウィンドウ内にある１つのシーケンス番号を含み、そのシーケンス番号が別のコマンドに使用されていない状態を強制(enforce)する。サーバは、最大ウィンドウサイズを保持し、これによって、クレジットを有するクライアントであっても、最大ウィンドウサイズに対応する最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信することはできない。
【０００７】
一般にサーバは、クライアントからコマンドを受信すると、そのシーケンス番号がウィンドウ内にあり、以前に使用されていないことを確認する。次いでサーバは、対応するシーケンス番号を、クライアントが使用できるシーケンス番号の中から削除し、これによってクレジットを１つ消費する。そしてサーバは、クライアントに１つ又は複数の他のクレジットを与えるかどうかを決定する。
【０００８】
したがって、クライアントに与えられる各クレジットを表す一意の番号を含む有効オペレーションウィンドウを介して、クライアントに与えられるクレジットの数を制御することによって、サーバリソースの使用を制限するメカニズムを提供する。強制メカニズム(enforcement mechanism)は、受信したコマンドに関してさらなるサーバオペレーションを認めるために、そのコマンドが、有効オペレーションウィンドウ内にある１つのシーケンス番号を含み、その一意の番号が別のコマンドに使用されていないことを保証する。割り当てメカニズム(allocation mechanism)は、クライアントに与えられるクレジット及び有効オペレーションウィンドウ内の一意の番号を制御する。
【０００９】
その他の利点は、以降の詳細な説明を図面と併せて理解すれば、明らかになるであろう。
【００１０】
本発明は、添付の図においては限定ではなく例として示されており、同様の参照番号は、類似した要素を指している。
【発明を実施するための最良の形態】
【００１１】
（例示的な動作環境）
図１は、本発明を実装できる適切なコンピューティングシステム環境１００の一例を示している。このコンピューティングシステム環境１００は、適切なコンピューティング環境の一例にすぎず、本発明の使用又は機能の範囲に対して何らかの限定を提示することを意図するものではない。またコンピューティング環境１００が、この例示的な動作環境１００内に示されているコンポーネントの任意の１つ又は組合せに関して何らかの依存性又は必要性を有すると解釈すべきでもない。
【００１２】
本発明は、他の多くの汎用又は専用のコンピューティングシステム環境又は構成と共に使用することができる。本発明と共に使用するのに適する可能性のあるよく知られたコンピューティングシステム、環境、及び／又は構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイス又はラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステム又はデバイスのいずれかを含む分散コンピューティング環境等を含むが、これらには限定されない。
【００１３】
本発明については、コンピュータによって実行される、プログラムモジュール等のコンピュータ実行可能命令という一般的なコンテキストにおいて説明することができる。一般にプログラムモジュールは、特定のタスクを実行したり特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。本発明は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、メモリストレージデバイスを含むローカルコンピュータストレージ媒体及び／又はリモートコンピュータストレージ媒体に配置することができる。
【００１４】
図１を参照すると、本発明を実装するための例示的なシステムは、汎用コンピューティングデバイスをコンピュータ１１０の形態で含む。コンピュータ１１０のコンポーネントは、処理装置１２０と、システムメモリ１３０と、システムメモリを含むさまざまなシステムコンポーネントを処理装置１２０に結合するシステムバス１２１とを含むことができるが、これらには限定されない。システムバス１２１は、メモリバス又はメモリコントローラと、ペリフェラルバスと、さまざまなバスアーキテクチャのいずれかを使用するローカルバスとを含む複数のタイプのバス構造のいずれにすることもできる。たとえばこのようなアーキテクチャは、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、及びメザニンバスとしても知られているＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含むが、これらには限定されない。
【００１５】
コンピュータ１１０は通常、さまざまなコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０によってアクセスできる利用可能な任意の媒体とすることができ、揮発性媒体及び不揮発性媒体、ならびに着脱式媒体及び固定式媒体の双方を含む。たとえばコンピュータ可読媒体は、コンピュータストレージ媒体及び通信媒体を含むことができるが、これらには限定されない。コンピュータストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータ等の情報を記憶するための任意の方法又は技術において実装される揮発性媒体及び不揮発性媒体、ならびに着脱式媒体及び固定式媒体を含む。コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又はその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、又はその他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、又はその他の磁気ストレージデバイス、あるいは希望の情報を保存するために使用可能で、コンピュータ１１０によってアクセス可能なその他の任意の媒体を含むが、これらには限定されない。通信媒体は通常、搬送波やその他の伝送メカニズム等の変調されたデータ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、又はその他のデータを具体化し、任意の情報伝達媒体を含む。「変調されたデータ信号」という用語は、情報をその信号内でコード化するような方法で設定又は変更されたその特性のうちの１つ又は複数を有する信号を意味する。たとえば通信媒体は、有線ネットワークや直接有線接続等の有線媒体と、音波媒体、ＲＦ媒体、赤外線媒体、その他の無線媒体等の無線媒体とを含むが、これらには限定されない。また上記のいずれの組合せも、コンピュータ可読媒体の範囲内に含まれるものである。
【００１６】
システムメモリ１３０は、コンピュータストレージ媒体を、読み取り専用メモリ（ＲＯＭ）１３１及びランダムアクセスメモリ（ＲＡＭ）１３２等の揮発性メモリ及び／又は不揮発性メモリの形態で含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中等にコンピュータ１１０内の要素間における情報伝達を補助する基本ルーチンを含み、通常はＲＯＭ１３１内に格納されている。ＲＡＭ１３２は通常、処理装置１２０がすぐにアクセスできるか、かつ／又は処理装置１２０によってその時点で操作されているデータモジュール及び／又はプログラムモジュールを含む。図１は、例としてオペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、及びプログラムデータ１３７を示しているが、これらには限定されない。
【００１７】
またコンピュータ１１０は、その他の着脱式／固定式、揮発性／不揮発性コンピュータストレージ媒体を含むこともできる。図１は、例示のみを目的として、固定式の不揮発性の磁気媒体との間で読み取りや書き込みを行うハードディスクドライブ１４１と、着脱式の不揮発性の磁気ディスク１５２との間で読み取りや書き込みを行う磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭやその他の光媒体等の着脱式不揮発性の光ディスク１５６との間で読み取りや書き込みを行う光ディスクドライブ１５５とを示している。典型的な動作環境において使用できるその他の着脱式／固定式、揮発性／不揮発性コンピュータストレージ媒体としては、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ等があるが、これらには限定されない。ハードディスクドライブ１４１は通常、インターフェース１４０等の固定式のメモリインターフェースを介してシステムバス１２１に接続されており、磁気ディスクドライブ１５１及び光ディスクドライブ１５５は通常、インターフェース１５０等の着脱式のメモリインターフェースによってシステムバス１２１に接続されている。
【００１８】
図１に示されている上述のドライブ及びそれらに関連するコンピュータストレージ媒体は、コンピュータ１１０用のコンピュータ可読命令、データ構造、プログラムモジュール、及びその他のデータの記憶を提供する。たとえば図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、及びプログラムデータ１４７を記憶するものとして示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、及びプログラムデータ１３７と同一とするか、又は異なっていてもよいという点に留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、及びプログラムデータ１４７が最低限異なるコピーであることを示すために、異なる番号を割り当てている。ユーザは、タブレットすなわち電子デジタイザ１６４、マイクロフォン１６３、キーボード１６２、及び通常はマウス、トラックボール、又はタッチパッドと呼ばれるポインティングデバイス１６１等の入力デバイスを介してコンピュータ１１０にコマンド及び情報を入力することができる。図１に示されていないその他の入力デバイスは、ジョイスティック、ゲームパッド、衛星放送受信用アンテナ、スキャナ等を含むことができる。これら及びその他の入力デバイスは、システムバスに結合されているユーザ入力インターフェース１６０を介して処理装置１２０に接続される場合が多いが、パラレルポート、ゲームポート、又はユニバーサルシリアルバス（ＵＳＢ）等のその他のインターフェース構造及びバス構造によって接続することもできる。またモニタ１９１やその他のタイプのディスプレイデバイスも、ビデオインターフェース１９０等のインターフェースを介してシステムバス１２１に接続される。モニタ１９１は、タッチスクリーンパネル等と一体化することもできる。モニタ及び／又はタッチスクリーンパネルは、タブレットタイプのパーソナルコンピュータにおけるように、コンピューティングデバイス１１０が内蔵されている筐体に物理的に結合することができるという点に留意されたい。さらに、コンピューティングデバイス１１０等のコンピュータは、スピーカ１９５及びプリンタ１９６等のその他の周辺出力デバイスを含むこともでき、これらは周辺出力インターフェース１９４等を介して接続することができる。
【００１９】
コンピュータ１１０は、リモートコンピュータ１８０等の１つ又は複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境内で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、又はその他の一般的なネットワークノードとすることができ、図１にはメモリストレージデバイス１８１しか示されていないが、通常はコンピュータ１１０に関連する上述の要素の多く又は全てを含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１及びワイドエリアネットワーク（ＷＡＮ）１７３を含むが、その他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、及びインターネットにおいてよく見受けられる。
【００２０】
ＬＡＮネットワーキング環境において使用する場合、コンピュータ１１０は、ネットワークインターフェース又はアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用する場合、コンピュータ１１０は通常、モデム１７２、又はインターネット等のＷＡＮ１７３上で通信を確立するためのその他の手段を含む。モデム１７２は、内蔵型又は外付け型とすることができ、ユーザ入力インターフェース１６０又はその他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関連して示されているプログラムモジュール、又はその一部をリモートメモリストレージデバイス内に格納することができる。図１は、例としてリモートアプリケーションプログラム１８５をメモリデバイス１８１上に常駐するものとして示しているが、この形態には限定されない。このネットワーク接続は例示的なものであり、コンピュータ間に通信リンクを確立するその他の手段も使用できることが理解できるであろう。
【００２１】
（シーケンス番号によるデータ通信の調整(coordination)）
本明細書に記載されている技術のさまざまな態様は、ＳＭＢプロトコルの修正バージョン（２．ｘ以降）等のデータ通信プロトコル内で採用できるメカニズムを対象としている。本明細書で一般的に記載されている実装形態の一例では、このメカニズムは、Ｗｉｎｄｏｗｓ（登録商標）ベースのファイル共有用に使用されるこの改訂版のＳＭＢプロトコル内におけるデータ／コマンドの流れを制御する。しかし容易に理解できることだが、本発明は、Ｗｉｎｄｏｗｓ（登録商標）ベースのシステムやＳＭＢプロトコルに限定されるものではなく、むしろこの技術の例は、必ずしもファイルデータを取り扱うとは限らないプロトコル等の他のファイル共有プロトコル及びデータ通信プロトコル全般に適用することができる。たとえばプリンタ、ネームドデータパイプ(named data pipe)、ジェネリックデバイス(generic device)等との通信状態で使用すること等、本発明を実装する多くの方法を実現可能である。そのようなものとして、本発明は、本明細書で使用されている特定のファイルベースの又はその他の例のいずれにも限定されることはなく、むしろコンピューティング全般において利益及び利点を提供する多くの方法で使用することができる。
【００２２】
図２を参照すると、クライアント２０２が１つ又は複数の通信チャネルを介してサーバ２０４と通信するネットワーキング環境の一例を表すブロック図が示されている。クライアント２０２及びサーバ２０４の機能及びコンポーネントは、図１のメインコンピュータシステム１１０及びリモートコンピュータシステム１８０等の２つの別々のコンピュータに配置されるものとして説明する。しかし、これら２つのコンピュータのコンポーネントや、それらによって実行される機能は、１つのマシン上に提供することもでき、複数のコンピュータに分散させることもできる。たとえばコンピュータシステムは、プリントサーバやプリンタ、ならびにＮＡＳストレージデバイス等のさまざまなネットワーク機器デバイスの１つを備えることができる。
【００２３】
アプリケーションプログラム２０６からのネットワークファイルシステムコマンドは、クライアントリダイレクタコンポーネント(client redirector component)２０８によって処理され、クライアントリダイレクタコンポーネント２０８は、相手方の共通ネットワークモジュール（ＳＲＶＮＥＴ）２１０と通信して、ファイルシステム２１２上のコマンドを実行する。一般にクライアント２０２は、コネクションを確立し、次いでサーバ２０４とネゴシエートして、最終的にセッションを開始する。この一環として、ファイルシステムによって指示されたコマンドが処理される前に、クライアントとサーバは、通信プロトコルについて取り決めする。この例では、このコネクション／セッション用に取り決められたプロトコルはＳＭＢ２．０であり、ここではクライアント側のＳＭＢエンジン２２０は、サーバ２０４との通信用にＳＭＢ２．０ドライバを採用する。共通ネットワークモジュール（ＳＲＶＮＥＴ）２１０も同様に、このコネクション上でクライアント通信を処理するＳＭＢ２．０プロバイダ２２６を採用する。プロバイダ２２６は、後述するように、クライアントが適切なシーケンス番号を必ず使用するようにする強制メカニズム及びデータ構造を含むか、或いはそうした強制メカニズム及びデータ構造に関連付けられる。
【００２４】
シーケンス番号によるデータ通信の調整という概念に着目すると、シーケンス番号は、所定のクライアントがサーバに対して発行する作業の量をサーバが抑制(throttle)するメカニズムを提供する。これは、所定のコマンドを識別する際にクライアントが使用できる利用可能なシーケンス番号のウィンドウをサーバに提供させることによって達成される。シーケンス番号及び所望の動作を実施するために、クレジットという概念を採用し、１つのクレジットは、１つのオペレーションをバックアップするのに必要なメモリと、そのオペレーションが消費できるＣＰＵサイクル等の、サーバ側のリソースの一部を消費する権利をクライアントに与える。クライアントは、送信する各コマンドに対して１つのクレジットを消費し、及び、サーバの応答に応じて、ゼロ、１つ又は複数の追加のクレジットを与えられる。クライアントは、シーケンス番号を再使用することはできず、したがってクライアントが発行できるコマンドの数は制御される。便宜上、単調に増加するシーケンス番号を使用するが、（セッション／コネクションごとの）一意の番号は同等である。
【００２５】
たとえばサーバがクライアントに５つのクレジットを与える場合、そのサーバは、最大５つのオペレーションを同時に提起する権利をクライアントに与える。サーバは、クライアントを抑制する必要がある場合、そのクライアントが利用可能なクレジットを減らすことによって、その抑制を行う。サーバは、作業する上でのリソースをより多くクライアントに与えたい場合、クレジットを与えることによって、これを行う。
【００２６】
このことは、サーバに複数のオプションを与える。クライアントにゼロのクレジットを与えることによって、サーバは、そのクライアントに割り当てられるリソースを減らす。あるいは１つのクレジットを返すことによって、サーバは、これまでのウィンドウサイズを維持する。複数のクレジットを返すことによって、サーバは、コマンドを実行するためのリソースをより多くクライアントに割り当てる。１つの制約は、サーバが、そのプロトコルが厳密にコマンドレスポンスプロトコルであると仮定して、帯域外のクレジット(credit out of band)を与える方法を有していない限り、サーバがウィンドウサイズをゼロ（有効なシーケンス番号がない状態）にすることはできないということである。この方法を使用しているプロトコル内でクライアントがクレジットを要求することを必要としなくてもクライアントにクレジットを与える方法がある場合には、この制約は適用されない。
【００２７】
ネゴシエーション要求／応答は、ゼロのシーケンス番号（メッセージＩＤ又はＭＩＤとも呼ばれる）と、１のウィンドウサイズとを有する。ＳＭＢ２．０では、以下のヘッダがこの情報を渡すことを容易にする。
【００２８】
【表１】
2006333434.tif 000003
【００２９】
上記のヘッダ構造から分かるように、クライアントは、望むだけのクレジットを要求するが、サーバは、クライアントにクレジットを与えることを管理している。したがってサーバは、クライアントのＩＤ、動作、あるいはその他の任意の属性又は基準に基づいて、ウィンドウを縮小又は拡張することができる。シーケンス番号はまた、所定のコネクション毎にクライアントからサーバへ送信されたコマンドを一意に識別する方法を提供する。
【００３０】
クライアント及びサーバは、コマンドウィンドウを確立することによって開始する。コマンドウィンドウは、デフォルトの又はネゴシエーションされた初期シーケンス番号（ＩＳＮ）（初期メッセージＩＤ又はＭＩＤとも呼ばれる）と、サーバが所定のコマンドを識別するために受け入れる許容可能な番号の範囲を表すクレジット数（ＮｏＣ）とを使用することによって開始する。したがってコマンドウィンドウは、はじめに［ＩＳＮ，ＩＳＮ＋ＮｏＣ−ｌ］を含む。ほとんどのプロトコルにとって、デフォルトはＩＳＮ＝１、ＮｏＣ＝１とすることができ、したがって最初にネゴシエーションした際にコマンドウィンドウが単に［１，１］である場合、サーバがコマンドを識別するために受け入れる唯一のシーケンス番号は１であることを表す。
【００３１】
通信が進むにつれて、クライアントは、範囲内の番号を使い切ることによってウィンドウ内の番号を移動していく。１つの番号は、一度使用すると、再び使用することはできない。これは、サーバによってそのように強制されているためである。また同時にサーバは、より多くのクレジットをクライアントに与えることによって、自分が決めるようにウィンドウの終点を延ばすことができる。たとえばコマンドウィンドウが［Ａ，Ｂ］である場合、クライアントがコマンドＡを送信すると、有効コマンドウィンドウは、基本的に［Ａ＋１，Ｂ］となる。サーバは、コマンドＡに応答する際、ゼロから現実的な数までの任意のクレジットをクライアントに与えることができる。したがってサーバがＮ個のクレジットを返した場合、有効コマンドウィンドウは［Ａ＋１，Ｂ＋Ｎ］となる。
【００３２】
許容可能な範囲内でシーケンス番号を使用する際、順序どおりでなくてもよい。プロトコルは、使用されているシーケンス番号が有効な範囲内にある限り、シーケンス番号の非同期的な使用を容易にするようにセットアップされる。これによってネットワークプロトコルは、順序どおりの送信を強制しようとするのではなく、パケットが利用可能なときにそれらのパケットを送信することができる。したがって非常に大きなパケット用にシーケンス番号Ａが必要とされており、その一方でバッファがＡ＋１の送信用に準備されている間にＡ＋２が入ってきて、そのＡ＋２が非常に小さい場合、（ウィンドウの終点≧Ａ＋２である限り）Ａの送信が開始するのを待たずにＡ＋１とＡ＋２を送信するのが正当である。
【００３３】
［１，５］という有効コマンドウィンドウがあり、パケット２、３、４が送信される場合、サーバは逆にクレジットを与えて、｛２、３、４｝を除く［１，８］のウィンドウ（１から８の間で２から４を除く全ての番号を意味する）を認めることができる。最終的にサーバは、パケット１が送信されて、ウィンドウがスライドできるようになるまで、クレジットを与えるのを停止する可能性が高い。この時点でクライアントが１を送信し、サーバが応答してクレジットを与えると、ウィンドウは［５，９］になる。
【００３４】
有効コマンドウィンドウの強制は、サーバの側で行われる。このシステムによって、クライアント側の構造は、その時点におけるシーケンス番号と最大シーケンス番号を有すること、及びインターロックされた比較とインクリメント(interlocked compares and increments)を唯一必要な同期化の方法として使用することという単純なものにすることができる。
【００３５】
したがって有効コマンドウィンドウ（有効オペレーション又はＶａｌｉｄ  Ｏｐウィンドウとも呼ばれる）は、サーバが受け入れる有効なＩＤのウィンドウを含む。クライアントは、次の有効なシーケンス番号を有する後続の各コマンドを（その有効なクレジットまで）送信し、有効ウィンドウのビューを維持する必要はない。クライアントは、（後述する）「最大ウィンドウサイズ」の概念を理解する必要がある。有効コマンド／オペレーションウィンドウを使用する例については、以降で説明する。
【００３６】
変更通知や、ネームドパイプ(named-pipe)の読み取り又は作成（オプロックブレイク(oplock break)上で未決の場合があるため）等、無限の時間にわたってブロックする可能性のある全てのオペレーションは、ブロッキングオペレーションとみなされる。このようなオペレーションを容易にするために、クライアントは、送信コマンド内に「オペレーションコンテキスト」の値、すなわちブロッキングフラグを提供することができる。そしてサーバは、首尾よくオペレーションを開始した時点で応答し、そのオペレーションがまだサーバ側で処理中であっても、シーケンス番号をインクリメントできるようにする。しかし、そのような長期継続オペレーションによって押さえられているリソースは、通常のコマンドに必要なリソースのサブセットである場合が多い。したがってサーバは、クライアントが消費できる「Ｂｌｏｃｋｉｎｇ  Ｏｐ  Ｃｒｅｄｉｔ」（ロングオペレーションクレジット又はＬＯＣとも呼ばれる）の最大数を決定することができる。シーケンス番号はまた、いくつのリソースをクライアントが消費できるかを制御することによって、長期継続コマンドと、サーバからの複数の応答を伴うコマンドとのバランスをとることができるようにする。
【００３７】
したがって有効コマンドウィンドウに対する１つの拡張は、そのウィンドウが引き続き通常どおりスライドできるようにし、無限の時間を要する可能性のあるオペレーションによって停滞しないようにすることである。この目的から、クライアントは、サーバによって所定の数のＢｌｏｃｋｉｎｇ  Ｏｐクレジットを与えられ、Ｂｌｏｃｋｉｎｇ  Ｏｐフラグを伴って発行されるオペレーションは全て、１つのＢｌｏｃｋｉｎｇ  Ｏｐクレジットを消費する。サーバは、コマンドを受信すると、長期継続コマンドを受信したことを知らせるフラグセットと共に中間応答をクライアントに返信することができ、非同期ＩＤ（ＡｓｙｎｃＩＤ）とも呼ばれる長期継続コマンドＩＤを返す。この応答によって、有効コマンドウィンドウは、通常どおりスライドすることができる。長期継続コマンドが完了すると、新たな応答が、どのパケットに応答しているかを示すための長期継続コマンドＩＤを使用してクライアントに返信される。この送信−応答−応答のアーキテクチャによって、ウィンドウは移動を続けることができ、クレジットメカニズムによって、サーバは、いくつのリソースをクライアントが消費できるかに関する制御を保持することができる。サーバは、クライアントから多数の長期継続オペレーションが進行中である場合、有効コマンドウィンドウを縮小することさえできる。
【００３８】
代替実装形態は、長期継続コマンドが来る可能性があることをクライアントがサーバに示唆できるようにするプロトコルを含む。非同期的な概念の別の実装形態は、仮の(interim)「アクセプト」等をクライアントに発行させることもでき、これによって非同期／ブロッキングオペレーションは、単なる送信−応答−応答とは対照的に「送信−応答−送信−応答」の形態をとる。基礎をなすいくつかの移送（たとえばＴＣＰ）は、要求−応答のトラフィック用に調整されている場合が多く、これによって、要求−応答−応答の状況では遅延が生じることがある。
【００３９】
プロトコル及び移送の非同期的な性質のために、その時点の有効ウィンドウは、その時点の最小のシーケンスＩＤにクレジットを加えたものに直接等しくはならない。これは、いくつかの中間のコマンドが先に受信される場合があり、すなわち、たとえばシーケンスＩＤ＝１のコマンドを処理するのに長い時間を要する場合があるためである。しかしサーバは、この有効ウィンドウが拡張をやめる前にどこまで拡張できるかに関して制限を課すことができる。前述の例について続けると、サーバは、最大ウィンドウサイズを１０に指定することができる。つまりサーバが、パケット１を受信するか又はその処理を完了する前に、パケット２、３、４、５、及び６を受信して処理する場合、有効オペレーション（コマンド）ウィンドウは［１，１０］へと拡張する。したがって有効となるシーケンス番号は、１、７、８、９、１０である。しかし、次いでサーバがパケット７を受信して処理する場合、有効オペレーション（コマンド）ウィンドウは、［１，１１］へスライドせず、許容可能なシーケンス番号が１、８、９、１０の状態で［１，１０］にとどまる。コマンドＢに関する応答は、−１のクレジットを示して、クライアントがその許容可能な限度の終点に達していること、すなわちそのクレジットの値が現在４であることをそのクライアントに告げる。これは、クライアントがシーケンス内の所定の番号をスキップするのをサーバが妨げる１つの方法であり、これによって、ウィンドウは良好にスライドできなくなる。これはまた、長い時間を要するコマンド用にサーバに対して「Ｂｌｏｃｋｉｎｇ  Ｏｐ」を発行する値を示す。
【００４０】
有効コマンドウィンドウをサーバ側でトラッキングすることは、交わるセットをサーバが追跡する必要があるため、計算の面で高くつく場合がある。これを簡略化するために、実装形態の一例では、前述の最大ウィンドウサイズを、サーバがコマンドウィンドウに対して認める最大のサイズとして確立する。これが確立されると、サーバは、このサイズを表すバッファを割り当て、コマンドが入ってくると、バッファ内のその場所の値が変更される。ウィンドウサイズが最大ウィンドウサイズ以下である限り、ウィンドウの始点が前に移動すると、サーバは、そのバッファポインタを前に移動させる。同様に、クレジットが与えられるにつれて終点が拡張すると、サーバは、その終点ポインタをバッファに沿って移動させる。計算は、バッファが最大ウィンドウサイズを「ラップ」(wraps)する状況を処理する。より大きなバッファを割り当て、現在の値をそこへコピーすることによって、最大ウィンドウサイズを動的に拡張することができる。ＡＶＡＩＬＡＢＬＥとして開始するインターロックしたオペレーションを使用して、ウィンドウ内の有効なコマンドのステータスを追跡する。クライアントからコマンドを受信すると、それらのインターロックしたオペレーションはＩＮ＿ＰＲＯＧＲＥＳＳへ移行し、応答（又は長期継続コマンドの場合の仮応答(interim response)）が送信されると、それはＵＳＥＤへ移行する。ＵＳＥＤへ移行する値がウィンドウ内の最初の値である場合、ウィンドウは、ＵＳＥＤではない値に出会うまで前にスライドされる。
【００４１】
別の代替実装形態では、サーバは、代わりのチャネル又は順序付けられていない通信(unsequenced communication)を介してクレジットを取り消すことができる。たとえばサーバがクライアントに１０のクレジットを与えたが、そのクライアントのクレジットを５に削りたいとすると、この状態は通常、クライアントが５つのコマンドを使用しない限り生じない。クライアントが休止状態にある場合、サーバは、次のＮ秒でクライアントは５つのクレジットを使用しなければならず、さもないと違反になり、終了させられる（又はクレジットを失う）ことになる旨をクライアントに示す。これによってサーバは、クライアントが自分自身のウィンドウを移動することに依存せずにクライアントを抑制することができる。
【００４２】
さまざまな例を使用した本発明のオペレーションの説明に移り、その時点の状態を次のフォーマットで説明する。
【００４３】
【表２】
2006333434.tif 000004
【００４４】
Ｍｉｎ列は、クライアントが使用できる最も低い未使用のクライアントシーケンス番号を示し、Ｃｕｒｒｅｎｔ  Ｃｒｅｄｉｔｓは、いくつのクレジットがクライアントに与えられているかを（通常のクレジット、Ｂｌｏｃｋｉｎｇ  Ｏｐクレジット）の形式で示している。クライアントは、送信に際してクレジットを１つ消費し、場合によっては（応答に応じて）受信に際して再びインクリメントを行う。単に「Ｃｒｅｄｉｔｓ」と書かれている次の列は、その時点でクライアントに認められるクレジットの最大数を示している。
【００４５】
Ｖａｌｉｄ及びＭａｘは、シーケンスＩＤを認証するためのサーバ側の構造を示している（クライアントは、これらに関してまったく関知する必要がない）。Ｖａｌｉｄは、Ｖａｌｉｄ  Ｏｐ  Ｗｉｎｄｏｗと、既に使用された（たとえばビットマップによって追跡されている）シーケンスＩＤの例外とを示しており、Ｍａｘは、クライアントが最初のオペレーションを完了する前に挿入できるＭａｘＣｏｍｍａｎｄＷｉｎｄｏｗ、すなわちウィンドウのシフトをもたらすことになるオペレーションを示している。
【００４６】
図３〜９は、有効オペレーション（Ｖａｌｉｄ  Ｏｐ）ウィンドウ３３０sがサーバ２０４において保持されている際にどのように拡張するかについての一例を表している（図３〜９においては、たとえば図３は、３３０sというラベルの有効オペレーションウィンドウを有し、図４は、４３０sというラベルの有効オペレーションウィンドウを有するといった具合に、有効オペレーションウィンドウが変わると、そのラベルの最初の数字が変わる）。
【００４７】
図３において、クライアントは、５つのクレジットと、先頭のシーケンス番号（すなわちＭＩＤ）として１を与えられている。割り当てコンポーネント３２２は、一般的に前述したいくつかの基準３２０、たとえばクライアントの種類を使用して、クライアントに与える量を決定する。したがってこの例では、その時点の有効オペレーションウィンドウは［１，５］であり、図３ではウィンドウ３３０s内の個々の数字によって縦に表されている。したがってサーバ２０４は、シーケンス番号１、２、３、４、又は５を有するパケットをこのクライアント２０２から受け入れる。あるいはこれは、前述した次のようなフォーマットでも表される。
【００４８】
【表３】
2006333434.tif 000005
【００４９】
パケットを自明に拒否するために、Ｖａｌｉｄ  Ｏｐウィンドウ３２０sを使用する。それらのパケットがＶａｌｉｄ  Ｏｐウィンドウ３２０s内に存在する場合、サーバ２０４は、内部の例外マップをチェックし、シーケンス番号が既に使用されていないことを保証する。
【００５０】
通常の単調に増加する受信の場合、クライアントは、ＭＩＤ＝１のパケットを送信し、クライアント及びサーバは、図４及び下記のテーブルに示されている状態に移行する（［１，５］が有効とみなされるが、１は、サーバからの応答に対してのみ真に有効であり、クライアントからの別の受信に対しては有効ではなく、Ｍｉｎ＝２のチェックを先に行うと失敗することになる）。
【００５１】
【表４】
2006333434.tif 000006
【００５２】
図４においてサーバは、シーケンス番号＝１のコマンドを受信し、処理する。つまり１は、もはや後続のコマンドに対して有効なシーケンス番号ではなく、このことは、上記のテーブル内におけるＶａｌｉｄ／ｅｘｃｅｐｔ列内の括弧でくくられた｛１｝によって示され、また図４における４３０sというラベルの有効オペレーションウィンドウ内に示されている。
【００５３】
図５及び下記のテーブルに示されているように、サーバは、応答する際にその応答上で＋１の追加クレジットをクライアントに与え、ウィンドウをスライドさせる。
【００５４】
【表５】
2006333434.tif 000007
【００５５】
すると、クライアントが有する有効ウィンドウは［２，６］となる。たとえば移送上で非同期的な送信があり、これによってサーバがコマンド２の前に（及びそれに応答する前に）コマンド３を受信した場合等、順序から外れた受信が発生したとする。すると、図６及び以降に示されているように、Ｖａｌｉｄ  Ｏｐウィンドウ６３０sが、概念上は存在することになる。
【００５６】
【表６】
2006333434.tif 000008
【００５７】
このテーブルでは、有効ウィンドウは拡張するが、最大ウィンドウはスライドしない。しかしサーバがコマンド２を受信して応答すると、ウィンドウ７３０sは、図７及び下記の双方におけるようにスライドする。
【００５８】
【表７】
2006333434.tif 000009
【００５９】
次に、悪意あるクライアントが、コマンドを送信して応答を拒否することによってサーバ上のリソースを使い果たすことをもくろんでいるとする。ここではクライアントは、コマンド４及び５をサーバへ送信し、応答を拒否している。状態は、図８及び以降に示されているようになる。
【００６０】
【表８】
2006333434.tif 000010
【００６１】
６、７、８のシーケンスＩＤを有するコマンドが送信されると、クレジットの強制のために、図９及び下記のテーブルに示されているように、クライアントはクレジットがなくなり、全てのパケットが拒否される。
【００６２】
【表９】
2006333434.tif 000011
【００６３】
最大ウィンドウの強制の例に移り、図１０〜１３及び同様のテーブルを使用する。悪意あるクライアントが、パケットＮを送信せずにＮ＋１以降のパケットを送信しようと試みているとする。図１０〜１３の例は、最後の攻撃者の前の状態で開始する。すなわち図１０は、本質的に図７である。
【００６４】
【表１０】
2006333434.tif 000012
【００６５】
クライアントはコマンド５、６、７、８、９、１０を送信し、サーバは応答するが、コマンド４は送信されない。この状態は、図１１及び下記のテーブルに示されている。
【００６６】
【表１１】
2006333434.tif 000013
【００６７】
コマンドウィンドウ内には実行可能なスロットが依然として５つ存在するため、クライアントは依然として５つのクレジットを有しているという点に留意されたい。しかしクライアントがコマンド１１を送信し、サーバがこれに応答した場合、図１２及び下記のテーブルに示されている状態が生じる。
【００６８】
【表１２】
2006333434.tif 000014
【００６９】
そしてクライアントは、１２、１３、１４について継続する。ＭａｘＷｉｎｄｏｗ内には利用可能なスロットがないため、クライアントが利用できるクレジット数は、各コマンドに対して１つ減少している。これは、コマンド１２、１３、１４についても継続する。
【００７０】
【表１３】
2006333434.tif 000015
【００７１】
図１３に示されているように、サーバがクライアントから受け入れるコマンドは、コマンド４のみとなる。
【００７２】
容易に理解できることだが、シーケンス番号のウィンドウの属性は、複数の望ましいシナリオにおいて非常に有利である。これらのシナリオのいくつかは、サービス妨害を防止すること、サービスの質を可能にすること、所定のコネクションを介して実行されたコマンドをクライアントとサーバが参照するための共通の言語を提供すること、長期継続コマンドと、サーバからの複数の応答を伴うコマンドとを可能にし、その一方で、いくつのリソースをクライアントが消費できるかを制御することによってそのバランスをとること、及びセキュリティ署名を継続的に使用できるようにすることを含む。
【００７３】
サービス妨害を防止することに関しては、サーバは、自分が所定のクライアントを認証し、そのクライアントが正しく動作するまで、そのクライアントコネクションが消費できるリソースの量を制限することができる。たとえばクライアントに割り当てられるリソースをサーバが制御できるようにすることによって、サーバは、攻撃の疑いが検出された場合、「パニックモード」に入ることができ、そのクライアントにとって利用可能なリソースを最小限まで削り、それらのリソースを信頼に基づいた上で戻す。サーバは、作業が発生できるのに十分な小さいウィンドウを各クライアントに与え、その一方でいずれかの単一のクライアントがリソースの全てを本質的に占領することのないようにする。攻撃が終了するか、又は緩和されると、サーバは、信頼できることが証明されたクライアントに対して再びリソースを与えることを開始することができる。
【００７４】
サービスの質を可能にすることに関しては、変動可能なウィンドウのスキームによって、サーバは、クライアントに割り当てられるリソースの量をクライアントのＩＤ及び／又は動作に基づいて増減させることができる。たとえばサーバは、ファイルサーバにコネクションしているウェブサーバに対しては、個々のドキュメントにアクセスしている単独のユーザに対するよりも多くのリソースを割り当てることができる。別の例としては、別のサーバが、ファイルサーバにアクセスしているデータベースサーバである場合、そのファイルサーバは、与えられるクレジット数を、平均的なユーザに与えられるクレジット数よりも高く加重することができる。
【００７５】
さらに、サービスの質を制御する際、クライアントへのリソースの割り当てをクライアントのさまざまなニーズに基づいて動的に変更することができる。これによってサーバは、完全に公平な方法でクレジットを与えるか、あるいはその他の情報を考慮に入れることができる。管理者は、リソースの優先順位に基づいてマシンを構成することができ、これは、ユーザがコネクションを行い、そしてコネクションを切断するのに応じて動的に利用及び変更することができる。
【００７６】
シーケンス番号はまた、所定のコネクションを介して実行されたコマンドをクライアントとサーバが参照するための共通の言語を提供する。これは、永続的な処理を含むさまざまな機能を構築する際に役立つ。たとえば、コマンドが送信及び受信される際にそれらのコマンドを識別するための共通の言語、すなわちシーケンス番号メカニズムについてクライアントとサーバの双方が合意しているため、コネクションの切断が生じた場合、どのコマンドが受信され、どのコマンドが受信されなかったかをコネクションが回復した段階でサーバとクライアントが判断するための簡単な方法が存在する。このようなセットスキームがなければ、追跡することはさらに困難になり、コマンドＩＤがクライアントによって選択され、かつ再利用されている可能性がある場合は、特に困難になる。
【００７７】
シーケンス番号はさらに、現在のモデルの極端なパフォーマンスの問題を伴わずにセキュリティ署名を継続的に使用できるようにし、送信は順序どおりでなくてもよい（ただし全パケットのチェックサムは、依然として計算することが必要となるであろうし、パケット全体は、発行前に受信することが必要となるであろう）。パケットの署名に関しては、再生可能性は存在しえない。より詳細には、署名を行うネットワークプロトコルは、署名されたパケットの再生可能性を阻むためにインデックス番号をパケットに組み込む必要があり、さもないと、攻撃者は単にそのパケットを再発行し、そのパケットを断念する必要がなくなり、そのパケットは有効なままとなる。他の方法はタイムスタンプ等を含むが、これらは、クライアントとサーバの間で何らかの形態の同期を必要とする。インデックス番号を使用する場合、クライアントは、パケット２を送信する前にサーバがパケット１を必ず受信しているようにする必要があるため、クライアントとサーバの間のネットワークトラフィックは、往々にして順番に並べられたものになる。
【００７８】
コマンドＩＤとして組み込まれたシーケンス番号と、サーバ上でサポートされる有効ウィンドウによって、内部にシーケンス番号を伴う平行したコマンド送信が必然的に発生する。サーバが有効ウィンドウを強制するため、各コマンドは一度しか発行することができず、このことによって、署名に使用されるキーが、認証される各コネクションに対して一意であることがプロトコルによって保証される限り、再生可能性は問題にならない。コマンドＩＤが繰り返される場合は、再生可能性が問題となるおそれがあり、したがってこれを防止するために、約３２ビット又は６４ビットのシーケンス番号が望ましく、切断されたコネクションの回復が可能な場合は、おそらく６４ビットがより望ましいという。
【００７９】
本発明は、さまざまな修正及び代替構成を受け入れることができるが、その特定の例示的な実施形態について図示し、詳細に前述した。しかし開示された特定の形態に本発明を限定する意図はなく、むしろ本発明の趣旨及び範囲内に収まる全ての変更、代替構成、及び均等物を含むことを意図していることが理解できるはずである。
【図面の簡単な説明】
【００８０】
【図１】本発明のさまざまな態様を組み込むことができる汎用コンピューティング環境の１つの具体例を示す図である。
【図２】本発明のさまざまな態様に従ってクライアントがサーバと通信するネットワーク環境の一例を示すブロック図である。
【図３】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図４】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図５】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図６】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図７】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図８】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図９】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図１０】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図１１】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図１２】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図１３】本発明のさまざまな態様による、シーケンス番号を使用するために保持されているクライアント及びサーバのデータを示す図である。
【図１】
2006333434.tif 000016
【図２】
2006333434.tif 000017
【図３】
2006333434.tif 000018
【図４】
2006333434.tif 000019
【図５】
2006333434.tif 000020
【図６】
2006333434.tif 000021
【図７】
2006333434.tif 000022
【図８】
2006333434.tif 000023
【図９】
2006333434.tif 000024
【図１０】
2006333434.tif 000025
【図１１】
2006333434.tif 000026
【図１２】
2006333434.tif 000027
【図１３】
2006333434.tif 000028
【手続補正書】
【提出日】平成18年9月8日(2006.9.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアント及びサーバを有するネットワークコンピューティング環境において、
１つ又は複数のサーバオペレーションを提起する権利を前記クライアントに付与するための少なくとも１つのクレジットを、前記クライアントに与えることであって、各クレジットは、前記クライアントが前記サーバにサーバリソースの使用を要求するためのコマンドを送信するために使用できるシーケンス番号に対応し、１つ又は複数のシーケンス番号のセットは有効コマンドウィンドウを形成することと、
受信される各コマンドに、前記コマンドが、前記有効コマンドウィンドウ内にあるシーケンス番号を含むこと、及び前記シーケンス番号が別のコマンドに使用されていないことを強制することと、
最大ウィンドウサイズを保持し、これによって、クレジットを有するクライアントは、前記最大ウィンドウサイズに対応する最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信できなくなることを含むことを特徴とする方法。
【請求項２】
コマンドを受信したことに応答して、前記ウィンドウを調整する未使用のシーケンス番号を前記クライアントに返すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記未使用のシーケンス番号は、前記有効コマンドウィンドウ内の最後の番号から単調に増加した値であることを特徴とする請求項２に記載の方法。
【請求項４】
各シーケンス番号は、３２ビット長以上の固定されたサイズの値であることを特徴とする請求項１に記載の方法。
【請求項５】
少なくとも１つのブロッキングオペレーションを提起する権利を前記クライアントに付与するための少なくとも１つのブロッキングオペレーションクレジットを、前記クライアントに与えることと、前記クライアントが、使用されるブロッキングオペレーションクレジットの最大数を超えないことを前記サーバにおいて強制することをさらに含むことを特徴とする請求項１に記載の方法。
【請求項６】
ブロッキングオペレーションクレジットに対応するコマンドを受信することと、前記ブロッキングオペレーションが進行中であることを示すデータを、前記ブロッキングオペレーションの完了時に返されることになるそのオペレーション用のＩＤと共に返すこととをさらに含むことを特徴とする請求項５に記載の方法。
【請求項７】
前記ブロッキングオペレーションコマンドを受信したことに応答して前記ウィンドウを調整する未使用のシーケンス番号を前記クライアントに返すことをさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
追加のクレジットを求める要求を前記クライアントから受信することと、前記要求を拒否して、前記クライアントにとって利用可能なクレジットの数を減らすことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項９】
予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すことをさらに含むことを特徴とする請求項１に記載の方法。
【請求項１０】
取り消される前に使用しなければ、少なくとも１つのクレジットが取り消されることになる旨を前記クライアントに知らせることをさらに含むことを特徴とする請求項９に記載の方法。
【請求項１１】
実行されると、
１つ又は複数のサーバオペレーションを提起する権利をクライアントに付与するための複数のクレジットを、前記クライアントに与えることであって、各クレジットは、前記クライアントが前記サーバにサーバリソースの使用を要求するためのコマンドを送信するために使用するシーケンス番号に対応し、前記シーケンス番号は有効コマンドウィンドウを形成することと、
前記クライアントからコマンドを受信した際に、
前記シーケンス番号が前記ウィンドウ内にあり、以前に使用されていないことを確認することと、
前記対応するシーケンス番号を、前記クライアントが使用できるシーケンス番号の中から削除し、クレジットを１つ消費することと、
前記クライアントに少なくとも１つの他のクレジットを与えるかどうかを決定することと、
最大ウィンドウサイズを評価することによって、前記クライアントに別のクレジットを与えないことを決定することを実行するコンピュータ実行可能命令を有することを特徴とする少なくとも１つのコンピュータ可読媒体。
【請求項１２】
前記サーバは、前記クライアントに少なくとも１つの他のクレジットを与えることを決定し、与えられる各クレジットに基づく対応するシーケンス番号によって前記有効コマンドウィンドウを調整することを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記サーバは、前記クライアントに別のクレジットを与えないことを決定し、それによって、前記クライアントにとって利用可能な前記クレジットを動的に減らすことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１４】
予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すことを含むさらなるコンピュータ実行可能命令を有することを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１５】
取り消される前に使用しなければ、少なくとも１つのクレジットが取り消されることになる旨を前記クライアントに知らせることを含むさらなるコンピュータ実行可能命令を有することを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
クライアント及びサーバを有するネットワークコンピューティング環境において、
前記クライアントに与えられるクレジットの数を制御することによってサーバリソースの使用を制限するためのメカニズムであって、前記クレジットによって１つ又は複数のサーバオペレーションを提起する権利を前記クライアントに付与するメカニズムを含むサーバ側のシステムであって、前記メカニズムは、
前記クライアントに与えられる各クレジットを表す一意の番号を含む有効オペレーションウィンドウと、
前記クライアントが前記サーバにサーバリソースの使用を要求するためのコマンドであって、受信した前記コマンドに関してさらなるサーバオペレーションを認めるために、前記コマンドが、前記有効オペレーションウィンドウ内にある１つのシーケンス番号を含み、前記一意の番号が別のコマンドに使用されていないことを保証する強制メカニズムと、
前記クライアントに与えられるクレジット及び前記有効オペレーションウィンドウ内の前記一意の番号を制御するとともに、最大ウィンドウサイズを保持し、これによって、クレジットを有するクライアントは、前記最大ウィンドウサイズに対応する最大のシーケンス番号を超えるシーケンス番号を有するコマンドを送信できなくする割り当てメカニズムを含むことを特徴とするシステム。
【請求項１７】
サーバリソースの使用を制限するための前記メカニズムは、サーバメッセージブロックプロトコルドライバに関連付けられていることを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記メカニズムは、予め前記クライアントに与えられていた少なくとも１つのクレジットを取り消すための手段を含むことを特徴とする請求項１６に記載のシステム。
【外国語明細書】
2006333434000001.pdf