自立型アクセス集中緩和システム
【課題】エンドサーバのサービス時間に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを正確に制御できる自立型アクセス集中緩和システムを提供する
【解決手段】エンドサーバに、アクセスパス要求に応答して待機時間を求めてアクセスパス応答として返信するアクセスパス処理部と、サービス要求に応答してサービスを提供するサービス提供部と、ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを設け、前記プロキシ部に、要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを設け、前記アクセスパス処理部に、アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、待機数およびサービス時間に基づいて待機時間を算出する手段とを設けた。
【解決手段】エンドサーバに、アクセスパス要求に応答して待機時間を求めてアクセスパス応答として返信するアクセスパス処理部と、サービス要求に応答してサービスを提供するサービス提供部と、ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを設け、前記プロキシ部に、要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを設け、前記アクセスパス処理部に、アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、待機数およびサービス時間に基づいて待機時間を算出する手段とを設けた。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信することでエンドサーバへのアクセス集中を緩和するシステムに関する。
【背景技術】
【０００２】
災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるエンドサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。これは同サービスを利用するユーザの満足度を低下させると共に、リクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。
【０００３】
イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には、１０倍から１００倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。
【０００４】
一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。
【０００５】
特許文献１には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。
【０００６】
ここでは、サービスを提供するエンドサーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
【０００７】
しかしながら、特許文献１では一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。
【０００８】
このような技術課題に対して、本発明の発明者等は特許文献２および非特許文献１のように、ユーザにサービスを提供するエンドサーバとは別に、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するアクセスサーバを設けることにより、サービス要求のアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提案している。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００７−２１９６５０号公報
【特許文献２】特開２００９−４３０６９号公報
【非特許文献】
【００１０】
【非特許文献１】「整理券発行機能を用いたアクセス制御システムの提案」，信学技法 vol.1 108 No.218, p81-p86.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
エンドサーバにおいてユーザ端末からのサービス要求を滞りなく処理するためには、エンドサーバに入力されるサービス要求の周期とエンドサーバが一つのサービス要求を処理するのに要する時間、すなわちサービス時間TAT(Turn Around Time)とが一致していることが望ましい。そこで、上記した特許文献２および非特許文献１に開示された技術では、各エンドサーバのサービス処理レートを予め統計的に推定し、この推定値に従って各サービス要求が各エンドサーバで処理されるという前提で各ユーザ端末のアクセスタイミングを決定していた。
【００１２】
しかしながら、例えばコンテンツ配信のサービス要求に応答してエンドサーバがユーザ端末へ動画などのコンテンツを配信するサービスでは、エンドサーバのサービス時間がユーザ端末におけるコンテンツのダウンロード速度に依存する。そして、ユーザ端末のダウンロード速度は、アクセス回線の容量や接続方式（有線LANまたは有線LANなど）に依存するので、提供するサービスが同一であってもエンドサーバのサービス時間が一定であるとは限らない。
【００１３】
したがって、上記の従来技術では、エンドサーバのサービス時間に関する推定値と実績値とに乖離が生じる場合があり、これが大きくなると、推定値＜実績値であればエンドサーバに輻輳が生じ、その逆に推定値＞実績値であればエンドサーバの運用効率が低下してしまう。
【００１４】
本発明の目的は、上記した従来技術の課題を解決し、エンドサーバのサービス時間に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを正確に制御することでアクセス集中を緩和する自立型アクセス集中緩和システムを提供することにある。
【課題を解決するための手段】
【００１５】
上記の目的を達成するために、本発明は、ユーザ端末がエンドサーバへアクセスパス要求を送信してサービス要求のタイミングを問い合わせ、エンドサーバから通知された待機時間の経過後にエンドサーバへサービス要求を送信する自立型アクセス集中緩和システムにおいて、以下のような手段を講じた点に特徴がある。
【００１６】
(1)エンドサーバに、アクセスパス要求に応答して待機時間を求め、これをアクセスパス応答に記述して返信するアクセスパス処理部と、サービス要求に応答してサービスを提供するサービス提供部と、ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを設けた。
【００１７】
(2)前記プロキシ部に、要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを設けた。
【００１８】
(3)前記アクセスパス処理部に、アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、待機数およびサービス時間に基づいて待機時間を算出する手段と、待機時間を含むアクセスパス応答を返信する手段とを設けた。
【発明の効果】
【００１９】
本発明によれば、以下のような効果が達成される。
(1)アクセスパスサーバの機能をエンドサーバ上に設け、ユーザ端末とエンドサーバとの通信をエンドサーバ上で監視してサービス時間を計測し、これに基づいて各ユーザ端末に許可するエンドサーバへのアクセスタイミングを設定するようにしたので、各エンドサーバにおいて自律的にアクセスタイミングを決定できる。したがって、能力の異なる多数のエンドサーバが収容されるネットワークでも、エンドサーバごとにアクセス数を最適化できるようになる。
(2)エンドサーバが一つのサービス要求を処理するのに要するサービス時間として、統計的に算出された推定値ではなく実績値を採用できるので、常に正確なサービス時間に基づいてアクセスタイミングを決定できるようになる。
(3)アクセスパスサーバをネットワーク上に配置する必要がないので、ネットワーク障害の影響を最小限に抑えられる。
(4)アクセスパスサーバの廃止によりサーバ間の通信を削減できるので、情報の漏洩や改竄に対するセキュリティが向上する。
(5)アクセスパスサーバの廃止によりサーバ数を削減できるので、ネットワーク構成の簡略化による信頼性の向上が期待できる。
【図面の簡単な説明】
【００２０】
【図１】本発明が適用されるネットワークの構成を示したブロック図である。
【図２】エンドサーバの構成を示したブロック図である。
【図３】要求管理部の一例を示したブロック図である。
【図４】エントリをみなし終了と判定する方法の一例を示した図である。
【図５】サービス開始時刻およびサービス終了時刻をSYN/FINパケットの監視結果に基づいて推定する方法を模式的に表現した図である。
【図６】サービス時間をHTTP METHODの監視結果に基づいて推定する方法を模式的に表現した図である。
【図７】サービス時間をHTTPメッセージボディの監視結果に基づいて推定する方法を模式的に表現した図である。
【図８】TCPセッションの構成を示した図である。
【図９】ユーザ端末の動作を示したフローチャートである。
【図１０】エンドサーバの動作を示したフローチャートである。
【発明を実施するための形態】
【００２１】
以下、図面を参照して本発明の実施形態について詳細に説明する。 図１は、本発明が適用されるネットワークの構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツ配信のサービスを要求する場合を例にして説明する。
【００２２】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは、基地局APを経由して携帯電話網あるいはインターネット等のIPネットワークNWに接続されている。また、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESj（jはエンドサーバ識別子）も前記IPネットワークNWに接続されている。
【００２３】
前記各エンドサーバESjは、各ユーザ端末MNにサービス要求を許可するタイミングを事前に決定して各ユーザ端末MNへ通知する機能を備え、ユーザ端末MNからコンテンツの識別情報等を含むアクセスパス要求のメッセージを受信すると、自身の能力や状況に基づいてアクセスタイミングを決定し、これを要求元のユーザ端末MNへ通知する。ユーザ端末MNは、通知されたアクセスタイミングを待ってエンドサーバESjへ改めてサービス要求を送信し、当該エンドサーバESjからコンテンツの配信サービスを受ける。
【００２４】
図２は、前記エンドサーバESの主要部の構成を示したブロック図であり、ユーザ端末MNから受信したアクセスパス要求を処理してアクセスパス応答を返信するアクセスパス処理部１と、ユーザ端末MNから受信したサービス要求に応答してサービスを提供するエンドサーバ本来の機能を実現するサービス提供部２と、ユーザ端末MNと前記サービス提供部２との間に介在してサービス要求およびその応答を中継するプロキシ部３と、ユーザ端末MNからエンドサーバESへのアクセスを、URLに基づいてアクセスパス処理部１またはプロキシ部３へ振り分ける振分部４とを主要な構成としている。
【００２５】
前記アクセスパス処理部１は、ユーザ端末MNから送信されたアクセスパス要求を受信するアクセスパス要求受信部１１と、受信したアクセスパス要求の数および終了したサービスの数に基づいて、未処理の要求数（未処理数）Rを管理する要求管理部１２と、エンドサーバESに同時接続しているユーザ端末MNの数Mをプロキシ部３から取得する同時接続数取得部１３と、サービス提供部２が一つのサービスを提供するのに要するサービス時間TATをプロキシ部３から取得するサービス時間取得部１４と、前記未処理数R、同時接続数Mおよびサービス時間TATに基づいて、各サービス要求のアクセスタイミングを計算するアクセスタイミング計算部１５と、前記アクセスタイミングの記述されたアクセスパス応答を生成するアクセスパス応答生成部１６と、前記アクセスパス応答を要求元のユーザ端末MNへ返信するアクセスパス応答返信部１７とを具備している。
【００２６】
プロキシ部３は、ユーザ端末MNから送信されたサービス要求を受信してサービス提供部２へ転送するサービス要求転送部３１と、このサービス要求に応答してサービス提供部２から提供されるサービスをユーザ端末MNへ転送するサービス転送部３２と、ユーザ端末MNの同時接続数Mを取得する同時接続数取得部３３と、取得した同時接続数Mをアクセスパス処理部１へ通知する同時接続数通知部３４と、ユーザ端末MNとエンドサーバESとの通信セッションを監視してサービス時間TATを取得するサービス時間取得部３５と、取得したサービス時間TATをアクセスパス処理部１へ通知するサービス時間通知部３６と、サービス提供部２における各サービスの終了タイミングを検知するサービス終了検知部３７と、検知されたサービス終了をアクセスパス処理部１へ通知するサービス終了通知部３８とを具備している。
【００２７】
図３は、前記要求管理部１２の一例を示したブロック図であり、受信した全てのアクセスパス要求を、その受付時刻、アクセスタイミングまでの待機時間WT、サービスの提供が完了するとセットされる終了フラグ、およびアクセスパス要求を一意に識別できる識別情報（アドレス、ポート番号、シーケンス番号など）を紐付けて管理する管理テーブル１２１と、アクセスパス要求の受信が通知されるごとに、管理テーブル１２１に当該アクセスパス要求のエントリを追加し、その受付時刻および識別情報を記述するエントリ追加部１２２と、アクセスタイミングまでの待機時間WTが通知されるごとに、これを対応するエントリに記述する待機時間登録部１２３と、サービス終了が通知されるごとに、対応するエントリの終了フラグをセットすると共に、所定のタイミングでエントリ自身を抹消するエントリ抹消部１２４とを具備している。
【００２８】
前記エントリ抹消部１２４はさらに、図４に模式的に示したように、アクセスパス要求の受付時刻からの経過時間が待機時間WTとサービス時間TATとの和に更に余裕時間αを加えた時間よりも長くなっているエントリについても、何らかの原因でサービスが放棄あるいは諦められたものとみなして終了フラグをセットする。
【００２９】
図５，６，７は、前記プロキシ部３のサービス時間取得部３５によるサービス時間TATの算出方法を模式的に表現した図であり、サービス要求およびサービス応答がTCPセッションを利用して行われる場合、SYN/FINパケット、HTTP METHOD、HTTPメッセージボディあるいはHTTP/1.1レンジリクエストを監視することでサービス時間TATが求められる。
【００３０】
図５は、サービス開始時刻およびサービス終了時刻をSYN/FINパケットの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３１】
TCPセッションは、図８(a)に示したように一つのセッションから構成されるとは限らず、同図(b)に示したように、複数（N個）のTCPコネクションにより構成されこともある。各TCPコネクションはユーザ端末MNから送信されるSYNパケットに対してエンドサーバESのサービス提供部２がSYN-ACKを返信し、さらにユーザ端末MNからエンドサーバESへACKパケットが送信されることにより確立される。そして、このようにして確立されたTCPコネクションは、ユーザ端末MNおよびエンドサーバESの双方がFIN-ACKを交換することで切断される。
【００３２】
そこで、本実施形態ではエンドサーバESから送信された最初のSYN-ACKがプロキシ部３で受信された時刻をサービス開始時刻とし、さらに、N回目のFIN-ACK交換においてユーザ端末MNから送信されたFIN-ACKがプロキシ部３で受信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００３３】
なお、前記TCPコネクション数（N個）はサービス内容に依存するので、プロキシ部３は事前に各エンドサーバESから各サービスのTCPコネクション数（N個）を取得しておくことが望ましい。
【００３４】
また、各TCPコネクションが同一のTCPセッションに係るものであるか否かは、例えば送信元IPアドレスおよびport番号が同一、かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断できる。あるいは、送信元端末固有のIDが同一かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断しても良い。
【００３５】
図６は、サービス時間TATをHTTP METHODの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３６】
本実施形態では、ユーザ端末MNから送信されたHTTP METHOD（例えば、GET，POSTなど）がプロキシ部３を通過した時点でユーザ端末MNとエンドサーバESとの間にTCPコネクションが確立されたものと判断し、当該時刻がサービス開始時刻とされる。
【００３７】
さらに、N回目のFIN-ACK交換においてユーザ端末MNから送信されたFIN-ACKがプロキシ部３で受信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００３８】
図７は、サービス時間TATをHTTPメッセージボディの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３９】
本実施形態では、ユーザ端末MNから送信されるHTTPメッセージボディをプロキシ部３で監視し、メッセージボディの所定の領域にセッション開始を意味する識別コード（たとえば、「start」などの文字列）が登録されていることが検知されると、当該時刻がサービス開始時刻とされる。
【００４０】
さらに、ユーザ端末MNから送信されるHTTPメッセージボディの所定の領域にセッション終了を意味する識別コード（たとえば、「finish」などの文字列）が登録されていることが検知されると、当該時刻がサービス開始時刻とされる。そして、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００４１】
次いで、フローチャートに沿って本発明の一実施形態の動作を詳細に説明する。図９は、アクセスパス要求およびサービス要求を送信するユーザ端末MNの動作を示したフローチャートであり、図１０は、エンドサーバESにおいてアクセスパス要求を受信し、これを処理するアクセスパス処理部１の動作を示したフローチャートである。いずれの処理も所定の周期で繰り返し実行される。
【００４２】
図９において、ユーザが自身のユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図９のステップＳ１１で検知されるとステップＳ１２へ進む。ステップＳ１２では、リクエストするコンテンツの識別子を含んでエンドサーバESのアクセスパス処理部１を宛先とするアクセスパス要求が生成され、ステップＳ１３において送信される。
【００４３】
エンドサーバESでは、図１０のステップＳ３１において、前記アクセスパス要求が前記アクセスパス要求受信部１１で受信されるとステップＳ３２へ進む。ステップＳ３２では、前記要求管理部１２のエントリ追加部１２２により、このアクセスパス要求のエントリが管理テーブル１２１に新規登録される。ステップＳ３３では、前記同時接続数取得部１３により現在の同時接続数Mがプロキシ部３から取得される。ステップＳ３４では、前記サービス時間取得部１４により現在のサービス時間TATがプロキシ部３から取得される。
【００４４】
ステップＳ３５では、前記アクセスタイミング計算部１５において、アクセスパス要求を送信しながら未だサービスを提供されていない待機数WNが次式(1)に基づいて算出され、ステップＳ３６では、サービス要求までの待機時間WTが次式(2)に基づいて算出される。なお、次式(1)の未処理数Rは、前記管理テーブル１２１に登録されているエントリのうち、終了フラグがセットされていないエントリの総数であり、次式(2)のMmaxは、エンドサーバの最大同時接続数である。
【００４５】
【数１】
【００４６】
【数２】
【００４７】
ステップＳ３７では、前記算出された待機時間WTが前記要求管理部１２の待機時間登録部１２３により管理テーブル１２１の対応するエントリに登録される。ステップＳ３８では、前記アクセスパス応答生成部１６において、前記待機時間WTがアクセスタイミングとして記述されたアクセスパス応答のメッセージが生成される。ステップＳ３９では、前記アクセスパス応答返信部１７により、前記アクセスパス応答がユーザ端末MNへ返信される。
【００４８】
図９へ戻り、ユーザ端末MNでは、前記アクセスパス応答をステップＳ１４で受信すると、ステップＳ１５では、このアクセスパス応答に登録されている待機時間WTが抽出される。ステップＳ１６では、リクエストが先着順に処理されている旨を示す受付終了メッセージが端末ディスプレーに表示される。ステップＳ１７では、配信を要求するコンテンツの識別子およびエンドサーバの識別子を含むサービス要求のメッセージが生成される。
【００４９】
ステップＳ１８では、前記ステップＳ１３においてアクセスパス要求を送信してからの経過時間が前記待機時間TWに達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップＳ１９へ進む。ステップＳ１９では、前記ステップＳ１７で生成されたサービス要求が、今度はエンドサーバESのプロキシ部３を宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java（登録商標）script，Flashなどの各種スクリプト言語を利用することで実装できる。
【００５０】
このサービス要求はエンドサーバESのプロキシ部３において、前記サービス要求転送部３１により受信されてサービス提供部２へ転送される。サービス提供部２は、このサービス要求を従来技術と同様に処理し、要求されたサービス（本実施形態ではコンテンツ）をプロキシ部３へ渡す。プロキシ部３では、この提供されたサービスがサービス転送部３２により受信されて要求元のユーザ端末MNへ転送される。
【００５１】
ユーザ端末MNは、前記コンテンツをステップＳ２０で受信すると、ステップＳ２１へ進んで当該コンテンツを保存する。ステップＳ２２では、ダウンロード完了メッセージが端末ディスプレーに表示される。
【００５２】
以上のようにしてサービスの提供が完了すると、エンドサーバESでは、これがプロキシ部３のサービス終了検知部３７で検知され、サービス終了通知部３８からアクセスパス処理部１へサービス終了が通知される。
【００５３】
図１０へ戻り、アクセスパス処理部１では、このサービス終了通知がステップＳ４０で検知されるとステップＳ４３へ進み、前記要求管理部１２のエントリ抹消部１２４により、対応するエントリの終了フラグがセットされる。なお、サービス終了が通知されていなくても、ステップＳ４１において、前記図４に関して説明した「みなし終了」の監視タイミングであると判定され、さらにステップＳ４２において、「みなし終了」の条件を満足するエントリが存在すると判断されれば、前記ステップＳ４３へ進んで当該エントリの終了フラグが同様にセットされる。
【００５４】
前記みなし終了エントリの監視タイミングは、エンドサーバESの負荷軽減のために30分に一回、数時間に一回、あるいは1日に一回といったように、十分に間隔をあけて実施することが望ましい。
【符号の説明】
【００５５】
１…アクセスパス処理部，２…サービス提供部，３…プロキシ部，４…振分部，１１…アクセスパス要求受信部，１２…要求管理部，１３…同時接続数取得部，１４…サービス時間取得部，１５…アクセスタイミング計算部，１６…アクセスパス応答生成部，１７…アクセスパス応答返信部，３１…サービス要求転送部，３２…サービス転送部，３３…同時接続数取得部，３４…同時接続数通知部，３５…サービス時間取得部，３６…サービス時間通知部，３７…サービス終了検知部，３８…サービス終了通知部，１２１…管理テーブル，１２２…エントリ追加部，１２３…待機時間登録部，１２４…エントリ抹消部
【技術分野】
【０００１】
本発明は、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へのアクセスパスとして返信することでエンドサーバへのアクセス集中を緩和するシステムに関する。
【背景技術】
【０００２】
災害発生時の安否確認のためのリクエスト、あるいはTV番組やラジオ番組でヒットチャートを発表した直後に人気曲の配信を要求するリクエストなど、特定のイベントを契機とするリクエストメッセージは短時間に集中する傾向がある。これらの宛先でリクエストを受け付けるエンドサーバでは、リクエスト数が処理能力を超過すると、超過分についてはサービスの提供が不可能となる。これは同サービスを利用するユーザの満足度を低下させると共に、リクエストが有料コンテンツの配信であれば、コンテンツ提供者にとっては販売機会の損失となる。
【０００３】
イベントを契機とするアクセスの集中は通常のアクセス量を遙かに凌駕し、瞬間的には、１０倍から１００倍に達する場合もある。したがって、アクセス集中時のピーク時に合わせてサーバ容量を設計してしまうと、時間的に大半を占める通常時には大幅な過剰設備状態を招いてしまう。しかも、このようなアクセス集中は予測が難しいので、たとえ十分と予測される設備を用意できたとしても、その容量を上回るアクセスが集中する可能性を否定できない。
【０００４】
一方、２００３年１２月に東京・大阪・名古屋で地上デジタル放送が開始され、それ以後、他の地域でも放送が順次開始されると共に、移動体受信端末向けサービスなどが拡充されることになっている。地上デジタル放送で提供される通信放送連携サービスでは、番組内容を契機とした同時大量アクセスの発生が予見されており、上記で指摘した事象が今後ますます顕在化してくることが想定される。
【０００５】
特許文献１には、アクセス集中により受付拒否されたリクエストメッセージの再アクセスを、新たなアクセス集中を生じさせることなく公平に受け付けて処理できるシステムが開示されている。
【０００６】
ここでは、サービスを提供するエンドサーバに多数のアクセスが集中すると、受け付けられないユーザに対して、現在混んでいる旨と、次回優先接続される時間帯が提示される。同ユーザが改めて優先接続時間帯にアクセスしてきた場合、このリクエストメッセージは他のリクエストメッセージよりも優先的に受け付けられる。
【０００７】
しかしながら、特許文献１では一のユーザがリクエストメッセージを送信した際に受付側の負荷が大きいと受付を後回しにされる一方、その直後に他の一のユーザがリクエストメッセージを送信した際に受付側の負荷が解消していると、当該他の一のユーザのリクエストメッセージが先に受け付けられてしまうので、受付が公平に行われないという技術課題があった。
【０００８】
このような技術課題に対して、本発明の発明者等は特許文献２および非特許文献１のように、ユーザにサービスを提供するエンドサーバとは別に、ユーザ端末から送信されたアクセスパス要求を受け付けて、各ユーザ端末のエンドサーバへのアクセスタイミングを決定し、これを各ユーザ端末へアクセスパスとして返信するアクセスサーバを設けることにより、サービス要求のアクセスを漏れなく、かつ順序逆転なく公平に受け付けられるようにしたリクエスト受付方法およびシステムを提案している。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００７−２１９６５０号公報
【特許文献２】特開２００９−４３０６９号公報
【非特許文献】
【００１０】
【非特許文献１】「整理券発行機能を用いたアクセス制御システムの提案」，信学技法 vol.1 108 No.218, p81-p86.
【発明の概要】
【発明が解決しようとする課題】
【００１１】
エンドサーバにおいてユーザ端末からのサービス要求を滞りなく処理するためには、エンドサーバに入力されるサービス要求の周期とエンドサーバが一つのサービス要求を処理するのに要する時間、すなわちサービス時間TAT(Turn Around Time)とが一致していることが望ましい。そこで、上記した特許文献２および非特許文献１に開示された技術では、各エンドサーバのサービス処理レートを予め統計的に推定し、この推定値に従って各サービス要求が各エンドサーバで処理されるという前提で各ユーザ端末のアクセスタイミングを決定していた。
【００１２】
しかしながら、例えばコンテンツ配信のサービス要求に応答してエンドサーバがユーザ端末へ動画などのコンテンツを配信するサービスでは、エンドサーバのサービス時間がユーザ端末におけるコンテンツのダウンロード速度に依存する。そして、ユーザ端末のダウンロード速度は、アクセス回線の容量や接続方式（有線LANまたは有線LANなど）に依存するので、提供するサービスが同一であってもエンドサーバのサービス時間が一定であるとは限らない。
【００１３】
したがって、上記の従来技術では、エンドサーバのサービス時間に関する推定値と実績値とに乖離が生じる場合があり、これが大きくなると、推定値＜実績値であればエンドサーバに輻輳が生じ、その逆に推定値＞実績値であればエンドサーバの運用効率が低下してしまう。
【００１４】
本発明の目的は、上記した従来技術の課題を解決し、エンドサーバのサービス時間に基づいて各ユーザ端末からエンドサーバへのアクセスタイミングを正確に制御することでアクセス集中を緩和する自立型アクセス集中緩和システムを提供することにある。
【課題を解決するための手段】
【００１５】
上記の目的を達成するために、本発明は、ユーザ端末がエンドサーバへアクセスパス要求を送信してサービス要求のタイミングを問い合わせ、エンドサーバから通知された待機時間の経過後にエンドサーバへサービス要求を送信する自立型アクセス集中緩和システムにおいて、以下のような手段を講じた点に特徴がある。
【００１６】
(1)エンドサーバに、アクセスパス要求に応答して待機時間を求め、これをアクセスパス応答に記述して返信するアクセスパス処理部と、サービス要求に応答してサービスを提供するサービス提供部と、ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを設けた。
【００１７】
(2)前記プロキシ部に、要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを設けた。
【００１８】
(3)前記アクセスパス処理部に、アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、待機数およびサービス時間に基づいて待機時間を算出する手段と、待機時間を含むアクセスパス応答を返信する手段とを設けた。
【発明の効果】
【００１９】
本発明によれば、以下のような効果が達成される。
(1)アクセスパスサーバの機能をエンドサーバ上に設け、ユーザ端末とエンドサーバとの通信をエンドサーバ上で監視してサービス時間を計測し、これに基づいて各ユーザ端末に許可するエンドサーバへのアクセスタイミングを設定するようにしたので、各エンドサーバにおいて自律的にアクセスタイミングを決定できる。したがって、能力の異なる多数のエンドサーバが収容されるネットワークでも、エンドサーバごとにアクセス数を最適化できるようになる。
(2)エンドサーバが一つのサービス要求を処理するのに要するサービス時間として、統計的に算出された推定値ではなく実績値を採用できるので、常に正確なサービス時間に基づいてアクセスタイミングを決定できるようになる。
(3)アクセスパスサーバをネットワーク上に配置する必要がないので、ネットワーク障害の影響を最小限に抑えられる。
(4)アクセスパスサーバの廃止によりサーバ間の通信を削減できるので、情報の漏洩や改竄に対するセキュリティが向上する。
(5)アクセスパスサーバの廃止によりサーバ数を削減できるので、ネットワーク構成の簡略化による信頼性の向上が期待できる。
【図面の簡単な説明】
【００２０】
【図１】本発明が適用されるネットワークの構成を示したブロック図である。
【図２】エンドサーバの構成を示したブロック図である。
【図３】要求管理部の一例を示したブロック図である。
【図４】エントリをみなし終了と判定する方法の一例を示した図である。
【図５】サービス開始時刻およびサービス終了時刻をSYN/FINパケットの監視結果に基づいて推定する方法を模式的に表現した図である。
【図６】サービス時間をHTTP METHODの監視結果に基づいて推定する方法を模式的に表現した図である。
【図７】サービス時間をHTTPメッセージボディの監視結果に基づいて推定する方法を模式的に表現した図である。
【図８】TCPセッションの構成を示した図である。
【図９】ユーザ端末の動作を示したフローチャートである。
【図１０】エンドサーバの動作を示したフローチャートである。
【発明を実施するための形態】
【００２１】
以下、図面を参照して本発明の実施形態について詳細に説明する。 図１は、本発明が適用されるネットワークの構成を示したブロック図であり、ここでは、ユーザ端末MNからエンドサーバES（サービス提供サーバ）へコンテンツ配信のサービスを要求する場合を例にして説明する。
【００２２】
携帯電話、PDAあるいはコンピュータなどのユーザ端末MNは、基地局APを経由して携帯電話網あるいはインターネット等のIPネットワークNWに接続されている。また、ユーザ端末MNからのサービス要求に応答して、音楽や映像などのコンテンツを配信する複数のエンドサーバESj（jはエンドサーバ識別子）も前記IPネットワークNWに接続されている。
【００２３】
前記各エンドサーバESjは、各ユーザ端末MNにサービス要求を許可するタイミングを事前に決定して各ユーザ端末MNへ通知する機能を備え、ユーザ端末MNからコンテンツの識別情報等を含むアクセスパス要求のメッセージを受信すると、自身の能力や状況に基づいてアクセスタイミングを決定し、これを要求元のユーザ端末MNへ通知する。ユーザ端末MNは、通知されたアクセスタイミングを待ってエンドサーバESjへ改めてサービス要求を送信し、当該エンドサーバESjからコンテンツの配信サービスを受ける。
【００２４】
図２は、前記エンドサーバESの主要部の構成を示したブロック図であり、ユーザ端末MNから受信したアクセスパス要求を処理してアクセスパス応答を返信するアクセスパス処理部１と、ユーザ端末MNから受信したサービス要求に応答してサービスを提供するエンドサーバ本来の機能を実現するサービス提供部２と、ユーザ端末MNと前記サービス提供部２との間に介在してサービス要求およびその応答を中継するプロキシ部３と、ユーザ端末MNからエンドサーバESへのアクセスを、URLに基づいてアクセスパス処理部１またはプロキシ部３へ振り分ける振分部４とを主要な構成としている。
【００２５】
前記アクセスパス処理部１は、ユーザ端末MNから送信されたアクセスパス要求を受信するアクセスパス要求受信部１１と、受信したアクセスパス要求の数および終了したサービスの数に基づいて、未処理の要求数（未処理数）Rを管理する要求管理部１２と、エンドサーバESに同時接続しているユーザ端末MNの数Mをプロキシ部３から取得する同時接続数取得部１３と、サービス提供部２が一つのサービスを提供するのに要するサービス時間TATをプロキシ部３から取得するサービス時間取得部１４と、前記未処理数R、同時接続数Mおよびサービス時間TATに基づいて、各サービス要求のアクセスタイミングを計算するアクセスタイミング計算部１５と、前記アクセスタイミングの記述されたアクセスパス応答を生成するアクセスパス応答生成部１６と、前記アクセスパス応答を要求元のユーザ端末MNへ返信するアクセスパス応答返信部１７とを具備している。
【００２６】
プロキシ部３は、ユーザ端末MNから送信されたサービス要求を受信してサービス提供部２へ転送するサービス要求転送部３１と、このサービス要求に応答してサービス提供部２から提供されるサービスをユーザ端末MNへ転送するサービス転送部３２と、ユーザ端末MNの同時接続数Mを取得する同時接続数取得部３３と、取得した同時接続数Mをアクセスパス処理部１へ通知する同時接続数通知部３４と、ユーザ端末MNとエンドサーバESとの通信セッションを監視してサービス時間TATを取得するサービス時間取得部３５と、取得したサービス時間TATをアクセスパス処理部１へ通知するサービス時間通知部３６と、サービス提供部２における各サービスの終了タイミングを検知するサービス終了検知部３７と、検知されたサービス終了をアクセスパス処理部１へ通知するサービス終了通知部３８とを具備している。
【００２７】
図３は、前記要求管理部１２の一例を示したブロック図であり、受信した全てのアクセスパス要求を、その受付時刻、アクセスタイミングまでの待機時間WT、サービスの提供が完了するとセットされる終了フラグ、およびアクセスパス要求を一意に識別できる識別情報（アドレス、ポート番号、シーケンス番号など）を紐付けて管理する管理テーブル１２１と、アクセスパス要求の受信が通知されるごとに、管理テーブル１２１に当該アクセスパス要求のエントリを追加し、その受付時刻および識別情報を記述するエントリ追加部１２２と、アクセスタイミングまでの待機時間WTが通知されるごとに、これを対応するエントリに記述する待機時間登録部１２３と、サービス終了が通知されるごとに、対応するエントリの終了フラグをセットすると共に、所定のタイミングでエントリ自身を抹消するエントリ抹消部１２４とを具備している。
【００２８】
前記エントリ抹消部１２４はさらに、図４に模式的に示したように、アクセスパス要求の受付時刻からの経過時間が待機時間WTとサービス時間TATとの和に更に余裕時間αを加えた時間よりも長くなっているエントリについても、何らかの原因でサービスが放棄あるいは諦められたものとみなして終了フラグをセットする。
【００２９】
図５，６，７は、前記プロキシ部３のサービス時間取得部３５によるサービス時間TATの算出方法を模式的に表現した図であり、サービス要求およびサービス応答がTCPセッションを利用して行われる場合、SYN/FINパケット、HTTP METHOD、HTTPメッセージボディあるいはHTTP/1.1レンジリクエストを監視することでサービス時間TATが求められる。
【００３０】
図５は、サービス開始時刻およびサービス終了時刻をSYN/FINパケットの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３１】
TCPセッションは、図８(a)に示したように一つのセッションから構成されるとは限らず、同図(b)に示したように、複数（N個）のTCPコネクションにより構成されこともある。各TCPコネクションはユーザ端末MNから送信されるSYNパケットに対してエンドサーバESのサービス提供部２がSYN-ACKを返信し、さらにユーザ端末MNからエンドサーバESへACKパケットが送信されることにより確立される。そして、このようにして確立されたTCPコネクションは、ユーザ端末MNおよびエンドサーバESの双方がFIN-ACKを交換することで切断される。
【００３２】
そこで、本実施形態ではエンドサーバESから送信された最初のSYN-ACKがプロキシ部３で受信された時刻をサービス開始時刻とし、さらに、N回目のFIN-ACK交換においてユーザ端末MNから送信されたFIN-ACKがプロキシ部３で受信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００３３】
なお、前記TCPコネクション数（N個）はサービス内容に依存するので、プロキシ部３は事前に各エンドサーバESから各サービスのTCPコネクション数（N個）を取得しておくことが望ましい。
【００３４】
また、各TCPコネクションが同一のTCPセッションに係るものであるか否かは、例えば送信元IPアドレスおよびport番号が同一、かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断できる。あるいは、送信元端末固有のIDが同一かつ宛先IPアドレスおよびport番号が同一であるか否かに基づいて判断しても良い。
【００３５】
図６は、サービス時間TATをHTTP METHODの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３６】
本実施形態では、ユーザ端末MNから送信されたHTTP METHOD（例えば、GET，POSTなど）がプロキシ部３を通過した時点でユーザ端末MNとエンドサーバESとの間にTCPコネクションが確立されたものと判断し、当該時刻がサービス開始時刻とされる。
【００３７】
さらに、N回目のFIN-ACK交換においてユーザ端末MNから送信されたFIN-ACKがプロキシ部３で受信された時刻をサービス終了時刻とし、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００３８】
図７は、サービス時間TATをHTTPメッセージボディの監視結果に基づいて推定する方法を模式的に表現した図である。
【００３９】
本実施形態では、ユーザ端末MNから送信されるHTTPメッセージボディをプロキシ部３で監視し、メッセージボディの所定の領域にセッション開始を意味する識別コード（たとえば、「start」などの文字列）が登録されていることが検知されると、当該時刻がサービス開始時刻とされる。
【００４０】
さらに、ユーザ端末MNから送信されるHTTPメッセージボディの所定の領域にセッション終了を意味する識別コード（たとえば、「finish」などの文字列）が登録されていることが検知されると、当該時刻がサービス開始時刻とされる。そして、サービス開始時刻からサービス終了時刻までが各サービス要求のセッション継続時間とされ、その算術平均あるいは移動平均等がサービス時間TATとされる。
【００４１】
次いで、フローチャートに沿って本発明の一実施形態の動作を詳細に説明する。図９は、アクセスパス要求およびサービス要求を送信するユーザ端末MNの動作を示したフローチャートであり、図１０は、エンドサーバESにおいてアクセスパス要求を受信し、これを処理するアクセスパス処理部１の動作を示したフローチャートである。いずれの処理も所定の周期で繰り返し実行される。
【００４２】
図９において、ユーザが自身のユーザ端末MNのキースイッチ等を操作してコンテンツのリクエスト操作を実施し、これが図９のステップＳ１１で検知されるとステップＳ１２へ進む。ステップＳ１２では、リクエストするコンテンツの識別子を含んでエンドサーバESのアクセスパス処理部１を宛先とするアクセスパス要求が生成され、ステップＳ１３において送信される。
【００４３】
エンドサーバESでは、図１０のステップＳ３１において、前記アクセスパス要求が前記アクセスパス要求受信部１１で受信されるとステップＳ３２へ進む。ステップＳ３２では、前記要求管理部１２のエントリ追加部１２２により、このアクセスパス要求のエントリが管理テーブル１２１に新規登録される。ステップＳ３３では、前記同時接続数取得部１３により現在の同時接続数Mがプロキシ部３から取得される。ステップＳ３４では、前記サービス時間取得部１４により現在のサービス時間TATがプロキシ部３から取得される。
【００４４】
ステップＳ３５では、前記アクセスタイミング計算部１５において、アクセスパス要求を送信しながら未だサービスを提供されていない待機数WNが次式(1)に基づいて算出され、ステップＳ３６では、サービス要求までの待機時間WTが次式(2)に基づいて算出される。なお、次式(1)の未処理数Rは、前記管理テーブル１２１に登録されているエントリのうち、終了フラグがセットされていないエントリの総数であり、次式(2)のMmaxは、エンドサーバの最大同時接続数である。
【００４５】
【数１】
【００４６】
【数２】
【００４７】
ステップＳ３７では、前記算出された待機時間WTが前記要求管理部１２の待機時間登録部１２３により管理テーブル１２１の対応するエントリに登録される。ステップＳ３８では、前記アクセスパス応答生成部１６において、前記待機時間WTがアクセスタイミングとして記述されたアクセスパス応答のメッセージが生成される。ステップＳ３９では、前記アクセスパス応答返信部１７により、前記アクセスパス応答がユーザ端末MNへ返信される。
【００４８】
図９へ戻り、ユーザ端末MNでは、前記アクセスパス応答をステップＳ１４で受信すると、ステップＳ１５では、このアクセスパス応答に登録されている待機時間WTが抽出される。ステップＳ１６では、リクエストが先着順に処理されている旨を示す受付終了メッセージが端末ディスプレーに表示される。ステップＳ１７では、配信を要求するコンテンツの識別子およびエンドサーバの識別子を含むサービス要求のメッセージが生成される。
【００４９】
ステップＳ１８では、前記ステップＳ１３においてアクセスパス要求を送信してからの経過時間が前記待機時間TWに達したか否かに基づいてアクセスタイミングであるか否かが判定され、アクセスタイミングを待ってステップＳ１９へ進む。ステップＳ１９では、前記ステップＳ１７で生成されたサービス要求が、今度はエンドサーバESのプロキシ部３を宛先として送信される。このようなユーザ端末MNにおけるアクセスタイミングまでの待機処理は、Java（登録商標）script，Flashなどの各種スクリプト言語を利用することで実装できる。
【００５０】
このサービス要求はエンドサーバESのプロキシ部３において、前記サービス要求転送部３１により受信されてサービス提供部２へ転送される。サービス提供部２は、このサービス要求を従来技術と同様に処理し、要求されたサービス（本実施形態ではコンテンツ）をプロキシ部３へ渡す。プロキシ部３では、この提供されたサービスがサービス転送部３２により受信されて要求元のユーザ端末MNへ転送される。
【００５１】
ユーザ端末MNは、前記コンテンツをステップＳ２０で受信すると、ステップＳ２１へ進んで当該コンテンツを保存する。ステップＳ２２では、ダウンロード完了メッセージが端末ディスプレーに表示される。
【００５２】
以上のようにしてサービスの提供が完了すると、エンドサーバESでは、これがプロキシ部３のサービス終了検知部３７で検知され、サービス終了通知部３８からアクセスパス処理部１へサービス終了が通知される。
【００５３】
図１０へ戻り、アクセスパス処理部１では、このサービス終了通知がステップＳ４０で検知されるとステップＳ４３へ進み、前記要求管理部１２のエントリ抹消部１２４により、対応するエントリの終了フラグがセットされる。なお、サービス終了が通知されていなくても、ステップＳ４１において、前記図４に関して説明した「みなし終了」の監視タイミングであると判定され、さらにステップＳ４２において、「みなし終了」の条件を満足するエントリが存在すると判断されれば、前記ステップＳ４３へ進んで当該エントリの終了フラグが同様にセットされる。
【００５４】
前記みなし終了エントリの監視タイミングは、エンドサーバESの負荷軽減のために30分に一回、数時間に一回、あるいは1日に一回といったように、十分に間隔をあけて実施することが望ましい。
【符号の説明】
【００５５】
１…アクセスパス処理部，２…サービス提供部，３…プロキシ部，４…振分部，１１…アクセスパス要求受信部，１２…要求管理部，１３…同時接続数取得部，１４…サービス時間取得部，１５…アクセスタイミング計算部，１６…アクセスパス応答生成部，１７…アクセスパス応答返信部，３１…サービス要求転送部，３２…サービス転送部，３３…同時接続数取得部，３４…同時接続数通知部，３５…サービス時間取得部，３６…サービス時間通知部，３７…サービス終了検知部，３８…サービス終了通知部，１２１…管理テーブル，１２２…エントリ追加部，１２３…待機時間登録部，１２４…エントリ抹消部
【特許請求の範囲】
【請求項１】
ユーザ端末がエンドサーバへアクセスパス要求を送信してサービス要求のタイミングを問い合わせ、エンドサーバから通知された待機時間の経過後にエンドサーバへサービス要求を送信する自立型アクセス集中緩和システムにおいて、
前記エンドサーバが、
アクセスパス要求に応答して待機時間を求め、これをアクセスパス応答に記述して返信するアクセスパス処理部と、
サービス要求に応答してサービスを提供するサービス提供部と、
ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを具備し、
前記プロキシ部が、
要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、
サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを具備し、
前記アクセスパス処理部が、
アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、
前記待機数およびサービス時間に基づいて待機時間を算出する手段と、
前記待機時間を含むアクセスパス応答を返信する手段とを具備したことを特徴とする自立型アクセス集中緩和システム。
【請求項２】
前記プロキシ部がさらに、前記サービス提供部と同時接続されるユーザ端末数を検知する手段を具備し、
前記待機時間を算出する手段は、アクセスパス要求の数から終了したサービスの数および同士接続数を減じた値を待機数とすることを特徴とする請求項１に記載の自立型アクセス集中緩和システム。
【請求項３】
前記待機時間を算出する手段は、待機数とサービス時間との積をエンドサーバの最大同時接続数で除して待機時間を算出することを特徴とする請求項２に記載の自立型アクセス集中緩和システム。
【請求項１】
ユーザ端末がエンドサーバへアクセスパス要求を送信してサービス要求のタイミングを問い合わせ、エンドサーバから通知された待機時間の経過後にエンドサーバへサービス要求を送信する自立型アクセス集中緩和システムにおいて、
前記エンドサーバが、
アクセスパス要求に応答して待機時間を求め、これをアクセスパス応答に記述して返信するアクセスパス処理部と、
サービス要求に応答してサービスを提供するサービス提供部と、
ユーザ端末とサービス提供部との間でサービス要求およびその応答を中継するプロキシ部とを具備し、
前記プロキシ部が、
要求されたサービスのサービス時間を計測してアクセスパス処理部へ通知する手段と、
サービス提供部で終了したサービスを識別してアクセスパス処理部へ通知する手段とを具備し、
前記アクセスパス処理部が、
アクセスパス要求の数および終了したサービスの数に基づいて待機数を管理する手段と、
前記待機数およびサービス時間に基づいて待機時間を算出する手段と、
前記待機時間を含むアクセスパス応答を返信する手段とを具備したことを特徴とする自立型アクセス集中緩和システム。
【請求項２】
前記プロキシ部がさらに、前記サービス提供部と同時接続されるユーザ端末数を検知する手段を具備し、
前記待機時間を算出する手段は、アクセスパス要求の数から終了したサービスの数および同士接続数を減じた値を待機数とすることを特徴とする請求項１に記載の自立型アクセス集中緩和システム。
【請求項３】
前記待機時間を算出する手段は、待機数とサービス時間との積をエンドサーバの最大同時接続数で除して待機時間を算出することを特徴とする請求項２に記載の自立型アクセス集中緩和システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−２３１３５３（Ｐ２０１０−２３１３５３Ａ）
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願番号】特願２００９−７６３８１（Ｐ２００９−７６３８１）
【出願日】平成２１年３月２６日（２００９．３．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
【公開日】平成２２年１０月１４日（２０１０．１０．１４）
【国際特許分類】
【出願日】平成２１年３月２６日（２００９．３．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【Ｆターム（参考）】
[ Back to top ]