JP2015165349A - 一次応答装置、制御方法及びコンピュータプログラム - Google Patents

Abstract

【課題】配信サーバの負荷が高くなることを抑制することができる一次応答装置、制御方法及びコンピュータプログラムを提供することである。【解決手段】実施形態の一次応答装置は、通信部と、制御部とを持つ。通信部は、複数の端末及びデータを配信する配信サーバと通信する。制御部は、配信サーバと複数の端末との間の通信を中継するように通信部を制御する制御部であって、複数の端末から配信サーバに向けて送信されたデータを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約し、代表リクエストによって取得されたデータを、同じデータを要求するリクエストを送信した端末のそれぞれに送信するように通信部を制御し、代表リクエストによるデータの取得が失敗した場合、代表リクエストを配信サーバに再送するように通信部を制御する。【選択図】図２

Description

本発明の実施形態は、一次応答装置、制御方法及びコンピュータプログラムに関する。

従来、映像や音声などのコンテンツをストリーミング形式で配信することが行われている。このようなコンテンツ配信の形態には、ＶＯＤ（Video on Demand）やライブ配信などの形態がある。ＶＯＤは、予め作成されたコンテンツファイルを配信する形態である。それに対して、ライブ配信は、録音中の音声データや撮影中の映像データをリアルタイムに配信する形態である。
ライブ配信を行うコンテンツ配信システムは、例えば、配信データを生成する配信サーバと、配信サーバから配信データを取得し利用者端末に送信するプロキシサーバ等の一次応答装置とにより実現される。従来のコンテンツ配信システムでは、配信サーバの負荷が高くなる場合があった。

特開平１１−０５３２４４号公報

本発明が解決しようとする課題は、配信サーバの負荷が高くなることを抑制することができる一次応答装置、制御方法及びコンピュータプログラムを提供することである。

実施形態の一次応答装置は、通信部と、制御部とを持つ。通信部は、複数の端末及びデータを配信する配信サーバと通信する。制御部は、前記配信サーバと前記複数の端末との間の通信を中継するように前記通信部を制御する制御部であって、前記複数の端末から前記配信サーバに向けて送信された前記データを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約し、前記代表リクエストによって取得されたデータを、前記同じデータを要求するリクエストを送信した端末のそれぞれに送信するように前記通信部を制御し、前記代表リクエストによるデータの取得が失敗した場合、前記代表リクエストを前記配信サーバに再送するように前記通信部を制御する。

実施形態のライブ配信システム１のシステム構成を示すシステム構成図。 プロキシサーバ４の機能構成を示す機能ブロック図。 リクエスト管理テーブル４３１の具体例を示す図。 キャッシュロック管理テーブル４３２の具体例を示す図。 実施形態のプロキシサーバ４の処理の流れを示すフローチャート。 実施形態のライブ配信システム１において、再送によってリクエストが正常終了する場合の流れを示すシーケンス図。 実施形態のライブ配信システム１において、リクエストが異常終了する場合の流れを示すシーケンス図。

以下、実施形態の一次応答装置、制御方法及びコンピュータプログラムを、図面を参照して説明する。
図１は、実施形態のライブ配信システム１のシステム構成を示すシステム構成図である。
ライブ配信システム１は、配信サーバ２、第１のネットワーク３及びプロキシサーバ（一次応答装置）４を備える。配信サーバ２は、第１のネットワーク３を介して、プロキシサーバ４と通信する。ライブ配信されるコンテンツの配信データを生成するサーバである。第１のネットワーク３は、ＬＡＮ（Local Area Network）やＷＡＮ（Wide Area Network）、インターネットなどのネットワークである。

プロキシサーバ４は、第２のネットワーク５を介して、クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３と通信する。プロキシサーバ４は、各クライアント端末からのリクエストに応じて、配信サーバ２から配信データを取得し、クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３に送信する。第２のネットワークは、第１のネットワーク３と同様、ＬＡＮやＷＡＮ、インターネットなどのネットワークである。

クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３は、配信サーバ２から配信される配信データを取得する端末である。クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３は、例えば、ＰＣやスマートフォン、タブレット、携帯電話などの情報処理装置である。クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３は、第２のネットワーク５を介してライブ配信システム１のプロキシサーバ４との間で通信し、配信データを取得する。

以下の説明では、説明を簡単にするために、特に区別しない限り、クライアント端末６−１、クライアント端末６−２及びクライアント端末６−３をまとめてクライアント端末６と記す。

図２は、プロキシサーバ４の機能構成を示す機能ブロック図である。
プロキシサーバ４は、例えば、第１通信部４１、第２通信部４２、記憶部４３及び制御部４４を備える。記憶部４３は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）、フラッシュメモリ等の記憶装置である。制御部４４は、例えば、記憶部４３とバスによって接続されたＣＰＵ（Central Processing Unit）等のプロセッサが、記憶部４３に格納されたプログラムを実行することによって、以下に説明する機能を実現する。なお、制御部４４の各機能の全て又は一部は、ＡＳＩＣ（Application Specific Integrated Circuit）やＰＬＤ（Programmable Logic Device）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを用いて実現されてもよい。プログラムは、フレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ等の可搬媒体等に格納されたものであってもよいし、電気通信回線を介して他のコンピュータから送信されたものであってもよい。

第１通信部４１は、例えば、ＬＡＮ等の通信インターフェースを含む。第１通信部は、第１のネットワーク３を介して、配信サーバ２との間で通信する。
第２通信部４２は、例えば、ＬＡＮ等の通信インターフェースを含む。第２通信部は、第２のネットワーク５を介して、クライアント端末６との間で通信する。
記憶部４３は、例えば、リクエスト管理テーブル４３１及びキャッシュロック管理テーブル４３２を記憶している。リクエスト管理テーブル４３１は、クライアント端末６の配信データ取得のリクエストを管理するためのテーブルである。キャッシュロック管理テーブル４３２は、クライアント端末６が要求する配信データに対するキャッシュロックを管理するためのテーブルである。キャッシュロックの内容について次に説明する。

ライブ配信されるコンテンツは、例えば、チャンクと呼ばれるデータの単位で配信される。クライアント端末６は、コンテンツを識別するためのコンテンツＩＤと、チャンクを識別するためのチャンクＩＤとを指定することによって、プロキシサーバ４に配信データの取得を要求する。プロキシサーバ４は、キャッシュロック機能によって、同一の配信データを要求するリクエストを代表リクエストに集約する。

具体的には、プロキシサーバ４は、配信サーバ２に配信データ取得のリクエストを送信する際に、その配信データに対応するキャッシュロックキーを記憶する。キャッシュロックキーとは、リクエストに含まれるコンテンツＩＤ及びチャンクＩＤに基づいて生成される、配信データの識別情報である。プロキシサーバ４は、コンテンツＩＤ及びチャンクＩＤとキャッシュロックキーとの対応情報を、記憶部４３等に保持している。

プロキシサーバ４は、キャッシュロックキーが存在する配信データと同じ配信データを要求する他のリクエストを受信した場合、すでに代表リクエストを送信済みであるとして、後続のリクエストを待機させる。一方、プロキシサーバ４は、キャッシュロックキーが存在しない配信データを要求するリクエストを受信した場合、要求された配信データのキャッシュロックキーを記憶し、受信されたリクエストを配信サーバ２に送信する。すなわち、ある一定期間内にクライアント端末６から送信された同じ配信データを要求するリクエストのうち、最初に送信されたリクエストが代表リクエストとなる。

プロキシサーバ４は、代表リクエストを配信サーバ２に送信し、指定されたチャンクのデータを取得する。プロキシサーバ４は、当該チャンクのデータを要求した全てのクライアント端末６に、取得されたチャンクのデータを送信する。

制御部４４は、第１通信部４１を介して配信サーバ２との間で通信し、配信データを取得する。制御部４４は、第２通信部４２を介してクライアント端末６との間で通信し、配信データ取得のリクエストを受信する。制御部４４は、受信されたリクエストに応じて、配信サーバ２から配信データを取得し、クライアント端末６に送信する。制御部４４は、上述したキャッシュロック機能を制御する。

図３は、リクエスト管理テーブル４３１の具体例を示す図である。
リクエスト管理テーブル４３１は、Ｒｅｑ＿ＩＤごとにリクエストレコードを有する。リクエストレコードは、Ｒｅｑ＿ＩＤ、Ｌｏｃｋ＿ＩＤ及び端末アドレスの各値を有する。Ｒｅｑ＿ＩＤは、クライアント端末６のリクエストを識別するための情報である。Ｒｅｑ＿ＩＤの値は、プロキシサーバ４によってリクエストごとに固有の値が生成される。Ｌｏｃｋ＿ＩＤは、リクエストに基づいて生成されるキャッシュロックキーの値を表す。端末アドレスは、リクエストを送信したクライアント端末６を識別するための情報である。端末アドレスは、例えば、ＩＰ（Internet Protocol）アドレスなどの情報である。リクエストレコードは、クライアント端末６の配信データ取得のリクエストが受信されたときに、制御部４４によって登録される。

図４は、キャッシュロック管理テーブル４３２の具体例を示す図である。
キャッシュロック管理テーブル４３２は、Ｌｏｃｋ＿ＩＤごとにキャッシュロックレコードを有する。キャッシュロックレコードは、Ｌｏｃｋ＿ＩＤ、Ｒｅｑ＿ＩＤ及び再送回数の各値を有する。Ｌｏｃｋ＿ＩＤは、キャッシュロックキーを識別するための情報である。Ｒｅｑ＿ＩＤは、Ｌｏｃｋ＿ＩＤの値が示すキャッシュロックキーに対応する配信データを取得するために、配信サーバ２に送信された代表リクエストを識別するための情報である。再送回数は、Ｒｅｑ＿ＩＤの値が示す代表リクエストが配信サーバ２に再送された回数を表す。キャッシュロックレコードは、Ｌｏｃｋ＿ＩＤの値が示すキャッシュロックキーに、対応するキャッシュロックキーが存在しないリクエストが受信されたときに、制御部４４によって登録される。

図５は、実施形態のプロキシサーバ４の処理の流れを示すフローチャートである。
まず、クライアント端末６は、配信データの取得のリクエストを送信する。プロキシサーバ４は、クライアント端末６の配信データ取得のリクエストを受け付ける（ステップＳ１０１）。プロキシサーバ４は、受信したリクエストのリクエストＩＤを生成する。プロキシサーバ４は、配信データ取得のリクエストに含まれるコンテンツＩＤ及びチャンクＩＤに基づいて、キャッシュロックキーを生成する。プロキシサーバ４は、Ｒｅｑ＿ＩＤ及びＬｏｃｋ＿ＩＤのそれぞれの値に、リクエストＩＤ及びキャッシュロックキーを持つリクエストレコードを、リクエスト管理テーブル４３１に登録する。

次に、プロキシサーバ４は、キャッシュロック管理テーブル４３２を参照し、要求された配信データがキャッシュロックされているか否かを判定する（ステップＳ１０２）。具体的には、プロキシサーバ４は、キャッシュロック管理テーブル４３２を参照し、Ｌｏｃｋ＿ＩＤの値に、生成されたキャッシュロックキーを有するリクエストレコードを選択する。レコードが選択された場合、当該リクエストの配信データは既にキャッシュロックされていると判断される。一方、レコードが選択されなかった場合、当該リクエストの配信データはキャッシュロックされていないと判断される。

要求された配信データがキャッシュロックされていない場合（ステップＳ１０２−ＮＯ）、プロキシサーバ４は、当該リクエストについてキャッシュロックの設定を行う（ステップＳ１０３）。具体的には、プロキシサーバ４は、Ｌｏｃｋ＿ＩＤ、再送回数及びＲｅｑ＿ＩＤのそれぞれの値に、生成されたキャッシュロックキー、“０”、リクエストＩＤを持つキャッシュロックレコードを、キャッシュロック管理テーブル４３２に登録する。プロキシサーバ４は、キャッシュレコードを登録すると、キャッシュロック時間の計時を開始する。キャッシュロック時間とは、代表リクエストに対する配信サーバ２の応答を待機する時間である。

プロキシサーバ４は、キャッシュロックの設定を行うと、当該リクエストを配信サーバ２に送信する（ステップＳ１０４）。プロキシサーバ４は、配信サーバ２の応答を受信し、配信データを受信する。プロキシサーバ４は、当該配信データの取得のリクエストを送信したクライアント端末６に、取得された配信データを送信する（ステップＳ１０５）。具体的には、プロキシサーバ４は、リクエスト管理テーブル４３１を参照し、Ｌｏｃｋ＿ＩＤの値に当該キャッシュロックキーを有するリクエストレコードを選択する。プロキシサーバ４は、選択されたリクエストレコードから端末アドレスの値を取得する。プロキシサーバ４は、取得された端末アドレス宛に取得された配信データを送信する。

一方、ステップＳ１０２において、要求された配信データがキャッシュロックされている場合（ステップＳ１０２−ＹＥＳ）、プロキシサーバ４は、当該リクエストを配信サーバ２に送信せず、配信サーバ２に対して既に実行されている配信データの取得のリクエストに対する応答を待機する（ステップＳ１０６）。プロキシサーバ４は、リクエストの待機中に、配信サーバ２がリクエストに応答したかを判定する（ステップＳ１０７）。配信サーバ２がリクエストに応答した場合（ステップＳ１０７−ＹＥＳ）、ステップＳ１０５に進み、配信サーバ２から取得された配信データをクライアント端末６に送信する。

一方、配信サーバ２がリクエストに応答しない場合（ステップＳ１０７−ＮＯ）、プロキシサーバ４は、キャッシュロックタイムアウトが発生したか否かを判定する（ステップＳ１０８）。キャッシュロックタイムアウトとは、代表リクエストに対して、配信サーバ２がキャッシュロック時間内に応答しない状況のことを指す。キャッシュロックタイムアウトが発生していない場合（ステップＳ１０８−ＮＯ）、ステップＳ１０６に戻り、プロキシサーバ４は、引き続きリクエストに対する応答を待機する。一方、キャッシュロックタイムアウトが発生した場合（ステップＳ１０８−ＹＥＳ）、プロキシサーバ４は、リクエストを再送した回数が所定の閾値（Ｎ）に達しているか否かを判定する（ステップＳ１０９）。

具体的には、プロキシサーバ４は、キャッシュロック管理テーブル４３２を参照し、Ｌｏｃｋ＿ＩＤの値に当該リクエストのキャッシュロックキーを有するキャッシュロックレコードを選択する。プロキシサーバ４は、選択されたキャッシュロックレコードから再送回数の値を取得する。プロキシサーバ４は、取得された再送回数の値と、所定の閾値（Ｎ）とを比較する。

リクエストを再送した回数が所定の閾値に達した場合（ステップＳ１０９−ＮＯ）、プロキシサーバ４は、当該リクエストのキャッシュロックを解除する（ステップＳ１１０）。具体的には、プロキシサーバ４は、Ｌｏｃｋ＿ＩＤの値に、当該リクエストのキャッシュロックキーを有するキャッシュロックレコードをキャッシュロック管理テーブル４３２から削除する。プロキシサーバ４は、キャッシュロックを解除すると、当該リクエストの配信データを要求したクライアント端末６にリクエストの異常終了を応答する（ステップＳ１１１）。

具体的には、プロキシサーバ４は、リクエスト管理テーブル４３１を参照し、Ｌｏｃｋ＿ＩＤの値に、ステップＳ１１０で解除されたキャッシュロックに対応するキャッシュロックキーを有するリクエストレコードを選択する。プロキシサーバ４は、選択されたリクエストレコードから端末アドレスを取得する。プロキシサーバ４は、取得された端末アドレス宛に、リクエストの異常終了を応答する。プロキシサーバ４は、リクエストの異常終了を応答すると、選択されたリクエストレコードをリクエスト管理テーブル４３１から削除する。

一方、ステップＳ１０９において、リクエストを再送した回数が所定の閾値に達していない場合（ステップＳ１０９−ＹＥＳ）、プロキシサーバ４は、キャッシュロック時間の計時をリセットし、計時を０からやり直す（ステップＳ１１２）。プロキシサーバ４は、キャッシュロックタイムアウトが発生したリクエストを配信サーバ２に再送する（ステップＳ１１３）。再送されるリクエストは、同一のキャッシュロックＩＤを有するリクエストのうち、プロキシサーバ４に最初に送信されたリクエストである。

具体的には、プロキシサーバ４は、キャッシュロック管理テーブル４３２を参照し、Ｌｏｃｋ＿ＩＤの値に、タイムアウトが発生したリクエストのキャッシュロックキーを有するキャッシュロックレコードを選択する。プロキシサーバ４は、選択されたキャッシュロックレコードから再送回数及びＲｅｑ＿ＩＤの値を取得する。プロキシサーバ４は、取得された再送回数の値と、所定の閾値（Ｎ）とを比較する。プロキシサーバ４は、Ｒｅｑ＿ＩＤの値が示すリクエストを配信サーバ２に再送する。プロキシサーバ４は、取得された再送回数の値を１増加させ、選択されたキャッシュロックレコードを更新する。

図６は、実施形態のライブ配信システム１において、再送によってリクエストが正常終了する場合の流れを示すシーケンス図である。
まず、クライアント端末６−１がプロキシサーバ４に配信データ取得のリクエスト（リクエストＮｏ１）を送信する（ステップＳ２０１）。なお、この時点では、クライアント端末６−１が要求した配信データに対してキャッシュロックは設定されていないものと仮定する。

プロキシサーバ４は、クライアント端末６−１が要求した配信データに対してキャッシュロックが設定されていないため、当該配信データに対してキャッシュロックを設定する（ステップＳ２０２）。プロキシサーバ４は、キャッシュロックを設定すると、当該配信データ取得のリクエスト（リクエストＮｏ１）を配信サーバ２に送信する（ステップＳ２０３）。

次に、クライアント端末６−２がプロキシサーバ４にクライアント端末６−１と同じ配信データ取得のリクエスト（リクエストＮｏ２）を送信する（ステップＳ２０４）。続いて、クライアント端末６−３がプロキシサーバ４にクライアント端末６−１と同じ配信データ取得のリクエスト（リクエストＮｏ３）を送信する（ステップＳ２０５）。プロキシサーバ４は、クライアント端末６−１及びクライアント端末６−３が要求する配信データは、リクエストＮｏ１によって既にキャッシュロックが設定されているため、配信サーバ２にリクエストＮｏ２及びリクエストＮｏ３を送信せずにリクエストＮｏ１に対する応答を待機する。

図６では、配信サーバ２は、リクエストＮｏ１に対してプロキシサーバ４が計時するキャッシュロック時間内に応答しない。そのため、プロキシサーバ４において、リクエストＮｏ１のキャッシュロックタイムアウトが発生する（ステップＳ２０６）。プロキシサーバ４は、キャッシュロック時間の計時をリセットし、計時をやり直す（ステップＳ２０７）。プロキシサーバ４は、再度リクエストＮｏ１を配信サーバ２に送信する（ステップＳ２０８）。配信サーバ２は、再送されたリクエストＮｏ１に対して、キャシュロックタイマーが計時する時間内に応答（応答Ｎｏ１）し（ステップＳ２０９）、要求された配信データをプロキシサーバ４に送信する。プロキシサーバ４は、配信サーバ２から配信データを取得し、クライアント端末６−１に応答（応答Ｎｏ１）を送信する（ステップＳ２１０）。同様に、プロキシサーバ４は、クライアント端末６−２に応答（応答Ｎｏ２）を送信する（ステップＳ２１１）。同様に、プロキシサーバ４は、クライアント端末６−３に応答（応答Ｎｏ３）を送信する（ステップＳ２１２）。

図７は、実施形態のライブ配信システム１において、リクエストが異常終了する場合の流れを示すシーケンス図である。
なお、図７では、図６と同様の処理については、図６と同じ符号を付すことによって説明を省略する。
また、図７では、プロキシサーバ４のキャッシュロックタイムアウトの発生によるリクエストの再送回数の閾値Ｎは“１”に設定されているものと仮定する。
図７では、配信サーバ２は、ステップＳ２０８において再送されたリクエストＮｏ１に対してもプロキシサーバ４が計時するキャッシュロック時間内に応答しない。そのため、プロキシサーバ４において、リクエストＮｏ１のキャッシュロックタイムアウトが再度発生する（ステップＳ３０１）。この時点でのリクエストＮｏ１の再送回数は“１”であり、再送回数の閾値Ｎに達している。そのため、プロキシサーバ４は、更なるリクエストＮｏ１の再送は行わず、クライアント端末６−１にリクエストＮｏ１が異常終了したことの応答（異常応答Ｎｏ１）を送信する（ステップＳ３０２）。同様に、プロキシサーバ４は、クライアント端末６−２にリクエストＮｏ２が異常終了したことの応答（異常応答Ｎｏ２）を送信する（ステップＳ３０３）。同様に、プロキシサーバ４は、クライアント端末６−３にリクエストＮｏ３が異常終了したことの応答（異常応答Ｎｏ３）を送信する（ステップＳ３０４）。

このように構成された実施形態のプロキシサーバ４は、配信サーバ２から配信データを取得するリクエストにおいてキャッシュロックタイムアウトが発生した場合、キャッシュロック時間の計時をリセットし、リクエストを再送する。そして、リクエストを再送した回数が所定の閾値に達すると、プロキシサーバ４は、リクエストを送信したクライアント端末６に対してリクエストの異常終了（所定の通知の一例）を応答する。
仮にこのような機能を有さない場合、キャッシュロックタイムアウトが発生すると、全てのクライアント端末６のリクエストを配信サーバ２に送信することが想定される。このような場合、キャッシュロックタイムアウトが発生すると、プロキシサーバ４と配信サーバ２における処理負荷が高くなる。さらに、クライアント端末６ごとに配信サーバ２から配信データが送信されるため、プロキシサーバ４と配信サーバ２との間のネットワークにおいて輻輳が発生する可能性が高まる。
そのため、実施形態のプロキシサーバ４は、上述の制御を行うことによって、キャッシュロックタイムアウトの発生によって配信サーバ２の負荷が高くなることを抑制することが可能となる。

次に、本実施形態の変形例について説明する。
第１のネットワーク及び第２のネットワークは、同じネットワークとして構成されてもよい。
プロキシサーバ４では、第２通信部４２を介して、多数のクライアント端末６に対するコンテンツの配信が行われることを考慮して、第２通信部４２は、ＴｏＥ（ＴＣＰ／ＩＰ ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）に対応した通信インターフェースを用いて構成されてもよい。
プロキシサーバ４では、第２通信部４２を介して、多数のクライアント端末６に対するコンテンツの配信が行われることを考慮して、第２通信部４２は、第１通信部４１よりも大きな帯域を有する通信インターフェースを用いて構成されてもよい。例えば、第１通信部４１が１Ｇｂｐｓの帯域を有する場合、第２通信部４２は、１０Ｇｂｐｓの帯域を有する通信インターフェースを用いて構成されてもよい。
プロキシサーバ４と配信サーバ２との間の通信と、プロキシサーバ４とクライアント端末６との間の通信と、をルータ等の中継装置を用いて分岐させることによって、プロキシサーバ４の第１通信部４１と第２通信部４２とは、１つの通信部に統合されてもよい。

以上説明した少なくともひとつの実施形態によれば、キャッシュロックタイムアウトが発生した際に、配信サーバ２に代表リクエストを再送する機能を持つことにより、キャッシュロックタイムアウトの発生時に配信サーバ２の負荷が高くなることを抑制することができる。
また、実施形態によれば、代表リクエストの再送回数が所定の閾値に達した場合、クライアント端末６に対してリクエストの異常終了を応答することにより、配信データがなかなか送信されてこないことによりユーザがイライラ感を覚えるのを防止することができる。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１…ライブ配信システム、２…配信サーバ、３…第１のネットワーク、４…プロキシサーバ、４１…第１通信部、４２…第２通信部、４３…記憶部、４３１…リクエスト管理テーブル、４３２…キャッシュロック管理テーブル、４４…制御部、５…第２のネットワーク、６、６−１、６−２、６−３…クライアント端末

Claims (7)

1. 複数の端末及びデータを配信する配信サーバと通信する通信部と、
   前記配信サーバと前記複数の端末との間の通信を中継するように前記通信部を制御する制御部であって、前記複数の端末から前記配信サーバに向けて送信された前記データを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約し、前記代表リクエストによって取得されたデータを、前記同じデータを要求するリクエストを送信した端末のそれぞれに送信するように前記通信部を制御し、前記代表リクエストによるデータの取得が失敗した場合、前記代表リクエストを前記配信サーバに再送するように前記通信部を制御する制御部と、
   を備える一次応答装置。
2. 前記制御部は、前記代表リクエストを前記配信サーバに送信するとき、前記代表リクエストに集約された他のリクエストを前記配信サーバに送信しないように前記通信部を制御し、前記代表リクエストを前記配信サーバに再送するとき、前記代表リクエストに集約された他のリクエストを前記配信サーバに送信しないように前記通信部を制御する、
   請求項１に記載の一次応答装置。
3. 前記制御部は、前記代表リクエストを前記配信サーバに再送する回数が所定の回数以上となった場合、前記同じデータを要求するリクエストを送信した端末に所定の通知を行う、
   請求項１又は２に記載の一次応答装置。
4. 前記プロキシサーバは、前記代表リクエストによるデータの取得が失敗した回数を記憶する記憶部をさらに備える、
   請求項３に記載の一次応答装置。
5. 複数の端末及びデータを配信する配信サーバと通信する通信部と、
   前記配信サーバと前記複数の端末との間の通信を中継するように前記通信部を制御する制御部であって、前記複数の端末から前記配信サーバに向けて送信された前記データを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約し、前記代表リクエストによって取得されたデータを、前記同じデータを要求するリクエストを送信した端末のそれぞれに送信するように前記通信部を制御し、前記代表リクエストによるデータの取得が失敗した場合、前記同じデータを要求するリクエストを送信した端末に所定の通知を行う制御部と、
   を備える一次応答装置。
6. 複数の端末及びデータを配信する配信サーバと通信する通信部を備える一次応答装置が、
   前記配信サーバと前記複数の端末との間の通信を中継するように前記通信部を制御し、前記複数の端末から前記配信サーバに向けて送信された前記データを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約し、前記代表リクエストによって取得されたデータを、前記同じデータを要求するリクエストを送信した端末のそれぞれに送信するように前記通信部を制御し、前記代表リクエストによるデータの取得が失敗した場合、前記代表リクエストを前記配信サーバに再送するように前記通信部を制御する、
   制御方法。
7. 複数の端末及びデータを配信する配信サーバと通信する通信部を備える一次応答装置に、
   前記配信サーバと前記複数の端末との間の通信を中継するように前記通信部を制御させ、前記複数の端末から前記配信サーバに向けて送信された前記データを要求するリクエストのうち同じデータを要求するリクエストを代表リクエストに集約させ、前記代表リクエストによって取得されたデータを、前記同じデータを要求するリクエストを送信した端末のそれぞれに送信するように前記通信部を制御させ、前記代表リクエストによるデータの取得が失敗した場合、前記代表リクエストを前記配信サーバに再送するように前記通信部を制御させるためのコンピュータプログラム。

Images