(57)【要約】【課題】複数のコンテンツのグループに対して輻輳制御を行えるクライアント装置を提供する。【解決手段】コンテンツを分割したオブジェクトを要求する要求パケットを、当該コンテンツの名前を含む名前情報に基づき転送するコンテンツ配信ネットワークのクライアント装置は、コンテンツが属するグループを示すグループ情報を保持する保持手段と、前記コンテンツ配信ネットワークに送信する前記要求パケットを、当該要求パケットが要求するコンテンツと前記グループ情報とに基づきグループに分類する分類手段と、グループ毎に、前記要求パケットの前記コンテンツ配信ネットワークへの送信タイミングを制御する制御手段と、を備えていることを特徴とする。【選択図】図２
2019145900.tif 000002
【特許請求の範囲】
【請求項１】
コンテンツを分割したオブジェクトを要求する要求パケットを、当該要求パケットに含まれる、当該コンテンツの名前を含む名前情報に基づき転送するコンテンツ配信ネットワークのクライアント装置であって、
コンテンツが属するグループを示すグループ情報を保持する保持手段と、
前記コンテンツ配信ネットワークに送信する前記要求パケットを、当該要求パケットが要求するコンテンツと前記グループ情報とに基づきグループに分類する分類手段と、
グループ毎に、前記要求パケットの前記コンテンツ配信ネットワークへの送信タイミングを制御する制御手段と、
を備えていることを特徴とするクライアント装置。
【請求項２】
前記名前情報は階層構造を有し、
前記クライアント装置は、
前記コンテンツ配信ネットワークに送信する前記要求パケットに含まれる前記名前情報の階層構造に基づき前記グループ情報を生成する生成手段をさらに備えていることを特徴とする請求項１に記載のクライアント装置。
【請求項３】
前記生成手段は、前記名前情報の下位側から所定数の階層を除いたプレフィクスが同じコンテンツを１つのグループとすることを特徴とする請求項２に記載のクライアント装置。
【請求項４】
前記生成手段は、前記名前情報を階層構造に従って木構造で表し、前記木構造のノードのうち、最もリーフ数が大きく、かつ、最も階層の深いノードを判定し、判定したノードに対応する前記名前情報のプレフィクスが同じコンテンツを１つのグループとすることを特徴とする請求項２に記載のクライアント装置。
【請求項５】
前記名前情報は階層構造を有し、
前記グループ情報は、前記名前情報の下位側から所定数の階層を除いたプレフィクスとグループとの対応関係を示し、
前記クライアント装置は、
前記コンテンツ配信ネットワークに送信する前記要求パケットに含まれる前記名前情報の下位側から前記所定数の階層を除いたプレフィクスに対応するグループが前記グループ情報に示されていないと、当該プレフィクスと新たなグループとの対応関係を前記グループ情報に追加する追加手段をさらに備えていることを特徴とする請求項１に記載のクライアント装置。
【請求項６】
前記グループ情報を前記コンテンツ配信ネットワークから取得する取得手段をさらに備えていることを特徴とする請求項１に記載のクライアント装置。
【請求項７】
前記要求パケットを送信してから前記要求パケットに含まれる名前情報が示す名前のオブジェクトを受信するまでのラウンド・トリップ時間を計測し、グループ内のコンテンツのラウンド・トリップ時間の平均値を計算する計算手段と、
第１グループ内の第１コンテンツのラウンド・トリップ時間の平均値と、当該第１グループの前記第１コンテンツとは異なるコンテンツのラウンド・トリップ時間の平均値との差が閾値以上であると、当該第１コンテンツが前記第１グループとは異なる第２グループとなる様に前記生成手段が生成したグループ情報を更新する更新手段をさらに備えていることを特徴とする請求項２から４のいずれか1項に記載のクライアント装置。
【請求項８】
前記要求パケットを送信してから前記要求パケットに含まれる名前情報が示す名前のオブジェクトを受信するまでのラウンド・トリップ時間を計測し、グループのラウンド・トリップ時間の平均値を計算する計算手段と、
第１グループのラウンド・トリップ時間の平均値と、第２グループのラウンド・トリップ時間の平均値との差が閾値以内であると、前記第１グループと前記第２グループとが同じグループとなる様に前記生成手段が生成したグループ情報を更新する更新手段をさらに備えていることを特徴とする請求項２から４のいずれか1項に記載のクライアント装置。
【請求項９】
前記コンテンツ配信ネットワークが前記要求パケットの応答として前記クライアント装置に送信するオブジェクトを含むデータ・パケットは、前記データ・パケットの送信元の装置の識別子、又は、前記データ・パケットの送信経路を示す情報を含み、
前記クライアント装置は、
前記送信元の装置の識別子、又は、前記データ・パケットの送信経路を示す情報に基づき、前記生成手段が生成したグループ情報を更新する更新手段をさらに備えていることを特徴とする請求項２から４のいずれか1項に記載のクライアント装置。
【請求項１０】
請求項１から９のいずれか１項に記載のクライアント装置としてコンピュータを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、コンテンツを１つ以上のオブジェクトに分割して配信するコンテンツ配信ネットワークのクライアント装置及びプログラムに関する。
【背景技術】
【０００２】
コンテンツを示す名前に基づきコンテンツの配信を行うネットワークが提案されている。特許文献１及び非特許文献１は、その様なネットワークの１つであるコンテンツ・セントリック・ネットワーク（ＣＣＮ：Ｃｏｎｔｅｎｔ  Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ）を開示している。
【０００３】
ＣＣＮにおいて、コンテンツを公開するサーバ装置は当該コンテンツを１つ以上のチャンクと呼ばれるオブジェクトに分割し、クライアント装置は、この分割されたオブジェクト単位でコンテンツを取得する。なお、例えば、コンテンツ名が"／ＡＡＡ／ＶＩＤＥＯ"であるコンテンツを１０個のオブジェクトに分割した場合、各オブジェクトには、"／ＡＡＡ／ＶＩＤＥＯ／１"〜"／ＡＡＡ／ＶＩＤＥＯ／１０"とのオブジェクト名が付与される。また、ＣＣＮにおいて、オブジェクトの転送を行った通信装置（以下、転送装置と呼ぶ。）は、当該オブジェクトを保持（キャッシュ）できる。この転送装置は、自装置が保持しているオブジェクトを要求するインタレスト・パケット（要求パケット）をクライアント装置から受信すると、当該インタレスト・パケットをサーバ装置に向けて転送することなく、自装置が保持するオブジェクトを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信できる。
【０００４】
以下に、転送装置の動作の一例を説明する。転送装置は、ＣＳ（Ｃｏｎｔｅｎｔｓ  Ｓｔｏｒｅ）と、ＦＩＢ（Ｆｏｒｗａｒｄｉｎｇ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）と、ＰＩＴ（ＰＩＴ：Ｐｅｎｄｉｎｇ  Ｉｎｔｅｒｅｓｔ  Ｔａｂｌｅ）と、を管理する。ＣＳは、自装置が保持しているオブジェクトを示す情報である。ＦＩＢは、オブジェクト名と、当該オブジェクト名のオブジェクトを要求するインタレスト・パケットを転送すべきインタフェースとの関係を示す情報である。なお、コンテンツ名（オブジェクト名）は階層構造をとるため、プレフィクスが共通するオブジェクト名を集約してＦＩＢのエントリとすることができる。つまり、例えば、"／ＡＡＡ／ＶＩＤＥＯ／１"〜"／ＡＡＡ／ＶＩＤＥＯ／１０"とのオブジェクト名それぞれに対して、ＦＩＢのエントリを設けるのではなく、"／ＡＡＡ／ＶＩＤＥＯ"をプレフィクスとするオブジェクト名について、１つのエントリ、つまり、１つの転送先インタフェースを示す様にＦＩＢを構成することができる。さらに、"／ＡＡＡ"をプレフィクスとするオブジェクト名について、１つのエントリとすることもできる。ＰＩＴは、転送したインタレスト・パケットが要求するオブジェクトと、当該転送したインタレスト・パケットを受信したインタフェースとの関係を示す情報である。
【０００５】
転送装置は、インタレスト・パケットを受信すると、ＣＳを検索し、当該インタレスト・パケットが要求するオブジェクトを保持しているか否かを判定する。保持している場合には、自装置が保持しているオブジェクトを含むデータ・パケットを、当該インタレスト・パケットの送信元のクライアント装置に向けて送信する。一方、受信したインタレスト・パケットが要求するオブジェクトを保持していない場合には、ＰＩＴを検索して、当該インタレスト・パケットと同じオブジェクトを要求するインタレスト・パケットを既に転送し、当該オブジェクトを含むデータ・パケットの受信待ちの状態であるかを判定する。受信待ちの状態であると、受信したインタレスト・パケットを転送せず、当該インタレスト・パケットの受信インタフェースを、当該インタレスト・パケットが要求するオブジェクトに関連付ける様にしてＰＩＴを更新する。一方、受信したインタレスト・パケットが要求するオブジェクトの受信待ちでなければ、ＦＩＢに基づき判定したインタフェースから当該インタレスト・パケットを転送すると共にＰＩＴを更新する。また、転送装置は、オブジェクトを含むデータ・パケットを受信すると、当該オブジェクトの転送先インタフェースをＰＩＴに基づき判定し、当該オブジェクトに関する情報をＰＩＴから削除する。また、転送装置は、受信して転送したオブジェクトを保存するとＣＳを更新する。
【０００６】
非特許文献２及び３は、ＣＣＮにおける輻輳制御を開示している。具体的には、あるコンテンツを取得する際、コンテンツを取得するクライアント装置は、送信したインタレスト・パケットの数と、受信したデータ・パケットの数とに基づき、後に送信するインタレスト・パケットの数やタイミングを制御することを非特許文献２及び３は開示している。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００９−２７７２３４号公報
【非特許文献】
【０００８】
【非特許文献１】Ｖ．Ｊａｃｏｂｓｏｎ，ｅｔ  ａｌ．，"Ｎｅｔｗｏｒｋｉｎｇ  Ｎａｍｅｄ  Ｃｏｎｔｅｎｔ"，ｉｎ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＡＣＭ  ＣｏＮＥＸＴ  ２００９，２００９年１２月
【非特許文献２】Ｓｃｈｎｅｉｄｅｒ，Ｋｌａｕｓ，ｅｔ  ａｌ．"Ａ  ｐｒａｃｔｉｃａｌ  ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ  ｓｃｈｅｍｅ  ｆｏｒ  ｎａｍｅｄ  ｄａｔａ  ｎｅｔｗｏｒｋｉｎｇ"，Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ｔｈｅ  ２０１６  ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  ３ｒｄ  ＡＣＭ  Ｃｏｎｆｅｒｅｎｃｅ  ｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ−Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ，ＡＣＭ，２０１６年
【非特許文献３】Ｃａｒｏｆｉｇｌｉｏ，ｅｔ  ａｌ．"Ｏｐｔｉｍａｌ  ｍｕｌｔｉｐａｔｈ  ｃｏｎｇｅｓｔｉｏｎ  ｃｏｎｔｒｏｌ  ａｎｄ  ｒｅｑｕｅｓｔ  ｆｏｒｗａｒｄｉｎｇ  ｉｎ  ｉｎｆｏｒｍａｔｉｏｎ−ｃｅｎｔｒｉｃ  ｎｅｔｗｏｒｋｓ：Ｐｒｏｔｏｃｏｌ  ｄｅｓｉｇｎ  ａｎｄ  ｅｘｐｅｒｉｍｅｎｔａｔｉｏｎ"，Ｃｏｍｐｕｔｅｒ  Ｎｅｔｗｏｒｋｓ，１１０，１０４−１１７，２０１６年
【発明の概要】
【発明が解決しようとする課題】
【０００９】
現在のインターネットのＷｅｂサービスや、動画配信サービスは、複数のコンテンツを組み合わせて提供されている。例えば、ブラウザでＷｅｂサーバにアクセスして動画を視聴する際には、Ｗｅｂページのコンテンツ、動画のコンテンツ、広告のコンテンツがそれぞれ、クライアント装置に配信される。しかしながら、非特許文献２及び３の構成は、コンテンツ毎に独立して輻輳制御を行うものである。つまり、非特許文献２及び３の構成において、異なるコンテンツの輻輳制御は、独立して行われる。したがって、同じサービスを構成する複数のコンテンツを並行して取得する際には輻輳制御が正常に行われず、ダウンロード時間が増加し得る。
【００１０】
本発明は、複数のコンテンツのグループに対して輻輳制御を行えるクライアント装置及びプログラムを提供するものである。
【課題を解決するための手段】
【００１１】
本発明の一態様によると、コンテンツを分割したオブジェクトを要求する要求パケットを、当該コンテンツの名前を含む名前情報に基づき転送するコンテンツ配信ネットワークのクライアント装置は、コンテンツが属するグループを示すグループ情報を保持する保持手段と、前記コンテンツ配信ネットワークに送信する前記要求パケットを、当該要求パケットが要求するコンテンツと前記グループ情報とに基づきグループに分類する分類手段と、グループ毎に、前記要求パケットの前記コンテンツ配信ネットワークへの送信タイミングを制御する制御手段と、を備えていることを特徴とする。
【発明の効果】
【００１２】
本発明によると、複数のコンテンツのグループに対して輻輳制御を行うことができる。
【図面の簡単な説明】
【００１３】
【図１】一実施形態によるクライアント装置の構成図。
【図２】一実施形態による輻輳制御部の構成図。
【図３】一実施形態によるキューＤＢを示す図。
【図４】一実施形態によるキューＤＢ構築処理の説明図。
【図５】一実施形態によるキューＤＢ構築処理の説明図。
【図６】一実施形態によるキューＤＢ変更処理の説明図。
【図７】一実施形態によるキューＤＢ変更処理の説明図。
【発明を実施するための形態】
【００１４】
以下、本発明の例示的な実施形態について図面を参照して説明する。なお、以下の各図においては実施形態の説明に必要ではない構成要素については図から省略する。また、以下の実施形態は例示であり本発明を実施形態の内容に限定するものではない。なお、以下の説明において、コンテンツ配信ネットワークがＣＣＮであるものとして説明を行う。しかしながら、本発明は、コンテンツを分割したオブジェクトを要求する要求パケットを、当該オブジェクトの名前に基づき転送するネットワークに適用することができる。なお、オブジェクトの名前は、コンテンツの名前を含むため、これらネットワークは、コンテンツを分割したオブジェクトを要求する要求パケットを、当該コンテンツの名前を含む名前情報に基づき転送するネットワークとみなすこともできる。
【００１５】
＜第一実施形態＞
図１は、本実施形態によるクライアント装置の構成図である。生成部１は、インタレスト・パケットを生成して輻輳制御部２に出力する。インタレスト・パケットは、要求するオブジェクトのオブジェクト名を含んでいる。図２は、輻輳制御部２の構成図である。キュー管理部２１は、キュー・データベース（キューＤＢ２１１）を有する。また、輻輳制御部２は、ｎ個のバッファ部２２−１から２２―ｎと、ｎ個の読出部２３−１〜２３−ｎを有する。ここで、バッファ部２２−ｋ及び読出部２３−ｋ（ｋは１〜ｎの整数）は、番号ｋのキュー（以下、キュー＃ｋと表示する。）を構成している。なお、数ｎは、固定値ではなく変数であり、キューの数は、キュー管理部２１がキューＤＢ２１１に基づき制御する。なお、キューの番号は、キューの識別子（キューＩＤ）でもある。
【００１６】
キュー管理部２１は、キューＤＢ２１１に基づき、入力されるインタレスト・パケットのキューＩＤを判定する。そして、判定したキューＩＤが＃ｋであると、当該インタレスト・パケットをキュー＃ｋのバッファ部２２−ｋに格納する。図３は、キューＤＢ２１１の一例を示している。キューＤＢ２１１は、オブジェクト名又はオブジェクト名のプレフィクスと、キューＩＤとの関係を示している。キュー管理部２１は、入力されるインタレスト・パケットに含まれるオブジェクト名と最も長く一致するエントリを判定し、判定したエントリのキューＩＤが、当該インタレスト・パケットのキューＩＤであると判定する。
【００１７】
例えば、インタレスト・パケットに含まれるオブジェクト名が"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／１"であると、／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"が対応するエントリであり、よって、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／１"のキューＩＤは＃２と判定される。また、インタレスト・パケットに含まれるオブジェクト名が"／ＡＡＡ／ｖｉｄｅｏ／ｍｏｕｓｅ／１"であると、／ＡＡＡ／ｖｉｄｅｏ"が対応するエントリであり、よって、"／ＡＡＡ／ｖｉｄｅｏ／ｍｏｕｓｅ／１"のキューＩＤは＃１と判定される。
【００１８】
このように、キューＤＢ２１１は、コンテンツが属するグループを示すグループ情報でもある。ここで、グループは、同じキューとなるコンテンツのグループである。キュー管理部２１は、生成部１から入力されるインタレスト・パケットを、各インタレスト・パケットが要求するコンテンツとキューＤＢ２１１に基づきグループに分類し、対応するグループのバッファ部２２−ｋにインタレスト・パケットを出力する。
【００１９】
読出部２３−ｋは、所定の輻輳制御のアルゴリズムに従い、バッファ部２２−ｋに格納されているインタレスト・パケットの送信タイミングを決定し、決定したタイミングでバッファ部２２−ｋに格納されているインタレスト・パケットを読み出して送受信部３に出力する。例えば、読出部２３−ｋは、キュー＃ｋから送信したインタレスト・パケットのうち、その応答としてデータ・パケットを受信していないインタレスト・パケットの数や、インタレスト・パケットを送信してから当該インタレスト・パケットに対するデータ・パケットを受信するまでのラウンド・トリップ・タイム（ＲＴＴ）等に基づき輻輳制御を行うことができる。この様に、各キューは、グループ毎（キュー毎）に、インタレスト・パケットのネットワークへの送信タイミングを制御する。
【００２０】
また、読出部２３−ｋは、インタレスト・パケットを送受信部３に出力すると、出力したインタレスト・パケットが要求するオブジェクト名を含む、インタレスト・パケットの送信情報を状態判定部４（図２）に通知する。また、状態判定部４は、受信したデータ・パケットに含まれるオブジェクトのオブジェクト名を含む、データ・パケットの受信情報を輻輳制御部２に出力する。輻輳制御部２は、データ・パケットの受信情報に基づき、送信済みであるが応答としてデータ・パケットを受信していないインタレスト・パケット及びその数や、ＲＴＴ等を判定する。
【００２１】
図２に戻り、送受信部３は、輻輳制御部２から出力されるインタレスト・パケットをネットワークに送信する。また、送受信部３は、ネットワークからデータ・パケットを受信すると、当該データ・パケットを状態判定部４に出力する。状態判定部４は、送受信部３からデータ・パケットを受信すると、受信情報を輻輳制御部２に通知するとともに、図示しないコンテンツ処理部に当該データ・パケットを出力する。
【００２２】
本実施形態において、クライアント装置は、あるサービスのコンテンツを取得する際、コンテンツの取得前に、当該サービスの提供者のサーバ装置からキューＤＢ２１１の情報を取得する。つまり、クライアント装置は、キューＤＢ２１１の情報を１つのコンテンツとしてまず取得し、キュー管理部２１は、取得した情報に基づきキューＤＢ２１１を構築する。なお、サービス提供者は、例えば、同じサーバ装置で公開しているコンテンツについては同じキューとし、コンテンツが格納されているサーバ装置が異なると異なるキューとすることができる。これは、同じサーバ装置に格納されているコンテンツについては、纏めて輻輳制御を行うことで、コンテンツの取得時間を短くできるからである。キュー管理部２１は、キューＤＢ２１１が示すキューの数をｎとして、キュー＃１〜キュー＃ｎを構成して、それぞれのキュー毎に輻輳制御を行ってインタレスト・パケットを送信する。この構成により、複数のコンテンツを纏めて輻輳制御の対象とすることができる。
【００２３】
＜第二実施形態＞
続いて、第二実施形態について第一実施形態との相違点を中心に説明する。第一実施形態において、クライアント装置は、キューＤＢ２１１を構築するための情報を事前にサービス提供者から取得していた。本実施形態では、クライアント装置が独自にキューＤＢ２１１を構築する。
【００２４】
例えば、ＣＣＮにおいて、コンテンツ名は、"／ＡＡＡ／ＢＢＢ／ＣＣＣ・・・"といった階層構造を有する。ここで、コンテンツ名のプレフィクスが一致する長さが長いコンテンツほど、同じサーバ装置に格納されている可能性が高い。そして、同じサーバ装置に格納されているコンテンツについては、配信される経路も同じである可能性が高く、よって、これらコンテンツの組を纏めて１つの輻輳制御の対象とすることで、効率よくコンテンツを取得することができる。したがって、本実施形態において、キュー管理部２１は、インタレスト・パケットを受信すると、当該インタレスト・パケットに含まれるオブジェクト名の末尾の所定数を除いたプレフィックス部分のエントリがキューＤＢ２１１に含まれているかを判定し、含まれていなければ、当該プレフィックス部分に新たなキューＩＤを割り当てて、キューＤＢ２１１に登録する。
【００２５】
図４は、本実施形態におけるキューＤＢ２１１の構築処理の説明図である。例えば、図４（Ａ）の１から６に示す順番で生成部１がインタレスト・パケットを送信したものとする。また、１番目のインタレスト・パケットを送信する前において、キューＤＢ２１１には、エントリがないものとする。また、キュー管理部２１は、オブジェクト名の末尾の２つの部分を除いたプレフィックス部分によりキューＤＢ２１１の構築処理を行うものとする。キュー管理部２１は、１番目のインタレスト・パケットを受信すると、当該インタレスト・パケットに含まれるオブジェクト名の末尾の２つの部分を除いた"/ＡＡＡ/ＢＢＢ/ｖｉｄｅｏ"のエントリがキューＤＢ２１１に存在するかを判定する。本例では、存在しないため、キュー管理部２１は、キューＩＤとして＃１を割り当て、"/ＡＡＡ/ＢＢＢ/ｖｉｄｅｏ"と＃１とを関連付けたエントリをキューＤＢ２１１に追加する。図４（Ｂ）の最初のエントリはこのエントリを示している。その後、キュー管理部２１は、１番目のインタレスト・パケットをバッファ部２２−１に出力する。
【００２６】
キュー管理部２１は、２番目のインタレスト・パケットを受信すると、当該インタレスト・パケットに含まれるオブジェクト名の末尾の２つの部分を除いた"/ＡＡＡ/ＢＢＢ/ｖｉｄｅｏ"のエントリがキューＤＢ２１１に存在するかを判定する。本例では、存在するため、キュー管理部２１は、２番目のインタレスト・パケットをバッファ部２２−１に出力する。３番目のインタレスト・パケットについても同様である。
【００２７】
キュー管理部２１は、４番目のインタレスト・パケットを受信すると、当該インタレスト・パケットに含まれるオブジェクト名の末尾の２つの部分を除いた"/ＡＡＡ/ＢＢＢ/ｔｒａｖｅｌ"のエントリがキューＤＢ２１１に存在するかを判定する。本例では、存在しないため、キュー管理部２１は、キューＩＤとして＃２を割り当て、"/ＡＡＡ/ＢＢＢ/ｔｒａｖｅｌ"と＃２とを関連付けたエントリをキューＤＢ２１１に追加する。図４（Ｂ）の２番目のエントリはこのエントリを示している。その後、キュー管理部２１は、４番目のインタレスト・パケットをバッファ部２２−２に出力する。
【００２８】
キュー管理部２１は、５番目のインタレスト・パケットを受信すると、当該インタレスト・パケットに含まれるオブジェクト名の末尾の２つの部分を除いた"/ＡＡＡ/ＢＢＢ/ｔｒａｖｅｌ"のエントリがキューＤＢ２１１に存在するかを判定する。本例では、存在するため、キュー管理部２１は、５番目のインタレスト・パケットをバッファ部２２−２に出力する。６番目のインタレスト・パケットについても同様である。
【００２９】
なお、上記説明において、キュー管理部２１は、生成部１からインタレスト・パケットを受信する度に、キューＤＢ２１１の情報と、受信したインタレスト・パケットが要求するオブジェクトのオブジェクト名を比較し、必要に応じてキューＤＢ２１１に新たなエントリを追加していた。しかしながら、あるサービスに含まれる１つ以上のコンテンツを取得する際には、これらコンテンツの名前をクライアント装置は既に知っている。したがって、サービスの１つ以上のコンテンツの取得を開始する前に、当該サービスに含まれる１つ以上のコンテンツの名前に基づき、キュー管理部２１がキューＤＢ２１１を生成する構成とすることもできる。
【００３０】
なお、例えば、オブジェクト名を木構造で表し、下流にあるリーフの数が最も多く、かつ、最も階層が深いノードに対応するプレフィクス部分を１つのキューとする構成とすることもできる。図５において、"／ｃ"配下のリーフの数は２であり、"／ｄ"配下のリーフの数は３であり、"／ｂ"配下の葉のリーフは５であり、"／ａ"配下のリーフの数は５である。したがって、図５の例において、リーフの数が最も多く、かつ、最も階層が深いプレフィクス部分は、"／ａ／ｂ"である。この場合、"／ａ／ｂ"をプレフィクスとして有するコンテンツを１つのグループとして１つのキューを割り当てることになる。
【００３１】
＜第三実施形態＞
第二実施形態では、クライアント装置が独自にキューＤＢ２１１を構築していた。本実施形態は、クライアント装置が独自に構築したキューＤＢ２１１を通信状態に応じて更新・修正するものである。図６は、キュー管理部２１が、例えば、あるサービスに含まれるコンテンツの名前情報に基づき構築したキューＤＢ２１１を示している。図６によると、"／ＡＡＡ／ｖｉｄｅｏ／ｄоｇ"と"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"には異なるキューが割り当てられている。キュー管理部２１は、状態判定部４からの受信情報に従いキューの過去所定数のＲＴＴの平均値を管理している。図６によると、"／ＡＡＡ／ｖｉｄｅｏ／ｄоｇ"のＲＴＴの平均値は１００ｍｓであり、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"のＲＴＴの平均値は２０ｍｓである。
【００３２】
ＣＣＮでは、転送装置がオブジェクトをキャッシュできるため、例えば、クライアント装置は、転送装置がキャッシュしているオブジェクトを取得する場合がある。しかしながら、転送装置がキャッシュできるオブジェクトは有限であり、あるコンテンツのオブジェクトを順に取得している際に、最初は、転送装置がキャッシュしていたオブジェクトを取得していたが、途中から、サーバ装置から取得する様になる場合がある。例えば、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／１"から"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５０"までをある転送装置がキャッシュしていたが、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５１"以降はいずれの転送装置にもキャッシュされておらず、サーバ装置のみが保持しているものとする。この場合、クライアント装置は、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５０"までは、オブジェクトを転送装置から取得する。そのときのＲＴＴの平均値が、図６に示す様に２０ｍｓであるものとする。しかしながら、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５１"は、サーバ装置から取得する様になるため、ＲＴＴがそれまでより長くなる。例えば、このサーバ装置が"／ＡＡＡ／ｖｉｄｅｏ／ｄоｇ"をプレフィクスとするオブジェクトも格納しているものである場合、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５１"以降のＲＴＴは、約１００ｍｓになる。
【００３３】
キュー管理部２１は、あるキューのＲＴＴが、それまでのＲＴＴの平均値と第１閾値以上乖離すると、第１閾値以上乖離してから所定数のＲＴＴの平均値を求め、それまでのＲＴＴの平均値と比較する。そして、所定数のＲＴＴの平均値とそれまでのＲＴＴの平均値との差が、依然、第１閾値以上であると、この所定数のＲＴＴの平均値との差が第２閾値以内であるＲＴＴに対応する他のキューを探索する。この所定数のＲＴＴの平均値との差が第２閾値以内であるＲＴＴに対応するキューがないと、キュー管理部２１は、当該キューについては、他のキューとマージすることなくそのまま、個別のキューとして管理する。一方、この所定数のＲＴＴの平均値との差が第２閾値以内であるＲＴＴに対応する他のキューがあると、キュー管理部２１は、当該キューを当該他のキューとマージする。例えば、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／５１"以降のＲＴＴの平均値が９８ｍｓであり、第２閾値を１０ｍｓとすると、キュー管理部２１は、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"に対応するキューＩＤを＃２から＃１に変更する。
【００３４】
また、キュー管理部２１は、１つのキューを分割することもできる。図７は、キュー管理部２１が構築したキューＤＢ２１１を示している。図７によると、"／ＡＡＡ／ｖｉｄｅｏ"にキュー＃１を割り当て、このキューのＲＴＴの平均値は１００ｍｓである。ここで、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ／ｘ"（ｘは任意の整数）のＲＴＴが、平均値である１００ｍｓから第３閾値以上乖離しはじめたものとする。この場合、キュー管理部２１は、乖離後から所定数の"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"をプレフィクスとするインタレスト・パケットのＲＴＴの平均値と、"／ＡＡＡ／ｖｉｄｅｏ"をプレフィクスとし、かつ、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"をプレフィクスとしないインタレスト・パケットのＲＴＴの平均値とを求めて、その差が第３閾値以上あるかを判定する。そして、第３閾値以上であると、例えば、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"には、キュー＃２を割り当て、"／ＡＡＡ／ｖｉｄｅｏ"をプレフィクスとし、かつ、"／ＡＡＡ／ｖｉｄｅｏ／ｃａｔ"をプレフィクスとしないインタレスト・パケットとは異なるキューとすることができる。
【００３５】
なお、キューの分離・統合はＲＴＴ以外の指標に基づき行うことができる。例えば、データ・パケットに送信元の識別子を格納する構成では、送信元の識別子に基づきキューを分離・統合する構成とすることができる。ここで、送信元の識別子とは、転送装置及びサーバ装置を識別する識別子である。キュー管理部２１は、異なるキューそれぞれについて、所定数のデータ・パケットに含まれる送信元の識別子のうち、最も多い識別子を判定する。そして、キュー管理部２１は、異なるキューの最も多い識別子が同じである場合、この異なるキューを１つのキューに統合することができる。また、キュー管理部２１は、同じキューについて、データ・パケットに含まれる送信元の識別子に基づきオブジェクト名をグループ化し、同じグループのオブジェクト名の最長のプレフィクスに基づきキューを分離することができる。なお、データ・パケットに送信元からクライアント装置までの経路情報を格納する場合にも同様に経路情報に基づきキューを分離・統合する構成とすることができる。
【００３６】
また、本発明によるクライアント装置は、コンピュータを上記クライアント装置として動作・機能させるプログラムにより実現することができる。これらコンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて、又は、ネットワーク経由で配布が可能なものである。
【符号の説明】
【００３７】
２１１：キュー・データベース、２１：キュー管理部、２２−１〜２２−ｎ：バッファ部、２３−１〜２３−ｋ：読出部
【図１】
2019145900.tif 000003
【図２】
2019145900.tif 000004
【図３】
2019145900.tif 000005
【図４】
2019145900.tif 000006
【図５】
2019145900.tif 000007
【図６】
2019145900.tif 000008
【図７】
2019145900.tif 000009