JP2000507428A - 有限メモリコンピュータシステム上におけるクライアント管理フロー制御方法及び装置 - Google Patents

Abstract

(57)【要約】 サーバおよび非ブロッキングクライアントノードを有するネットワーク上のデータフローを制御する方法および装置であって、クライアントノードは、サーバから受信したリクエストを落とし得ない。非ブロッキングクライアントノード上のプロセスは、非ブロッキングクライアントノード上のリソースを割当て、サーバに割り当てられたリソースを知らせる。次に、サーバは、サーバ上のアプリケーションによるリクエストを完了するために必要な非ブロッキングクライアントノード上のリソースを決定し、アプリケーションによるリクエストを完了するために十分なリソースが非ブロッキングクライアントノード上で使用可能か否かを決定する。十分なリソースが使用可能である場合、サーバは、リクエストをクライアントノードに送信し、十分リソースが存在しない場合には、サーバは、十分なリソースが存在するまで待ち、非ブロッキングクライアントノードにリクエストを発行する。

Description

【発明の詳細な説明】 有限メモリコンピュータシステム上における クライアント管理フロー制御方法及び装置発明の属する技術分野 本発明は、概してコンピュータ用通信システムに関し、より詳細には、コンピ ュータネットワーク用通信システムに関する。発明の背景 現代のコンピュータネットワークは数多くのコンピュータにより構成される。 コンピュータネットワークを構成するコンピュータはノードと呼ばれ、一連の通 信リンク上において互いにデータのパケットを送信することにより通信を行う。 コンピュータは、一般に通信プロトコルと呼ばれる規則のセットに従って通信を 行う。１つの通信プロトコルのモデルはそれぞれ専門の機能を有する一連の層を 記述する。最下位の３つのプロトコル層はともに一般にネットワークサービスと 呼ばれる。 ネットワークサービスの最下位のプロトコル層は物理層と呼ばれる。物理層は 通信リンクの物理的な特性を支配する標準のセットである。物理層にはデータが 送信される電圧、及びデータパルスが通信リンクに与えられる周波数が含まれる 。物理層の上のプロトコル層はデータリンク層である。 データリンク層は送信ノードにおいて元のデータをパケットに分割すること、 及び受信ノードにおいてデータパケットを元のデータに再構築することについて 責任を有する。加えて、データリンク層はエラーのないデータ送信について責任 を有する。データリンク層は、パケット又はパケット群が受信される時ごとに、 送信ノードに対して、受信ノードに肯定応答を送信させることにより、このこと を達成する。もしデータリンク層が肯定応答を受信することに失敗した場合、特 定の時間後、送信に応答して、データリンク層はデータパケットが受信ノードに 到達していないと仮定し、パケットを再送信する。肯定応答の使用は、データが 受信ノードに対して余りに高速に送信されることを防ぐフロー制御機構として機 能する。 データパケットの保証された正確な伝送を確実にすることにより、小型コンピ ュータのコンピュータネットワークは、一旦大きなメインフレームに退避された タスクを実行するために使用される。そのようなネットワークにおいて、特定の ノードは、サーバと呼ばれる他のノードから、クライアントリクエストサービス と呼ばれる。例えば、クライアントノード上のユーザはサーバノード上のデータ をアクセスすることができる。これにより、ユーザのノード上にそのデータのた めの記憶装置を持つ必要はなくなる。 従来技術にとって公知である典型的なアプリケーションにおいては、アプリケ ーションを実行しているクライアントノードは、ファイルサーバノードからのデ ータをローカルに要求する。ファイルサーバノードが要求されたデータを送信す るためには不十分なバッファしか有しないことを発見した場合、ファイルサーバ ノードは単にブロックし、送信バッファが使用可能になるのを待つ。完全なオペ レーティングシステムと十分なメモリを有するファイルサーバノードは、他のタ スク上における処理を継続しながら、１つのクライアントにデータを供給する１ つのタスクをブロックすることができる。送信バッファが使用可能になると、フ ァイルサーバノードはブロックを解除しバッファのデータをクライアントノード に送信する。 別の典型的ではないアプリケーションにおいては、クライアントノードは、ネ ットワークアプリケーション実行サーバと呼ばれる別のネットワークノードに位 置するアプリケーションを実行する。この場合クライアントノードは、ネットワ ークアプリケーション実行サーバに対する入力デバイスおよび出力デバイスとし て機能するだけである。クライアントノードは主にデータ入力およびデータ表示 のために使用されるため、このようなクライアントノードは典型的には完全なオ ペレーティングシステムを有しておらず、少量のメモリしか有さない比較的能力 のないコンピュータである。ネットワークアプリケーション実行サーバ上で実行 しているアプリケーションがデータを必要としている場合、典型的にはクライア ントからデータを要求しなければならない。このように、このアプリケーション においては、クライアントおよびサーバの典型的な役割は、データの伝送に関し て逆にされる。 より小型の、比較的能力のないコンピュータの使用は、クライアントが不十分 な使用可能な伝送バッファを有している場合に、そのバッファが使用可能になる のを待っている間ブロックができないという問題を生じさせる。これは、クライ アントノードが典型的には一度に一つのタスクしか実行可能でなく、一つのタス クのブロッキングはコンピュータが他のタスクを実行することを妨げるからであ る。また、クライアントは要求を単純にドロップできず、ネットワークアプリケ ーション実行サーバを時間切れにさせることができない。なぜなら、小型メモリ のクライアントノードで十分なバッファを欠くことは、かなり頻繁に起きること であり、このことが性能の低下をもたらすからである。 本発明は、要求をドロップし得ない非ブロッキングクライアントを有するネッ トワークにおいてフロー制御を提供する方法および装置を提供する。発明の概要 一つの実施形態では、本発明は、サーバと非ブロッキングクライアントノード とを有するネットワークであって、このネットワークにおいてクライアントがサ ーバから受け取ったリクエストをドロップし得ないネットワーク上のデータフロ ーを制御する方法に関する。この方法は、非ブロッキングクライアントノード上 でリソースを割り当て、割り当てられたリソースをサーバに知らせるステップと を包含する。サーバは、その後サーバのアプリケーションによるリクエストを完 了するために必要とされる非ブロッキングクライアントノード上のリソースを決 定し、アプリケーションのリクエストを完了するために非ブロッキングクライア ントノード上で十分なリソースが使用可能かどうかを決定する。リクエストを完 了するために、非ブロッキングクライアントノードで十分なリソースが使用可能 な場合、サーバはクライアントノードにリクエストを送り、十分なリソースが存 在しない場合、サーバは十分なリソースが存在して非ブロッキングクライアント ノードにリクエストを発行するまで待機する。他の実施形態においては、サーバ は、分割可能なリクエストをサブリクエストに分割する。サブリクエストは該非 ブロッキングクライアントノード上で使用可能なリソースによって満足させられ 得る。 更に別の実施形態において、本発明は、通信リンクによって相互接続されるサ ーバノードと非ブロッキングクライアントノードとを有する、ネットワーク上の フローコントローラに関する。非ブロッキングクライアントノードは、メモリと プロセッサを含む。非ブロッキングクライアントノード上のプロセッサは、リソ ースを割り当て、通信リンクをわたってサーバノードにリソースが使用可能であ ることを知らせる。アプリケーションを実行しているサーバノード上でのフロー 制御プロセスは、非ブロッキングクライアントノードに直結するアプリケーショ ンからの要求を受け取る。サーバフロー制御プロセスは要求を供給するために非 ブロッキングクライアントノード上に十分に使用可能なリソースがあるかどうか を決定する。十分なリソースが使用可能な場合、サーバフロー制御プロセスは、 要求をアプリケーションから非ブロッキングクライアントノードへと、通信リン クにわたって通過させる。十分なリソースが使用可能でない場合、サーバプロセ スは、アプリケーションからのリクエストを供給するために十分なリソースが使 用可能であるという情報を、サーバプロセスが非ブロッキングクライアントノー ドから受け取るまで、リクエストを保持する。図面の簡単な説明 本発明を、特に添付の請求の範囲において示す。本発明の上記およびさらなる 利点は、添付の図面に関連して以下の説明を参照することによってより理解され 得る。 図１は、本発明のアプリケーションに従ってネットワークにおける通信リンク によって接続されるサーバノードおよび非ブロッキングクライアントノードの実 施態様のブロック図である。 図２および図２Ａは、本発明の方法の実施態様のフロー図である。発明の詳細な説明 図１を参照しながら簡単に説明する。本発明に従って構築されたネットワーク は、サーバノード１０、非ブロッキングクライアントノード１８、および通信リ ンク２６を有する。サーバノード１０は、マイクロプロセッサ３４およびメモリ ４２を有する。サーバマイクロプロセッサ３４は、アプリケーションプロセス５ ０およびフロー制御プロセス５８を実行している。サーバノード１０はさらに、 メモリ４２内にリソースカウンタ６６を有する。非ブロッキングクライアントノ ード１８はさらに、クライアントプロセス８２を実行し、限定された量のメモリ ９０を有するマイクロプロセッサ７４を有する。限定されたメモリとは、ノード が受け取るリクエストの数を処理するのに使用可能な通信バッファスペースの量 が不十分であることを意味する。従来技術では、このような状況は、通常、リク エストまたは関連の応答を落としてしまうことになる。 立ち上げ時に、クライアントプロセス８２は、使用可能なバッファメモリ９０ をバッファ９８（ａ）−（ｃ）などの割当て可能なリソースに分割する。これに よって、所定のサービスに対するメモリが、クライアント−ホスト接続に基づい て確実に使用可能になる。 動作中、クライアントノード１８は、通信リンク２６を通してメッセージをサ ーバノード１０に送信する。このメッセージは、クライアントノード１８が使用 可能なリソース９８（ａ）−（ｃ）の量および各バッファの最大サイズを示す。 フロー制御プロセス５８は、この番号を、接続を記載するデータ構造におけるメ モリ内に配置されたリソースカウンタ６６にロードする。次に、クライアントノ ード１８は、サーバノード１０に、クライアントノード１８に対してアプリケー ションプロセス５０を実行するように要請し得る。例えば、アプリケーションプ ロセスは、アカウティングプログラムであり得る。 アプリケーションプロセス５０が実行されるとき、クライアントノード１８か らのデータを受け取る必要があり得、このようなリクエストをフロー制御プロセ ス５８に対して行う。例えば、アプリケーションプログラム５０は、クライアン トノード１８を通してディスク１１４上の格納１０６から受信されるデータを必 要とし得る。フロー制御プロセス５８は、クライアントノード１８が十分なリソ ース、例えば、バッファ９８（ａ）−（ｃ）を有するか否かを決定し、メモリ４ ２内のリソースカウンタ６６を調べることによってリクエストを供給する。十分 なバッファ９８（ａ）−（ｃ）がクライアントノード１８上に存在する場合、サ ーバノード１０は、リクエストをクライアントノード１８に送信し、リソースカ ウンタ６６において使用可能なリソースの数を減少させる。 十分なリソース９８（ａ）−（ｃ）がクライアントノード１８上に存在しない 場合、フロー制御プロセス５８は、アプリケーションプロセス５０からのリクエ ストが、クライアントノード１８上でのリソースで間に合うような多数のより小 さなリクエストに分割され得るか否かを決定する。例えば、アプリケーション５ ０が、クライアントノード１８からの５つのバッファの情報を必要とし、クライ アントノードが、３つのバッファしか使用可能でない場合、フロー制御プロセス ５８は、リクエストを、クライアントノード１８からの３つのバッファのデータ に対するリクエストに分割する。次に、フロー制御プロセス５８は、このような リソースが、クライアントノード１８上で使用可能になるまで、２つのバッファ に対する残りのサブリクエストを保持する。クライアントノード１８が、アプリ ケーションプロセス５０へのデータの送信を完了し、バッファを再使用できるよ うに放出すると、サーバノード１０は、３つのバッファの到着に留意し、リソー スカウンタ６６を３だけ増加させ、クライアントノード１８上でさらにリソース が使用可能であることを示す。しかし、クライアントの単一スレッデッド（sing le threaded）特性のために、送信は即座に成し遂げられ得ず、その結果、リク エストおよび／または応答は、送信が完了するまで予め割り当てられたバッファ 内にとどまる。 図２および図２Ａを参照しながら、プロセスをさらに詳細に検討する。クライ アントノード１８は、使用可能なバッファメモリを送信および受信バッファに分 割することによってバッファを割り当てる（ステップ１０）。次に、クライアン ト１８は、通信リンク２６を通して、メッセージをサーバノード１０に送信する （ステップ１８）。このメッセージは、クライアントノード１８が、データ送信 用に使用可能であること、およびクライアントノード１８が使用可能な送信バッ ファ９８（ａ）−（ｃ）の数を示す。サーバノード１０上のフロー制御プロセス ５８は、このメッセージを受信し（ステップ２６）、この使用可能なバッファの 数をメモリ４２に格納する（ステップ３４）。サーバノード１０上のアプリケー ション５０が開始すると（ステップ４２）、フロー制御プロセス５８は、クライ アントノード１８に向けられたアプリケーション５０からのデータに対するリク エストを受信する（ステップ５０）。 フロー制御プロセス５８は、クライアントノード１８が、リクエストを供給す るために使用できる十分なバッファ９８（ａ）−（ｃ）を有するか否かを決定す る（ステップ５８）。フロー制御プロセス５８は、メモリ４２内に格納されたバ ッファの数を調べることによってこのような決定を行う。フロー制御プロセス５ ８が、十分なバッファ９８（ａ）−（ｃ）がクライアントノード１８上に存在す ると決定すると（ステップ６４）、サーバノード１０は、リクエストをクライア ントノード１８に送信し、メモリ４２内に挙げられた使用可能なバッファの数を 減少させる（ステップ７２）。 フロー制御プロセスが、十分なバッファ９８（ａ）−（ｃ）が、クライアント ノード１８上に存在しないと決定すると（ステップ８０）、フロー制御プロセス ５８は、リクエストが分割され得るかどうかを決定する（ステップ８８）。リク エストが分割され得ない場合（ステップ９６）、分割されたリクエストに必要な バッファの量が、上記のように決定される（ステップ５８）。リクエストがさら に分割され得ない場合（ステップ１０４）、フロー制御プロセスは、分割された リクエストに対して十分なバッファの数が使用可能になるまで待つ（ステップ１ １２）。 一旦、クライアントノード１８が、リクエストを受信し（ステップ１２０）、 リクエストされたデータをサーバノード１０に送信すると（ステップ１２８）、 クライアントノード１８は、バッファを再使用できるように放出する。一旦、サ ーバノード１０がデータを受信すると（ステップ１３６）、サーバノード１０は 、バッファがクライアントノード１８上で放出されたことを知り、メモリ４２内 の使用可能なバッファの数を増加させる（ステップ１４４）。このように、サー バノード１０は、クライアントノード１８上の使用可能なバッファの数を追跡し 、クライアントノードのブロックを必要とせず、リクエストを落とすことなく、 データの紛失を防止するのに必要なフロー制御を提供する。 本発明の好ましい実施態様について説明したが、同様の概念を含む他の実施態 様も用いられ得ることは当業者に明白である。従って、これらの実施態様は、開 示されている実施態様に限定されず、以下の請求の範囲の精神および範囲のみに よって限定されるべきである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，Ｓ Ｄ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ， ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，Ｎ Ｏ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ， ＵＺ，ＶＮ，ＹＵ

Claims (1)

1. 【特許請求の範囲】 １．リクエストを落とし得ないサーバおよび非ブロッキングクライアントノード を有するネットワーク上のフロー制御方法であって、 該非ブロッキングノードによって該非ブロッキングクライアントノード上のリ ソースを割り当てるステップと、 該サーバに、該割当てられたリソースを該非ブロッキングクライアントノード によって知らせるステップと、 該サーバ上で実行されるアプリケーションによって成されるリクエストを完了 するために必要な該非ブロッキングクライアントノード上の該リソースを該サー バによって決定するステップと、 該アプリケーションの該リクエストを完了するために十分なリソースが、該非 ブロッキングクライアントノード上で使用可能か否かを該サーバによって決定す るステップと、 該リクエストを完了するために十分なリソースが該非ブロッキングクライアン トノード上で使用可能である場合、該サーバによって該アプリケーションの該リ クエストを該非ブロッキングクライアントノードに送信するステップと、 を包含する方法。 ２．前記サーバ上の前記非ブロッキングクアイアントノードの前記割り当てられ たリソースの前記通知を格納するステップをさらに包含し、該通知は該非ブロッ キングクライアントノード上の使用可能な割り当てられたリソースに関する情報 を含む、請求項１に記載のフロー制御方法。 ３．前記非ブロッキングクライアントノードに送信される前記アプリケーション からの前記リクエストに応答して、前記サーバによって前記通知情報を更新する ステップをさらに包含する、請求項２に記載のフロー制御方法。 ４．前記リクエストを完了するために十分な使用可能なリソースが前記非ブロッ キングクライアントノード上で使用可能でない場合、該リクエストが分割可能で あるか否かを該サーバによって決定するステップと、 該リクエストが分割可能である場合、該リクエストをサブリクエストに分割す るステップであって、サブリクエストの数が、該サブリクエストの少なくとも１ つを完了するために該非ブロッキングクライアントノード上で十分なリソースが 使用できるように選択される、ステップと、 該非ブロッキングクライアントノード上の該リソースによって完了され得る該 サブリクエストを、該サーバによって該非ブロッキングクライアントに送信する ステップと、 をさらに包含する、請求項１に記載の方法。 ５．前回のリクエストに対する応答を、前記非ブロッキングクライアントノード から該サーバによって受信するステップと、 該応答に応答して、該サーバノード上に格納される前記通知を更新するステッ プと、 をさらに包含する、請求項２に記載のフロー制御方法。 ６．リクエストを落とし得ない、複数のリソースを含む非ブロッキングクライア ントノードと、 該非ブロッキングクライアントノードと通信するサーバノードとを有し、 該サーバノードが、 該サーバノード上で実行されるアプリケーションプロセスと、 該サーバノード上で実行されるフロー制御プロセスであって、該フロー制御プ ロセスが、該非ブロッキングクライアントノードがリクエストを受信および供給 できるか否かを決定する、プロセスと、 該非ブロッキングクライアントノード上に配置された使用可能なリソースに対 応するリソース情報を含むメモリと、 を有する、ネットワーク。 ７．前記サーバノードが、リソース情報に応答して、前記アプリケーションプロ セスからのリクエストを前記非ブロッキングクライアントノードに送信し、該非 ブロッキングクライアントノードに送信されるリクエストおよび該非ブロッキン グクライアントノードから受信されるバッファに応答して、該リソース情報を更 新する、請求項６に記載のネットワーク。