[1.コンテンツ配信システムの構成等]
始めに、図1を参照して、情報配信システムとしてのコンテンツ配信システムの概要構成等について説明する。
図1は、本実施形態に係るコンテンツ配信システムにおける各ノード装置の接続態様の一例を示す図である。
図1の下部枠501内に示すように、中継装置としてのIX(Internet eXchange)3、ISP(Internet Service Provider)4、DSL(Digital Subscriber Line)回線事業者の装置5a及び5b、FTTH(Fiber To The Home)回線事業者の装置6、及び通信回線(例えば、電話回線や光ケーブル等)7等によって、インターネット等のネットワーク(現実世界のネットワーク)8が構築されている。
そして、このようなネットワーク8を介して相互に接続された各ノード装置1a,1b,1c・・・1x,1y,1z・・には、IP(Internet Protocol)アドレス等の宛先情報を含むノード装置を示す情報(ノード情報)が割り当てられており、更に各ノード装置を特定するための固有の値としてのノードID(IDentifier)(装置情報)が割り当てられている。これらノードIDは複数のノード装置間で重複しないものである。なお、以下の説明において、ノード装置1a,1b,1c・・・1x,1y,1z・・・のうち何れかのノード装置を示す場合には、便宜上、ノード装置1という場合がある。
また、コンテンツ配信システムSにおいて、当該ノード装置1が、他のノード装置1の持つ情報にアクセスする際には、その情報を持つノード装置1の宛先情報(IPアドレス及びポート番号)を知っていなければならない。
このようなシステムの一例として、DHTを利用したアルゴリズムによって、図1の上部枠500内に示すような、オーバーレイネットワーク9が構築されることになる。つまり、このオーバーレイネットワーク9は、既存のネットワーク8を用いて形成された仮想的なリンクを構成するネットワークを意味する。
装置情報としてのノードIDは、各ノード装置を一意に識別することができるものであればよく、例えば、工場出荷時に予め割り振られる製造番号やマシン名等を共通のハッシュ関数(ハッシュアルゴリズム)によりハッシュ化して得たハッシュ値をGUID(Global Unique IDentifier)として用い、これらを組み合わせて、ノードIDとして各ノード装置1に用いることが可能である。
またノードIDは、ノード装置の最大運用台数を収容できるだけのbit数を持たせる必要がある。例えば、128bitの番号とすれば、2^128≒340×10^36台のノード装置を運用できる。実際には既知のハッシュ関数であるSHA−1(Secure Hash Algorithm 1)(生成桁数160bit)やMD5(Message Digest 5)(生成桁数120bit)を用いることが想定される。
また、コンテンツ配信システムSは、本発明の登録装置の一例としてのシステム管理サーバ100を備える。
システム管理サーバ100は、オーバーレイネットワーク9内の各ノード装置1にて共用されるコンテンツを投入し登録すると共に、ネットワーク内にあるコンテンツのタイトル、コンテンツID、コンテンツの価格等を含むコンテンツ登録情報をカタログリストとして全ノード装置1に配布するコンテンツ登録作業を行なう。更に、各ノード装置1によってコンテンツが購入されると、その購入情報を受け、ログとして管理し、決済の日に各ノード装置1のユーザの銀行口座等から購入金額の引き落としを行なう課金作業を行なう。更に、オーバーレイネットワーク9に新たに参加しようとするノード装置1から、システムに参加しているノード装置1のうち、最初にアクセスすべきノード装置1の問い合わせを受け、何れかのノード装置1をコンタクトノードとして紹介するコンタクトノード紹介作業を行なう。
[1−1.DHTの概要]
以下に、本実施形態に係る分散ハッシュテーブル(以下、DHT(Distributed Hash Table)という)を利用したアルゴリズムについて説明する。
本実施形態においては、DHTを利用したアルゴリズムによって構築されたオーバーレイネットワーク9を前提としており、このオーバーレイネットワーク9(図1の上部枠500内)に配置されたノード装置1を、オーバーレイネットワーク9に参加しているノード装置1という。言い換えれば、オーバーレイネットワーク9は、ノード装置1の参加により形成されている。このようなオーバーレイネットワーク9への参加は、参加していないノード装置1が、参加している任意のノード装置1に対して参加要求を示す参加要求情報としての参加メッセージを送信することによって行われる。
また、コンテンツ配信システムSに参加している複数のノード装置1には、1のノード装置1から他のノード装置1に配信される共用情報としてのコンテンツ(例えば、映画や音楽等)データが分散して保存(格納)されているが、当該コンテンツにも、それぞれのコンテンツ毎にユニーク(固有)な共用情報識別情報(以下、コンテンツIDという。)が付与される。
このコンテンツIDは、ノードIDと同様の長さ(例えば、128bit等)であって、コンテンツをコンテンツ配信システムSに投入して登録を行なうシステム管理サーバ100によって決定され各コンテンツに付与される。
図2は32bitでノードID及びコンテンツIDを付与し、ID空間上に図示したものである。図中黒点はノードIDを、黒ひし形はコンテンツIDを示し、反時計回りでIDが増加するものとする。
システム管理サーバ100が当該システムに新たなコンテンツを投入する際に、当該新たなコンテンツに付与するコンテンツIDを決定するが、コンテンツIDの決定の説明の前に、オーバーレイネットワーク9のID空間(識別情報空間)における、コンテンツと当該コンテンツを管理するノード装置1との関係について説明する。
図2に示すようなID空間において、どのノード装置1に、どのコンテンツが管理されるかは、コンテンツIDとノードIDとが「所定の関係」にあるか否かによって決定される。ここで、「所定の関係」とは、一定の規則の下に決定されるが、本実施形態においては、「あるコンテンツIDを有するコンテンツデータを管理するノード装置は、そのコンテンツIDに最も近接するノードIDを有するノード装置1である」という規則とする。つまり、コンテンツIDと最も近接する(例えば、上位桁がより多く一致する)ノードIDであって、コンテンツIDの値と同じかそれ以下の値となるノードIDを有するノード装置1が、当該コンテンツデータを保存するノード装置の所在情報を管理することとする。
ここで、「所定の関係」の定義は、当該コンテンツIDを超えず、コンテンツIDとノードIDとの差が一番少ないものとするが、本発明はこれに限定されず、各コンテンツデータの管理を各ノード装置1に割り振る際に、一貫していればよい。同図に示す例では、この定義に基づいて、コンテンツIDaは、ノードIDaを有するノード装置に管理され、コンテンツIDbは、ノードIDbを有するノード装置に管理される。また、コンテンツIDc、IDdは、ノードIDcを有するノード装置1に管理されるように、あるノード装置は複数の異なるコンテンツデータを管理することもある。
なお、ここで「管理」というのは、コンテンツを保存/保持していることを意味するのではなく、「コンテンツのデータ(コンテンツデータ)が何れのノード装置1に保存されているかを知っている」ことを言う。すなわち、図2において、ノードIDaを有するノード装置1は、コンテンツIDaを有するコンテンツが何れのノード装置1に保存されているかを知っており、ノードIDbを有するノード装置1及びノードIDcを有するノード装置1も同様に、それぞれコンテンツIDbを有するコンテンツ及びコンテンツIDc、IDdを有するコンテンツが何れのノード装置1に保存されているかを知っている、ということになる。
このように、あるコンテンツが何れのノード装置1に保存されているかを知っているノード装置を、そのコンテンツのルートノードと言う。つまり、ノードIDaを有するノード装置1は、コンテンツIDaを有するコンテンツのルートノードであって、ノードIDbを有するノード装置1は、コンテンツIDbを有するコンテンツのルートノードであって、ノードIDcを有するノード装置1は、コンテンツIDc、IDdを有するコンテンツのルートノードである。
ところで、人気のあるコンテンツは、多くのユーザからの需要がある(配信要求の頻度が多い)ので、安定したノード装置1がルートノードとなり管理することが望ましい。
そこで、システム管理サーバ100は、コンテンツの人気度と、オーバーレイネットワーク9に参加するノード装置1の安定度を把握し、各コンテンツのコンテンツIDを決定する。
上述したように、コンテンツIDとノードIDとが「所定の関係」である場合に、当該コンテンツを管理するルートノードが決定される。本実施形態では、コンテンツIDと最も近接するノードIDであって、当該コンテンツIDの値と同じかそれ以下の値となるノードIDを有するノード装置1がルートノードとなる。従って、システム管理サーバ100は、例えば、人気の高いコンテンツにコンテンツIDを付与する場合には、安定度の高いノード装置1のノードIDと同じ値か、それより大きい値であって、次に大きいノードID未満となるコンテンツIDを決定し、付与する。このようにしてコンテンツを管理すべきノード装置1を、コンテンツの人気度に応じた安定度を有するノード装置1として選択することができる。
[1−2.ルーティングテーブルの作成]
ここで、図3を参照して、DHTで用いるルーティングテーブルの作成手法の一例について説明する。
図3は、DHTにおけるルーティングテーブルの構成の一例を示す図である。
まず、図3(A)に示す如く、ID空間を幾つかのエリアに分割する。なお、このエリアはルーティングテーブルを作成するためにID空間を分割したものであって、実際には、16分割程度が良く用いられるが、説明を簡単にするためここでは4分割とし、IDをビット長16Bitの4進数で表すこととした。そして、ノード装置1NのノードIDを「10230210」とし、このノード装置1Nのルーティングテーブルを作る例について説明する。
(レベル1のルーティング)
まず、ID空間を4分割とすると、それぞれのエリアは4進数で表すと最大桁が異なる4つのエリア「0XXXXXXX」「1XXXXXXX」、「2XXXXXXX」、「3XXXXXXX」(Xは0から3の自然数、以下同様。)で分けられる。ノード装置1Nは、当該ノード装置1N自身のノードIDが「10230210」であるため、図中左下「1XXXXXXX」のエリアに存在することになる。そして、ノード装置1Nは、自分の存在するエリア(すなわち、「1XXXXXXX」のエリア)以外のエリアに存在するノード装置1を適当に選択し、当該ノードIDの宛先情報(IPアドレス及びポート番号)をレベル1のテーブルに記憶する。図4(A)がレベル1のテーブルの一例である。2列目はノード装置1N自身を示しているため、宛先情報(IPアドレス及びポート番号)を記憶する必要は無い。
(レベル2のルーティング)
次に、図3(B)に示す如く、上記ルーティングによって4分割したエリアのうち、自分の存在するエリアを更に4分割し、更に4つのエリア「10XXXXXX」「11XXXXXX」、「12XXXXXX」、「13XXXXXX」と分ける。そして、上記と同様に自分の存在するエリア以外のエリアに存在するノード装置1を適当に選択し、当該ノードIDの宛先情報(IPアドレス及びポート番号)をレベル2のテーブルに記憶する。図4(B)がレベル2のテーブルの一例である。1列目はノード装置1N自身を示しているため、宛先情報(IPアドレス及びポート番号)を記憶する必要は無い。
(レベル3のルーティング)
さらに、図3(C)に示す如く、上記ルーティングによって4分割したエリアのうち、自分の存在するエリアを更に4分割し、更に4つのエリア「100XXXXX」「101XXXXX」、「102XXXXX」、「103XXXXX」と分ける。そして、上記と同様に自分の存在するエリア以外のエリアに存在するノード装置1を適当に選択し、当該ノードIDの宛先情報(IPアドレス及びポート番号)をレベル1のテーブルに記憶する。図4(C)がレベル3のテーブルの一例である。3列目はノード装置1N自身を示しているため、宛先情報(IPアドレス及びポート番号)を記憶する必要は無く、2列目、4列目はそのエリアにノード装置が存在しないため空白となる。
このようにして、レベル4以下レベル8まで同様にルーティングテーブル図4(D)に示す如く作成することにより、16bitのID全てを網羅することができる。レベルが上がる毎にテーブルの中に空白が目立つようになる。
実際に、オーバーレイネットワーク9に未参加のノード装置1が、オーバーレイネットワーク9に参加して、上述したような構成になるようにテーブルを作るには、まず、オーバーレイネットワーク9に参加する際に、システム管理サーバ100に最初にアクセスすべきノード装置1(コンタクトノード)を問合せ、回答されたノード装置1(コンタクトノード)に対して参加依頼メッセージを送信すると共に、当該ノード装置1(コンタクトノード)からルーティングテーブルをコピーさせてもらう。また、メッセージの転送などの際に、他のノード装置1の存在を知ったタイミングで、その装置のノードIDがテーブルのどのマス目に適合するかを判断して、各テーブルの内容を追記(更新)していく。また、他のノード装置が脱退したことを知ったタイミングで、当該装置のノードIDをテーブルから削除する。
以上説明した手法に従って、ノード装置1が使用するルーティングテーブルが作成され、動的に追記(更新)されていく。
[1−3.コンテンツの人気度]
システム管理サーバ100では、様々な決定要因に基づいてコンテンツの人気度を決定し、当該人気度に応じた安定度のノード装置1をルートノードとしている。ここでは新たにシステムに投入するコンテンツの人気度を決定する際の決定手法と、システムに投入された後に、新たな人気度を決定する決定要因について説明する。
1−3−1 システム投入時のコンテンツの人気度
新たにシステムに投入するコンテンツの人気度を、過去に投入したコンテンツの人気度から予測する。
例えば、システム管理サーバ100の記憶部等に、「コンテンツ人気度管理テーブル」を記憶しておき、過去のコンテンツ投入後の人気度を記録しておく。例えば、コンテンツの人気度をA〜Cの3ランクに分類し、表1に示すような「コンテンツ人気度管理テーブル」として、各アーティスト毎にその実績を管理する。なお、Aが最も高く、B,Cの順で人気度が低くなる。
新たに投入するコンテンツのアーティストがSSSである場合には、これまでに投入した同じアーティストのコンテンツでは、人気度「A」となったコンテンツの数が最も多いので、新たなコンテンツの人気度も「A」として予測し決定する。
そして、この最も高い人気度「A」のコンテンツには、安定度の高いノード装置1が優先的にルートノードとして選ばれるよう、安定度の高いノード装置1の管理下にあるコンテンツID、すなわち、当該ノード装置1のノードIDと同じか、それより大きい値であって、次に大きいノードID未満となるコンテンツIDを、当該コンテンツのコンテンツIDとして決定する。
1−3−2 システム投入後のコンテンツの人気度
システムに投入された後のコンテンツの人気度を決定する決定要因について説明する。
(1)課金ログ
各ノード装置1のユーザが、コンテンツをダウンロード(複製)する際には、当該コンテンツの著作権等の権利を有する権利者に対して、システム管理サーバ100を通じて所定の対価の支払いを行なう。つまり、システム管理サーバ100では、各コンテンツについて、ユーザからの配信要求の頻度を示す配信要求頻度情報の一例として課金ログを管理する。課金ログは、ユーザの配信要求に伴うコンテンツ購入メッセージの受信回数を集計したものである。
従って、システム管理サーバ100では、コンテンツをシステムに投入した後は、システム管理サーバ100から当該コンテンツの課金ログを取得し、例えば、過去一週間におけるコンテンツ購入メッセージの受信回数(課金頻度)に応じて、換言すれば、配信要求頻度に応じて各コンテンツの人気度を決定(更新)することができる(表2参照)。
(2)ルートノードのインデックス情報の量
オーバーレイネットワーク9においては、コンテンツを保持するノード装置は、システム管理サーバ100から最初にコンテンツを保持するよう指定されたノード装置1だけでなく、当該コンテンツ保持ノードからコンテンツの配信を受けたノード装置1や、またこのノード装置1からコンテンツの配信を受けたノード装置1、といったように、様々なコンテンツ(例えば、映画や音楽等)データ(配信情報の一例)の複数の複製情報(以下、レプリカという)が複数のノード装置1に分散して保存(格納)される。
例えば、ノード装置1a及びノード装置1cには、タイトルがXXXの映画のコンテンツデータのレプリカが保存されており、一方、ノード装置1b及びノード装置1dには、タイトルがYYYの映画のコンテンツデータのレプリカが保存されるというように、複数のコンテンツ保持ノードであるノード装置1に分散されて保存される。また、これらのコンテンツデータのレプリカには、夫々、コンテンツ名(タイトル)及びコンテンツID(システム管理サーバ100によって付与される)等の情報が付加されている。
また、このように分散保存されているコンテンツデータのレプリカの所在を示すインデックス情報(当該レプリカを保存している各コンテンツ保持ノードのノード情報(ノードID、宛先情報(IPアドレス及びポート番号)等)を含む)は、上述したように、ルートノードにより管理されるようになっている。例えば、タイトルがXXXの映画のコンテンツデータのレプリカのインデックス情報は、そのコンテンツ(コンテンツID)のルートノードであるノード装置1fにより管理され、タイトルがYYYの映画のコンテンツデータのレプリカのインデックス情報は、そのコンテンツ(コンテンツID)のルートノードであるノード装置1dにより管理される。
コンテンツデータのレプリカを保存したノード装置1は、当該レプリカを保存したことをそのルートノードに知らせるために、そのレプリカに付加されているコンテンツID及び自己のノード情報(ノードID、宛先情報(IPアドレス及びポート番号)等)が含まれる公開(パブリッシュ)メッセージ(レプリカを保存したので、ノード情報の管理の要求を示す管理要求情報)を、そのルートノードに向けて送出する。これにより、メッセージは、コンテンツIDをキーとするDHTルーティングによってルートノードに到着することになる。
つまり、同一のコンテンツデータ(コンテンツIDが同一)のレプリカが、夫々、複数のノード装置1に保存されている場合であっても、かかるコンテンツデータのレプリカのインデックス情報は、1つのルートノードで管理することができる。
また、人気の高いコンテンツは、多くのノード装置1によりダウンロードされるため、そのレプリカは自然に増加する。一方、その後、人気の無くなってきたコンテンツは、ノード装置1により削除されるため、そのレプリカは自然に減少する。従って、コンテンツの人気度は、各コンテンツのルートノードが管理するコンテンツのレプリカの数により把握することができる。
従って、システム管理サーバ100では、コンテンツをシステムに投入した後は、当該コンテンツを管理するルートノードに、インデックス情報に含まれる全レプリカの数(保存装置数情報)を問い合わせ、当該レプリカの数をコンテンツの新たな人気度を決定付ける決定要因情報の一例として、当該レプリカの数に応じて当該コンテンツの人気度を決定(更新)することができる(表3参照)。
(3)各ノード装置1に配布されたカタログリストを通じて
ユーザが、配布されたカタログリストを参照してコンテンツの配信要求を行なうと、その旨がカタログリストの編集元であるシステム管理サーバ100に通知されるよう構成することにより、システム管理サーバ100では配信要求をリアルタイムに監視し、各コンテンツの配信要求頻度を把握することができる。
(4)コンテンツへのアクセス回数
システム管理サーバ100は、コンテンツのレプリカを保持する複数のノード装置1に、コンテンツへのアクセス回数を通知してもらうことにより、その回数からコンテンツの人気度を把握することもできる。
[1−4.ノード装置の安定度]
各ノード装置1の安定度を決定する決定要因について説明する。
ノード装置1の安定度は、オーバーレイネットワーク9へ参加している時間(参加持続時間)によって決定することができる。すなわち、参加持続時間が長いほど高い安定度が高いノード装置、参加持続時間が短いほど安定度が低いノード装置として決定することができる。
この場合、各ノード装置1が、自身の参加持続時間を計測して、参加持続時間に対応する安定度のランクが変更となったときに、自分がルートノードとして管理しているコンテンツIDのリストを、システム管理サーバ100へ通知する。参加持続時間と安定度の対応テーブルを表4に示す。
図5は、ノード装置1のシステム管理サーバ100への通知の様子をDHTのID空間にて示した概念図である。なお、図1中オーバーレイネットワーク9には15台のノード装置1が参加しているが、ここでは図示を簡単にするため、図5に示すように、8台のノード装置1がネットワークに参加しているものとして説明する。
図中、各ノード装置1に付された時間は、各ノード装置1の参加持続時間を示すものである。なお、ノード装置1の工場出荷時は参加持続時間は「0」である。一度オーバーレイネットワーク9へ参加したノード装置1が、何らかの原因によりオーバーレイネットワーク9から脱退した後、再度オーバーレイネットワーク9に参加する際には、参加持続時間が「0」にリセットされる。
図5に示す例によれば、ノード装置1aは、参加持続時間が「1日」であるので、安定度は「C」と低く、ノード装置1cは、参加持続時間が「21日」であるので、安定度は「A」と高い。
そして、ノード装置1fは、参加持続時間が5日となったので、安定度のランクがCからBに変更された旨を、自己がルートノードとなって管理しているコンテンツIDのリストと共にシステム管理サーバ100へ通知する。
このように、システム管理サーバ100では、オーバーレイネットワーク9に参加する全ノード装置1について、オーバーレイネットワーク9への参加持続時間に基づいて安定度を把握し、各ノード装置1の宛先情報(IPアドレス及びポート番号)と、安定度とを対応付けて管理する。
また、システム管理サーバ100が各ノード装置1の安定度を取得する他の手法として、システム管理サーバ100は、各コンテンツのコンテンツIDを決定(更新)する際、少なくとも1台以上の各ノード装置1に対して、オーバーレイネットワーク9への参加持続時間を問い合わせて(安定度問合せ手段)安定度を取得するよう構成することもできる。ノード装置1からの安定度ランク変更に伴う通知だけで管理するのでは、実際にあるコンテンツIDのルートノードとなるべきノード装置1が、今現在オーバーレイネットワーク9に参加しているか否かは不明であるが、コンテンツIDを決定(更新)する都度、直接各ノード装置1に参加持続時間を問い合わせて安定度を各ノード装置1から受信して(安定度受信手段)取得すれば、必ずオーバーレイネットワーク9に参加中のノード装置1をルートノードとして決定することができる。この場合、表4に示した「システム管理サーバ100へのアクセス回数に基づく安定度決定テーブル」を、システム管理サーバ100の記憶部等に記憶しておき、これを参照することにより、各ノード装置1から取得した参加持続時間に応じた安定度を容易に取得することができる。
また、本発明の安定度とは、オーバーレイネットワーク9への参加持続時間に限定されず、例えば、オーバーレイネットワーク9への脱退頻度を安定度としてもよい。ノード装置がオーバーレイネットワーク9から脱退すると、当該ノード装置1が管理していた、すなわち当該ノード装置1がルートノードであったコンテンツに関しては、上述した一定の規則に基づいて選ばれたノード装置1が新たなルートノードとならなければない。このようにオーバーレイネットワーク9への参加・脱退を繰り返すと、安定して動作しないノード装置1とノードIDが近いノード装置1にとって負担が増え、またその他のノード装置1にとっても、ルーティング経路やキャッシュ情報の更新が頻繁に発生することとなる。従って、オーバーレイネットワーク9への脱退頻度が少ないほど安定度が高く、オーバーレイネットワーク9への脱退頻度が多いほど安定度が低い。
この脱退頻度は、オーバーレイネットワーク9に参加する際に最初にアクセスするシステム管理サーバ100へのアクセス回数に反映される。
図6は、オーバーレイネットワーク9にノード装置1が参加する際の様子をDHTのID空間にて示した概念図である。
新たなノード装置1(新規参加ノード装置1)が、オーバーレイネットワーク9へ参加する際には、システム管理サーバ100に、最初にアクセスすべきノード装置1(コンタクトノード)を問合せ、回答されたノード装置1(コンタクトノード)に対して参加メッセージを送信する。
図中、ノード装置1に付された数字「0」〜「6」は、当該システム管理サーバ100へのアクセス回数を示すものである。なお、ノード装置1の工場出荷時はアクセス回数は「0」である。一度オーバーレイネットワーク9へ参加したノード装置1が、何らかの原因によりオーバーレイネットワーク9から脱退した後、再度オーバーレイネットワーク9に参加する際には、上記同様にしてシステム管理サーバ100にコンタクトノードの問合せを行なう必要がある。よって、システム管理サーバ100へのアクセス回数が多いノード装置1ほど、オーバーレイネットワーク9への脱退頻度が高く、安定度が低い。一方、システム管理サーバ100へのアクセス回数が少ないノード装置1ほど、オーバーレイネットワーク9への脱退頻度が低く、安定度が高い。
以下の表5に示す「システム管理サーバ100へのアクセス回数に基づく安定度決定テーブル」をシステム管理サーバ100の記憶部等に記憶しておき、当該テーブルを参照することによって、安定度とアクセス回数の対応付けを容易に行なうことができる。
図6に示す例によれば、ノード装置1aは、システム管理サーバ100へのアクセス回数が「6」であるので、安定度は「C」と低く、ノード装置1c、1iは、システム管理サーバ100へのアクセス回数が「2」であるので、安定度は「A」と高い。
そして、表5に示すような「ノード装置リスト」として管理する(表5参照)。
システム管理サーバ100が、新規参加ノード装置1にコンタクトノードを紹介する際には、比較的安定度の高いノード装置1を紹介するよう構成することが好ましい。従って、例えば図6に示す例では、システム管理サーバ100は、新規参加ノード装置1に、アクセス回数が「2」である安定度「A」のノード装置1cが紹介され、新規参加ノード装置1から当該ノード装置1cに対して参加メッセージが送信されている。
なお、コンタクトノードとして紹介するノード装置1が、毎回同じであると、略同じテーブル情報を持つノード装置1が複数できてしまうので、システム管理サーバ100は、比較的安定度の高いノード装置1が複数ある場合は、その中からランダムにコンタクトノードを選択するよう構成してもよい。比較的安定度の高いノード装置1が1台しか無い場合に、そのノード装置1だけが何度もコンタクトノードとして選択されてしまうような場合には、連続してコンタクトノードとして選択できる回数に閾値を設けるなどして、閾値を越えたときには、安定度に拘らず「コンテンツID管理テーブル」中からランダムにコンタクトノードを選択してもよい。
[2.各装置の構成等]
次に、システム管理サーバ100、ノード装置1の構成及び機能について説明する。
[2−1.システム管理サーバの構成等]
図7は、システム管理サーバ100の概要構成例を示すブロック図である。
図7に示すように、本実施形態に係るシステム管理サーバ100は、演算機能を有するCPU、作業用RAM(Random Access Memory)、各種データ及びプログラムを記録するROM(Read Only Memory)等から構成された制御部101と、上記コンテンツ自体としてのコンテンツデータ、その配信に必要な各種ルーティング用データ及びその他の必要なプログラム(本発明の登録処理プログラムを含む)等を記録保存(格納)するためのHDD(Hard Disc Drive)等から構成された記憶部102と、ネットワークを通じてシステムに含まれる各ノード装置1等との間の情報の通信制御を行なうための通信部103と、当該システム管理サーバ100を管理する管理者からの指示を受け付け当該指示に応じた指示信号を制御部101に出力する入力部(例えば、キーボード、マウス或いは、操作パネル等)104と、を備えて構成され、制御部101、記憶部102及び通信部103はバス105を介して相互にデータの授受が可能に接続されている。
記憶部102は、安定度記憶手段、評価値記憶手段として機能し、オーバーレイネットワーク9に含まれる各ノード装置1のノードID、宛先情報(IPアドレス(及びポート番号)、管理中のコンテンツの数、安定度、管理中コンテンツのコンテンツID及びコンテンツの人気度とを「コンテンツID管理テーブル」(表6参照)として記憶している。また、各ノード装置1がルートノードとなって管理すべき全てのコンテンツIDについて、使用済みであるか否かを、「使用フラグ」により判断できるようになっている。
また、記憶部102は、各コンテンツの配信用頻度情報の一例として、所定の期間(例えば、一週間等)のコンテンツ購入メッセージの受信回数を課金ログとして記憶する(表7参照)。そして、所定の期間毎に、課金ログを集計し、各コンテンツの人気度を把握して、人気度に応じたルートノードが各コンテンツに割り当てられているか否か、検討を行なう。
更に、記憶部102は、コンテンツ人気度管理テーブル(表1参照)を記憶し、過去の実績人気度を記録しておく。
そして、制御部101におけるCPUが記憶部102等に記録された各種プログラムを実行することにより、制御部101が、実施形態に係るシステム管理サーバ100としての全体動作を統括制御し、上記各構成部材と協動して、評価値入力手段、取得手段、選択手段、共用情報識別情報付与手段、登録要求通知手段、安定度問い合わせ手段、安定度受信手段、安定度記憶手段、評価値記憶手段、決定要因情報取得手段、評価値決定手段、評価値更新手段、変更通知手段、安定度記憶手段及び情報削除手段として機能し、当該システム管理サーバ100を本発明における登録装置として機能させる。
[2−2.ノード装置の構成等]
次に、ノード装置1の構成及び機能について説明する。
図8は、ノード装置1の概要構成例を示す図である。
図8に示すように、実施形態に係るノード装置1は、演算機能を有するCPU,作業用RAM,各種データ及びプログラムを記憶するROM等から構成されたコンピュータとしての制御部11と、各種データ(例えば、コンテンツデータのレプリカ、DHT)及びプログラム等を記憶保存(格納)するためのHDD等から構成されたノード情報記憶手段としての記憶部12(上記、コンテンツデータのレプリカは、保存されていないノード装置1もある)と、受信されたコンテンツデータのレプリカを一時蓄積するバッファメモリ13と、コンテンツデータのレプリカに含まれるエンコードされたビデオデータ(映像情報)及びオーディオデータ(音声情報)等をデコード(データ伸張や復号化等)するデコーダ部14と、当該デコードされたビデオデータ等に対して所定の描画処理を施しビデオ信号として出力する映像処理部15と、当該映像処理部15から出力されたビデオ信号に基づき映像表示するCRT,液晶ディスプレイ等の表示部16と、上記デコードされたオーディオデータをアナログオーディオ信号にD(Digital)/A(Analog)変換した後これをアンプにより増幅して出力する音声処理部17と、当該音声処理部17から出力されたオーディオ信号を音波として出力するスピーカ18と、ネットワーク8を通じて他のノード装置1との間の情報の通信制御を行なうための通信部20と、ユーザからの指示を受け付け当該指示に応じた指示信号を制御部11に対して与える入力部(例えば、キーボード、マウス、或いは、操作パネル等)21と、を備えて構成され、制御部11、記憶部12、バッファメモリ13、デコーダ部14、及び通信部20はバス22を介して相互に接続されている。
記憶部12は、オーバーレイネットワーク9に参加する際に最初にアクセスするシステム管理サーバ100の宛先情報(IPアドレス及びポート番号)を記憶する。また、自己のノードIDとして工場出荷時の製造番号をハッシュ化して得たGUID「XXXXXXXX」(Xは自然数であって、各ノード装置毎に固有の値である。)によるノードIDを記憶する。
また、記憶部12は、オーバーレイネットワーク9への参加持続時間と安定度の対応表(表4参照)を記憶し、制御部11は、当該対応表に基づいて安定度の変動があった場合にはシステム管理サーバ100へ通知を行なう。
そして、制御部11におけるCPUが記憶部11等に記録された各種プログラムを実行することにより、制御部11が、実施形態に係るノード装置1としての全体動作を統括制御し、上記各構成部材と協動して当該ノード装置1を本発明における情報処理装置として機能させる。
[3.各装置の処理動作]
続いて、各装置の動作例について図を用いて説明する。なお、以下に説明する処理は、本発明における共用情報の評価値(コンテンツの人気度)の決定要因情報を、システム管理サーバ100における課金ログの集計結果(配信要求頻度情報)とし、本発明における情報処理装置(ノード装置1)の安定度を、オーバーレイネットワーク9への参加持続時間とした場合の各装置の動作例である。
[3−1.ノード装置の処理]
初めに、図9を用いて各ノード装置にて実行される処理について説明する。図9は、ノード装置1における処理の一例を示すフローチャートであり、この処理は、制御部11の制御に基づいて実行され、また、ノード装置1の電源がオンとされることにより開始する。
先ず、制御部11は、記憶部12に予め記憶していたシステム管理サーバ100の宛先情報(IPアドレス及びポート番号)に基づいて、システム管理サーバ100にアクセスし、コンタクトノードの問合せメッセージを送信する(ステップS1)。そして、システム管理サーバ100から、コンタクトノード(オーバーレイネットワーク9に参加している何れかのノード装置1)の宛先情報(IPアドレス及びポート番号)を受信して、コンタクトノードの紹介を受ける(ステップS2)。
そして、ノード装置1内に具備する内蔵時計等を使用して、参加持続時間の計測を開始する(ステップS3)。そして、ステップS2にて受信した宛先情報(IPアドレス及びポート番号)に基づいて、紹介されたコンタクトノードへ参加依頼メッセージを送信する(ステップS4)
続いて、電源がオフとされたか否かを判定し(ステップS5)、オフとされた場合(ステップS5:Yes)には処理を終了し、オフとされていない場合(ステップS5:No)には、他のノード装置1からオーバーレイネットワーク9への新規コンテンツの管理を指示する公開メッセージ(パブリッシュメッセージ)、或いは既にオーバーレイネットワーク9にあるコンテンツの削除を指示する削除メッセージ(リトラクトメッセージ)を受信したか否かを判断する(ステップS6)。
そして、公開メッセージを受信した場合(ステップS6:公開)には、公開メッセージに含まれるコンテンツに関する情報(コンテンツID、コンテンツデータのレプリカの所在を示すインデックス情報等)を、記憶部12におけるインデックスキャッシュ領域(インデックス情報を記憶するためのキャッシュ領域)に登録する(ステップS7)。他方、削除メッセージを受信した場合(ステップS6:削除)には、削除メッセージに含まれるコンテンツに関する情報を、記憶部12におけるインデックスキャッシュ領域から削除する(ステップS8)。
そして、制御部11は、記憶部12に保存したDHTのルーティングテーブルを参照して、自己が、当該メッセージに含まれるコンテンツIDのルートノードであるか否かを判別する(ステップS9)。自己がルートノードであると判別された場合(例えば、自己のノードIDが当該コンテンツIDと最も近い(例えば、上位桁がより多く一致する)場合)には(ステップS9:Yes)、ステップS4に移行する。
一方、ステップS9の判定において、自己がルートノードでない(言い換えれば、キャッシュノードである)と判別された場合(例えば、自己以外に当該コンテンツIDと最も近い(例えば、上位桁がより多く一致する)ノードIDを有するノード装置1がDHTのルーティングテーブルに登録されている場合)には(ステップS9:No)、制御部11は、自己のDHTのルーティングテーブルから、転送先のノード装置1(例えば、上記コンテンツIDと最も近い(例えば、上位桁がより多く一致する)ノードIDを有するノード装置)の宛先情報(IPアドレス及びポート番号)を取得し、その宛先情報(IPアドレス及びポート番号)宛てに、ステップS6にて受信したメッセージを転送し(ステップS10)、ステップS5に移行する。
この公開又は削除メッセージは、各ノード装置1が有するDHTのルーティングテーブルに基づいてルートノードまで転送される。例えば、図10に示すように、コンテンツID“22222222”に関するメッセージ(パブリッシュ、リトラクト、或いはコンテンツデータのレプリカの所在の問合せなど)が、コンテンツ保持ノードであるノード装置1aから送信された場合には、当該メッセージがノード装置1b、ノード装置1dと転送され、コンテンツID“22222222”のルートノードのノード装置1cまで転送される。このメッセージが公開メッセージ(パブリッシュメッセージ)である場合には、ノード装置1b、1d、1cは自己のキャッシュ領域にコンテンツID“22222222”を含むコンテンツに関する情報(例えば、コンテンツデータのレプリカの所在を示すインデックス情報等)を登録し、削除メッセージ(リトラクトメッセージ)である場合には、ノード装置1b、1d、1cは自己のキャッシュ領域にあるコンテンツID“22222222”に関する情報を削除する。
また、ステップS6の判定において、コンテンツの公開・削除メッセージを受信していない場合(ステップS6:No)には、コンテンツID変更メッセージを受信したか否かを判定し(ステップS11)、コンテンツID変更メッセージを、システム管理サーバ100から受信した場合には、自己が当該コンテンツID変更メッセージにかかるコンテンツのルートノード(変更前のルートノード)であるので、指定されたコンテンツを保持するコンテンツ保持ノードにコンテンツID変更メッセージを送信(ステップS12)する。
このコンテンツID変更メッセージは、後に詳述するシステム管理サーバ100の指示によって、コンテンツの人気度の変動、或いはルートノードの安定度の変動に起因して、コンテンツIDの変更、すなわちルートノードの変更を指示するメッセージである。このコンテンツID変更メッセージは、システム管理サーバ100から、ID変更前のルートノードが受信し、そして、変更対象となるコンテンツを保持するノード装置1に対して送出される(ステップS11、12)。つまり、このコンテンツID変更メッセージをシステム管理サーバ100から受信した場合は、自身がコンテンツID変更前のルートノードであり、コンテンツID変更メッセージを他のノード装置1から受信した場合は、自身が当該コンテンツID変更メッセージに係るコンテンツを保持するコンテンツ保持ノードであって、送信元の他のノード装置1がコンテンツID変更前のルートノードである。
従って、コンテンツID変更メッセージを他のノード装置1から受信した場合は、自己が保持するコンテンツのうち、メッセージにかかるコンテンツIDを新たなコンテンツIDに変更する(ステップS13)。そして、新たなコンテンツIDをキーとして、DHTルーティングに従って公開メッセージ(パブリッシュメッセージ)を新たなルートノードに向けて送信(ステップS14)し、ステップS5に移行する。
なお、自己が当該コンテンツを保持するコンテンツ保持ノードである場合には、変更前のコンテンツIDをキーとして、DHTルーティングに従って、削除メッセージ(リトラクトメッセージ)を変更前のルートノードに向けて送信する。
つまり、削除メッセージは、変更前のコンテンツIDに従って、各ノード装置1が有するDHTのルーティングテーブルに基づいてID変更前のルートノードに辿りつき、公開メッセージは、変更後のコンテンツIDに従って、各ノード装置1が有するDHTのルーティングテーブルに基づいてID変更後のルートノードに辿りつく。
図11を用いて具体的に説明すると、コンテンツID変更メッセージ、公開メッセージ及び削除メッセージの様子をDHTのID空間にて示す。コンテンツID変更メッセージ(一点鎖線)は、システム管理サーバ100からID変更前のルートノードであるノード装置1fへと送信され、これを受けたノード装置1fは、コンテンツID変更メッセージに係るコンテンツを保持するコンテンツ保持ノードであるノード装置1dへとコンテンツID変更メッセージを送信する。コンテンツID変更メッセージは、DHTルーティングに依らず、各ノード装置1の宛先情報を知っている装置同士で直接授受されるものである。
一方、削除メッセージ(実線)は、コンテンツID変更メッセージを受信したコンテンツ保持ノードであるノード装置1dから、DHTルーティングに従って各ノード装置1間を転送し、コンテンツID変更前のルートノードであるノード装置1fに辿りつく。このとき、削除メッセージを転送した各ノード装置1i、1aは、当該コンテンツのID変更前のキャッシュであるため、キャッシュを削除する(ステップS8)ようになっている。従って、コンテンツID変更前のルートノードとキャッシュを保持するノード装置1は、誤りなく当該コンテンツに係る情報を削除することができる。
また、公開メッセージ(破線)は、コンテンツID変更メッセージを受信したコンテンツ保持ノードであるノード装置1dから、DHTルーティングに従って各ノード装置1間を転送し、コンテンツID変更後のルートノードであるノード装置1eに辿りつく。このとき、公開メッセージを転送した各ノード装置1k、1iは、当該コンテンツのID変更後の新たなキャッシュであるため、当該コンテンツデータをキャッシュとして登録する(ステップS7)ようになっている。
引き続き図9のフローチャートの説明を続ける。コンテンツID変更メッセージを受信していない場合(ステップS11:No)には、新たにオーバーレイネットワーク9に参加しようとするノード装置1から、参加依頼メッセージを受信したか否かを判定(ステップS15)し、参加依頼メッセージを受信した場合(ステップS15:Yes)には、自己が所持しているルーティングテーブルを参加依頼メッセージの送信元のノード装置へ送信(ステップS16)して、ステップS5へ移行する。
参加依頼メッセージを受信していない場合(ステップS15:No)には、その他のメッセージを受信したか否かを判定(ステップS17)し、受信した場合(ステップS17:Yes)には、当該メッセージに対応する処理を実行(ステップS18)し、その他のメッセージを受信していない場合(ステップS17:No)には、ノード装置1にて行なわれるべき「その他の処理」を実行し(ステップ19)、ステップS5へ移行する。なお、当該その他のメッセージには、他のノード装置1及びシステム管理サーバ100との、各種情報のやり取り等が含まれる。
そして、ステップS5〜S19の処理が、電源がオフ(ステップS5:Yes)とされるまで繰り返し実行される。
続いて、ステップS19において実行される「その他の処理」の一例について、図12のフローチャートを用いて説明する。ここでは「その他の処理」を、主にルーティングテーブルの書換え処理と、安定度の確認処理に係る処理として説明する。
先ず、他のノード装置1からテーブル情報を受信したか否かを判定(ステップS31)し、テーブル情報を受信した場合(ステップS31:Yes)には、記憶部12に記憶する自己のルーティングテーブルを追記(更新)する(ステップS32)。
一方、テーブル情報を受信していない場合(ステップS31:No)には、計測されたオーバーレイネットワーク9への参加持続時間に基づいて、対応する安定度を取得する(ステップS34)。
そして、安定度のランクが変更されているか否かを判定し(ステップS35)、変更されている場合(ステップS35:Yes)には、自身がルートノードとして管理しているコンテンツがあるか否かを判定する(ステップS36)。安定度が変更されていない場合(ステップS35:No)、そのまま処理を終了する。
そして、ステップS36の判定において、ルートノードとして管理しているコンテンツが無い場合(ステップS36:No)には、安定度が変更されたことを示す旨の安定度変更メッセージ(変更後の安定度を含む)をシステム管理サーバ100に通知(ステップS37)して、処理を終了する。
他方、ステップS36の判定において、ルートノードとして管理しているコンテンツがある場合(ステップS36:Yes)には、管理しているコンテンツIDリストを生成(ステップS38)し、図5を用いて前述したように当該リスト及び変更後の安定度を含む安定度変更メッセージをシステム管理サーバ100に通知(ステップS39)して、処理を終了する。
[3−2.システム管理サーバの処理]
続いて、図13を用いてシステム管理サーバ100にて実行される処理について説明する。この処理は、登録処理プログラムが制御部101の制御に基づいて実行され、また、システム管理サーバ100の電源がオンとされることにより開始する。
制御部101は、コンタクトノードの問合せメッセージを受信したか否かを判定(ステップ100)し、受信していない場合(ステップS100:No)にはステップS104へ移行する。
一方、コンタクトノードの問合せメッセージを受信した場合(ステップS100:Yes)には、記憶部102に記憶した「コンテンツID管理テーブル」(表6参照)にコンタクトノードの問合せ元のノード装置1があるか否かを判定(ステップS101)し、「コンテンツID管理テーブル」にコンタクトノードの問合せ元のノード装置1がない場合(ステップS101:No)には、「コンテンツID管理テーブル」に問合せ元のノード装置1を追加(ステップS102)し、ステップS103に移行する。
そして、「コンテンツID管理テーブル」にある場合(ステップS101:Yes)、又は、ステップS102にて問い合わせもとのノード装置1を追加した後に、「コンテンツID管理テーブル」中の何れかのノード装置1を、コンタクトノードとして選択し、当該ノード装置1の宛先情報(IPアドレス情報及びポート番号)を問合せ元のノード装置1に送信(ステップS103)し、ステップS115へ移行する。
ステップS100の判定において、コンタクトノードの問合せメッセージを受信していない場合(ステップS100:No)には、オーバーレイネットワーク9に含まれるノード装置1からコンテンツ購入メッセージを受信したか否かを判定(ステップS104)し、制御部101が決定要因情報取得手段として機能してコンテンツ購入メッセージを受信した場合(ステップS104:Yes)には、当該コンテンツ購入メッセージに係るコンテンツの課金ログ(表7参照)を更新する(ステップS105)。
続いて、前回の課金ログ集計から所定の期間(例えば、一週間等)が経過したか否かを判定(ステップS106)し、経過している場合(ステップS106:Yes)には、課金ログを集計する(ステップS107)。所定期間が経過していないと判定された場合(ステップS106:No)には、ステップS115へ移行する。
そして、「コンテンツID管理テーブル」(表6参照) の各コンテンツについて、各ルートノードが適切か否かを判定する(ステップS108)。具体的には、制御部101が評価値決定手段及び評価値更新手段として機能し、ステップS107にて集計した課金ログに基づいて、最新のコンテンツの人気度を決定し、「コンテンツID管理テーブル」に登録されているコンテンツの人気度を更新すると共に、現在のルートノードが、更新後の人気度に応じた安定度を有するか否かに基づいて、現在のルートノードが適切であるか判定する。
判定の結果、ルートノードが適切でない場合(ステップS108:No)には、各コンテンツについて「ルートノード変更処理」(後に説明する。)を行なう(ステップS109)。
「コンテンツID管理テーブル」の全てのコンテンツについてルートノード適否判断及びルートノード変更処理(ステップS108、109)を行なった後、又は、ステップS108の判定の結果、ルートノードが適切であった場合(ステップS108:Yes)には、ステップS115へ移行する。
一方、コンテンツ購入メッセージを受信していない場合(ステップS104:No)には、オーバーレイネットワーク9に含まれるノード装置1から安定度変更メッセージを受信したか否かを判定(ステップS110)し、安定度変更メッセージを受信した場合(ステップS110:Yes)には、安定度変更メッセージにコンテンツIDリストを含むか否かを判定(ステップS111)し、含まない場合(ステップS110:No)には、「コンテンツID管理テーブル」にある、当該安定度変更メッセージの送信元のノード装置1の安定度を、安定度変更メッセージに含まれる変更後の安定度に従って更新する(ステップS112)。
安定度変更メッセージにコンテンツIDリストを含む場合(ステップS111:Yes)には、当該リストに含まれる全てのコンテンツについて、「ルートノード変更処理」(後に説明する。)を行なう(ステップS113、S114)。
そして、メッセージ送信元のノード装置1の安定度を更新(ステップS112)した後、又はコンテンツIDリスト中の全てのコンテンツについて「ルートノード変更処理」を行った(ステップS113、S114)後に、その他の処理ステップS115を行い、ステップS116にて、電源がオフとされたか否かを判定(ステップS116)し、電源がオフとされるまで、ステップS100乃至ステップS115の処理を繰り返し行なう。
次に、上記ステップS109及びS114における「ルートノード変更処理」について、図14を用いて説明する。
先ず、「コンテンツID決定(変更)処理」(後に説明する。)を行ない(ステップS140)、変更後のコンテンツIDに対応するルートノードとして決定されたノード装置1が、現在のルートノードと同じランクの安定度を有するノード装置1であるか否かを判定する(ステップS141)。現在のルートノードと同じランクの安定度を有するノード装置1である場合(ステップS141:Yes)には、ルートノードを変更する必要はないので、処理を終了する。
一方、同じランクの安定度で無い場合(ステップS141:No)には、制御部101は、共用情報識別情報付与手段及び変更通知手段として機能し、「コンテンツID決定(変更)処理」にて決定されたコンテンツIDを、当該コンテンツに付与し、現在のルートノードへコンテンツID変更メッセージを送信する(ステップS142)。図11に示す例の場合、現在の(ID変更前の)ルートノードであるノード装置1fにコンテンツID変更メッセージを送信している。
そして、評価値記憶手段、安定度記憶手段としての「コンテンツID管理テーブル」を更新し、「コンテンツID管理テーブル」(表6参照)を更新し、各ノード装置1に配布するカタログリストを更新・作成して、各ノード装置1に配布して(ステップS143〜S145)、処理を終了する。
ところで、ステップS140における「コンテンツID決定(変更)処理」は、オーバーレイネットワーク9に新たにコンテンツを登録(投入)する際の処理においても実行されるため、先に、図15を用いて、その他の処理ステップS115の一例として新たにコンテンツを登録(投入)する場合のシステム管理サーバ100の処理について説明し、その後に続いて図16を用いて「コンテンツID決定(変更)処理」について説明することとする。
新たにコンテンツを登録(投入)する処理は、新たなコンテンツの投入指示が入力部104によって操作されたとき、或いは、予め登録準備がされていたコンテンツが登録日時(発売日時など)となったときに登録処理プログラムが制御部101の制御に基づいて実行される処理である。
先ず、制御部101は、評価値取得手段として機能し、「コンテンツ人気度管理テーブル」(表1参照)を参照して、新たなコンテンツの予想人気度を求め、ルートノードとなるべきノード装置1の安定度を決定する(ステップS150)。例えば、表1に示す「コンテンツ人気度管理テーブル」に基づいて説明すると、新たに投入するコンテンツのアーティストがSSSである場合、このアーティストは人気度「A」となったコンテンツの数が最も多いので、新たなコンテンツの人気度を「A」と予測し決定する。そして、この最も高い人気度「A」のコンテンツを管理すべきルートノードの安定度を最も高い安定度「A」として決定する。
続いて、「コンテンツID決定(変更)処理」(後に説明する。)を行ない(ステップS151)、決定されたコンテンツIDを付与して(共用情報識別情報付与手段)、ランダムに選んだノード装置1に対して新たなコンテンツデータを保持するよう(コンテンツ保持ノードとなるよう)指示する。この目的のために、制御部101は、登録要求通知手段として機能し、コンテンツ保持ノードに対して登録要求通知をメッセージとして送信する。
当該登録要求通知をシステム管理サーバ100から受けたコンテンツ保持ノードとなるべきノードは、システム管理サーバ100に対して、新たなコンテンツデータを要求し、そのデータを取得して、自身の記憶手段に記憶し、コンテンツ保持ノードとなる。コンテンツ保持ノードは、コンテンツを記憶すると、コンテンツIDをキーとしてルートノードに向けて公開メッセージ(パブリッシュメッセージ)を送出する。そして、公開メッセージ(パブリッシュメッセージ)が、DHTルーティングに従って他のノード装置1間を転送され、ルートノードに到達することにより、新たなコンテンツのオーバーレイネットワーク9への投入が完了する(ステップS152)。
ステップS151の「コンテンツID決定(変更)処理」において、新たなコンテンツのコンテンツIDを、ルートノードのノードIDに基づいて、具体的には、ノードIDと同じ値か、それより大きい値であって、次に大きいノードID未満となるよう決定しているので、当該コンテンツIDをキーとしてルーティングテーブルに基づいて転送されることにより、最終的にルートノードとなるべきノード装置1に確実に辿り着くことができる。
そして、「コンテンツID管理テーブル」に新たなコンテンツをルートノードのノードIDと対応付けて登録し、決定されたコンテンツIDの使用済みフラグを「1」として使用済みとする。例えば、表6に示す「コンテンツID管理テーブル」の場合、「コンテンツID決定(変更)処理」において、コンテンツIDを“00000028”として決定した場合には、当該コンテンツの使用フラグを「0」から「1」に変更する。従って、新たにコンテンツIDを決定するときには、未使用のコンテンツIDの中から選択できるので、コンテンツIDによって各コンテンツを一意に識別することができる。
その後、評価値記憶手段、安定度記憶手段としての「コンテンツID管理テーブル」を更新し、各ノード装置1に配布するカタログリストを更新・作成して、各ノード装置1に配布して(ステップS153〜155)、処理を終了する。
続いて、ステップS140及びステップS151の「コンテンツID決定(変更)処理」について図16を用いて説明する。ステップS140の「コンテンツID決定(変更)処理」は、ルートノードとなっていたノード装置1の安定度の変動、或いはコンテンツの人気度の変動に起因する、「ルートノード変更処理」(図14)におけるコンテンツIDの変更処理であって、ステップS151の「コンテンツID決定(変更)処理」は、新たなコンテンツを投入する際におけるコンテンツID決定処理である。
先ず、制御部101は、安定度取得手段として機能し、「コンテンツID管理テーブル」を参照してオーバーレイネットワーク9に含まれるノード装置1の安定度を取得する。そして、指定されたランクの安定度を有するノード装置1が、「コンテンツID管理テーブル」(表6参照)にあるか否かを判定する(ステップS170)。
ステップS140の場合であって、コンテンツの人気度変動に起因する場合には、ステップS107にて集計した課金ログに基づいて、更新されたコンテンツの人気度に応じた安定度を有するノード装置1があるか否かを判定し、ルートノードとなっていたノード装置1の安定度の変動に起因する場合には、ステップS110にて受信した安定度変更メッセージに含まれる変更後の安定度を有するノード装置1があるか否かを判定する。一方、ステップS151の場合には、新たなコンテンツの予想人気度に対応する安定度を有するノード装置1があるか否かを判定する。
そして、指定されたランクの安定度を有するノード装置1が、「コンテンツID管理テーブル」(表6参照)にある場合(ステップS170:Yes)には、制御部101は選択手段として機能し、指定されたランクの安定度を有するノード装置1の中から、ルートノードとなるべきノード装置1をランダムに選択する(ステップS171)。このとき、指定されたランクの安定度を有するノード装置1が複数ある場合には、既に管理しているコンテンツの数が比較的少ないノード装置1を選択するよう構成してもよい。例えば、指定された安定度のランクが「A」である場合、表6の「コンテンツID管理テーブル」の場合、ノードID“00000003”“10000320”“30000000”のノード装置1が安定度Aを有することとなるが、このうち、最も管理中コンテンツの数が少ないノードID“00000003”のノード装置1を選択する。
続いて、選択されたノード装置1が管理するノードIDの中に未使用のコンテンツIDがあるか否かを「コンテンツID管理テーブル」(表6参照)の使用フラグに基づいて判定し(ステップS172)、未使用のコンテンツIDがある場合(ステップS172:Yes)には、当該未使用のコンテンツIDを、コンテンツIDとして決定し(ステップS173)、処理を終了する。
他方、指定されたランクの安定度を有するノード装置1が、「コンテンツID管理テーブル」(表6参照)にない場合(ステップS170:No)、及び、選択されたノード装置1が管理するノードIDの中に未使用のコンテンツIDが無い場合(ステップS172:No)には、指定されたランクよりも上位のランクのノード装置1が「コンテンツID管理テーブル」(表6参照)にあるか否かを判定(ステップS174)し、上位のランクのノード装置1がある場合(ステップS174:Yes)には、指定のランクを1つ上げ(ステップS175)、最上位のランクの安定度(本実施形態の場合には安定度「A」)までステップS170〜S175の処理を繰り返し行なう。
つまり、指定された安定度のランクが「B」である場合には、表6の「コンテンツID管理テーブル」の場合、ノードID“22120003”のノード装置1が選択されるが、当該ノード装置1が管理するノードIDの中に未使用のコンテンツIDが無い場合には、指定のランクを「B」から「A」に1つ上げる。
そして、指定されたランクよりも上位のランクのノード装置1が「コンテンツID管理テーブル」(表6参照)にない場合(ステップS174:No)には、「コンテンツID管理テーブル」を参照してランダムに選んだノード装置1の未使用のコンテンツIDをコンテンツIDとして決定し(ステップS176)、処理を終了する。
以上説明した実施形態によれば、各コンテンツのコンテンツIDを、管理すべきノード装置1のノードIDに応じて付与するようにしたので、各コンテンツの人気度に応じた安定度を有するノード装置1に、各コンテンツを管理させるよう構成したので、ノード装置1の脱退等によるルーティング経路の変更を少なくしてシステム全体の負荷を低減することができる。
また、コンテンツを識別するコンテンツIDと、ノード装置1を識別するノードIDとを用いて、各IDがDHTのID空間において所定の関係となる場合に、管理されるよう構成したので、従来公知の分散ハッシュテーブルを利用して構築されたオーバーレイネットワークにおけるコンテンツの配信システムに容易に適用することができる。
また、コンテンツの人気度を、コンテンツの課金ログ、すなわち、コンテンツ購入メッセージの受信回数に応じて決定するよう構成したので、システム管理サーバ100は、人気度の変動をリアルタイムに把握し、更新することができる。
更に、人気度の高いコンテンツには安定度の高いノード装置1がルートノードとなって管理するよう構成したので、コンテンツの購入(配信要求)が頻繁に行なわれる場合であっても安定したノード装置1にて安定して管理することができる。
なお、「コンテンツID管理テーブル」(表6参照)にて、常に全ノード装置1の安定度を記憶していることとすると、オーバーレイネットワーク9に参加するノード装置1の数が多くなると管理情報が膨大になってしまう。従って、制御部101を情報削除手段として機能させ、例えば、最近アクセスがされた1000台のノード装置1の安定度を管理することとしたり、或いは過去数年以内にアクセスがされたノード装置1のみの安定度を管理することとし、新たにノード装置1からアクセスがあったときには、一番古いアクセスのノード装置1を管理から除外するよう構成してもよい。さらに、コンテンツ毎に公開終了日時を定め、公開終了日時を経過したときに、当該コンテンツを管理から除外するよう構成してもよい。
また、ノード装置1のオーバーレイネットワーク9への参加持続時間(表4)を安定度としたが、この定義方法だと、一瞬でも脱退すると、参加持続時間が0に戻ってしまうので、平均してみると参加率が高いノード装置であっても、安定度が低いとみなされてしまうことになる。これを避けるためには、所定の参加時間計測期間中における参加時間に基づいて安定度を決定してもよい。この計測期間は、ノード装置1の製造後(設置後)から今現在までの経過時間としてもよく、或いは過去1000時間とすることもでき、或いはコンテンツの人気度の変動に応じて設定することもできる。
コンテンツの人気度の変動に応じて設定する場合について説明すると、例えば、あるコンテンツの公開直後やコンテンツの宣伝が行なわれた後、2週間は確実にこのコンテンツに対するアクセスが集中すると予測できる場合には、その2週間の間、安定しているノード装置1を、ルートノードとして決定すればよい。そのためには、過去2週間の各ノード装置1の参加時間を計測する。過去2週間安定していたノード装置は、この後の2週間も安定して稼働する確率が高いとみなすことができるからである。
また、人気度の変動のスパンが短い場合、例えば、コンテンツ公開期間が午後7時〜9時である場合には、過去数日の午後7時〜9時を参加時間計測期間として、この間の各ノード装置1の参加時間を計測し、この計測時間に対する参加時間が長いノード装置1を安定度が高いものと判断し、このノード装置1をルートノードとすればよい。
また、コンテンツの評価値の一例として人気度を用いて説明したが、本発明はこれに限定されるものではなく、例えばコンテンツの注目度や、コンテンツの推薦度などであってもよい。
また、本実施形態では、本発明の登録装置の一例としてのシステム管理サーバ100にて、コンテンツの人気度の管理やノード装置1の安定度の管理を行なうよう構成したが、本発明はこれに限定されるものではなく、本発明の登録装置を複数のサーバに対して適用してもよく、この場合、コンテンツ登録作業、課金作業、コンタクトノード紹介作業を複数のサーバにて分担するよう構成し、必要に応じて各サーバ間にて情報の授受を行なうことにより、コンテンツの人気度やノード装置1の安定度を管理し、各コンテンツに最適なコンテンンツIDを付与するよう構成すればよい。