(57)【要約】【課題】  セッション単位に処理の実行を保証するとともに、セッション内における各コマンドの処理負荷を考慮して輻輳制御を行うことにより、過剰な輻輳制御処理を防止して、サーバの処理能力を有効に利用する。【解決手段】  クライアント装置（以下、装置とする。）が接続時に、処理コストカウンタと処理コスト閾値を比較し、カウンタが閾値以上の場合、輻輳制御を行って装置からの通信を切断し、カウンタが閾値より小さい場合、装置からリクエストを受信して、当該リクエストの種別に対応する処理コストを、処理コストテーブルを参照して取得し、取得したコストをカウンタに加算し、リクエストに対応する処理を実行して処理結果を装置に送信し、通信が完了するまで、装置からリクエストを受信して、当該リクエストに対応するカウンタの加算、及び処理の実行を繰り返し、一定時間ごとにカウンタをクリアするサーバを有する輻輳制御システム。【選択図】      図１
2005078205.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置からのリクエストに応じた処理を実行するサーバにおけるクライアント装置の輻輳制御を行う輻輳制御システムであって、
クライアント装置とサーバとの通信を中継する通信装置と、
前記リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブル，輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値，一定時間内に受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタを有する記憶装置と、
一又は二以上のクライアント装置がアクセスするサーバと、を備え、
前記サーバは、
前記クライアント装置が接続してくると、前記処理コストカウンタと前記処理コスト閾値を比較し、前記処理コストカウンタが前記処理コスト閾値以上の場合、輻輳制御を行うと判断して当該クライアント装置からの通信を切断し、前記処理コストカウンタが前記処理コスト閾値より小さい場合、前記クライアント装置からリクエストを受信して、当該リクエストの種別に対応する処理コストを、前記処理コストテーブルを参照して取得し、取得した処理コストを前記処理コストカウンタに加算し、前記リクエストに対応する処理を実行して処理結果を前記クライアント装置に送信し、通信が完了するまで、前記クライアント装置からリクエストを受信して、当該リクエストに対応する前記処理コストカウンタの加算、及び処理の実行を繰り返し、前記一定時間ごとに前記処理コストカウンタをクリアする
ことを特徴とする輻輳制御システム。
【請求項２】
前記リクエストが、複数回のコマンド送信及び応答送信を繰り返すセッションを構成する
ことを特徴とする請求項１記載の輻輳制御システム。
【請求項３】
クライアント装置からのリクエストに応じた処理を実行するにあたり、クライアント装置の接続時に、輻輳制御判断を行う輻輳制御サーバであって、
前記クライアント装置との通信を行う通信制御手段と、
前記クライアント装置からの接続要求を前記通信制御手段を介して入力すると、一定時間内に受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値を比較して、前記処理コストカウンタが前記処理コスト閾値以上の場合、輻輳制御を行うと判断して前記クライアント装置からの通信を切断し、前記処理コストカウンタが前記処理コスト閾値より小さい場合は、輻輳制御を行わない輻輳制御処理手段と、
前記クライアント装置からのリクエストを、前記通信制御手段を介して入力し、前記リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得し、取得した処理コストを前記処理コストカウンタに加算する処理コストカウンタ加算手段と、
前記リクエストに対応する処理を実行して処理結果を前記通信制御手段へ出力する通信内容処理手段と、
前記一定時間ごとに前記処理コストカウンタをクリアする処理コストカウンタクリア手段と、を有する
ことを特徴とする輻輳制御サーバ。
【請求項４】
前記リクエストが、複数回のコマンド送信及び応答送信を繰り返すセッションを構成する
ことを特徴とする請求項３記載の輻輳制御サーバ。
【請求項５】
クライアント装置からのリクエストに応じた処理を実行するサーバに、クライアント装置の輻輳制御を実行させる輻輳制御プログラムであって、
前記サーバに、
前記クライアント装置の接続時に、一定時間内に前記サーバが受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと、輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値とを比較させ、
前記処理コストカウンタが前記処理コスト閾値以上の場合、輻輳制御を行うと判断させて前記クライアント装置からの通信を切断させ、
前記処理コストカウンタが前記処理コスト閾値より小さい場合、前記クライアント装置からリクエストを受信させて、当該リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得させ、取得した処理コストを前記処理コストカウンタに加算させ、前記リクエストに対応する処理を実行させて処理結果を前記クライアント装置に送信させ、
通信が完了するまで、前記クライアント装置からリクエストを受信させて、当該リクエストに対応する前記処理コストカウンタの加算、及び処理の実行を繰り返させ、
前記一定時間ごとに前記処理コストカウンタをクリアさせる
ことを実行させるための輻輳制御プログラム。
【請求項６】
クライアント装置からのリクエストに応じた処理を実行するサーバが、クライアント装置の接続時に、輻輳制御判断を行う輻輳制御方法であって、
前記クライアント装置が、前記サーバに接続し、
前記サーバが、
一定時間内に前記サーバが受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと、輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値とを比較し、
前記処理コストカウンタが前記処理コスト閾値以上の場合、輻輳制御を行うと判断して前記クライアント装置からの通信を切断し、
前記処理コストカウンタが前記処理コスト閾値より小さい場合、前記クライアント装置からリクエストを受信して、当該リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得し、取得した処理コストを前記処理コストカウンタに加算し、前記リクエストに対応する処理を実行して処理結果を前記クライアント装置に送信し、
通信が完了するまで、前記クライアント装置からリクエストを受信して、当該リクエストに対応する前記処理コストカウンタの加算、及び処理の実行を繰り返し、
前記一定時間ごとに前記処理コストカウンタをクリアする
ことを特徴とする輻輳制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、セッション単位に処理の実行を保証することができ、かつセッション内における各コマンドの処理負荷を考慮して輻輳制御を行うことの可能な輻輳制御システム、輻輳制御サーバ、輻輳制御プログラム、及び輻輳制御方法に関する。
【背景技術】
【０００２】
近年、インターネットやイントラネットなど、情報処理装置のネットワーク化が進展し、様々なサーバが、多くのクライアント端末からの要求にもとづいて処理を実行している。このような状況において、特定のサーバに多くのクライアント端末からの処理要求が集中したような場合、そのサーバが過負荷状態となり、処理の遅延が生じてしまう場合があった。このような問題に対応するため、所定量以上の処理要求については接続を受け付けないようにしたり、あるいは複数のサーバへ処理要求を振り分けるといった輻輳制御が実現されている。
【０００３】
このような従来の輻輳制御においては、一般にサーバへの流入トランザクションを制限するための輻輳制御装置がネットワーク上に設けられている。この輻輳制御装置は、一のサーバに対して単位時間あたりに一定量以上の接続要求があった場合に、以降の接続を受け付けないようにしたり、あるいはサーバとクライアントの間に維持されているコネクションの数が規定量に達している場合に、コネクション数が規定量を下回るまでサーバへの接続を受け付けないようにすることにより輻輳制御を行っている。
【０００４】
しかし、このような輻輳制御装置を用いた方式においては、各処理ごとのサーバにかかる負荷が考慮されていないことから、サーバの処理能力に余力がある場合でも、輻輳制御が行われてしまう場合があった。
一方、サーバの負荷状態をリアルタイムに把握して、動的な負荷分散を実現する輻輳制御技術なども提案されている（例えば、特許文献１参照。）。
【特許文献１】特開２００２−９１９３６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、このような従来の輻輳制御技術によれば、サーバに流入するトランザクションが多種のリクエストや多種のリクエストシーケンスで構成されている場合、接続時点では新規トランザクションによってどれだけのＣＰＵ負荷がサーバにかかるかを予測することができない。したがって、輻輳状態を防ぐためには、もっとも負荷が高いトランザクションが流入した場合を想定して装置の輻輳設定を行わなければならなかった。
このため、負荷の低いトランザクションが多数流入した場合には、サーバの処理能力が余っているにもかかわらず以降の接続が拒否されてしまい、サーバの能力を十分に活かすことができない場合が生じるという問題があった。
【０００６】
また、従来の輻輳制御技術は、サーバとクライアント端末の接続が確立した後に、複数回のコマンド送信及び応答送信を繰り返すというセッションを想定していないため、セッションの途中で接続が切断されてしまう場合があった。このような場合、クライアント端末から再度サーバへ処理要求が行われ、もう一度セッションのはじめから処理が繰り返されるため、かえってサーバの処理負荷を増大させてしまうという問題があった。
【０００７】
例えば、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）にもとづいて電子メールを送信する場合、クライアント端末は、「ＨＥＬＯ」コマンドによりセッションを開始し、「ＭＡＩＬ」コマンドで送信者の名前を、「ＲＣＰＴ」コマンドでメール受信者の一覧をサーバへ送信する。そして、「ＤＡＴＡ」コマンドによりメール本文を送信し、「ＱＵＩＴ」コマンドによりそのメールの送信を指示する。従来の技術によれば、「ＲＣＰＴ」コマンドまでの処理が実行された後、「ＤＡＴＡ」コマンドの処理要求が輻輳制御により実行されないような場合が生じてしまう。このような場合、クライアント端末は、再度「ＨＥＬＯ」コマンドから処理要求を行うため、輻輳制御を行っているつもりが、かえって処理負荷を増加する結果を招いている場合があった。
【０００８】
本発明は、上記の事情にかんがみなされたものであり、セッション単位に処理の実行を保証するとともに、セッション内における各コマンドの処理負荷を考慮して輻輳制御を行うことにより、過剰な輻輳制御処理を防止してサーバの処理能力を有効に利用しることを可能とする輻輳制御システム、輻輳制御サーバ、輻輳制御プログラム、及び輻輳制御方法の提供を目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明の輻輳制御システムは、クライアント装置からのリクエストに応じた処理を実行するサーバにおけるクライアント装置の輻輳制御を行う輻輳制御システムであって、クライアント装置とサーバとの通信を中継する通信装置と、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブル，輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値，一定時間内に受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタを有する記憶装置と、一又は二以上のクライアント装置がアクセスするサーバとを備え、サーバは、クライアント装置が接続してくると、処理コストカウンタと処理コスト閾値を比較し、処理コストカウンタが処理コスト閾値以上の場合、輻輳制御を行うと判断して当該クライアント装置からの通信を切断し、処理コストカウンタが処理コスト閾値より小さい場合、クライアント装置からリクエストを受信して、当該リクエストの種別に対応する処理コストを、処理コストテーブルを参照して取得し、取得した処理コストを処理コストカウンタに加算し、リクエストに対応する処理を実行して処理結果をクライアント装置に送信し、通信が完了するまで、クライアント装置からリクエストを受信して、当該リクエストに対応する処理コストカウンタの加算、及び処理の実行を繰り返し、一定時間ごとに処理コストカウンタをクリアする構成としてある。
また、本発明の輻輳制御システムは、リクエストが、複数回のコマンド送信及び応答送信を繰り返すセッションを構成するものとしてある。
【００１０】
また、本発明の輻輳制御サーバは、クライアント装置からのリクエストに応じた処理を実行するにあたり、クライアント装置の接続時に、輻輳制御判断を行う輻輳制御サーバであって、クライアント装置との通信を行う通信制御手段と、クライアント装置からの接続要求を通信制御手段を介して入力すると、一定時間内に受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値を比較して、処理コストカウンタが処理コスト閾値以上の場合、輻輳制御を行うと判断してクライアント装置からの通信を切断し、処理コストカウンタが処理コスト閾値より小さい場合は、輻輳制御を行わない輻輳制御処理手段と、クライアント装置からのリクエストを、通信制御手段を介して入力し、リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得し、取得した処理コストを処理コストカウンタに加算する処理コストカウンタ加算手段と、リクエストに対応する処理を実行して処理結果を通信制御手段へ出力する通信内容処理手段と、一定時間ごとに処理コストカウンタをクリアする処理コストカウンタクリア手段とを有する構成としてある。
また、本発明の輻輳制御サーバは、リクエストが、複数回のコマンド送信及び応答送信を繰り返すセッションを構成するものとしてある。
【００１１】
また、本発明の輻輳制御プログラムは、クライアント装置からのリクエストに応じた処理を実行するサーバに、クライアント装置の輻輳制御を実行させる輻輳制御プログラムであって、サーバに、クライアント装置の接続時に、一定時間内にサーバが受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと、輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値とを比較させ、処理コストカウンタが処理コスト閾値以上の場合、輻輳制御を行うと判断させてクライアント装置からの通信を切断させ、処理コストカウンタが処理コスト閾値より小さい場合、クライアント装置からリクエストを受信させて、当該リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得させ、取得した処理コストを処理コストカウンタに加算させ、リクエストに対応する処理を実行させて処理結果をクライアント装置に送信させ、通信が完了するまで、クライアント装置からリクエストを受信させて、当該リクエストに対応する処理コストカウンタの加算、及び処理の実行を繰り返させ、一定時間ごとに処理コストカウンタをクリアさせる構成としてある。
【００１２】
また、本発明の輻輳制御方法は、クライアント装置からのリクエストに応じた処理を実行するサーバが、クライアント装置の接続時に、輻輳制御判断を行う輻輳制御方法であって、クライアント装置が、サーバに接続し、サーバが、一定時間内にサーバが受け付けたリクエストの処理コストの累積値を記憶する処理コストカウンタと、輻輳制御を行うか否かの判断の基準値を記憶する処理コスト閾値とを比較し、処理コストカウンタが処理コスト閾値以上の場合、輻輳制御を行うと判断してクライアント装置からの通信を切断し、処理コストカウンタが処理コスト閾値より小さい場合、クライアント装置からリクエストを受信して、当該リクエストの種別に対応する処理コストを、リクエストの種別ごとに対応する処理コストを記憶する処理コストテーブルを参照して取得し、取得した処理コストを処理コストカウンタに加算し、リクエストに対応する処理を実行して処理結果をクライアント装置に送信し、通信が完了するまで、クライアント装置からリクエストを受信して、当該リクエストに対応する処理コストカウンタの加算、及び処理の実行を繰り返し、一定時間ごとに処理コストカウンタをクリアする構成としてある。
【００１３】
輻輳制御システム、輻輳制御サーバ、又は輻輳制御プログラムをこのような構成にすれば、あるいは輻輳制御方法をこのような方法にすれば、サーバは、リクエストに応じて処理を実行するにあたり、そのリクエスト種別に対応する処理コストを、一定時間ごとに累積し、処理コストカウンタとして保有しておくことができる。そして、クライアント装置が接続してきた時点で、この処理コストカウンタが、所定の閾値以上になっていないかどうかを確認することができる。
これによって、ＳＭＴＰなどのように、複数のコマンドによりひとつのセッションが完結するようなリクエストに対して、一度リクエストを受け付けた場合には、その途中で輻輳制御を行うことを防止することが可能となる。また、このようなリクエストを処理する場合であっても、各コマンドごとの処理コストを処理コストカウンタに累積しておくことができるため、より適切な輻輳制御を実行することが可能となっている。
【００１４】
なお、上述の「記憶装置」は、サーバの外部記憶装置に限定するものではなく、サーバの内部に構成してもよいことは言うまでもない。
さらに、「通信が完了する」とは、セッションにおけるすべてのコマンドについての処理が実行されて正常終了するか、あるいはクライアントによって途中終了することを意味している。
【発明の効果】
【００１５】
本発明によれば、セッション単位に処理の実行を保証することができるとともに、セッション内における各コマンドの処理負荷を考慮して輻輳制御を行うことが可能であるため、処理時間の伸びと、タイムアウト後のクライアントリトライ処理による輻輳状態の継続の悪循環をより効果的に防ぐことができるとともに、サーバの処理能力を有効利用できるように、過剰な輻輳制御処理を防止することも可能となる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施形態につき、図面を参照して説明する。
［第一実施形態］
まず、本発明の第一実施形態の構成について、図１及び図２を参照して説明する。図１は、本実施形態の輻輳制御システムの構成を示すブロック図である。図２は、本実施形態の輻輳制御システムにおける処理コストテーブル及び処理コスト閾値を示す図である。
【００１７】
図１に示すように、本実施形態の輻輳制御システムは、通信装置１１０，サーバ１２０，記憶装置１３０を有している。
通信装置１１０は、サーバ１２０とクライアントとの通信を中継する装置である。通信装置１１０は、クライアントからの処理要求をサーバ１２０に送信し、その処理結果をサーバ１２０から受信してクライアントへ送信する。
なお、ここでいうクライアントとは、図示しないが、サーバ１２０と通信を行うパーソナルコンピュータなどの情報処理装置を意味している。
【００１８】
サーバ１２０は、通信装置１１０からの処理要求があると、輻輳制御を行う必要があるかどうかを判断し、輻輳制御を行う必要がない場合にその処理を実行する情報処理装置である。
このサーバ１２０は、通信制御手段１２２及び通信内容処理手段１２３を有するサービス提供部１２１，輻輳制御処理手段１２４，処理コストカウンタ加算手段１２５，処理コストカウンタクリア手段１２６を有している。
【００１９】
通信制御手段１２２は、ネットワーク上の通信装置１１０との通信(受信及び送信)を行う。また、通信制御手段１２２は、通信装置１１０を介してクライアントからの接続を受けると、輻輳制御処理手段１２４に輻輳制御を行うかどうかを問い合わせる。そして、輻輳制御を行う場合には、通信装置１１０との通信の切断を行い、輻輳制御を行わない場合には、通信内容処理手段１２３、及び処理コストカウンタ加算手段１２５に受信した内容を渡す。そして、その処理結果を通信装置１１０に送信する。
【００２０】
通信内容処理手段１２３は、通信制御手段１２２から受け取ったクライアントからのリクエストを処理する。
輻輳制御処理手段１２４は、処理コスト閾値１３２及び処理コストカウンタ１３３を参照して、処理コストカウンタ１３３の値が、処理コスト閾値１３２の値以上であれば、輻輳制御を行うと判断し、処理コストカウンタ１３３の値が、処理コスト閾値１３２の値より小さければ、輻輳制御を行わないと判断する。
【００２１】
処理コストカウンタ加算手段１２５は、通信制御手段１２２から受け取ったクライアントからのリクエストに見合うコストを算出する。このとき、処理コストの算出は、処理コストテーブル１３１を参照し、リクエスト種別に対応した処理コストを検索することによって行われる。
処理コストカウンタクリア手段１２６は、一定の間隔ごとに処理コストカウンタ１３３のクリアを行う。
【００２２】
記憶装置１３０は、本発明の輻輳制御処理において使用する各種情報を記憶する装置である。この記憶装置１３０は、処理コストテーブル１３１，処理コスト閾値１３２，処理コストカウンタ１３３を有している。
処理コストテーブル１３１は、図２に示すように、リクエストシーケンスに含まれる個々のリクエスト種別と、それに対応する処理コストの対応を記憶している。
処理コストとは、その処理負荷の高さ、つまり処理に必要なＣＰＵ時間の長さに対応するものである。
なお、ＣＰＵ時間とは、ある処理のためにＣＰＵが動作する時間のことで、ＣＰＵ処理量とも言い換えることができる。一定時間あたりに同じ件数の処理を行う場合、よりＣＰＵ時間の長い処理を行ったほうが、ＣＰＵ使用率が高くなることになる。
【００２３】
処理コスト閾値１３２は、輻輳制御を起こすかどうかを判断するために使用する基準値を記憶する。
この処理コスト閾値１３２には、一定間隔の間に使用できるＣＰＵ時間に対応した処理コスト値が設定されている。すなわち、処理コスト閾値１３２は、処理コストカウンタ１３３の値が、処理コスト閾値１３２を超えたとき、ＣＰＵ使用率が１００％より低いが１００％に近い値になるように設定された閾値を記憶している。このような閾値は、実際にサーバにＣＰＵ使用率が１００％に近い値になるような負荷をかけ、そのときの処理コストカウンタ１３３を測定することによって決定することができる。本実施形態においては、図２に示すように、処理コスト閾値１３２を「１５」としている。
【００２４】
処理コストカウンタ１３３は、一定時間内に受け付けたリクエストの処理コストの累積値を記憶する。すなわち、この処理コストカウンタ１３３は、処理コストカウンタ加算手段１２５によって加算された値の累計を記憶するとともに、一定間隔ごとに処理コストカウンタクリア手段１２６によってクリアされる。
この一定間隔は、例えば、サーバの実現するサービスの提供方針や、サーバに実際に入ってくるリクエストの流入傾向に基づいて定めることができる。間隔が短い場合には、ある瞬間にリクエストの流入が集中した場合に輻輳制御が起きることになる。間隔が長い場合には、瞬間的なリクエストの流入で輻輳制御が起こることはないがリクエストの流入量が少なくなった時でも輻輳制御を起こし続ける可能性がある。瞬間的にリクエストが集中するのが普通でありそのようなリクエストを漏らさず処理する方針のサービスでは間隔を長く定め、瞬間的なリクエストの集中は異常な状況でしか起こらないようなサービスでは間隔を短く定めることができる。
なお、記憶装置１３０は、図１に示すようにサーバ１２０の外部記憶装置とする他、サーバ１２０の内部記憶装置とすることもできる。
【００２５】
次に、本実施形態の輻輳制御システムにおける処理手順について、図１〜図４を参照して説明する。
図３は、本実施形態の輻輳制御システムにおける処理手順を示すフローチャートである。図４は、本実施形態の輻輳制御システムにおける処理手順を示すシーケンスチャートである。
【００２６】
まず、一台のクライアントのみがリクエストを送信した場合の動作について説明する。
クライアントからの接続を、通信装置１１０を介して受け付けた通信制御手段１２２は、クライアントに対する処理を行っても良いかどうかを、輻輳制御処理手段１２４に問い合わせる。
【００２７】
問い合わせを受けた輻輳制御処理手段１２４は、処理コスト閾値１３２と処理コストカウンタ１３３を参照して、これらを比較することにより、輻輳制御を行うか否かを判断する（ステップ１０）。なお、図３においては、ステップ１０において、「処理コストカウンタ１３３が、処理コスト閾値１３２より小さい場合に、輻輳制御を行わない」としているが、その分岐の判断基準を、「処理コストカウンタ１３３が、処理コスト閾値１３２以下の場合、輻輳制御を行わない」としてもかまわない。
処理コストカウンタ１３３の値が、処理コスト閾値１３２の値以上である場合、輻輳制御処理手段１２４は、輻輳制御を行うと決定し、輻輳制御のために、通信制御手段１２２、及び通信装置１１０を通じて、クライアントに対してエラー応答を返し（ステップ１１）、接続を切断する（ステップ１２）。
【００２８】
処理コストカウンタ１３３の値が、処理コスト閾値１３２より小さい場合、輻輳制御処理手段１２４は、輻輳制御を行わないと決定し、以下のようにクライアントからのリクエストを受け付けて処理を行う。
通信制御手段１２２は、輻輳制御処理手段１２４から輻輳制御を行わないとする決定を受け取って、クライアントから通信装置１１０を介して受信したリクエストの内容を、処理コストカウンタ加算手段１２５に通知する。
【００２９】
リクエスト内容を通知された処理コストカウンタ加算手段１２５は、処理コストテーブル１３１を参照してリクエストに対する処理コストを算出し、このコストを処理コストカウンタ１３３に加算する（ステップ１３）。
さらに、通信制御手段１２２は、受け取ったリクエストの内容を通信内容処理手段１２３にも渡す。通信内容処理手段１２３は、リクエストの処理を実行する（ステップ１４）。
【００３０】
通信内容処理手段１２３は、その処理の結果を通信制御手段１２２に返却し、通信制御手段１２２は、通信装置１１０を通じてクライアントに処理結果を返す（ステップ１５）。
そして、通信が完了するまで、ステップ１３からステップ１５の処理を繰り返す（ステップ１６）。したがって、本発明では、一度接続を受け付けたセッションは、たとえセッション中にコスト閾値を超えたとしても、そのセッションにおけるすべてのコマンドについての処理が実行されて正常終了するか、あるいはクライアントによって途中終了するまで接続が継続されることとなる。
【００３１】
次に、図４を参照して、同時に複数のクライアントに対してサービスを提供している場合の動作について説明する。図４は、サービス提供部１２１でＳＭＴＰサービスを提供している場合の動作を示すものである。
図４中の時刻ｔ１において、処理コストカウンタクリア手段１２６は、処理コストカウンタ１３３をクリアしている。この時点では、クライアント１は、既にサービス提供部１２１に接続している状態であり、クライアント２、クライアント３、及びクライアント４は、まだサービス提供部１２１に接続していない状態である。
【００３２】
時刻ｔ２において、通信制御手段１２２は、クライアント１から”ＲＣＰＴ”という種別のリクエストを受け取る。クライアント１は、既にサービス提供部１２１に接続している状態であるため、輻輳制御を行うか否かの判断は行わない。したがって、この時点では、通信制御手段１２２は、リクエストの処理を行うか否かの問い合わせを輻輳制御処理手段１２４に対して行わず、受け取ったリクエストの内容を処理コストカウンタ加算手段１２５に通知する。
【００３３】
通信制御手段１２２からＲＣＰＴリクエストを受け取った処理コストカウンタ加算手段１２５は、図２に示すような処理コストテーブル１３１を参照する。同図の場合、”ＲＣＰＴ”に対応するコストは「５」であるため、「５」を処理コストカウンタ１３３に加算する。
【００３４】
さらに、通信制御手段１２２からＲＣＰＴリクエストを受け取った通信内容処理手段１２３は、リクエストされた処理を実行して、通信制御手段１２２にその処理結果を返す。
通信制御手段１２２は、その処理結果を、通信装置１１０を通じてクライアント１に送信する。
【００３５】
時刻ｔ３において、クライアント２からの接続を受け付けた通信制御手段１２２は、輻輳制御処理手段１２４に問い合わせて、処理を行うか、切断を行うかの決定を受け取る。
この場合、輻輳制御処理手段１２４は、処理コスト閾値１３２を参照した結果である「１５」と、処理コストカウンタ１３３を参照した結果である「５」を比較する。そして、処理コストカウンタ１３３の値が、処理コスト閾値１３２よりも小さいため、クライアント２のリクエストに対する処理を行うと判断する。
【００３６】
時刻ｔ４，ｔ５においては、処理コストカウンタ加算手段１２５が、クライアント１、クライアント２に対して時刻ｔ２における場合と同様の処理を行い、それぞれのリクエストＤＡＴＡとＨＥＬＯに対応するコストである「１１」と「１」を、処理コストカウンタ１３３に加算する。
この結果、時刻ｔ５における処理コストカウンタ１３３の値は「１７」となる。
【００３７】
時刻ｔ６においては、クライアント３からの接続を受け付けた通信制御手段１２２は、輻輳制御処理手段１２４に問い合わせて、処理を行うか、切断を行うかの決定を受け取る。
この場合、輻輳制御処理手段１２４は、処理コスト閾値１３２を参照した結果である「１５」と、処理コストカウンタ１３３を参照した結果である「１７」を比較する。そして、処理コストカウンタ１３３の値が、処理コスト閾値１３２の値以上であるため、クライアント３の接続を切断すると判断し、この判断結果を通信制御手段１２２に通知する。そして、通信制御手段１２２は、クライアントに対してエラー応答を送信し、接続を切断する。
【００３８】
時刻ｔ７において、処理コストカウンタクリア手段１２６は、処理コストカウンタ１３３をクリアする。
時刻ｔ８，ｔ９において、処理コストカウンタ加算手段１２５は、クライアント１、クライアント２に対して時刻ｔ２における場合と同様の処理を行い、それぞれのリクエストＱＵＩＴとＭＡＩＬに対応するコストである「１」と「１」を、処理コストカウンタ１３３に加算する。
この結果、時刻ｔ９における処理コストカウンタ１３３の値は「２」となる。
【００３９】
時刻ｔ１０において、クライアント４からの接続を受け付けた通信制御手段１２２は、輻輳制御処理手段１２４に問い合わせて、処理を行うか、切断を行うかの決定を受け取る。
この場合、輻輳制御処理手段１２４は、処理コスト閾値１３２を参照した結果である「１５」と、処理コストカウンタ１３３を参照した結果である「２」を比較する。そして、処理コストカウンタ１３３の値が、処理コスト閾値１３２よりも小さいため、クライアント４のリクエストに対する処理を行うと判断する。
【００４０】
時刻ｔ１１において、処理コストカウンタ加算手段１２５が、クライアント４に対して時刻ｔ２における場合と同様の処理を行い、リクエストＨＥＬＯに対するコストである「１」を、処理コストカウンタ１３３に加算する。
そして、時刻ｔ１２において、再び処理コストカウンタクリア手段１２６は、処理コストカウンタ１３３をクリアしている。
【００４１】
このように、本実施形態の輻輳制御システムによれば、クライアントからのリクエストに対応する処理を行う場合に、サーバ１２０は、処理コストを処理コストカウンタに加算する。また、クライアントからの接続を受け付けたとき、リクエストを処理するか、あるいはリクエストを処理せずにエラーを返却するかどうかの判断を、処理コストカウンタと処理コスト閾値を比較して行っている。この処理コスト閾値には、一定間隔の間に使用できるＣＰＵ時間に対応した処理コスト値が設定されているため、処理コストカウンタが処理コスト閾値以上であるときは、ＣＰＵ時間が不足していると判断することができる。
【００４２】
したがって、ＣＰＵ時間が不足しているのにもかかわらず、処理を行おうとした場合の処理時間の増加を防止することができるとともに、クライアントタイムアウトとクライアントリトライが発生し、それが原因でサーバに対する時間あたりのリクエスト件数が増え、ますますＣＰＵ時間が不足するという悪循環を回避することが可能となる。
また、本実施形態では、一度受け付けたセッションは、完了するまで処理が実行されるため、セッション単位に処理の実行を保証することが可能である。
さらに、セッション内における各コマンドの処理負荷を考慮して輻輳制御を行うことができるため、セッション内の処理負荷にもとづいて、新規のアクセスについて接続を拒否することもできる。このため、クライアントリトライをより効率的に排除することができ、上記の効果を一層向上させることが可能となっている。
【００４３】
また、上記の各実施形態における輻輳制御を行うか否かの判断や、処理コストカウンタへの処理コストの加算などの各処理は、輻輳制御プログラムにより実行される。
この輻輳制御プログラムは、サーバ１２０におけるメモリ上に展開されてＣＰＵとの協働作業により上述の各処理手段により実行される。
すなわち、本実施形態における上各処理は、輻輳制御プログラムとサーバ１２０とが協働して実現している。
【００４４】
なお、本発明は以上の実施形態に限定されるものではなく、本発明の範囲内において、種々の変更実施が可能であることは言うまでもない。
例えば、処理コストテーブルにおける情報や、処理コスト閾値を変更したり、又は図１に示すサーバ１２０内における各手段を併合し、あるいはより詳細な単位に分割するなど適宜変更することが可能である。
【産業上の利用可能性】
【００４５】
ＳＭＴＰによる通信を行うサーバなどにおいて、サーバの処理能力を有効に利用することができるように、過剰な輻輳制御処理を防止する用途に好適に利用することが可能である。
【図面の簡単な説明】
【００４６】
【図１】本発明の実施形態の輻輳制御システムの構成を示すブロック図である。
【図２】本発明の実施形態の輻輳制御システムにおける処理コストテーブル及び処理コスト閾値を示す図である。
【図３】本発明の第一実施形態の輻輳制御システムにおける処理手順を示すフローチャートである。
【図４】本発明の第一実施形態の輻輳制御システムにおける処理手順を示すシーケンスチャートである。
【符号の説明】
【００４７】
１１０  通信装置
１２０  輻輳制御サーバ
１２１  サービス提供部
１２２  通信制御手段
１２３  通信内容処理手段
１２４  輻輳制御処理手段
１２５  処理コストカウンタ加算手段
１２６  処理コストカウンタクリア手段
１３０  記憶装置
１３１  処理コストテーブル
１３２  処理コスト閾値
１３３  処理コストカウンタ
【図１】
2005078205.tif 000003
【図２】
2005078205.tif 000004
【図３】
2005078205.tif 000005
【図４】
2005078205.tif 000006