Peer-to-Peer Computing

Peer-to-Peer Computing
DEJAN S. MILOJICIC, VANA KALOGERAKI,
RAJAN LUKOSE, KIRAN NAGARAJA,
JIM PRUYNE, BRUNO RICHARD, SAMI
ROLLINS, and ZHICHEN XU
http://www.hpl.hp.com/techreports/2002/HPL-2002-57.pdf
Abstract
P2Pとは

分散して存在する資源を活用するシステムやアプリケーションの
一種
P2Pのメリット



中央点への依存の排除による規模性の向上
クライアントの直接通信によるコスト高なインフラの必要性の排
除
リソースの集約化
本論文はP2Pシステムとアプリケーションの重要事項と概
要について紹介


P2Pの詳細な概要やケーススタディを知らない人向け
代替手段との比較をしたい研究者、開発者等向け
1. INTRODUCTION
1. INTRODUCTION
P2Pはとても議論の余地のあるトピック


研究領域としてはまだ若い
そのため、このようなサーベイ論文が必要
本論文のゴール



何がP2Pで、何がP2Pでないか理解する
現在のP2Pの分析、具体例
今後のP2Pの可能性の分析
P2Pが可能にすること

価値のある外部性
 リソースを集合させることにより、全体で（単体では
出来なかった）素晴らしいことができる

低コスト、コスト共有
 既存のリソース、インフラの利用

匿名性・プライバシー
P2Pの問題

セキュリティ
P2Pが流行するきっかけ



Napsterで一躍有名に
分散協調手段として重要な技術に
P2Pを推進する会社が登場
 Intel, HP, Sony, Sun etc.

学会が登場
 International Workshop on P2P Computing etc.

大学のプロジェクトも登場
 Chord, OceanStore, PAST, CAN, FreeNet
P2Pの定義



システム間で直接コンピュータのリソースやサービス
を共有すること [p2pwg, 2001]
クライアントの限界無しに、インターネットに接続され
たデバイスを利用すること（？） [Veytsel, 2001]
3 keys requirements [Graham 2001]
 全てのノードはサーバの性質を持つ
 全てのノードはDNSから独立したアドレッシング
 全てのノードはあらゆる接続を共有する

独立した生存期間をもつシステム [Kindberg 2002]
著者の見識

P2Pとは
 P2P is about sharing. (resource, information)
 分散システム実装の一手段

Peerの定義：“ like each other”
 ある自律したpeerは他の自律したpeerに依存する
 peerは他のpeerを必ずしも信用できない
 規模や冗長性が必要
P2Pモデルについて


サーバ・クライアントの変
形として捉えられる
新しい考えではない
 UUCP, Switched networks
などの先駆けがあり
上から
1.
2.
3.
4.
マーケット
アプリケーション
テクノロジー
プラットフォーム
詳しい分類は2章で
P2Pの網羅すること





分散コンピューティング
コンテンツシェアリング
無線やハンドヘルドPCなどにおける通信の優位性
P2Pソフトウェアアーキテクチャ
P2Pアルゴリズム
P2Pでの新規性

Technology requirements
 スケール、アドホックな接続、セキュリティ

Architectural requirements
 多数のコンピュータでの動作を可能に
 新規システムなどでのスケーラビリティ
 プライバシーと匿名性

Economy requirements
 コスト
 利用の普及（品質保証か、ベストエフォートか）
P2Pの新規でない点









アプリケーション
スケーラビリティなどのための分散化
分散ステートマネージメント
非接続時の対応
分散スケジューリング
スケーラビリティ
アドホックネットワーク
E-Business
分散アルゴリズム
2. OVERVIEW
2. OVERVIEW
P2Pは他の単語と混同されやすい



Traditional distributed computing
Grid computing
Ad-Hoc Network
P2Pをより明確に定義するため、P2Pの
ゴール、単語、分類を紹介する
2.1. Goals
Cost sharing/reduction


集中型システムはコストが高い
P2Pはコストを各peerに分散できる
Improved scalability/reliability

信頼性のある中央サーバがいないので、
scalability/reliabilityを実現するアルゴリズムが必要
Resource aggregation and interoperability

多くのノードのリソースを集約することにより、多くの処
理が可能になる
Increased autonomy


分散システムのユーザは中央サーバに依ら
ず、自分達でなんとかしたい
ローカルにファイルをおきたい（Napsterなど）
 サーバのオペレータに見つからないため
Anonymity/privacy


クライアントサーバでは、クライアントのIPアド
レスでクライアントをある程度特定可能
P2Pではそのようなトラックが難しい
Dynamism

ノードの参加・離脱が動的
Enabling ad-hoc communication and
collaboration

既存のインフラに依らず、論理オーバレイを構
築可能
2.2. Terminology
Centralized systems

Single-unit solutions（スパコン、メインフレームなど）
Distributed Systems

ネットワークに接続した複数のコンポーネンツが、メッ
セージのみで協調するシステム
Client

要求を送るエンティティ（サーバ、プログラム、モジュー
ルなど）
Server

他のエンティティから要求を受け取るエンティティ
Client-Server model

Client と Serverのエンティティによって構成されるシ
ステム
Peer

システムにおいて、他のエンティティと似たようなエン
ティティ
P2P model


限られた通信で互いのpeerのリソース共有を可能と
する
通信制約のあるpeerの考慮、実インフラから独立した
naming、peerはserverの役割もかねる
Distributed computing


ネットワークに接続したコンピュータでタスクを共有す
るシステム [IEEE 1990]
Computing cluster, grids, global computing
systems
Grid computing


仮想の団体で、リソース共有や問題解決を図っていく
こと [Foster and Kesselmna 1999]
グローバルに計算リソースを共有するインフラ
Ad-hoc communication

固定されたインフラを持たないでコミュニケーションを
可能とするシステム
2.3. P2P Taxonomies
分類


Centralized Systems
Distributed Systems
Client-Server


Flat: 一つのサーバ、多くのクライアント。Webなど
Hierarchical: 複数の階層状のサーバ。DNSなど
Peer-to-Peer


Pure: 中央サーバなし。Gnutellaなど
Hybrid: 中央サーバあり。Napsterなど
 中央サーバはメタ情報（他のpeerの位置など）の伝達、セ
キュリティ目的（認証など）などを行う
P2Pシステムの分類

Platforms

JXTA, .NETなど
 Collaboration

Groove, Jabberなど
 Computing

SETI@HOME, Avakiなど
 File sharing

Napster, Gnutellaなど
P2Pアプリケーションの分類

Parallelizable
 Compute-intensive: peerごとのパラメータが違う
だけで、タスクは同じ。SETI＠HOMEなど
 Componentized: peerごとのタスクが異なる

Content and file management
 Napster, OpenCOLAなど

Collaborative
 IM、Distributed PowerPointなど
P2Pターゲット環境について


Internet, Intranet, Ad-hoc Networkなど
最も一般的なのが家庭のネットワーク
 コンテンツシェアリングによく利用される
 P2Pコンピューティングも流行った



SETI@HOMEなど
IntranetではDataSynapseなど
Ad-Hoc Networkはまだこれから
P2Pマーケットの分類

Consumer
 パーソナルユース
 コンテンツシェアリング、IM、ゲームなど

Enterprise
 バイオ、金融、B2Bなどの用途：DataSynapseなど

Public
 情報共有、デジタル著作権管理、エンターテイメント
Nethisingheによる分類

@work, @play, @rest
3. COMPONENTS AND
ALGORITHMS
この章では以下の事柄を紹介


P2Pシステムのコンポーネント
P2Pで用いられるアルゴリズム
3.1. Infrastructure Components
5つのレイヤに分けられる

必ずしも厳密ではない
Communication

P2Pは幅広い通信の枠組みを提供する
 Peerがデスクトップだったり、PDAだったり

Peerの幅広い種類や行動を克服するのが重要
 あるコンピュータが突然電源OFF
 ダイヤルアップが突然切れる
Group Management


他のpeerの発見、ルーティング
対象とするpeerに応じて最適なアルゴリズムを
 無線端末はAd-Hocで発見、デスクトップはindexサーバで発見

ロケーション・ルーティングアルゴリズムは、メッセージ伝播のパ
スを最適化するのが重要
 例えば遅延などを考慮
Robustness

セキュリティ
 ユーザにとって負担にしかならない
 処理を集中化させるのが一番楽な実現手段

リソース集約
 ファイル、CPU、帯域、電池、ディスクスペース等

信頼性
 冗長性を持たせる



タスク：失敗したら他のマシンで再開、同タスクを複数のマシンで実行
ファイル：複数のマシンで保存
メッセージ：もう一度再送、別のパスで再送
Class-Specific




Scheduling 数値計算などのスケジューリング
Meta-data：共有ファイルの属性情報として
Messaging：他のノードのやりとり
Management：P2Pインフラの管理
Application-Specific

P2Pインフラの上に実現される
 Tools, Applications, Services

コラボレーションソフトの場合、カレンダー、ノート、
メール、チャットなど
3.2. Algorithms
Centralized directory model





Napsterが代表的
コンテンツに関する情報を中央サーバが一括管理
Peerの要求に応じて中央サーバはコンテンツを保持
するpeerを検索、peerの位置を伝達
Peer同士がコンテンツを直接交換
スケーラビリティに難がある
Flooded requests model




Gnutellaが代表的
要求をP2Pネットワークにフラッディング、TTLは大抵５
～９に制限
Peerに広帯域が必要、あまりスケールしない
SuperPeerを導入して、スケーラビリィを改善するシス
テムもある
Document routing model


FreeNetが代表的
仕組み





ノードのID：ランダムな値
コンテンツ：コンテンツ自体orコンテンツ名のハッシュ値
コンテンツはもっともIDが近いPeerが保存
コンテンツをルーティングするとき、コピーを保存
特徴
 大きなコミュニティで効率的
 前もってコンテンツのIDを知る必要あり

検索が難しい
 リンクが途絶えた島ができる可能性あり
Document routing model

４つの主要なアルゴリズム
 Chord, CAN, Tapestry, Pastry

ゴール
 コンテンツまでのホップ数を減らす
 ルーティング情報を減らす

それぞれ得意・不得意あり
 CANはルーティングテーブルが小さい


Peer参加・離脱時のルーティングテーブル更新量が小さい
代わりにサーチのパスが長くなりがち
 Tapestry・Pastryはホップ数・遅延減を目指している
Chord




１次元の円形ID空間
Peer ID=hash(IP address)
logNのルーティングテーブルを保持
P2Pネットワークに参加する場合
 Gateway peerにコンタクト
 そのサクセッサにルーティング
CAN



多次元ID空間
各peerは隣の次元をトラック
P2Pネットワークに参加する場合
 一つのID空間を選択し、分割
 隣のpeerの情報を更新
Tapestry・Pastry


Plaxton構造を持つ
ID=hash(IP Address)
4. CHARACTERISTICS
P2Pの特性












Decentralization
Scalability
Anonymity
Self-organization
Cost of ownership
Ad-hoc connectivity
Performance
Security
Transparency
Usability
Fault resilience
interoperability
4.1. Decentralization
従来のクライアントサーバ
モデル


アクセス権やセキュリティ
の管理等に最適
非能率、ボトルネック、リ
ソースの無駄使い
P2Pモデル


全てのピアが対等→全体
を知る者がいない
Napsterはファイルリストだ
けサーバが管理
4.2. Scalability
スケーラビリティを左右する事項

中心での作業量、ステート量、並行性、プログラミングモデルなど
ハイブリッドP2Pの具体例


Napster：600万人のユーザ
SETI@HOME：350万人のユーザ
ピュアP2P



Gnutella, FreeNet: フラッディングによる検索、スケーラビリティ
はそこまで優れていない
Chordなど：オブジェクトとノードをIDによってマッピング、オーバ
レイネットワークを形成、1014ものファイルを管理可能
もっと発展する余地あり
4.3. Anonymity
匿名の構成要素 [Dingledine 2000]

著者、発行者、読者、サーバ、ドキュメント、クエリ
匿名の種類 [Pfitzmann 1987]

送信者の匿名性、受信者の匿名性、相互の匿名性
匿名の度合い

Absolute privacy, beyond suspicion, probable
innocence, probably exposed
匿名を実現する技術

マルチキャスト、送信者のアドレス詐称、ID詐称、パス
の秘匿、エイリアス、非自主的なコンテンツ保管
マルチキャスト


受信者の秘匿に利用可
IP層でマルチキャストをサポートすること
送信者のアドレス詐称


UDPなどで送信者アドレスを詐称
プロトコルの変更必要、ISPによってははじかれる
ID詐称


コンテンツ保有ピアのID詐称
Freenetでは、キャッシュを持つIDもクエリに応答
パスの秘匿


プロキシによる送信者の秘匿、パスの持続にも利用できる
includeMix [Chaum 1981], Onion [Syverson 1997], Anonymizing,
Proxy [Gabber 1997], Crowds [Reiter 1998], Herdes [Shields
2000]
エイリアス


LPWA [Gabber 1999]
一種のプロキシ、アカウントの作成が必要
非自主的なコンテンツ保管

どのピアがどのコンテンツを保管しているか分からな
い
4.4. Self-Organization
Self-organizationの定義
P2Pシステムに不可欠

スケーラビリティ、失敗への弾力性、リソースへの接
続性
予想できない

システム数、ユーザ数、負荷
自動でメンテナンス、修復が必要
各ピアで分散して管理することも必要

一人でor一台のピアでするのは大変
OceanStore

インフラとしてTapestryを利用
Pastry



クエリはO(log 16N)で到達
ファイルレプリカは拡散される
負荷分散のため、ストレージはランダム
FastTrack

性能に優れたピアはスーパーノードになる
SearchLing


ネットワークに適するように
トラフィック↓、不到達情報↓
4.5. Cost of Ownership
コストを減らすことが重要


システムやコンテンツを保有するコスト
メンテナンスするコスト
当時、SETI@HOMEは世界最速スパコンよ
り高速、かつコストはそのスパコンの1%
Napster,Gnutellaはピアのディスクに保有
Parastic Grid

Ad-Hoc Networkの実装？？
4.6. Ad-Hoc Connectivity
P2Pシステムでピアの違いや、参加離脱を吸収
する必要がある

分散コンピューティング：
 各ピアがシステムを実行できる時間はまちまち

コンテンツ共有：
 冗長性の確保により、アドホックの課題を減らす

コラボレーション：
 モバイル端末が多い（？）
 オフラインピアへの対応

他のピアがメッセージを保管、後に再送
4.7. Performance
パフォーマンスは以下の3つのリソース

Processing, storage, networking
中央管理モデルでは


単一故障点などの問題は残る
サーバを複数用意して解決する方法も [Yang 2001]
分散モデルでは


管理のためのメッセージが多く行き交う
帯域を消費してしまう
パフォーマンスを最適化する手法

Replication, Caching, Intelligent routing and
network organization
Replication



ピアが突然離脱しても平気
良いルーティングと組み合わせれば、コンテンツ送信の遅延を最
小限に可能
データ更新→レプリカも更新する必要あり
Caching


Freenetではコンテンツのホップ時にキャッシュ
トラフィック量↓、遅延↓、スループット↑
Intelligent routing and network organization

P2Pを引き出すには、社会的な動向（？）も必要
 Small-world：赤の他人でも、高々6ホップでたどり着く
 Power-law
 Good peers:興味の近いピア同士を近づける、メッセージ削減の効
果、ローカル情報だけでリンクを追加・削除可能
4.8. Security
Multi-key encryption


Publiusなどのファイル共有ソフトで利用される
一つの公開鍵と、複数の秘密鍵を利用する
Sandboxing



コードの安全性を検証
ソフトが読み書きできるローカルファイルを制
限
例：JavaのVM、Vmware、Internet
C++(icvm)
Digital Rights Management


P2Pではファイルのコピーが容易
ファイルに「透かし」や「埋め込み」を行う
Reputation and Accountability



「良い」＆「使える」ピアの評価
たとえば、いいファイルをたくさん持っているなど
ただし、それが妥当とは限らない
Firewalls




P2Pではピア同士の直接通信が必要
FirewallやNATなどがそれを拒む
80番ポートが開いていることが多いので、それを利用
共にFirewall内のときは、中継ピアが必要
4.9. Transparency and
Usability
ユーザがシステム内部を気にすることなく、P2Pソ
フトを使えるようにするのが重要



Access, concurrency, replication, failure, mobility,
scaling
End-to-end address transparency（アドレスさえ知っ
ていれば通信可能）
Naming transparency (URL)
No configuration, no setup
自動認証、操作の代行など
ユーザインタフェース



Webブラウザ：コンテンツ共有など
目に見えない（プラットフォーム）：.NETなど
ローカルにインストールされたソフト：分散コンピュー
ティング、Napsterなど
4.10. Fault Resilience
P2Pモデルの特徴




単一故障点は存在しない
しかし、ネットワーク切断・ピア群の分断・ピア
のエラーなどがある
Faultに対してベストエフォートに対応
各ピアで分散してfaultに対応するのが、クライ
アントサーバモデルとの大きな違い
例

Coda（P2Pではないが）
 オフラインノードに対応

Groove
 特別なノードを用意、アップデートや通信をキャッシュ

Freenet, Publius
 レプリケーションを利用

OceanStore
 2階層でレプリケーション
 場所が離れたところにレプリカがいくように

レプリケーションをとるのはファイルとは限らない
 ファイルシステムの拡張を
4.11. Interoperability
異なるP2Pソフト同士の相互運用性
実現するための要求事項



設計の重要性（利用するプロトコルなど）
要求やデータの交換手法
広告・セキュリティ・QoS・信頼性等の基準
手法


Standards IEEE, common specifications, common
source code, open-source, de facto standards
P2P Working Group等で推進の動き
P2Pプラットフォームの利用

JXTAなど
4.12. Summary
5. P2P SYSTEMS
この図の詳細な説明
5.1. Historical
初期の分散システムはP2Pモデル

タイムシェアリングシステム、ワークステーション
80年代後半～90年代前半

クライアントサーバ：技術に明るくないユーザが増加
初期のP2Pシステム


SMTP
Archie：FTPでのファイル検索機構→Napsterの先駆
P2Pの先駆け


AOLメッセンジャ、Napster
普及させるには初心者に適したインタフェースを
5.2. Distributed Computing
分散コンピューティングの先駆け

Beowulf project from NASA, MOSIX, Condor
グリッドコンピューティングの先駆け


I-WAY （アメリカの17の拠点を相互接続、Globus
Toolkit の先祖）
Global Grid form, Globus project
この文書では

Internetに接続した一般のPCの集合に基づくグリッド
コンピューティング＝分散コンピューティングと定義
分散コンピューティング


RSA解読@distributed.net (1999)が世間一
般に認知された先駆け
SETI@HOMEは300万ノードで25TFlops達成
P2P?

厳密にはP2Pではない
 ピア同士は直接通信しない
 しかしPCのリソースを利用、匿名性という特性
 なので、我々はP2Pだと考えている
動作手順
1.
2.
3.
サーバはピア（クライアントソフト導入済）に仕事を渡
す
（スクリーンセーバのように）ピアは空いている時間
を見つけて仕事を実行
終わったら、サーバに返す
使われ方


ピア同士の通信はしない→線形代数問題といった
スパコンのような処理はできない
SPMD (Single Process Multiple Data)＆マルチタス
ク
アプリケーション例

金融
 以前は、大銀行が夜中にメインフレームでシミュレーションを行う、と
いう形が一般だった
 P2Pへの以降により、15時間の計算が30分ですむようになったケー
スも

バイオ
 データが巨大（ヒトゲノムは300万シーケンス）
 以前はHigh Performance Clustering (HPC)を使っていた
 会社例：Platform Computing (LSF), Entropia, Avaki, Grid
Computing Bioinformatis
 プロジェクト例: Genome@home, Folding@home
ビジネスモデル


こなした計算数によってユーザに報酬をだす
成功例はなかなかない
5.3. File Sharing
P2Pファイル共有ソフトが提供するもの

ファイル交換場所
 ピアのストレージに保存、検索手段も提供

高有効性で安全なストレージ
 冗長化


匿名性
管理容易性
 分散していても高速検索（キャッシュなどにより）、ファイルを
取得してももともとどこにあったのか知らない、誰がファイル
に責任を持つのか？
技術





課題：帯域消費、セキュリティ、検索
モデル：中央ディレクトリ、リクエストフラッディング、ド
キュメントルーティング
現在(2002)は小さなファイル交換が主流
今後は大きなデータの交換が主流に
例：Xdegrees (M$に買収されました)
 XRNS (eXtensible Resource Name System) を提供：各ピア
のリソースにそれぞれ一意の名前をつける
アプリケーション例

Napster




P2Pで最初に有名になった
サーバでインデックス化、検索可能
他人にアップロード＝自分の帯域が消費される
OpenNapが登場


open source のNapsterサーバ
サーバ同士の連携可能
 訴えられた→有料会員制へ、ルール作りを

Morpheus
 あらゆるファイルを検索可能
 多数のピアから同時にダウンロード可能
 自動レジューム機能

Kazaa
 スーパーノードの存在
 ファイルダウンロード後、メタデータを開き、次の検索に生かす
 MD5で整合性チェック
5.4. Collaboration
例

IM、チャット、ゲーム、ビジネス・教育・家庭などでの共有アプリケーショ
ンなど
イベントベース
技術的な課題

ロケーション
 Magiは中央サーバがピアのオンライン状況を把握
 NetMeetingを開始する場合、相手のIPアドレスを入力

失敗寛容性
 基本的にベストエフォート

リアルタイムの制約
 原因は下層のネットワーク
 DOOMなどのFPSは遅延に関してシビア、Internetではスケールしない
5.5. Platforms
P２Pシステムに必要なコンポーネントを提
供
例

.NET, JXTA, Groove, Magi
6. CASE STUDIES
8つのケーススタディ








Avaki
SETI@home
Groove
Magi
Freenet
Gnutella
JXTA
.NET
6.1. Avaki
種別

分散コンピューティング
歴史

Mentat → Legion(1994) → Avaki(2001)
 Legionはバージニア大学のプロジェクト
 1997年、ベンチャー企業Applied MetaComputingで登場
 2001年、Avaki Corporationとして再始動
ゴール


透過的な分散実行環境
高速実行
設計


ミドルウェア、OOP、異種機器の統合
3つの主要コンポーネント
 コアサービス：プロトコル処理（JXTAと相互運用可）、セキュリティ、分散ディ
レクトリ、発見、イベント通知など
 システムマネージメント：メタシステムの監視・制御、ポリシー管理
 アプリケーション
規模拡張性


管理ドメイン可のリソースは完全制御できる
統合されたファイルシステム
耐障害性


高速実行より耐障害性を重視（結果が重要だから）
ハードウェアトラブルを重視
実装


仮想化→オーバヘッドが生じる
一番の目標は実行時間↓
6.2. SETI@home
Search for Extraterrestrial Intelligence
種別

分散コンピューティング
ゴール

電波の解析、地球外生命体の発見
設計

二つのコンポーネント


データベースサーバ
クライアント：多くのプラットフォームに対応
耐障害性

チェックポイントアルゴリズム


１０分おきに途中経過を保存
単純だが、オーバヘッドが少なく効果的
スケーラビリティ


水平：OK
垂直：ボトルネックあり、でも上手くいっている
教訓


実世界においてP2Pが役立っている
３００万人もの貢献者
6.3. Groove
種別

コラボレーション
歴史

1997年、Ray Ozzieによって開発、2001年にリリース
ゴール


サーバを頼らないユーザ同士の直接通信
インターネット、イントラネットなど環境選ばず
アプリケーション



コミュニケーション：音声、IM、チャットなど
コンテンツ共有：ファイル、画像など
コラボレーション：カレンダー、共同ドローソフト
設計

システムサービス





セキュリティ：公開・秘密鍵の自動管理
ストレージ：XMLベース
同期：ローカルのファイルを同期
ピアの接続：自動化（帯域推測、ファイアウォール越え）
中央サービス
 ライセンス管理
 コンポーネント管理：適宜アップグレード
 使用状況：アプリケーションの使われ方の調査
耐障害性

ピアがオフライン時の遅延配送など
ビジネスモデル


ライセンス形式
Magiなどが対抗馬
6.4. Magi
種別

プラットフォーム
歴史



Project at the Univ. of California
Endeavors Technology (1998)
Tadpole Technology (2000)
ゴール


情報共有、メッセージング
クロスプラットフォーム
設計

実装手段
 Javaベース
 XML (micro-Apache)

コア






通信：HTTP経由
イベント：
仲間：リスト
アクセス：厳密なアクセスコントロール
plug-ableサービス：Magichat、MagiDAVなど
プロトコル
 HTTP1.1
 WebDAV
 Wf-XML：ワークフロー：リモートプロセスの監視と制御
スケーラビリティ


ピア発見にDDNSを利用
認証にCertificate Authorityを利用
対障害性


メッセージの遅延配信
他ピアのクラッシュは検地できない
実装


Java、Servlets、Tomcatなど
小型端末には好ましくない
教訓

汎用性の高い実装→高い相互運用性を実現
アプリケーション


コラボレーションがメイン
エンタープライズ向けに対応可能
6.5. FreeNet
種別

ファイル共有
歴史

Ian Clarke が開発 (1999) at the Univ. of
Edinburgh
ゴール

情報の保有と検索に匿名性を
設計


ファイルとファイルキーはペア
3つのファイルキー：ファイル識別用
 KSK (keyword-signed key)



記述ストリング（ファイル名のようなもの）を入力として作成した公開・秘密鍵
公開鍵はハッシュ化されてファイルキーになる
秘密鍵はファイル署名用
 SSK (signed-subspace key)




記述ストリングは重複することがあるため、ユーザ名による名前空間を追加する
ユーザごとに公開・秘密鍵を作成
その公開鍵と記述ストリングのハッシュをXOR演算し、それをさらにハッシュ
ファイル更新時に、ユーザの秘密鍵が必要になる
 CHK (content-hash key)

ファイルの中身をハッシュ化したもの
設計（続き）

検索
1.
2.
3.

挿入
1.
2.


リクエストを受け取ると、そのファイルキーに最も近いIDを持つピ
アに転送
見つかると、同じ経路でファイルを返す
ファイル転送中、各ピアはキャッシュする
同じIDのファイルがないかリクエストを出して検索（TTLが切れる
まで）
重複がなければファイルを挿入（このとき、ファイル格納ピアが自
分でないことをチェック）
結果的に、各ピアは似たキーのコンテンツばかり保有する
ピアの追加


ファイル挿入時とほぼ同じ
Freenet自身は、ランデブー機構を備えていない
6.6. Gnutella
種別

ファイル共有
歴史



AOLのNullsoft事業部の社員二人が密かに開発、公開
同日、Webページが削除された
しかし、Gnutellaプロトコルを元にクローンソフトが多数開発され
た
ゴール

純粋な分散ファイル共有手段の提供
設計



あくまでGnutellaとはプロトコル名
プロトコルは検索やファイル共有手法を提供
ランデブーはユーザに委ねる（Webなど）
スケーラビリティ


実はあまりスケールしない
1ピアあたり2ピアと接続、TTL＝7の場合、128ノードしか検索できない
耐故障性


Gnutellaプロトコル自身は提供しない
要求が届かなかったら、ユーザ自身がリトライ
実装とパフォーマンス

多くのクローン、パフォーマンスはクローン次第？
 Limewire, ToadNode, BearShare

DL成功率、2000年：10%、2001年：25％以上
ビジネスモデル

企業のファイル共有用にGnutellaの開発をしているところも
教訓

モデル的に問題を抱えている
 非組織化、信頼性、スケーラビリティなど
6.7. JXTA
種別

プラットフォーム
歴史

2001年4月25日にSunが発表
ゴール



相互運用性
プラットフォーム独立性（プログラミング言語、システム、
ネットワーク）
偏在
設計

アプリケーションではなく、プラットフォームのみを提供
サービス

コア
 認証、ピア発見・管理、暗号化キット

オプション
 ネーミング、ルーティング、インデックス、検索

2002年の時点でサポート無し
 ファイアウォール、コンテンツリクエスト転送
アプリケーション


JXTA Shell
InstantP2P (チャット)
スケーラビリティ

ユニークIDの問題？（本当に世界でユニーク？）
実装

Solaris、Windows、Linuxなどで動作
ビジネスモデル


オープンソース
実際にアプリケーションが登場している
6.8. .NET My Services
種別

プラットフォーム
歴史

2000年6月に
Microsoftが発表
ゴール

あらゆるコンテキスト
からアクセス可能に
設計

サービスの分散化にフォーカス
 SOAP、UDDI（Webサービスのディレクトリ）、WSDL（Webサービスのプロトコ
ルフォーマットの定義）
セキュリティとプライバシ

パスポート




ユーザ認証に利用
シングルサインインを実現
1億6000万のアカウント（2001年7月時点）
パスポートに含まれる情報




パスポートユニークID (puid)
ユーザプロファイル
信用証明
お財布（オプション）
 PC環境以外でも利用可 (例：cHTML for I-mode)
スケーラビリティと耐故障性

コンポーネント＆サービスの分散化で、どちらも向上
実装とパフォーマンス

基本的にWindows環境のみ
ビジネスモデル

MicrosoftはInternet、オープンソースを取り囲もうとしている
 XML, SOAP, WSDL, UDDI, C#
アプリケーション

Officeを.NETに移行中
教訓


パスポート：多くの人を集められる
アプリケーション：普及させるには魅力的なアプリケーションが重要
6.9. Summary
7. LESSONS LEARNED
7.1. Strengths and
Weaknesses
P2Pの

強み





状況によって強み





分散化
アドホック
コスト所有権
匿名性
スケーラビリティ
パフォーマンス
耐障害性
自律組織化
弱み
 セキュリティ
 相互運用性
7.2. Non-Technical Challenges
7.3. Implications for Users,
Developers, and IT
各立場からの比較


信頼性は中央集権型が強
い
周辺ソフトウェアや互換性
はクライアントサーバが強
い
 規格やソースコードがオー
プンであるから

標準化や管理はまだまだ
これから
8. SUMMARY AND FUTURE
WORK
まとめ
8.1. Final Thoughts on What
P2P Is
P2Pとは




概念である
モデルである
実装手段である
システムや環境の一部である
8.2. Why We Think P2P is
Important
スケーラビリティ
接続性、アドホック、分散化
8.3. P2P in the Future
アルゴリズム

これからよりスケーラビリティや匿名性に優れ
たアルゴリズムが出現するはず
アプリケーション

もっと便利なものが出るはず
プラットフォーム

P2Pシステムの間口をさらに広げてくれるはず
8.4. Summary
P2Pは研究対象としてだけではなく、今後
のソフトウェアの基盤としてさらに発展する
だろう

Download Report