(57)【要約】【課題】キャッシュデータを共用してストリームサービスを実現できるストリームコンテンツ配送システムおよびプロキシサーバを提供することにある。【解決手段】ストリームサーバからコンテンツパケットを受信した時、受信パケットから抽出したコンテンツデータをストリームコンテンツのキャッシュデータとしてファイル装置に格納すると共に、受信パケットのアドレスを書き換えてコンテンツ要求元に転送するプロキシサーバにおいて、コンテンツパケットの送信元ストリームサーバに対してサービス中止を要求し、他のプロキシサーバに上記ストリームコンテンツの残り部分の転送を要求するための機能を備える。【選択図】　図３
2004070860.tif 000002
【特許請求の範囲】
【請求項１】
ストリームコンテンツをキャッシュデータとして蓄積するためのファイル装置を有し、ストリームサーバからコンテンツパケットを受信した時、受信パケットから抽出したコンテンツデータをストリームコンテンツのキャッシュデータとして上記ファイル装置に格納すると共に、受信パケットのアドレスを書き換えてコンテンツ要求元に転送するプロキシサーバであって、
上記コンテンツパケットの送信元ストリームサーバに対してサービス中止を要求し、他のプロキシサーバに上記ストリームコンテンツの残り部分の転送を要求するための第１手段を備えたことを特徴とするプロキシサーバ。
【請求項２】
クライアントからコンテンツ要求を受信した時、該コンテンツ要求で指定されたコンテンツが前記ファイル装置にキャッシュデータとして存在した場合、上記ファイル装置からストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元クライアントに送信するための第２手段と、
上記コンテンツ要求で指定されたコンテンツが前記ファイル装置にキャッシュデータとして存在しなかった場合、前記ストリームサーバにコンテンツの送信を要求するための第３手段と、
上記コンテンツ要求で指定されたコンテンツ識別子を含む要求受付通知を管理サーバに送信するための第４手段とを有し、
前記第１手段が、上記要求受付通知に対する上記管理サーバからの応答に従って、前記ストリームサーバに対するサービスの中止要求と、他のプロキシサーバへのストリームコンテンツの転送要求を実行することを特徴とする請求項１に記載のプロキシサーバ。
【請求項３】
他のプロキシサーバからコンテンツ要求を受信した時、上記ファイル装置から上記要求に合致したストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元プロキシサーバに送信するための手段を備えたことを特徴とする請求項１に記載のプロキシサーバ。
【請求項４】
コンテンツ要求に応答してストリームコンテンツの配信サービスを実行する少なくとも１つのストリームサーバと、
それぞれストリームコンテンツをキャッシュデータとして蓄積するためのファイル装置を備えた複数のプロキシサーバと、
上記プロキシサーバとストリームサーバと通信網との間でパケット交換を行うと共に、上記通信網から受信したコンテンツ要求を上記複数のプロキシサーバに振り分けるスイッチとからなり、
上記各プロキシサーバが、
クライアントからのコンテンツ要求を受信した時、該コンテンツ要求で指定されたコンテンツが上記ファイル装置にキャッシュデータとして存在した場合、上記ファイル装置からストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元クライアントに送信するための手段と、
上記コンテンツ要求で指定されたコンテンツが上記ファイル装置にキャッシュデータとして存在しなかった場合、上記ストリームサーバにコンテンツの送信を要求するための手段と、
上記ストリームサーバからコンテンツパケットを受信した時、受信パケットから抽出したコンテンツデータをストリームコンテンツのキャッシュデータとして上記ファイル装置に格納すると共に、受信パケットのアドレスを書き換えてコンテンツ要求元に転送するための手段と、
上記ストリームサーバに対してサービス中止を要求し、他のプロキシサーバに上記ストリームコンテンツの残り部分の転送を要求するための手段とを備えたことを特徴とするストリームコンテンツ配送システム。
【請求項５】
請求項４に記載のストリームコンテンツ配送システムにおいて、更に、
前記スイッチを介して前記各プロキシサーバと交信し、各プロキシサーバが保持するキャッシュデータに関する管理情報を収集する管理サーバを有し、
前記各プロキシサーバが、前記コンテンツ要求で指定されたコンテンツ識別子を含む要求受付通知を上記管理サーバに送信し、該通知に対する上記管理サーバからの応答に従って、前記ストリームサーバに対するサービスの中止要求と、他のプロキシサーバへのストリームコンテンツの転送要求を実行することを特徴とするストリームコンテンツ配送システム。
【請求項６】
前記管理サーバが、前記管理情報に従って前記要求受付通知が示すコンテンツ識別子と対応するキャッシュデータの有無を判定し、他のプロキシサーバにキャッシュデータが存在した場合、上記通知の送信元となったプロキシサーバに対して、切替先プロキシサーバを指定した前記応答を返すことを特徴とする請求項５に記載のストリームコンテンツ配送システム。
【請求項７】
前記各プロキシサーバが、他のプロキシサーバからコンテンツ要求を受信した時、前記ファイル装置から上記要求に合致したストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元プロキシサーバに送信するための手段を備えたことを特徴とする請求項５に記載のストリームコンテンツ配送システム。
【請求項８】
前記管理サーバが、前記各プロキシサーバの負荷状態を記憶する負荷管理テーブルを有し、前記要求受付通知を受信した時、上記負荷管理テーブルを参照して前記切替先プロキシサーバを選択することを特徴とする請求項６に記載のストリームコンテンツ配送システム。
【請求項９】
前記管理サーバが、前記ストリームサーバの負荷状態を記憶するための第２の負荷管理テーブルを有し、前記要求受付通知を受信した時、上記第２の負荷管理テーブルを参照し、上記ストリームサーバが過負荷状態になった場合は、上記通知の送信元となったプロキシサーバに対して、サービスの中止を指定した応答を返すことを特徴とする請求項６に記載のストリームコンテンツ配送システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ストリームコンテンツ配送システムおよびプロキシサーバに関し、特にストリームサーバにおける負荷分散を可能としたストリームコンテンツ配送システムおよびプロキシサーバに関する。
【０００２】
【従来の技術】
インターネット等のネットワークの帯域増加に伴って、ネットワークを利用したストリームコンテンツの配送サービスが実現可能となった。ビデオオンデマンド等のストリームコンテンツの配送サービス（以下、ストリームサービスと言う）では、ユーザ端末（以下、クライアントと言う）からストリームコンテンツの配送元となるストリームサーバにコンテンツ要求メッセージを送り、この要求に対する応答として、ストリームサーバからクライアントに要求ストリームコンテンツを含む一連のパケットを送信し、クライアントでストリームを再生する。
【０００３】
ストリームサービスにおいて、不特定多数のクライアントからのコンテンツ要求に対処するためには、ストリームコンテンツの供給源となるサーバを複数台用意する必要がある。また、ストリームサービスが大規模化してくると、ネットワークトポロジ的に並列配置された複数のストリームサーバをスイッチを介してネットワークに接続し、上記スイッチで、例えば、ラウンドロビン等の負荷分散アルゴリズムに従って、コンテンツ要求をストリームサーバに振り分ける負荷分散型のシステム構成が採用される。しかしながら、サービス対象となるストリームコンテンツを全てのストリームサーバに均等に持たせ、スイッチで振り分けられたコンテンツ要求を任意のサーバで処理できるようにしようとすると、各サーバに大きなコンテンツファイル（ストレージ）が必要となる。
【０００４】
コンテンツデータ蓄積用のストレージを有効利用するため、ストリームサービスでは次のシステム構成が知られている。
第１タイプのシステム構成では、ストリームサーバ毎に異なったコンテンツを有し、コンテンツ要求があった時、要求コンテンツを持つ特定のサーバがクライアントにコンテンツデータを送信する。
第２タイプのシステム構成では、複数のストリームサーバがコンテンツファイルを共有し、各ストリームサーバが任意のコンテンツ要求を受付け、上記共用ファイルから要求コンテンツを読み出して、クライアントに送信する。
第３タイプのシステム構成は、第１のシステム構成における複数のサーバに、要求頻度の高いストリームコンテンツの複製を持たせておき、人気ストリームに対するコンテンツ要求に複数のサーバが応答できるようにしたものである。
第４タイプのシステム構成では、ストリームサーバの前にプロキシサーバを配置し、プロキシサーバに要求頻度の高いストリームコンテンツをキャッシュデータとして保持させ、プロキシサーバからクライアントにコンテンツデータを送信する。
【０００５】
【発明が解決しようとする課題】
ストリームコンテンツは、通常のＷｅｂサービスと比較し、コンテンツのサイズが大きいため、ネットワークやサーバの負荷が大きい。特に、上記第１タイプのシステム構成では、クライアントからの要求が特定のストリームコンテンツに集中した場合、上記特定ストリームを保持するサーバに負荷が集中し、クライアントからの要求に十分に対応することが困難となる。
【０００６】
第２タイプのシステム構成では、特定ストリームに対する多数のコンテンツ要求を複数のサーバで受け付ることができるが、コンテンツファイルがこれら複数のサーバで共用されているため、アクセス速度の早い高性能ストレージが必要となる。
第３タイプのシステム構成では、要求頻度の高いコンテンツを予め予測することが困難であり、コンテンツの複製を複数のサーバにロードするための作業が発生するため、システムの運用コストが高くなる。
【０００７】
第４タイプのシステム構成では、要求頻度の高いコンテンツをキャッシュデータとしてプロキシサーバに自動的に蓄積できる利点がある。しかしながら、ストリームコンテンツはデータサイズが大きいため、キャッシュファイルの容量的制約から、新たなキャッシュデータの蓄積エリアを確保するために、旧いキャッシュデータの無効化が頻繁に発生する。各プロキシサーバは、クライアントから要求されたコンテンツのキャッシュデータが自分のキャッシュファイルになければ、仮に他のプロキシサーバにキャッシュデータがあった場合でも、オリジナルコンテンツをもつストリームサーバをアクセスすることになるため、キャッシュデータの利用に問題がある。この問題は、複数のプロキシサーバ間でキャッシュを共有することによって解決できる。
【０００８】
しかしながら、必要なキャッシュデータが無かったとき、各プロキシサーバが他のプロキシサーバに目的キャッシュデータの有無を問合せる方法を採用すると、プロキシサーバ間での制御メッセージの交信が頻発し、キャッシュを共有するためのオーバヘッドが無視できなくなる。特開２００１−２０２３３号公報には、ネットワークスイッチで全てのサーバのキャッシュ状態を把握しておき、必要なキャッシュデータを保持しているサーバに対してコンテンツ要求を選択的に振り分けるクラスタサーバ装置が提案されている。この場合、通信負荷が集中するネットワークスイッチに、サーバのキャッシュ状態を把握するための特殊な機能が必要となるため、例えば、ラウンドロビンでコンテンツ要求を振り分けるタイプの比較的安価な汎用的ネットワークスイッチを採用することはできない。
【０００９】
本発明の目的は、複数のプロキシサーバ間でキャッシュデータを共用してストリームサービスを実現できるストリームコンテンツ配送システムおよびプロキシサーバを提供することにある。
本発明の他の目的は、キャッシュ状態を把握するための特殊機能をもたないネットワークスイッチを適用して、キャッシュデータを有効利用してストリームサービスを実現できるストリームコンテンツ配送システムおよびプロキシサーバを提供することにある。
【００１０】
【課題を解決するための手段】
上記目的を達成するため、本発明は、ストリームコンテンツをキャッシュデータとして蓄積するためのファイル装置を有し、ストリームサーバからコンテンツパケットを受信した時、受信パケットから抽出したコンテンツデータをストリームコンテンツのキャッシュデータとして上記ファイル装置に格納すると共に、受信パケットのアドレスを書き換えてコンテンツ要求元に転送するプロキシサーバにおいて、上記コンテンツパケットの送信元ストリームサーバに対してサービス中止を要求し、他のプロキシサーバに上記ストリームコンテンツの残り部分の転送を要求するための機能を備えたことを特徴とする。
【００１１】
本発明の他の特徴は、上記プロキシサーバが、他のプロキシサーバからコンテンツ要求を受信した時、上記ファイル装置から上記要求に合致したストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元プロキシサーバに送信するための機能を備えたことにある。
【００１２】
更に詳述すると、本発明のプロキシサーバは、クライアントからコンテンツ要求を受信した時、該コンテンツ要求で指定されたコンテンツが前記ファイル装置にキャッシュデータとして存在した場合、上記ファイル装置からストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元クライアントに送信するための手段と、上記コンテンツ要求で指定されたコンテンツが上記ファイル装置にキャッシュデータとして存在しなかった場合、上記ストリームサーバにコンテンツの送信を要求するための手段と、上記コンテンツ要求で指定されたコンテンツ識別子を含む要求受付通知を管理サーバに送信するための手段とを有し、ストリームサーバに対するサービスの中止要求と、他のプロキシサーバへのストリームコンテンツの転送要求が、上記要求受付通知に対する上記管理サーバからの応答に従って実行される。
【００１３】
本発明のストリームコンテンツ配送システムは、コンテンツ要求に応答してストリームコンテンツの配信サービスを実行する少なくとも１つのストリームサーバと、それぞれストリームコンテンツをキャッシュデータとして蓄積するためのファイル装置を備えた複数のプロキシサーバと、上記プロキシサーバとストリームサーバと通信網との間でパケット交換を行うと共に、上記通信網から受信したコンテンツ要求を上記複数のプロキシサーバに振り分けるスイッチとからなり、上記各プロキシサーバが、
クライアントからのコンテンツ要求を受信した時、該コンテンツ要求で指定されたコンテンツが上記ファイル装置にキャッシュデータとして存在した場合、上記ファイル装置からストリームコンテンツを読み出し、一連のコンテンツパケットとして要求元クライアントに送信するための手段と、
上記コンテンツ要求で指定されたコンテンツが上記ファイル装置にキャッシュデータとして存在しなかった場合、上記ストリームサーバにコンテンツの送信を要求するための手段と、
上記ストリームサーバからコンテンツパケットを受信した時、受信パケットから抽出したコンテンツデータをストリームコンテンツのキャッシュデータとして上記ファイル装置に格納すると共に、受信パケットのアドレスを書き換えてコンテンツ要求元に転送するための手段と、
上記ストリームサーバに対してサービス中止を要求し、他のプロキシサーバに上記ストリームコンテンツの残り部分の転送を要求するための手段とを備えたことを特徴とする。
【００１４】
本発明の１実施例では、ストリームコンテンツ配送システムが、更に、上記スイッチを介して各プロキシサーバと交信し、各プロキシサーバが保持するキャッシュデータに関する管理情報を収集する管理サーバを有し、各プロキシサーバが、コンテンツ要求で指定されたコンテンツ識別子を含む要求受付通知を上記管理サーバに送信し、該通知に対する上記管理サーバからの応答に従って、前記ストリームサーバに対するサービスの中止要求と、他のプロキシサーバへのストリームコンテンツの転送要求を実行することを特徴とする。
この場合、管理サーバは、上記管理情報に従って上記要求受付通知が示すコンテンツ識別子と対応するキャッシュデータの有無を判定し、他のプロキシサーバにキャッシュデータが存在した場合、上記通知の送信元となったプロキシサーバに対して、切替先プロキシサーバを指定した前記応答を返す。
【００１５】
本発明の構成によれば、コンテンツ要求をコンテンツ識別子に無関係にプロキシサーバに振り分けた場合でも、プロキシサーバ間でキャッシュデータを共用できるため、ストリームサーバの負荷を軽減できる。また、同一ストリームのキャッシュデータを複数のプロキシサーバに持たせることによって、人気ストリームに対するコンテンツ要求を複数のプロキシサーバで並列的に処理することが可能となる。
本発明の他の目的および特徴は以下の実施例の説明から明らかになる。
【００１６】
【発明の実施の形態】
以下、本発明の実施例について図面を参照して説明する。
図１は、本発明のプロキシサーバを適用したネットワークシステムの概略的な構成を示す。
クライアント端末（以下、単にクライアントと言う）１ａ〜１ｍは、ＩＰ網２を介してスイッチ３に接続されている。スイッチ３は、ストリームサーバ４ａ〜４ｎと、プロキシサーバ５ａ〜５ｋと、管理サーバ６とから構成されるストリームサービスサイトのアクセスポイントとなっている。各クライアントは、取得したいストリームコンテンツの識別子（以下、コンテンツ識別子と言う）を指定したコンテンツ要求を上記スイッチ３宛に送信する。スイッチ３は、例えば、ラウンドロビン等の振分けアルゴリズムに従って、上記コンテンツ要求をコンテンツ識別子に依存することなくプロキシサーバ５ａ〜５ｋに振分け、プロキシサーバ５ａ〜５ｋの負荷を分散する。７は、ＩＰ網２に接続されたＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｅｒｖｅｒ）、４０ａ〜４０ｎは、それぞれストリームサーバ４ａ〜４ｎが備えるストリームコンテンツ蓄積用のファイル装置（ストレージ装置）を示す。
【００１７】
各プロキシサーバ５（５ａ〜５ｋ）は、スイッチ３からコンテンツ要求を受信すると、アドレステーブルを参照し、コンテンツ識別子で特定されるストリームコンテンツを提供するストリームサーバのアドレスを取得する。上記コンテンツ識別子と対応するストリームサーバアドレスが未登録の場合は、コンテンツ識別子を指定してＤＮＳ７にストリームサーバのアドレスを問合せる。この後、上記コンテンツ要求のヘッダに含まれる宛先アドレスをストリームサーバアドレスに書き換え、送信元アドレスを自分のアドレスに書き換えて、スイッチ３に出力する。上記アドレス変換されたコンテンツ要求は、スイッチ３によって宛先アドレスが示す特定のサーバ、例えば、ストリームサーバ４ａに転送される。上記コンテンツ要求を受信したストリームサーバ４ａは、ファイル装置４０ａから上記コンテンツ要求が示すコンテンツ識別子で特定されたストリームコンテンツを読み出し、これを複数のデータパケットに分割して、要求元のプロキシサーバに送信する。
【００１８】
図２は、ファイル装置４０ａから読み出されたストリームコンテンツと送信パケットとの関係を示す。
ストリームコンテンツ２０の先頭には、制御パラメータとして、データサイズ２１と該ストリームコンテンツの送信に必要な帯域２２の値が設定される。ストリームサーバ４ａは、上記制御パラメータを含むコンテンツデータを所定長の複数のデータブロックＤ１、Ｄ２、…に分割し、各データブロック１０にＩＰヘッダ１１とＴＣＰヘッダ１２とを付加し、複数のＩＰパケット８０（８０−１〜８０−ｎ）としてスイッチ３に送出する。最後のデータブロックＤｎは、半端な長さとなるため、最後のＩＰパケット８０−ｎの長さは、他のパケットよりも短くなっている。
【００１９】
上記各ＩＰヘッダ１１の宛先アドレスは、要求元となったプロキシサーバのアドレスが設定されているため、各ＩＰパケットはスイッチ３から要求元プロキシサーバ、例えば、プロキシサーバ５ａに転送される。プロキシサーバ５ａは、上記ＩＰパケットの宛先アドレスをコンテンツ要求の送信元となっていたクライアントのアドレスに書き換え、送信元アドレスをコンテンツ要求の宛先アドレスとなっていたスイッチアドレスに書き換えて、スイッチ３に送出する。これによって、ストリームサーバ４ａから送信されたコンテンツデータを含むＩＰパケットが、スイッチを介して要求元のクライアントに次々と転送されることになる。
【００２０】
図３は、本発明のプロキシサーバによるストリームコンテンツの配送方法を示す。
ストリームサーバ４ａは、ストリームコンテンツを複数のブロック（Ｄ１〜Ｄ４）に分割し、ＩＰパケット８０（８０−１〜８０−ｎ）として要求元のプロキシサーバ５ａに送信する。プロキシサーバ５ａは、受信コンテンツデータをＩＰパケット８１ａ（８１ａ−１〜８１ａ−ｎ）として要求元ユーザ端末、例えば、クライアント１ａに転送すると共に、これをキャッシュデータとしてキャッシュファイル５２ａに蓄積しておく。Ｐ０〜Ｐ４は、ストリームコンテンツ中での分割ブロックの境界位置を示している。
【００２１】
プロキシサーバ５ａが、コンテンツデータ８０をクライアント１ａに転送中、またはコンテンツ提供サービス完了後に、他のユーザ端末、例えば、クライアント１ｂが上記コンテンツデータについてコンテンツ要求を発行し、この要求がプロキシサーバ５ｂで受付けられた場合、本発明では、矢印８２で示すように、プロキシサーバ５ａのキャッシュファイル５２ａから読み出されたコンテンツデータをプロキシサーバ５ｂに供給することによって、２つのプロキシサーバ５ａ、５ｂによる同一ストリームコンテンツの並列的な提供サービスを可能とする。
【００２２】
また、プロキシサーバ５ａから供給されたストリームコンテンツをプロキシサーバ５ｂのキャッシュファイル５２ｂに蓄積しておくことによって、例えば、プロキシサーバ５ｃが更にクライアント１ｃからの同一ストリームコンテンツの要求を受付けた場合、矢印８３で示すように、プロキシサーバ５ｂからプロキシサーバ５ｃへのコンテンツデータの供給を可能とする。従って、本発明によれば、ストリームサーバ４ａの負荷を軽減して、プロキシサーバからクライアントへのストリームコンテンツの供給サービスが可能となる。
【００２３】
各プロキシサーバにおけるキャッシュデータの保有状態は、後述するように管理サーバ６によって管理される。プロキシサーバ間でのキャッシュデータの転送は、矢印４５ａ〜４５ｃで示すように、管理サーバ６とプロキシサーバ５ａ〜５ｃとの間での制御メッセージの交信と、要求元プロキシサーバから供給元プロキシサーバへのコンテンツ（キャッシュデータ）転送要求によって実行される。
【００２４】
図４は、プロキシサーバ５（５ａ〜５ｋ）の構成を示す。
プロキシサーバ５は、プロセッサ５０と、プロセッサ５０が実行する各種の制御プログラムを格納したプログラムメモリ５１と、ストリームコンテンツをキャッシュデータとして蓄積するためのキャッシュファイル５２と、スイッチ３と通信するための入力回線インタフェース５３および出力回線インタフェース５４と、入力回線インタフェース５３で受信されたパケットを一時的に蓄積するための受信バッファ５５と、出力回線インタフェース５４に接続された送信パケット一時蓄積用の送信バッファ５６と、データメモリ５９とからなる。データメモリ５９には、後述する接続管理テーブル５７とキャッシュ管理テーブル５８が形成されている。
【００２５】
図５は、管理サーバ６の構成を示す。
管理サーバ６は、プロセッサ６０と、プロセッサ６０が実行する各種の制御プログラムを格納したプログラムメモリ６１と、スイッチ３と通信するための入力回線インタフェース６３および出力回線インタフェース６４と、入力回線インタフェースで受信されたパケットを一時的に蓄積するための受信バッファ６５と、出力回線インタフェース６４に接続された送信パケット一時蓄積用の送信バッファ６６と、データメモリ６２とからなる。データメモリ６２には、後述する接続管理テーブル６７、キャッシュ管理テーブル６８、負荷管理テーブル６９が形成されている。
上記プロキシサーバ５と管理サーバ６は、システム管理者によるデータ入力を可能とするための入力装置と表示装置を備えているが、これらの要素は本発明の動作に直接関係しないため、図面では省略してある。
【００２６】
図６は、管理サーバ６が備える接続管理テーブル６７の１実施例を示す。
各プロキシサーバ５が備える接続管理テーブル５７も、管理サーバ６が備える接続管理テーブル６７と基本的に同様の構成となっているため、ここでは、図６を接続管理テーブル５７の説明にも利用する。但し、接続管理テーブル５７の登録エントリは、各プロキシサーバに固有のエントリに限定されている。
【００２７】
接続管理テーブル６７は、プロキシサーバ５ａ〜５ｋが実行中のコンテンツ要求を管理するための複数の接続管理エントリ６７０−１、６７０−２、…からなり、これらのエントリは、後述するように、管理サーバ６が各プロキシサーバから受信する要求受付通知Ｍ３（図１２）に基づいて生成される。また、プロキシサーバが備える接続管理テーブル５７の各エントリは、各プロキシサーバがクライアントから受信するコンテンツ要求（メッセージ）Ｍ１と、ストリームサーバから受信する最初のコンテンツパケットに付された制御パラメータに基づいて生成される。
【００２８】
コンテンツ要求Ｍ１は、例えば、図１１に示すように、ＩＰヘッダ１１とＴＣＰヘッダ１２に続いて、メッセージ種別１０１と、コンテンツ識別子１０２と、１つのストリーム中でユーザが送信を希望するコンテンツ部分の先頭位置を示す再生開始位置１０３とを含んでいる。
【００２９】
接続管理テーブル６７と５７の各エントリは、送信元ＩＰアドレス６７１Ａ、送信元ポート番号６７１Ｂ、宛先ＩＰアドレス６７１Ｃ、宛先ポート番号６７１Ｄと、プロキシサーバ識別子６７２、接続識別子６７３、コンテンツ識別子６７４、受付時刻６７５、開始位置６７６Ａ、サイズ６７６Ｂ、所要帯域６７７、キャッシュ利用フラグ６７８、コンテンツソース識別子６７９とからなっている。
【００３０】
プロキシサーバの接続管理テーブル５７では、各エントリの送信元ＩＰアドレス６７１Ａ、送信元ポート番号６７１Ｂは、コンテンツ要求Ｍ１に付されたＩＰヘッダ１１およびＴＣＰヘッダ１２から抽出された送信元ＩＰアドレスと送信元ポート番号の値が設定される。宛先アドレス６７１Ｃと宛先ポート番号６７１Ｄには、プロキシサーバからストリームサーバに転送されるコンテンツ要求Ｍ１’に付されたＩＰヘッダの宛先ＩＰアドレスとＴＣＰヘッダの宛先ポート番号の値が設定される。従って、宛先アドレス６７１ＣはストリームサーバのＩＰアドレスを示している。尚、コンテンツ要求Ｍ１’は、ＩＰヘッダとＴＣＰヘッダが異なるのみで、内容的には図１１に示したコンテンツ要求Ｍ１と同一であり、コンテンツ要求Ｍ１’のＴＣＰヘッダには、送信元ポートとして、プロキシサーバ各コネクションに割り当てた固有のポート番号（以下、プロキシポート番号と言う）が設定される。
【００３１】
管理サーバの接続管理テーブル６７では、各エントリの送信元ＩＰアドレス６７１Ａ、送信元ポート番号６７１Ｂ、宛先ＩＰアドレス６７１Ｃ、宛先ポート番号６７１Ｄには、要求受付通知Ｍ３に付されたＩＰヘッダ１１およびＴＣＰヘッダ１２から抽出された送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号の値が設定される。
【００３２】
プロキシサーバ識別子６７２は、コンテンツ要求Ｍ１を処理中のプロキシサーバのＩＰアドレスを示し、接続識別子６７３は、該プロキシサーバにおける接続管理エントリの識別子（管理番号）を示している。コンテンツ識別子６７４は、コンテンツ要求Ｍ１で指定されたコンテンツ識別子の値を示し、受付時刻６７５は、プロキシサーバにおけるコンテンツ要求Ｍ１の受付時刻を示す。開始位置６７６Ａには、コンテンツ要求Ｍ１で再生開始位置１０３として指定された値が設定され、サイズ６７６Ｂには、ストリームサーバから通知されたサイズ２１の値が設定される。上記開始位置６７６Ａとサイズ６７６Ｂによって、１つのストリームコンテンツのうち、プロキシサーバにキャッシュデータとして蓄積されるコンテンツの範囲が特定される。
【００３３】
所要帯域６７７には、ストリームサーバから通知される帯域２２の値が設定され、キャッシュ利用フラグ６７８は、コンテンツ要求Ｍ１に対してキャッシュデータが利用されたか否かを示す。コンテンツソース識別子６７９は、ストリームコンテンツの供給元となったストリームサーバまたはプロキシサーバの識別子を示す。
尚、各プロキシサーバが備えるコネクション管理テーブル５７の各エントリには、コンテンツ要求Ｍ１’に応答してストリームサーバから送信されるコンテンツパケットを要求元クライアントのアドレス情報に対応付けるために、図６に示した項目６７１Ａ〜６７９の他に、上述したプロキシポート番号が追加されている。
【００３４】
図７は、キャッシュ管理テーブル６８の１実施例を示す。
キャッシュ管理テーブル６８は、プロキシサーバ５ａ〜５ｋにキャッシュデータとして蓄積されているストリームコンテンツとその所在箇所を検索するためのものであり、それぞれコンテンツ識別子６８１と、データサイズ６８２と、開始位置６８３と、プロキシサーバ識別子６８４と、接続識別子６８５と、完了フラグ６８６とを示す複数のエントリ６８０−１、６８０−２、…が登録されている。完了フラグ６８６は、プロキシサーバがキャッシュデータを格納動作中（“０”）か、格納動作を完了（“１”）したかを示している。
【００３５】
各プロキシサーバ５が備えるキャッシュ管理テーブル５８も、図７に示したキャッシュ管理テーブル６８と同様の構成となっている。但し、登録エントリは、各プロキシサーバに固有のエントリに限定されている。
【００３６】
図８は、負荷管理テーブル６９の１実施例を示す。
負荷管理テーブルは、プロキシサーバ５ａ〜５ｋの負荷状態を記憶するためのものであり、プロキシサーバ５ａ〜５ｋの識別子６９１と対応した複数のエントリ６９０−１、６９０−２、…からなっている。各エントリは、サーバ識別子６９１と対応して、コネクション数６９２と、使用帯域６９３と、コネクション数の上限６９４と、帯域上限６９５を示している。コネクション数の上限６９４と帯域上限６９５の値は、プロキシサーバをサービスサイトに加えた時点でシステム管理者によって設定される。コネクション数６９２は、各プロキシサーバが現在処理中のコンテンツ要求の数を示し、使用帯域６９３は、これらのコネクションで現在使用中の通信帯域の合計値を示している。
【００３７】
図９は、各プロキシサーバ５のプログラムメモリ５１に用意され、要求メッセージの受信時にプロセッサ５０が実行する要求処理ルーチン５００の１実施例を示すフローチャートである。
プロセッサ５０は、受信した要求メッセージの種別を判定し（ステップ５０１）、受信メッセージがクライアントからのコンテンツ要求Ｍ１の場合は、要求されたコンテンツがキャッシュファイル５２にキャッシュデータとして蓄積されているか否かを判定する（５０２）。コンテンツ要求Ｍ１は、図１１に示したように、メッセージ種別１０１、コンテンツ識別子１０２、再生開始位置１０３を含んでいる。上記ステップ５０２では、キャッシュ管理テーブル５８を参照し、コンテンツ識別子６８１が上記コンテンツ識別子１０２に一致し、開始位置６８３が再生開始位置１０３を満たすエントリが登録済みか否かをチェックする。
【００３８】
要求されたコンテンツがキャッシュデータとして蓄積されていなければ、図示しないアドレステーブルから上記コンテンツ識別子１０２と対応するストリームサーバアドレスを検索する。ストリームサーバアドレスが不明の場合は、上記コンテンツ識別子指定してＤＮＳ７にサーバアドレスを問合せ（５０３）、ＤＮＳから回答されたサーバアドレスをもつストリームサーバに対してコンテンツ要求メッセージを転送し（５０４）、応答パケットが受信されるのを待つ（５０５）。この時、ストリームサーバに転送されるコンテンツ要求メッセージＭ１’は、クライアントから受信したコンテンツ要求Ｍ１のＩＰヘッダ１１に含まれる宛先アドレスをストリームサーバアドレスに、送信元アドレスを自アドレス（プロキシサーバアドレス）に書き換え、ＴＣＰヘッダの送信元ポート番号をプロキシポート番号に書き換えたものとなっている。
【００３９】
ストリームサーバから応答パケットを受信すると、プロセッサ５０は、応答種別を判定する（５０６）。受信した応答パケットがコンテンツパケットの場合は、受信パケットがコンテンツストリームの第１データブロックを含む最初のコンテンツパケットか否かを判定する（５０７）。最初のコンテンツパケットの場合は、キャッシュファイル５２に新たなストリームコンテンツを格納するためのキャッシュ領域を確保（５０８）した後、上記受信パケットから抽出したコンテンツデータを上記キャッシュ領域に格納し（５０９）、上記受信パケットのアドレスを変換して、コンテンツ要求元のクライアントに転送する（５１０）。
【００４０】
すなわち、コネクション管理テーブル５７から、宛先ＩＰアドレス６７１Ｃが受信パケットの送信元ＩＰアドレスと一致し、プロキシポート番号が受信パケットの宛先ポート番号と一致するエントリを検索し、ＩＰヘッダ１１の宛先アドレスと宛先ポートを上記エントリが示すコンテンツ要求元クライアントのＩＰアドレス６７１Ａとポート番号６７１Ｂの値に書き換え、送信元ＩＰアドレスをスイッチ３のアドレスに書き換えた後、上記受信メッセージをスイッチ３に送信する。この後、プロセッサ５０は、接続管理テーブル５７とキャッシュ管理テーブル５８に新たなエントリを追加し（５１１）、管理サーバ６に要求受付通知Ｍ３を送信（５１２）し、ステップ５０５に戻って次の応答パケットが受信されるのを待つ。
【００４１】
接続管理テーブル５７とキャッシュ管理テーブル５８に追加される新たなエントリは、図６、図７で説明した管理サーバ用の接続管理テーブル６７、キャッシュ管理テーブル６８の各エントリと同様の複数の項目からなり、これらのエントリは、コンテンツ要求Ｍ１の内容と、ストリームサーバから受信した最初のコンテンツパケットに付された制御パラメータに従って生成される。
【００４２】
上記要求受付通知Ｍ３は、図１２に示すように、ＩＰヘッダ１１、ＴＣＰヘッダ１２、メッセージ識別子１０１に続いて、プロキシサーバ識別子１１１、接続識別子１１２、コンテンツ識別子１０２、受付時刻１１３、再生開始位置１０３、サイズ１１４、所要帯域１１５、キャッシュ利用フラグ１１６、コンテンツソース識別子１１７を含んでいる。プロキシサーバ識別子１１１〜コンテンツソース識別子１１７には、接続管理テーブル５７に新たに登録されたエントリのプロキシサーバ識別子６７２〜コンテンツソース識別子６７９の値が設定される。この時点では、サイズ１１４は、最初のコンテンツパケットに付されたサイズ２１の値を示し、キャッシュ利用フラグ１１５は、キャッシュ未利用を示す状態（“０”）となっている。
【００４３】
受信パケットがコンテンツストリームの第２データブロック以降のデータブロックを含むコンテンツパケットの場合は、受信パケットから抽出したコンテンツデータをキャッシュファイルに格納し（５２０）、最初の受信パケットと同様、受信パケットのヘッダ情報を書き換えた後、コンテンツ要求元のクライアントに転送する（５２１）。上記受信パケットが、コンテンツストリームの最後のデータブロックを含む最終コンテンツパケットでなければ、ステップ５０５に戻り、次の応答パケットの受信を待つ。受信パケットが最終コンテンツパケットの場合は、管理サーバ６に応答完了通知Ｍ４を送信（５２３）した後、接続管理テーブル５７から不要となったエントリを削除し、キャッシュ管理テーブル５８で該当エントリの完了フラグ６８６を“１”に設定し（５２４）、コンテンツ要求処理を終了する。
【００４４】
応答完了通知Ｍ４は、例えば、図１３に示すように、ＩＰヘッダ１１、ＴＣＰヘッダ１２、メッセージ識別子１０１に続いて、プロキシサーバ識別子１１１、接続識別子１１２、コンテンツ識別子１０２、キャッシュ利用フラグ１１６、キャッシュデータサイズ１１８を含んでいる。プロキシサーバ識別子１１１〜キャッシュ利用フラグ１１６の値は、要求受付通知Ｍ３の値と同一であり、キャッシュデータサイズ１１８は、ステップ５０９、５２０でカウントされるキャッシュファイルに実際に格納されたコンテンツストリームのデータ長を示している。
【００４５】
ステップ５０５で受信した応答パケットが、管理サーバ６から出されたソース切替指令を含む場合、現在アクセス中のストリームサーバに対してサービスの中止（コネクションの切断）要求を送信し（５３０）、上記ソース切替指令で指定されたプロキシサーバに対してキャッシュデータ転送要求Ｍ２を送信して（５３１）、ステップ５０５に戻る。
上記キャッシュデータ転送要求Ｍ２は、図１１に示したコンテンツ要求Ｍ１と同一のフォーマットを有し、再生開始位置１０３には、ストリームサーバから既に受信済みデータブロックの次に位置したデータブロックの先頭を示す値が設定される。
【００４６】
ステップ５０１において、受信した要求メッセージが他のプロキシサーバからのキャッシュデータ転送要求Ｍ２の場合は、キャッシュファイル５２から上記要求Ｍ２で指定されたストリームコンテンツを読み出す（５４０）。コンテンツデータの読み出しは、図２で説明したように、所定長のデータブロック単位で行われ、各データブロックは、ＩＰヘッダ１１とＴＣＰヘッダ１２を付加したＩＰパケットとして、要求元のプロキシサーバに送信される（５４１）。最後のデータブロックが送信されると（５４２）、管理サーバに応答完了通知を送信し（５４３）、キャッシュデータ転送要求の処理を終了する。
【００４７】
ステップ５０２において、コンテンツ要求Ｍ１で要求されたコンテンツがキャッシュデータとして蓄積されていた場合は、図１０に示すように、キャッシュファイル５２から上記要求Ｍ１で指定されたストリームコンテンツを図２で説明したようにブロック単位で読み出し（５５０）、ＩＰパケットとして要求元のプロキシサーバに送信する（５５１）。最初のデータブロックを送信した場合は（５５２）、接続管理テーブル５７とキャッシュ管理テーブル５８に新たなエントリを追加し（５５３）、管理サーバ６に要求受付通知Ｍ３を送信する（５５４）。この場合、要求受付通知Ｍ３のキャッシュ利用フラグ１１６は、キャッシュ利用を示す“１”状態となっている。
【００４８】
上記要求受付通知Ｍ３に対して、管理サーバ６からは、現在のアクセスの継続を指示する応答が戻ってくるため、管理サーバからの応答受信に関係なくステップ５５０に戻って、キャッシュファイル５２から次のデータブロックを読み出し、要求元クライアントへのコンテンツパケットの送信を繰り返す。
コンテンツストリームの最後のデータブロックを送信した場合は、管理サーバ６に応答完了通知Ｍ４を送信（５６１）し、接続管理テーブル５７から不要となったエントリを削除して（５６２）、コンテンツ要求処理を終了する。
【００４９】
以上のように、本発明のプロキシサーバは、ストリームサーバから受信したコンテンツをクライアントへ転送する第１モードと、キャッシュファイルから読み出したコンテンツをクライアントへ転送する第２モードと、他のプロキシサーバから受信したコンテンツをクライアントへ転送する第３モードと、キャッシュファイルから読み出したコンテンツを他のプロキシサーバに送信する第４モードとを有し、第１モードから第３モードへの切替えと第４モードの実行は管理サーバ６によって制御される。
【００５０】
図１５は、管理サーバ６のプロセッサ６０が実行する通知処理ルーチン６００の１実施例を示すフローチャートである。
プロセッサ６０は、プロキシサーバから受信した通知メッセージの種別を判定し（ステップ６０１）、受信メッセージが要求受付通知Ｍ３の場合は、接続管理テーブル６７に上記要求受付通知Ｍ３と対応した新たなエントリ６７０−ｊを追加し、負荷管理テーブル６９を更新する（６０２）。上記エントリ６７０−ｊの送信元ＩＰアドレス６７１Ａ〜宛先ポート番号６７１Ｄの値は、受信メッセージＭ３のＩＰヘッダ１１とＴＣＰヘッダ１２から抽出され、プロキシサーバ識別子６７２〜コンテンツソース識別子６７９の値は、受信メッセージＭ３のプロキシサーバ識別子１１１〜コンテンツソース識別子１１７から得られる。また、負荷管理テーブル６９の更新では、上記要求受付通知Ｍ３のプロキシサーバ識別子１１１に一致したサーバ識別子６９１をもつエントリにおいて、コネクション数６９２の値がインクリメントされ、使用帯域６９３の値に上記要求受付通知Ｍ３が示すサイズ１１４の値が加算される。
【００５１】
プロセッサ６０は、要求受付通知Ｍ３のキャッシュ利用フラグ１１６を判定し（６０３）、キャッシュ利用状態（“１”）となっていた場合は、該要求受付通知Ｍ３の送信元となったプロキシサーバに対して、現在のアクセスの継続を指示する要求受付通知応答Ｍ５を送信して（６１０）、この処理を終了する。
【００５２】
要求受付通知応答Ｍ５は、例えば、図１４に示すように、ＩＰヘッダ１１、ＴＣＰヘッダ１２、メッセージ種別１０１に続いて、接続識別子１１２と切替先ソース識別子１２０を含んでいる。接続識別子１１２には、要求受付通知Ｍ３から抽出された接続識別子１１２の値が設定される。また、要求元のプロキシサーバに現在のアクセスの継続を指示する場合は、切替先ソース識別子１２０に所定値（例えば、オール“０”）が設定される。プロキシサーバは、上記切替先ソース識別子１２０の値から受信メッセージＭ５がソース切替を指示したものか、現在のアクセスの継続を指示したものかを判定できる。
【００５３】
要求受付通知Ｍ３のキャッシュ利用フラグ１１６がキャッシュ未利用（“０”）を示していた場合、プロセッサ６０は、キャッシュ管理テーブル６８からコンテンツ識別子６８１が上記要求受付通知Ｍ３のコンテンツ識別子１０２と一致するエントリを検索する（６０４）。コンテンツ識別子１０２と一致するエントリ６８０−ｊが見つかった場合は、負荷管理テーブル６９からサーバ識別子６９１が上記エントリ６８０−ｊのプロキシサーバ識別子６８４と一致するエントリ６９０−ｋを検索し、切替先候補となったプロキシサーバの負荷状態を判定する（６０６）。
【００５４】
プロキシサーバの負荷状態は、上記エントリ６９０−ｋのコネクション数６９２と使用帯域６９３の値をそれぞれ上限値６９４、６９５と比較し、予め決められた閾値状態に達しているか否かをチェックすることによって判定できる。例えば、インクリメントしたコネクション数が上限値６９４を超える時、または、使用帯域６９２に要求受付通知Ｍ３が示す所要帯域１１５を加えた値が上限値６９５を超える場合に、重負荷状態と判断してもよい。
【００５５】
切替先候補となったプロキシサーバが新たな負荷を受付できない（ソース切替え不可）重負荷状態の場合は（６０７）、ステップ６０４に戻って、キャッシュ管理テーブル６８からコンテンツ識別子１０２と一致する次の候補エントリを検索し、上記と同様の動作を繰り返す。
【００５６】
切替先候補となったプロキシサーバが軽負荷状態となっていた場合は、エントリ６９０−ｋのコネクション数６９２の値をインクリメントし、使用帯域６９３の値に上記要求受付通知Ｍ３が示すサイズ１１４の値を加算（６０８）した後、切替先ソース識別子１２０に上記エントリ６９０−ｋのサーバ識別子６９１の値を設定した要求受付通知応答（ソース切替指令）Ｍ５を作成し、これを上記要求受付通知Ｍ３の送信元プロキシサーバに送信する（６０９）。
【００５７】
切替先プロキシサーバが見つからないまま、キャッシュ管理テーブル６８の検索を完了した場合（６０５）は、要求受付通知Ｍ３の送信元プロキシサーバに対して、現在のアクセスの継続を指示する要求受付通知応答Ｍ５を送信して（６１０）、この処理を終了する。
【００５８】
ステップ６０１で、受信メッセージが応答完了通知Ｍ４の場合は、上記応答完了通知Ｍ４のコンテンツ識別子１０２とプロキシサーバ識別子１１１に基づいて、キャッシュ管理テーブル６８と負荷管理テーブル６９を更新する（６２０）。この場合、例えば、キャッシュ管理テーブル６８から上記コンテンツ識別子１０２とプロキシサーバ識別子１１１に一致するコンテンツ識別子６８１とプロキシサーバ識別子６８４をもつエントリ６８０−ｊを検索し、サイズ６８２を求める。次に、負荷管理テーブル６９から上記プロキシサーバ識別子１１１に一致するエントリを検索し、コネクション数６９２の値をデクリメントした後、使用帯域６９３の値から上記サイズ６８２が示す値を減算する。また、キャッシュ管理テーブル６８の上記エントリ６８０−ｊにおいて、サイズ６８２の値を上記応答完了通知Ｍ４が示すキャッシュデータサイズ１１７の値に書き換え、完了フラグ６８６を完了状態（“１”）に設定する。
【００５９】
この後、接続管理テーブル６７からプロキシサーバ識別子６７２と接続識別子６７３が上記応答完了通知Ｍ４のプロキシサーバ識別子１１１と接続識別子１１２に一致するエントリ（不要エントリ）を削除し（６２１）、応答完了通知Ｍ４の処理を終了する。
【００６０】
図１６は、図１に示したシステムにおいて、クライアント１ａからのコンテンツ要求Ｍ１がプロキシサーバ５ａに割当てられた時、プロキシサーバ５ａにも他のプロキシサーバにも、要求コンテンツのキャッシュデータが無かった場合のメッセージフローを示す。ここでは、既に説明したプロキシサーバ、管理サーバの機能との対応関係を明確にするために、図９、図１０、図１５と同一の符号が使用されている。
【００６１】
プロキシサーバ５ａは、キャッシュデータの有無を判定し（５０２）、キャッシュファイル５２に要求コンテンツのキャッシュデータが無いことが判明すると、ＤＮＳ７にサーバアドレスを問合せる（５０３Ａ）。プロキシサーバ５ａは、ＤＮＳからのサーバアドレスの通知を受けると（５０３Ｂ）、指定されたサーバ、例えば、ストリームサーバ４ａにアドレス変換されたコンテンツ要求Ｍ１’を送信する（５０４）。これによって、ストリームサーバ４ａからプロキシサーバ５ａへのコンテンツパケットの送信が開始される。
【００６２】
プロキシサーバ５ａは、最初のコンテンツパケット８０−１を受信すると、これをキャッシュファイルに格納し（５０８）、アドレスを書き換えて要求元のクライアント１ａに転送すると共に、管理サーバ６に要求受付通知Ｍ３を送信する（５１２）。この例では、他のプロキシサーバにも要求コンテンツのキャッシュデータがないため、管理サーバ６は、プロキシサーバ５ａにアクセス継続を指示する要求受付応答Ｍ５を送信する（６１０）。従って、プロキシサーバ５ａは、その後に受信されるコンテンツパケット８０−２〜８０−ｎをキャッシュファイルに格納し（５２０）、アドレスを書き換えて要求元のクライアント１ａに転送する（５２１）。最後のコンテンツパケット８０−ｎを転送した時、プロキシサーバ５ａは、管理サーバ６に応答完了通知Ｍ４を送信し、上記コンテンツ要求Ｍ１の処理動作を終了する。
【００６３】
図１７は、クライアント１ａからのコンテンツ要求Ｍ１を受付けたプロキシサーバ５ａが、要求コンテンツのキャッシュデータを持っていた場合のメッセージフローを示す。
プロキシサーバ５ａは、キャッシュファイル５２に要求コンテンツのキャッシュデータがあることが判明すると、キャッシュファイルからコンテンツデータの最初のブロックを読み出し、これをＩＰパケット８０−１としてクライアント１ａに転送し、管理サーバ６に要求受付通知Ｍ３を送信する（５５４）。管理サーバ６は、プロキシサーバ５ａにアクセス継続を指示する要求受付応答Ｍ５を送信する（６１０）。従って、プロキシサーバ５ａは、キャッシュファイルからコンテンツデータの後続ブロックを次々と読み出し（５５０）、コンテンツパケット８０−２〜８０−ｎとしてクライアント１ａに転送する（５５１）。最後のコンテンツパケット８０−ｎを転送した時、プロキシサーバ５ａは、管理サーバ６に応答完了通知Ｍ４を送信して、コンテンツ要求Ｍ１の処理動作を終了する。
【００６４】
図１８は、クライアント１ａから要求されたコンテンツのキャッシュデータが、要求を受付けたプロキシサーバ５ａには無く、他のプロキシサーバ５ｂにあった場合のメッセージフローを示す。
プロキシサーバ５ａから管理サーバ６に要求受付通知Ｍ３を送信するまでの動作シーケンスは、図１６と同様である。管理サーバ６は、プロキシサーバ５ｂに要求コンテンツのキャッシュデータがあり、プロキシサーバ５ｂがプロキシサーバ５ａにキャッシュデータを転送可能な状態にあることが判明すると、プロキシサーバ５ａに対して、ソース切替指令を示す要求受付応答Ｍ５を送信する（６０９）。
【００６５】
プロキシサーバ５ａは、上記要求受付応答Ｍ５を受信すると、現在アクセス中のストリームサーバ４ａにコネクションの切断を要求し（５３０）、上記要求受付応答Ｍ５で指定されたプロキシサーバ５ｂにキャッシュデータの転送要求Ｍ２を送信する（５３１）。プロキシサーバ５ｂは、上記キャッシュデータの転送要求Ｍ２を受信すると、キャッシュファイルから指定されたコンテンツデータを読み出し（５４０）、コンテンツパケット８０−２〜８０−ｎとして要求元のプロキシサーバ５ａに転送する（５４２）し、最後のコンテンツパケット８０−ｎを転送した時、管理サーバ６に応答完了通知Ｍ４’を送信して、要求Ｍ２の処理動作を終了する。
【００６６】
プロキシサーバ５ａは、プロキシサーバ５ｂから受信したコンテンツパケットをキャッシュファイル５２に格納する（５２０）と共に、要求元のクライアント１ａに転送する（５２１）。プロキシサーバ５ａは、最後のコンテンツパケットをクライアント１ａに転送した時、管理サーバ６に応答完了通知Ｍ４を送信し、要求Ｍ３の処理を終了する。
【００６７】
以上の実施例において、管理サーバ６は、キャッシュ管理テーブル６８と負荷管理テーブル６９を参照して、キャッシュデータ転送要求を受付可能なプロキシサーバを検索したが、例えば、要求コンテンツのキャッシュデータが複数のプロキシサーバに蓄積されていた場合、これらのプロキシサーバの中から負荷が最も軽い状態にあるサーバを見つけて、切替先プロキシサーバに指定するようにしてもよい。
【００６８】
また、実施例では、ストリームコンテンツの最後のデータブロックがクライアントに送信された時点で、各プロキシサーバから管理サーバに応答完了通知を送信し、キャッシュファイルに実際に蓄積されたコンテンツデータのサイズを管理サーバに通知するようにしたが、各プロキシサーバから管理サーバにコンテンツデータの蓄積量を時々刻々と通知し、管理サーバが、コンテンツデータ（キャッシュデータ）の蓄積量も考慮に入れて切替先プロキシサーバを選択するようにしてもよい。
【００６９】
コンテンツデータの蓄積量は、例えば、図９のフローチャートのステップ５２０でコンテンツデータの長さをカウントしておき、データ長の増加分が所定値に達する毎に、管理サーバに通知すればよい。ストリーム毎に受信したコンテンツパケットの個数をカウントしておき、Ｎパケット毎に現在のコンテンツデータ長を管理サーバに通知するようにしてもよい。
【００７０】
また、図９のフローチャートのステップ５０８で新たなストリームコンテンツ用のキャッシュ領域を確保するために、プロキシサーバが既存の何れかのストリームコンテンツを無効にした場合、プロキシサーバと管理サーバが互いに同期して、それぞれのキャッシュ管理テーブル５８、６８から、無効ストリームコンテンツと対応するエントリを削除する必要がある。このようなキャッシュ管理テーブル更新を実現するためには、例えば、図１２に示した要求受付通知Ｍ３のコンテンツ識別子１１７の次に、無効化コンテンツの識別子を追加し、管理サーバに無効ストリームコンテンツを通知し、管理サーバ側では、図１５に示したフローチャートのステップ６０２で、キャッシュ管理テーブル６８から上記無効化コンテンツの識別子に該当するエントリを削除するようにすればよい。無効化すべきコンテンツ（キャッシュデータ）の選択には、各種のアルゴリズムを適用できる。最も簡単な方法は、例えば、キャッシュ管理テーブル５８にキャッシュデータの最新の利用時刻を記憶しておき、この時刻情報から、登録エントリ中で最も旧いエントリを選択する。キャッシュファイルに新たに登録されたキャッシュは、登録時刻を最新利用時刻の初期値として設定し、例えば、図１０のステップ５５３の実行時に、上記最新利用時刻の値を更新すればよい。
【００７１】
上述した実施例では、管理サーバ６が、負荷管理テーブル６９をプロキシサーバ５ａ〜５ｋの負荷監視用として利用しているが、プロキシサーバ用の負荷管理テーブル６９とは別にストリームサーバ用の負荷管理テーブル６９Ｂを用意し、管理サーバがストリームサーバの負荷状態に応じて、コンテンツ要求の実行を制限するようにしてもよい。ストリームサーバ用の負荷管理テーブル６９Ｂは、プロキシサーバ用の負荷管理テーブル６９と同一の構成で、サーバ識別子６０１にストリームサーバ識別子を含む複数のエントリからなる。
【００７２】
上記負荷管理テーブル６９Ｂは、例えば、図１５に示したフローチャートのステップ６０２で更新できる。すなわち、受信した要求受付通知Ｍ３のキャッシュ利用フラグをチェックし、該フラグが“０”となっていた時、コンテンツソース識別子１１７に従って負荷管理テーブル６９Ｂを参照し、サーバ識別子６９１が上記コンテンツソース識別子１１７と一致するエントリを検索することによって、プロキシサーバ用の負荷管理テーブル６９と同様に、コネクション数６９２と使用帯域６９３の値を更新できる。コンテンツ要求の実行制限は、例えば、更新されたコネクション数６９２、使用帯域６９３の値をそれぞれの上限値６９４、６９５と比較し、コネクション数または使用帯域の何れかが上限値を超えた場合は、要求受付通知Ｍ３の送信元となったプロキシサーバにアクセス中止指令を含む応答メッセージを送信するようにすればよい。
【００７３】
上記アクセス中止指令を含む応答メッセージは、図９に示したフローチャートのステップ５０５で受信され、ステップ５０６で識別される。従って、各プロキシサーバには、上記アクセス中止指令を受信した時、ストリームサーバに切断を要求し、コンテンツ要求の発行元のクライアントに対して、ビジーによるコンテンツ供給サービスの中止を知らせるメッセージを送信させるようにすればよい。このように、ストリームサーバが重負荷状態にあるとき、新たに発生したコンテンツ要求の実行を中断することによって、現在実行中のコンテンツ配信サービスの品質低下を回避できる。
【００７４】
【発明の効果】
本発明の構成によれば、コンテンツ要求をコンテンツ識別子に無関係にプロキシサーバに振り分けた場合でも、プロキシサーバ間でキャッシュデータを共用できるため、ストリームサーバの負荷を軽減できる。また、同一ストリームのキャッシュデータを複数のプロキシサーバに持たせることによって、人気ストリームに対するコンテンツ要求を複数のプロキシサーバで並列的に処理することが可能となる。
【図面の簡単な説明】
【図１】本発明のプロキシサーバを適用したネットワークシステムの概略的な構成図。
【図２】ストリームコンテンツとコンテンツパケットとの関係を説明するための図。
【図３】本発明のプロキシサーバによるストリームコンテンツの配送方法を示す図。
【図４】プロキシサーバ５の構成を示す図。
【図５】管理サーバ６の構成を示す図。
【図６】管理サーバ６が備える接続管理テーブル６７の１実施例を示す図。
【図７】管理サーバ６が備えるキャッシュ管理テーブル６８の１実施例を示す図。
【図８】管理サーバ６が備える負荷管理テーブル６９の１実施例を示す図。
【図９】プロキシサーバ５で実行される要求処理ルーチン５００の１実施例を示すフローチャートの主要部を示す図。
【図１０】要求処理ルーチン５００の残り部分を示す図。
【図１１】クライアントから送信されるコンテンツ要求Ｍ１のメッセージフォーマットの１例を示す図。
【図１２】プロキシサーバから管理サーバに送信される要求受付通知Ｍ３のメッセージフォーマットの１例を示す図。
【図１３】プロキシサーバから管理サーバに送信される応答完了通知Ｍ４のメッセージフォーマットの１例を示す図。
【図１４】管理サーバからプロキシサーバに送信される要求受付通知応答Ｍ５のメッセージフォーマットの１例を示す図。
【図１５】管理サーバ６で実行される通知処理ルーチン６００の１実施例を示すフローチャート。
【図１６】コンテンツ要求を受信したプロキシサーバ５ａに要求コンテンツのキャッシュデータが無かった場合のメッセージフローを示す図。
【図１７】コンテンツ要求を受信したプロキシサーバ５ａに要求コンテンツのキャッシュデータが有った場合のメッセージフローを示す図。
【図１８】他のプロキシサーバ５ｂに要求コンテンツのキャッシュデータが有った場合のメッセージフローを示す図。
【符号の説明】
１：クライアント、２：ＩＰ網、３：スイッチ、４：ストリームサーバ、５：プロキシサーバ、６：管理サーバ、７：ＤＮＳ、４０：コンテンツファイル、５２：キャッシュファイル、５７、６７：接続管理テーブル、５８、６８：キャッシュ管理テーブル、６９：負荷管理テーブル。
【図１】
2004070860.tif 000003
【図２】
2004070860.tif 000004
【図３】
2004070860.tif 000005
【図４】
2004070860.tif 000006
【図５】
2004070860.tif 000007
【図６】
2004070860.tif 000008
【図７】
2004070860.tif 000009
【図８】
2004070860.tif 000010
【図９】
2004070860.tif 000011
【図１０】
2004070860.tif 000012
【図１１】
2004070860.tif 000013
【図１２】
2004070860.tif 000014
【図１３】
2004070860.tif 000015
【図１４】
2004070860.tif 000016
【図１５】
2004070860.tif 000017
【図１６】
2004070860.tif 000018
【図１７】
2004070860.tif 000019
【図１８】
2004070860.tif 000020