JP2004265419A - リソースの遅延割振りのための方法およびシステム - Google Patents

Abstract

【課題】 リソースの遅延割振りのための方法およびシステムを提供する。
【解決手段】 本発明は、サーバが、クライアントの要求にリソースを割り振ることを遅延させることができるようにする。クライアントがサーバリソースを必要とする機能を要求した場合、サーバは、クライアントの要求を受け入れ、確認するが、クライアントは、サーバからさらに通知があるまで、要求の機能を使用することを禁じられる。その後、サーバは、リソースが利用可能になった場合にだけ、クライアントの要求をサポートするのに必要なリソースを割り振る。それまで、サーバは、要求をサポートすることなく通信セッションを維持する。クライアントは、サーバが即時に要求を満たすことができない場合、要求を繰り返す必要がない。代わりに、サーバは、要求を受け入れ、後に、十分なリソースが利用可能になった時点でその要求をサポートすることを始める。
【選択図】 図６

Description

本発明は、一般に、ネットワーク通信に関し、より詳細には、ネットワーク上のクライアントおよびサーバの間でリソースを割り振ることに関する。

近年における公共と私設両方のコンピュータ網の急速な成長は、大部分が、「クライアント／サーバコンピューティング」によって促進されてきた。このモデルでは、１つのコンピューティングデバイスであるクライアントが、別のコンピューティングデバイスであるサーバにサービスまたは機能を提供することを要求する。「クライアント」および「サーバ」は、要求トランザクションにおける当事者を表わすためだけに使用していることに留意されたい。一部のコンピューティングデバイスは、複数のクライアントにサービスを提供することができる専用サーバとして実施されるが、クライアントとサーバは、トランザクションごとに役割を交替することができる。「ピアツーピア」ネットワーク（例えば、短距離無線を介して通信するデバイスの間で一般的である）では、すべてのコンピューティングデバイスが、順次に、または同時にクライアントとサーバの両方になる可能性を有する。

サーバは、しばしば、機能またはサービスの要求を満たすために貴重なリソースを割り振らなければならない。クライアントから要求を受信すると、サーバは、自らのリソースの利用可能性を調べる。従来、サーバは、要求を満たすリソースを有していない場合、その要求を拒否する。クライアントは、要求の機能またはサービスなしに進むことができる場合、そのようにし、要求を満たすのに必要なリソースがサーバに用意されている可能性がある後の時点で要求を再び提出する。

貴重なサーバリソースがそのリソースを使用することを許可されたクライアントだけに専用であることを確実にするため、サーバは、しばしば、要求を行っているクライアントの同一性を調べる。クライアントが、サーバを満足させるように自らを認証できない場合、サーバは、要求を拒否する。

しかし、許可のないクライアントからのこの保護は、完全ではない。認証プロセスが完了する前にいくつかのタイプの要求が行われる。その要求が最終的に拒否される場合でも、これらの要求を処理することは、いくらかのレベルのサーバリソースを消費する。例えば、不正なクライアントが、サーバに要求を繰り返し行うことにより、サーバに対して「サービス拒否（ｄｅｎｉａｌ ｏｆ ｓｅｒｖｉｃｅ）（ＤＯＳ）」攻撃をもたらす可能性がある。このクライアントは、自らを認証することに失敗し、クライアントの要求は最終的に拒否されるが、サーバは、当面、各要求中にクライアントを認証しようと試みてあまりにも多くのリソースを利用するので自らのリソースプールを使い果たし、しまいには、いずれの要求も満たすことができないようになり、許可されたクライアントによって行われた要求さえ満たすことができなくなる。

以上に鑑みて、本発明は、サーバが、クライアントの要求にリソースを割り振ることを遅延させることができるようにする。クライアントがサーバリソースを必要とするサービスまたは機能（例えば、クライアントとサーバの間のメッセージの暗号化または圧縮などの）を要求した場合、サーバは、クライアントの要求を受け入れ、確認するが、クライアントは、サーバからさらに通知があるまで、要求の機能を使用することを禁じられる。例えば、許可プロセス中、サーバは、セッションを維持し、クライアントを許可するのに必要とされる最小限のリソースだけを割り振る。その後、サーバは、リソースが利用可能になった場合にだけ、クライアントの要求をサポートするのに必要なリソースを割り振る。それまで、サーバは、要求をサポートすることなく通信セッションを維持する。したがって、サーバは、潜在的に悪意のあるクライアント、動作不良のクライアント、または誤った構成のクライアントの気の向くままに自らのリソースをゆだねるのではなく、リソースの世話をする。また、正当なクライアントは、サーバが即時に要求を満たすことができない場合、要求を繰り返す必要がない。代わりに、サーバは、要求を受け入れ、後に、十分なリソースが利用可能になった時点でその要求をサポートする。

一実施形態によれば、クライアントからデータ圧縮の要求を受信した後、サーバは、その要求を受け入れ、確認するが、通信データを圧縮するのに必要なリソースを割り振ることを遅延させる。実際、サーバは、クライアントがサーバに対して成功裡に自らを認証するまで、リソースが利用可能であるかどうかを調べることさえ行わない可能性がある。圧縮要求は受け入れられているが、クライアントおよびサーバは、データを圧縮することなく通信する。これは、圧縮に必要なリソースがサーバ上で利用可能になるまで続けられる。その時点で、サーバは、必要なリソースを割り振り、現時点で圧縮がサポートされることをクライアントに示す。サーバは、例えば、クライアントに圧縮されたデータを送信することにより、そのことを合図することができる。合図（例えば、圧縮データ）を受け取ると、クライアントは、現時点で、圧縮を使用して通信することが許されていることを認識する。クライアントは、圧縮データをサーバに伝送することを始めることによって応答する。

圧縮は、クライアントが要求することが可能な通信機能の一例に過ぎない。他の例には、サービス品質（ＱＯＳ）と一般に呼ばれる多様な機能が含まれる。ＱＯＳ機能には、一般に、帯域幅保証、応答時間保証、誤りに対する耐性、メッセージシーケンスの完全性および重複の欠如、最大許容可能損失率（ｍａｘｉｍｕｍ ｐｅｒｍｉｓｓｉｂｌｅ ｌｏｓｓ ｒａｔｅ）等が含まれる。ＱＯＳ機能は、本発明の一実施形態に従って、サーバが、一度にすべてではなく、レベルごとにリソースを割り振ることができる例を提供する。例えば、クライアントが、大量の保証された帯域幅を要求する。サーバは、最初、要求を受け入れるが、少量の保証された帯域幅だけをサポートするのに十分なリソースを割り振る。クライアントは、これを認識し、少量の帯域幅だけを使用する。後に、サーバは、より多くの帯域幅をこのクライアントに割り振り（例えば、別のクライアントが帯域幅を解放したことに応答して）、クライアントが、より多くの帯域幅量を使用し始める。

やはり、本発明に従って、サーバまたはクライアント（あるいは両方）が、要求された機能に関する情報、およびサポートされているサービスの実際のレベルに関する情報を保持する。サーバは、各クライアントに関してこの情報を監視し、クライアントの要求をより十分にサポートするために、リソースが利用可能になるにつれて追加のリソースをクライアントに割り振る。

クライアントは、受け入れられてサポートされている、受け入れられるが、まだサポートされていない、および拒否されたものとして要求のステータスをユーザに表示することができる。サーバは、同様の情報を管理者に、またはログファイルに提供することができる。

特許請求の範囲が詳細に本発明の特徴について述べているが、本発明、ならびに本発明の目的および利点は、添付の図面と併せて考慮される以下の詳細な説明からよく理解することができる。

同様の符号が同様の要素を指している図面を参照すると、本発明が、適切なコンピューティング環境において実施されているのが示されている。以下の説明は、本発明の実施形態に基づいており、本明細書で明示的に説明しない代替の実施形態に関して本発明を限定するものと考えるべきではない。

以下の説明では、本発明は、特に明記しない限り、１つまたは複数のコンピューティングデバイスによって行われる作用（ａｃｔ）、および動作の記号表現に関連して説明する。このため、ときとしてコンピュータによって実行されるものとして述べるそのような作用および動作には、コンピューティングデバイスの処理ユニットによって行われる構造化された形態のデータを表わす電気信号の操作が含まれることを理解されたい。この操作は、データを変換するか、またはコンピューティングデバイスのメモリシステムの中の場所にデータを保持し、これにより、当分野の技術者には周知の仕方でデバイスの動作が再構成されるか、または別の形で変えられる。データが保持されるデータ構造は、データのフォーマットによって定義された特定のプロパティを有するメモリの物理域である。ただし、本発明を以上の文脈で説明しているが、限定することを意図するものではない。というのは、以下に説明する様々な作用および動作は、ハードウェアで実施することも可能であるからである。

本発明は、サーバが、クライアント要求を受け入れるが、その要求をサポートするのに必要なリソースを割り振るのを遅延させることができるようにする。図１は、本発明を使用することができるコンピュータネットワーキング環境１００の例を与えている。例示的なネットワーク１００は、サーバコンピューティングデバイス１０２、ならびに３つのクライアントコンピューティングデバイス１０４、１０６、および１０８を含む。ネットワーク１００は、企業ローカルエリアネットワーク（ＬＡＮ）、無線ネットワーク、インターネット、または任意の中間形態のネットワークであることが可能であり、ルータ、ゲートウェイ、ハブなどの多くの周知の構成要素を含むことが可能である。例示的なトランザクションでは、クライアント１０４が、サーバ１０２からサービスまたは通信機能を要求する。サーバ１０２は、要求を暫定的に受け入れるが、例えば、クライアント１０４が自らをサーバ１０２に対して認証するまで、またはリソースが利用可能になるまで、要求された機能をサポートするリソースを割り振らない。リソースが割り振られ、サーバ１０２が、クライアント１０４にその事実を知らせるまで、クライアント１０４とサーバ１０２は、要求された機能を使用することなく通信する。したがって、サーバ１０２は、潜在的に悪意のあるクライアント、動作不良のクライアント、または誤った構成のクライアントの気の向くままに自らのリソースをゆだねるのではなく、リソースの番をする。

別のトランザクションでは、クライアント１０４とサーバ１０２は、役割を交替して、「サーバ」１０２が「クライアント」１０４からサービスを要求することが可能である。ピアツーピアネットワークでは、すべてのコンピューティングデバイスが、順次に、または同時にクライアントとサーバの両方になることができる。したがって、本発明の実施形態は、クライアント上で、サーバ上で、ピア上で、または以上の任意の組合せで実施することが可能である。

コンピューティングデバイス１１０は、別のサーバであるが、サーバ１０２とだけ直接に通信してサーバ１０２にリソースを提供するサーバである。デバイス１１０の存在は、本発明の方法に従い、サーバ１０２が、自らのリソースの番をするだけでなく、ネットワーキング環境１００全体のリソースの番もすることを例示している。

図１のコンピューティングデバイス１０２および１０４は、任意のアーキテクチャであることが可能である。図２は、本発明をサポートする例示的なコンピュータシステムを全体的に示すブロック図である。図２のコンピュータシステムは、適切な環境の一例に過ぎず、本発明の使用および機能の範囲について何ら限定を示唆するものではない。また、コンピューティングデバイス１０２が、図２に例示した構成要素のいずれか１つ、またはいずれかの組合せに関連する依存性または要件を有すると解釈すべきでもない。本発明は、多数の他の汎用または専用のコンピューティング環境またはコンピューティング構成で機能する。本発明で使用するのに適した周知のコンピューティングシステム、コンピューティング環境、およびコンピューティング構成の例には、パーソナルコンピュータ、サーバ、ハンドヘルドデバイスまたはラップトップデバイス、タブレットデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに以上のシステムまたはデバイスのいずれかを含む分散コンピューティング環境が含まれるが、以上には限定されない。最も基本的な構成では、コンピューティングデバイス１０２は、通常、少なくとも１つの処理ユニット２００、およびメモリ２０２を含む。メモリ２０２は、揮発性（ＲＡＭなどの）、不揮発性（ＲＯＭまたはフラッシュメモリなどの）、あるいはこの２つの何らかの組合せであることが可能である。この最も基本的な構成を図２に破線２０４で示している。コンピューティングデバイス１０２は、磁気ディスクおよび磁気テープ、ならびに光ディスクおよび光学テープを含む追加の記憶装置（取外し可能な記憶装置および取外し不可能な記憶装置）を含むことが可能である。そのような追加の記憶装置を図２に取外し可能な記憶装置２０６および取外し不可能な記憶装置２０８で示している。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意の方法または技術で実施された揮発性の媒体および不揮発性の媒体、取外し可能な媒体および取外し不可能な媒体が含まれる。メモリ２０２、取外し可能な記憶装置２０６、および取外し不可能な記憶装置２０８はすべて、コンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク、他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶デバイス、ならびに所望の情報を記憶するのに使用することができ、コンピューティングデバイス１０２によってアクセスすることが可能な任意の他の媒体が含まれるが、以上には限定されない。また、デバイス１０２は、コンピュータが他のデバイスと通信することを可能にする通信チャネルをも含むことが可能である。通信チャネル２１０は、通信媒体の例である。通信媒体は、通常、搬送波などの変調されたデータ信号、または他の移送機構でコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを実現し、任意の情報配信媒体が含まれる。「変調されたデータ信号」という用語は、信号に情報を符号化するような仕方で特性の１つまたは複数が設定されている、または変更されている信号を意味する。例として、限定としてではなく、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、およびその他の無線媒体などの無線媒体が含まれる。本明細書で使用する「コンピュータ可読媒体」という用語には、記憶媒体と通信媒体がともに含まれる。また、コンピューティングデバイス１０２は、キーボード、マウス、ペン、音声入力デバイス、タブレット、タッチ入力デバイスなどの入力デバイス２１２も有することが可能である。また、ディスプレイ（タッチ入力デバイスと一体になっていることが可能な）、スピーカ、およびプリンタなどの出力デバイスをも含むことが可能である。以上すべてのデバイスは、当技術分野で周知であり、本明細書で詳述する必要はない。

図３ａおよび３ｂはともに、クライアント１０４がサーバ１０２からある機能を要求した際のメッセージの例示的な交換を示している。図５ａ、５ｂ、７ａ，および７ｂが以下に、可能なメッセージ交換のさらなる詳細を提示している。クライアント１０４が、図３ａのステップ３００で機能を要求する。機能は、データ圧縮、データ暗号化、および多数のＱＯＳ機能を含め、任意のタイプであることが可能である。また、メッセージプロトコルも、例えば、ＳＩＰ（セッション開始プロトコル）などの任意のタイプであることが可能である。ステップ３００における機能要求は、明示的でないことに留意されたい。すなわち、この機能要求は、代わりに、クライアント１０４とサーバ１０２の間で使用されるメッセージプロトコルによって暗示されることも可能である。

ステップ３０２で、サーバ１０２が機能要求を受信し、その機能をサポートするかどうかを決める。サポートしない場合、サーバ１０２は、プロトコルにおいて定義されたメソッドを使用して要求を拒否する（図示せず）。サーバ１０２は、要求された機能をサポートし、即時にそうする用意がある場合、その機能をサポートするのに必要とされるリソースを割り振り、要求を受け入れる（やはり図示せず）。図３ａおよび３ｂに描いたシナリオは、サーバ１０２に関する第３の可能性に関する。すなわち、サーバ１０２は、要求された機能を将来、サポートすることはいとわない可能性があるが、まだそうする用意がない。このシナリオをもたらす一例は、サーバ１０２が、現在、その機能をサポートするのに利用できるリソースを有していないが、そのリソースを間もなく獲得することを予期している場合である。別の例では、サーバ１０２は、まだ、貴重なリソースをクライアント１０４の要求に割り振るだけ十分にクライアント１０４を信頼していない。サーバ１０２は、まだ、リソースを割り振らないが、クライアント１０４が自らを成功裡に認証するまで待つ（以下の図３ｂのステップ３１０および３１２のステップの説明を参照）。図３ａのシナリオでは、サーバ１０２が、ステップ３０２で、要求が受け入れられたことを示すが、要求された機能がまだサポートされないことも示すメッセージをクライアント１０４に送信する。

サーバ１０２が、要求された機能がまだサポートされないことを示すことができる多数のやり方が存在する。例えば、ＳＩＰでは、データ圧縮が通信リンク上で許される場合、データフィールドに「タグ」が追加される（図４および付随する説明を参照）。圧縮が使用可能にされた場合でさえ、すべてのデータメッセージが圧縮されるわけではなく（例えば、所与のメッセージが、圧縮を活用するには短すぎる可能性がある）、したがって、タグの中のフラグにより、付随するデータが圧縮されるかどうかが示される。本発明の実施形態は、このタグおよびフラグをステップ３０２で使用することができる。すなわち、受入れメッセージにタグを付けて、データ圧縮の要求が許されていることを示すが、フラグによって示されるとおり、そのメッセージの中のデータは圧縮されていない。ステップ３０４で、クライアント１０４が、受入れメッセージを受信し、要求の機能がまだサポートされていないことに気付く。データ圧縮の例では、タグは、要求の受入れを示すが、圧縮の欠如により、サーバが圧縮データのための用意ができていないことが示される。

ステップ３０６および３０８で、クライアント１０４とサーバ１０２が、要求の機能を使用せずに通信する。状況に応じて、これらのステップは、長い間（例えば、サーバ１０２が必要なリソースを獲得するまで）、続くことが可能であり、あるいは非常に短い（例えば、単にクライアント１０４がサーバ１０２に対して自らを成功裡に認証するまで）ことが可能である。

図３ｂのステップ３１０および３１２は、ある意味で、オプションであるが、本発明の方法が非常に有用であるシナリオを例示しているために含めている。これらのステップの間、クライアント１０４は、使用しているプロトコルによって確立されたメソッドを使用して、サーバ１０２に対して自らを認証する（当技術分野で多くのそのようなメソッドが知られている）。当然のことながら、サーバ１０２は、以上のステップが完了するまで、貴重なリソースを割り振ることを渋る。このシナリオは、リソースの遅延割振りが有用であることが分かる唯一のシナリオではないが、ＤＯＳ攻撃を防止することに密接に結び付いた１つのシナリオである。

最後に、ステップ３１４で、サーバ１０２が、クライアント１０４の要求をサポートするリソースを割り振ることを決める。ステップ３１６で、サーバ１０２は、現時点で機能がサポートされていることをクライアント１０４に示す。ステップ３０２に関して前述した多数の可能な指示の場合と同様に、現時点で機能がサポートされていることをサーバ１０２が示すことができる多くのやり方が存在する。データ圧縮の例を使用すると、サーバ１０２は、単に圧縮データをクライアント１０４に送信することができる。ステップ３１８で、どのようなものであれ指示を受信すると、クライアント１０４は、現時点で機能がサポートされていることに気付く。この時点以降、クライアント１０４とサーバ１０２は、状況に適切なように、要求の機能を使用して、あるいは使用せずに通信を行うことができる。

図４は、圧縮データまたは未圧縮のデータを送信するために使用されるメッセージデータ構造４００を示す。データ構造４００は、３つのタグフィールドを含む。最初のタグフィールド４０２は、フラグに指定される（本明細書では「フラグタグ」）。フラグタグフィールド４０２は、フィールド４０８内のデータのフォーマットを示すために、具体的には、データが圧縮されているかどうかを示すために使用される。この実施例では、フラグフィールドは、相互に排他的なビットを含む。例として、データが未圧縮であることを示すのに０ｘ８０ビットが使用され、０ｘ２０ビットにより、データが圧縮されていることが示される。

一部の実施形態では、少なくとも３つのタイプのデータパケットが存在する。すなわち、（１）現在の接続に関してデータ圧縮が利用できないことを示すタグの付いていないデータ、（２）圧縮が可能であることを示すタグが付けられているが、フィールド４０８内のデータは圧縮されていないことがフラグで示されているデータ、および（３）圧縮が可能であることを示すタグが付けられており、フィールド４０８内のデータが圧縮されているデータである。それぞれ、図３ａのステップ３０４、および図３ｂのステップ３１８で、クライアント１０４は、自らがサーバ１０２から受信したデータパケットのタイプを特定して、データ圧縮がサポートされているか否かを知る。

サーバ１０２によって行われる例示的なステップを示す流れ図を図５ａおよび５ｂに示している。ステップ５００で、サーバ１０２は、クライアント１０４からサービスまたは通信機能の要求を受信する。前述したとおり、この要求は、クライアント１０４によって送信された明示的なメッセージの形態であること、またはクライアント１０４とサーバ１０２の間で使用される通信プロトコルにおいて暗示することが可能である。サーバ１０２は、ステップ５０２で、要求された機能をサポートすることができるかどうか自らの構成を調べる。サーバ１０２がサポートするように構成されていない機能をクライアント１０４が要求していることが生じる可能性がある。その場合、メソッドは、ステップ５１０に進み、サーバ１０２がその要求を拒否する。

サーバ１０２は、少なくとも理論上、要求された機能をサポートすることができる場合、ステップ５０４で、要求を受け入れるが、クライアント１０４がまだその機能を使用できないことをクライアント１０４に告げる。

サーバ１０２が認証を受けたクライアントだけに提供するいくつかの機能が存在する。クライアント１０４がそのような機能を要求した場合、ステップ５０６で、認証プロセスが行われる。クライアント１０４が、ステップ５０８で認証に失敗した場合、サーバ１０２は、ステップ５０４で以前に要求を暫定的に受け入れているものの、ステップ５１０でその要求を拒否することができる。認証の失敗は、クライアント１０４がサーバ１０２との通信セッションを終了させなければならないことを必ずしも暗示しないことに留意されたい。終了させることは、可能な結果ではあるが、当説明では、認証の失敗の結果は、クライアント１０４が、要求の機能を使用できないことである。

クライアント１０４が、サーバ１０２に対して自らを成功裡に認証した場合（またはそのような認証が必要ない場合）、クライアント１０４とサーバ１０２は、互いに通信することを始めるが、要求の機能を使用することなく通信する。必要な場合、サーバ１０２は、ステップ５１２で十分なリソースの利用可能性を調べ、図５ｂのステップ５１４で、そのようなリソースが利用可能になった場合、クライアント１０４によって要求された機能をサポートするようにそのリソースを割り振る。図１に関連して前述したとおり、このリソースは、サーバ１０２自体に存在する必要はない。このリソースは、別のサーバ１１０によって提供することが可能である。一部のシナリオでは、リソースは、別のクライアントがそのリソースを解放した場合にステップ５１４で利用可能になることが可能である。他のシナリオでは、リソースは、常に利用可能であるが、サーバ１０２は、クライアント１０４が、図５ａのステップ５０８で自らを成功裡に認証するまで、そのリソースをクライアント１０４にゆだねることを渋る。

図５ｂのステップ５１６で、サーバ１０２は、現時点で、要求された機能をサポートする用意ができていることを示す。いくつかの機能を、異なるレベルでサポートすることが可能である。例えば、クライアント１０４が、５１２ｋｂｐｓの最小帯域幅保証を要求する。サーバ１０２は、その要求を完全にサポートするリソースを有さない場合、その要求を単に拒否することが可能である。別法として、サーバ１０２は、要求を受け入れるが、１２８ｋｂｐｓの帯域幅保証だけしかサポートできないことをクライアント１０４に告げることができる。クライアント１０４は、より低い保証が許容できるか否かを決め、それに応じて反応する。

この手続き全体で、サーバ１０２は、ステップ５１８で示されるとおり、自らのリソースのレベルおよび割振りを追跡する。サーバ１０２は、自らが要求された機能をサポートするのに十分なリソースを有しているかどうかを判定する際に、この情報を使用する。システム管理者は、サーバ１０２が最適に構成されているかどうかを判定する際にこの情報を使用する。

図６は、サーバ１０２のリソースログの例を与えている。リソース割振りログ６００は、単一の機能要求にそれぞれが関わる４つのエントリ行を含む。ログ６００において、クライアント１０４（フィールド６０２）が、データ圧縮（フィールド６０４）を要求しており、その要求が受け入れられている（フィールド６０６）。クライアント１０６によるデータ圧縮の要求は、おそらく、クライアント１０６がサーバ１０２に対して自らを認証することに失敗したために拒否されている。クライアント１０８によるデータ圧縮の要求は、暫定的に受け入れられているが、まだサポートされていない。クライアント１０８は、別の要求を行っており、今度は、５１２ｋｂｐｓの保証された帯域幅を要求している。要求は受け入れられているが、その機能は、現在、１２８ｋｂｐｓというより低いレベルでだけサポートされている。

図５ｂのステップ５２０で、クライアント１０４とサーバ１０２が、通信において要求の機能を使用することができる。ただし、クライアント１０４とサーバ１０２がその機能を使用することは必須ではない。例えば、圧縮がサポートされている場合でも、一部のメッセージは、圧縮されることを活用するには短すぎる。

サーバ１０２のリソース割振りログ６００の別の用法が、ステップ５２２で示されている。ここでは、一部のリソースが解放され（おそらく、別のクライアントから）、サーバ１０２が、リソース割振りログ６００を調べる。ログ６００は、例えば、クライアント１０８が、５１２ｋｂｐｓの保証された帯域幅を要求したが、１２８ｋｂｐｓだけしか与えられなかったことを記している。サーバ１０２は、より高いレベルで１０８の要求をサポートすることができ、そうすることを所望する場合、現時点で、そうすることができる。一部の機能に関して、サーバ１０２は、このメソッドを使用してサポートのレベルを低下させることさえできる。他の機能では、これが可能ではなく、サポートのレベルが交渉しなおされなければならない。

機能要求トランザクションのクライアント１０４の側を図７ａおよび７ｂの流れ図に示している。クライアント１０４の手続きの大半は、サーバ１０２の手続きの以上の説明に鑑みて明白であるので、ここでは、いくつかの態様を説明するだけでよい。クライアント１０４は、図６のサーバ１０２のリソース割振りログ６００と同様に、自らの要求のログを保持することができる。図７ｂのステップ７１６および７２０で示すとおり、適切な場合、サポートのレベルも含め、機能要求のステータスをクライアント１０４のユーザに表示することが可能である。

以上の説明は、サーバ１０２とクライアント１０４の間における交換の予期される経過を中心に扱った。以下のテーブルは、生じる可能性がある予期されない事態のいくつか、ならびにクライアント１０４がどのように反応すべきかを示している。

本発明の原理を適用することができる多くの可能な実施形態に鑑みて、図面に関連して本明細書で説明した実施形態は、単に例示することを意図しており、本発明の範囲を限定するものと受け止められるべきでないことを認識されたい。例えば、本発明の趣旨を逸脱することなく、例示した実施形態の構成および詳細を変更することが可能であることが、当分野の技術者には認められよう。本発明は、ソフトウェアモジュールまたはソフトウェア構成要素に関連して説明したが、それらは、ハードウェア構成要素によって等価に置き換えることができることが、当分野の技術者には認められよう。したがって、本明細書で説明した本発明は、特許請求の範囲の範囲に入る可能性があるすべてのそのような実施形態、および等価形態を企図している。

本発明を実施することができる例示的なコンピュータネットワーキング環境を示すブロック図である。 本発明をサポートする例示的なコンピュータシステムを全体的に示す概略図である。 クライアントの通信機能要求の交渉を行う間のクライアントとサーバの間における例示的なメッセージ交換を示す流れ図である。 クライアントの通信機能要求の交渉を行う間のクライアントとサーバの間における例示的なメッセージ交換を示す流れ図である。 図３ａおよび３ｂのシナリオ中にクライアントとサーバの間で交換される例示的なメッセージのデータ構造を示す図である。 サーバによって行われる例示的なリソース割振りメソッドを示す流れ図である。 サーバによって行われる例示的なリソース割振りメソッドを示す流れ図である。 サーバによって使用することが可能な要求ステータスリストのデータ構造を示す図である。 クライアントによって行われる例示的な機能要求メソッドを示す流れ図である。 クライアントによって行われる例示的な機能要求メソッドを示す流れ図である。

符号の説明

１０４、１０６、１０８ コンピューティングデバイス
６００ ログ
６０２、６０４、６０６ フィールド

Claims (43)

1. サーバコンピューティングデバイスとクライアントコンピューティングデバイスとを含む通信環境において、前記サーバが前記クライアントのために機能をサポートすることを遅延させるための方法であって、
   前記機能の要求を受信するステップと、
   前記要求が許可されたことを前記クライアントに示すステップと、
   前記要求の機能がまだサポートされていないことを前記クライアントに示すステップと、
   前記要求の機能がまだサポートされていないことを前記クライアントに示した後、前記要求の機能がサポートされることを前記クライアントに示すステップと、
   前記クライアントのために前記要求の機能をサポートするステップとを含むことを特徴とする方法。
2. 前記要求の機能は、圧縮、サービス品質、帯域幅、応答時間保証、誤りに対する耐性、メッセージシーケンスの完全性および重複の欠如、および最大許容可能損失率から成るグループから選択された前記クライアントと前記サーバの間における通信の機能であることを特徴とする請求項１に記載の方法。
3. 前記機能の要求を受信するステップは、前記クライアントから前記機能の明示的な要求を受信するステップを含むことを特徴とする請求項１に記載の方法。
4. 前記機能の要求を受信するステップは、前記クライアントから前記機能の暗示的な要求を受信するステップを含むことを特徴とする請求項１に記載の方法。
5. 前記機能の前記暗示的な要求が、前記クライアントおよび前記サーバによって使用される通信プロトコルによって指定されることを特徴とする請求項４に記載の方法。
6. 前記機能の要求を受信するステップは、前記要求の機能の第１のサポートレベルの要求を受信するステップを含み、前記要求の機能がサポートされることを前記クライアントに示すステップは、前記要求の機能が前記要求の機能の第２のサポートレベルでサポートされることを前記クライアントに示すステップを含むことを特徴とする請求項１に記載の方法。
7. 前記要求の機能の前記第２のサポートレベルは、前記要求の機能の前記第１のサポートレベルより低いことを特徴とする請求項６に記載の方法。
8. 前記クライアントのために前記要求の機能をサポートするステップは、前記要求の機能を前記要求の機能の前記第２のサポートレベルでサポートするステップを含む
   ことを特徴とする請求項６に記載の方法。
9. 前記要求の機能が前記要求の機能の前記第２のサポートレベルでサポートされることを前記クライアントに示した後、前記要求の機能が前記要求の機能の前記第１のサポートレベルでサポートされることを前記クライアントに示すステップをさらに含むことを特徴とする請求項６に記載の方法。
10. １つの指示は、
    前記要求が許可されたことを前記クライアントに示すステップと、
    前記要求の機能がまだサポートされていないことを前記クライアントに示すステップとを含むことを特徴とする請求項１に記載の方法。
11. 前記要求の機能がまだサポートされていないことを前記クライアントに示すステップは、前記クライアントとの通信において前記要求の機能を使用しないステップを含むことを特徴とする請求項１に記載の方法。
12. 前記要求の機能がサポートされていることを前記クライアントに示すステップは、前記クライアントとの通信において前記要求の機能を使用するステップを含むことを特徴とする請求項１に記載の方法。
13. 前記クライアントのために前記要求の機能をサポートするステップは、リソースを割り振るステップを含むことを特徴とする請求項１に記載の方法。
14. リソースを割り振るステップは、前記サーバ以外のコンピューティングデバイスによって提供されるリソースを割り振るステップを含むことを特徴とする請求項１３に記載の方法。
15. 前記要求の機能をサポートするためにリソースの利用可能性を調べるステップと、
    前記要求の機能をサポートするためのリソースが利用可能になるまで前記要求の機能がサポートされていることを前記クライアントに示すステップを遅延させるステップとをさらに含むことを特徴とする請求項１３に記載の方法。
16. 使用されるリソースに関する情報、およびまだサポートされていない機能要求に関する情報を保持するステップをさらに含むことを特徴とする請求項１５に記載の方法。
17. 前記サーバは、複数のクライアントをサポートし、リソースは、他のクライアントによって明け渡された際に前記要求の機能をサポートするために利用可能になることを特徴とする請求項１６に記載の方法。
18. 前記要求の機能がサポートされていることを前記クライアントに示す前に、前記クライアントの同一性を認証するステップをさらに含むことを特徴とする請求項１に記載の方法。
19. 前記要求の機能がサポートされていることを前記クライアントに示すステップは、前記サーバに対する前記クライアントの同一性の認証が成功したことに関連して行われることを特徴とする請求項１８に記載の方法。
20. 機能要求のステータスを拒否されている、受け入れられたが、まだサポートされていない、または受け入れられてサポートされているとしてログ記録するステップをさらに含むことを特徴とする請求項１に記載の方法。
21. 機能要求のサポートレベルをログ記録するステップと、
    機能要求のサポートに割り振られたリソースをログ記録するステップとをさらに含むことを特徴とする請求項２０に記載の方法。
22. サーバコンピューティングデバイスがクライアントコンピューティングデバイスのために機能をサポートすることを遅延させるための方法を行うためのコンピュータ実行可能命令を含むコンピュータ可読媒体であって、
    前記方法は、
    前記機能の要求を受信するステップと、
    前記要求が許可されたことを前記クライアントに示すステップと、
    前記要求の機能がまだサポートされていないことを前記クライアントに示すステップと、
    前記要求の機能がまだサポートされていないことを前記クライアントに示した後、前記要求の機能がサポートされることを前記クライアントに示すステップと、
    前記クライアントのために前記要求の機能をサポートするステップとを含むことを特徴とする媒体。
23. サーバコンピューティングデバイスとクライアントコンピューティングデバイスとを含む通信環境において、前記クライアントが前記サーバから機能のためのサポートを獲得するための方法であって、
    前記サーバから前記機能を要求するステップと、
    前記要求が許可されたという指示を受信するステップと、
    前記要求の機能がまだサポートされていないという指示を受信するステップと、
    前記要求の機能を使用することを控えるステップと、
    前記要求の機能がまだサポートされていないという前記指示を受信した後、前記要求の機能がサポートされているという指示を受信するステップと、
    前記要求の機能を使用するステップとを含むことを特徴とする方法。
24. 前記要求の機能は、圧縮、サービス品質、帯域幅、応答時間保証、誤りに対する耐性、メッセージシーケンスの完全性および重複の欠如、および最大許容可能損失率から成るグループから選択された前記クライアントと前記サーバの間における通信の機能であることを特徴とする請求項２３に記載の方法。
25. 前記機能を要求するステップは、前記機能の明示的な要求を前記サーバに送信するステップを含むことを特徴とする請求項２３に記載の方法。
26. 前記機能を要求するステップは、前記機能を暗示的に要求するステップを含むことを特徴とする請求項２３に記載の方法。
27. 前記機能の前記暗示的な要求が、前記クライアントおよび前記サーバによって使用される通信プロトコルによって指定されることを特徴とする請求項２６に記載の方法。
28. 前記機能を要求するステップは、前記要求の機能の第１のサポートレベルを要求するステップを含み、前記要求の機能がサポートされているという指示を受信するステップは、前記要求の機能が前記要求の機能の第２のサポートレベルでサポートされているという指示を受信するステップを含むことを特徴とする請求項２３に記載の方法。
29. 前記要求の機能の前記第２のサポートレベルは、前記要求の機能の前記第１のサポートレベルより低いことを特徴とする請求項２８に記載の方法。
30. 前記要求の機能を使用するステップは、前記要求の機能を前記要求の機能の前記第２のサポートレベルで使用するステップを含むことを特徴とする請求項２８に記載の方法。
31. 前記要求の機能が前記要求の機能の前記第２のサポートレベルでサポートされるという指示を受信した後、前記要求の機能が、前記要求の機能の前記第１のサポートレベルでサポートされるという指示を受信するステップをさらに含むことを特徴とする請求項２８に記載の方法。
32. １つの指示を受信するステップは、
    前記要求が許可されたという指示を受信するステップと、
    前記要求の機能がまだサポートされていないという指示を受信するステップとを含むことを特徴とする請求項２３に記載の方法。
33. 前記要求の機能がまだサポートされていないという指示を受信するステップは、前記要求の機能を使用しない前記サーバから通信を受信するステップを含むことを特徴とする請求項２３に記載の方法。
34. 前記要求の機能がサポートされているという指示を受信するステップは、前記要求の機能を使用する前記サーバから通信を受信するステップを含むことを特徴とする請求項２３に記載の方法。
35. 前記要求の機能がサポートされているという指示を受信する前に、前記サーバに対して前記クライアントの同一性を認証するステップをさらに含むことを特徴とする請求項２３に記載の方法。
36. 前記機能要求のステータスを拒否されている、受け入れられたが、まだサポートされていない、または受け入れられてサポートされているとして前記クライアントのユーザに表示するステップをさらに含むことを特徴とする請求項２３に記載の方法。
37. 前記機能要求のサポートレベルを前記クライアントのユーザに表示するステップをさらに含むことを特徴とする請求項３６に記載の方法。
38. クライアントコンピューティングデバイスがサーバコンピューティングデバイスから機能のためのサポートを獲得するための方法を行うためのコンピュータ実行可能命令を含むコンピュータ可読媒体であって、
    前記方法は、
    前記サーバから前記機能を要求するステップと、
    前記要求が許可されたという指示を受信するステップと、
    前記要求の機能がまだサポートされていないという指示を受信するステップと、
    前記要求の機能を使用することを控えるステップと、
    前記要求の機能がまだサポートされていないという前記指示を受信した後、前記要求の機能がサポートされているという指示を受信するステップと、
    前記要求の機能を使用するステップとを含むことを特徴とする媒体。
39. サーバコンピューティングデバイスとクライアントコンピューティングデバイスとを含む通信環境において、前記サーバが前記クライアントのために機能をサポートすることを遅延させるため、および前記クライアントが前記サーバから前記機能のためのサポートを獲得するための方法であって、
    前記クライアントによる前記サーバから前記機能を要求するステップと、
    前記サーバによる前記機能の前記要求を受信するステップと、
    前記サーバによる前記クライアントに前記要求が許可されたことを示すステップと、
    前記クライアントによる前記要求が許可されたという前記指示を受信するステップと、
    前記サーバによる前記クライアントに前記要求の機能がまだサポートされていないことを示すステップと、
    前記クライアントによる前記要求の機能がまだサポートされていないという前記指示を受信するステップと、
    前記クライアントによる前記要求の機能を使用することを控えるステップと、
    前記サーバによる前記クライアントに前記要求の機能がまだサポートされていないことを示すステップの後、前記サーバによる前記クライアントに前記要求の機能がサポートされていることを示すステップと、
    前記クライアントによる前記要求の機能がまだサポートされていないという前記指示を受信するステップの後、前記クライアントによる前記要求の機能がサポートされているという前記指示を受信するステップと、
    前記サーバによる前記クライアントのための前記要求の機能をサポートするステップと、
    前記クライアントによる前記要求の機能を使用するステップとを含むことを特徴とする方法。
40. サーバコンピューティングデバイスがクライアントコンピューティングデバイスのために機能をサポートすることを遅延させるため、および前記クライアントが前記サーバから前記機能のためのサポートを獲得するための方法を行うためのコンピュータ実行可能命令を含むコンピュータ可読媒体であって、
    前記クライアントによる前記サーバから前記機能を要求するステップと、
    前記サーバによる前記機能の前記要求を受信するステップと、
    前記サーバによる前記クライアントに前記要求が許可されたことを示すステップと、
    前記クライアントによる前記要求が許可されたという前記指示を受信するステップと、
    前記サーバによる前記クライアントに前記要求の機能がまだサポートされていないことを示すステップと、
    前記クライアントによる前記要求の機能がまだサポートされていないという前記指示を受信するステップと、
    前記クライアントによる前記要求の機能を使用することを控えるステップと、
    前記サーバによる前記クライアントに前記要求の機能がまだサポートされていないことを示すステップの後、前記サーバによる前記クライアントに前記要求の機能がサポートされていることを示すステップと、
    前記クライアントによる前記要求の機能がまだサポートされていないという前記指示を受信するステップの後、前記クライアントによる前記要求の機能がサポートされているという前記指示を受信するステップと、
    前記サーバによる前記クライアントのための前記要求の機能をサポートするステップと、
    前記クライアントによる前記要求の機能を使用するステップとを含むことを特徴とする媒体。
41. クライアントコンピューティングデバイスの同一性を表わすデータを含む第１のデータフィールドと、
    前記クライアントによって要求された機能を表わすデータを含む第２のデータフィールドと、
    前記機能の要求されたサポートレベルを表わすデータを含む第３のデータフィールドと、
    前記機能の現在のサポートレベルを表わすデータを含む第４のデータフィールドと、
    前記機能をサポートすることに現在、割り振られているリソースの量を表わすデータを含む第５のデータフィールドとを含むリソース割振りデータ構造を含むことを特徴とするコンピュータ可読媒体。
42. 前記要求の機能は、前記クライアントコンピューティングデバイスと前記サーバコンピューティングデバイスの間の通信の機能であることを特徴とする請求項４１に記載のコンピュータ可読媒体。
43. 前記第４のデータフィールドと前記第５のデータフィールドは、同一のデータフィールドであることを特徴とする請求項４１に記載のコンピュータ可読媒体。
    

Images