JXTA総まとめ P2P特論 最終回 / 2005-07-13

JXTAの基本コンセプト

JXTAとオーバレイ・ネットワーク D・E・Fは、物理ネットワークを超えて、（仮想的に）P2Pネットワークに参加している。 この仮想的なネットワークを「オーバレイ・ネットワーク」と言う。 JXTAを利用して、オーバレイ・ネットワークを構築できる。

Peer Peer = ネットワーク上のデバイス PC, Work station, PDA, 携帯電話など

Peer Group Peer は Peer Group に参加できる Peer Group が P2Pのサービスに相当する 例えばファイル共有やメッセンジャーなど

Pipe Peer 間でのメッセージの送受信に使用する。 input pipe (入力パイプ) と output pipe (出力パイプ) がある。 Unix のパイプ (“|”) と考え方は同じ。

ID JXTAで使われる資源には、IDが振られる。 資源 = Peer, Peer Group, Pipe など Peer の ID の例: urn:jxta:uuid-59616261646162614A7874615032503388D9B1D1048B4CE99A7CB17A2CB3E5F703

Advertisements (告知) Peer, Peer Group, Pipe などの資源について記述したもの。メタデータ。 JXTAでの資源の発見 = Advertisement の発見 Advertisement は XML で書かれる。

Advertisements (告知) パイプ告知の例 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jxta:PipeAdvertisement> <jxta:PipeAdvertisement xmlns:jxta="http://jxta.org"> <Id> urn:jxta:uuid-59616261646162614E504720503250330937A65BF6C6410E923799B39ED9B20C04 </Id> <Type>JxtaUnicast</Type> <Name>mypipe</Name> </jxta:PipeAdvertisement>

パイプ告知を用いた通信

Peerの種類 (1) Edge Peer (エッジ・ピア) RendezVous Peer (ランデブー・ピア) 平民。通信を行う。 RendezVous Peer (ランデブー・ピア) Advertisement のインデックスを管理。 他のPeerからの問い合わせに対応する。 Relay Peer (リレー・ピア) ファイアウォールやNATをまたいで通信する。

Peerの種類 (2) Edge Peer と RendezVous Peer は固定的な役割ではない。 また、RendezVous が Edge に。 ある Peer Group では RendezVous でも、別の Peer Group では Edge の場合がある。

JXTAでの検索と RendezVous Peer

JXTAでの検索 基本的に Advertisement を探索する 必要な Advertisement をいかにして探すか？

JXTA 1.0 での検索 PeerGroup 内のすべての Peer へのブロードキャスト 「フラッディング (flooding)」 水浸しにする、という意味 トラフィックが大きくなる ネットワークやPeerへの負荷が大きい

JXTA 2.0 での検索 SRDI を用いる フラッディングは用いないので、基本的にパフォーマンスが向上する Shared Resource Distributed Index の採用 フラッディングは用いないので、基本的にパフォーマンスが向上する

JXTAのネットワーク ひとつの RendezVous Peer に複数の Edge Peer がぶらさがっている。

RendezVous Peer (1) Edge Peer の機能をすべて持つ。 Advertisement のインデックスを管理。

RendezVous Peer (2) Edge Peer と RendezVous Peer は固定的な役割ではない。 また、RendezVous が Edge に。 ある Peer Group では RendezVous でも、別の Peer Group では Edge の場合がある。

RendezVous Peer (3) RendezVous Peer では、Advertisement のハッシュ表（の一部）を管理する 値は Advertisement を持っている Peer の ID つまり、RendezVous Peer で Advertisement 自体を保持している訳ではない

SRDI

SRDI とは Shared Resouce Distributed Index Advertisement のインデックスを分散管理する方法 JXTA 2.0 から採用

ハッシュ表 「キー」と「値」がペアになっているデータ構造 「キー」を元に「ハッシュ値」を作成する キーの重複はない。 Java では、java.util.Map を実装している java.util.HashMap が該当する

RendezVous Peer での Advertisement の管理 値は Advertisement を持っている Peer の ID

DHT Distributed Hash Table = 分散ハッシュテーブル 実装はさまざま ひとつのハッシュテーブルを分散して管理することで、負荷の集中をさける 実装はさまざま Chord, CAN, Pastry, Tapestry

SRDI ハッシュテーブルを分散して管理する 分散されたハッシュテーブルをきっちりと管理するのではなく、 ゆるやかに管理して、 必要があれば探しにいく

JXTAでのadvertisement検索の シナリオ

RPV (1) RendezVous Peer View ある RendezVous Peer から見える RendezVous Peer 群。 Peer の ID でソートされている。 Peer ID は、物理ネットワーク上の位置とは無関係

パイプ告知の公開

告知のインデックスを どこに格納するか？ (1) RendezVous Peer では、告知のインデックス情報を管理する 告知そのものを管理するわけではない adv1 のインデックスを、R5で管理するとは限らない

告知のインデックスを どこに格納するか？ (2) RPV 中の R1 〜 R6 のどれかでインデックス情報を管理する R5では、SRDI の関数を用いて、どこで adv1 のインデックス情報を管理するか計算する 計算の結果、R2 に決まったとする H(adv1) = R2

インデックス情報の格納 (1) R5 は R2 にインデックス情報を管理してもらう。 R2だけでなく、両隣の R1 と R3 にも管理してもらう。

インデックス情報の格納 (2)

インデックス情報の格納 (3) こうすることによって、ネットワークの構成が変化しても、告知が発見されやすくなる R2 が脱退した場合など

インデックス情報の格納 (4) このようにして、すべての告知（のインデックス情報) は、RPV中のどこかの RendezVous Peer で管理される。 RPV 全体で、ひとつのハッシュ表を管理する。

インデックス情報の格納 (5)

告知の 探索

R2の脱退による影響 (1)

R2の脱退による影響 (2) adv1 のインデックス情報は、R2のほかにもR1, R3 で管理 R2 がいなくなっても、もとのR3 (現R2) によって adv1 を探し出せる

RPVの構成が変化(1)

RPVの構成が変化(2) H(adv1) = R2 のとき、R2にインデックス情報が見つからなかったら、”walk” が起こる。 up 方向と down 方向がある。 最大ホップ数が決まっている(はず)。

RPV (2) すべての RendezVous Peer が、同じ RPV を持っていなくてもよい。 図では R1のRPV と R4 の RPV が同じではない。

RPV (3) R1とR4が同じRPVを持つことを目指す でも、あまり頑張りすぎない。