(57)【要約】【課題】ＩＰアドレスを動的に払い出す場合においても、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供することを課題とする。【解決手段】サーバは、各クライアント端末から受信した「Discover信号」を順次処理し、応答信号として生成した「Offer信号」が送出可能な状態になっても、一律、例えば、２秒遅延させてから各クライアント端末に返送する。また、各クライアント端末から受信した「Request信号」を順次処理し、応答信号として生成した「Ack信号」が送出可能な状態になっても、一律、例えば、２秒遅延させてから各クライアント端末に返送する。【選択図】        図１
2010154096.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置がサーバに要求信号を送出し、要求信号に対する応答信号をサーバがクライアント装置に返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供する通信システムであって、
前記サーバは、前記応答信号を送出可能な状態になっても、前記応答信号の送出を遅延させるように制御する応答送出制御手段を有することを特徴とする通信システム。
【請求項２】
前記要求信号の受信状況からサーバが輻輳状態にあるか否かを判定する輻輳判定手段と、
前記要求信号に応じた応答信号を蓄積する応答信号蓄積手段と
をさらに有し、
前記応答送出制御手段は、前記輻輳判定手段によりサーバが輻輳状態にないものと判定された場合には、前記応答信号蓄積手段に蓄積されている応答信号を送出するように制御することを特徴とする請求項１に記載の通信システム。
【請求項３】
前記要求信号を蓄積する要求信号蓄積手段が前記要求信号を蓄積可能な状態にあるか否かを判定する蓄積状況判定手段と、
前記要求信号に応じた応答信号を蓄積する応答信号蓄積手段と
をさらに有し、
前記応答送出制御手段は、前記蓄積状況判定手段により前記要求信号蓄積手段が前記要求信号を蓄積可能な状態にあると判定された場合には、前記応答信号蓄積手段に蓄積されている応答信号を送出するように制御することを特徴とする請求項１に記載の通信システム。
【請求項４】
前記要求信号の受信状況からサーバが輻輳状態にあるか否かを判定する輻輳判定手段と、
前記要求信号を蓄積する要求信号蓄積手段が前記要求信号を蓄積可能な状態にあるか否かを判定する前記蓄積状況判定手段と、
前記要求信号に応じた応答信号を蓄積する応答信号蓄積手段と
をさらに有し、
前記応答送出制御手段は、前記輻輳判定手段による前記輻輳状態にあるか否かの判定結果、および前記蓄積状況判定手段による前記要求信号蓄積手段が前記要求信号を蓄積可能な状態にあるか否かの判定結果の組合せに応じて、前記応答信号蓄積手段に蓄積されている応答信号を送出するように制御することを特徴とする請求項１に記載の通信システム。
【請求項５】
前記応答送出制御手段は、第１の要求信号送出後に、各クライアント装置から送出される第２の要求信号が分散されるように前記応答信号の送出を遅延させるように制御することを特徴とする請求項１〜４のいずれか１つに記載の通信システム。
【請求項６】
前記応答送出制御手段は、前記応答信号を優先的に返送すべきことを示す優先度情報が設定されているクライアント装置について、前記応答信号の送出遅延時間が短くなるように制御することを特徴とする請求項１〜５のいずれか１つに記載の通信システム。
【請求項７】
所定の単位時間あたりに受信される前記要求信号の数を計数する計数手段をさらに有し、
前記応答送出制御手段は、前記計数手段により計数された前記要求信号の数に応じて、前記応答信号の送出遅延時間を変更することを特徴とする請求項１〜６のいずれか１つに記載の通信システム。
【請求項８】
クライアント装置から要求信号を受け付けて、要求信号に対する応答信号を返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供するサーバであって、
前記応答信号を送出可能な状態になっても、前記応答信号の送出を遅延させるように制御する応答送出制御手段を有することを特徴とするサーバ。
【請求項９】
クライアント装置から要求信号を受け付けて、要求信号に対する応答信号を返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供するサーバに適用される応答送出制御方法であって、
前記応答信号を送出可能な状態になっても、前記応答信号の送出を遅延させるように制御する応答送出制御ステップを含んだことを特徴とする応答送出制御方法。
【請求項１０】
クライアント装置から要求信号を受け付けて、要求信号に対する応答信号を返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供するサーバとしてのコンピュータに実行させる応答送出制御プログラムであって、
前記応答信号を送出可能な状態になっても、前記応答信号の送出を遅延させるように制御する応答送出制御手順を前記コンピュータに実行させることを特徴とする応答送出制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、通信システム、サーバ、応答送出制御方法および応答送出制御プログラムに関する。
【背景技術】
【０００２】
従来、ＤＨＣＰ（Dynamic Host Configuration Protocol）に代表される通信プロトコルを用いて、クライアントとサーバとの間で関連性を持った複数の要求および応答の対をやり取りさせることで、サーバからクライアントに対して、ＩＰアドレスやサブネットマスクなどのＩＰ通信のための情報を払い出すサービスを提供する技術が存在する。
【０００３】
以下に、図１１を参照しつつ、クライアントとサーバとで構成される通信システムに、ＤＨＣＰを適用した場合のやり取りについて簡単に説明する。ＤＨＣＰクライアントは、例えば、電源投入のタイミングで、クライアントに一意なクライアントＩＤを含む「Discover信号」を送出して、ＩＰアドレスやサブネットマスクなどのＩＰ通信に必要な情報（ＩＰ設定情報）を要求する（同図（１）参照）。
【０００４】
ＤＨＣＰサーバは、ＤＨＣＰクライアントから「Discover信号」を受け付けると、「Discover信号」に含まれるクライアントＩＤに従って、払出可能なＩＰ設定情報の候補を決定し、決定したＩＰ設定情報の候補を含む「Offer信号」を送出する（図１１の（２）参照）。ＤＨＣＰサーバは、ＤＨＣＰクライアントから「Offer信号」を受け付けると、「Offer信号」に含まれるＩＰ設定情報の候補を確認して、受託できるものであれば「Request信号」をＤＨＣＰサーバに送出し、ＩＰ設定情報の確保を要求する（同図（３）参照）。
【０００５】
ＤＨＣＰサーバは、ＤＨＣＰクライアントから「Request信号」を受け付けると、ＤＨＣＰクライアントに通知したＩＰ設定情報の候補を、ＤＨＣＰクライアントに払い出すＩＰ設定情報として確定的に確保する。そして、確定的に確保したＩＰ設定情報を含む「Ack信号」をＤＨＣＰクライアントに送出し、ＩＰ設定情報の最終的な通知を行う（図１１の（４）参照）。なお、図１１は、従来技術を説明するための図である。
【０００６】
上述してきたように、クライアントとサーバとで構成される通信システムに、ＤＨＣＰを適用した場合には、クライアントとサーバとの間で、「Discover信号とOffer信号」、「Request信号とAck信号」という２種類の要求‐応答の対が交換される。このように、複数の要求および応答の対をクライアントとサーバとの間で交換する通信システムにおいて、複数のクライアントをサーバが収容している場合には、クライアントからの要求を一斉に受けてサーバが輻輳状態に陥ると、サーバの処理能力が低下する。その結果、クライアントとサーバとの間で、複数の要求および応答の対の交換に要する時間が増大してしまい、サービスを迅速に提供することができない。
【０００７】
このような問題に対して、例えば、特許文献１では、サーバが、輻輳の検出を契機として、ＭＡＣアドレスとＩＰアドレスとの対からなるリストを全クライアントに送出することで、迅速にサービスを提供する技術が提案されている。
【０００８】
【特許文献１】特開２００２−２３２４４７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記した特許文献１に提案の技術は、全クライアントに払い出すＩＰアドレスが固定的な場合には適用可能であるが、クライアントからの要求に応じて動的にＩＰアドレスを払い出す場合には適用できないという問題点があった。
【００１０】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、クライアントとサーバとで構成される通信システムにおいて、ＩＰアドレスを動的に払い出す場合においても、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供することが可能な通信システム、サーバ、通信方法、通信プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するため、本発明は、各クライアント装置がサーバに要求信号を送出し、要求信号に対する応答信号をサーバがクライアント装置にそれぞれ返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供する通信システムであって、前記サーバは、前記応答信号を送出可能な状態になっても、前記応答信号の送出を遅延させるように制御する応答送出制御手段を有する。
【発明の効果】
【００１２】
本発明によれば、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供できる。
【発明を実施するための最良の形態】
【００１３】
以下に添付図面を参照して、この発明に係る通信システム、サーバ、通信方法および通信プログラムの一実施形態を詳細に説明する。なお、以下の実施例１では、実施例１に係るサーバの概要および特徴、かかるサーバの構成および処理を順に説明し、実施例１による効果を説明する。
【実施例１】
【００１４】
［サーバの概要および特徴（実施例１）］
まず、図１を用いて、実施例１に係るサーバの概要および特徴を説明する。図１は、実施例１に係るサーバの概要および特徴を説明するための図である。
【００１５】
同図に示すように、実施例１に係るサーバは、複数のクライアント端末（１）〜（１０）を収容し、クライアント端末から要求信号を受け付けて、要求信号に対する応答信号を返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービス（ＩＰアドレス等を利用した通信サービス）を提供することを概要とする。
【００１６】
そして、実施例１に係るサーバは、応答信号を送出可能な状態になっても、応答信号の送出を遅延させるように制御する点に主たる特徴がある。この特徴により、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供できる。
【００１７】
以下、この主たる特徴について具体的に説明する。図１に示すように、各クライアント端末が一斉に起動し、例えば、０．１秒間隔で要求信号である「Discover信号」をサーバに送出して、ＩＰアドレスやサブネットマスクなどのＩＰ通信に必要な情報（ＩＰ設定情報）の候補を要求する。
【００１８】
実施例１に係るサーバは、各クライアント端末から受信した「Discover信号」を順次処理し、応答信号として生成した「Offer信号」が送出可能な状態になっても、一律、２秒遅延させてから各クライアント端末に返送する。
【００１９】
各クライアント端末は、サーバから「Offer信号」を受信すると、「Offer信号」に含まれるＩＰ設定情報の候補を確認して、受託できるものであれば直ちに「Request信号」をＤＨＣＰサーバに送出し、ＩＰ設定情報の確保を要求する。
【００２０】
実施例１に係るサーバは、各クライアント端末から受信した「Request信号」を順次処理し、応答信号として生成した「Ack信号」が送出可能な状態になっても、一律、２秒遅延させてから各クライアント端末に返送する。
【００２１】
各クライアント端末は、サーバから「Ack信号」を受信すると、「Ack信号」に含まれる確保済みのＩＰ設定情報を自身のネットワークインタフェースに設定し、通信サービスの利用を開始する。
【００２２】
このようなことから、実施例１に係るサーバは、上述した主たる特徴のように、応答信号を送出可能な状態になっても、応答信号の送出を遅延させるように制御するので、サーバからの応答がクライアント端末からの更なる要求を誘発することを原因として、サーバが輻輳状態に陥ることを抑制する。そして、サーバが輻輳状態に陥ることを抑制する結果、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供できる。
【００２３】
［サーバの構成（実施例１）］
次に、図２を用いて、実施例１に係るサーバの構成を説明する。図２は、実施例１に係るサーバの構成を示す図である。同図に示すように、実施例１に係るサーバ１００は、要求信号受信機能部１１０と、受信バッファ１２０と、要求信号処理機能部１３０と、送信バッファ１４０と、応答信号送信制御機能部１５０とを有する。
【００２４】
要求信号受信機能部１１０は、サーバ１００が収容するクライアント端末から、「Discover信号」や「Request信号」などの要求信号を受信する。具体的に説明すると、要求信号受信機能部１１０は、クライアント端末から要求信号を受信すると、現在時刻を信号の受信時刻として取得し、取得した受信時刻とともに、受信信号データを受信バッファ１２０に積み上げて、信号受信待ち状態で待機する。
【００２５】
受信バッファ１２０は、要求信号受信機能部１１０により積み上げられた受信信号データおよび受信時刻を保持する。例えば、要求信号処理機能部１３０による信号処理中に、要求信号受信機能部１１０がクライアント端末から受信した新たな要求信号データを保持しておくことができる。
【００２６】
要求信号処理機能部１３０は、要求信号受信機能部１１０がクライアント端末から受信した要求信号を処理して応答信号を作成する。具体的に説明すると、要求信号処理機能部１３０は、受信バッファ１２０から受信信号および受信時刻の取得を試みる。そして、受信信号および受信時刻を取得できた場合には、受信信号の種別が「Request信号」であるか否かを確認する。確認の結果、「Request信号」である場合には、この「Request信号」に紐づく「Discover信号」の受信後に既に決定してあったＩＰアドレスやサブネットマスクなどのＩＰ設定情報を取得し、取得したＩＰ設定情報を元にして「Ack信号」を生成する。そして、受信バッファ１２０から取得した受信時刻とともに、生成した「Ack信号」を送信バッファ１４０に積み上げる。そして、要求信号処理機能部１３０は、受信バッファ１２０から次の受信信号の取得を試みる。
【００２７】
一方、要求信号処理機能部１３０は、受信バッファ１２０から取得した受信信号の種別が「Request信号」であるか否かを確認した結果、「Request信号」でない場合には、「Discover信号」であるか否かを確認する。確認の結果、「Discover信号」である場合には、「Discover信号」の送信元であるクライアント端末に応じて、払い出し候補のＩＰ設定情報を決定する。払い出し候補のＩＰ設定情報を決定した後、要求信号処理機能部１３０は、払い出し候補として決定したＩＰ設定情報を元にして「Offer信号」を生成する。そして、受信バッファ１２０から取得した受信時刻とともに、生成した「Offer信号」を送信バッファ１４０に積み上げる。そして、要求信号処理機能部１３０は、受信バッファ１２０から次の受信信号の取得を試みる。
【００２８】
なお、ＩＰ設定情報の決定ロジックとしては、サーバがあらかじめ内部的に備えるＤＢ等にクライアントＩＤと対応付けてＩＰ設定情報を保持しておき、クライアントＩＤに対応付けられたＩＰ設定情報を払い出し候補として決定する方法を採用しても良い。あるいは、サーバがあらかじめ内部的に備えるＤＢ等に、払い出し可能な複数のＩＰ設定情報を払い出し状況とともに保持しておき、未だ払い出されていないＩＰ設定情報から払い出し候補として決定する方法を採用しても良い。
【００２９】
また、要求信号処理機能部１３０は、受信バッファ１２０から取得した受信信号の種別が「Discover信号」であるか否かを確認した結果、「Discover信号」でもない場合には、不正信号とみなして信号を破棄し、受信バッファ１２０から次の受信信号の取得を試みる。
【００３０】
送信バッファ１４０は、応答信号を送出するタイミングとなるまで、要求信号処理機能部１３０により積み上げられた応答信号データおよび受信時刻を保持する。
【００３１】
応答信号送信制御機能部１５０は、応答信号を送出可能な状態になっても、応答信号を送出するタイミングとなるまで、応答信号の送出を遅延させるように制御する。具体的に説明すると、応答信号送信制御機能部１５０は、送信バッファ１４０から応答信号および受信時刻の取得を試みる。そして、応答信号および受信時刻を取得できた場合には、現在時刻を取得し、取得した現在時刻が受信時刻から２秒以上経過しているか否かを判定する。判定の結果、２秒以上経過している場合には、応答信号の送出タイミングに到達しているものとして、送信バッファ１４０から取得した応答信号をクライアント端末に返送する。そして、応答信号送信制御機能部１５０は、送信バッファ１４０から次の応答信号の取得を試みる。
【００３２】
一方、応答信号送信制御機能部１５０は、現在時刻が受信時刻から２秒以上経過しているか否かを判定した結果、２秒以上経過していない場合には、応答信号と受信時刻を送信バッファ１４０の元の位置に戻す。そして、応答信号送信制御機能部１５０は、送信バッファ１４０から次の応答信号の取得を試みる。なお、応答信号送信制御機能部１５０は、特許請求の範囲に記載の「応答送出制御手段」に対応する。
【００３３】
［サーバによる処理（実施例１）］
続いて、図３〜図５を用いて、実施例１に係るサーバによる処理の流れを説明する。図３〜図５は、実施例１に係るサーバによる処理の流れを示す図である。
【００３４】
［要求信号受信処理］
まず、図３を参照しつつ、要求信号受信処理の流れを説明する。同図に示すように、要求信号受信機能部１１０は、クライアント端末から送出される要求信号の受信待ち状態で待機し（ステップＳ１）、要求信号を受信すると（ステップＳ１肯定）、現在時刻を信号の受信時刻として取得する（ステップＳ２）。そして、要求信号受信機能部１１０は、取得した受信時刻とともに、受信信号データを受信バッファ１２０に積み上げて（ステップＳ３）、再び信号受信待ち状態に戻る。
【００３５】
［要求信号処理］
次に、図４を参照しつつ、要求信号処理の流れを説明する。同図に示すように、要求信号処理機能部１３０は、受信バッファ１２０から受信信号および受信時刻の取得を試みる（ステップＳ１）。そして、受信信号および受信時刻を取得できた場合には（ステップＳ１肯定）、受信信号の種別が「Request信号」であるか否かを確認する（ステップＳ２）。
【００３６】
要求信号処理機能部１３０は、確認の結果、「Request信号」である場合には（ステップＳ２肯定）、この「Request信号」に紐づく「Discover信号」の受信後に既に決定してあったＩＰアドレスやサブネットマスクなどのＩＰ設定情報を取得し（ステップＳ３）、取得したＩＰ設定情報を元にして「Ack信号」を生成する（ステップＳ４）。そして、受信バッファ１２０から取得した受信時刻とともに、生成した「Ack信号」を送信バッファ１４０に積み上げる（ステップＳ５）。そして、要求信号処理機能部１３０は、上述したステップＳ１に戻って、受信バッファ１２０から次の受信信号の取得を試みる。
【００３７】
ここで、ステップＳ２の説明に戻ると、要求信号処理機能部１３０は、受信バッファ１２０から取得した受信信号の種別が「Request信号」であるか否かを確認した結果、「Request信号」でない場合には（ステップＳ２否定）、「Discover信号」であるか否かを確認する（ステップＳ６）。確認の結果、「Discover信号」である場合には（ステップＳ６肯定）、「Discover信号」の送信元であるクライアント端末に応じて、払い出し候補のＩＰ設定情報を決定する（ステップＳ７）。払い出し候補のＩＰ設定情報を決定した後、要求信号処理機能部１３０は、払い出し候補として決定したＩＰ設定情報を元にして「Offer信号」を生成する（ステップＳ８）。そして、受信バッファ１２０から取得した受信時刻とともに、生成した「Offer信号」を送信バッファ１４０に積み上げる（ステップＳ９）。そして、要求信号処理機能部１３０は、上述したステップＳ１に戻り、受信バッファ１２０から次の受信信号の取得を試みる。
【００３８】
ここで、ステップＳ６の説明に戻ると、要求信号処理機能部１３０は、受信バッファ１２０から取得した受信信号の種別が「Discover信号」であるか否かを確認した結果、「Discover信号」でもない場合には（ステップＳ６否定）、不正信号とみなして信号を破棄し、上述したステップＳ１に戻り、受信バッファ１２０から次の受信信号の取得を試みる。
【００３９】
［応答信号送信制御処理］
次に、図５を参照しつつ、応答信号送信制御処理の流れを説明する。同図に示すように、応答信号送信制御機能部１５０は、送信バッファ１４０から応答信号および受信時刻の取得を試みる（ステップＳ１）。そして、応答信号および受信時刻を取得できた場合には（ステップＳ１肯定）、現在時刻を取得し（ステップＳ２）、取得した現在時刻が受信時刻から２秒以上経過しているか否かを判定する（ステップＳ３）。判定の結果、２秒以上経過している場合には（ステップＳ３肯定）、応答信号の送出タイミングに到達しているものとして、送信バッファ１４０から取得した応答信号をクライアント端末に送出する（ステップＳ４）。そして、応答信号送信制御機能部１５０は、上述したステップＳ１に戻って、送信バッファ１４０から次の応答信号の取得を試みる。
【００４０】
ここで、ステップＳ３の説明に戻ると、応答信号送信制御機能部１５０は、現在時刻が受信時刻から２秒以上経過しているか否かを判定した結果、２秒以上経過していない場合には（ステップＳ３否定）、応答信号と受信時刻を送信バッファ１４０の元の位置に戻す（ステップＳ５）。そして、応答信号送信制御機能部１５０は、上述したステップＳ１に戻って、送信バッファ１４０から次の応答信号の取得を試みる。
【００４１】
［実施例１による効果］
上述してきたように、実施例１によれば、サーバ１００は、応答信号を送出可能な状態になっても、応答信号の送出を遅延させるように制御するので、サーバからの応答がクライアント端末からの更なる要求を誘発することを原因として、サーバが輻輳状態に陥ることを抑制する。そして、サーバが輻輳状態に陥ることを抑制する結果、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供できる。
【００４２】
すなわち、実施例１によれば、サーバ１００は、応答信号を送出可能な状態になっても、直ちに、クライアント端末に応答信号を返送するのではなく、一定の遅延時間（例えば、２秒）が経過した後、応答信号を返送する。これにより、クライアント端末から送出されたDiscover信号が集中する時間帯に、Request信号が到達してしまうことを防止して、サーバ１００の処理能力をDiscover信号の処理に集中させることができる。したがって、クライアント端末からの要求を逐次処理しながら動的にサービスの内容を決定する処理を効率的に実施可能である。
【００４３】
また、上記の実施例１では、応答信号の送出を遅延させるために、一定の遅延時間を持たせているが、これに限定されるものではなく、遅延時間を要求信号ごとに個別、かつランダムに決定することもできる。これにより、例えば、Discover信号のような第１の信号の到達が短期間に集中したとしても、Request信号のような第２の信号の到達時間を分散させて、トラヒック量を平準化できる。
【００４４】
また、上記の実施例１において、クライアント端末（サービス加入者）を識別するクライアントＩＤに対応付けて、応答信号を優先的に返送すべきことを示す優先度情報を予め設定しておく。要求信号の送信元であるクライアント端末（クライアントＩＤ）に優先度情報が設定されている場合には、遅延時間を短めに設定し、優先度情報が設定されていない場合には、遅延時間を長めに設定するようにして、応答信号の返送を制御することもできる。これにより、クライアント端末（サービス加入者）ごとに個別具体的なサービス提供も可能である。
【実施例２】
【００４５】
上記の実施例１では、応答信号の送出を遅延させるために、一定の遅延時間を持たせる場合を説明した。しかしながら、これに限定されるものではなく、サーバ１００の輻輳状況に応じて、応答信号の送出を決定するようにしてもよい。そこで、以下の実施例２では、実施例２に係るサーバの構成および処理を順に説明した後に、実施例２による効果を説明する。
【００４６】
［サーバの構成（実施例２）］
図６を用いて、実施例２に係るサーバの構成を説明する。図６は、実施例２に係るサーバの構成を示す図である。同図に示すように、実施例２に係るサーバは、実施例１に係るサーバと基本的には同様の構成であるが、以下に説明する点が異なる。
【００４７】
すなわち、要求信号受信機能部１１０は、受信した要求信号の信号カウント数を記録するとともに、カウント開始時刻を記録する。具体的に説明すると、処理開始時に、カウント開始時刻として現在時刻を設定するとともに、信号カウント数を０に設定する初期化処理を実行して、クライアント端末からの要求信号の受信待機状態に入る。
【００４８】
初期化処理完了後、要求信号受信機能部１１０は、要求信号を受信すると、現在時刻を取得して、現在時刻がカウント開示時刻から１０秒経過しているか否かを判定する。判定の結果、現在時刻がカウント開示時刻から１０秒経過している場合には、現在時刻とカウント開始時刻との差を１０秒で割った余りを計算する。そして、算出された余りを現在時刻から減算した値をカウント開始時刻として更新するとともに、信号カウント数を０に初期化する。
【００４９】
例えば、要求信号受信機能部１１０は、カウント開始時刻が「１０：００分  １０．００５秒」であり、現在時刻が「１０：００分  ３５．９００秒」であった場合、現在時刻とカウント開始時刻との差である「２５．８９５秒」を１０秒で割った余りを計算する。そして、算出された余りである「５．９８５秒」を現在時刻から減算した値である「１０：００分  ３０．００５秒」をカウント開始時刻として更新するとともに、信号カウント数を０に初期化する。
【００５０】
そして、要求信号受信機能部１１０は、カウント開始時刻の更新および信号カウント数の初期化が完了した場合、もしくは現在時刻がカウント開示時刻から１０秒経過していなかった場合には、信号カウント数を１増加させた後、受信信号を受信バッファに積み上げ、クライアント端末からの要求信号の受信待機状態に戻る。
【００５１】
要求信号処理機能部１３０は、生成した「Offer信号」あるいは「Ack信号」のみを送信バッファ１４０に積み上げる。
【００５２】
応答信号送信制御機能部１５０は、要求信号受信機能部１１０からカウント開始時刻および信号カウント数を取得した後、現在時刻を取得するとともに、予め設定されている輻輳閾値を取得する。そして、信号カウント数を現在時刻とカウント開始時刻との差で除算した値が輻輳閾値を超えているか否かを判定する。判定の結果、輻輳閾値を超えている場合には、サーバ１００が輻輳状態にあると判断し、続いて、受信バッファ１２０の空き容量が総容量の半分以上あるか否かを確認する。
【００５３】
応答信号送信制御機能部１５０は、確認の結果、受信バッファ１２０の空き容量が総容量の半分以上ある場合には、送信バッファ１４０から応答信号の取得を試みる。応答信号を取得できた場合には、クライアント端末に返送する。クライアント端末に応答信号送出後、あるいは応答信号の取得に失敗後、応答信号送信制御機能部１５０は、処理開始状態に戻る。
【００５４】
また、応答信号送信制御機能部１５０は、受信バッファ１２０の空き容量が総容量の半分以上あるか否かを確認した結果、空き容量が総容量の半分以上ない場合には、そのまま処理開始状態に戻る。
【００５５】
また、応答信号送信制御機能部１５０は、信号カウント数を現在時刻とカウント開始時刻との差で除算した値が輻輳閾値を超えていない場合には、サーバが輻輳状態にないものと判断して、送信バッファ１４０から受信信号の取得を試みる。受信信号を取得できた場合には、クライアント端末に返送する。クライアント端末に応答信号送出後、あるいは受信信号の取得に失敗後、応答信号送信制御機能部１５０は、処理開始状態に戻る。
【００５６】
［サーバによる処理（実施例２）］
続いて、図７〜図９を用いて、実施例２に係るサーバによる処理の流れを説明する。図７〜図９は、実施例２に係るサーバによる処理の流れを示す図である。
【００５７】
［要求信号受信処理］
まず、図７を参照しつつ、要求信号受信処理の流れを説明する。同図に示すように、要求信号受信機能部１１０は、処理開始時に、カウント開始時刻として現在時刻を設定するとともに（ステップＳ１）、信号カウント数を０に設定する初期化処理を実行して（ステップＳ２）、クライアント端末からの要求信号の受信待機状態に入る。
【００５８】
初期化処理完了後、要求信号受信機能部１１０は、クライアント端末からの要求信号受信を待機し（ステップＳ３）、要求信号を受信すると（ステップＳ３肯定）、現在時刻を取得して（ステップＳ４）、現在時刻がカウント開示時刻から１０秒経過しているか否かを判定する（ステップＳ５）。判定の結果、現在時刻がカウント開示時刻から１０秒経過している場合には（ステップＳ５肯定）、現在時刻とカウント開始時刻との差を１０秒で割った余りを計算し、算出された余りを現在時刻から減算した値をカウント開始時刻として更新するとともに、信号カウント数を０に初期化する（ステップＳ６）。
【００５９】
そして、要求信号受信機能部１１０は、カウント開始時刻の更新および信号カウント数の初期化が完了すると、信号カウント数を１増加させた後（ステップＳ７）、受信信号を受信バッファに積み上げ（ステップＳ８）、クライアント端末からの要求信号の受信待機状態に戻る（ステップＳ３参照）。
【００６０】
ここで、ステップＳ５の説明に戻ると、要求信号受信機能部１１０は、現在時刻がカウント開示時刻から１０秒経過しているか否かを判定した結果、現在時刻がカウント開示時刻から１０秒経過していなかった場合には（ステップＳ５否定）、上述したステップＳ７およびステップＳ８と同様にして、信号カウント数を１増加させた後、受信信号を受信バッファに積み上げ、クライアント端末からの要求信号の受信待機状態に戻る。
【００６１】
［要求信号処理］
次に、図８を参照しつつ、要求信号処理の流れを説明する。実施例２に係る要求信号処理は、上記の実施例１で説明した要求信号処理（図４参照）とは、以下に説明する点が異なる。すなわち、要求信号処理機能部１３０は、受信バッファ１２０から受信信号のみを取得し、生成した「Offer信号」あるいは「Ack信号」のみを送信バッファ１４０に積み上げる（ステップＳ１、ステップＳ５、ステップＳ８参照）。
【００６２】
［応答信号送信制御処理］
次に、図９を用いて、応答信号送信制御処理の流れを説明する。同図に示すように、応答信号送信制御機能部１５０は、要求信号受信機能部１１０からカウント開始時刻および信号カウント数を取得した後（ステップＳ１）、現在時刻を取得するとともに（ステップＳ２）、予め設定されている輻輳閾値を取得する（ステップＳ３）。そして、信号カウント数を現在時刻とカウント開始時刻との差で除算した値が輻輳閾値を超えているか否かを判定する（ステップＳ４）。判定の結果、輻輳閾値を超えている場合には（ステップＳ４肯定）、サーバ１００が輻輳状態にあると判断し、続いて、受信バッファ１２０の空き容量が総容量の半分以上あるか否かを確認する（ステップＳ５）。
【００６３】
応答信号送信制御機能部１５０は、確認の結果、受信バッファ１２０の空き容量が総容量の半分以上ある場合には（ステップＳ５肯定）、送信バッファ１４０から受信信号の取得を試みる（ステップＳ６）。受信信号を取得できた場合には（ステップＳ６肯定）、クライアント端末に返送し（ステップＳ７）、処理開始状態に戻る（ステップＳ１参照）。一方、受信信号を取得できなかった場合にも（ステップＳ６否定）、同様に、そのまま処理開始状態に戻る。
【００６４】
ここで、ステップＳ５の説明に戻ると、応答信号送信制御機能部１５０は、受信バッファ１２０の空き容量が総容量の半分以上あるか否かを確認した結果、空き容量が総容量の半分以上ない場合には（ステップＳ５否定）、そのまま処理開始状態に戻る。
【００６５】
また、ステップＳ４の説明に戻ると、応答信号送信制御機能部１５０は、信号カウント数を現在時刻とカウント開始時刻との差で除算した値が輻輳閾値を超えているか否かを判定した結果、輻輳閾値を超えていない場合には（ステップＳ４否定）、サーバが輻輳状態にないものと判断して、上述したステップＳ６と同様に、送信バッファ１４０から受信信号の取得を試みる。受信信号を取得できた場合には、クライアント端末に返送する。クライアント端末に応答信号送出後、あるいは受信信号の取得に失敗後、応答信号送信制御機能部１５０は、処理開始状態に戻る。
【００６６】
［実施例２による効果］
上述してきたように、実施例２によれば、サーバ１００の輻輳状況に応じて、応答信号の送出を決定するので、クライアント端末からの要求を逐次処理しながら動的にサービスの内容を決定する処理を効率的に実施しつつ、クライアントからの要求量を平準化できる。このようなことから、実施例２によれば、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供できる。
【００６７】
すなわち、実施例２によれば、サーバ１００が輻輳状態にない場合、あるいは輻輳状態であるが受信バッファ１２０の容量に余裕がある場合にのみ、クライアントへの応答を行うように制御する。したがって、サーバ１００の処理能力に余裕が出てくるタイミングでRequest信号のような第２の信号の各クライアント端末から到達する時間を分散させて、クライアントからの要求を効率的に処理するとともに、トラヒック量を平準化できる。
【００６８】
また、上記の実施例２において、クライアント端末から、単位時間当たりに一定量の要求を受信していることを条件に、応答を遅延させるように制御してもよい。これにより、上述してきた制御と同様に、クライアントからの要求を効率的に処理するとともに、トラヒック量を平準化でき、迅速なサービスをクライアントに提供できる。
【００６９】
また、上記の実施例２では、受信バッファ１２０の空き状況に応じて、応答信号を送出するタイミングを計る場合を説明したが、これに限定されるものではなく、単位時間当たりの受信信号数に応じて応答信号の送出タイミングを計るようにしてもよい。例えば、単位時間当たりの受信信号数が所定の閾値を超えていれば、遅延時間を長く持たせ、単位時間当たりの受信信号数が所定の閾値を下回っていれば、遅延時間を短くする。
【００７０】
また、上記の実施例２では、サーバの輻輳状態および受信バッファのデータ蓄積状況の双方を考慮して、応答信号の送出を制御する場合を説明したが、これに限定されるものではなく、サーバの輻輳状態、受信バッファのデータ蓄積状況のいずれか一方を考慮して、応答信号の送出を制御するようにしてもよい。
【００７１】
また、上記の実施例２において、サーバの輻輳状態および受信バッファのデータ蓄積状況の双方を考慮した上で、さらに、上記の実施例１に記載したように、個別の遅延時間を設けたり、クライアント端末（サービス加入者）ごとに優先的に返送すべきことを示す優先度情報を設けたり、単位時間あたりの受信信号数に応じた遅延時間を設定したりして、応答信号の送出を制御することもできる。すなわち、サーバの輻輳状況の判定、受信バッファの蓄積状況の判定、任意な遅延時間の設定、優先度情報の設定、単位時間あたりの受信信号数に応じた遅延時間の設定を任意に組み合わせて、応答信号の送出を制御することもできる。
【実施例３】
【００７２】
さて、これまで本発明に係るサーバの一実施形態として、実施例１および２を説明してきたが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施形態について説明する。
【００７３】
（１）装置構成等
上記の実施例１または２において図示したサーバ１００（図２または図６参照）の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、サーバ１００の分散・統合の具体的形態は図示のものに限られず、例えば、要求信号受信機能部１１０と、要求信号処理機能部１３０と、応答信号送信制御機能部１５０とを統合してもよい。このように、サーバ１００が有する各構成要素の全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、サーバ１００にて行なわれる各処理機能は（図３〜図５、あるいは図７〜図９等参照）、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００７４】
（２）応答送出制御プログラム
また、上記の実施例１あるいは２で説明したサーバ１００の各種の処理（例えば、図３〜図５、あるいは図７〜図９等参照）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、図１０を用いて、上記の実施例１あるいは２と同様の機能を有する応答送出制御プログラムを実行するコンピュータの一例を説明する。図１０は、応答送出制御プログラムを実行するコンピュータを示す図である。
【００７５】
同図に示すように、コンピュータ２００は、通信制御部２１０、ＨＤＤ２２０、ＲＡＭ２３０およびＣＰＵ２４０をバス３００で接続して構成される。
【００７６】
ここで、通信制御部２１０は、クライアント端末との間でやり取りされる各種信号に関する通信を制御する。ＨＤＤ２２０は、ＣＰＵ２４０による各種処理の実行に必要な情報を記憶する。ＲＡＭ２３０は、各種情報を一時的に記憶する。ＣＰＵ２４０は、各種演算処理を実行する。
【００７７】
そして、ＨＤＤ２２０には、図１０に示すように、上記の実施例１あるいは２に示したサーバ１００が有する各機能部と同様の機能を発揮する応答送出制御プログラム２２１と、応答送出制御データ２２２とがあらかじめ記憶されている。なお、この応答送出制御プログラム２２１を適宜分散させて、ネットワークを介して通信可能に接続された他のコンピュータの記憶部に記憶させておくこともできる。
【００７８】
そして、ＣＰＵ２４０が、この応答送出制御プログラム２２１をＨＤＤ２２０から読み出してＲＡＭ２３０に展開することにより、図１０に示すように、応答送出制御プログラム２２１は応答送出制御プロセス２３１として機能するようになる。すなわち、応答送出制御プロセス２３１は、応答送出制御データ２２２等をＨＤＤ２２０から読み出して、ＲＡＭ２３０において自身に割り当てられた領域に展開し、この展開したデータ等に基づいて各種処理を実行する。なお、応答送出制御プロセス２３１は、上記の実施例１あるいは２で説明したサーバ１００の処理機能部（要求信号受信機能部１１０、要求信号処理機能部１３０、および応答信号送信制御機能部１５０等）において実行される処理にそれぞれ対応する。
【００７９】
なお、上記した応答送出制御プログラム２２１については、必ずしも最初からＨＤＤ２２０に記憶させておく必要はなく、例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ２００に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ２００がこれらから各プログラムを読み出して実行するようにしてもよい。
【００８０】
（３）応答送出制御方法
上記の実施例１あるいは２で説明したサーバ１００により、以下のような応答送出制御方法が実現される。すなわち、応答信号を送出可能な状態になっても、応答信号の送出を遅延させるように制御する応答送出制御ステップ（例えば、図５のステップＳ３参照）を含んだ応答送出制御方法が実現される。
【産業上の利用可能性】
【００８１】
以上のように、本発明に係る通信システム、サーバ、応答送出制御方法および応答送出制御プログラムは、クライアント装置がサーバに要求信号を送出し、要求信号に対する応答信号をサーバがクライアント装置に返送する処理を一単位とした一連の処理を完結することで、クライアント装置にサービスを提供する場合に有用であり、特に、ＩＰアドレスを動的に払い出す場合においても、サーバ側の処理能力を効率的に利用して、迅速なサービスをクライアントに提供することに適する。
【図面の簡単な説明】
【００８２】
【図１】実施例１に係るサーバの概要および特徴を説明するための図である。
【図２】実施例１に係るサーバの構成を示す図である。
【図３】実施例１に係るサーバによる処理の流れを示す図である。
【図４】実施例１に係るサーバによる処理の流れを示す図である。
【図５】実施例１に係るサーバによる処理の流れを示す図である。
【図６】実施例１に係るサーバの構成を示す図である。
【図７】実施例２に係るサーバによる処理の流れを示す図である。
【図８】実施例２に係るサーバによる処理の流れを示す図である。
【図９】実施例２に係るサーバによる処理の流れを示す図である。
【図１０】応答送出制御プログラムを実行するコンピュータを示す図である。
【図１１】従来技術を説明するための図である。
【符号の説明】
【００８３】
１００  サーバ
１１０  要求信号受信機能部
１２０  受信バッファ
１３０  要求信号処理機能部
１４０  送信バッファ
１５０  応答信号送信制御機能部
２００  コンピュータ
２１０  通信制御部
２２０  ＨＤＤ（Hard Disk Drive）
２２１  応答送出制御プログラム
２２２  応答送出制御データ
２３０  ＲＡＭ（Random Access Memory）
２３１  応答送出制御プロセス
２４０  ＣＰＵ（Central Processing Unit）
３００  バス
【図１】
2010154096.tif 000003
【図２】
2010154096.tif 000004
【図３】
2010154096.tif 000005
【図４】
2010154096.tif 000006
【図５】
2010154096.tif 000007
【図６】
2010154096.tif 000008
【図７】
2010154096.tif 000009
【図８】
2010154096.tif 000010
【図９】
2010154096.tif 000011
【図１０】
2010154096.tif 000012
【図１１】
2010154096.tif 000013