JP2012521696A

JP2012521696A - ピア・ツー・ピア・ネットワークにおけるイベント識別

Info

Publication number: JP2012521696A
Application number: JP2012501143A
Authority: JP
Inventors: ヨウニメーンパー，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2009-03-23
Filing date: 2009-03-23
Publication date: 2012-09-13
Anticipated expiration: 2029-03-23
Also published as: EP2412138B1; US8509407B2; JP5442841B2; EP2412138A1; US20120039453A1; WO2010108535A1

Abstract

ＤＨＴベースのＰ２Ｐオーバレイネットワークについてのイベントトリガリング手法を用いた、ＤＨＴについてのイベント通知手法及びアクセス制御手法が記載される。特定のイベントに興味があるユーザは、トリガをＤＨＴに挿入することができる。イベントが発生した時、トリガに火がついて、予め定義されたアクションが実行される。特に、ＤＨＴを有するＰ２Ｐネットワークにおいてイベントを監視する方法が記載される。ユーザピアは、イベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードをＤＨＴへと挿入する。前記イベントが関連付けられ又は関連付けられるであろう、監視されるリソースレコードが識別される。そして、前記監視されるリソースレコードを管理する責任がある監視ピアが識別される。前記監視ピアにおいて前記トリガ・リソースレコードが管理される。

Description

本発明は、Ｐ２Ｐネットワークにおけるイベント識別に関する。特に本発明は、ＤＨＴベースのＰ２Ｐオーバレイネットワークについてのイベントトリガリング手法に関する。

ハッシュテーブルは、キーを値と関連付けるデータ構造である。キーは、例えば、人名でありうる。このとき対応する値は、人の連絡先アドレス（例えば電子メールアドレス、又はセッション開始プロトコル（ＳＩＰ）のユニフォーム・リソース・アイデンティファイア（ＵＲＩ）でありうる。ハッシュテーブルがサポートする主な動作は、ルックアップであり、キーが与えられると、ハッシュテーブルは対応する値を発見する。

分散ハッシュテーブル（ＤＨＴ）は、ハッシュテーブルに類似したルックアップサービスを提供する。しかしながら、通常のハッシュテーブルとは異なり、ＤＨＴは集中排除された分散システムである。ＤＨＴにおいて、名前から値へのマッピングを管理する責任は、システムに参加しているノード（又はピア）の間で分散されている。このことは、キー空間を参加ノードの間で分割することによって達成される。ノードはオーバレイネットワークによって互いに接続され、このことはノードがキー空間における任意の所与のキーの持ち主を発見することを可能とする。

オーバレイネットワークにおいて、それぞれのノードは他のノードへのリンクのセットを管理する。このリンクのセットは、ノードのルーティングテーブルである。Ｃｈｏｒｄ（Ｓｔｏｉｃａほか、"Ｃｈｏｒｄ：ＡＳｃａｌａｂｌｅＰｅｅｒ−ｔｏ−ｐｅｅｒＬｏｏｋｕｐＳｅｒｖｉｃｅｆｏｒＩｎｔｅｒｎｅｔＡｐｐｌｉｃａｔｉｏｎｓ（Ｃｈｏｒｄ：インターネットアプリケーションのためのスケーラブルなピア・ツー・ピア・ルックアップサービス）"、ＰｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅＡＣＭＳＩＧＣＯＭＭ'０１Ｃｏｎｆｅｒｅｎｃｅ，２００１年８月、サンディエゴ、カリフォルニア、米国）のようないくつかのＤＨＴにおいて、ルーティングテーブル内のエントリはフィンガと呼ばれる。それぞれのノードはまた、ルーティングテーブルに加えて、隣接リスト(neighbor list)と呼ばれる他のデータ構造を管理する。隣接リストは、オーバレイネットワークにおける、ノードの直接のサクセサ(successor)及び直接のプレデセサ(predecessor)（すなわちネイバ(neighbor)）へのポインタを含む。ノードはそのネイバを、ネットワークトポロジと呼ばれる特定の構造に従って選ぶ。ノードがピアであるような、リングトポロジと呼ばれるこのようなトポロジの１つが、図１に示されている。ビア１０１は、直接のプレデセサ１０２，１０３と、直接のサクセサ１０４，１０５を有する。ピア１０１もまた、そのルーティングテーブルにおいて、ネットワークのどこかにある３つのフィンガ１１１，１１２，１１３へのリンクを管理している。

ＤＨＴに参加しているそれぞれのピアは、そのピアのＩＰアドレス及びポート番号のような一意な情報の決まった部分に対してハッシュを計算することにより生成された、そのピア識別子（ピアＩＤ）によって識別される。多くのＤＨＴは、セキュア・ハッシュ・アルゴリズム・ワン（ＳＨＡ−１）を、ベース・ハッシュ・アルゴリズムとして用いる。ＤＨＴにおいて、ピア識別子及びリソース識別子（すなわちキー）は、同じ名前空間に格納される。例えば、ＣｈｏｒｄＤＨＴにおいて、それぞれのピアは、その識別子がそのプレデセサのピア識別子と自身のピア識別子との間に入るようなリソースを格納する責任を有する。リソース識別子（リソースＩＤ）もまた、（ピアＩＤと類似の方法で）そのリソースを一意に識別する情報の一部に対してハッシュを計算することによって構成される。例えば、リソースレコードがユーザのＳＩＰ端末の連絡先アドレスであるならば、リソースＩＤはこのユーザのＳＩＰＵＲＩに対してハッシュを計算することによって形成されることができる。ＤＨＴにおいて、ユーザの連絡先情報が、ユーザのエンドポイントが責任を持つ識別子空間の一部に入る場合にのみ、ユーザは自身の連絡先情報を格納する責任を持つ。

ＤＨＴには、低い資本費用、低い営業費用、スケーラビリティ、及びロバスト性のような多くの利益を有するが、ボイス・オーバ・ＩＰ（ＶｏＩＰ）、インスタントメッセージング、及びプレゼンスシステムのような、分散個人間通信システムに用いられる場合、ＤＨＴはいくつかの問題に直面する。従来のクライアント・サーバ通信システムにおいてはシステムのインテリジェンスの全ては中央サーバに存在するが、一方でピア・ツー・ピア（Ｐ２Ｐ）システムにおいては、システムのインテリジェンスの全てがエンドポイントへと分散される。クライアント・サーバＶｏＩＰは、他のものの中でも、呼制御、プレゼンス、ユーザ登録、電話付加サービス、及びネットワークアドレス変換器（ＮＡＴ）通過のような機能を提供する時に、中央サーバに頼る。Ｐ２ＰＶｏＩＰにおいては、それらの機能は分散された方法で提供される必要がある。

１つの問題は、分散プレゼンスサービスの用意にある。純粋なＰ２Ｐプレゼンスシステムにおいては、ユーザが自分のプレゼンスステータスを更新することができ、ユーザの仲間のプレゼンスステータスの変更についてユーザに通知することができるような、中央プレゼンスサーバは存在しない。その代わりに、ユーザには自分自身でユーザの仲間のプレゼンスステータスを追跡する責任がある。ユーザの仲間がＰ２Ｐオーバレイに参加した時を検出するために、ユーザはオフラインの仲間を定期的にポーリングしなければならない。定期的なポーリング動作のそれぞれは、ＤＨＴから仲間の連絡先レコードを取得することを試みるＰ２Ｐルックアップを必要とする。連絡先レコードを見つけることができないならば、仲間はまだオフラインのままである。理想的には、仲間がオーバレイに参加してからユーザがこのことを検出するまでに大きな間隔が存在しないように、オフラインの仲間がポーリングされるこの間隔はかなり短い。このアプローチに関する問題は、オフラインの仲間に対する定期的なルックアップが、オーバレイにおいて多くの余分のトラフィックを発生させることである。ポーリング間隔が頻繁であるならば、システムにおける大部分のルックアップが、オフラインの仲間についてのルックアップであることは、珍しいことではない。システムがこのようなルックアップであふれてしまうために、このことは性能にネガティブな影響を有する。

ポーリングトラフィックの量を減らすために、ポーリング間隔はいくぶん頻繁ではないようにされることができる。これが、現実世界のＰ２Ｐプレゼンスシステムが行うことを強いられているアプローチである。これらのシステムにおいては、ユーザがシステムに参加した時からユーザの仲間がこのことを検出するまでに、５分以上かかることはまれではない。このことは自然ながら、悪いユーザ体験に繋がる。このように、Ｐ２Ｐ存在システムは、ポーリングトラフィックを減らすか又は除き、さらに仲間がオンラインになったことの検出をほとんど瞬時にする手法から、多くの利益を得るだろう。

電話付加サービスもまた、分散環境において提供することは難しい。従来のクライアント・サーバ・システムでは、呼転送、呼制限、及びビジーな加入者への呼接続のような付加サービスは、中央ネットワーク要素によって取り扱われる。Ｐ２Ｐ環境においては、そのようなサービスを実装する直接の方法が存在しない。

１つのさらなる問題は、サービス発見である。Ｐ２Ｐシステムにおいては、特定のサービスを提供するピアは、サービスのサービス識別子を用いて、サービスプロバイダとしてオーバレイへと登録する。他のピアは、サービス識別子に対するルックアップを送信することにより、サービスプロバイダを発見する。サービスプロバイダが利用できないならば、サービスに興味があるピアは、サービスが利用可能になる時を検出するために、定期的にルックアップを行わなければならない。このような定期的な問い合わせは、また、余分なトラフィックを引き起こし、システムの性能を低下させる。

ＤＨＴベースのＰ２Ｐシステムにおいて、（中でも）プレゼンスサービス、電話付加サービス、及びサービス発見を提供することに関連する困難性に取り組むことが、本発明の目的である。

本発明は概して、ＤＨＴベースのＰ２Ｐオーバレイネットワークについてのイベントトリガリング手法を用いて、ＤＨＴについての一般的なイベント通知手法及びアクセス制御手法を提供する。特定のイベントに興味があるユーザは、トリガをＤＨＴに挿入することができる。イベントが発生した時、トリガに火がついて、予め定義されたアクションが実行される。

本発明の１つの態様に従って、ＤＨＴを有するＰ２Ｐネットワークにおいてイベントを監視する方法が提供される。ユーザピアは、イベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードをＤＨＴへと挿入する。前記イベントが関連付けられ又は関連付けられるであろう、監視されるリソースレコードが識別される。そして、前記監視されるリソースレコードを管理する責任がある監視ピアが識別される。前記監視ピアにおいて前記トリガ・リソースレコードが管理される。

前記監視ピアの前記識別は、例えばハッシュアルゴリズムを用いることにより前記監視されるリソースレコードからリソースＩＤキーを計算することによって、可能とされてもよい。

前記監視ピアは、トリガデータベースに前記トリガ・リソースレコードを格納してもよい。すると、前記監視されるリソースレコードに影響を与える何らかのイベントが発生した際に、前記監視ピアは、当該イベント及び監視されるレコードについての前記トリガ・レコードリソースを検索するために、前記トリガデータベースの内容を確認する。この組み合わせについてのトリガ・リソースレコードが存在する場合、前記特定されたアクションが実行される。

この方法により監視されうる典型的なイベントは、前記監視されるリソースレコードの生成と、前記監視されるリソースレコードの除去と、前記監視されるリソースレコードの更新と、前記監視されるリソースレコードを読み込む試みと、前記監視されるリソースレコードに関連付けられたカウンタが閾値に到達することと、前記監視されるリソースレコードが達しようとしている期限切れまでの所定の時間間隔と、を含みうる。前記特定されたアクションは、前記イベントが起こったことの通知を前記ユーザピアに送信することと、前記イベントが起こったことの通知を前記監視されるリソースレコードのオーナへと送信することと、前記監視されるリソースレコードを削除することと、前記トリガ・リソースレコードに含まれるカウンタをインクリメント又はデクリメントすることと、前記監視されるリソースレコードへのアクセスを許可し又は制限することと、のうちの少なくとも１つを含んでもよい。

１つの実施形態において、前記イベントは前記監視されるリソースレコードの生成である。この場合、前記トリガ・リソースレコードが前記ＤＨＴに挿入される時に前記監視されるリソースレコードはまだ存在しない。前記監視されるリソースレコードについてのリソース識別子が予測されて、このリソース識別子は前記監視ピアを識別するために用いられる。

前記監視されるリソースレコードは第２のユーザの連絡先情報であってもよく、前記監視されるリソースレコードの生成は前記第２のユーザがオンラインになる結果として起こってもよい。このように、トリガレコードはプレゼンスサービスを提供するために用いられてもよい。あるいは、前記監視されるリソースレコードは、サービスと関連付けられたサービス・リソースレコードであってもよく、前記監視されるリソースレコードの生成は、前記サービスが利用可能になる結果として起こってもよい。

どちらの場合であっても、前記監視されるリソースレコードが存在するか否かを識別するために前記ユーザピアによってルックアップ要求が最初に送信されてもよい。前記ルックアップ要求は、前記監視されるリソースレコードが存在しないことが識別された場合に前記ＤＨＴへと前記トリガ・リソースレコードを挿入する命令を含んでもよい。

前記トリガ・リソースレコードは既存の監視されるリソースレコードに関連付けられてもよい。１つの実施形態において、前記イベントは、第三者ピアによる、前記監視されるリソースレコードへのアクセスを得ようとする試みであってもよい。前記トリガ・リソースレコードは、前記監視されるリソースレコードに対するアクセスが許可されるピアのホワイトリストと、前記監視されるリソースレコードに対するアクセスが許可されないピアのブラックリストと、のうちの少なくとも一方を含んでもよい。前記特定されたアクションは、前記第三者ピアが前記ホワイトリスト又は前記ブラックリストにあるか否かに基づいて、前記監視されるリソースレコードへのアクセスを許可するか又は制限することを含んでもよい。前記トリガ・リソースレコードは、前記ブラックリスト上のピアについてアクセスが制限されるアクセス制限理由を含んでもよい。

ホワイトリストとブラックリストとの少なくとも一方の使用は、電話付加サービスの用意を可能とする。例えば、前記アクセス制限理由が、前記監視されるリソースレコードへの着信呼がリダイレクトされるべきであることである場合、呼転送が実現されうる。前記特定されたアクションは、前記第三者ピアへのアクセスを制限することと、アクセスが試みられるべき代わりのリソースレコードの識別表示を前記第三者ピアへと提供することと、を含んでもよい。前記アクセス制限理由が、前記ユーザピアがビジーであることであり、前記特定されたアクションが、前記第三者ピアとのアクセスを制限することと、前記ユーザピアがビジーであることを前記第三者ピアに通知することとを含む場合に、ビジーな加入者への呼着信が実現されうる。この場合、前記第三者ピアは、前記トリガ・リソースレコードが除去された場合に前記監視されるリソースレコードへのアクセスを得るさらなる試みがなされうるように、前記トリガ・リソースレコードを監視するために前記ＤＨＴにさらなるトリガ・リソースレコードを挿入してもよい。

前記トリガ・リソースレコード内の情報は、前記トリガ・リソースレコードを識別するトリガＩＤと、前記監視されるリソースレコードを識別するモニタードＩＤと、監視されているイベントの型を識別するイベントＩＤと、前記イベントの発生の際に行われる前記特定されたアクションを識別するトリガ・アクションＩＤと、前記ユーザピアを識別するインサーティング・ピアＩＤと、を含んでもよい。

本発明はまた、上述の方法を実行するように構成されたピアを含むＰ２Ｐネットワークを提供する。

本発明のもう１つの態様に従って、ＤＨＴを有するＰ２Ｐネットワークで用いられるユーザピアが提供される。ユーザピアは、監視されるイベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードと、前記監視されるイベントが関連付けられ又は関連付けられるであろう、監視されるリソースレコードの識別表示とを生成するプロセッサを備える。ユーザピアはまた、前記監視されるリソースレコードを管理する責任がある監視ピアにおいて前記トリガ・リソースレコードが管理されるように前記ＤＨＴに挿入するために、前記トリガ・リソースレコードを前記Ｐ２Ｐネットワークへと送信する送信機を備える。

本発明のもう１つの態様に従って、ＤＨＴを有するＰ２Ｐネットワークで用いられる監視ピアが提供される。監視ピアは、監視されるリソースレコードを管理する格納機能を備える。前記監視されるリソースレコードと関連付けられたイベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードを、ユーザピアから受信する受信機が備えられる。前記特定されたアクションを実行するプロセッサが備えられる。監視ピアもまた、前記トリガ・リソースレコードを、オプションとしてトリガデータベース中で、管理するように構成される。

「ユーザピア」及び「監視ピア」との用語は、便利にする目的で用いられるラベルであって、１つのピアが双方の機能を同時に実行できてもよいことが、理解されるだろう。

リングトポロジにおけるノードを示す概略図である。ＤＨＴへのトリガの挿入を示す流れ図である。プレゼンスサービスを実装するためのＤＨＴトリガの使用を示す流れ図である。ピアの構成を示す概略図である。

ＤＨＴトリガ
ＤＨＴトリガは、スタンドアロンな方式で、又は既存のリソースレコードに付加することにより、ＤＨＴベースのオーバレイネットワークに格納されることができる、特別なリソースレコードの形をとる。１つ目のケースにおいてトリガは、どんなリソースレコードにも付加されないので、スタンドアロン・トリガと呼ばれる。２つ目のケースにおいてトリガは、付加トリガ(attached trigger)と呼ばれる。スタンドアロン・トリガ及び付加トリガが、以下でさらに説明される。

オーバレイネットワークにおけるピア間で使われるプロトコルは、ピアプロトコルと呼ばれる。ピア・ツー・ピア・セッション開始プロトコル（Ｐ２ＰＳＩＰ）システムにおいては、リソース・ロケーション・アンド・ディスカバリ（ＲＥＬＯＡＤ）プロトコルがピアプロトコルとして用いられる。トリガレコードは、本明細書においてインサートトリガ(InsertTrigger)メッセージと呼ばれる、新しいピアプロトコル・メッセージを用いて生成される。ＤＨＴトリガは、オーバレイネットワークで起こっているイベントにサブスクライブするために用いられることができる。イベントが起こるとき、トリガレコードで指定されたアクションが実行される。１つのありうるアクションは、通知要求の生成である。このような通知は、本明細書においてトリガ・アクション(TriggerAction)メッセージと呼ばれる、新しいピアプロトコル・メッセージを用いて送信される。

トリガイベント
上述のようにＤＨＴトリガは、Ｐ２Ｐオーバレイネットワークで起こっている様々なイベントへとサブスクライブするために用いられることができる。このようなイベントの例が、表１に列挙されている。

トリガ・アクション
それぞれのトリガは、ユーザがトリガを挿入することによってサブスクライブしたイベントが発生した時に行われるべきアクションを特定する。イベントが起こる時、トリガで指定されたアクションが行われる。ありうるアクションは、たとえば表２に明記されているものを含む。

スタンドアロン・トリガ
スタンドアロン・トリガは、ユーザが関心のあるリソースレコードがまだ存在していない時、このことは特定されたリソースＩＤのリソースレコードをオーバレイに誰も格納していないことを意味するが、この時に用いられる。この場合、ユーザが関心のあるイベントは、リソースレコードの生成である。スタンドアロン・トリガは、トリガが関連するリソースのリソースＩＤを用いて格納される。例えば、もしリソースがユーザであるアリスの連絡先情報であり、アリスのＳＩＰＵＲＩが"sip:alice@example.com"であるならば、トリガはアリスの連絡先レコードのリソースＩＤを用いて格納される。このリソースＩＤは、オーバレイアルゴリズムによって規定されるハッシュアルゴリズムを用いてアリスのＳＩＰＵＲＩに対してハッシュを計算することによって得られうる。

トリガは、関連付けられているレコードのリソースＩＤを用いて格納されるので、このレコードを管理する責任のあるピアによって格納されるだろう。これは、典型的なピア４１の構成の概略図である図４を参照して理解することができる。ピア４１は、（トリガレコードのような）情報をネットワークへと送信するための送信機４２と、ネットワークから情報を受け取るための受信機４３とを含む。プロセッサ４４は、トリガレコードを生成することと、トリガレコードで特定されたアクションを実行することとの少なくとも一方が可能である。レコードは格納媒体４５によって格納され、格納媒体の一部が専用のトリガデータベース４６であってもよい。

上の例に戻って図１に示されるリングトポロジをまた考慮し、ユーザピア１０１がアリスがオンラインになったときに通知されることを望んでいると仮定する。アリスの連絡先レコードについてのリソースＩＤが計算され、これはネットワークにおいてどのピア（例えば、ユーザピア１０１によってフィンガとして管理されるピア１１２）が、アリスがオンラインになった時にアリスの連絡先レコードを管理する責任があるかを示すだろう。ピア１１２がアリスの連絡先レコードについて責任があるので、ピア１１２は自分のトリガデータベース４６にこのトリガをまた格納する。

この処理はまた図２に示される。ステップＳ２１において、ユーザピア１０１はトリガレコードを生成する。ステップＳ２２において、このトリガはＤＨＴに挿入される。ステップＳ２３において、トリガが関連付けられている（又は関連付けられるであろう）リソースが特定される。上の例では、このリソースはアリスの連絡先レコードである。ステップＳ２４において、このリソースのリソースＩＤが判定される。ステップＳ２５において、このリソースＩＤは、どのピア（例えばフィンガ１０１）がこのリソースを管理する責任があるのかを判定する。ステップＳ２６において、このトリガはこのピアに格納される。

ピアがリソースレコードを格納するように要求された時にはいつでも、このピアはまずこのリソースのリソースＩＤで格納されている何らかのスタンドアロン・トリガが存在するか否かを確認する。もしトリガが存在するならば、それらのトリガ・アクションが実行される。このように、上の例において、ピア１１２がアリスの連絡先レコードを格納するように要求されるとすぐに、ピア１１２は自身のトリガデータベースを確認し、ユーザピア１０１によって挿入されたトリガを発見する。ピア１１２はするとトリガに含まれているアクションを実行し、これはユーザピア１０１にアリスがオンラインになったことを通知するものである。

スタンドアロン・トリガは、２つの方法で生成されることができる。１つの手法においては、インサートトリガ(InsertTrigger)要求が、送信者が興味のあるリソースＩＤについて責任があるピアへと送られることができる。もう１つの手法においては、ルックアップを行っているピアは、ピアプロトコルのルックアップ(Lookup)要求において、特定されたリソースＩＤを有するリソースレコードが存在しない場合、トリガが自動的に生成されるべきであることを特定することができる。このために、新しいフラグである、クリエイト・トリガ・イフ・リソース・ノット・ファウンド(createTriggerIfResoureNotFound)がルックアップ(Lookup)リクエストにおいて用いられることができる。

付加トリガ
付加トリガは、既存のリソースレコードについて生成されたトリガである。付加トリガは、リソースレコードに対して追加のサービスロジックを追加するために用いられることができる。例として、
・ユーザは、自分の連絡先レコードに、この連絡先レコードが期限切れになろうとしている時に、この連絡先レコードを格納する責任があるピアにこのユーザに通知するように伝えるトリガを、付加することができる。
・ユーザは、特定のリソースレコードを格納する責任があるピアに、このリソースレコードが更新され又は削除された時にはいつでも、このユーザに通知するように伝えるトリガを、付加することができる。このリソースレコードが連絡先レコードであるならば、この連絡先レコードと関連付けられた連絡先アドレスが変更されたどんな時でも知ることができるように、ユーザはトリガを挿入してもよい。

付加トリガには異なる型がある。
・レギュラー(Regular)−他の種類によって拡張される標準的なトリガ。
・カウンタ(Counter)−トリガイベントが起こった回数を記録する能力でレギュラートリガを拡張する。
・アクセス制御(Access-control)−どのピアがリソースレコードにアクセスすることを許されており、どのピアがそうではないのかを特定するアクセス制御リストでレギュラートリガを拡張する。

複数のピアが同じリソースにトリガを付加する
多くの場合に、同じリソースにトリガを付加することに複数のピアが興味がある。このことは例えば、複数のピアが同じユーザを仲間として有し、このユーザがオーバレイに自分の連絡先情報を格納した時を知りたい時に起こりうる。このことをサポートするためにピアは、責任があるトリガをトリガデータベースに格納すべきである。トリガデータベースに対するキーは、トリガが生成されたリソースのリソースＩＤである。特定のリソースが生成され、アクセスされ、修正され、又は削除された時にはいつでも、このリソースについて責任があるピアは、トリガデータベースがそのリソースのリソースＩＤに関連する何らかのトリガレコードを格納しているか否かを確認し、これを処理すべきである。

トリガレコードの移動
新しいピアが参加し古いピアが去る際に、通常のリソースレコードが移動されるのと全く同じやり方で、トリガレコードはオーバレイネットワーク内のピア間で移動される必要がある。特定の時にピアが所定のリソースレコードを格納する責任があるという事実は、ＤＨＴアルゴリズムによって規定される。トリガが生成されたリソースＩＤが所属する識別子空間の一部についてオーバレイネットワークに参加する新しいピアが責任があるようになった時にはいつでも、又はリソースＩＤについて現在責任のあるピアがネットワークを去る時に、スタンドアロン・トリガは移動される。付加トリガは、トリガが付加されているリソースレコードが移動された時にはいつでも、移動される。

トリガのフォーマット
トリガレコードは、表３に明記されている情報ピースからなる。

表３に列挙されているフィールドに加えて、カウンタ(counter)型の付加トリガは、表４に明記されている追加のフィールドを有する。

表３に列挙されているフィールドに加えて、アクセス・コントロール(access-control)トリガは、表５に明記されているさらなるフィールドを有する。

プレゼンスサービスを実装するためのＤＨＴトリガの使用
Ｐ２Ｐプレゼンスシステムにおいては、仲間が自分の連絡先情報をオーバレイに格納する時（すなわちオンラインになった時）を発見するために、ユーザはオフラインである自分の仲間を定期的にポーリングする必要がある。それぞれのオフラインの仲間の各々のオフラインの仲間のステータスをポーリングする代わりに、ユーザは、自分の仲間の連絡先レコードのリソースＩＤについてのスタンドアロンＤＨＴトリガを格納することができる。このトリガのおかげで、仲間がオーバレイに参加して自分の連絡先レコードを格納するとすぐに、ユーザは通知を受ける。上述のように、仲間のＳＩＰＵＲＩに対してハッシュを計算することによって、ユーザは仲間の連絡先情報のリソースＩＤを構築することができる。

一例として、ＳＩＰＵＲＩがsip:bob@example.comであるボブがＰ２Ｐオーバレイに参加した時を知ることを望む場合、アリスは以下の値をフィールドに含むトリガをオーバレイへと挿入するだろう。
・トリガ・タイプ(Trigger-type)：レギュラー(regular)
・トリガＩＤ(Trigger-ID)：トリガを格納するピアによって設定される
・モニタードＩＤ(Monitord-ID)：hash(sip:bob@example.com)
・トリガ・アクション(Trigger action)：ノーティファイ・ミー(notify me)
・イベント(Event)：クリエイテッド(created)
・インサーティング・ピアＩＤ(Inserting-peer-ID)：アリスのエンドポイントのピアＩＤ

ボブの連絡先レコードはまたオーバレイに存在しないため、アリスが挿入するトリガはスタンドアロン・トリガとなるだろう。このトリガは、モニタードＩＤについて現在責任のあるピアに格納されるだろう。

このことは、図３を参照して知ることができる。アリスは、ＤＨＴへとトリガを挿入する（Ｓ３１）。ボブの連絡先レコードについてのリソースＩＤが判定され（Ｓ３２）、ボブの連絡先レコードを管理する責任があるピアを判定するために用いられる（Ｓ３３）。トリガはそのピアのトリガデータベースに格納される（Ｓ３４）。ボブがオンラインとなった時（Ｓ３５）、トリガはこのデータベースから取得され（Ｓ３６）、そこに特定されているアクション−ボブが今オンラインであることをアリスに通知すること−が実行される（Ｓ３７）。

アクセス制御を実装するためのＤＨＴトリガの使用
アクセス・コントロール(access-control)型の付加トリガは、特定のリソースレコードにアクセスすることをどのピアが許されているか（ホワイトリスト）、又はこのリソースレコードにアクセスする権利をどのピアが有していないか（ブラックリスト）を特定するために用いられることができる。この場合、トリガレコードに特定されるアクションは、バリデート・ピア(validate-peer)である（表２を参照）。ピアプロトコルのルックアップ(Lookup)要求を送信することによりリソースレコードにアクセスしようとしているピアが、そのようにする権利を有さない場合、ルックアップ(Lookup)要求は拒絶される。
例えば、アリスの連絡先情報へのピア群からのアクセスをアリスが拒否したい場合、アリスは以下のような内容を有するアクセス・コントロール・トリガを生成するだろう。
・トリガ・タイプ(Trigger-type)：アクセス・コントロール(access-control)
・トリガＩＤ(Trigger-ID)：トリガを格納するピアによって設定される
・モニタードＩＤ(Monitored-ID)：hash(sip:alice@example.com)
・トリガ・アクション(Trigger action)：バリデート・ピア(validate-peer)
・イベント(Event)：リソース・リード(resource-read)
・インサーティング・ピアＩＤ(Inserting-peer-ID)：アリスのエンドポイントのピアＩＤ
・リスト・タイプ(List-type)：ブラックリスト(blacklist)
・リスト(List)：ブラックリストに載せられたピアＩＤ群
・アクセス・リストリクテッド・リーズン(Access-restricted-reason)：ノー・ライト(no-rights)
・オルタナティブ・リソースＩＤ(Alternative-resource-ID)：エンプティ(empty)

ＤＨＴトリガ及びカウンタ
カウンタ(counter)型の付加トリガは、イベントカウンタをリソースレコードに関連付けるために用いられうる。ユーザは例えば、オーバレイに格納した画像が何回見られたかに興味があるかもしれない。例えば、アリスがオーバレイに画像を格納しており、この画像のリソースレコードにカウンタを関連付けたいものと仮定する。カウンタの初期値はゼロであり、カウンタはこの画像のリソースレコードが取得されるたびにインクリメントされるべきである。アリスがこの画像のリソースレコードに付加するトリガが以下に示される。
・トリガ・タイプ(Trigger-type)：カウンタ(counter)
・トリガＩＤ：トリガを格納するピアによって設定される
・モニタードＩＤ(Monitored-ID)：画像のリソースＩＤ
・トリガ・アクション(Trigger-action)：インクリメント・カウンタ(increment-counter)
・イベント(Event)：リソース・リード(resource-read)
・インサーティング・ピアＩＤ(Inserting-peer-ID)：アリスのエンドポイントのピアＩＤ
・カウンタ(Counter)：０
・カウンタ・スレショルド(Counter-threshold)：１０

アリスはまた、カウンタの値が１０（上記のように、カウンタ・スレショルド(counter-threshold)フィールドで特定されている）に到達した時に、通知を受け取ることに興味がある。この場合、アリスはもう１つのトリガを生成する。この第２のトリガは、トリガ・アクション(trigger-action)をノーティファイ・ミー(notify-me)に、イベントをカウンタ・スレショルド・リーチド(counter-thereshold-reached)に特定する、レギュラートリガである。この第２のトリガは、このトリガのリソースＩＤフィールドを第１のレコードのトリガＩＤを含むように設定することにより、第１のトリガに付加される。カウンタ・スレショルド・リーチド(counter-threshold-reached)イベントを監視するトリガはリソースレコードに付加されることはできず、型がカウンタ(counter)である他のトリガレコードにのみ付加されることに留意する。アリスが格納する２つめのトリガは、以下のように見える。
・トリガ・タイプ(Trigger-type)：レギュラー(regular)
・トリガＩＤ(Trigger-ID)：トリガを格納するピアによって設定される
・モニタードＩＤ(Monitored-ID)：第１のトリガのトリガＩＤ
・トリガ・アクション(Trigger-action)：ノーティファイ・ミー(notify-me)
・イベント(Event)：カウンタ・スレショルド・リーチド(counter-threshold-reached)
・インサーティング・ピアＩＤ(Inserting-peer-ID)：アリスのエンドポイントのピアＩＤ

トリガ及びサービス発見
Ｐ２Ｐオーバレイに参加しているピアは、互いにサービスを提供することができる。ピアが互いに提供することができるサービスの１つの例は、ＴＵＲＮ（トラバーサル・ユージング・リレーズ・アラウンド・ネットワーク・アドレス・トランスレーション）リレーサービスである。ＴＵＲＮサービスを提供するピアは、オーバレイに、ＴＵＲＮサービスのサービスＩＤと共にリソースレコードを格納するか、又はもしＴＵＲＮサービスレコードが既に存在しているならば、既存のレコードへとその情報を追加する。もし他のピアが特定のサービス（例えばＴＵＲＮリレーサービス）に興味があるが、他のピアが現在サービスを提供していないならば、このサービスのサービスＩＤについてのスタンドアロン・トリガを生成するために、ＤＨＴトリガリング手法が用いられうる。こうして、トリガを挿入したユーザは、サービスが利用可能になった時に通知を得る。

トリガ及び電話付加サービス
電話付加サービスは、典型的には中央呼制御要素を必要とし、したがって分散Ｐ２Ｐオーバレイにおいて実装することは難しい。しかしながら、ＤＨＴトリガリング手法は、いくつかの付加サービスを分散された方法で提供する方法を提供する。以下では３つの付加サービス、すなわち着信呼制限、呼転送、及びビジーな加入者への呼接続が、例として用いられる。

着信呼制限
着信呼制限は、セクション０で説明されたアクセス制御手法を用いて実装されることができる。ピアのサブセット又は全てのピアからの着信呼をブロックするために、ユーザは自分の連絡先レコードについてアクセス制御トリガを生成することができる。
例えば、全ての着信呼をブロックするためには、トリガレコードのアクセス・コントロール・トリガ特有のフィールドは、以下のように設定されるべきである。
・リスト・タイプ(List-type)：ブラックリスト(blacklist)
・リスト(List)：*
・アクセス・リストリクテッド・リーズン(Access-restricted-reason)：ブロック(block)
・オルタナティブ・リソースＩＤ(Alternative-resource-ID)：エンプティ(empty)

呼転送
呼転送付加サービスは、アクセス・コントロール・トリガ特有のフィールドが以下の値を有するアクセス・コントロール・トリガを用いて実装することができる。
・タイプ(Type)：ブラックリスト(blacklist)
・リスト(List)：*
・アクセス・リストリクテッド・リーズン(Access-restricted-reason)：リダイレクト(redirect)
・オルタナティブ・リソースＩＤ(Alternative-resource-ID)：呼が転送されるべきエンドポイントの連絡先レコードのリソースＩＤ

ビジーな加入者への呼接続
ビジーな加入者への呼接続を作動させるためには、呼に関与するユーザは、自分の連絡先レコードについてのアクセス・コントロール・トリガを生成するべきである。アクセス・コントロール・トリガは、以下の情報を有するべきである。
・リスト・タイプ(List-type)：blacklist（ブラックリスト）
・リスト(List)：*
・アクセス・リストリクテッド・リーズン(Access-restricted-reason)：ビジー(busy)
・オルタナティブ・リソースＩＤ(Alternative-resource-ID)：エンプティ(empty)

電話をかける人がビジーなユーザの連絡先レコードを取得しようとする時、電話をかける人は、リジェクト・リーズン(reject-reason)フィールドが値としてビジー(busy)を有するエラー応答を受け取るだろう。ここで電話をかける人は、ビジーなユーザの連絡先レコードのアクセス・コントロール・トリガに、トリガを付加することができる。このトリガはレギュラートリガであり、以下の情報を有する。
・モニタードＩＤ(Monitored-ID)：アクセス・コントロール・トリガのトリガＩＤ
・トリガ・アクション(Trigger-action)：ノーティファイ・ミー(notify-me)
・イベント(Event)：リソース・リムーブド(resource-removed)
・インサーティング・ピアＩＤ(Inserting-peer-ID)：電話をかける人のピアＩＤ

電話をかける人がこのトリガを挿入したので、電話をかけられたユーザがアクセス・コントロール・トリガを除去した時に、電話をかける人は通知を受け取るだろう。このように電話をかける人は、電話をかけられたユーザがもはやビジーではない時（すなわち通話が終わった時）を知るだろう。

このように、上述のアプローチは、ＶｏＩＰ、プレゼンス、及びインスタントメッセージングのような個人間通信に用いられる時にＤＨＴベースのＰ２Ｐシステムが直面するいくつかの課題に取り組んでいることがわかる。特に、システムの分散された性質のために、Ｐ２Ｐオーバレイに参加しているエンドポイントは、クライアント・サーバ・システムにおいては中央サーバによって提供されるサービスの多くを提供する責任がある。Ｐ２Ｐ通信システムにおいては効率的に提供することが難しい機能の２つの例が、プレゼンス及び電話付加サービスであり、双方がトリガの使用により容易になることが理解されるだろう。

特に、分散プレゼンスサービスにおける１つの大きな課題が、オフラインの仲間がＰ２Ｐオーバレイネットワークに参加した時を検出するために必要なポーリングである。このことはネットワークにかなりの量の余分なトラフィックを引き起こし、それゆえその性能を低下させる。説明されたシステムの１つの利点は、このようなポーリングトラフィックを完全に削減する方法を提供することにある。

以前から知られているＰ２Ｐプレゼンスシステムの他の課題は、ユーザがシステムに参加してからユーザの仲間がこのことを検知するまでの間の遅延がかなりのものであることである。このことは当然、劣ったユーザ体験につながる。ポーリングトラフィックを削減することの他に、提案されたＤＨＴトリガリング手法はまた、この遅延を削減する。

Ｐ２Ｐプレゼンスを最適化することに加えて、ＤＨＴトリガリング手法はまた、従来の電話付加サービスをＰ２ＰＶｏＩＰシステムにおいて実装するために用いられうる。このようなサービスの例は、呼転送、ビジーな加入者への呼着信、及び呼制限を含む。このトリガリング手法はまた、Ｐ２Ｐオーバレイネットワークにおいてリソースレコードに対するアクセス制御サービスを実装する方法を提供する。さらにＤＨＴトリガは、Ｐ２Ｐオーバレイネットワークにおいてイベント計数サービス実装するために用いられうる。この手法はまた、ＤＨＴベースのオーバレイネットワークにおいて、サービス発見手法を改善するために用いられうる。

上に説明された実施形態からの変形例もまた、添付の請求の範囲によって規定される本発明の範囲に入ってもよいことが、理解されるだろう。

Claims

分散ハッシュテーブル（ＤＨＴ）を有するピア・ツー・ピア（Ｐ２Ｐ）ネットワークにおいてイベントを監視する方法であって、
ユーザピアが、イベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードをＤＨＴへと挿入する工程と、
前記イベントが関連付けられ又は関連付けられるであろう、監視されるリソースレコードを識別する工程と、
前記監視されるリソースレコードを管理する責任がある監視ピアを識別する工程と、
前記監視ピアにおいて前記トリガ・リソースレコードを管理する工程と、
を含むことを特徴とする方法。
前記イベントが、
前記監視されるリソースレコードの生成と、
前記監視されるリソースレコードの除去と、
前記監視されるリソースレコードの更新と、
前記監視されるリソースレコードを読み込む試みと、
前記監視されるリソースレコードに関連付けられたカウンタが閾値に到達することと、
前記監視されるリソースレコードが達しようとしている期限切れまでの所定の時間間隔と、
のうちの１以上を含むことを特徴とする、請求項１に記載の方法。
前記特定されたアクションは、
前記イベントが起こったことの通知を前記ユーザピアに送信することと、
前記イベントが起こったことの通知を前記監視されるリソースレコードのオーナへと送信することと、
前記監視されるリソースレコードを削除することと、
前記トリガ・リソースレコードに含まれるカウンタをインクリメント又はデクリメントすることと、
前記監視されるリソースレコードへのアクセスを許可し又は制限することと、
のうちの１以上を含むことを特徴とする、請求項１又は２に記載の方法。
前記監視ピアは、トリガデータベースに前記トリガ・リソースレコードを格納し、
前記監視されるリソースレコードに影響を与える何らかのイベントが発生した際に、前記監視ピアは、当該イベント及び監視されるレコードについての前記トリガ・レコードリソースを検索するために、前記トリガデータベースの内容を確認し、及び、
前記特定されたアクションが実行される
ことを特徴とする、請求項１乃至３の何れか１項に記載の方法。
前記監視ピアの前記識別を可能とするために、リソースＩＤキーが、ハッシュアルゴリズムを用いて前記監視されるリソースレコードから計算されることを特徴とする、請求項１乃至４の何れか１項に記載の方法。
前記トリガ・リソースレコードが前記ＤＨＴに挿入される時に前記監視されるリソースレコードはまだ存在せず、
前記監視されるリソースレコードについてのリソース識別子が予測されて、前記監視ピアを識別するために用いられ、及び、
前記イベントは前記監視されるリソースレコードの生成である
ことを特徴とする、請求項１乃至５の何れか１項に記載の方法。
前記監視されるリソースレコードは第２のユーザの連絡先情報であり、前記監視されるリソースレコードの生成は前記第２のユーザがオンラインになる結果として起こることを特徴とする、請求項６に記載の方法。
前記監視されるリソースレコードは、サービスと関連付けられたサービス・リソースレコードであり、前記監視されるリソースレコードの生成は、前記サービスが利用可能になる結果として起こることを特徴とする、請求項６に記載の方法。
前記監視されるリソースレコードが存在するか否かを識別するために前記ユーザピアによってルックアップ要求が送信され、
前記ルックアップ要求は、前記監視されるリソースレコードが存在しないことが識別された場合に前記ＤＨＴへと前記トリガ・リソースレコードを挿入する命令を含む
ことを特徴とする、請求項６乃至８の何れか１項に記載の方法。
前記トリガ・リソースレコードは既存の監視されるリソースレコードに関連付けられることを特徴とする、請求項１乃至５の何れか１項に記載の方法。
前記イベントは、第三者ピアによる、前記監視されるリソースレコードへのアクセスを得ようとする試みであり、
前記トリガ・リソースレコードは、前記監視されるリソースレコードに対するアクセスが許可されるピアのホワイトリストと、前記監視されるリソースレコードに対するアクセスが許可されないピアのブラックリストと、のうちの少なくとも一方を含み、
前記特定されたアクションは、前記第三者ピアが前記ホワイトリスト又は前記ブラックリストにあるか否かに基づいて、前記監視されるリソースレコードへのアクセスを許可するか又は制限することを含む
ことを特徴とする、請求項１０に記載の方法。
前記トリガ・リソースレコードは、前記ブラックリスト上のピアについてアクセスが制限されるアクセス制限理由を含むことを特徴とする、請求項１１に記載の方法。
前記アクセス制限理由は、前記監視されるリソースレコードへの着信呼がリダイレクトされるべきであることであり、前記特定されたアクションは、前記第三者ピアへのアクセスを制限することと、アクセスが試みられるべき代わりのリソースレコードの識別表示を前記第三者ピアへと提供することと、を含むことを特徴とする、請求項１２に記載の方法。
前記アクセス制限理由は、前記ユーザピアがビジーであることであり、前記特定されたアクションは、前記第三者ピアとのアクセスを制限することと、前記ユーザピアがビジーであることを前記第三者ピアに通知することとを含むことを特徴とする、請求項１２に記載の方法。
前記第三者ピアは、前記トリガ・リソースレコードが除去された場合に前記監視されるリソースレコードへのアクセスを得るさらなる試みがなされるように、前記トリガ・リソースレコードを監視するために前記ＤＨＴにさらなるトリガ・リソースレコードを挿入することを特徴とする、請求項１４に記載の方法。
前記トリガ・リソースレコード内の情報は、
前記トリガ・リソースレコードを識別するトリガＩＤと、
前記監視されるリソースレコードを識別するモニタードＩＤと、
監視されているイベントの型を識別するイベントＩＤと、
前記イベントの発生の際に行われる前記特定されたアクションを識別するトリガ・アクションＩＤと、
前記ユーザピアを識別するインサーティング・ピアＩＤと、
を含むことを特徴とする、請求項１乃至１５の何れか１項に記載の方法。
請求項１乃至１６の何れか１項に記載の方法を実行するように構成されたピアを含むＰ２Ｐネットワーク。
分散ハッシュテーブル（ＤＨＴ）を有するピア・ツー・ピア（Ｐ２Ｐ）ネットワークで用いられるユーザピアであって、
監視されるイベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードと、前記監視されるイベントが関連付けられ又は関連付けられるであろう、監視されるリソースレコードの識別表示とを生成するプロセッサと、
前記監視されるリソースレコードを管理する責任がある監視ピアにおいて前記トリガ・リソースレコードが管理されるように前記ＤＨＴに挿入するために、前記トリガ・リソースレコードを前記Ｐ２Ｐネットワークへと送信する送信機と、
を備えることを特徴とするユーザピア。
前記監視されるイベントが、
前記監視されるリソースレコードの生成と、
前記監視されるリソースレコードの除去と、
前記監視されるリソースレコードの更新と、
前記監視されるリソースレコードを読み込む試みと、
前記監視されるリソースレコードに関連付けられたカウンタが閾値に到達することと、
前記監視されるリソースレコードが達しようとしている期限切れまでの所定の時間間隔と、
のうちの１以上を含むことを特徴とする、請求項１８に記載のユーザピア。
前記特定されたアクションは、
前記イベントが起こったことの通知を前記ユーザピアに送信することと、
前記イベントが起こったことの通知を前記監視されるリソースレコードのオーナへと送信することと、
前記監視されるリソースレコードを削除することと、
前記トリガ・リソースレコードに含まれるカウンタをインクリメント又はデクリメントすることと、
前記監視されるリソースレコードへのアクセスを許可し又は制限することと、
のうちの１以上を含むことを特徴とする、請求項１８又は１９に記載のユーザピア。
前記監視されるリソースレコードはまだ存在せず、
前記ユーザピアは、前記監視ピアを識別することを可能とするように、前記監視されるリソースレコードについてのリソース識別子を予測するように構成され、
前記イベントは前記監視されるリソースレコードの生成である
ことを特徴とする、請求項１８乃至２０の何れか１項に記載のユーザピア。
前記監視されるリソースレコードが存在するか否かを識別するためにルックアップ要求を送信するように構成され、
前記ルックアップ要求は、前記監視されるリソースレコードが存在しないことが識別された場合に前記ＤＨＴへと前記トリガ・リソースレコードを挿入する命令を含む
ことを特徴とする、請求項２１に記載のユーザピア。
前記監視されるイベントは、第三者ピアによる、前記監視されるリソースレコードへのアクセスを得ようとする試みであり、
前記トリガ・リソースレコードは、前記監視されるリソースレコードに対するアクセスが許可されるピアのホワイトリストと、前記監視されるリソースレコードに対するアクセスが許可されないピアのブラックリストと、のうちの少なくとも一方を含み、
前記特定されたアクションは、前記第三者ピアが前記ホワイトリスト又は前記ブラックリストにあるか否かに基づいて、前記監視されるリソースレコードへのアクセスを許可するか又は制限することを含む
ことを特徴とする、請求項１８乃至２０の何れか１項に記載のユーザピア。
前記トリガ・リソースレコードは、前記ブラックリスト上のピアについてアクセスが制限されるアクセス制限理由を含むことを特徴とする、請求項２３に記載のユーザピア。
前記アクセス制限理由は、前記監視されるリソースレコードへの着信呼がリダイレクトされるべきであることであり、前記特定されたアクションは、前記第三者ピアへのアクセスを制限することと、アクセスが試みられるべき代わりのリソースレコードの識別表示を前記第三者ピアへと提供することと、を含むことを特徴とする、請求項２４に記載のユーザピア。
前記アクセス制限理由は、前記ユーザピアがビジーであることであり、前記特定されたアクションは、前記第三者ピアとのアクセスを制限することと、前記ユーザピアがビジーであることを前記第三者ピアに通知することとを含むことを特徴とする、請求項２４に記載のユーザピア。
前記トリガ・リソースレコード内の情報は、
前記トリガ・リソースレコードを識別するトリガＩＤと、
前記監視されるリソースレコードを識別するモニタードＩＤと、
監視されているイベントの型を識別するイベントＩＤと、
前記イベントの発生の際に行われる前記特定されたアクションを識別するトリガ・アクションＩＤと、
前記ユーザピアを識別するインサーティング・ピアＩＤと、
を含むことを特徴とする、請求項１８乃至２６の何れか１項に記載のユーザピア。
分散ハッシュテーブル（ＤＨＴ）を有するピア・ツー・ピア（Ｐ２Ｐ）ネットワークにおいて用いられる監視ピアであって、
監視されるリソースレコードを管理する格納機能と、
前記監視されるリソースレコードと関連付けられたイベントの発生に際して特定されたアクションを実行させる命令を含むトリガ・リソースレコードを、ユーザピアから受信する受信機と、
前記特定されたアクションを実行するプロセッサと、
を備え、
前記トリガ・リソースレコードを管理するように構成されていることを特徴とする、監視ピア。
前記トリガ・レコードリソースが格納されるトリガデータベースを含み、
前記監視されるリソースレコードに影響を与える何らかのイベントが発生した際に、当該イベント及び監視されるレコードについての前記トリガ・レコードリソースを検索するために、前記トリガデータベースの内容を確認し、及び、前記特定されたアクションが実行されるように構成されている
ことを特徴とする、請求項２８に記載の監視ピア。