JP2011096275A - ファイル管理システム - Google Patents

Abstract

【課題】データの更新があった場合に送信先ノードに更新データの送信を行うこと。
【解決手段】ファイル管理方法において、複数のノードのうち、第１のノードにおいてオリジナルデータを記憶部に格納し、格納されたオリジナルデータを前記複数のノードのうち１又は複数のノードに送信し、第１のノードにおいて、オリジナルデータが送信された１又は複数のノードの情報を記憶し、第１のノードにおいて、オリジナルデータが更新された更新データを前記記憶部に記憶し、第１のノードにおいて、前記第１のノードに格納されたデータを定期的に検索することで、オリジナルデータの更新がなされたことを検出し、オリジナルデータの更新がなされたことの検出をトリガとして、１又は複数のノードの情報に従って、１又は複数のノードに対して更新データの送信を行う。
【選択図】図７

Description

本発明は、ピアツーピアネットワーク（Ｐ２Ｐ）におけるファイル管理システムに関し、より詳細には更新可能ファイルの配信元においてファイル配信先ノードを記憶しておき、ファイル更新の都度配信先に更新ファイルを配信するファイル管理システムに関する。

従来から、特定のサーバを介さず、エンドノード間でファイル共有を実現するピアツーピア（Ｐ２Ｐ）型ネットワークが着目されている。Ｐ２Ｐ型ネットワークでは、そのネットワーク内のあるノードにおけるコピーファイルが別のノードでさらにコピーされ、スケーラビリティがあるファイル共有を実現している。従来のＰ２Ｐ通信では下記の２つの機能により、エンドノード間でのファイル共有を実現している。

１）ファイル検索機能: ファイルをどのノードが有しているかを検索できる機能。その実現方式は大きく二つある。
（ａ）中央サーバ型：中央サーバがファイルの属性情報(ファイル名やタイムスタンプなど)と、そのファイルを有するノードのリストを有し、エンドノードがこれを検索する方式。
（ｂ）ピュア-Ｐ２Ｐ型：Ｐ２Ｐのノード間で検索メッセージをフラッディング(Flooding）し、ファイルを有するノードを検索する方式。

2）ファイルのダウンロード機能: ファイル検索によって得られたノードとセッションを張ってファイル転送を行う機能。
本発明は上記のピュアＰ２Ｐ型を対象とするため、以下にその動作例について記載する。なおＰ２Ｐでは、ピュアＰ２Ｐ型であれ中央サーバ型であれ、現状、標準化された技術はないため、ここではピュアＰ２Ｐ型の代表的なアプリケーションソフトであるグヌーテラ（Gnutella）を従来技術として示す。

図１は従来のGnutellaの概要を説明する概略図である。
Gnutella概要
Gnutellaはインターネットを通じて個人間でファイルの交換を行うアプリケーションソフトである。Gnutellaのユーザはインターネットを通じて相互に接続され、互いに所有するファイルの中から、他のユーザと共有してもよいファイルのリストを公開する。Gnutella上でファイル検索を行うと自ノード以外のノードが公開しているファイルから条件に合致するものが抽出され、ファイル検索を行ったノードは該リソースを有するノードから直接、該リソースをダウンロードすることができる。

Gnutellaにおけるファイル検索手順
以下、Gnutellaにおけるファイル検索手順について記す。
（手順特徴）
図１において、ファイルの発見要求クエリ（Query）を、接続しているホストに送ると、該要求が隣ノード間で順次中継される。要求対象のファイルを有するホストがヒット（Hit）応答を返すことで、ファイルの発見を実現する。
(手順)
(1)隣接ノードに対して、ファイルのクエリ(Query）コマンドを送信する。
(2)このコマンドは順次中継される。
(3)ファイルを有するノードは、Hit応答を返す。
(4)Hit応答はQueryとは逆の経路を順にたどって、Queryの送信元のノードへ応答する。
(5)Hit応答を返したノードのうちのいずれかとTCPで接続する。
(6)ファイルのGet要求を送信する。
(7)ファイルの内容が送り返されてくる。
なお上記（２）において、無限にQueryが中継されてしまうことを防ぐために、ＩＰ(Internet Protocol)と同様にTTL(Time To Live)の概念があり、一定ノード数以上を転送されたクエリは廃棄される。
図２は従来のピュアＰ２Ｐネットワークにおけるファイルの配布状態を説明する図である。図示例では、ファイル名がWork.doc、更新時刻が２０ＡＡ年ＢＢ月ＣＣ日、ＤＤ時ＥＥ分ＦＦ秒のファイルがノードＡから見てのダウンロード元ノードＢからノードＡを経由してノードＣに配布されている。ノードＣはノードＡから見ての配布先ノードである。

上記従来技術では、ダウンロードを希望するノードによるファイル検索がトリガとなって通信が始まる。これは、従来技術では音楽ファイルなど、更新が行われないことを前提としたファイルの交換を対象としていたためである。このため、更新が行われるワードやエクセル等で作成されたファイルをダウンロードした場合は、ダウンロード後の更新が行われたかどうかは配信先ノードには直ちには分からないという問題があった。

このため、従来技術では、ファイルの作成元のノードでファイル更新があった際に、その更新を他ノード(そのファイルのコピーを有するノード)で検知するためには、ファイル検索を繰り返すことによって更新有無をチェックする、といった煩雑な手間がかかるという問題があった。これは上記したように、通信のトリガがダウンロードを希望するノードによるファイル検索となっているためである。

本発明の目的は、Ｐ２Ｐの枠組みでのファイル交換を行う場合に、ファイルの更新があった場合に配信先ノードにその更新ファイルを直ちに送信することにある。
この目的を達成するために、本発明の第１の態様によれば、ピアツーピア型ネットワークに含まれるノードの少なくとも１つにおいて、更新可能ファイルを格納するデータベースと、該データベースに格納されたファイルの配信先ノードを記憶する配信履歴リストを作成する配信履歴リスト作成手段とを備えることを特徴とするファイル管理システムが提供される。

これにより、ピアツーピア型ネットワークに含まれるノードの少なくとも１つのノードは更新されたファイルの配信先ノードの配信履歴リストを保持しているので、配信先に更新ファイルを直ちに配信することができ、配信先ノードでは配信元ノードでファイルの更新があっても常に最新のファイルを入手することが可能になる。

本発明の第２の態様によれば、上記ファイル管理システムでは、少なくとも１つのノードは、ファイルが更新された時に、その更新時から所定時間内に配信履歴リストに登録されている配信先ノードに更新後のファイルを配布するファイル再配布手段を備える。
これにより、配信先ノードに更新後のファイルが確実に配布される。

本発明の第３の態様によれば、上記ファイル管理システムでは、ピアツーピア型ネットワークに含まれるすべてのノードは、配信履歴リスト作成手段とファイル再配布手段とを備えている。
これにより、ピアツーピア型ネットワークに含まれるすべてのノードにおいて、配信先ノードに更新後のファイルが確実に配布される。

本発明の第４の態様によれば、上記ファイル管理システムは、ファイルの配信元ノードがピアツーピア型ネットワークから離脱する場合に、配信元ノードとは別のピアツーピア型ネットワークに含まれる代替ノードに配信履歴リストを委託する配信履歴リスト委託手段を備えている。
これにより、ファイル配信元ノードがシャットダウン等によりネットワークから離脱する場合でも、代替ノードに配信履歴リストを委託できるので更新ファイルの入手ができなくなることはない。

本発明の第５の態様によれば、上記ファイル管理システムは、ピアツーピア型ネットワークから離脱したノードがピアツーピア型ネットワークに復帰した場合に、代替ノードから配信履歴リストを該復帰したノードに返却するファイル返却手段を代替ノードが備えている。
これにより、ピアツーピア型ネットワークから離脱したノードがピアツーピア型ネットワークに復帰した場合に、復帰したノードにより更新ファイルが配信先ノードに配布できるようになる。

本発明によれば、上記ファイル管理システムを実現する方法、コンピュータに上記ファイル管理システムの動作を実行させるプログラム及びそのプログラムを記録した記録媒体も提供される。

従来の従来のGnutellaの概要を説明する概略図である。 従来のピュアＰ２Ｐネットワークにおけるファイルの配布状態を説明する図である。 本発明の実施の形態による一つの中継ノードの構成を示すブロック図である。 本発明の実施の形態によるファイルの配布経路を動的に作成する処理の流れを全体的に説明する図である。 本発明の実施の形態による配信元ノードαにおける処理の流れを説明する図である。 本発明の実施の形態による配信先ノードβにおける処理の流れを説明する図である。 本発明の実施の形態によるファイル更新時の処理の流れを全体的に説明する図である。 本発明の実施の形態によるファイル更新時の配信元ノードαにおける処理の流れを説明する図である。 本発明の実施の形態によるファイル更新時の配信先ノードβにおける処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の処理の流れを全体的に説明する図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の処理の流れを示すタイムシーケンス図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時におけるノードαの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時におけるノードβの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時におけるノードγの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時におけるノードδの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードβにおける図１０Ｂの（ａ）の処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードδにおける図１０Ｂの（ｂ）処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードδにおける図１０Ｂの（ｃ）処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードβにおける図１０Ｂの（ｄ）処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の処理の流れを全体的に説明する図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の処理の流れを示すタイムシーケンス図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時におけるノードαの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時におけるノードβの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時におけるノードγの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時におけるノードδの配信履歴リストを示す図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードδにおける図１５Ｂの（ａ）の処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードβにおける図１５Ｂの（ｂ）処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードδにおける図１５Ｂの（ｃ）処理の流れを説明する図である。 本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードαにおける図１５Ｂの（ｄ）処理の流れを説明する図である。

図３は本発明の実施の形態によるＰ２Ｐネットワーク内の一つの中継ノードの構成を示す機能ブロック図である。同図において、ノード３は、配信履歴リストデータベース３０１と、ファイルデータベース３０２と、受信部３０３と、更新ファイル処理部３０４と、Ｐ２Ｐ処理部３０５と、フィールド抽出部３０６と、配信履歴リスト作成／更新部３０７と、配信履歴リスト検索部３０８と、配信履歴リスト送信部３０９と、制御メッセージ送信部３１０と、ファイル検索部３１１と、ファイル送信部３１２と、タイマー部３１３と、コンソール部３１４と、返却配信履歴リスト検索部を備えている。

配信履歴リスト検索部３０８は返却配信履歴リスト検索部も含む。配信履歴リスト送信部３０９は返却配信履歴リスト送信部も含む。

配信履歴リストデータベース３０１は、配信履歴リストを管理するデータベースであり、図に表で示したように、以下の情報を格納する。
（１）ファイル名: Ｐ２Ｐ網経由で、自ノードにダウンロードした、または自ノードからダウンロードされたファイルのファイル名。
（２）ダウンロード元ＩＰアドレス: 上記“ファイル名”のファイルのダウンロード元ノードのＩＰアドレス。本データベースを有するノードがファイルの作成元の場合、ダウンロード元にあたるノードは存在しないため、本エントリは”NULL”となる(図の表記上は”-“とする)。
（３）配布先ＩＰアドレス: 上記“ファイル名”のファイルの配布先ノードのＩＰアドレス。本データベースを有するノードから該ファイルが複数のノードにダウンロードされた場合には本エントリには複数のＩＰアドレスが記載される。なお該ファイルが本ノードからダウンロードされていない場合には、本エントリは”NULL”となる(図の表記上は”-“とする)。
（４）更新日時: 上記“ファイル名”フィールドに記載したファイルが作成または更新された日時。
（５）依頼フラグ（Flag）: 他ノードから依頼されて有している配信履歴リストのエントリを示す。その内容は、”0”であれば自ノードで作成されたエントリであることを示し、”1”であれば他ノードで作成されたエントリであることを示す。次の「依頼元ＩＰアドレス」のエントリがあわせて記載される。
（６）依頼元ＩＰアドレス: 本エントリが他ノードからの依頼により作成されている場合は、その依頼元ノードのＩＰアドレスを記載する。

ファイルデータベース３０２は、ファイルを管理するデータベースであり、いわゆるＯＳのファイルシステムである。
受信部３０３は、ネットワークからの通信を電気的に終端し、また受信フレームの種別を識別し、内部の処理フロー（経由する機能ブロック群）を決定する。

更新ファイル処理部３０４は、更新されたファイルを上流ノードから受信時にファイルデータベース３０２に該ファイルを書き込む。なお書き込み方は、古いファイルを無条件に上書きする方法や、ユーザに問い合わせた上で上書きするなど、実装依存とし、特に限定はしない。

Ｐ２Ｐ処理部３０５は、いわゆるＰ２Ｐ一般で必要となる下記の処理を行う。
（１）ファイル検索処理：Ｐ２Ｐでファイルの検索要求に応じてのファイル検索処理、その要求のフォーワード処理（自ノードに検索対象のファイルがなかった場合）及びファイル検索結果の通知処理（（自ノードに検索対象のファイルがあった場合）を行う。
（２）ファイル送受信処理: ファイル転送時のファイルの送受信処理を行う。

フィールド抽出部３０６は、ファイルをダウンロードさせるときやファイルをダウンロードするときにその制御フレームから配信履歴リストデータベース３０１を作成するために必要なフィールドの情報を抽出する。抽出するフィールドの情報は下記の通りである。
（１）ファイル名
（２）ダウンロード元ＩＰアドレス、または配布先ＩＰアドレス
（３）ファイルのタイムスタンプ

配信履歴リスト作成／更新部３０７は、配信履歴リストのエントリの作成及び更新（エントリのフィールド変更及び削除）を行う。
配信履歴リスト検索部３０８は、配信履歴リストの検索を前段の機能ブロックから指定された検索キーで検索し、ヒットしたエントリのフィールドを戻り値とする。

配信履歴リスト送信部３０９は、配信履歴リスト検索部３０８で抽出されたＩＰアドレス毎に配信履歴リストの返却を行う。配信履歴リスト検索部３０８は、ノードのシャットダウンが回復した際に返却されるファイルの返却配信履歴リスト検索部も含む。また、配信履歴リスト送信部３０９は、返却されたファイルの返却配信履歴リスト送信部も含む。

制御メッセージ送信部３１０は、配信履歴リストデータベース３０１の管理に関する制御メッセージの送信を行う。制御フレームには以下の二つがある（それぞれの意味については次節参照）。
（１）配信履歴リスト変更依頼フレーム
（２）配信履歴リスト受信完了フレーム

配信履歴リスト送信部３０９は、配信履歴リストデータベース３０１の全エントリを送信する。
ファイル検索部３１１は、更新があったファイルを、ファイルを蓄積しているデバイス（例えば自ノードのハードディスク）から検索する。
ファイル送信部３１２は、ファイル検索部３１１での検索結果として見つかったファイルを対象に、配信履歴リストデータベース３０１を検索し、配布先ＩＰアドレスに向けて送信する。または配信履歴リストの返却依頼時には依頼元ＩＰアドレスに向けて送信する。

タイマー部３１３は、予め決められた時間間隔毎にファイル検索部３１１に対して更新ファイルの検索指示を、また配信履歴リスト検索部３０８に、配信履歴リストの検索フラグが”1”になっているファイルの依頼元ＩＰアドレスの抽出を指示する。依頼元ノードが再起動し、依頼されていた配信履歴リストを返却できるか確認するためである。
コンソール部３１４は、区切り文字保持部と自局ＩＰアドレス保持部の設定を予め行うユーザの入出力を扱うインタフェース部である。

次に動作を説明する。
図４は、本発明の実施の形態によるファイルの配布経路を動的に作成する処理の流れを全体的に説明する図である。同図において、Ｐ２Ｐのファイルダウンロード処理が行われ、配信履歴リストをファイル配布元ノードαとファイル配布先ノードβが作成する過程が示されている。

配信履歴リストを作成する前提として、ファイルの検索処理は予め行われているものとする(図１の”query”と”hit”があったとする)。即ち、ノードβはノードαが目的とするファイル(Document-A)を有していることをここでは図示しない方法、例えばＰ２Ｐにおける一般的なファイル検索手法など、により予め知っているものとする。

Ｐ２Ｐにおけるファイルダウンロードに関する一般的な処理、即ち、配信履歴リストを作成する以外の処理、例えば、ダウンロードしたファイルのディスクへの書き込みなど、は図５及び図６のＰ２Ｐ処理部３０５で処理することとし、ここではその詳細な記載を省略する。

ノードαやノードβから、更に別のノードにファイルがダウンロードされる場合についての手順は同様のため記載を省略する。
図４中では「配信履歴リスト」の「依頼フラグ」と「依頼元ＩＰアドレス」の両フィールドは、ファイルの配布経路を動的に作成のためには使用しないので、記載を省略している。本実施の形態では、ファイルの配布経路を動的に作れる。すなわち、依頼元のノードβから配布先のノードαにダウンロード要求フレームを送信し、配布先ノードαではこのダウンロード要求フレームに応答してファイル（Document-A）を依頼元ノードβに転送する。ファイルのコピーを配布元ノードから配布先ノードに配布した時点で配布元ノードにおいて配布先ノードを配布履歴リストに登録することが本実施の形態における重要なポイントである。

配布元ノードαの動作
図５は本発明の実施の形態による配信元ノードαにおける処理の流れを説明する図である。図５以降の図において、太線のブロックがそれぞれの処理に係わるブロックである。
受信部３０３は配信先ノードβからファイルのダウンロード要求(例えば図１の“get”)
を受信する。

Ｐ２Ｐ処理部３０５は、ダウンロード要求のファイルを要求先ノードβに向けてファイル転送フレームとして送信する。異常なく送信できた場合にはフィールド抽出部３０６へ処理を渡す。異常時にはコンソール３１４にメッセージを表示して処理を終了する。
フィールド抽出部３０６は、配信履歴リストを作成するためにダウンロード要求フレームから以下のフィールドを抽出する。
（１）ファイル名
（２）ダウンロード要求の要求元ＩＰアドレス

またダウンロードされたファイルの属性からファイルの更新日時（タイムスタンプ）を抽出する。
配信履歴リスト作成／更新部３０７は、フィールド抽出部３０６から抽出したデータから配信履歴リストデータベース３０１に新規エントリを作成する。

配布先ノードβの動作
図６は本発明の実施の形態による配信先ノードβにおける処理の流れを説明する図である。同図において、受信部３０３は、ノードαから自ノード(ノードβ)がダウンロードを要求したファイルをファイル転送フレームとして受信する。

Ｐ２Ｐ処理部３０５は、受信したファイルを配信履歴リストデータベース３０１に書き込む。
フィールド抽出部３０６は、受信したダウンロードファイル及びその転送フレームから以下の情報を抽出する。
（１）ファイル名
（２）ダウンロード元のＩＰアドレス
（３）ファイルの更新日時（タイムスタンプ）
配信履歴リスト作成／更新部３０７は、フィールド抽出部３０６から抽出したデータから配信履歴リストデータベース３０１に新規エントリを作成する。

次にファイル更新時の更新元ノード及び配信先ノードの動作を説明する。
図７は、本発明の実施の形態によるファイル更新時の処理の流れを全体的に説明する図である。
ファイル更新処理の概要
ファイル（Document-A）の更新が該ファイルのオリジナルを有するノードαで行われ（１）、それをトリガにして配信履歴リストに基づき、更新されたファイル（Document-A）がノードβに配信される（２）過程を示す。
ファイルの更新が行われる前提として、本例ではノードαからノードβに配信する場合にのみについて記載するが、ノードβ以外のノードへも該ファイルがダウンロードされている場合の処理も同様である。

更新されたファイルを受信したノードβが該受信ファイルをどう処理するか、例えば、更新前のファイルに無条件に上書きする、ユーザに上書きするか否かを確認する、などはいずれでもよい。いずれにしても、ノードβの配信履歴リストに更新済みのファイル（Document-A）が書き込まれる。
図７においては、「配信履歴リスト」の「依頼フラグ」と「依頼元ＩＰアドレス」の両フィールドは未使用なため記載を省略してある。
次にファイル更新時の配信元ノードと配信先ノードにおける各部の動作を説明する。

配信元ノードαの動作
図８は本発明の実施の形態によるファイル更新時の配信元ノードαにおける処理の流れを説明する図である。同図において、タイマー部３１３は、定期的にファイル検索部を駆動する。ファイル検索部３１１は、ファイルデータベース３０２から前回検索時以降に更新されたファイルを検索する。更新されたファイルを検出した場合、ファイル情報(ファイル名とファイルそのもの)を配信履歴リスト検索部３０８へ渡す。更新されたファイルがなかった場合は、処理を終了する。

配信履歴リスト検索部３０８は、ファイル検索部３１１から渡されたファイル情報のファイル名を検索キーとして、配信履歴リストデータベース３０１を検索する。そのファイル名のエントリがあった場合、「配布先ＩＰアドレス」のノードのＩＰアドレスと、ファイル検索部３１１から渡されたファイル情報をファイル送信部３１２に渡す。
ファイル送信部３１２は、「配布先ＩＰアドレス」のノードへファイルを、更新ファイル転送フレームとして送信する。

ノードβの動作
図９は本発明の実施の形態によるファイル更新時の配信先ノードβにおける処理の流れを説明する図である。同図において、受信部３０３は、ノードαが送信した更新ファイル転送フレームを受信する。更新ファイル処理部３０４は、更新ファイル転送フレームが有するファイルをファイルデータベース３０２に書き込む。無条件に書き込むか、ユーザに書き込むか否かを確認するかなどの書き込み方法の詳細手順は本発明では特定しない。

配信履歴リスト検索部３０８は、更新されたファイルを検索する。更新日時を新たに受信したファイルの更新日時にアップデートするとともに、さらに該ファイルを転送するか否かを配布先ＩＰアドレスから決定する。即ち、配信履歴リストの「配布先ＩＰアドレス」のフィールドがNULLの場合は処理を終了し、NULLではない場合は、ファイル送信部３１２を経由してファイルをさらに下流のノードに転送する。

次に配信履歴リストデータベース３０１の管理依頼時の動作を説明する。
図１０Ａ〜図１０Ｆは、本発明の実施の形態による配信履歴リストデータベースの管理依頼時の処理の流れを全体的に説明する図である。
配信履歴リストデータベース３０１の管理依頼時の処理の概要
任意のノード(図１０Ａ及び図１０Ｂではノードβ)が、マシンのシャットダウンなどによりＰ２Ｐ網を一時的に離脱するときに、配信履歴リストの保持を他のノード(図１０Ａ及び図Ｂではノードδ)に依頼する処理の過程を示す。図１０Ｃ、図１０Ｄ、図１０Ｅ、図１０Ｆはそれぞれ、のときのノードα、β、γ、δの配信履歴リストを示す。
そして、依頼元ノードβがＰ２Ｐ網を離脱しているときに、ファイル更新によるファイル受信があった場合には依頼先ノードδがこれを代理で受信処理し、配信履歴リスト返却時に該ファイルも依頼先ノードδから依頼元ノードβに送信する。

前提として、ノードα→ノードβ→ノードγとファイルが本処理の始まる以前にダウンロードされていたものとする。また、ノードαはＰ２Ｐ網上の他のノード(ノードδ)をここでは記載しない手法（Ｐ２Ｐ網上で隣接しているノードであるなどの基準による選択手法など）で予め決定しているものとする。
ノードβの動作その１
図１１は本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードβにおける図１０Ｂの（ａ）の処理の流れを説明する図である。同図において、コンソール部３１４は、ユーザがノードβにシャットダウン指示をした場合などをトリガに、コンソール部３１４から配信履歴リストの管理を他ノードに依頼する旨を配信履歴リスト検索部３０８に通知する。これを受けた配信履歴リスト検索部３０８は、配信履歴リストデータベース３０１内の配信履歴リストの全エントリから「配布先ＩＰアドレス」と「ダウンロード元ＩＰアドレス」を抽出する。

制御メッセージ送信部３１０は、配信履歴リスト検索部３０８で抽出された両ＩＰアドレス宛に配信履歴リスト変更依頼フレームを送信する。送信される変更依頼には下記の情報が含まれる。
（１）変更依頼元ＩＰアドレス（ここではノードβ）
（２）変更先ＩＰアドレス（ここではノードδ）

なお「変更先ＩＰアドレス」は、ここでは記載しない手法（Ｐ２Ｐ網上で隣接しているノードであるなどの基準による選択手法など）で予め決定しているものとする。
配信履歴リスト送信部３０９は、配信履歴リストを、配信履歴リスト変更依頼フレームとして、予め決定されているＰ２Ｐ網上の任意の隣接ノード(ここではノードδ)に送信する。

ノードαの動作(ノードγの処理も同様)
図１２は、本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードδにおける図１０Ｂの（ｂ）処理の流れを説明する図である。同図において、受信部３０３は、(ノードβが送信した)配信履歴リスト変更依頼フレームを受信する。
次いで配信履歴リスト作成／更新部３０７は、配信履歴リスト変更依頼フレームに含まれる「変更依頼元ＩＰアドレス」を検索キーとして、配信履歴リストデータベース３０１に対して以下の２回の検索処理を行う。
（１）「ダウンロード元ＩＰアドレス」を検索対象フィールドとして検索する。ヒットしたエントリの「ダウンロード元ＩＰアドレス」を配信履歴リスト変更依頼に含まれる「変更先ＩＰアドレス」に変更する。
（２）「配布先ＩＰアドレス」を検索対象フィールドとして検索する。ヒットしたエントリの「配布先ＩＰアドレス」を配信履歴リスト変更依頼に含まれる「変更先ＩＰアドレス」に変更する。

ノードδの動作
図１３は、本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードδにおける図１０Ｂの（ｃ）処理の流れを説明する図である。同図において、受信部３０３は、(ノードβが送信した)配信履歴リスト送信フレームを受信する。次いで配信履歴リスト作成／更新部３０７は、受信した配信履歴リスト送信フレームが有する配信履歴リストを、配信履歴リストデータベース３０１に書き込む。なおこの際に書き込む全エントリに対し、以下のフィールドを追記する。
（１）依頼フラグ（Flag）フィールド: “1”として書き込む。
（２）依頼元ＩＰアドレスフィールド: 配信履歴リストの送信元ノード(ノードβ)のＩＰアドレスを書き込む。
次いで配信履歴リストデータベース３０１は、配信履歴リスト受信完了フレームを配信履歴リストの送信元(ノードβ)に向けて送信する。

ノードβの動作その２
図１４は、本発明の実施の形態による配信履歴リストデータベースの管理依頼時の配信先ノードβにおける図１０Ｂの（ｄ）処理の流れを説明する図である。同図において、受信部３０３は、(ノードδが送信した)配信履歴リスト受信完了フレームを受信する。次いで配信履歴リスト作成／更新部３０７は、配信履歴リストの全エントリを削除し、次いでコンソール部３１４に配信履歴リストの管理の依頼処理が完了したことを通知する。

次に配信履歴リストデータベース３０１の返却依頼時の動作を説明する。
処理の概要
図１５Ａ〜図１５Ｆは、本発明の実施の形態による配信履歴リストデータベースの返却依頼時の処理の流れを全体的に説明する図である。同図において、任意のノード(図１５Ａ及び図１５Ｂではノードβ)が、マシンシャットダウンなどの理由によりＰ２Ｐ網から一時的に離脱するときに、配信履歴リストの保持を他のノード(図１５Ａではノードδ)に依頼したのち、再び依頼元ノード（ノードβ）がＰ２Ｐ網から一時的に離脱する理由が解消すると、Ｐ２Ｐ網に再度加入し、自ノードの配信履歴リストを依頼先（ノードδ）から返却してもらう。

前提として、図１０Ａ〜図１０Ｆの場合と同様に、ノードα→ノードβ→ノードγとファイルが本処理が始まる以前にダウンロードされていたものとする。また、ノードαはＰ２Ｐ網上の他のノード(ノードδ)をここでは記載しない手法（Ｐ２Ｐ網上で隣接しているノードであるなどの基準による選択手法など）で予め決定しているものとする。なお、図１５Ｃ、図１５Ｄ、図１５Ｅ、図１５Ｆはそれぞれ、このときのノードα、ノードβ、ノードγ、ノードδの配信履歴リストを示す。

ノードδの動作その1
図１６は、本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードδにおける図１５Ｂの（ａ）の処理の流れを説明する図である。同図において、タイマー部３１３は、配信履歴リスト検索部３０８に対し、定期的に「依頼Flagフィールド」が”1”であるエントリの検索を駆動する。

タイマー部３１３からの駆動を受けた配信履歴リスト検索部３０８は、「依頼Flagフィールド」が”1”であるエントリの検索を配信履歴リストデータベース３０１に対して実施する。該当するエントリの「依頼元ＩＰアドレスフィールド」毎に、該エントリの「依頼Flagフィールド」と「依頼元ＩＰアドレスフィールド」を除くフィールドを配信履歴リスト送信部へ渡す。なお図１０〜図１４を参照して記載した配信履歴リストデータベース３０１の管理依頼の手順により、代理で管理することになった配信履歴リスト内のファイルが代理管理中に更新された場合はそのファイルも配信履歴リスト送信部３０９へ渡す（図示せず）。

配信履歴リスト送信部３０９は、配信履歴リスト検索部３０８から渡された配信履歴リストのエントリ及びファイル（もし更新されていれば）を、依頼元ＩＰアドレスを宛先アドレスとし、配信履歴リスト送信フレームとして送信する。

ノードβの動作
図１７は、本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードβにおける図１５Ｂの（ｂ）処理の流れを説明する図である。同図において、受信部３０３は、配信履歴リスト送信フレームを受信する。配信履歴リスト作成／更新部３０７は、配信履歴リスト送信フレームから配信履歴リストデータベース３０１にエントリを作成（エントリの復元）する。もしファイルも配信履歴リスト送信フレームに含まれていれば、ファイルデータベース３０２の該ファイルも更新する（図示せず）。

制御メッセージ送信部３１０は、以下の二つの制御メッセージを送信する。
（１）配信履歴リスト受信完了フレーム: 配信履歴リスト送信フレームの送信元（ノードδ）に送信する。
（２）配信履歴リスト変更依頼フレーム: 復元したエントリのダウンロード元ＩＰアドレス(ＩＰ-α)と配布先ＩＰアドレス(ＩＰ-γ)毎に送信する。該配信履歴リスト変更依頼フレームには、配信履歴リスト送信フレームの送信元ＩＰアドレス(ＩＰ-δ)が含まれる。

ノードδの動作その２
図１８は、本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードδにおける図１５Ｂの（ｃ）処理の流れを説明する図である。同図において、受信部３０３は、配信履歴リスト受信完了フレームを受信する。なお配信履歴リスト送信フレームを送信後、一定時間以内に該フレームを受信しない場合には受信タイムアウトで終了する。これは、依頼元ＩＰアドレスがまだ配信履歴リストを再管理できない状態にあると判断するからである。

配信履歴リスト送信部３０９は、配信履歴リスト受信完了フレームの送信元ＩＰアドレス(ＩＰ-β)を検索キーとして、配信履歴リストデータベース３０１の「依頼元ＩＰアドレスフィールド」を検索し、該当したエントリを削除する。

ノードαの動作
図１９は、本発明の実施の形態による配信履歴リストデータベースの返却依頼時の配信先ノードαにおける図１５Ｂの（ｄ）処理の流れを説明する図である。同図において、受信部３０３は、配信履歴リスト変更依頼フレームを受信する。配信履歴リスト送信部３０９は、配信履歴リスト変更依頼フレームに含まれるＩＰアドレス(ＩＰ-δ）を検索キーとして、配信履歴リストDBに対して以下の２回の検索処理を行う。
（１）「ダウンロード元ＩＰアドレス」を検索対象フィールドとして検索する。ヒットしたエントリの「ダウンロード元ＩＰアドレス」を配信履歴リスト変更依頼フレームの送信元ＩＰアドレス(ＩＰ-β)に変更する。
（２）「配布先ＩＰアドレス」を検索対象フィールドとして検索する。ヒットしたエントリの「配布先ＩＰアドレス」を配信履歴リスト変更依頼フレームの送信元ＩＰアドレス(ＩＰ-β)に変更する。

以上の説明から明らかなように、本発明によれば、Ｐ２Ｐネットワーク内でファイルの配布経路を各ノードが管理することにより、更新ファイルの再配布を可能とし、それによりユーザのファイル検索工数が削減される。
また、Ｐ２Ｐネットワーク内であるノードがシャットダウンした場合でも、代替ノードによるファイル配布経路を作成することにより、ファイル配布経路上のノードがシャットダウンしていても更新ファイルを再送付できるようになり、更新ファイルの配布の即時性が向上する。

Claims (3)

1. ファイル管理方法において、
   複数のノードのうち、第１のノードにおいてオリジナルデータを記憶部に格納し、格納された前記オリジナルデータを前記複数のノードのうち１又は複数のノードに送信し、
   前記第１のノードにおいて、前記オリジナルデータが送信された前記１又は複数のノードの情報を記憶し、
   前記第１のノードにおいて、前記オリジナルデータが更新された更新データを前記記憶部に記憶し、
   前記第１のノードにおいて、前記第１のノードに格納されたデータを定期的に検索することで、前記オリジナルデータの更新がなされたことを検出し、
   前記オリジナルデータの更新がなされたことの検出をトリガとして、前記１又は複数のノードの情報に従って、前記１又は複数のノードに対して前記更新データの送信を行う、
   ことを特徴とするファイル管理方法。
2. 更に、前回の検索時刻の後に前記オリジナルデータについて更新がなされたことの検出に用いられる、前記オリジナルデータの更新時刻を記憶する、ことを特徴とする請求項１に記載のファイル管理方法。
3. オリジナルデータを最初に格納するともに、前記オリジナルデータの１又は複数の送信先のノードの情報を記憶する記憶手段と、
   前記記憶手段に格納されたデータを定期的に検索して、前記オリジナルデータの更新が行われたことを検出する検索手段と、
   前記検索手段によって前記オリジナルデータの更新が行われたことを検出されたことをトリガとして、前記情報に従って、前記更新されたデータを前記１又は複数の送信先に送信する送信手段と、
   を備えたことを特徴とするノード。

Images