JP2004102493A - コンテンツ配信方法及びコンテンツ配信制御装置 - Google Patents
コンテンツ配信方法及びコンテンツ配信制御装置 Download PDFInfo
- Publication number
- JP2004102493A JP2004102493A JP2002261261A JP2002261261A JP2004102493A JP 2004102493 A JP2004102493 A JP 2004102493A JP 2002261261 A JP2002261261 A JP 2002261261A JP 2002261261 A JP2002261261 A JP 2002261261A JP 2004102493 A JP2004102493 A JP 2004102493A
- Authority
- JP
- Japan
- Prior art keywords
- archive
- receiving device
- information
- content
- 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.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】本発明は情報を提供するサーバにかかる負荷を効率的に分散するとともに新たな設備を導入するコストや設備を管理及び運営するコストなどの増大を抑制することを目的とする。
【解決手段】更新されたコンテンツを一纏めにして書庫として管理する手順と、書庫の転送先の受信装置を決定する手順と、書庫を送信装置から決定された特定の受信装置に転送する手順と、各受信装置が送信装置の書庫を受け取った場合に、第1のイベント情報を生成し前記送信装置に通知する手順と、各受信装置が受信した書庫の内容を展開して管理する手順と、各受信装置が受信した書庫の情報の再転送先となる他の受信装置を決定する手順と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する手順と、各受信装置が他の受信装置から書庫を受け取った場合に第2のイベント情報を転送元と送信装置に通知する手順とを設けた。
【選択図】 図1
【解決手段】更新されたコンテンツを一纏めにして書庫として管理する手順と、書庫の転送先の受信装置を決定する手順と、書庫を送信装置から決定された特定の受信装置に転送する手順と、各受信装置が送信装置の書庫を受け取った場合に、第1のイベント情報を生成し前記送信装置に通知する手順と、各受信装置が受信した書庫の内容を展開して管理する手順と、各受信装置が受信した書庫の情報の再転送先となる他の受信装置を決定する手順と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する手順と、各受信装置が他の受信装置から書庫を受け取った場合に第2のイベント情報を転送元と送信装置に通知する手順とを設けた。
【選択図】 図1
Description
【0001】
【発明の属する技術分野】
本発明は、様々なコンテンツのデータを不特定多数に配信する場合に利用可能なコンテンツ配信方法及びコンテンツ配信制御装置に関する。
【0002】
【従来の技術】
コンテンツ配信方法や配信時のサーバにかかる負荷を効率的に削減する従来技術として、マルチキャストを用いてファイルを配信する方法(特許文献1)、オリジナルサーバに蓄積するコンテンツのうち人気のあるものだけを配信するシステム(特許文献2)、オリジナルサーバで更新され続けるコンテンツのうち、最新の差分だけを配信する方法(特許文献3)などがある。
【特許文献1】特願2002−024389号
【特許文献2】特開2001−27965号公報
【特許文献3】特開2001−92699号公報
インターネット上のようにアクセスが集中する可能性のある環境で様々なコンテンツの情報を提供しようとする場合には、サーバに対する負荷を分散するために複数のサーバをネットワークに接続し、それぞれのサーバにコンテンツの情報を蓄積しておく場合が多い。
【0003】
このような通信システムにおいては、最初にコンテンツを保持する1つのサーバはオリジナルサーバと呼ばれ、オリジナルサーバからコンテンツの転送を受ける他のサーバはミラーサーバと呼ばれる。
オリジナルサーバから不特定多数のミラーサーバに対してコンテンツを配信する場合の配信方式としては、PUSH型,PULL型,IPマルチキャストプロトコルを用いる方式などが考えられる。
【0004】
PUSH型の場合には、オリジナルサーバからミラーサーバに対してコンテンツを送りつける。PULL型の場合には、ミラーサーバが定期的にオリジナルサーバに問い合わせを行い、更新されたコンテンツをミラーサーバがオリジナルサーバからダウンロードする。IPマルチキャストプロトコルを用いる場合には、オリジナルサーバから全てのミラーサーバに対して一斉にコンテンツを配信する。
【0005】
また、PUSH型は更に一定間隔方式,スケジュール方式,オンデマンド方式などに区分することができる。
一定間隔方式の場合には、コンテンツを送信する契機として、1分おき、1時間おきなどの一定時間間隔を用いる。スケジュール方式の場合には、例えば毎朝6時など予めスケジュールで定めた時刻に配布を開始する。オンデマンド方式の場合には、コンテンツ提供者が送りたいときに配布を開始する。
【0006】
また、配信宛先が大量になる場合には、同時に配信する宛先数を制限して配信セッションを分けたり、分けることができない場合にはオリジナルサーバの数を宛先数に応じて増やしたりして対処するのが一般的である。
配信セッションを分ける方法では、オリジナルサーバを増やすことなく多数の宛先に配信することが可能であり、低コストであるという長所があるが、宛先数が増えるに従って配信所要時間が長くなるという問題もある。
【0007】
このため、一定間隔方式やスケジュール方式を採用している場合には、オリジナルサーバにおいて、最初に起動された配信処理中に、次に起動された配信処理が重ならないように配信処理間隔を定める必要がある。また、オリジナルサーバが故障すると全ての配信処理が停止するので、オリジナルサーバのクラスター化のような信頼性向上施策が不可欠である。
【0008】
PULL型についても、PUSH型と同様に一定間隔方式,スケジュール方式,オンデマンド方式などの配信契機を持たせることができる。
PULL型の場合には、オリジナルサーバにおけるファイルリストとミラーサーバにおけるファイルリストとを比較して、足りないファイルをダウンロードすることができるので、ミラーサーバにおいて欠損ファイルが生じたり、何らかの理由で更新間隔が長くなってしまった場合には、容易にミラーサーバのコンテンツの内容をオリジナルサーバと同一の内容までキャッチアップすることができる。
【0009】
しかしながら、PULL型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかや、オリジナルサーバからミラーサーバへのファイルの転送がいつ終了するかが分からないので、配信宛先数が増えた場合に負荷を分散するのが困難になる。
【0010】
すなわち、PULL型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかをオリジナルサーバ上で把握できないので、PUSH型の場合のようにオリジナルサーバからの同時配信処理数を制限するようにサーバ毎の配信処理時間を定めることができない。
従って、大量のミラーサーバからのアクセス負荷を分散するために、オリジナルサーバを複数台用意しておき、ミラーサーバ群はいくつかの台数毎にグループに分け、グループ毎に異なるオリジナルサーバを割り当てるような構成をとる必要がある。
【0011】
また、ミラーサーバをグループ分けしない場合にはオリジナルサーバとミラーサーバ群との間に負荷分散装置を配置し、ミラーサーバ群からのアクセスを負荷分散装置で振り分ける処理を行う必要がある。
また、PUSH型、PULL型のいずれの場合についても、データセンタを構成する場合には高信頼なオリジナルサーバを設置し、大容量配信のためにネットワーク帯域を増強する必要がある。
【0012】
ミラーサーバが増えた場合の負荷の集中を防止するのに最も適した方法は、IPマルチキャストを用いてファイルを配信することである。
IPマルチキャストを用いると、最も理想的な場合には一度の配信処理だけで、全てのミラーサーバヘのファイル配信を完了することができる。しかし、実際のインターネットではIPパケットの消失の無い理想的な配信は困難なのでIPパケットの再送によるエラー回復が必要になる。
【0013】
エラー回復の技術については、連送配信と逐次回復の2つに分けることができる。連送配信の場合には、最初から同じデータを複数回重複させて配信する。逐次回復の場合には、受信に失敗したミラーサーバに対して回復データをTCPコネクションで受け渡す。
しかし、受信側のミラーサーバの数が増大すると、連送配信の場合には確率的には連送回数を増やす必要があるし、逐次回復の場合には確率的にエラーを起こす受信側が増えるので、エラー回復のためのオリジナルサーバの負荷が増大するのは避けられない。
【0014】
一方、IPマルチキャストプロトコルは、公共のネットワークであるインターネット上では実質的に伝搬不可能であるし、イントラネット内であっても、ネットワーク機器やサイトポリシーの都合により伝搬不可能な場合が多い。
そのため、IPマルチキャストプロトコルを用いたファイル配信は実際には採用できない場合がほとんどである。
【0015】
【発明が解決しようとする課題】
大量のファイルを大量のミラーサーバに配信するような場合には、前述のPUSH型配信、PULL型配信のいずれであっても、受信先のミラーサーバの数の増大に伴って、オリジナルサーバ側のサーバ端末やネットワークの負荷が増大することは避けられない。
【0016】
このような負荷を分散する手法としては、オリジナルサーバからミラーサーバヘの配信時間をずらし、時間軸に沿って負荷を分散する方式や、オリジナルサーバの台数を増強するとともにネットワークの帯域幅も増やし、設備増強により負荷を分散する方式とがある。
しかし、前者の負荷分散方式では、ファイルサイズが大きくなったり、宛先ミラーサーバの数が著しく増大した場合には、許容された時間内で配信が終了できない可能性がある。
【0017】
また、後者の負荷分散方式では、設備を導入するコストや設備を管理及び運営するコストなどがかさんでしまい、ファイルを分散させるメリットが薄れてしまう。
このように、オリジナルサーバにかかる負荷が大きく、またその負荷を分散させることが難しい一方で、ミラーサーバ側はオリジナルサーバからのファイルを受信する以外の負荷はほとんどかかっておらず、サーバ能力及びネットワーク帯域幅には共に余力がある。
【0018】
なお、このような状況はオリジナルサーバと多数のミラーサーバとで構成される特定の通信システムに限ったことではなく、サーバと多数のクライアント端末とで構成される一般的な通信システムにおいても想定される問題である。
本発明は、情報を提供するサーバにかかる負荷を効率的に分散するとともに、新たな設備を導入するコストや設備を管理及び運営するコストなどの増大を抑制することを目的とする。
【0019】
【課題を解決するための手段】
請求項1は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信方法において、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手順と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手順と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手順と、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手順と、生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手順と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手順と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手順とを設けたことを特徴とする。
【0020】
請求項1においては、送信装置から受信装置に配信すべき情報は、コンテンツ書庫化手順によって最小化される。すなわち、前回の配信時と比べて新たに追加登録されたコンテンツ及び内容の更新されたコンテンツの全てが一纏めにされ、圧縮されて書庫として管理される。従って、配信するファイルのサイズが低減される。
【0021】
送信装置は配下の全ての受信装置に対してコンテンツを配信する必要はない。すなわち、転送宛先決定手順で決定された特定の転送先の受信装置に対して書庫の情報が書庫転送手順で転送される。
各受信装置が送信装置から書庫の情報を受け取った場合には、第1のイベント情報が生成され、これが送信装置に通知されるので、送信装置は各受信装置に対するコンテンツの配信状況を把握することができる。このようなコンテンツの配信状況は、配信履歴として所定のデータベースに記録される。
【0022】
コンテンツの配信状況を参照することにより、書庫の情報を取得済みの受信装置と未配信の受信装置とを区別することができる。
請求項1においては、書庫の情報を取得した受信装置は未配信の他の受信装置の有無を識別し、未配信の他の受信装置に対して送信装置の代わりに受信情報を再配信する。
【0023】
このように、書庫の情報を取得した受信装置が他の受信装置に対して受信情報を再配信するので、送信装置(例えば前述のオリジナルサーバ)は一部分の受信装置(例えば前述のミラーサーバ)だけにコンテンツを配信すればよく、配信先の増大に伴う送信装置側の負荷の増大を受信装置が肩代わりすることになる。従って、配信にかかるコストの低減,時間の短縮,信頼性の向上などが実現する。
【0024】
請求項2は、請求項1のコンテンツ配信方法において、前記コンテンツ書庫化手順では、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
【0025】
請求項2においては、属性情報を参照することにより、様々な状況の把握が可能になる。すなわち、書庫化日時及びバージョンの情報を参照することにより、該当するファイルが受信装置の既に受け取った書庫化ファイルと同じか否か、あるいは該当するファイルが受信装置の既に受信して展開したファイルよりも古いか否かを検査することができる。
【0026】
例えば、受信した書庫化ファイルと同一バージョンのファイル、もしくは受信した書庫化ファイルよりも新しいバージョンのファイルを展開し終えている場合には、受信した書庫化ファイルを展開しないように制御することができる。
なお、書庫に含まれる元のファイルの情報としては、ファイル名,タイムスタンプ,サイズなどが考えられる。これらの情報は、書庫化ファイルを展開した後で、展開したファイルの情報を属性情報に合わせて書き換えるために用いることができる。また、オリジナルコンテンツの全ファイルのファイル名,タイムスタンプ,サイズなどの情報を書庫に含めてもよい。
【0027】
例えば、送信装置にあるファイルと受信装置にあるファイルのタイムスタンプが両者で一致するように処理することにより、受信装置は自分の保持するファイルが、送信装置にあるファイルと同一かどうかを容易に検査できる。
請求項3は、請求項1のコンテンツ配信方法において、前記転送宛先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【0028】
請求項3においては、複数の受信装置を複数のグループに区分して管理するので、グループ毎に転送先の受信装置を決定することができる。このため、全てのグループに均等に転送が配分されるように負荷を分散することも容易である。
また、最初は各グループの最上位の受信装置だけを選択するが、最上位の受信装置が故障などの原因で応答しない場合には、次順位の受信装置を選択する。次順位の受信装置が故障している場合には、更にその次の受信装置というように、降順で受信装置を選択する。
【0029】
また、一通りのグループに配信が行き渡り、更に各グループ内においてはまだ未配信の受信装置がある場合には、今度は各グループの最下位から昇順で配信先の受信装置を選択する。
請求項4は、請求項1のコンテンツ配信方法において、前記再転送先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択することを特徴とする。
【0030】
請求項4においては、既に書庫の情報を受信した第1の受信装置と同一のグループに属する他の受信装置の中から、再転送先となる第2の受信装置が選択されるので、受信装置同士の間で実施される情報の再転送は同一グループ内に限定される。このため、第2の受信装置の選択が容易になる。また、ネットワーク上の通信経路が複雑化するのを避けることもできる。
【0031】
請求項5は、請求項1のコンテンツ配信方法において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手順と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手順とをさらに設けたことを特徴とする。
【0032】
請求項5においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を受信中か否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルの配信要求があっても、その要求を受け付けないように制御できる。
なお、ログファイルに出力される進捗情報としては、受信中書庫化ファイルの名称,書庫化ファイル全体のサイズ,現在までに受信が終了したファイル量などが考えられる。
【0033】
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
請求項6は、請求項5のコンテンツ配信方法において、前記書庫情報展開手順では、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【0034】
請求項6においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を展開処理中であるか否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルが複数存在する場合であっても、他の書庫化ファイルの展開処理を開始しないように制御できる。
【0035】
ログファイルに出力される進捗情報については、書庫化ファイルに含まれる全ファイル数や現在までに展開が終了したファイル数などが考えられる。
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
【0036】
なお、受信装置において書庫化ファイルの展開が終了すると、書庫化ファイル展開終了のイベントデータを作成し、それを送信装置にを通知する。通知されたイベントデータは送信装置のデータベースに記録され、転送宛先を決定する際に参照される。
請求項7は、請求項1のコンテンツ配信方法において、前記書庫情報展開手順では、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【0037】
請求項7においては、受信した書庫内に含まれているファイルの展開に失敗した場合であっても、受信装置における自律的な制御により該当するファイルを他の受信装置からダウンロードしてエラーを回避することができる。
該当するファイルと同じ情報を既に保持している他の受信装置を検索する場合には、最初は同一バージョンのファイルを保持している受信装置を検索する。該当する受信装置が存在しない場合には、同じコンテンツ名の、最も新しいバージョンの書庫化ファイルを保持し、かつネットワーク上で最も近い受信装置を検索する。
【0038】
なお、エラーの発生したバージョンとは異なる最新バージョンの書庫化ファイルを受信装置が受け取った場合には、バージョンの相違によりコンテンツ内容の不備が生じる可能性がある。
オリジナルコンテンツのファイルリストが書庫化ファイルに付加されている場合には、その内容からコンテンツ内容の不備を検出することが可能である。不足するファイルが存在する場合には、そのファイルを個別に前記最新の書庫化ファイルを保持する受信装置からダウンロードすればよい。
【0039】
請求項8のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手段と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手段と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手段と、各々の受信装置について、書庫の情報を受け取ったか否かを表す情報を管理し、その結果を前記転送宛先決定手段の制御に反映する受信状況管理手段とを設けたことを特徴とする。
【0040】
請求項8においては、請求項1の方法と同様に、送信装置は全ての受信装置に対してコンテンツを配信する必要がないので、送信装置にかかる負荷を分散することができる。
請求項9のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置が、新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するとともに、前記書庫で管理されている情報を特定の受信装置に配信する場合に、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手段と、生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手段と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手段と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手段とを設けたことを特徴とする。
【0041】
請求項9においては、請求項1の方法と同様に、各受信装置が書庫の情報を受け取ったか否かを把握することができるので、送信装置から情報を受け取った受信装置は他の受信装置に対して情報を再転送することができる。
受信装置同士の間で情報の再転送が実施されるので、送信装置がコンテンツを配信すべき受信装置の数を減らすことができ、送信装置にかかる負荷を分散することができる。
【0042】
請求項10は、請求項8のコンテンツ配信制御装置において、前記コンテンツ書庫化手段は、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
請求項10においては、請求項2の方法と同様の結果が得られる。
【0043】
請求項11は、請求項8のコンテンツ配信制御装置において、前記転送宛先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【0044】
請求項11においては、請求項3の方法と同様の結果が得られる。
請求項12は、請求項9のコンテンツ配信制御装置において、前記再転送先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択することを特徴とする。
【0045】
請求項12においては、請求項4の方法と同様の結果が得られる。
請求項13は、請求項9のコンテンツ配信制御装置において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手段と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手段とをさらに設けたことを特徴とする。
【0046】
請求項13においては、請求項5の方法と同様の結果が得られる。
請求項14は、請求項13のコンテンツ配信制御装置において、前記書庫情報展開手段は、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【0047】
請求項14においては、請求項6の方法と同様の結果が得られる。
請求項15は、請求項9のコンテンツ配信制御装置において、前記書庫情報展開手段は、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【0048】
請求項15においては、請求項7の方法と同様の結果が得られる。
【0049】
【発明の実施の形態】
本発明のコンテンツ配信方法及びコンテンツ配信制御装置の1つの実施の形態について、図1〜図11を参照して説明する。この形態は全ての請求項に対応する。
【0050】
図1は通信システムの構成例を示すブロック図である。図2は送信装置の動作を示すフローチャートである。図3は受信装置の動作を示すフローチャートである。図4は転送宛先決定部の動作(1)を示すフローチャートである。図5は転送宛先決定部の動作(2)を示すフローチャートである。
図6は通信システム全体の動作例を示すシーケンス図である。図7は送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。図8はMirrorControlファイルの構成を示す模式図である。図9はCommonConfigファイルの構成を示す模式図である。図10は配信制御テーブルの構成例を示す模式図である。図11は装置間通信メッセージの構成例を示す模式図である。
【0051】
この形態では、請求項8の送信装置,受信装置,コンテンツ書庫化手段,転送宛先決定手段,書庫転送手段及び受信状況管理手段は、それぞれ送信装置10,受信装置20,書庫化ファイル生成部11,転送宛先決定部30,書庫化ファイル送信部12及び配信制御用DB(データベース)14に対応する。
また、請求項9の第1のイベント情報生成手段,第1のイベント情報通知手段,書庫情報展開手段,再転送先決定手段,書庫再転送手段及び第2のイベント情報通知手段は、それぞれステップS86,書庫化ファイル送受信部22,書庫化ファイル展開部21,転送宛先決定部30,書庫化ファイル送受信部22及びステップS91に対応する。
【0052】
また、請求項13のロックファイル作成手段及び受信ログ生成手段は書庫化ファイル送受信部22に対応する。
この形態では、図1に示すような構成の通信システムを用いて、送信装置10から複数の受信装置20に対してコンテンツを配信する場合を想定している。例えば、オリジナルサーバとミラーサーバとの間でコンテンツの転送を行う場合には、送信装置10がオリジナルサーバに相当し、受信装置20がミラーサーバに相当する。また、サーバとクライアント端末との間でコンテンツの転送を行う場合には、送信装置10がサーバに相当し、受信装置20がクライアント端末に相当する。
【0053】
図1に示す通信システムにおいては、送信装置10,転送宛先決定部30及び複数の受信装置20がIPネットワーク35を介して互いに接続されている。なお、転送宛先決定部30については送信装置10と一体に構成することもできるし、いずれかの受信装置20に配置することもできる。
送信装置10は、書庫化ファイル生成部11,書庫化ファイル送信部12,コンテンツ記憶部13及び配信制御用DB14を備えている。
【0054】
コンテンツ記憶部13には配信すべきコンテンツの情報が保持され、その情報はコンテンツ提供者からの要求などに応じて追加及び更新される。配信制御用DB14には、配信制御に必要な様々な情報が保持される。配信制御用DB14上の情報は必要に応じて更新される。
コンテンツ記憶部13については、実際には送信装置10の本体にSCSIインタフェースやATAインタフェースで直接接続してもよいし、外部装置である記憶装置サーバ(NAS:Network Attached Strage)をNFSで送信装置10に接続してもよい。
【0055】
送信装置10から受信装置20へのコンテンツ配信を開始する条件(図2に示す動作を開始する条件)は、前回配信時のコンテンツと比べて新しいファイルがコンテンツ記憶部13に追加された場合、又はファイルのタイムスタンプやファイルサイズが更新されたことを発見した場合である。
この検査は、送信装置10上のコンテンツ記憶部13を走査することによって行われる。
【0056】
コンテンツ記憶部13を走査する契機については、送信装置10上にコンテンツ毎に用意されているMirrorControlファイルと呼ばれる定義ファイルの内容に応じて、Event型,Scheduled型,OnDemand型のいずれかに切り替えることができる。
【0057】
Event型の場合には、例えば1分おき、1時間おきなどの一定時間周期で走査を行う。Scheduled型の場合には、例えば毎日午前8時、毎週月曜〜金曜の午前8時などのように特定の時間に走査を行う。OnDemand型の場合には、コンテンツを追加した任意の時間にコンテンツの配信を行う。
書庫化ファイル生成部11は、コンテンツ記憶部13上に新たなコンテンツが追加された場合や、既に登録されているコンテンツのバージョンが更新された場合に、追加又は更新された全てのコンテンツのファイルを一纏めにして書庫として管理する。書庫内に格納される各々のファイルは、圧縮された状態で保持される。また、書庫にはそれに格納されているファイルを管理するための情報が含まれている。
【0058】
書庫化ファイル送信部12は、書庫化ファイル生成部11が生成した書庫の内容、すなわち前回配信時の内容とは異なる追加又は変更されたコンテンツの情報を受信装置20に対して送信する。この場合の宛先は、転送宛先決定部30が決定する。
転送宛先決定部30は、送信装置10又はいずれかの受信装置20から問い合わせを受けた場合に、送信装置10上の配信制御用DB14で管理されている情報に基づいて特定の受信装置20を宛先として決定する。
【0059】
各受信装置20に備わった書庫化ファイル送受信部22は、送信装置10又は他の受信装置20から送信されるコンテンツの情報を受信するとともに、受信した情報を他の未受信の受信装置20に対して再転送する。
また、受信したコンテンツの情報は書庫として纏められ圧縮されているので、その情報を書庫化ファイル展開部21が展開する。展開した受信情報はコンテンツ記憶部23に蓄積される。
【0060】
ところで、コンテンツ記憶部13及び23上の記憶領域は、図7に示すような階層構造により、領域毎にディレクトリとして区分されて管理されている。また、この形態ではディレクトリ毎にコンテンツの配信を制御することができる。そのため、MirrorControlファイルはディレクトリ毎にそれぞれ用意される。
図7に示す階層構造においては、ServiceDirectoryRootで示されたディレクトリが最上位の階層の記憶領域を表している。このディレクトリの下の階層にはServerのディレクトリが作成され、更にその下の階層に、Contentsディレクトリと、Resourcesディレクトリと、Systemディレクトリとが配置されている。
【0061】
また、TreeManagerの下の階層にはResourcesディレクトリだけが配置されている。
この例では、Serverのディレクトリの下の階層に配置されるファイルは、主に送信装置10自身が参照し、TreeManagerディレクトリ以下の階層に配置されるファイルは、主に転送宛先決定部30によって参照される。
【0062】
また、Serverのディレクトリの下の階層のContentsディレクトリの下には、コンテンツ配信単位で独立したディレクトリが配置され、それらのディレクトリの配下に、コンテンツ提供者から送信される実際のコンテンツが配置される。
Contentsディレクトリ配下のディレクトリをここではコンテンツ名と呼ぶ。このコンテンツ名に対応したディレクトリが、ServiceDirectoryRoot/Server/Resourcesの配下にも作られる。これらのディレクトリには、コンテンツ毎の定義ファイルが配置される。
【0063】
このコンテンツ名毎のディレクトリの各々を、ここではリソースディレクトリと呼ぶ。MirrorControlファイルは、リソースディレクトリに配置される。
各々のMirrorControlファイルには、図8に示すような様々なパラメータが含まれている。図8に示すように、インターバルを決定するパラメータVersionCheckInterval,EventDrivenPushInterval,ScheduledPushIntervalは、MirrorControlファイルの中で独立に指定することができる。すなわち、コンテンツのバージョンの走査周期と配信の周期とは独立に定めることができる。
【0064】
また、EventDrivenPushIntervalによって制御されるイベントドリブン型プッシュ制御とScheduledPushIntervalによって制御されるスケジュール型プッシュ制御とは同時に動作させることができる。
例えば、イベントドリブン型プッシュ制御により配信処理が行われた後でスケジュール型プッシュ制御により配信処理が行われる場合を想定すると、イベントドリブン型プッシュ制御とスケジュール型プッシュ制御との間でバージョンチェックが実施されるが、この時に新規コンテンツが検出されない場合には、コンテンツの書庫化及びファイルの配信は行われない。
【0065】
オンデマンド型の配信制御を行う場合には、任意のタイミングでバージョンチェック及びコンテンツの配信処理を起動することができる。
書庫化ファイルの作成は、バージョンチェックが行われた後で、イベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動するか、もしくはオンデマンド配信コマンドが呼ばれることによって実施される。
【0066】
書庫化ファイルの作成時には、ロックファイルDarLockが作成される。このロックファイルDarLockの有無は、制御の中で参照される。例えば、書庫化ファイルの作成に時間がかかり、作成が終了する前に次の書庫化ファイル作成タイミングが到来したような場合には、ロックファイルDarLockが存在するので、次のプロセスの起動を中止する。
【0067】
これにより、書庫化ファイルの作成プロセスが2重に起動するのを防止できるので、先に起動された書庫化プロセスと、後から起動された書庫化プロセスの両方に格納されるファイルが出てきたり、そのどちらにも格納されないファイルが出てくるのを避けることができる。
書庫化ファイルの作成が無事終了した場合には、ロックファイルDarLockは削除される。この後で、次のイベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動されると、書庫化ファイルの作成が可能になる。
【0068】
書庫化ファイルの作成が終了すると、次は配信宛先となる受信装置20に対して配信通知を行う。
ところで、ServiceDirectoryRoot/Server/Systemの配下には定義ファイルCommonConfigが存在する。書庫化ファイルの配信は、送信装置10の性能的な許容負荷を超えない範囲で行う必要がある。そのために、定義ファイルCommonConfigの中には、図9に示すようにパラメータMaxPararelTransferを設けてある。
【0069】
この例では、ServiceDirectoryRoot/Server/Resourcesの配下とServiceDirectoryRoot/Server/Systemの配下とにそれぞれ定義ファイルが配置される。Resourcesの配下に配置される定義ファイルはコンテンツ毎に独立しており、Systemの配下の定義ファイルはシステム全体で共通のパラメータとして利用される。
送信装置10の配信能力は、コンテンツ毎に決定されるものではなく、送信装置10全体で決定される。そのため、Systemの配下に配置される定義ファイルCommonConfigの中で、最大並行配信数(MaxPararelTransfer)のパラメータを定義してある。
【0070】
送信装置10の書庫化ファイル送信部12は、転送宛先決定部30を用いて配信先の受信装置20を決定する。この場合、書庫化ファイル送信部12はそれ自身の定義ファイルCommonConfigにおけるパラメータ(MaxPararelTransfer)と、現在コンテンツを送信中の受信装置20の数を配信制御用DB14の内容に基づいて計算し、これからコンテンツの送信を行う受信装置20の数が(MaxPararelTransfer)を超えない数の分だけ、転送宛先決定部30に対して転送先の受信装置名を要求(問い合わせ)する。
【0071】
転送宛先決定部30は、送信装置10から問い合わせを受けると、送信装置10上の配信制御用DB14の内容を参照して、転送先の受信装置20を決定する。
配信制御用DB14には、図10に示すような構成の配信制御テーブルが保持されている。この配信制御テーブルは、コンテンツ毎にそれぞれ用意されている。各配信制御テーブルには、それぞれの受信装置20について、受信装置名,コンテンツバージョン,配信開始日時,配信終了日時及び装置状態の情報が記録されている。
【0072】
また、送信装置10から転送宛先決定部30への問い合わせのメッセージは、図11に示すように送信装置名と、コンテンツ名と、コンテンツバージョンの情報とを含んでいる。また、この問い合わせに対する転送宛先決定部30から送信装置10への返信メッセージには、受信装置名とそのURL又はIPアドレスとが含まれている。
【0073】
ところで、転送宛先決定部30は、配信制御用DB14に記述されている多数の受信装置20を複数グループに区分し、目印を付けて管理している。各々のグループにはn個の受信装置20が割り当てられる。nの値については、オペレータが任意に決定すればよい。また、各グループ内のn個の受信装置20は、例えば並び順などによりグループ内の順位を付けて管理されている。
【0074】
そして、転送宛先決定部30は送信装置10からの転送宛先の問い合わせが届くと、まず、各々のグループにおける1番目の順位の受信装置20を代表受信装置として選択し、その情報を順番に送信装置10に返す。
もしも1番目の順位の受信装置20の状態が異常である場合には、2番目の順位の受信装置20を代表受信装置として選択する。
【0075】
また、各グループの代表受信装置が全て配信済みになった場合には、転送宛先決定部30は各グループの最下位の順位の受信装置20を配信宛先として選択する。
このように、選択する順番を順位の降順と昇順とで切り替えるのは、配信の重複が生じるのをなるべく避けるためである。すなわち、転送宛先決定部30に対する問い合わせ及びコンテンツの転送をするのは送信装置10だけでなく、複数の受信装置20も問い合わせをするので、問い合わせに対する回答の内容及びタイミングによっては同じ受信装置20に対して重複してコンテンツの配信が行われる可能性がある。
【0076】
転送宛先決定部30が転送宛先の受信装置20を選択する順番を順位の降順と昇順とで切り替えることにより、コンテンツの重複配信が生じる可能性を減らすことができる。
転送宛先決定部30が送信装置10から転送宛先の問い合わせを受けた場合の転送宛先決定部30における動作は以上に説明した通りであり、動作手順の概略を図で示すと図4のようになる。
【0077】
コンテンツの配信を実行する場合、送信装置10の書庫化ファイル送信部12は転送宛先決定部30に対して問い合わせを行い、書庫化ファイル送信部12は転送宛先決定部30からの応答として転送宛先の受信装置名を取得する(図2のS39)。
この後、書庫化ファイル送信部12は、コンテンツを送信するが、その前に転送宛先決定部30で決定された特定の受信装置20に対して、コンテンツの更新通知を送信する(図2のS41)。
【0078】
このコンテンツの更新通知には、図11に示すように受信装置20が取得すべき書庫化ファイル名とコンテンツのバージョンとが含まれている。
受信装置20は、送信装置10又は他の受信装置20からのコンテンツ更新通知を受信すると、図3に示すような処理を実行し、送信装置10からのコンテンツの受信及び他の受信装置20へのコンテンツの再転送を行う。
【0079】
但し、コンテンツの更新通知を受けた受信装置20が既に該当するバージョンのコンテンツをダウンロードしている最中であるか、もしくは既に取得済みである場合には、コンテンツの更新通知に対する処理をキャンセルする。その場合、受信装置20は送信装置10に対して、当該コンテンツをダウンロードしている最中か、取得済みであるかのどちらかの情報を通知する(図3のS65)。
【0080】
この通知を受信すると、送信装置10はそれ自身が保持している配信制御用DB14上の配信制御テーブルの内容を、受信装置20からのメッセージに従って書き換える。
受信装置20は、更新通知として送信装置10から通知されたコンテンツをまだ取得していなければ、該当するコンテンツの書庫化ファイルを、通知を発した送信装置10もしくは他の受信装置20からダウンロードする(図3のS52)。
【0081】
書庫化ファイルのダウンロードが始まると、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を「送信装置より受信中」に書き換える。
また、書庫化ファイルのダウンロードが終了すると、受信装置20はダウンロードを結果を送信装置10に通知する。この場合も、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を通知に従って書き換える。
【0082】
但し、通知の内容が「異常終了」であった場合には、再び送信装置10から受信装置20にコンテンツの更新通知が送信され、書庫化ファイルのダウンロードがやり直される。
通知の内容が「正常終了」であった場合には、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を「正常終了」に書き換える。そして、次の転送宛先となる受信装置20を転送宛先決定部30に問い合わせる。
【0083】
一方、書庫化ファイルを受信した受信装置20においては、受信した書庫の内容を書庫化ファイル展開部21が展開するのと並行して、他の受信装置20に対する書庫化ファイルの再転送のための処理を開始する。すなわち、コンテンツの受信を完了した受信装置20は送信装置10の代わりに、未受信の受信装置20に対するコンテンツの転送を行う。
【0084】
この場合、書庫化ファイルを既に受信した受信装置20は、転送宛先決定部30に対して書庫化ファイルを再転送すべき宛先の他の受信装置20の名称を問い合わせる(図3のS53)。
受信装置20から転送先の問い合わせを受けると、転送宛先決定部30は図5に示すような動作を行う。
【0085】
すなわち、転送宛先決定部30は配信制御用DB14上の配信制御テーブルを参照し、問い合わせ元の受信装置20が属するグループ内の受信状況を検査し(S21)、未配信の受信装置20を該当するグループの上位から順に転送先として選択する(S23)。
未配信の受信装置20が存在しない場合には、転送宛先決定部30は無し(NULL)を問い合わせ元の受信装置20に応答する(S26)。
【0086】
受信装置20は、問い合わせの結果として転送宛先決定部30から無し(NULL)を受信した場合には、配信処理を終了する。
なお、転送宛先決定部30は問い合わせを受けた場合に、未配信でかつ、可能であればネットワーク的に近い距離にある受信装置20を計算して転送先として選択するのが望ましい。
【0087】
また、転送宛先決定部30は、求めるバージョンのコンテンツが未配信の受信装置20を配信制御用DB14から検索した結果、該当する受信装置20が見つかった場合には、その受信装置20の名前(IPアドレス又はURL)を転送先として返す。
一方、書庫化ファイルを受信した受信装置20においては、書庫の展開が無事に終了すると、「展開終了」のステータス情報を送信装置10に対して通知する(図3のS64)。
【0088】
この通知を受けた送信装置10は、通知に従って配信制御用DB14の状態を書き換える。一方、受信装置20から他の受信装置20の名前が返ってきた場合には、返ってきた名前の受信装置20に対して送信装置10はコンテンツの更新通知を送信する。
なお、受信装置20が他の受信装置20に対して書庫化ファイルを送信する場合にも、最大並行配信数については送信装置10の場合と同様に、ServiceDirectoryRoot/Server/System/CommonConfigに記述されているパラメータMaxPararelTransferの値に従う。
【0089】
すなわち、受信装置20はパラメータMaxPararelTransferの値によって許される数だけ、転送宛先決定部30に対して再転送先となる未配信の受信装置20を問い合わせ、その結果として転送宛先決定部30から通知された未配信の受信装置20に対してコンテンツの更新通知を送信する(S55)。
一方、受信装置20は他の受信装置20からコンテンツの更新通知を受け取ると、更新通知を送信した受信装置20から該当する書庫化ファイルをダウンロードする(S52)。
【0090】
但し、他の書庫化ファイルを受信している途中であったり、受信した書庫化ファイルを展開している途中であると、送信装置10に拒否が通知される(S65)。これらの条件に適合するときには、ロックファイルが作成されているので、図3のステップS51ではロックファイルの有無を調べる。
他の受信装置20からの書庫化ファイルのダウンロードが正常に終了した場合には、受信装置20は「正常終了」のメッセージを送信側の受信装置20及び送信装置10に対して通知する。
【0091】
受信装置20からの通知を受けると、送信装置10は配信制御用DB14の状態を書き換える。
受信装置20においては、他の受信装置20に対する書庫化ファイルの再転送処理と並行して、書庫の内容の展開が書庫化ファイル展開部21によって実施される。
【0092】
展開された書庫には属性ファイルが含まれている。この属性ファイルには、書庫化ファイルのバージョン,書庫化ファイルに含まれていたファイルの名前,サイズ,タイムスタンプなどの情報が書き込まれている。
書庫化ファイル展開部21は、属性ファイルに書き込まれた情報に基づいて、書庫化ファイルに含まれていたファイルが正しいファイルかどうかを検証する。また、展開したコンテンツのタイムスタンプをオリジナルのコンテンツに合わせる。
【0093】
また、属性ファイルには、オリジナルのコンテンツに含まれる全てのファイルの名前,サイズ,タイムスタンプなどの情報も記述されているので、それらの情報に基づいて、書庫化ファイル展開部21は自身が管理しているコンテンツが正しく、オリジナルコンテンツと同一かどうかを検査する。
もしも、欠損したコンテンツや一致しないコンテンツなどがあった場合には、受信装置20の書庫化ファイル送受信部22はオリジナルコンテンツを保持する送信装置10から直接オリジナルコンテンツをダウンロードする。
【0094】
書庫化ファイル展開部21は、その受信装置20が管理しているコンテンツが全て正しくオリジナルコンテンツを把握したものであることを確認すると、属性ファイルに含まれていたバージョン番号を読み出し、ServiceDirectoryRoot/Server/Resources/<コンテンツ名>/配下にあるVersion状態ファイルの内容を更新する。
【0095】
もしも、書庫化ファイルが正常にダウンロードできなかった場合や、ダウンロードした書庫化ファイルに異常があり正常に展開できなかったような場合、すなわち書庫化ファイルの取得に異常が生じた場合には、受信装置20は転送宛先決定部30に対して、ダウンロードした書庫化ファイルと同一のバージョンの書庫化ファイルを保持する別の受信装置20を問い合わせる。
【0096】
この場合、問合せを受けた転送宛先決定部30は、まず問い合わせ元の受信装置20と同一のグループの中で同じバージョンの書庫化ファイルを保持する受信装置20を検索する。存在しなければ、同一コンテンツを保持する全ての受信装置20及び送信装置10の中から、同じバージョンの書庫化ファイルを持つ受信装置20又は送信装置10を検索してその結果を問い合わせ元に返す。
【0097】
もしも、同じバージョンの書庫化ファイルを持つ受信装置20及び送信装置10が存在しなかった場合には、同一グループ内で最も新しいバージョンの書庫化ファイルを保持する受信装置20が紹介される。
異なるバージョンの書庫化ファイルをダウンロードした受信装置20においては、オリジナルコンテンツとの間で欠損するコンテンツが生じる可能性がある。この欠損については、書庫化ファイルに付属しているオリジナルサーバ(送信装置10)のファイルリスト情報に基づいて検出することができる。
【0098】
欠損を検出した場合、受信装置20は足りないファイルについて、最新の書庫化ファイルが「展開終了」状態の受信装置20を転送宛先決定部30に対して問い合わせ、転送宛先決定部30から通知された受信装置20から個別に欠損ファイルをダウンロードする。
このように受信装置20が処理するので、エラー回復時であっても大元の送信装置10に対して負荷がかかるのを抑制するので、配信にかかるコストを低減することができる。
【0099】
すなわち、コンテンツの配信を行う際に、大元の送信装置10だけでなく、コンテンツを受信した受信装置20までもが次々に送信装置10に代わって未配信の他の受信装置20にコンテンツを配信していくことが最大の特徴である。
図1に示す通信システムにおける基本的な動作例について、図6を参照しながら説明する。
【0100】
送信装置10上のコンテンツ記憶部13に保持されているコンテンツに追加や更新が発生すると、送信装置10はステップS71で追加及び更新されたコンテンツを一纏めにした書庫、すなわち書庫化ファイルを作成する。
次に、送信装置10は配信すべきコンテンツの転送先をステップS72で転送宛先決定部30に問い合わせる。図6の例では、転送宛先決定部30はステップS73で1つの受信装置20(R1)を転送先の情報として含む応答を送信装置10に返す。
【0101】
この応答を受信すると、送信装置10は指定された受信装置20(R1)に対してステップS74でコンテンツ更新通知を送信する。
この通知により、受信装置20(R1)は送信装置10上のコンテンツが更新されたことを把握し、ステップS75で応答メッセージを返信し、更に次のステップS76で、コンテンツダウンロードの要求を送信装置10に送信する。
【0102】
この要求に従って、送信装置10は更新されたコンテンツを書庫化ファイルとしてステップS77で受信装置20(R1)に送信する。
受信装置20(R1)は、書庫化ファイルを受信すると、書庫化ファイル展開部21を用いて受信した書庫化ファイルの展開(書庫解凍)を開始する(S80)。また、この動作と並行して受信装置20(R1)から他の受信装置20に対して受信した書庫化ファイルを再転送する。
【0103】
再転送を行う場合の宛先を調べるために、受信装置20(R1)はステップS78で転送宛先決定部30に対して転送先を問い合わせる。図6の例では、この問い合わせに対して、該当するコンテンツを未受信の受信装置20(R2)を検索し、その結果を含む応答をステップS79で受信装置20(R1)に返す。
従って、受信装置20(R1)はステップS82で受信装置20(R2)に対してコンテンツの更新通知を送信する。
【0104】
受信装置20(R2)は、この更新通知を受信すると、ステップS83で応答メッセージを受信装置20(R1)に返し、更に次のステップS84で受信装置20(R1)に対してコンテンツダウンロードの要求を送信する。
この要求に従って、受信装置20(R1)はステップS85で既に受信したコンテンツの書庫化ファイルを受信装置20(R2)に対して再転送する。
【0105】
受信装置20(R1)は、送信装置10から受信した書庫化ファイルの展開が完了すると、ステップS86で送信装置10に対して配信終了通知を送信し、送信装置10はステップS87で応答メッセージを受信装置20(R1)に返す。この後、受信装置20(R1)はステップS88で処理の結果をログファイルに出力する。
【0106】
同様に、受信装置20(R2)は受信装置20(R1)から受信した書庫化ファイルの展開が完了すると、ステップS91で送信装置10に対して配信終了通知を送信し、送信装置10はステップS92で応答メッセージを受信装置20(R2)に返す。この後、受信装置20(R2)はステップS93で処理の結果をログファイルに出力する。
【0107】
図6の例では、受信装置20(R1)が送信装置10から受信した書庫化ファイルを受信装置20(R2)に対して再転送するので、送信装置10は受信装置20(R2)に対して書庫化ファイルを配信する必要がない。従って、送信装置10の負荷を軽減できる。
【0108】
【発明の効果】
本発明によれば、前回配信時より更新のあったファイルや新規に追加されたファイルのみを検索して書庫化ファイルを生成するので、配信するコンテンツの情報量を必要最低限に抑えることができる。
【0109】
また、書庫化ファイル中に属性情報として何回目の配信かを表わす書庫化バージョン、書庫に含まれるファイルの名前、タイムスタンプ、サイズなどの情報を含むことにより、書庫化ファイルを展開する際に、書庫化ファイルの中に正しくファイルが全て含まれているかを確認できる。
【0110】
また、書庫化ファイルの中にオリジナルのコンテンツの全てのファイル情報を含めることにより、受信装置内にあるコンテンツが、全て正しくオリジナルコンテンツを反映しているかどうかを確認できる。
また、本発明では、受信装置群を複数のグループに分け、それぞれのグループから代表受信装置を選び出し、まずそれらの受信装置に書庫化ファイルの配信を行い、次に代表受信装置が属する各グループ内の受信装置に書庫化ファイルの配信を行い、またそれと並行して送信装置も各グループにまんべんなくコンテンツ配信を行うことにより、大量の受信装置へのコンテンツの配信を効率よく高速に行うことができる。
【0111】
また、転送宛先を選択する際に、代表受信装置への配信の終了した送信装置から転送先の問い合わせがあった場合には各グループの最下位の受信装置のうち未配信のものを指定し、グループ内の受信装置から転送先の問い合わせがあった場合にはグループの上位のうち未配信のものから転送先を指定することにより、転送先となる受信装置の検索を効率的に行うことができる。
【0112】
また、本発明では受信装置が書庫化ファイルを受信中もしくは展開中に進捗状況をログファイルに出力することにより、オペレータが受信装置への配信の進捗状況を詳細に把握することが可能になる。
また本発明では、書庫化ファイルの展開終了を送信装置に通知することにより、送信装置では自身が管理する配信データベースで、コンテンツの配信状況を一括管理することができる。
【0113】
以上のような特徴により、本発明では大量のコンテンツを大量の受信装置に配信しようとする場合に、データセンタヘの設備投資を最小限に抑え低コストに、かつ高速かつ効率的に行うことができる。
【図面の簡単な説明】
【図1】通信システムの構成例を示すブロック図である。
【図2】送信装置の動作を示すフローチャートである。
【図3】受信装置の動作を示すフローチャートである。
【図4】転送宛先決定部の動作(1)を示すフローチャートである。
【図5】転送宛先決定部の動作(2)を示すフローチャートである。
【図6】通信システム全体の動作例を示すシーケンス図である。
【図7】送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。
【図8】MirrorControlファイルの構成を示す模式図である。
【図9】CommonConfigファイルの構成を示す模式図である。
【図10】配信制御テーブルの構成例を示す模式図である。
【図11】装置間通信メッセージの構成例を示す模式図である。
【符号の説明】
10 送信装置
11 書庫化ファイル生成部
12 書庫化ファイル送信部
13 コンテンツ記憶部
14 配信制御用DB
20 受信装置
21 書庫化ファイル展開部
22 書庫化ファイル送受信部
23 コンテンツ記憶部
30 転送宛先決定部
35 IPネットワーク
【発明の属する技術分野】
本発明は、様々なコンテンツのデータを不特定多数に配信する場合に利用可能なコンテンツ配信方法及びコンテンツ配信制御装置に関する。
【0002】
【従来の技術】
コンテンツ配信方法や配信時のサーバにかかる負荷を効率的に削減する従来技術として、マルチキャストを用いてファイルを配信する方法(特許文献1)、オリジナルサーバに蓄積するコンテンツのうち人気のあるものだけを配信するシステム(特許文献2)、オリジナルサーバで更新され続けるコンテンツのうち、最新の差分だけを配信する方法(特許文献3)などがある。
【特許文献1】特願2002−024389号
【特許文献2】特開2001−27965号公報
【特許文献3】特開2001−92699号公報
インターネット上のようにアクセスが集中する可能性のある環境で様々なコンテンツの情報を提供しようとする場合には、サーバに対する負荷を分散するために複数のサーバをネットワークに接続し、それぞれのサーバにコンテンツの情報を蓄積しておく場合が多い。
【0003】
このような通信システムにおいては、最初にコンテンツを保持する1つのサーバはオリジナルサーバと呼ばれ、オリジナルサーバからコンテンツの転送を受ける他のサーバはミラーサーバと呼ばれる。
オリジナルサーバから不特定多数のミラーサーバに対してコンテンツを配信する場合の配信方式としては、PUSH型,PULL型,IPマルチキャストプロトコルを用いる方式などが考えられる。
【0004】
PUSH型の場合には、オリジナルサーバからミラーサーバに対してコンテンツを送りつける。PULL型の場合には、ミラーサーバが定期的にオリジナルサーバに問い合わせを行い、更新されたコンテンツをミラーサーバがオリジナルサーバからダウンロードする。IPマルチキャストプロトコルを用いる場合には、オリジナルサーバから全てのミラーサーバに対して一斉にコンテンツを配信する。
【0005】
また、PUSH型は更に一定間隔方式,スケジュール方式,オンデマンド方式などに区分することができる。
一定間隔方式の場合には、コンテンツを送信する契機として、1分おき、1時間おきなどの一定時間間隔を用いる。スケジュール方式の場合には、例えば毎朝6時など予めスケジュールで定めた時刻に配布を開始する。オンデマンド方式の場合には、コンテンツ提供者が送りたいときに配布を開始する。
【0006】
また、配信宛先が大量になる場合には、同時に配信する宛先数を制限して配信セッションを分けたり、分けることができない場合にはオリジナルサーバの数を宛先数に応じて増やしたりして対処するのが一般的である。
配信セッションを分ける方法では、オリジナルサーバを増やすことなく多数の宛先に配信することが可能であり、低コストであるという長所があるが、宛先数が増えるに従って配信所要時間が長くなるという問題もある。
【0007】
このため、一定間隔方式やスケジュール方式を採用している場合には、オリジナルサーバにおいて、最初に起動された配信処理中に、次に起動された配信処理が重ならないように配信処理間隔を定める必要がある。また、オリジナルサーバが故障すると全ての配信処理が停止するので、オリジナルサーバのクラスター化のような信頼性向上施策が不可欠である。
【0008】
PULL型についても、PUSH型と同様に一定間隔方式,スケジュール方式,オンデマンド方式などの配信契機を持たせることができる。
PULL型の場合には、オリジナルサーバにおけるファイルリストとミラーサーバにおけるファイルリストとを比較して、足りないファイルをダウンロードすることができるので、ミラーサーバにおいて欠損ファイルが生じたり、何らかの理由で更新間隔が長くなってしまった場合には、容易にミラーサーバのコンテンツの内容をオリジナルサーバと同一の内容までキャッチアップすることができる。
【0009】
しかしながら、PULL型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかや、オリジナルサーバからミラーサーバへのファイルの転送がいつ終了するかが分からないので、配信宛先数が増えた場合に負荷を分散するのが困難になる。
【0010】
すなわち、PULL型の場合にはミラーサーバがオリジナルサーバにいつアクセスするかをオリジナルサーバ上で把握できないので、PUSH型の場合のようにオリジナルサーバからの同時配信処理数を制限するようにサーバ毎の配信処理時間を定めることができない。
従って、大量のミラーサーバからのアクセス負荷を分散するために、オリジナルサーバを複数台用意しておき、ミラーサーバ群はいくつかの台数毎にグループに分け、グループ毎に異なるオリジナルサーバを割り当てるような構成をとる必要がある。
【0011】
また、ミラーサーバをグループ分けしない場合にはオリジナルサーバとミラーサーバ群との間に負荷分散装置を配置し、ミラーサーバ群からのアクセスを負荷分散装置で振り分ける処理を行う必要がある。
また、PUSH型、PULL型のいずれの場合についても、データセンタを構成する場合には高信頼なオリジナルサーバを設置し、大容量配信のためにネットワーク帯域を増強する必要がある。
【0012】
ミラーサーバが増えた場合の負荷の集中を防止するのに最も適した方法は、IPマルチキャストを用いてファイルを配信することである。
IPマルチキャストを用いると、最も理想的な場合には一度の配信処理だけで、全てのミラーサーバヘのファイル配信を完了することができる。しかし、実際のインターネットではIPパケットの消失の無い理想的な配信は困難なのでIPパケットの再送によるエラー回復が必要になる。
【0013】
エラー回復の技術については、連送配信と逐次回復の2つに分けることができる。連送配信の場合には、最初から同じデータを複数回重複させて配信する。逐次回復の場合には、受信に失敗したミラーサーバに対して回復データをTCPコネクションで受け渡す。
しかし、受信側のミラーサーバの数が増大すると、連送配信の場合には確率的には連送回数を増やす必要があるし、逐次回復の場合には確率的にエラーを起こす受信側が増えるので、エラー回復のためのオリジナルサーバの負荷が増大するのは避けられない。
【0014】
一方、IPマルチキャストプロトコルは、公共のネットワークであるインターネット上では実質的に伝搬不可能であるし、イントラネット内であっても、ネットワーク機器やサイトポリシーの都合により伝搬不可能な場合が多い。
そのため、IPマルチキャストプロトコルを用いたファイル配信は実際には採用できない場合がほとんどである。
【0015】
【発明が解決しようとする課題】
大量のファイルを大量のミラーサーバに配信するような場合には、前述のPUSH型配信、PULL型配信のいずれであっても、受信先のミラーサーバの数の増大に伴って、オリジナルサーバ側のサーバ端末やネットワークの負荷が増大することは避けられない。
【0016】
このような負荷を分散する手法としては、オリジナルサーバからミラーサーバヘの配信時間をずらし、時間軸に沿って負荷を分散する方式や、オリジナルサーバの台数を増強するとともにネットワークの帯域幅も増やし、設備増強により負荷を分散する方式とがある。
しかし、前者の負荷分散方式では、ファイルサイズが大きくなったり、宛先ミラーサーバの数が著しく増大した場合には、許容された時間内で配信が終了できない可能性がある。
【0017】
また、後者の負荷分散方式では、設備を導入するコストや設備を管理及び運営するコストなどがかさんでしまい、ファイルを分散させるメリットが薄れてしまう。
このように、オリジナルサーバにかかる負荷が大きく、またその負荷を分散させることが難しい一方で、ミラーサーバ側はオリジナルサーバからのファイルを受信する以外の負荷はほとんどかかっておらず、サーバ能力及びネットワーク帯域幅には共に余力がある。
【0018】
なお、このような状況はオリジナルサーバと多数のミラーサーバとで構成される特定の通信システムに限ったことではなく、サーバと多数のクライアント端末とで構成される一般的な通信システムにおいても想定される問題である。
本発明は、情報を提供するサーバにかかる負荷を効率的に分散するとともに、新たな設備を導入するコストや設備を管理及び運営するコストなどの増大を抑制することを目的とする。
【0019】
【課題を解決するための手段】
請求項1は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信方法において、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手順と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手順と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手順と、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手順と、生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手順と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手順と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手順と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手順とを設けたことを特徴とする。
【0020】
請求項1においては、送信装置から受信装置に配信すべき情報は、コンテンツ書庫化手順によって最小化される。すなわち、前回の配信時と比べて新たに追加登録されたコンテンツ及び内容の更新されたコンテンツの全てが一纏めにされ、圧縮されて書庫として管理される。従って、配信するファイルのサイズが低減される。
【0021】
送信装置は配下の全ての受信装置に対してコンテンツを配信する必要はない。すなわち、転送宛先決定手順で決定された特定の転送先の受信装置に対して書庫の情報が書庫転送手順で転送される。
各受信装置が送信装置から書庫の情報を受け取った場合には、第1のイベント情報が生成され、これが送信装置に通知されるので、送信装置は各受信装置に対するコンテンツの配信状況を把握することができる。このようなコンテンツの配信状況は、配信履歴として所定のデータベースに記録される。
【0022】
コンテンツの配信状況を参照することにより、書庫の情報を取得済みの受信装置と未配信の受信装置とを区別することができる。
請求項1においては、書庫の情報を取得した受信装置は未配信の他の受信装置の有無を識別し、未配信の他の受信装置に対して送信装置の代わりに受信情報を再配信する。
【0023】
このように、書庫の情報を取得した受信装置が他の受信装置に対して受信情報を再配信するので、送信装置(例えば前述のオリジナルサーバ)は一部分の受信装置(例えば前述のミラーサーバ)だけにコンテンツを配信すればよく、配信先の増大に伴う送信装置側の負荷の増大を受信装置が肩代わりすることになる。従って、配信にかかるコストの低減,時間の短縮,信頼性の向上などが実現する。
【0024】
請求項2は、請求項1のコンテンツ配信方法において、前記コンテンツ書庫化手順では、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
【0025】
請求項2においては、属性情報を参照することにより、様々な状況の把握が可能になる。すなわち、書庫化日時及びバージョンの情報を参照することにより、該当するファイルが受信装置の既に受け取った書庫化ファイルと同じか否か、あるいは該当するファイルが受信装置の既に受信して展開したファイルよりも古いか否かを検査することができる。
【0026】
例えば、受信した書庫化ファイルと同一バージョンのファイル、もしくは受信した書庫化ファイルよりも新しいバージョンのファイルを展開し終えている場合には、受信した書庫化ファイルを展開しないように制御することができる。
なお、書庫に含まれる元のファイルの情報としては、ファイル名,タイムスタンプ,サイズなどが考えられる。これらの情報は、書庫化ファイルを展開した後で、展開したファイルの情報を属性情報に合わせて書き換えるために用いることができる。また、オリジナルコンテンツの全ファイルのファイル名,タイムスタンプ,サイズなどの情報を書庫に含めてもよい。
【0027】
例えば、送信装置にあるファイルと受信装置にあるファイルのタイムスタンプが両者で一致するように処理することにより、受信装置は自分の保持するファイルが、送信装置にあるファイルと同一かどうかを容易に検査できる。
請求項3は、請求項1のコンテンツ配信方法において、前記転送宛先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【0028】
請求項3においては、複数の受信装置を複数のグループに区分して管理するので、グループ毎に転送先の受信装置を決定することができる。このため、全てのグループに均等に転送が配分されるように負荷を分散することも容易である。
また、最初は各グループの最上位の受信装置だけを選択するが、最上位の受信装置が故障などの原因で応答しない場合には、次順位の受信装置を選択する。次順位の受信装置が故障している場合には、更にその次の受信装置というように、降順で受信装置を選択する。
【0029】
また、一通りのグループに配信が行き渡り、更に各グループ内においてはまだ未配信の受信装置がある場合には、今度は各グループの最下位から昇順で配信先の受信装置を選択する。
請求項4は、請求項1のコンテンツ配信方法において、前記再転送先決定手順では、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択することを特徴とする。
【0030】
請求項4においては、既に書庫の情報を受信した第1の受信装置と同一のグループに属する他の受信装置の中から、再転送先となる第2の受信装置が選択されるので、受信装置同士の間で実施される情報の再転送は同一グループ内に限定される。このため、第2の受信装置の選択が容易になる。また、ネットワーク上の通信経路が複雑化するのを避けることもできる。
【0031】
請求項5は、請求項1のコンテンツ配信方法において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手順と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手順とをさらに設けたことを特徴とする。
【0032】
請求項5においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を受信中か否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルの配信要求があっても、その要求を受け付けないように制御できる。
なお、ログファイルに出力される進捗情報としては、受信中書庫化ファイルの名称,書庫化ファイル全体のサイズ,現在までに受信が終了したファイル量などが考えられる。
【0033】
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
請求項6は、請求項5のコンテンツ配信方法において、前記書庫情報展開手順では、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【0034】
請求項6においては、ロックファイルの有無を調べることにより、各受信装置が書庫の情報を展開処理中であるか否かを識別できる。従って、例えばロックファイルが存在する場合には、たとえ同一コンテンツの書庫化ファイルが複数存在する場合であっても、他の書庫化ファイルの展開処理を開始しないように制御できる。
【0035】
ログファイルに出力される進捗情報については、書庫化ファイルに含まれる全ファイル数や現在までに展開が終了したファイル数などが考えられる。
出力されるログ情報については、例えばオペレーターから受信装置に閲覧要求が届いた場合にオペレーターに通知すればよい。従って、オペレータは配信状況をログ情報により確認できる。
【0036】
なお、受信装置において書庫化ファイルの展開が終了すると、書庫化ファイル展開終了のイベントデータを作成し、それを送信装置にを通知する。通知されたイベントデータは送信装置のデータベースに記録され、転送宛先を決定する際に参照される。
請求項7は、請求項1のコンテンツ配信方法において、前記書庫情報展開手順では、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【0037】
請求項7においては、受信した書庫内に含まれているファイルの展開に失敗した場合であっても、受信装置における自律的な制御により該当するファイルを他の受信装置からダウンロードしてエラーを回避することができる。
該当するファイルと同じ情報を既に保持している他の受信装置を検索する場合には、最初は同一バージョンのファイルを保持している受信装置を検索する。該当する受信装置が存在しない場合には、同じコンテンツ名の、最も新しいバージョンの書庫化ファイルを保持し、かつネットワーク上で最も近い受信装置を検索する。
【0038】
なお、エラーの発生したバージョンとは異なる最新バージョンの書庫化ファイルを受信装置が受け取った場合には、バージョンの相違によりコンテンツ内容の不備が生じる可能性がある。
オリジナルコンテンツのファイルリストが書庫化ファイルに付加されている場合には、その内容からコンテンツ内容の不備を検出することが可能である。不足するファイルが存在する場合には、そのファイルを個別に前記最新の書庫化ファイルを保持する受信装置からダウンロードすればよい。
【0039】
請求項8のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手段と、前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手段と、前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手段と、各々の受信装置について、書庫の情報を受け取ったか否かを表す情報を管理し、その結果を前記転送宛先決定手段の制御に反映する受信状況管理手段とを設けたことを特徴とする。
【0040】
請求項8においては、請求項1の方法と同様に、送信装置は全ての受信装置に対してコンテンツを配信する必要がないので、送信装置にかかる負荷を分散することができる。
請求項9のコンテンツ配信制御装置は、送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、前記送信装置が、新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するとともに、前記書庫で管理されている情報を特定の受信装置に配信する場合に、各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手段と、生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手段と、各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手段と、書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手段と、各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手段とを設けたことを特徴とする。
【0041】
請求項9においては、請求項1の方法と同様に、各受信装置が書庫の情報を受け取ったか否かを把握することができるので、送信装置から情報を受け取った受信装置は他の受信装置に対して情報を再転送することができる。
受信装置同士の間で情報の再転送が実施されるので、送信装置がコンテンツを配信すべき受信装置の数を減らすことができ、送信装置にかかる負荷を分散することができる。
【0042】
請求項10は、請求項8のコンテンツ配信制御装置において、前記コンテンツ書庫化手段は、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とする。
請求項10においては、請求項2の方法と同様の結果が得られる。
【0043】
請求項11は、請求項8のコンテンツ配信制御装置において、前記転送宛先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択することを特徴とする。
【0044】
請求項11においては、請求項3の方法と同様の結果が得られる。
請求項12は、請求項9のコンテンツ配信制御装置において、前記再転送先決定手段は、複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択することを特徴とする。
【0045】
請求項12においては、請求項4の方法と同様の結果が得られる。
請求項13は、請求項9のコンテンツ配信制御装置において、各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手段と、各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手段とをさらに設けたことを特徴とする。
【0046】
請求項13においては、請求項5の方法と同様の結果が得られる。
請求項14は、請求項13のコンテンツ配信制御装置において、前記書庫情報展開手段は、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とする。
【0047】
請求項14においては、請求項6の方法と同様の結果が得られる。
請求項15は、請求項9のコンテンツ配信制御装置において、前記書庫情報展開手段は、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とする。
【0048】
請求項15においては、請求項7の方法と同様の結果が得られる。
【0049】
【発明の実施の形態】
本発明のコンテンツ配信方法及びコンテンツ配信制御装置の1つの実施の形態について、図1〜図11を参照して説明する。この形態は全ての請求項に対応する。
【0050】
図1は通信システムの構成例を示すブロック図である。図2は送信装置の動作を示すフローチャートである。図3は受信装置の動作を示すフローチャートである。図4は転送宛先決定部の動作(1)を示すフローチャートである。図5は転送宛先決定部の動作(2)を示すフローチャートである。
図6は通信システム全体の動作例を示すシーケンス図である。図7は送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。図8はMirrorControlファイルの構成を示す模式図である。図9はCommonConfigファイルの構成を示す模式図である。図10は配信制御テーブルの構成例を示す模式図である。図11は装置間通信メッセージの構成例を示す模式図である。
【0051】
この形態では、請求項8の送信装置,受信装置,コンテンツ書庫化手段,転送宛先決定手段,書庫転送手段及び受信状況管理手段は、それぞれ送信装置10,受信装置20,書庫化ファイル生成部11,転送宛先決定部30,書庫化ファイル送信部12及び配信制御用DB(データベース)14に対応する。
また、請求項9の第1のイベント情報生成手段,第1のイベント情報通知手段,書庫情報展開手段,再転送先決定手段,書庫再転送手段及び第2のイベント情報通知手段は、それぞれステップS86,書庫化ファイル送受信部22,書庫化ファイル展開部21,転送宛先決定部30,書庫化ファイル送受信部22及びステップS91に対応する。
【0052】
また、請求項13のロックファイル作成手段及び受信ログ生成手段は書庫化ファイル送受信部22に対応する。
この形態では、図1に示すような構成の通信システムを用いて、送信装置10から複数の受信装置20に対してコンテンツを配信する場合を想定している。例えば、オリジナルサーバとミラーサーバとの間でコンテンツの転送を行う場合には、送信装置10がオリジナルサーバに相当し、受信装置20がミラーサーバに相当する。また、サーバとクライアント端末との間でコンテンツの転送を行う場合には、送信装置10がサーバに相当し、受信装置20がクライアント端末に相当する。
【0053】
図1に示す通信システムにおいては、送信装置10,転送宛先決定部30及び複数の受信装置20がIPネットワーク35を介して互いに接続されている。なお、転送宛先決定部30については送信装置10と一体に構成することもできるし、いずれかの受信装置20に配置することもできる。
送信装置10は、書庫化ファイル生成部11,書庫化ファイル送信部12,コンテンツ記憶部13及び配信制御用DB14を備えている。
【0054】
コンテンツ記憶部13には配信すべきコンテンツの情報が保持され、その情報はコンテンツ提供者からの要求などに応じて追加及び更新される。配信制御用DB14には、配信制御に必要な様々な情報が保持される。配信制御用DB14上の情報は必要に応じて更新される。
コンテンツ記憶部13については、実際には送信装置10の本体にSCSIインタフェースやATAインタフェースで直接接続してもよいし、外部装置である記憶装置サーバ(NAS:Network Attached Strage)をNFSで送信装置10に接続してもよい。
【0055】
送信装置10から受信装置20へのコンテンツ配信を開始する条件(図2に示す動作を開始する条件)は、前回配信時のコンテンツと比べて新しいファイルがコンテンツ記憶部13に追加された場合、又はファイルのタイムスタンプやファイルサイズが更新されたことを発見した場合である。
この検査は、送信装置10上のコンテンツ記憶部13を走査することによって行われる。
【0056】
コンテンツ記憶部13を走査する契機については、送信装置10上にコンテンツ毎に用意されているMirrorControlファイルと呼ばれる定義ファイルの内容に応じて、Event型,Scheduled型,OnDemand型のいずれかに切り替えることができる。
【0057】
Event型の場合には、例えば1分おき、1時間おきなどの一定時間周期で走査を行う。Scheduled型の場合には、例えば毎日午前8時、毎週月曜〜金曜の午前8時などのように特定の時間に走査を行う。OnDemand型の場合には、コンテンツを追加した任意の時間にコンテンツの配信を行う。
書庫化ファイル生成部11は、コンテンツ記憶部13上に新たなコンテンツが追加された場合や、既に登録されているコンテンツのバージョンが更新された場合に、追加又は更新された全てのコンテンツのファイルを一纏めにして書庫として管理する。書庫内に格納される各々のファイルは、圧縮された状態で保持される。また、書庫にはそれに格納されているファイルを管理するための情報が含まれている。
【0058】
書庫化ファイル送信部12は、書庫化ファイル生成部11が生成した書庫の内容、すなわち前回配信時の内容とは異なる追加又は変更されたコンテンツの情報を受信装置20に対して送信する。この場合の宛先は、転送宛先決定部30が決定する。
転送宛先決定部30は、送信装置10又はいずれかの受信装置20から問い合わせを受けた場合に、送信装置10上の配信制御用DB14で管理されている情報に基づいて特定の受信装置20を宛先として決定する。
【0059】
各受信装置20に備わった書庫化ファイル送受信部22は、送信装置10又は他の受信装置20から送信されるコンテンツの情報を受信するとともに、受信した情報を他の未受信の受信装置20に対して再転送する。
また、受信したコンテンツの情報は書庫として纏められ圧縮されているので、その情報を書庫化ファイル展開部21が展開する。展開した受信情報はコンテンツ記憶部23に蓄積される。
【0060】
ところで、コンテンツ記憶部13及び23上の記憶領域は、図7に示すような階層構造により、領域毎にディレクトリとして区分されて管理されている。また、この形態ではディレクトリ毎にコンテンツの配信を制御することができる。そのため、MirrorControlファイルはディレクトリ毎にそれぞれ用意される。
図7に示す階層構造においては、ServiceDirectoryRootで示されたディレクトリが最上位の階層の記憶領域を表している。このディレクトリの下の階層にはServerのディレクトリが作成され、更にその下の階層に、Contentsディレクトリと、Resourcesディレクトリと、Systemディレクトリとが配置されている。
【0061】
また、TreeManagerの下の階層にはResourcesディレクトリだけが配置されている。
この例では、Serverのディレクトリの下の階層に配置されるファイルは、主に送信装置10自身が参照し、TreeManagerディレクトリ以下の階層に配置されるファイルは、主に転送宛先決定部30によって参照される。
【0062】
また、Serverのディレクトリの下の階層のContentsディレクトリの下には、コンテンツ配信単位で独立したディレクトリが配置され、それらのディレクトリの配下に、コンテンツ提供者から送信される実際のコンテンツが配置される。
Contentsディレクトリ配下のディレクトリをここではコンテンツ名と呼ぶ。このコンテンツ名に対応したディレクトリが、ServiceDirectoryRoot/Server/Resourcesの配下にも作られる。これらのディレクトリには、コンテンツ毎の定義ファイルが配置される。
【0063】
このコンテンツ名毎のディレクトリの各々を、ここではリソースディレクトリと呼ぶ。MirrorControlファイルは、リソースディレクトリに配置される。
各々のMirrorControlファイルには、図8に示すような様々なパラメータが含まれている。図8に示すように、インターバルを決定するパラメータVersionCheckInterval,EventDrivenPushInterval,ScheduledPushIntervalは、MirrorControlファイルの中で独立に指定することができる。すなわち、コンテンツのバージョンの走査周期と配信の周期とは独立に定めることができる。
【0064】
また、EventDrivenPushIntervalによって制御されるイベントドリブン型プッシュ制御とScheduledPushIntervalによって制御されるスケジュール型プッシュ制御とは同時に動作させることができる。
例えば、イベントドリブン型プッシュ制御により配信処理が行われた後でスケジュール型プッシュ制御により配信処理が行われる場合を想定すると、イベントドリブン型プッシュ制御とスケジュール型プッシュ制御との間でバージョンチェックが実施されるが、この時に新規コンテンツが検出されない場合には、コンテンツの書庫化及びファイルの配信は行われない。
【0065】
オンデマンド型の配信制御を行う場合には、任意のタイミングでバージョンチェック及びコンテンツの配信処理を起動することができる。
書庫化ファイルの作成は、バージョンチェックが行われた後で、イベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動するか、もしくはオンデマンド配信コマンドが呼ばれることによって実施される。
【0066】
書庫化ファイルの作成時には、ロックファイルDarLockが作成される。このロックファイルDarLockの有無は、制御の中で参照される。例えば、書庫化ファイルの作成に時間がかかり、作成が終了する前に次の書庫化ファイル作成タイミングが到来したような場合には、ロックファイルDarLockが存在するので、次のプロセスの起動を中止する。
【0067】
これにより、書庫化ファイルの作成プロセスが2重に起動するのを防止できるので、先に起動された書庫化プロセスと、後から起動された書庫化プロセスの両方に格納されるファイルが出てきたり、そのどちらにも格納されないファイルが出てくるのを避けることができる。
書庫化ファイルの作成が無事終了した場合には、ロックファイルDarLockは削除される。この後で、次のイベントドリブン型プッシュ制御又はスケジュール型プッシュ制御が起動されると、書庫化ファイルの作成が可能になる。
【0068】
書庫化ファイルの作成が終了すると、次は配信宛先となる受信装置20に対して配信通知を行う。
ところで、ServiceDirectoryRoot/Server/Systemの配下には定義ファイルCommonConfigが存在する。書庫化ファイルの配信は、送信装置10の性能的な許容負荷を超えない範囲で行う必要がある。そのために、定義ファイルCommonConfigの中には、図9に示すようにパラメータMaxPararelTransferを設けてある。
【0069】
この例では、ServiceDirectoryRoot/Server/Resourcesの配下とServiceDirectoryRoot/Server/Systemの配下とにそれぞれ定義ファイルが配置される。Resourcesの配下に配置される定義ファイルはコンテンツ毎に独立しており、Systemの配下の定義ファイルはシステム全体で共通のパラメータとして利用される。
送信装置10の配信能力は、コンテンツ毎に決定されるものではなく、送信装置10全体で決定される。そのため、Systemの配下に配置される定義ファイルCommonConfigの中で、最大並行配信数(MaxPararelTransfer)のパラメータを定義してある。
【0070】
送信装置10の書庫化ファイル送信部12は、転送宛先決定部30を用いて配信先の受信装置20を決定する。この場合、書庫化ファイル送信部12はそれ自身の定義ファイルCommonConfigにおけるパラメータ(MaxPararelTransfer)と、現在コンテンツを送信中の受信装置20の数を配信制御用DB14の内容に基づいて計算し、これからコンテンツの送信を行う受信装置20の数が(MaxPararelTransfer)を超えない数の分だけ、転送宛先決定部30に対して転送先の受信装置名を要求(問い合わせ)する。
【0071】
転送宛先決定部30は、送信装置10から問い合わせを受けると、送信装置10上の配信制御用DB14の内容を参照して、転送先の受信装置20を決定する。
配信制御用DB14には、図10に示すような構成の配信制御テーブルが保持されている。この配信制御テーブルは、コンテンツ毎にそれぞれ用意されている。各配信制御テーブルには、それぞれの受信装置20について、受信装置名,コンテンツバージョン,配信開始日時,配信終了日時及び装置状態の情報が記録されている。
【0072】
また、送信装置10から転送宛先決定部30への問い合わせのメッセージは、図11に示すように送信装置名と、コンテンツ名と、コンテンツバージョンの情報とを含んでいる。また、この問い合わせに対する転送宛先決定部30から送信装置10への返信メッセージには、受信装置名とそのURL又はIPアドレスとが含まれている。
【0073】
ところで、転送宛先決定部30は、配信制御用DB14に記述されている多数の受信装置20を複数グループに区分し、目印を付けて管理している。各々のグループにはn個の受信装置20が割り当てられる。nの値については、オペレータが任意に決定すればよい。また、各グループ内のn個の受信装置20は、例えば並び順などによりグループ内の順位を付けて管理されている。
【0074】
そして、転送宛先決定部30は送信装置10からの転送宛先の問い合わせが届くと、まず、各々のグループにおける1番目の順位の受信装置20を代表受信装置として選択し、その情報を順番に送信装置10に返す。
もしも1番目の順位の受信装置20の状態が異常である場合には、2番目の順位の受信装置20を代表受信装置として選択する。
【0075】
また、各グループの代表受信装置が全て配信済みになった場合には、転送宛先決定部30は各グループの最下位の順位の受信装置20を配信宛先として選択する。
このように、選択する順番を順位の降順と昇順とで切り替えるのは、配信の重複が生じるのをなるべく避けるためである。すなわち、転送宛先決定部30に対する問い合わせ及びコンテンツの転送をするのは送信装置10だけでなく、複数の受信装置20も問い合わせをするので、問い合わせに対する回答の内容及びタイミングによっては同じ受信装置20に対して重複してコンテンツの配信が行われる可能性がある。
【0076】
転送宛先決定部30が転送宛先の受信装置20を選択する順番を順位の降順と昇順とで切り替えることにより、コンテンツの重複配信が生じる可能性を減らすことができる。
転送宛先決定部30が送信装置10から転送宛先の問い合わせを受けた場合の転送宛先決定部30における動作は以上に説明した通りであり、動作手順の概略を図で示すと図4のようになる。
【0077】
コンテンツの配信を実行する場合、送信装置10の書庫化ファイル送信部12は転送宛先決定部30に対して問い合わせを行い、書庫化ファイル送信部12は転送宛先決定部30からの応答として転送宛先の受信装置名を取得する(図2のS39)。
この後、書庫化ファイル送信部12は、コンテンツを送信するが、その前に転送宛先決定部30で決定された特定の受信装置20に対して、コンテンツの更新通知を送信する(図2のS41)。
【0078】
このコンテンツの更新通知には、図11に示すように受信装置20が取得すべき書庫化ファイル名とコンテンツのバージョンとが含まれている。
受信装置20は、送信装置10又は他の受信装置20からのコンテンツ更新通知を受信すると、図3に示すような処理を実行し、送信装置10からのコンテンツの受信及び他の受信装置20へのコンテンツの再転送を行う。
【0079】
但し、コンテンツの更新通知を受けた受信装置20が既に該当するバージョンのコンテンツをダウンロードしている最中であるか、もしくは既に取得済みである場合には、コンテンツの更新通知に対する処理をキャンセルする。その場合、受信装置20は送信装置10に対して、当該コンテンツをダウンロードしている最中か、取得済みであるかのどちらかの情報を通知する(図3のS65)。
【0080】
この通知を受信すると、送信装置10はそれ自身が保持している配信制御用DB14上の配信制御テーブルの内容を、受信装置20からのメッセージに従って書き換える。
受信装置20は、更新通知として送信装置10から通知されたコンテンツをまだ取得していなければ、該当するコンテンツの書庫化ファイルを、通知を発した送信装置10もしくは他の受信装置20からダウンロードする(図3のS52)。
【0081】
書庫化ファイルのダウンロードが始まると、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を「送信装置より受信中」に書き換える。
また、書庫化ファイルのダウンロードが終了すると、受信装置20はダウンロードを結果を送信装置10に通知する。この場合も、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を通知に従って書き換える。
【0082】
但し、通知の内容が「異常終了」であった場合には、再び送信装置10から受信装置20にコンテンツの更新通知が送信され、書庫化ファイルのダウンロードがやり直される。
通知の内容が「正常終了」であった場合には、送信装置10は配信制御用DB14上の配信制御テーブルにおける該当する受信装置20の状態を「正常終了」に書き換える。そして、次の転送宛先となる受信装置20を転送宛先決定部30に問い合わせる。
【0083】
一方、書庫化ファイルを受信した受信装置20においては、受信した書庫の内容を書庫化ファイル展開部21が展開するのと並行して、他の受信装置20に対する書庫化ファイルの再転送のための処理を開始する。すなわち、コンテンツの受信を完了した受信装置20は送信装置10の代わりに、未受信の受信装置20に対するコンテンツの転送を行う。
【0084】
この場合、書庫化ファイルを既に受信した受信装置20は、転送宛先決定部30に対して書庫化ファイルを再転送すべき宛先の他の受信装置20の名称を問い合わせる(図3のS53)。
受信装置20から転送先の問い合わせを受けると、転送宛先決定部30は図5に示すような動作を行う。
【0085】
すなわち、転送宛先決定部30は配信制御用DB14上の配信制御テーブルを参照し、問い合わせ元の受信装置20が属するグループ内の受信状況を検査し(S21)、未配信の受信装置20を該当するグループの上位から順に転送先として選択する(S23)。
未配信の受信装置20が存在しない場合には、転送宛先決定部30は無し(NULL)を問い合わせ元の受信装置20に応答する(S26)。
【0086】
受信装置20は、問い合わせの結果として転送宛先決定部30から無し(NULL)を受信した場合には、配信処理を終了する。
なお、転送宛先決定部30は問い合わせを受けた場合に、未配信でかつ、可能であればネットワーク的に近い距離にある受信装置20を計算して転送先として選択するのが望ましい。
【0087】
また、転送宛先決定部30は、求めるバージョンのコンテンツが未配信の受信装置20を配信制御用DB14から検索した結果、該当する受信装置20が見つかった場合には、その受信装置20の名前(IPアドレス又はURL)を転送先として返す。
一方、書庫化ファイルを受信した受信装置20においては、書庫の展開が無事に終了すると、「展開終了」のステータス情報を送信装置10に対して通知する(図3のS64)。
【0088】
この通知を受けた送信装置10は、通知に従って配信制御用DB14の状態を書き換える。一方、受信装置20から他の受信装置20の名前が返ってきた場合には、返ってきた名前の受信装置20に対して送信装置10はコンテンツの更新通知を送信する。
なお、受信装置20が他の受信装置20に対して書庫化ファイルを送信する場合にも、最大並行配信数については送信装置10の場合と同様に、ServiceDirectoryRoot/Server/System/CommonConfigに記述されているパラメータMaxPararelTransferの値に従う。
【0089】
すなわち、受信装置20はパラメータMaxPararelTransferの値によって許される数だけ、転送宛先決定部30に対して再転送先となる未配信の受信装置20を問い合わせ、その結果として転送宛先決定部30から通知された未配信の受信装置20に対してコンテンツの更新通知を送信する(S55)。
一方、受信装置20は他の受信装置20からコンテンツの更新通知を受け取ると、更新通知を送信した受信装置20から該当する書庫化ファイルをダウンロードする(S52)。
【0090】
但し、他の書庫化ファイルを受信している途中であったり、受信した書庫化ファイルを展開している途中であると、送信装置10に拒否が通知される(S65)。これらの条件に適合するときには、ロックファイルが作成されているので、図3のステップS51ではロックファイルの有無を調べる。
他の受信装置20からの書庫化ファイルのダウンロードが正常に終了した場合には、受信装置20は「正常終了」のメッセージを送信側の受信装置20及び送信装置10に対して通知する。
【0091】
受信装置20からの通知を受けると、送信装置10は配信制御用DB14の状態を書き換える。
受信装置20においては、他の受信装置20に対する書庫化ファイルの再転送処理と並行して、書庫の内容の展開が書庫化ファイル展開部21によって実施される。
【0092】
展開された書庫には属性ファイルが含まれている。この属性ファイルには、書庫化ファイルのバージョン,書庫化ファイルに含まれていたファイルの名前,サイズ,タイムスタンプなどの情報が書き込まれている。
書庫化ファイル展開部21は、属性ファイルに書き込まれた情報に基づいて、書庫化ファイルに含まれていたファイルが正しいファイルかどうかを検証する。また、展開したコンテンツのタイムスタンプをオリジナルのコンテンツに合わせる。
【0093】
また、属性ファイルには、オリジナルのコンテンツに含まれる全てのファイルの名前,サイズ,タイムスタンプなどの情報も記述されているので、それらの情報に基づいて、書庫化ファイル展開部21は自身が管理しているコンテンツが正しく、オリジナルコンテンツと同一かどうかを検査する。
もしも、欠損したコンテンツや一致しないコンテンツなどがあった場合には、受信装置20の書庫化ファイル送受信部22はオリジナルコンテンツを保持する送信装置10から直接オリジナルコンテンツをダウンロードする。
【0094】
書庫化ファイル展開部21は、その受信装置20が管理しているコンテンツが全て正しくオリジナルコンテンツを把握したものであることを確認すると、属性ファイルに含まれていたバージョン番号を読み出し、ServiceDirectoryRoot/Server/Resources/<コンテンツ名>/配下にあるVersion状態ファイルの内容を更新する。
【0095】
もしも、書庫化ファイルが正常にダウンロードできなかった場合や、ダウンロードした書庫化ファイルに異常があり正常に展開できなかったような場合、すなわち書庫化ファイルの取得に異常が生じた場合には、受信装置20は転送宛先決定部30に対して、ダウンロードした書庫化ファイルと同一のバージョンの書庫化ファイルを保持する別の受信装置20を問い合わせる。
【0096】
この場合、問合せを受けた転送宛先決定部30は、まず問い合わせ元の受信装置20と同一のグループの中で同じバージョンの書庫化ファイルを保持する受信装置20を検索する。存在しなければ、同一コンテンツを保持する全ての受信装置20及び送信装置10の中から、同じバージョンの書庫化ファイルを持つ受信装置20又は送信装置10を検索してその結果を問い合わせ元に返す。
【0097】
もしも、同じバージョンの書庫化ファイルを持つ受信装置20及び送信装置10が存在しなかった場合には、同一グループ内で最も新しいバージョンの書庫化ファイルを保持する受信装置20が紹介される。
異なるバージョンの書庫化ファイルをダウンロードした受信装置20においては、オリジナルコンテンツとの間で欠損するコンテンツが生じる可能性がある。この欠損については、書庫化ファイルに付属しているオリジナルサーバ(送信装置10)のファイルリスト情報に基づいて検出することができる。
【0098】
欠損を検出した場合、受信装置20は足りないファイルについて、最新の書庫化ファイルが「展開終了」状態の受信装置20を転送宛先決定部30に対して問い合わせ、転送宛先決定部30から通知された受信装置20から個別に欠損ファイルをダウンロードする。
このように受信装置20が処理するので、エラー回復時であっても大元の送信装置10に対して負荷がかかるのを抑制するので、配信にかかるコストを低減することができる。
【0099】
すなわち、コンテンツの配信を行う際に、大元の送信装置10だけでなく、コンテンツを受信した受信装置20までもが次々に送信装置10に代わって未配信の他の受信装置20にコンテンツを配信していくことが最大の特徴である。
図1に示す通信システムにおける基本的な動作例について、図6を参照しながら説明する。
【0100】
送信装置10上のコンテンツ記憶部13に保持されているコンテンツに追加や更新が発生すると、送信装置10はステップS71で追加及び更新されたコンテンツを一纏めにした書庫、すなわち書庫化ファイルを作成する。
次に、送信装置10は配信すべきコンテンツの転送先をステップS72で転送宛先決定部30に問い合わせる。図6の例では、転送宛先決定部30はステップS73で1つの受信装置20(R1)を転送先の情報として含む応答を送信装置10に返す。
【0101】
この応答を受信すると、送信装置10は指定された受信装置20(R1)に対してステップS74でコンテンツ更新通知を送信する。
この通知により、受信装置20(R1)は送信装置10上のコンテンツが更新されたことを把握し、ステップS75で応答メッセージを返信し、更に次のステップS76で、コンテンツダウンロードの要求を送信装置10に送信する。
【0102】
この要求に従って、送信装置10は更新されたコンテンツを書庫化ファイルとしてステップS77で受信装置20(R1)に送信する。
受信装置20(R1)は、書庫化ファイルを受信すると、書庫化ファイル展開部21を用いて受信した書庫化ファイルの展開(書庫解凍)を開始する(S80)。また、この動作と並行して受信装置20(R1)から他の受信装置20に対して受信した書庫化ファイルを再転送する。
【0103】
再転送を行う場合の宛先を調べるために、受信装置20(R1)はステップS78で転送宛先決定部30に対して転送先を問い合わせる。図6の例では、この問い合わせに対して、該当するコンテンツを未受信の受信装置20(R2)を検索し、その結果を含む応答をステップS79で受信装置20(R1)に返す。
従って、受信装置20(R1)はステップS82で受信装置20(R2)に対してコンテンツの更新通知を送信する。
【0104】
受信装置20(R2)は、この更新通知を受信すると、ステップS83で応答メッセージを受信装置20(R1)に返し、更に次のステップS84で受信装置20(R1)に対してコンテンツダウンロードの要求を送信する。
この要求に従って、受信装置20(R1)はステップS85で既に受信したコンテンツの書庫化ファイルを受信装置20(R2)に対して再転送する。
【0105】
受信装置20(R1)は、送信装置10から受信した書庫化ファイルの展開が完了すると、ステップS86で送信装置10に対して配信終了通知を送信し、送信装置10はステップS87で応答メッセージを受信装置20(R1)に返す。この後、受信装置20(R1)はステップS88で処理の結果をログファイルに出力する。
【0106】
同様に、受信装置20(R2)は受信装置20(R1)から受信した書庫化ファイルの展開が完了すると、ステップS91で送信装置10に対して配信終了通知を送信し、送信装置10はステップS92で応答メッセージを受信装置20(R2)に返す。この後、受信装置20(R2)はステップS93で処理の結果をログファイルに出力する。
【0107】
図6の例では、受信装置20(R1)が送信装置10から受信した書庫化ファイルを受信装置20(R2)に対して再転送するので、送信装置10は受信装置20(R2)に対して書庫化ファイルを配信する必要がない。従って、送信装置10の負荷を軽減できる。
【0108】
【発明の効果】
本発明によれば、前回配信時より更新のあったファイルや新規に追加されたファイルのみを検索して書庫化ファイルを生成するので、配信するコンテンツの情報量を必要最低限に抑えることができる。
【0109】
また、書庫化ファイル中に属性情報として何回目の配信かを表わす書庫化バージョン、書庫に含まれるファイルの名前、タイムスタンプ、サイズなどの情報を含むことにより、書庫化ファイルを展開する際に、書庫化ファイルの中に正しくファイルが全て含まれているかを確認できる。
【0110】
また、書庫化ファイルの中にオリジナルのコンテンツの全てのファイル情報を含めることにより、受信装置内にあるコンテンツが、全て正しくオリジナルコンテンツを反映しているかどうかを確認できる。
また、本発明では、受信装置群を複数のグループに分け、それぞれのグループから代表受信装置を選び出し、まずそれらの受信装置に書庫化ファイルの配信を行い、次に代表受信装置が属する各グループ内の受信装置に書庫化ファイルの配信を行い、またそれと並行して送信装置も各グループにまんべんなくコンテンツ配信を行うことにより、大量の受信装置へのコンテンツの配信を効率よく高速に行うことができる。
【0111】
また、転送宛先を選択する際に、代表受信装置への配信の終了した送信装置から転送先の問い合わせがあった場合には各グループの最下位の受信装置のうち未配信のものを指定し、グループ内の受信装置から転送先の問い合わせがあった場合にはグループの上位のうち未配信のものから転送先を指定することにより、転送先となる受信装置の検索を効率的に行うことができる。
【0112】
また、本発明では受信装置が書庫化ファイルを受信中もしくは展開中に進捗状況をログファイルに出力することにより、オペレータが受信装置への配信の進捗状況を詳細に把握することが可能になる。
また本発明では、書庫化ファイルの展開終了を送信装置に通知することにより、送信装置では自身が管理する配信データベースで、コンテンツの配信状況を一括管理することができる。
【0113】
以上のような特徴により、本発明では大量のコンテンツを大量の受信装置に配信しようとする場合に、データセンタヘの設備投資を最小限に抑え低コストに、かつ高速かつ効率的に行うことができる。
【図面の簡単な説明】
【図1】通信システムの構成例を示すブロック図である。
【図2】送信装置の動作を示すフローチャートである。
【図3】受信装置の動作を示すフローチャートである。
【図4】転送宛先決定部の動作(1)を示すフローチャートである。
【図5】転送宛先決定部の動作(2)を示すフローチャートである。
【図6】通信システム全体の動作例を示すシーケンス図である。
【図7】送信装置及び受信装置のコンテンツ記憶部における記憶領域の階層構造を示す模式図である。
【図8】MirrorControlファイルの構成を示す模式図である。
【図9】CommonConfigファイルの構成を示す模式図である。
【図10】配信制御テーブルの構成例を示す模式図である。
【図11】装置間通信メッセージの構成例を示す模式図である。
【符号の説明】
10 送信装置
11 書庫化ファイル生成部
12 書庫化ファイル送信部
13 コンテンツ記憶部
14 配信制御用DB
20 受信装置
21 書庫化ファイル展開部
22 書庫化ファイル送受信部
23 コンテンツ記憶部
30 転送宛先決定部
35 IPネットワーク
Claims (15)
- 送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信方法において、
前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手順と、
前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手順と、
前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手順と、
各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手順と、
生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手順と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手順と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手順と、
書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手順と、
各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手順と
を設けたことを特徴とするコンテンツ配信方法。 - 請求項1のコンテンツ配信方法において、前記コンテンツ書庫化手順では、
書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理する
ことを特徴とするコンテンツ配信方法。 - 請求項1のコンテンツ配信方法において、前記転送宛先決定手順では、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、
最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択する
ことを特徴とするコンテンツ配信方法。 - 請求項1のコンテンツ配信方法において、前記再転送先決定手順では、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択する
ことを特徴とするコンテンツ配信方法。 - 請求項1のコンテンツ配信方法において、
各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手順と、
各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手順と
をさらに設けたことを特徴とするコンテンツ配信方法。 - 請求項5のコンテンツ配信方法において、前記書庫情報展開手順では、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とするコンテンツ配信方法。
- 請求項1のコンテンツ配信方法において、前記書庫情報展開手順では、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とするコンテンツ配信方法。
- 送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、
前記送信装置上で新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するコンテンツ書庫化手段と、
前記書庫で管理されている情報の転送先の受信装置を決定する転送宛先決定手段と、
前記書庫で管理されている情報を送信装置から決定された特定の受信装置に転送する書庫転送手段と、
各々の受信装置について、書庫の情報を受け取ったか否かを表す情報を管理し、その結果を前記転送宛先決定手段の制御に反映する受信状況管理手段と
を設けたことを特徴とするコンテンツ配信制御装置。 - 送信装置と複数の受信装置とが所定の通信網を介して互いに接続された通信システムを用いて、前記送信装置の保持しているコンテンツの情報を各々の受信装置に配信するためのコンテンツ配信制御装置であって、
前記送信装置が、新規に登録されたコンテンツ及び内容の更新されたコンテンツを一纏めにして圧縮し書庫として管理するとともに、前記書庫で管理されている情報を特定の受信装置に配信する場合に、
各受信装置が前記送信装置の書庫で管理されている情報を受け取った場合に、第1のイベント情報を生成する第1のイベント情報生成手段と、
生成された第1のイベント情報を前記送信装置に通知する第1のイベント情報通知手段と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の内容を展開して管理する書庫情報展開手段と、
各受信装置が前記書庫で管理されている情報を受け取った場合に、受信した書庫の情報の再転送先となる他の受信装置を決定する再転送先決定手段と、
書庫の情報を受信した第1の受信装置から再転送先の第2の受信装置に対して書庫の情報を転送する書庫再転送手段と、
各受信装置が他の受信装置から書庫の情報を受け取った場合に、第2のイベント情報を転送元の受信装置及び送信装置の少なくとも一方に通知する第2のイベント情報通知手段と
を設けたことを特徴とするコンテンツ配信制御装置。 - 請求項8のコンテンツ配信制御装置において、前記コンテンツ書庫化手段は、書庫化日時と、コンテンツの更新回数を表すバージョンと、書庫に含まれる元のファイルの情報とを属性情報として書庫の情報に含めて管理することを特徴とするコンテンツ配信制御装置。
- 請求項8のコンテンツ配信制御装置において、前記転送宛先決定手段は、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
最初はグループ内の最上位の受信装置を転送先として選択し、最上位の受信装置が応答しない場合には降順で次の受信装置を選択し、
最上位の受信装置についてコンテンツが配信済みの場合には、最下位の受信装置から昇順で受信装置を選択する
ことを特徴とするコンテンツ配信制御装置。 - 請求項9のコンテンツ配信制御装置において、前記再転送先決定手段は、
複数の受信装置を複数のグループに区分して管理するとともに、各グループに含まれる複数の受信装置の各々をグループ内の順位を付けて管理し、
第1の受信装置が書庫の情報を受信した場合には、第1の受信装置が属するグループの中で、コンテンツが未配信の受信装置について、順位が上位の受信装置から降順で再転送先の第2の受信装置を選択する
ことを特徴とするコンテンツ配信制御装置。 - 請求項9のコンテンツ配信制御装置において、
各受信装置が前記書庫で管理されている情報を受信している時には、書庫の情報を受信中であることを表すロックファイルを作成するロックファイル作成手段と、
各受信装置が前記書庫で管理されている情報を受信している時には、少なくとも受信中のファイル名称と、受信対象の書庫全体のサイズと、受信の進捗状態を表す進捗情報とを、一定時間おきに受信装置内のログファイルに出力する受信ログ生成手段と
をさらに設けたことを特徴とするコンテンツ配信制御装置。 - 請求項13のコンテンツ配信制御装置において、前記書庫情報展開手段は、各受信装置が受信した書庫の情報を展開処理している時には、展開処理中であることを表すロックファイルを作成するとともに、1ファイルの展開が終了する毎に、展開処理の進捗状態を表す進捗情報を受信装置内のログファイルに出力することを特徴とするコンテンツ配信制御装置。
- 請求項9のコンテンツ配信制御装置において、前記書庫情報展開手段は、受信した書庫内に含まれているファイルの展開に失敗した場合には、該当するファイルと同じ情報を既に保持している他の受信装置の検索を行い、他の受信装置から該当する書庫のファイルをダウンロードすることを特徴とするコンテンツ配信制御装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002261261A JP2004102493A (ja) | 2002-09-06 | 2002-09-06 | コンテンツ配信方法及びコンテンツ配信制御装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002261261A JP2004102493A (ja) | 2002-09-06 | 2002-09-06 | コンテンツ配信方法及びコンテンツ配信制御装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004102493A true JP2004102493A (ja) | 2004-04-02 |
Family
ID=32261688
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002261261A Pending JP2004102493A (ja) | 2002-09-06 | 2002-09-06 | コンテンツ配信方法及びコンテンツ配信制御装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004102493A (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008250773A (ja) * | 2007-03-30 | 2008-10-16 | Brother Ind Ltd | 情報配信システム、管理装置用プログラム及び情報処理装置用プログラム |
JP2010238162A (ja) * | 2009-03-31 | 2010-10-21 | Brother Ind Ltd | コンテンツ配信システム、ノード装置、コンテンツ配信方法及びコンテンツ取得処理プログラム |
JP2011048466A (ja) * | 2009-08-25 | 2011-03-10 | Nippon Television Network Corp | データ配信方法、データ配信システム、配信元端末、及び配信先端末 |
WO2012025971A1 (ja) * | 2010-08-27 | 2012-03-01 | 株式会社日立ソリューションズ | コンテンツ変換装置、コンテンツ変換方法、コンテンツ変換プログラムおよびコンテンツ配信システム |
JP2015026207A (ja) * | 2013-07-25 | 2015-02-05 | 富士通株式会社 | ファイル管理プログラム,ファイル管理装置及びファイル管理方法 |
JP2019056958A (ja) * | 2017-09-19 | 2019-04-11 | ヤフー株式会社 | ファイル管理装置、ファイル管理システム、ファイル管理方法およびファイル管理プログラム |
-
2002
- 2002-09-06 JP JP2002261261A patent/JP2004102493A/ja active Pending
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008250773A (ja) * | 2007-03-30 | 2008-10-16 | Brother Ind Ltd | 情報配信システム、管理装置用プログラム及び情報処理装置用プログラム |
US8336075B2 (en) | 2007-03-30 | 2012-12-18 | Brother Kogyo Kabushiki Kaisha | Information distribution system, program-for-management-apparatus recording medium, and program-for-information-processor recording medium |
JP2010238162A (ja) * | 2009-03-31 | 2010-10-21 | Brother Ind Ltd | コンテンツ配信システム、ノード装置、コンテンツ配信方法及びコンテンツ取得処理プログラム |
JP2011048466A (ja) * | 2009-08-25 | 2011-03-10 | Nippon Television Network Corp | データ配信方法、データ配信システム、配信元端末、及び配信先端末 |
WO2012025971A1 (ja) * | 2010-08-27 | 2012-03-01 | 株式会社日立ソリューションズ | コンテンツ変換装置、コンテンツ変換方法、コンテンツ変換プログラムおよびコンテンツ配信システム |
CN103081490A (zh) * | 2010-08-27 | 2013-05-01 | 株式会社日立解决方案 | 内容变换装置、内容变换方法、内容变换程序以及内容发布*** |
JPWO2012025971A1 (ja) * | 2010-08-27 | 2013-10-28 | 株式会社日立ソリューションズ | コンテンツ変換装置、コンテンツ変換方法、コンテンツ変換プログラムおよびコンテンツ配信システム |
JP5588008B2 (ja) * | 2010-08-27 | 2014-09-10 | 株式会社日立ソリューションズ | コンテンツ変換装置、コンテンツ変換方法、コンテンツ変換プログラムおよびコンテンツ配信システム |
JP2015026207A (ja) * | 2013-07-25 | 2015-02-05 | 富士通株式会社 | ファイル管理プログラム,ファイル管理装置及びファイル管理方法 |
US9690796B2 (en) | 2013-07-25 | 2017-06-27 | Fujitsu Limited | Non-transitory computer-readable media storing file management program, file management apparatus, and file management method |
JP2019056958A (ja) * | 2017-09-19 | 2019-04-11 | ヤフー株式会社 | ファイル管理装置、ファイル管理システム、ファイル管理方法およびファイル管理プログラム |
JP6991026B2 (ja) | 2017-09-19 | 2022-01-12 | ヤフー株式会社 | ファイル管理システム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9747301B2 (en) | Distributed file system using consensus nodes | |
US9846704B2 (en) | Distributed file system using consensus nodes | |
US8108347B2 (en) | Web server content replication | |
EP0976042B1 (en) | System and method for transferring one-to-many disk image among computers in a network | |
JP4590105B2 (ja) | ウェブサーバコンテンツ複製 | |
US20020161890A1 (en) | System and method for intelligently distributing content over a communicatons network | |
AU2005203359B2 (en) | Communication system | |
JP2009140515A (ja) | 中断された同期プロセスに対処してデータを同期させる方法、装置、システム | |
CN102567438A (zh) | 对分布式存储***中的数据项进行访问的方法 | |
WO2013075488A1 (zh) | 网元升级方法及装置 | |
JP2004102493A (ja) | コンテンツ配信方法及びコンテンツ配信制御装置 | |
CN114363350A (zh) | 一种服务治理***及方法 | |
JP2007293444A (ja) | 帳票配信システム、および帳票配信方法 | |
CN115914207A (zh) | 基于网页的文件传输方法、装置及可读存储介质 | |
CN112527369B (zh) | 一种智能终端的资源更新方法 | |
JPH09138769A (ja) | ソフトウェア配布システム及びソフトウェア配布方法 | |
JP3718273B2 (ja) | メンテナンスデータ管理方法 | |
JP4862346B2 (ja) | ダウンロードシステム及びプログラム | |
JP2005173724A (ja) | 文書管理システム、ファイルサーバ、文書管理プログラム、文書管理方法 | |
JP2004157753A (ja) | ファームウェアダウンロードシステム | |
KR101312573B1 (ko) | 메타데이터 접근 장치 및 방법 | |
JP2001014228A (ja) | ファイル配信システム、方法及び記録媒体 | |
JP5481845B2 (ja) | 情報処理システム、サービス提供方法、装置及びプログラム | |
JPH10124432A (ja) | クライアントサーバシステム | |
JP5498447B2 (ja) | ソフトウェアイメージ配信方法、ソフトウェアイメージ配信システム、サーバ、およびプログラム |