grid p2p
Download
Skip this Video
Download Presentation
Grid/P2P プログラミングモデルと関連技術

Loading in 2 Seconds...

play fullscreen
1 / 68

Grid/P2P プログラミングモデルと関連技術 - PowerPoint PPT Presentation


  • 100 Views
  • Uploaded on

Grid/P2P プログラミングモデルと関連技術. 東京大学 情報理工学系研究科 田浦健次朗. P2P. よく知られている起源 : Napster ファイル共有 ユーザ間の勝手な音楽ファイル転送を手助け 手助け ( 持ち主の検索のためのディレクトリ作成 ) はサーバ , 転送はユーザ間で その後 多数のファイル共有 (Gnutella, Kazaa, WinMX, Winny, …) 同時配信のための P2P ネットワーク (BitTorrent) 構造的 P2P ネットワーク (Chord, Pastry, Tapestry, CAN, …).

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Grid/P2P プログラミングモデルと関連技術' - neron


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
grid p2p

Grid/P2Pプログラミングモデルと関連技術

東京大学 情報理工学系研究科

田浦健次朗

slide2
P2P
  • よく知られている起源: Napsterファイル共有
    • ユーザ間の勝手な音楽ファイル転送を手助け
    • 手助け(持ち主の検索のためのディレクトリ作成)はサーバ, 転送はユーザ間で
  • その後
    • 多数のファイル共有(Gnutella, Kazaa, WinMX, Winny, …)
    • 同時配信のためのP2Pネットワーク(BitTorrent)
    • 構造的P2Pネットワーク(Chord, Pastry, Tapestry, CAN, …)

PPLサマースクール

slide3
P2Pのインパクト
  • 社会的インパクト(省略)
  • もう少し技術的なインパクト
    • 初めて多くの人が,非常に多数の計算機の協調によって,実質的にサービスの質・容量が向上しているのを見た
    • 強力なサーバ << 多数のPC
    • サービス= 大きなコンテンツの多数への配信
      • ファイル共有 : キャッシュ
      • BitTorrent : 同時配信

PPLサマースクール

slide4
Grid
  • 起源となるアイデア: メタコンピューティング
    • 遠隔にある複数の資源を統合した計算
  • 期待をこめた見方
    • 世界中の計算資源の効率的な流通(融通)
      • 必要な時に,必要な人の下へ計算資源を即座に提供する基盤
      • Where is 計算資源?
    • 電力網(Power Grid)と同じくらい普遍的に,誰でも利用可能な「計算網」(Computational Grid)

PPLサマースクール

seti@home
[email protected]
  • ユーザの遊休PCを計算資源とした並列計算
    • Volunteer計算, インターネット計算

http://www.boincsynergy.com/

PPLサマースクール

seti@home1
[email protected]のインパクト
  • 印象的なクライアント数
  • ここでも:
    • 初めて,多くの人が,非常に多数の計算機の協調によって,実質的にサービスの質・容量が向上しているのを見た
    • スーパーコンピュータ << 多数のPC
    • サービス= 科学を助ける計算

PPLサマースクール

p2p grid vs
P2P/Grid vs. 伝統的並列処理
  • 非常に多数の計算機(インターネット上のPC)の協調によって,実質的にサービスの質・容量が向上している …
    • それって大昔からある「並列処理」では?
    • それもきわめて限定された,単純な応用(ブロードキャスト,CPU-only計算)の…
  • 半分は真実
    • Broadcastのテクニックはよく知られている(MPIライブラリ)
    • 科学技術計算の高度な並列処理は多数行われてきた
  • But, これまでの多くの並列処理とプラットフォームの仮定が根本的に異なる

PPLサマースクール

vs p2p grid
伝統的並列処理 vs P2P/Grid: プラットフォームに関する仮定の違い

PPLサマースクール

slide9
課題と共通ゴール

並列

環境固定, 性能一様, 故障なし, などの前提からの脱却

共通ゴール「分散環境での一般的な並列処理」動的な変化, 故障, ネットワーク性能の多様性, スケール

P2Pbeyond ブロードキャスト

(e.g., 検索)

Volunteer Computing

beyond CPU-only型の応用(e.g., データ集約的応用)

PPLサマースクール

slide10
共通鍵技術:オーバーレイネットワーク
  • 参加計算機間で,一部の(TCP)接続を作り,維持する
  • この接続でできたグラフ上をメッセージが流れる
  • 通信アブストラクションの提供.e.g.
    • マルチキャスト
    • 1-1通信

PPLサマースクール

slide11
なぜオーバーレイネットワークが重要か?
  • なぜ下位の通信レイヤで直接接続・通信しないのか?
    • 直接接続が可能とは限らない(Firewall/NAT)
    • N-Nの直接接続は資源を圧迫し,無駄に使う
      • ファイルディスクリプタ,ポート,TCPの再送Window
    • N-Nの接続は変更の際に維持するコストが大きい
      • cf. クライアントサーバ
  • トラフィック量(ホップ数)  許容台数,資源消費

??

PPLサマースクール

slide12
本チュートリアルの中心課題
  • 並列プログラミングのための「オーバーレイネットワークの構築とそれを利用した通信の実現方法」
    • 資源消費(接続数)
    • ノードや接続の増減に伴う更新コスト
    • ルーティング性能(ホップ数)
  • 既存提案,興味深い理論,理論的な限界などの紹介
  • これらは,分散環境(資源の動的増減,ネットワーク性能の多様性,故障,etc.)での並列処理の基盤となる(はず)

PPLサマースクール

roadmap
Roadmap
  • Part I: 並列・分散プログラミングモデルの実例
    • メッセージパッシング,共有メモリ,RPC/RMI, タプルスペース
    • 大規模,分散,故障のある,動的な環境での課題
  • Part II: 構造的P2PとDHTの枠組み
  • Part III: Advanced Topics
    • 任意の重みつきグラフに対するCompactルーティング
    • 構造がないグラフ上の効率的ルーティング

PPLサマースクール

part i
Part I: 並列・分散プログラミングモデルの実例
  • メッセージパッシング
  • 共有メモリ
  • タプルスペース

PPLサマースクール

slide15
Grid (分散)環境での並列処理の現状
  • 「並列プログラミングなし」という実用的解
    • 逐次プログラム+バッチスケジューラ(SGE, Condor, etc.)
    • 並列シェル(GXP, pdsh, dsh, etc.)
  • 伝統的並列プログラミングモデルの利用
    • メッセージパッシング(MPI, PVM, etc.)
    • 分散共有メモリはほとんど使われない
  • 伝統的分散プログラミングモデルの利用
    • RMI, RPC, ソケット
    • タプルスペース (JavaSpace, TSpace, etc.)
  • 分散環境に適した並列プログラミングモデル
    • Phoenix
    • マスターワーカモデル

PPLサマースクール

slide16
課題
  • 伝統的並列プログラミングの課題
    • 分散環境で当然の故障,動的な資源増減下でのプログラミングを支援していない
    • ネットワークの制限(Firewall/NAT)下でしばしば動作しない
  • 伝統的分散プログラミングの課題
    • 多くは1-1のみの通信をサポートしているのみで,「多数のプロセスの協調」を直接支援していない

PPLサマースクール

slide17
メッセージパッシング
  • 実例 MPI, PVM
  • 基本アイデア:
    • 各参加プロセスに固定された名前(e.g., 0, 1, 2, …)をつける
    • プロセス名を指定した通信(メッセージ送信)
  • 基本API
    • send(p, msg) /* プロセスpにメッセージを送る */
    • msg = recv() /* メッセージを受け取る */
    • 集団通信(broadcast, reduction, etc.)

p

PPLサマースクール

slide18
メッセージパッシング:単純な実装のモデル
  • 各プロセスが「APIレベルのプロセス名  下位通信レイヤにおける名前」の対応を保持
    • プロセスの増減がなければ起動時に定まり,不変
  • send(p, msg)  下位通信レイヤの送信プリミティブを起動

下位通信レイヤの接続

PPLサマースクール

slide19
メッセージパッシング:分析
  • 固定した多数のプロセス集合による計算の素直なモデル
  • 全プロセス間で接続が許可されていれば, 1,000プロセス程度まではN-N接続可能(ボトルネックのない実装が容易)
  • 効率的な集合通信(特にbroadcast)の支援が容易
  • プロセスが動的に増減する場合,プログラミングの複雑度が非常に増す
    • 参加中のプロセス名の管理
    • プロセス  データのマッピングの管理

PPLサマースクール

slide20
共有メモリ
  • 実例: 共有メモリ計算機,分散共有メモリ(仮想共有メモリ)
  • 基本アイデア:
    • 通信にはプロセス名を用いず,別の名前空間(アドレス空間: 通常プロセス数よりずっと大きい)を用いる
    • プロセス間の通信は複数プロセスが同じアドレスにアクセスすることで(間接的に)行われる
  • 基本API:
    • WRITE(a, v)
    • READ(a)

a

PPLサマースクール

slide21
共有メモリ: 単純な実装のモデル
  • キャッシュ(複製)なし
  • アドレス空間を分割担当.各プロセスが,「アドレス  担当するプロセス名」の対応を保持
  • read(a)/write(a, v) aを担当するプロセスへのメッセージ送信

read(a)

a

PPLサマースクール

slide22
共有メモリ: 分析
  • 通信にプロセス名を用いないため,プロセスの増減下でのプログラミングモデルとして好ましい
  • 通信の効率が悪い(ほぼ常に2ホップ)
  • ブロードキャストプリミティブの不在
    • 1-1をN回繰り返すことになる

PPLサマースクール

slide23
タプルスペース
  • 実例: Linda, JavaSpace
  • 基本アイデア:
    • 共有メモリに類似した空間「タプル空間」にタプルを出し入れすることで通信
  • 基本API
    • out(value)
    • value = in(template), value = rd(template)

in(int, int)

out(3, 5)

(3, 5)

PPLサマースクール

slide24

(string,int)

(string, string”)

(3, *)

(”bye”, string, int)

タプルスペース: 実装のモデル
  • タプルサーバを配置
    • 全ての成立していない通信を格納する.i.e.
    • outされたが,マッチするinが発行されていないタプル
    • inされたが,マッチするoutが発行されていないタプル
  • in/out  タプルサーバとの通信

in/out

(1,”hello”)

(2,”bye”)

(5,”hello”)

PPLサマースクール

(”bye”, 10, 12)

タプルサーバ

slide25
タプルスペース: 分析
  • 共有メモリの利点/欠点を多くの大部分継承する
  • タプルサーバがボトルネックにならない実装は難しい
  • 通信の粒度の通信が可能(メッセージのサイズが任意)
    • メッセージパッシングの利点を踏襲

PPLサマースクール

part i 1

通信のアブストラクション

Part I: まとめ(1)
  • 多かれ少なかれ,モデルを実装するとは

プログラミングモデルレベルの通信  下位通信レイヤにおける通信(主にTCP接続を用いた通信)

のマッピングを行うことである

    • 1-1メッセージのルーティング,マルチキャスト

下位レイヤの通信

PPLサマースクール

part i 2
Part I: まとめ(2)
  • 下位通信レイヤへのマッピングの方法は様々であり,トレードオフが存在する
    • OSの資源制約内でサポートできる台数
    • 通信の性能(ホップ数など)
    • ボトルネックの有無
    • 動的な更新のコスト

PPLサマースクール

part ii p2p dht
Part II: 構造的P2PとDHT
  • 基本アイデア: 参加ノードで協調的に,規則的に,オーバーレイネットワークを構築
    • 不規則なネットワークでは困難な,1-1通信を効率的に実現
    • 以下の3点の“good balancing point”
      • トラフィック量(ホップ数)
      • 消費資源(維持すべき接続数)
      • 参加・脱退時の更新コスト
  • 提供する通信のアブストラクション
    • 分散ハッシュ表(DHT)

PPLサマースクール

slide29
DHT
  • Chord [SIGCOMM 2001]を例として説明する
  • 同時期に発表された類似システム
    • Pastry [Middleware 2001]
    • Tapestry [Berkeley Technical Report 2000]
    • CAN [SIGCOMM 2001]

PPLサマースクール

slide30
構造的P2P: 動機
  • 初期のP2Pシステム
    • 同一コンテンツの大量配信(ブロードキャスト)に威力
    • 検索には洗練されていない方法を用いていた
      • 単一サーバ,flooding
  • 技術的言い換え
    • ブロードキャストは無秩序なオーバーレイネットワークで十分効率よく実行可能
    • 1-1メッセージのルーティングは非効率的

PPLサマースクール

dht distributed hash table
DHT (Distributed Hash Table)
  • 構造的P2Pが提供しているアブストラクション(問題設定)
    • put(key, value)
    • value = get(key)
    • keyは大きな整数の区間(e.g., [0, 2160))の要素
  • 本質的には共有メモリと同じ
    • 注: 厳密な共有メモリの意味論(consistency)を実装するのはもっと複雑

a

鍵空間

PPLサマースクール

chord 1

a

あるプロセスの担当範囲

key

b

Chord (1)
  • 鍵空間[0, 2m) modulo 2m (m : たとえば160)
    • Chord ring, Chord circleなどと呼ばれる
  • 参加中のプロセスがこの空間を分割して担当する
    • 1プロセスは一つの区間(a, b] modulo 2mを担当
    • bをそのプロセスのidと呼ぶ
  • 実装の鍵となる要素: ルーティング
    • 与えられたkeyを担当するプロセスへメッセージを配達する

Chord ring

PPLサマースクール

chord 2
Chord (2)
  • 各プロセスは以下のプロセスへの接続を持つ
    • Chord ring上の両隣(predecessor, successor)
    • Finger table : 自分のid = bとして,
      • b + 2m – 1
      • b + 2m – 2
      • b + 21
      • を担当するプロセス(最大でm個.プロセスidが均等分布していれば約log N個)
  • 2mノードのHypercubeネットワークを(ノードの集合を1ノードに縮約することにより)Nプロセスで模倣したものに近い

PPLサマースクール

chord
Chord ルーティング
  • 問題 key kを担当するプロセスにメッセージを届ける
  • if (kが自分の担当) {自分へ配達;} else { Finger tableからkを越えない最大のentry iを取り出す; /* k < b + 2i */メッセージを対応するプロセス(pi)へ転送}

k

PPLサマースクール

chord1
Chordルーティング
  • ホップ数 < m, プロセスidほぼ均等ならばO(log N)
  • ノードの参加・脱退時のコスト
    • O(log2N)個のメッセージ(接続の追加,変更)
  • いずれもHypercubeの性質(ノード当たりlog Nリンク, diameter log N)と比べると理解しやすい

PPLサマースクール

slide36
  • Chordおよび多くのDHTの提案は, 世の中で使われている “ファイル共有アプリケーション” と異なり,各ノードが望むノードと接続を作ることができると仮定している
    • 実用的には, “No firewall/NAT”を仮定
    • 抽象的には,「完全グラフのspanner」を設計している
    • 伝統的ネットワークトポロジーの模倣が常に可能
  • より現実に即した,発展形の問題
    • 任意のグラフのspannerをオーバーレイネットワークとする
    • 重みつきグラフの元でのホップ数拡大係数

PPLサマースクール

part iii advanced topics
Part III: Advanced Topics
  • 任意の重みつきグラフに対するCompactルーティング
  • 構造がないグラフ上の効率的なルーティング

PPLサマースクール

slide38

t

s

ルーティング: 問題設定
  • G = V, E : 重み付きグラフが与えられる
    • V : プロセスの集合, E : 通信路の集合
    • 辺の重み: その辺を通るコスト(遅延)
  • タスク: パケットのソース sとあて先 tを与えられ,それを低いコストで届ける
    • コスト: 通った辺の重みの和
  • 任意の重み付きグラフを考えることで,現実の分散環境を反映したモデルとなる

3

2

1

6

2

5

3

3

4

1

1

2

PPLサマースクール

slide39

プロセス

次ホップ

0

3

1

22

2

9

3

35

22

3

10

9

N – 2

22

N – 1

3

35

ルーティングの基本方式(最短路)
  • 基本アイデア: 全対全の最短路を計算する
  • 各ノードは,他の各ノードへの最短路に沿った次ホップを蓄えた表(経路表/ルーティング表)を保持
    • 記憶領域: N log N
    • ルーティングの品質: 最適

PPLサマースクール

topic 1
Topic 1: コンパクトルーティング
  • Nプロセスに対し,各プロセスがsubblinear (o(N))の記憶領域を用いるルーティング方式をコンパクトルーティングという
    • 当然コンパクトルーティングは最適でないルーティング(回り道)をする可能性がある
  • あるルーティング方式のstretch (伸び率) = [ そのルーティングによるコスト / 最短路のコスト ]の,全プロセス対にわたる最悪値
  • 目標 : stretchを抑えたコンパクトルーティング

PPLサマースクール

taxonomy name independence
Taxonomy : Name Independence
  • トポロジ非依存名((topology) independent names)
    • ルーティング関数に与えられるあて先(アドレス)は,あらかじめ決められたノード名(e.g., 0, 1, …, n – 1)
  • トポロジ依存名 ((topology) dependent names)
    • ルーティング関数に与えられるあて先(アドレス)は,ルーティング方式が決めてよい
      • ルーティングに関する情報を,アドレスに「埋め込む」ことを許す
      • 極端な方法: グラフ全体の情報がアドレスに埋め込まれている
        • サイズ0のルーティング表
      • 制約: アドレス長さ = log nの多項式

PPLサマースクール

slide42
  • 重み一様な完全グラフに関するルーティングを考える

常にマスタ(ルーティングセンター)を経由

stretch = 2

トポロジ非依存名  コンパクトにできない

トポロジ依存名  コンパクトにできる

(e.g., マスタ以外各ノードのアドレス=マスタ側ポート番号とする)

PPLサマースクール

slide43
知られている結果
  • (トポロジ依存名) Stretch 3 コンパクトルーティング
    • Cowen SODA 1999, “Compact routing with Minimum Stretch”
  • トポロジ非依存名 Stretch 3 コンパクトルーティング
    • Abraham et al. SPAA 2004, “Compact name-independent routing with minimum stretch”
  • Stretch 3は「最適」なコンパクトルーティング
    • 全ノードo(n)の記憶域でstretch < 3は達成不可能
    • Gavoille et al. SIROCCO 1997, “Space Efficiency of routing schemes of stretch factor three”
  • 以降はCowenの方法の基本アイデアを紹介する

PPLサマースクール

cowen stretch 3 compact routing
CowenのStretch 3 Compact Routing
  • 仮定
    • G = V, E. 重みつき無向グラフ. nノード.
    • トポロジ依存名: i.e. ノードのアドレス(あて先)は事前に付け替えてよい(制約: アドレスはO(log n) bits)
  • 結果
    • 任意のグラフに対し,Stretch 3 (最短路の3倍以下)でルーティング
    • ルーティング表サイズ O(n2/3 log4/3n)

PPLサマースクール

slide45
基本アイデア
  • 準備:
    • 少数の「目印(Landmark)」ノードを決める
      • ただし,どのノードも最低一つの目印を近くに持つように
    • 各ノードuに対し「uの近くのノード」と,全目印への最短路を計算.uに,それら(のみ)への次ホップを保持
  • ルーティング (s to t):
    • case 1: tがsの近く  最短路
    • case 2: そうでない  tに最寄の目印を目指す

: 目印

: あて先(t)

: 送信元(s)

case 1

case 2

PPLサマースクール

slide46
ポイント
  • なぜ経路表を小さくできるか?
    • 近くのノードと,目印へのエントリしか持たない
      • 必要な目印の数を抑えられればよい
  • なぜstretch 3か?
    • 後述
  • 微妙なところ:
    • あて先ノードに最寄の目印をどう知るか?
    • 目印ノードの経路表の大きさは?
    • 答: アドレスに情報を含めておく
      • トポロジ依存名の活用

実際の道

最短路

PPLサマースクール

slide47
アルゴリズム: 全体構造
  • 前処理 :以下を計算
    • 目印の集合 L
    • 各ノード uに対するトポロジ依存名(3つ組) = u, uに最寄の目印 lu, luから uへの最短路上の次ホップ
  • 経路表構築 :各ノード uは,以下のノードらにする最短路を計算し,それに沿った次ホップを経路表に登録
    • u に近いノード
    • 全目印 L
  • ルーティング (s t):
    • 自分に近いノードへは最短路
    • それ以外は,tに最寄の目印を経由

PPLサマースクール

slide48
目印の選択
  • 要件1: どのノード uも自分の近く (B(u)) に一つ目印を持つ
    • ある程度遠いノード間では目印を経由しても,ひどい回り道にならない
  • 要件2: 目印の数が少ない
    • 全目印へ最短経路を記憶しても表サイズがnにならない

PPLサマースクール

slide49
前処理
  • for uV {B(u) = uから近いn個のノード /*  < 1 : 定数.同距離はノード名で順序付け */R(u) = { y | uB(y) } /* uを近くに持つノード */}C = { u | |R(u)| > n(1+ )/2 }D = GREEDY_COVER(V, { B(u) }uV)L = C  D /* 目印 */for uV {lu = uに最も近い目印n = luからuへ最短路上の次hopaddress(u) = u,lu, n}

PPLサマースクール

greedy cover
GREEDY_COVER
  • GREEDY_COVER(P, S) input: S : 集合, P : Sの,「大きさkの部分集合」の集合output: Pを覆うSの部分集合T. i.e. T S s.t. XPtXT = {} /* for each stept = 新たに覆われる集合が最も増える要素T = T + { t }return T
  • 事実: Pの各要素の大きさがkのときTの要素数は O(|S|/k log n)

PPLサマースクール

slide51

vへの最短路を保持するノード

経路表構築
  • for vV: /* 自分の近傍へのエントリ */ for uB(v) s.t. vuの最短路上に目印が存在しないuの表にvへのエントリ(最短路上の次hop)を追加for lL: /* 目印へのエントリ */ for uV: uの表にlへのエントリ(最短路上の次hop)を追加

B(v)

v

PPLサマースクール

slide52
ルーティング
  • あて先 address(t) = t, lt, n by s :
    • s = lt  nへ転送
    • tが経路表にある  経路表を見て次hopへ転送
    • otherwise  経路表を見てltへの次hopへ転送

PPLサマースクール

slide53
なぜコンパクトか?
  • 目印Lの作り方再掲:C = { u | | R(u) | > n(1+ )/2 }D = GREEDY_COVER(V, { B(u) }uV)L = C  D /* 目印 */
  • よって,
    • | C | n(1+ )/2 (  | R(u) | =  | B(v) | = n(1+ ))
    • | D |  n / n log n = n1–  log n
    •  | L |  n(1+ )/2 + n1–  log n

PPLサマースクール

stretch 3
なぜstretch 3か?
  • s lttの場合だけが問題

1. ba (sはtへの最短路を持っていない)

2. c a + b (cは s lt の最短路)

 b + c  2a + b  3a

lt

b

c

a

s

t

最短路

PPLサマースクール

topic 2
Topic 2: 構造のないグラフ上の効率的ルーティング
  • 我々の文脈における動機
    • 維持にほとんどコストのかからないオーバーレイネットワークが構築可能か?
  • Kleinberg [STOC 2000] “The Small-World Phenomenon: An Algorithmic Perspective”

PPLサマースクール

milgram
Milgramの実験
  • 目標: あて先(住所と名前)のついた手紙を渡され,あて先の人へ手紙を届ける
    • 渡された人は自分の知人の誰かに手紙を渡すことができる
  • 実験結果: アメリカ人は6 hopでつながっている
    • ランダムなグラフの直径が小さいことを示していると解釈できる

PPLサマースクール

kleinberg
Kleinbergの問題意識
  • 「グラフの直径が小さい」からと言って,「グラフ全体に関する知識なしに目的地までの短いパスが見つかる」とは限らない
    • i.e. 効率的な(ホップ数の少ない)ルーティングが可能とは限らない
      • 効率的 log Nの多項式ホップ数でルーティング可能
    • アメリカ人全体で「ルーティング表」があるわけではない…
  • これを可能にするようなグラフの性質とはどんなものか?

PPLサマースクール

slide58
モデル

長距離辺

  • nn格子点上にノード
  • 辺(知人)
    • 隣への「短距離辺」
    • ある確率で選ばれた1つの「長距離辺」
  • ノード間の「距離」
    • d(P, Q) = | xP – xQ | + | yP – yQ |
  • ルーティングアルゴリズム
    • あて先へ最も距離が近い知人へ転送

PPLサマースクール

slide59
長距離辺の選び方
  • rをある定数(0  r < )として,

     辺(u, v)が選ばれる確率 d(u, v)–r

  とする

  • r : 短い辺に偏って選ぶことになる
  • r = 0 : 一様な確率で選ぶことになる

PPLサマースクール

slide60
結果

1. r = 2 のとき: 先のルーティングは平均O(log2n)ホップ

2. それ以外のとき: どんなdecentralizedルーティングアルゴリズムも(n2/3)かかる

  • 注: k次元格子点の場合,上記の結果は“r = kのとき”となる
  • 以降では,一つ目の結果の証明と直感的説明を行う
    • 易しくするためにk = 1として証明する

PPLサマースクール

slide61
直感
  • r大 : 長距離辺が少なくなるので時間がかかりそう
    • より詳しくは,「目的地の遠くでさまよう」
  • r小 : 目的地の近傍を端点とする長距離辺が「十分な密度で」存在しない
    • 目的地へだいぶ近づいてから長距離辺が使えなくなる

PPLサマースクール

slide62
もう少し定量的な直感
  • あて先から距離 d (Ld < 2L)の点から,次ホップで距離L以内に突入する辺の存在確率は?
  • 大雑把に言って
    • L–r (の面積) = Lk–r
  • 解釈
    • k < r : 大きなLに対して小さい
    • k > r : 小さなLに対して小さい

L

L

PPLサマースクール

k 1 1
k = 1の場合の証明(1)
  • 目的地から距離 [2j, 2j+1)にいる間をphase jと呼ぶ(0  j log n)
  • パケットの現在地をuとして,ここでphase jが終了する確率を評価する

2 j

2 j

u

PPLサマースクール

k 1 2
k = 1の場合の証明(2)
  • uからある特定のv (あて先までの距離 2j)へ長距離辺が伸びている確率p1
  • uからどれかの,あて先までの距離 2jのノードへ長距離辺が伸びている確率p2

PPLサマースクール

k 1 3
k = 1の場合の証明(3)
  • phase jの長さの期待値  1 / p2 = 4 lg n
  • 目的地到達までの長さの期待値 4 log n lg n  O(log2n)

PPLサマースクール

slide66
参考 k = 0 の場合は?
  • p1 = 1 / n (一様)
  • p2 = 2j / n

PPLサマースクール

slide67
まとめに変えて
  • 目標 : 以下の条件での効率的な通信(1-1のルーティング, 集合通信)
    • 多数(> 数千)のノード
    • 実行時に変化する
    • 場所によって性能が多様
  • 恩恵を受ける(はずの)システム
    • 並列ミドルウェア(メッセージパッシング,etc.)
    • スケーラブルサービス(モニタリングシステム,ファイルシステム,資源管理システム,etc.)
    • 新P2Pアプリケーション

PPLサマースクール

ad