JXTA総まとめ P2P特論 最終回 / 2005-07-13 1 JXTAの基本コンセプト 2 JXTAとオーバレイ・ネットワーク D・E・Fは、物理ネット ワークを超えて、（仮想 的に）P2Pネットワークに 参加している。 この仮想的なネットワー クを「オーバレイ・ネット ワーク」と言う。 JXTAを利用して、オーバ レイ・ネットワークを構築 できる。 3 Peer Peer = ネットワーク 上のデバイス PC, Work station, PDA, 携帯電話など 4 Peer Group Peer は Peer Group に参加できる ひとつの Peer は複数 の Peer Group に参 加できる Peer Group が P2Pの サービスに相当する 例えばファイル共有や メッセンジャーなど 5 Pipe Peer 間でのメッセージ の送受信に使用する。 input pipe (入力パイ プ) と output pipe (出 力パイプ) がある。 Unix のパイプ (“|”) と 考え方は同じ。 6 ID JXTAで使われる資源には、IDが振られる。 資源 = Peer, Peer Group, Pipe など Peer の ID の例: urn:jxta:uuid59616261646162614A78746150325033 88D9B1D1048B4CE99A7CB17A2CB3E5F 703 7 Advertisements (告知) Peer, Peer Group, Pipe などの資源につい て記述したもの。メタデータ。 JXTAでの資源の発見 = Advertisement の発見 Advertisement は XML で書かれる。 8 Advertisements (告知) パイプ告知の例 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jxta:PipeAdvertisement> <jxta:PipeAdvertisement xmlns:jxta="http://jxta.org"> <Id> urn:jxta:uuid59616261646162614E504720503250330937A65BF6C641 0E923799B39ED9B20C04 </Id> <Type>JxtaUnicast</Type> <Name>mypipe</Name> </jxta:PipeAdvertisement> 9 パイプ告知を 用いた通信 10 Peerの種類 (1) Edge Peer (エッジ・ピア) RendezVous Peer (ランデブー・ピア) 平民。通信を行う。 Advertisement のインデックスを管理。 他のPeerからの問い合わせに対応する。 Relay Peer (リレー・ピア) ファイアウォールやNATをまたいで通信する。 11 Peerの種類 (2) Edge Peer と RendezVous Peer は固定的 な役割ではない。 Edge Peer が RendezVous Peer に。 また、RendezVous が Edge に。 ある Peer Group では RendezVous でも、 別の Peer Group では Edge の場合があ る。 12 JXTAでの検索と RendezVous Peer 13 JXTAでの検索 基本的に Advertisement を探索する 必要な Advertisement をいかにして探す か？ 14 JXTA 1.0 での検索 PeerGroup 内のすべての Peer へのブ ロードキャスト 「フラッディング (flooding)」 水浸しにする、という意味 トラフィックが大きくなる ネットワークやPeerへの負荷が大きい 15 JXTA 2.0 での検索 SRDI を用いる Shared Resource Distributed Index の採用 フラッディングは用いないので、基本的に パフォーマンスが向上する 16 JXTAのネットワーク ひとつの RendezVous Peer に 複数の Edge Peer が ぶらさがっている。 RendezVous Peer 同 士が接続されている。 17 RendezVous Peer (1) Edge Peer の機能をすべて持つ。 Advertisement のインデックスを管理。 Edge Peer からの要求に応じてインデック スを検索。 検索要求をほかの RendezVous Peer に 転送する。 他のPeerからの問い合わせに対応する。 18 RendezVous Peer (2) Edge Peer と RendezVous Peer は固定的 な役割ではない。 Edge Peer が RendezVous Peer になることが ある。 また、RendezVous が Edge に。 ある Peer Group では RendezVous でも、 別の Peer Group では Edge の場合があ る。 19 RendezVous Peer (3) RendezVous Peer では、Advertisement のハッシュ表（の一部）を管理する キーは Advertisement のハッシュ値 値は Advertisement を持っている Peer の ID つまり、RendezVous Peer で Advertisement 自体を保持している訳ではない 20 SRDI 21 SRDI とは Shared Resouce Distributed Index Advertisement のインデックスを分散管理 する方法 JXTA 2.0 から採用 22 ハッシュ表 「キー」と「値」がペアになっている データ構造 「キー」を元に「ハッシュ値」を作成 する キーの重複はない。 Java では、java.util.Map を実装し ている java.util.HashMap が該当 する 23 RendezVous Peer での Advertisement の管理 RendezVous Peer では、Advertisement のハッシュ表の一部を管理する キーは Advertisement のハッシュ値 値は Advertisement を持っている Peer の ID 24 DHT Distributed Hash Table = 分散ハッシュ テーブル ひとつのハッシュテーブルを分散して管理する ことで、負荷の集中をさける 実装はさまざま Chord, CAN, Pastry, Tapestry 25 SRDI ハッシュテーブルを分散して管理する 分散されたハッシュテーブルをきっちりと管 理するのではなく、 ゆるやかに管理して、 必要があれば探しにいく 26 JXTAでのadvertisement検索の シナリオ 27 RPV (1) RendezVous Peer View ある RendezVous Peer から見える RendezVous Peer 群。 Peer の ID でソートされ ている。 Peer ID は、物理ネット ワーク上の位置とは無関 係 28 パイプ告 知の公開 29 告知のインデックスを どこに格納するか？ (1) RendezVous Peer では、告知のイン デックス情報を管理 する 告知そのものを管 理するわけではない adv1 のインデック スを、R5で管理する とは限らない 30 告知のインデックスを どこに格納するか？ (2) RPV 中の R1 〜 R6 のどれかで インデックス情報を管理する R5では、SRDI の関数を用いて、 どこで adv1 のインデックス情報 を管理するか計算する 計算の結果、R2 に決まったとす る H(adv1) = R2 31 インデックス情報の格納 (1) R5 は R2 にイン デックス情報を管理 してもらう。 R2だけでなく、両隣 の R1 と R3 にも管 理してもらう。 32 インデック ス情報の 格納 (2) 33 インデックス情報の格納 (3) こうすることによっ て、ネットワークの 構成が変化しても、 告知が発見されや すくなる R2 が脱退した場合 など 34 インデックス情報の格納 (4) このようにして、すべての告知（のインデッ クス情報) は、RPV中のどこかの RendezVous Peer で管理される。 RPV 全体で、ひとつのハッシュ表を管理す る。 35 インデック ス情報の 格納 (5) 36 告知の 探索 37 R2の脱 退による 影響 (1) 38 R2の脱退による影響 (2) adv1 のインデックス 情報は、R2のほかに もR1, R3 で管理 R2 がいなくなっても、 もとのR3 (現R2) に よって adv1 を探し出 せる 39 RPVの 構成が 変化(1) 40 RPVの構成が変化(2) H(adv1) = R2 のとき、 R2にインデックス情報 が見つからなかった ら、”walk” が起こる。 up 方向と down 方向 がある。 最大ホップ数が決 まっている(はず)。 41 RPV (2) すべての RendezVous Peer が、 同じ RPV を持ってい なくてもよい。 図では R1のRPV と R4 の RPV が同じで はない。 42 RPV (3) R1とR4が同じRPVを 持つことを目指す でも、あまり頑張りす ぎない。 43
© Copyright 2024 ExpyDoc
