JP5168333B2 - P2p端末及びコンテンツ配信システム - Google Patents
P2p端末及びコンテンツ配信システム Download PDFInfo
- Publication number
- JP5168333B2 JP5168333B2 JP2010215863A JP2010215863A JP5168333B2 JP 5168333 B2 JP5168333 B2 JP 5168333B2 JP 2010215863 A JP2010215863 A JP 2010215863A JP 2010215863 A JP2010215863 A JP 2010215863A JP 5168333 B2 JP5168333 B2 JP 5168333B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- cache
- karaoke
- cache file
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Description
本発明は、ネットワークを介して相互に接続された複数の端末装置間でピアツーピア(Peer to Peer(P2P))型のコンテンツ配信を行う技術に関する。
近年、ネットワークを介して相互に接続された複数の端末同士でデータを共有するP2P方式のコンテンツ配信システムが実用化している(例えば、特許文献1参照)。このようなP2P方式のコンテンツ配信システムによれば、コンテンツを配給するセンタサーバの負荷を軽減し、システムの運用・保守にかかるコストを低減できるとされている。
ところで、カラオケサービスを提供するカラオケ端末は、利用客からのサービス要求に応じて楽曲データの再生や、歌詞字幕の表示及び色変わり、背景動画の表示等の処理を行っている。また、通信カラオケにおいては、そうしたカラオケサービスの提供の他に、最新楽曲やオンデマンドによるコンテンツのダウンロードも並行して行わなければならない。
こうしたカラオケ端末にP2P方式のコンテンツ配信機能を搭載する問題として、CPUの処理負荷の増大による処理の遅延が挙げられる。それは、P2P方式のコンテンツ配信においては、クライアントサーバ方式と異なり、1つの端末がコンテンツの受信(ダウンロード)だけでなく他の端末へのコンテンツ送信(アップロード)も同時に行わなければならないからである。かといって、各端末がカラオケサービスの提供を優先したがためにアップロードを停止してしまえば、他の端末はコンテンツを取得することができなくなり、P2P方式のコンテンツ配信システムとしては破綻してしまうだろうし、利用者に迅速なオンデマンドサービスを提供できなくなってしまう。
こうしたカラオケサービス特有の問題を回避するため、カラオケサービスを提供するカラオケ端末とは別に、P2Pネットワークに接続してコンテンツ交換(コンテンツを他の端末にアップロードしたり、他の端末からダウンロード)するためのデータを記憶する補助記憶手段(以下、キャッシュ領域)を備えたP2P端末を設け、これらをローカルネットワーク(例えば、カラオケ店舗内に敷設されたLAN)によって相互に接続する構成が考案されている。このように構成されたシステムでは、カラオケ端末はローカルネットワークを介してP2P端末対して必要なコンテンツを要求し、P2P端末はP2Pネットワークを介して取得した要求コンテンツをキャッシュ領域に一時記憶してカラオケ端末に配信したり、P2Pネットワーク側の他のP2P端末との間で、キャッシュ領域を介してコンテンツを共有するようになっている。このようにして、P2Pネットワーク間でのコンテンツの送受信に係る処理をP2P端末に代表して負担させることで、カラオケ端末の処理負荷が軽減し、カラオケサービスを安定して提供することができる。
しかしながら、このようなP2P端末を用いたコンテンツ配信システムにおいて問題となるのが、P2P端末内でコンテンツのキャッシュ領域が何らかの不具合により使用不可能になる場合である。各P2P端末で持ち合っているコンテンツの保存場所であるキャッシュ領域が使用不能となれば、そのキャッシュ領域に格納されていたコンテンツのデータは失われ、他のP2P端末に対するアップロードが不可能となる。そうした端末が増えれば、コンテンツの配信に遅延を招くおそれがあり、そのような事態が更に悪化し、P2P端末間でのコンテンツの送受信に支障を来すことになれば、カラオケサービスにとって致命的である。
特にカラオケサービスでは、大量のコンテンツ提供が必要となる為、比較的安価で大容量の記憶媒体であるハードディスクドライブ(HDD)がP2P端末のキャッシュ領域としてよく使用されるが、機械的な駆動機構が多用されるHDDは過熱や衝撃に弱く、故障してしまうことも少なくない。
本発明は、このような問題を解決するためになされたものであり、P2P方式のコンテンツ配信システムを構成するP2P端末のキャッシュ領域に不具合が生じた場合に、速やかにキャッシュ領域を復元してコンテンツの送信機能を回復できるようにするための技術を提供することを目的とする。
上記目的を達成するためになされた請求項1に記載のP2P端末は、P2Pネットワークに接続され、このP2Pネットワークを構成する他の複数のP2P端末との間で、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する。それと共に、ローカルネットワークに接続され、このローカルネットワークを構成する複数のカラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記P2Pネットワークにおいて他のP2P端末から取得した前記キャッシュファイルを配信する。
加えて、本発明のP2P端末は、キャッシュ手段、リスト記憶手段、検知手段、マウント先選定手段、マウント手段、キャッシュ復元手段を備える。キャッシュ手段は、P2Pネットワークにおいて他のP2P端末へ送信するキャッシュファイルを格納するためのものである。リスト記憶手段は、キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するものである。検知手段は、キャッシュ手段の不具合を検知するためのものである。
マウント先選定手段は、検知手段によりキャッシュ手段の不具合を検知した場合、ローカルネットワークを構成する複数のカラオケ端末の中からマウント対象となるカラオケ端末を選定する。マウント手段は、マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自P2P端末のキャッシュ手段として代用可能な状態にマウントする。ここでいうマウントとは、P2P端末がカラオケ端末が備える記憶手段を自身のファイルシステムとして認識し、操作可能にするための手続きを指す。
キャッシュ復元手段は、検知手段によりキャッシュ手段の不具合が検知された場合、まず、リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有するカラオケ端末及び他のP2P端末を特定する。そして、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末からキャッシュファイルリストに記載のキャッシュファイルを取得してマウント手段によりマウントした特定領域に記録する。そして、P2P端末は、キャッシュ復元手段によりキャッシュファイルが復元された特定領域を、キャッシュ手段として代用する。
このように構成されたP2P端末によれば、万一、HDDが故障するなどしてキャッシュ手段が使用不能になった場合でも、ローカルネットワークを介して接続しているカラオケ端末の記憶手段をキャッシュ手段として代用でき、キャッシュファイルのアップロードを継続できる。さらに、キャッシュファイルリストに基づいて、破損前のキャッシュファイルをキャッシュ手段の代用としてマウントされた記憶領域に復元できる。これにより、P2Pネットワークを構成する端末間において共有の管理情報を変更することなく、破損前と同等のキャッシュファイルを他のP2P端末へアップロード可能である。
また、復元するキャッシュファイルの取得先を、ローカルネットワーク経由でカラオケ端末から取得するか、あるいはP2Pネットワーク経由で他のP2P端末から取得するか、そのときの取得速度(例えば、通信速度)が最も早い端末から選定することで、速やかにキャッシュファイルを復元し、キャッシュファイルのアップロード機能を迅速に回復できる。
つぎに、請求項2に記載のP2P端末は次のような特徴を有する。すなわち、マウント先選定手段は、ローカルネットワークを構成する複数のカラオケ端末について、それぞれの記憶手段の空き容量を比較し、記憶手段の空き容量が大きいカラオケ端末を優先してマウント対象に選定する。このように構成することで、複数のカラオケ端末の中から記憶容量に余裕のあるカラオケ端末を優先的にマウント対象に選定することができ、マウント対象のカラオケ端末が持つ記憶資源に対してなるべく負担がかからないようにできる。
つぎに、請求項3に記載のP2P端末は次のような特徴を有する。すなわち、マウント先選定手段は、ローカルネットワークを構成する複数のカラオケ端末について、キャッシュファイルの復元処理の速さに関する所定の指標を比較し、キャッシュファイルの復元処理の速いカラオケ端末を優先してマウント対象に選定する。なお、ここでいうキャッシュファイルの復元処理の速さに関する所定の指標とは、例えば、キャッシュファイルの転送時における通信速度や、カラオケ端末が持つCPUの使用率等が挙げられる。具体的には、通信速度が速ければファイルの転送速度が向上し、キャッシュファイルの復元処理を速やかに完了できる。また、カラオケ端末のCPUの使用率が低ければ、キャッシュファイルの復元処理のためにCPUを占有できる時間を多く確保できるので、キャッシュファイルの復元処理を速やかに完了できる。
このように構成することで、複数のカラオケ端末の中から情報処理能力に余裕のあるカラオケ端末を優先的にマウント対象に選定することができ、キャッシュファイルの復元を迅速に完了できるようにすると共に、マウント対象のカラオケ端末が持つ情報処理能力に対してなるべく負担がかからないようにできる。
ところで、オンデマンドによるコンテンツのダウンロードサービスを提供するカラオケ端末においては、利用客からのリクエストに応じて不定期にコンテンツの配信要求がなされる。このとき、ダウンロード要求先のP2P端末がキャッシュ手段の不具合によりキャッシュファイルを復元中であったとしても、カラオケ端末からの配信要求に係るコンテンツのキャッシュファイルの配信に遅延が生じないようにすることが肝要である。
そこで、請求項4に記載のように構成するとよい。すなわち、キャッシュ復元手段は、ローカルネットワークを構成するカラオケ端末からキャッシュファイルの配信要求を受けている場合、その配信要求に該当のキャッシュファイルを保有する取得先端末を選定し、その選定した取得先端末から当該配信要求に該当のキャッシュファイルを優先して取得する。このように構成することで、破損前の保有状況を記したキャッシュファイルリストの内容に関わらず、カラオケ端末からの配信要求に対応するキャッシュファイルを優先的に取得できる。これにより、キャッシュファイルを復元中であったとしても、カラオケ端末からの配信要求に係るキャッシュファイルの取得に遅延が生じないようにできる。
ところで、復元するキャッシュファイルの取得先を選定する場合には、必要なキャッシュファイルを保有している端末を特定する必要がある。P2Pネットワーク内から必要なキャッシュファイルを保有する端末を探す場合、P2Pネットワーク内でキャッシュファイルの保有状況を示すインデックス情報を共有する周知の仕組みにより、必要なキャッシュファイルを保有する端末を確実に特定できる。
一方、ローカルネットワーク内から必要なキャッシュファイルを保有する端末を探す場合、あるタイミングで各カラオケ端末へ問合せることにより、その時点での保有状況を把握できる。しかしながら、カラオケ端末では、コンテンツを保有するための記憶資源に限りがあるため、製作時期が古いコンテンツや再生リクエストの少ないコンテンツ等に関するキャッシュファイルをカラオケ端末独自の判断により削除する場合がある。そのため、ローカルネットワーク内においてキャッシュファイルの保有状況はその時々で変化している。このような事情により、P2P端末側で過去に把握したローカルネットワーク内のキャッシュファイルの保有状況と、実際の保有状況とが必ずしも一致するとは限らない。
このような問題を解決するために、請求項5に記載のように構成するとよい。すなわち、キャッシュ復元手段は、取得先端末を選定する事前に、ローカルネットワークを構成する複数のカラオケ端末におけるキャッシュファイルの保有状況を取得し、その取得した保有状況に基づいて取得先端末を選定する。このように構成することで、復元するキャッシュファイルの取得先を選定する直前においてローカルネットワーク内におけるキャッシュファイルの最新の保有状況を把握でき、必要なキャッシュファイルを保有するカラオケ端末を確実に特定できる。
つぎに、請求項6に記載の発明は、P2Pネットワークを構成し、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する複数のP2P端末と、複数のP2P端末の各々が1つ又は複数単位で接続された複数のローカルネットワークを構成する複数のカラオケ端末とを有するコンテンツ配信システムに関するものである。そして、このコンテンツ配信システムを構成するP2P端末は、請求項1に記載のP2P端末と同様の構成を有する。
このように構成されたコンテンツ配信システムによれば、請求項1に記載のP2P端末に関して上述した効果を得られると共に、P2P端末のHDDの破損といった不具合に対して耐久性のあるコンテンツ配信システムを実現できる。
以下、本発明の一実施形態を図面に基づいて説明する。
[コンテンツ配信システム1の構成の説明]
図1に示すように、コンテンツ配信システム1は、利用客にカラオケサービスを提供する複数のカラオケ店舗A,B,Cにそれぞれ敷設された店舗内ネットワークが、広域ネットワークであるP2Pネットワーク200を介して相互に接続されることによって形成されている。各カラオケ店舗の店舗内ネットワークは、少なくとも1台のP2P端末3と、通常は複数台のカラオケ端末4とが店舗内に敷設されたLAN100を介して相互に接続されている。また、各カラオケ店舗のP2P端末3は、P2Pネットワーク200を介して相互に接続されている。なお、図1においては、説明の便宜上、3つのカラオケ店舗A,B,CがP2Pネットワーク200に接続されている構成を示すが、更に多くのカラオケ店舗が接続されていてもよい。また、各カラオケ店舗において、1台のP2P端末3と、3台のカラオケ端末4とが設置されている構成を示すが、1つの店舗に複数台のP2P端末3が配置されていてもよいし、更に多くのカラオケ端末4が配置されていてもよい。
[コンテンツ配信システム1の構成の説明]
図1に示すように、コンテンツ配信システム1は、利用客にカラオケサービスを提供する複数のカラオケ店舗A,B,Cにそれぞれ敷設された店舗内ネットワークが、広域ネットワークであるP2Pネットワーク200を介して相互に接続されることによって形成されている。各カラオケ店舗の店舗内ネットワークは、少なくとも1台のP2P端末3と、通常は複数台のカラオケ端末4とが店舗内に敷設されたLAN100を介して相互に接続されている。また、各カラオケ店舗のP2P端末3は、P2Pネットワーク200を介して相互に接続されている。なお、図1においては、説明の便宜上、3つのカラオケ店舗A,B,CがP2Pネットワーク200に接続されている構成を示すが、更に多くのカラオケ店舗が接続されていてもよい。また、各カラオケ店舗において、1台のP2P端末3と、3台のカラオケ端末4とが設置されている構成を示すが、1つの店舗に複数台のP2P端末3が配置されていてもよいし、更に多くのカラオケ端末4が配置されていてもよい。
このコンテンツ配信システム1は、各P2P端末3間でカラオケサービスのコンテンツに関するキャッシュファイルを互いに送受信するP2P方式のネットワークシステムと、P2P端末3が保有するキャッシュファイルを店舗内のLAN100を介してカラオケ端末4へ配信するサーバクライアント型のネットワークシステムとが複合したものである。
P2P端末3は、自端末の記憶装置であるハードディスクドライブ(以下、HDD)34に予め確保したキャッシュ領域にコンテンツのキャッシュファイルを保存しておき、他のP2P端末3との間でキャッシュファイルをアップロードしたりダウンロードすることでコンテンツを共有している。それと共に、自P2P端末3が属するLAN100において隷下にあるカラオケ端末4からキャッシュファイルの配信要求があった場合、他のP2P端末からダウンロードしてキャッシュ領域に保存した要求ファイルを、要求元のカラオケ端末4に対して配信する。また、各P2P端末3には、識別情報として広域ネットワークに接続するための固有のグローバルIPアドレスが割当てられている。なお、P2P端末3で共有するキャッシュファイルは、コンテンツの元データを暗号化したり分割化して機密性を向上させたものであってもよいし、元データのままでもよい。
P2P端末3は、HDD34が故障してキャッシュ領域が使用不能になった場合に、隷下のカラオケ端末4のHDD44に自端末が利用可能なキャッシュ領域を確保すると共に、故障前にキャッシュ領域に保有していたキャッシュファイルを新たに確保したキャッシュ領域に復元する機能を有する。これらの処理の詳細な内容については後述する。
一方、カラオケ端末4は、P2P端末3から取得したキャッシュファイルをHDD44に保有しており、このキャッシュファイルに基づいてカラオケコンテンツの再生処理をする情報処理装置である。また、各カラオケ端末4には、識別情報として自装置が属するLAN100の範囲内で固有のローカル(又はプライベート)IPアドレスが割当てられている。このカラオケ端末4は、実行するコンテンツのファイルを自ら保有するためのHDD44を備えているが、このHDD44の記憶容量はコンテンツ配信システム1において流通する全てのコンテンツを保有するには小さいものである。そのため、個々のカラオケ端末4は一部のコンテンツしか保有していない。そのため、カラオケ端末4は、利用者からのリクエストに基づき、自端末が属するLAN100内のP2P端末3に対してオンデマンドの配信要求を行い、リクエストされたコンテンツのキャッシュファイルをP2P端末3からダウンロードする。
図2(a)は、P2P端末3の概略構成を示すブロック図である。P2P端末3は、ハードウェア構成としてCPU31、RAM32、ROM33、HDD34、P2Pネットワーク通信部35、LAN通信部36等を備える。
CPU31は、RAM32やROM33に記憶されたプログラムやデータに従って、P2P端末3の各部に対する制御及び各種演算を実行する装置で、後述するキャッシュ領域監視処理、保有端末応答処理は、このCPU31によって実行される。RAM32はCPU31から直接アクセスされるメインメモリとして利用される記憶装置である。後述する保有キャッシュファイルリストやキャッシュファイルの保有端末一覧、LAN内のキャッシュファイル保有状況等もここに記憶される。ROM33は、不揮発性の記憶装置であり、BIOSや読み出し専用のデータ等を記憶している。HDD34は、プログラムや他のP2P端末3から取得したキャッシュファイル等を保存しておくための記憶装置である。このHDD34には、他のP2P端末3との間で送受信するキャッシュファイルを保管しておくためのキャッシュ領域が設けられている。
P2Pネットワーク通信部35は、P2P端末3をP2Pネットワーク200に接続して他のP2P端末3との間で通信を行うための通信インタフェースである。LAN通信部36は、P2P端末3をLAN100に接続して、同一店舗内のLAN100に接続された各カラオケ端末4との間で通信を行うための通信インタフェースである。
一方、図2(b)は、カラオケ端末4の概略構成を示すブロック図である。カラオケ端末4は、ハードウェア構成としてCPU41、RAM42、ROM43、HDD44、操作部45、再生部46、入力部47、LAN通信部48等を備える。
CPU41は、RAM42やROM43に記憶されたプログラムやデータに従ってカラオケ端末4各部に対する制御及び各種演算を行う装置で、後述するHDD情報送信処理、マウント要求応答処理、保有状況応答処理は、このCPU41によって実行される。RAM42は、CPU41から直接アクセスされるメインメモリとして利用される記憶装置である。ROM43は、不揮発性の記憶装置でありBIOSや読み出し専用のデータ等を記憶している。HDD44は、カラオケ用の楽曲や映像等のコンテンツやプログラム等の各種データを保存しておくための装置である。操作部45は、ユーザからの各種指示を入力するための入力装置であり、複数のキースイッチ等によって構成される。
再生部46は、演奏データに基づく演奏再生をおこなうMIDI音源、MIDI音源から再生されたオーディオ信号及び入力部47から入力された音声信号をスピーカへ出力する音声制御部、画像データに基づく映像の再生を制御する映像再生部、映像を表示するためのモニタ等を備える。入力部47は、マイクロフォンによって歌唱者の歌唱音声を音声信号に変換し、再生部46へ入力するためのものである。LAN通信部48は、カラオケ端末4をLAN100に接続して、同一店舗内のLAN100に接続されたP2P端末3や他のカラオケ端末4との間で通信を行うための通信インタフェースである。
[各種リストの説明]
図3(a)は、各P2P端末3が記憶管理している保有キャッシュファイルリストの一例である。この保有キャッシュファイルリストは、自P2P端末3がキャッシュ領域に現に保有しているキャッシュファイルの一覧であり、P2P端末3のRAM32に記憶されている。
図3(a)は、各P2P端末3が記憶管理している保有キャッシュファイルリストの一例である。この保有キャッシュファイルリストは、自P2P端末3がキャッシュ領域に現に保有しているキャッシュファイルの一覧であり、P2P端末3のRAM32に記憶されている。
図3(a)に示すとおり、P2P端末3の保有キャッシュファイルリストには、自己のグローバルIPアドレスに対応付けて、現在保有しているキャッシュファイルの一覧が記述されている。キャッシュファイルの一覧には、ファイルを取得(ダウンロード)した時期(例えば年月日)や、取得先のP2P端末3のグローバルIPアドレスがファイル名ごとに記述されている。この保有キャッシュファイルリストは、他のP2P端末3からキャッシュファイルを新たに取得したときには、CPU31によってそのキャッシュファイルのレコードが追加されるようになっている。また、保有しているキャッシュファイルをキャッシュ領域から消去したときには、CPU31によってその消去したキャッシュファイルのレコードが削除されるようになっている。
図3(b)は、各P2P端末3が記憶管理しているキャッシュファイルの保有端末一覧の一例である。この保有端末一覧は、どのキャッシュファイルをどのP2P端末3が保有しているのかを示す一覧であり、P2P端末3のRAM32に記憶されている。
図3(b)に示すとおり、キャッシュファイルの保有端末一覧には、自己のグローバルIPアドレスに対応付けて、キャッシュファイル名ごとにそのキャッシュファイルを保有しているP2P端末3のグローバルIPアドレスの一覧が記述されている。この保有端末一覧は、CPU31による情報収集や、P2P端末3同士の情報交換等により取得した保有状況に基づいて更新される。なお、この保有端末一覧では、1台のP2P端末3において全てのキャッシュファイルの保有状況が網羅されているわけではなく、複数のP2P端末3の間で分担して全ての保有状況を網羅するようになっている。よって、自己が記憶している保有端末一覧に網羅されていないキャッシュファイルの保有端末を特定する場合、P2Pネットワーク200を介して他のP2P端末3に問合せることで特定可能である。
図3(c)は、各カラオケ端末4が記憶管理している保有キャッシュファイルリストの一例である。この保有キャッシュファイルリストは、自カラオケ端末4がHDD44に保有しているキャッシュファイルの一覧であり、カラオケ端末4のRAM42やHDD44等に記憶されている。
図3(c)に示すとおり、カラオケ端末4の保有キャッシュファイルリストには、自己のローカルIPアドレスに対応付けて、現在保有しているキャッシュファイルの一覧が記述されている。キャッシュファイルの一覧には、ファイルを取得した時期(例えば年月日)や、取得先のP2P端末3のグローバルIPアドレスがファイル名ごとに記述されている。この保有キャッシュファイルリストは、同一店舗内のP2P端末3からキャッシュファイルを取得したときには、CPU41によってその取得したキャッシュファイルのレコードが追加されるようになっている。また、保有しているキャッシュファイルをHDD44から消去したときには、CPU41によってその消去したキャッシュファイルのレコードが削除されるようになっている。
なお、各カラオケ店舗のP2P端末3は、同一店舗内のLAN100に接続している全てのカラオケ端末4の保有キャッシュファイルリストをRAM32に記憶している。ただし、カラオケ端末4では、製作時期が古いコンテンツや再生リクエストの少ないコンテンツ等に関するキャッシュファイルをカラオケ端末4独自の判断により削除する場合がある。そのため、P2P端末3側で過去に把握したカラオケ端末4のキャッシュファイルの保有状況と、実際の保有状況とが必ずしも一致するとは限らない。
[1.P2P端末3が実行する処理の説明]
(1−1.キャッシュ領域監視処理)
P2P端末3のCPU31が実行するキャッシュ領域監視処理の手順について図4のフローチャートを参照しながら説明する。この処理は、P2P端末3の稼働中において所定時間ごとに繰返し実行される処理である。
(1−1.キャッシュ領域監視処理)
P2P端末3のCPU31が実行するキャッシュ領域監視処理の手順について図4のフローチャートを参照しながら説明する。この処理は、P2P端末3の稼働中において所定時間ごとに繰返し実行される処理である。
P2P端末3のCPU31は、まず、HDD34のキャッシュ領域に対するリード・ライトを試みることで、キャッシュ領域を検査する(S100)。検査の結果、キャッシュ領域の破損を検知したか否かを判定する(S101)。
S101で、キャッシュ領域に破損がない、すなわちキャッシュ領域に対するアクセスが正常に機能すると判定した場合(S101:NO)、本処理を終了する。一方、キャッシュ領域に破損がある、すなわちキャッシュ領域に対するアクセスが正常に機能しないと判定した場合(S101:YES)、S102においてマウント処理を実行する。S102のマウント処理では、LAN100に接続している隷下のカラオケ端末4の中からマウント対象となる端末を選定し、このマウント対象のカラオケ端末4が備えるHDD44の特定領域を、自P2P端末3のキャッシュ領域として代用可能な状態にマウントする(詳細な手順については後述する)。
つぎに、S103においてキャッシュファイル復元処理を実行する。このキャッシュファイル復元処理では、S102においてマウントした代用のキャッシュ領域に、破損したキャッシュ領域に従前まで記憶されていたキャッシュファイルを復元する(詳細な手順については後述する)。
(1−2.マウント処理)
上述のキャッシュ領域監視処理(図4参照)のS102でCPU31が実行するマウント処理の手順について図5(a)のフローチャートを参照しながら説明する。
上述のキャッシュ領域監視処理(図4参照)のS102でCPU31が実行するマウント処理の手順について図5(a)のフローチャートを参照しながら説明する。
まず、S200では、LAN100内にブロードキャストでHDD情報送信要求を発信する。このHDD情報送信要求は、各カラオケ端末4に対して、代用のキャッシュ領域として提供可能なHDD44の空き容量を示すHDD情報の送信を要求するメッセージである。つぎに、S201では、各カラオケ端末4から通知されたHDD情報に基づき、マウント対象選定処理を実行する。このマウント対象選定処理では、LAN100に接続している複数のカラオケ端末4の中から、代用のキャッシュ領域をマウントする対象となる端末を選択する(詳細な手順については後述する)。
つぎに、S202では、S201で選定したマウント対象のカラオケ端末4が備えるHDD44の特定領域を、自身のファイルシステムにおいて利用可能なキャッシュ領域としてマウントする。ここでいうマウントとは、P2P端末3がカラオケ端末4のHDD44の特定領域を自身のファイルシステムとして認識し、操作可能にするための手続きを指す。本実施形態では、NFS(Network File System)に実装されている周知のマウント機能を用いる。具体的には、P2P端末3側から、マウント対象のカラオケ端末4に対してキャッシュ領域のマウント要求を通知する。これに対し、マウント対象のカラオケ端末4は、キャッシュ領域として提供するHDDの特定領域(マウント領域)を要求元のP2P端末3へ通知し、マウントを受付ける。この一連の手続きにより、代用のキャッシュ領域のマウントが成立する。
(1−3.マウント対象選定処理、第1実施形態)
上述のマウント処理(図5(a)参照)のS201でCPU31が実行するマウント対象選定処理の第1実施形態の手順について図5(b)のフローチャートを参照しながら説明する。
上述のマウント処理(図5(a)参照)のS201でCPU31が実行するマウント対象選定処理の第1実施形態の手順について図5(b)のフローチャートを参照しながら説明する。
まず、S300では、各カラオケ端末4から、HDD情報を受信する。このHDD情報には、送信元のカラオケ端末4の識別情報(ローカルIPアドレス)及び、代用のキャッシュ領域として提供可能なHDD44の空き容量を示す情報が含まれる。つぎに、S302では、受信したHDD情報に基づいて各カラオケ端末4のHDD44の空き容量を比較し、空き容量が最大のカラオケ端末4をマウント対象に選定する。
(1−4.マウント対象選定処理、第2実施形態)
上述のマウント処理(図5(a)参照)のS201でCPU31が実行するマウント対象選定処理の第2実施形態の手順について図5(c)のフローチャートを参照しながら説明する。
上述のマウント処理(図5(a)参照)のS201でCPU31が実行するマウント対象選定処理の第2実施形態の手順について図5(c)のフローチャートを参照しながら説明する。
まず、S301では、LAN100に接続している各カラオケ端末4との間の通信速度をそれぞれ測定する。測定方法の一例としては、各カラオケ端末4に対してpingコマンドを送信し、各カラオケ端末4から返信されるまでの所要時間を測定して、この通信時間とpingコマンドのデータサイズとから、各カラオケ端末4の通信速度を算出する。
つぎに、S303では、S301での測定結果に基づいて各カラオケ端末4の通信速度を比較し、通信速度が最大のカラオケ端末4をマウント対象に選定する。
(1−5.キャッシュファイル復元処理)
上述のキャッシュ領域監視処理(図4参照)のS103でCPU31が実行するキャッシュファイル復元処理の手順について図6のフローチャートを参照しながら説明する。
(1−5.キャッシュファイル復元処理)
上述のキャッシュ領域監視処理(図4参照)のS103でCPU31が実行するキャッシュファイル復元処理の手順について図6のフローチャートを参照しながら説明する。
まず、S400では、RAM32に記憶している自己の保有キャッシュファイルリスト(図3(a)参照)に記述されている全てのキャッシュファイルについて、マウント領域(代用のキャッシュ領域)への復元が完了したか否かを判定する。全てのキャッシュファイルの復元が完了していない場合(S400:NO)、S401でLAN内保有状況確認処理を実行する。このLAN内保有状況確認処理では、LAN100に接続している全てのカラオケ端末4におけるキャッシュファイルの保有状況を確認し、RAM32に記憶している各カラオケ端末4の保有キャッシュファイルリスト(図3(c)参照)を更新する(詳細な手順については後述する)。
つぎに、S402では、現時点でカラオケ端末4から特定のキャッシュファイルに対するダウンロード要求があるか否かを判定する。カラオケ端末4からのダウンロード要求がある場合(S402:YES)、要求されているキャッシュファイルを次の取得対象のキャッシュファイルに選定する(S403)。一方、カラオケ端末4からのダウンロード要求がない場合(S402:NO)、自己の保有キャッシュファイルリストを参照し、復元が未完了のキャッシュファイルのうちの1つを、次の取得対象のキャッシュファイルに選定する(S404)。
つぎに、S405では、RAM32に記憶しているキャッシュファイルの保有端末一覧(図3(b)参照)、及び、各カラオケ端末4の保有キャッシュファイルリスト(図3(c)参照)を参照し、取得対象のキャッシュファイルを保有している端末が既知であるか否かを判定する。取得対象のキャッシュファイルを保有している端末が既知である場合(S405:YES)、S408の処理へ進み、取得対象のキャッシュファイルを保有している端末が不明、すなわち、参照したリストに取得対象のキャッシュファイルの保有先が記述されていない場合(S405:NO)、S406の処理へ進む。
取得対象のキャッシュファイルを保有している端末が不明である場合に進むS406では、他のP2P端末3に対して、取得対象のキャッシュファイルを保有している端末を問合せる。そして、この問合せの結果得られた情報に基づいて、取得対象のキャッシュファイルを保有しているP2P端末3の情報をRAM32の保有端末一覧に追加更新し(S407)、S408の処理へ進む。
S408では、取得先選定処理を実行する。この取得先選定処理では、取得対象のキャッシュファイルを保有しているP2P端末3及びカラオケ端末4の中から、当該キャッシュファイルの取得先となる端末を選定し、この取得先の端末から取得対象のキャッシュファイルをダウンロードする(詳細な手順については後述する)。
S408の処理を実行後、S400の処理へ戻る。以降、S400〜S408の処理を繰返すことで、自己の保有キャッシュファイルリストに記録されているキャッシュファイルを順次マウント領域(代用のキャッシュ領域)へ復元する。そして、S400において全てのキャッシュファイルの復元が完了したと判定した場合(S400:YES)、本処理を終了する。以降、自P2P端末3のHDD34が復旧されるまで、カラオケ端末4のHDD44に復元されたキャッシュ領域を代用して、他のP2P端末4との間でキャッシュファイルの送受信を継続する。
(1−6.LAN内保有状況確認処理)
上述のキャッシュファイル復元処理(図6参照)のS401でCPU31が実行するLAN内保有状況確認処理の手順について図7(a)のフローチャートを参照しながら説明する。
上述のキャッシュファイル復元処理(図6参照)のS401でCPU31が実行するLAN内保有状況確認処理の手順について図7(a)のフローチャートを参照しながら説明する。
まず、S500では、LAN100内にブロードキャストで保有キャッシュファイルリストの送信要求を発信する。保有キャッシュファイルリストの送信要求は、各カラオケ端末4に対して、各自の保有キャッシュファイルリスト(図3(c)参照)の送信を要求するメッセージである。つぎに、S501では、RAM32に既存の各カラオケ端末4の保有キャッシュファイルリストと、S500の送信要求に応じて各カラオケ端末4から送信されてきた最新の保有キャッシュファイルリストとで、記録内容に差分があるか否かを判定する。既存の保有キャッシュファイルリストと、最新の保有キャッシュファイルリストとで差分がある場合(S501:YES)、RAM32に既存のカラオケ端末4の保有キャッシュファイルリストを最新の内容に更新する(S502)。一方、既存の保有キャッシュファイルリストと、最新の保有キャッシュファイルリストとで記憶内容が同一である場合(S501:NO)、本処理を終了する。
(1−7.取得先選定処理)
上述のキャッシュファイル復元処理(図6参照)のS408でCPU31が実行する取得先選定処理の手順について図7(b)のフローチャートを参照しながら説明する。
上述のキャッシュファイル復元処理(図6参照)のS408でCPU31が実行する取得先選定処理の手順について図7(b)のフローチャートを参照しながら説明する。
まず、S600では、取得対象のキャッシュファイルを保有しているP2P端末3及びカラオケ端末4(以下、保有端末)が複数存在するか否かを判定する。保有端末が複数存在する場合(S600:YES)、各保有端末との間のデータ転送レートをそれぞれ測定し、全保有端末の中からデータ転送レートが最大のP2P端末3又はカラオケ端末4の何れか1つを、取得先の端末に選定する(S601)。一方、保有端末が唯一である場合(S600:NO)、その唯一の保有端末であるP2P端末3又はカラオケ端末4を取得先の端末に選定する(S602)。
つぎに、S603では、S601又はS602で選定した取得先の端末から取得対象のキャッシュファイルをダウンロードし、そのダウンロードしたキャッシュファイルをマウント対象のカラオケ端末4に設けられたマウント領域(代用のキャッシュ領域)に保存する。
(1−8.保有端末応答処理)
P2P端末3のCPU31が実行する保有端末応答処理の手順について図8のフローチャートを参照しながら説明する。この処理は、P2P端末3の稼働中において所定時間ごとに繰返し実行される処理である。
P2P端末3のCPU31が実行する保有端末応答処理の手順について図8のフローチャートを参照しながら説明する。この処理は、P2P端末3の稼働中において所定時間ごとに繰返し実行される処理である。
P2P端末3のCPU31は、まず、他のP2P端末3からキャッシュファイルの保有端末の問合せを受信したか否かを判定する(S700)。この問合せは、上述のキャッシュファイル復元処理(図6参照)のS406において送信されるものである。保有端末の問合せを受信した場合(S700:YES)、RAM32に記憶している自己の保有キャッシュファイルリストを要求元のP2P端末3に対して送信し(S701)、本処理を終了する。一方、保有端末の問合せを受信していない場合(S700:NO)、そのまま本処理を終了する。
[2.カラオケ端末4が実行する処理の説明]
(2−1.HDD情報送信処理)
カラオケ端末4のCPU41が実行するHDD情報送信処理の手順について図9(a)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
(2−1.HDD情報送信処理)
カラオケ端末4のCPU41が実行するHDD情報送信処理の手順について図9(a)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
カラオケ端末4のCPU41は、まず、P2P端末3からHDD情報送信要求を受信したか否かを判定する(S800)。このHDD情報送信要求は、上述のマウント処理(図5(a)参照)のS200において送信されるものである。HDD情報送信要求を受信した場合(S800:YES)、HDD44の利用状況から代用のキャッシュ領域として提供可能なHDD44の空き容量を算出し、この空き容量と自カラオケ端末4のローカルIPアドレスとを含むHDD情報を要求元のP2P端末3に対して送信し(S801)、本処理を終了する。一方、HDD情報送信要求を受信していない場合(S800:NO)、そのまま本処理を終了する。
(2−2.マウント要求応答処理)
カラオケ端末4のCPU41が実行するマウント要求応答処理の手順について図9(b)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
カラオケ端末4のCPU41が実行するマウント要求応答処理の手順について図9(b)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
カラオケ端末4のCPU41は、まず、P2P端末3からマウント要求を受信したか否かを判定する(S900)。このマウント要求は、上述のマウント処理(図5(a)参照)のS202において送信されるものである。マウント要求を受信した場合(S900:YES)、マウントを受付ける領域を示すマウントポイントを要求元のP2P端末3に対して通知し(マウント応答、S901)、P2P端末3からのマウントを許可する(マウント受付、S902)。一方、マウント要求を受信していない場合(S900:NO)、そのまま本処理を終了する。
(2−3.保有状況応答処理)
カラオケ端末4のCPU41が実行する保有状況応答処理の手順について図9(c)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
カラオケ端末4のCPU41が実行する保有状況応答処理の手順について図9(c)のフローチャートを参照しながら説明する。この処理は、カラオケ端末4の稼働中において所定時間ごとに繰返し実行される処理である。
カラオケ端末4のCPU41は、まず、P2P端末3からカラオケ端末4の保有キャッシュファイルリストの送信要求を受信したか否かを判定する(S1000)。この送信要求は、上述のキャッシュファイル復元処理(図6参照)のS401において送信されるものである。保有キャッシュファイルリストの送信要求を受信した場合(S1000:YES)、RAM42又はHDD44に記憶している自己の保有キャッシュファイルリストを要求元のP2P端末3に対して送信し(S1001)、本処理を終了する。一方、保有キャッシュファイルリストの送信要求を受信していない場合(S1000:NO)、そのまま本処理を終了する。
[特許請求の範囲に記載の構成との対応]
実施形態のコンテンツ配信システム1の構成と、特許請求の範囲に記載の構成との対応は次のとおりである。所定のプログラムに沿って各種演算処理を行うP2P端末3のCPU31が、特許請求の範囲における検知手段、マウント先選定手段、マウント手段、キャッシュ復元手段に相当する。また、P2P端末3のHDD34がキャッシュ手段に相当する。また、P2P端末3のRAM32がリスト記憶手段に相当する。
実施形態のコンテンツ配信システム1の構成と、特許請求の範囲に記載の構成との対応は次のとおりである。所定のプログラムに沿って各種演算処理を行うP2P端末3のCPU31が、特許請求の範囲における検知手段、マウント先選定手段、マウント手段、キャッシュ復元手段に相当する。また、P2P端末3のHDD34がキャッシュ手段に相当する。また、P2P端末3のRAM32がリスト記憶手段に相当する。
[効果]
上記実施形態のコンテンツ配信システム1によれば、次のような効果を奏する。
(1)P2P端末3のHDD34が故障するなどしてキャッシュ領域が使用不能になった場合でも、LAN100を介して接続しているカラオケ端末4のHDD44をキャッシュ領域として代用でき、他のP2P端末3に対するキャッシュファイルのアップロードを継続できる。さらに、RAM32に記憶している保有キャッシュファイルリストに基づいて、破損前のキャッシュファイルをキャッシュ領域の代用としてマウントされた記憶領域に復元できる。これにより、P2Pネットワークを構成する端末間において共有の管理情報を変更することなく、破損前と同等のキャッシュファイルを他のP2P端末3へアップロード可能である。また、復元するキャッシュファイルの取得先として、データ転送レート(通信速度)が最大の端末を選定することで、速やかにキャッシュファイルを復元し、キャッシュファイルのアップロード機能を迅速に回復できる。
上記実施形態のコンテンツ配信システム1によれば、次のような効果を奏する。
(1)P2P端末3のHDD34が故障するなどしてキャッシュ領域が使用不能になった場合でも、LAN100を介して接続しているカラオケ端末4のHDD44をキャッシュ領域として代用でき、他のP2P端末3に対するキャッシュファイルのアップロードを継続できる。さらに、RAM32に記憶している保有キャッシュファイルリストに基づいて、破損前のキャッシュファイルをキャッシュ領域の代用としてマウントされた記憶領域に復元できる。これにより、P2Pネットワークを構成する端末間において共有の管理情報を変更することなく、破損前と同等のキャッシュファイルを他のP2P端末3へアップロード可能である。また、復元するキャッシュファイルの取得先として、データ転送レート(通信速度)が最大の端末を選定することで、速やかにキャッシュファイルを復元し、キャッシュファイルのアップロード機能を迅速に回復できる。
(2)マウント対象選定処理(第1実施形態)では、HDD44の空き容量が最大のカラオケ端末4をマウント対象として選定することで、マウント対象のカラオケ端末4が持つ記憶資源に対してなるべく負担がかからないようにできる。
(3)マウント対象選定処理(第2実施形態)では、P2P端末3との通信速度が最大のカラオケ端末4をマウント対象として選定することで、キャッシュファイルの復元を迅速に完了できるようにすると共に、マウント対象のカラオケ端末4が持つ情報処理能力に対してなるべく負担がかからないようにできる。
(4)P2P端末3がキャッシュファイルを復元する最中において、カラオケ端末4からキャッシュファイルのダウンロード要求を受けた場合、保有キャッシュファイルリストの内容に関わらず、カラオケ端末4からのダウンロード要求に対応するキャッシュファイルを優先的に取得できる。これにより、キャッシュファイルを復元中であったとしても、カラオケ端末4からのダウンロード要求に係るキャッシュファイルの取得に遅延が生じないようにできる。
(5)復元するキャッシュファイルの取得先を選定する直前のタイミングで、各カラオケ端末4からキャッシュファイルの保有状況を取得することで、LAN100内におけるキャッシュファイルの最新の保有状況を把握でき、必要なキャッシュファイルを保有するカラオケ端末4を確実に特定できる。
[変形例]
以上、本発明の実施形態について説明したが、本発明は上記の実施形態に何ら限定されるものではなく様々な態様にて実施することが可能である。
以上、本発明の実施形態について説明したが、本発明は上記の実施形態に何ら限定されるものではなく様々な態様にて実施することが可能である。
例えば、上述のマウント対象選定処理の第2実施形態(図5(c)参照)においては、P2P端末3との通信速度が最大のカラオケ端末4をマウント対象に選定する構成となっていた。これに対し、通信速度に基づいてマウント対象を選定する代わりに、各カラオケ端末4のCPU41の使用率を取得し、それに基づいてCPU41の使用率が低いカラオケ端末4をマウント対象に選定するように構成してもよい。カラオケ端末4のCPU41の使用率が低ければ、キャッシュファイルの復元処理のためにCPU41を占有できる時間を多く確保できるので、キャッシュファイルの復元処理を速やかに完了できる。また、処理能力に余裕のあるカラオケ端末4がマウント対象に選定されることになるため、カラオケ端末4が本来実行すべきカラオケサービスの実施に支障を及ぼすおそれがない。
あるいは、上述のマウント対象選定処理の第1実施形態(図5(b)参照)と、第2実施形態の要件を併せ持つように構成してもよい。すなわち、複数のカラオケ端末4の間でHDD44の空き容量及び通信速度をそれぞれ比較し、その中からHDD44の空き容量が大きく、かつ、通信速度が速いカラオケ端末4を優先的にマウント対象に選定するように構成することが考えられる。
1…コンテンツ配信システム、3…P2P端末、31…CPU、32…RAM、33…ROM、34…HDD、35…P2Pネットワーク通信部、36…LAN通信部、4…カラオケ端末、41…CPU、42…RAM、43…ROM、44…HDD、45…操作部、46…再生部、47…入力部、48…LAN通信部、100…LAN、200…P2Pネットワーク。
Claims (6)
- ピアツーピア(以下、P2P)ネットワークに接続され、このP2Pネットワークを構成する他の複数のP2P端末との間で、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受すると共に、ローカルネットワークに接続され、このローカルネットワークを構成する複数のカラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記P2Pネットワークにおいて他のP2P端末から取得した前記キャッシュファイルを配信するP2P端末であって、
前記P2Pネットワークにおいて他のP2P端末へ送信するキャッシュファイルを格納するためのキャッシュ手段と、
前記キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するリスト記憶手段と、
前記キャッシュ手段の不具合を検知する検知手段と、
前記検知手段により前記キャッシュ手段の不具合を検知した場合、前記ローカルネットワークを構成する複数の前記カラオケ端末の中からマウント対象となるカラオケ端末を選定するマウント先選定手段と、
前記マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自P2P端末の前記キャッシュ手段として代用可能な状態にマウントするマウント手段と、
前記検知手段により前記キャッシュ手段の不具合が検知された場合、前記リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有する前記カラオケ端末及び前記他のP2P端末を特定して、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末から前記キャッシュファイルリストに記載のキャッシュファイルを取得して前記マウント手段によりマウントした特定領域に記録するキャッシュ復元手段とを備え、
そして、前記キャッシュ復元手段によりキャッシュファイルが復元された前記特定領域を、前記キャッシュ手段として代用すること
を特徴とするP2P端末。 - 請求項1に記載のP2P端末において、
前記マウント先選定手段は、前記ローカルネットワークを構成する複数のカラオケ端末について、それぞれの記憶手段の空き容量を比較し、前記記憶手段の空き容量が大きい前記カラオケ端末を優先して前記マウント対象に選定すること
を特徴とするP2P端末。 - 請求項1又は請求項2に記載のP2P端末において、
前記マウント先選定手段は、前記ローカルネットワークを構成する複数のカラオケ端末について、キャッシュファイルの復元処理の速さに関する所定の指標を比較し、キャッシュファイルの復元処理の速い前記カラオケ端末を優先して前記マウント対象に選定すること
を特徴とするP2P端末。 - 請求項1ないし請求項3の何れか1項に記載のP2P端末において、
前記キャッシュ復元手段は、前記ローカルネットワークを構成するカラオケ端末からキャッシュファイルの配信要求を受けている場合、その配信要求に該当のキャッシュファイルを保有する前記取得先端末を選定し、その選定した取得先端末から当該配信要求に該当のキャッシュファイルを優先して取得すること
を特徴とするP2P端末。 - 請求項1ないし請求項4の何れか1項に記載のP2P端末において、
前記キャッシュ復元手段は、前記取得先端末を選定する事前に、前記ローカルネットワークを構成する複数のカラオケ端末におけるキャッシュファイルの保有状況を取得し、その取得した保有状況に基づいて前記取得先端末を選定すること
を特徴とするP2P端末。 - ピアツーピア(以下、P2P)ネットワークを構成し、カラオケ端末で実行されるコンテンツに関するキャッシュファイルを相互に授受する複数のP2P端末と、
前記複数のP2P端末の各々が1つ又は複数単位で接続された複数のローカルネットワークを構成する複数のカラオケ端末とを有し、
前記P2P端末の各々は、自P2P端末が接続する前記ローカルネットワークを構成する複数の前記カラオケ端末に対して、自らが保有する前記キャッシュファイル又は前記P2Pネットワークにおいて他のP2P端末から取得した前記キャッシュファイルを配信するコンテンツ配信システムであって、
前記P2P端末の各々は、
前記P2Pネットワークにおいて他のP2P端末へ送信するキャッシュファイルを格納するためのキャッシュ手段と、
前記キャッシュ手段に現に格納されているキャッシュファイルの一覧であるキャッシュファイルリストを記憶するリスト記憶手段と、
前記キャッシュ手段の不具合を検知する検知手段と、
前記検知手段により前記キャッシュ手段の不具合を検知した場合、自P2P端末が接続しているローカルネットワークを構成する複数の前記カラオケ端末の中からマウント対象となるカラオケ端末を選定するマウント先選定手段と、
前記マウント先選定手段により選定したマウント対象のカラオケ端末が備える記憶手段の特定領域を、自P2P端末の前記キャッシュ手段として代用可能な状態にマウントするマウント手段と、
前記検知手段により前記キャッシュ手段の不具合が検知された場合、前記リスト記憶手段におけるキャッシュファイルリストに記されたキャッシュファイルを保有する前記カラオケ端末及び前記他のP2P端末を特定して、その中から最もファイルの取得速度が速い端末を取得先端末として選定し、その選定した取得先端末から前記キャッシュファイルリストに記載のキャッシュファイルを取得して前記マウント手段によりマウントした特定領域に記録するキャッシュ復元手段とを備え、
そして、前記キャッシュ復元手段によりキャッシュファイルが復元された前記特定領域を、前記キャッシュ手段として代用すること
を特徴とするコンテンツ配信システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010215863A JP5168333B2 (ja) | 2010-09-27 | 2010-09-27 | P2p端末及びコンテンツ配信システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2010215863A JP5168333B2 (ja) | 2010-09-27 | 2010-09-27 | P2p端末及びコンテンツ配信システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2012073664A JP2012073664A (ja) | 2012-04-12 |
JP5168333B2 true JP5168333B2 (ja) | 2013-03-21 |
Family
ID=46169800
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2010215863A Active JP5168333B2 (ja) | 2010-09-27 | 2010-09-27 | P2p端末及びコンテンツ配信システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5168333B2 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106363653B (zh) * | 2016-10-20 | 2018-12-28 | 中国农业大学 | 一种黄瓜采摘机器人的末端执行器 |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6194202B2 (ja) * | 2013-07-19 | 2017-09-06 | 株式会社第一興商 | 通信デュエットの遅延判定方式に特徴を有するカラオケシステム |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3609599B2 (ja) * | 1998-01-30 | 2005-01-12 | 富士通株式会社 | ノード代理システム、ノード監視システム、それらの方法、及び記録媒体 |
JP2000099435A (ja) * | 1998-09-18 | 2000-04-07 | Nippon Telegr & Teleph Corp <Ntt> | サーバ切り替え装置および方法とサーバ切り替えプログラムを記録した記録媒体 |
JP3463803B2 (ja) * | 1999-11-09 | 2003-11-05 | 松下電器産業株式会社 | クラスタサーバ装置 |
JP3835199B2 (ja) * | 2001-04-25 | 2006-10-18 | 日本電気株式会社 | 分散管理型ネットワークファイルシステム及びファイル方法 |
JP2004078557A (ja) * | 2002-08-19 | 2004-03-11 | Brother Ind Ltd | メモリの保守操作方法および保守システム |
WO2009063762A1 (ja) * | 2007-11-12 | 2009-05-22 | Nec Corporation | データ通信システムおよび方法およびプログラム |
JP5176835B2 (ja) * | 2008-09-29 | 2013-04-03 | ブラザー工業株式会社 | 監視装置、情報処理装置、情報処理方法並びにプログラム |
-
2010
- 2010-09-27 JP JP2010215863A patent/JP5168333B2/ja active Active
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106363653B (zh) * | 2016-10-20 | 2018-12-28 | 中国农业大学 | 一种黄瓜采摘机器人的末端执行器 |
Also Published As
Publication number | Publication date |
---|---|
JP2012073664A (ja) | 2012-04-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7433934B2 (en) | Network storage virtualization method and system | |
US8713145B2 (en) | Information distribution system, information distributing method, node, and recording medium | |
JP5970541B2 (ja) | 情報処理システム、管理サーバ群、および、サーバ管理プログラム | |
US8250171B2 (en) | Content delivery apparatus, content delivery method, and content delivery program | |
JP4861472B2 (ja) | コンテンツ配信装置、コンテンツ配信方法、及びコンテンツ配信プログラム | |
US20090063507A1 (en) | Methods and apparatus for retrieving content | |
WO2007134918A1 (en) | Distributed storage | |
US8903906B2 (en) | Information communications system, node device, method of communicating contents, computer readable recording medium storing a program | |
US10387043B2 (en) | Writing target file including determination of whether to apply duplication elimination | |
US20080235244A1 (en) | Distributed content storing system, node device, node process program, and content data providing method | |
JP5168333B2 (ja) | P2p端末及びコンテンツ配信システム | |
US9544371B1 (en) | Method to discover multiple paths to disk devices cluster wide | |
JP5445138B2 (ja) | データ分散格納方法およびデータ分散格納システム | |
CN115004665B (zh) | 文件分享方法、装置及系统 | |
JP2010271933A (ja) | 分散保存システム、ノード装置、ノード処理プログラム及びデータファイル保存方法 | |
JP2011211543A (ja) | 情報通信システム、情報処理装置、情報処理方法、及び情報処理プログラム | |
JP4877107B2 (ja) | 情報配信システムにおける端末装置及び情報処理プログラム、並びに端末装置の情報処理方法 | |
JP2011118593A (ja) | データ転送サーバ、データ転送システム、データ転送方法およびプログラム | |
WO2013047207A1 (ja) | キャッシュシステム、キャッシュ方法、及びキャッシュサーバ | |
EP3479550B1 (en) | Constraint based controlled seeding | |
US20100250593A1 (en) | Node device, information communication system, method for managing content data, and computer readable medium | |
JP2013105227A (ja) | P2P型Webプロキシネットワークシステム | |
US20100250594A1 (en) | Node device, information communication system, method for retrieving content data, and computer readable medium | |
JP2011008657A (ja) | コンテンツ配信システム、ノード装置、コンテンツ配信方法及びノードプログラム | |
JP2014203329A (ja) | ストレージシステム、ノード装置及びデータ管理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121121 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20121127 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20121210 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5168333 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |