平成１８年度卒業論文

Gnutellaプロトコルの拡張によるPush型情報共有

情報通信工学科 　情報通信システム学講座

０３１０００９ 　安齋 　嶺

指導教官 　寺田 実 助教授

提出日 　２００７年 　１月３１日

概要

目的ファイル共有ソフトは参加するユーザの増加とともにファイル共有や発見に手間がかかるようになってきた．その解決方法としてクラスタリングがあるが，このクラスタリングにも収束に時間がかかったり，欲しいファイルが発見できないなどの問題点がある．本研究では，Gnutella 0.4のプロトコルを拡張として，Push型情報共有を提供する手法を追加する．その追加した手法によってクラスタリングを実現する．この拡張されたプロトコルに従って，シミュレーションを行い，それによって生成されるクラスタの状態や形状から提案する手法の有効性を検証する．

方法本研究では Javaでシミュレータを作成し，提案手法であるPoshを含む 3つの手法を比較し，Poshの有効性を検証した．

結論提案手法においてクラスタリングの収束までの時間は短く，有効であると考えられる．

しかし，提案手法によるクラスタリングを行うと，ファイルに到達できるノード数が減少した．この点については，改良の余地がある．

1

目 次

第 1章 序論 5

1.1 研究の背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 着眼点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

第 2章 関連研究 7

2.1 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Gnutella 0.4 Protocol[5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 デスクリプタのルーティング . . . . . . . . . . . . . . . . . . . . . 11

2.3 Gnutella 0.6 Protocol[6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Ultra Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 pushare[7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

第 3章 提案手法 13

3.1 デスクリプタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 送受信・転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 クラスタリング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 先行研究との違い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.1 QueryHitを利用したクラスタリング . . . . . . . . . . . . . . . . . 15

3.4.2 ランダムに接続するクラスタリング . . . . . . . . . . . . . . . . . . 15

第 4章 シミュレーション 18

4.1 シミュレータの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 初期接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.2 デスクリプタ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.3 通信路 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.4 興味 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.5 ノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 シミュレーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 シミュレーション 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.2 シミュレーション 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2

第 5章 結果 21

5.1 シミュレーション 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 シミュレーション 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

第 6章 考察 24

6.1 それぞれの動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.2 シミュレーション 2における到達ノードの減少 . . . . . . . . . . . . . . . . 24

6.2.1 Random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.2.2 QeuryHit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2.3 Posh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3 収束までの時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6.3.1 Random . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.2 QueryHit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.3.3 Posh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.4 Poshの有効性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

第 7章 今後の課題 30

7.1 接続・切断のポリシー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

7.2 実ネットワーク上での動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

第 8章 謝辞 31

参考文献 32

3

図 目 次

2.1 サーバ・クライアント方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Hybrid P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Pure P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Unstructured P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Structured P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Poshの動作 1:メッセージは Floodingで送信される . . . . . . . . . . . . . 14

3.2 Poshの動作 2:Poshに従って接続される . . . . . . . . . . . . . . . . . . . . 14

3.3 QueryHitの動作 1:Queryを Floodingで送信 . . . . . . . . . . . . . . . . . 16

3.4 QueryHitの動作 2:QueryHitが送信される . . . . . . . . . . . . . . . . . . 16

3.5 QueryHitの動作 3:経路上のノードが接続する . . . . . . . . . . . . . . . . 17

3.6 Randomの動作:ランダムに選択し，接続する . . . . . . . . . . . . . . . . 17

5.1 到達ノードの推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.2 クラスタノードの推移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3 到達ノードの増減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.4 クラスタノードの増減 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.1 Random減少の原因 1:aが bに接続要求を出す . . . . . . . . . . . . . . . . 25

6.2 Random減少の原因 2:cが切断される . . . . . . . . . . . . . . . . . . . . . 25

6.3 QueryHit減少の原因 1:aが Queryを発信する . . . . . . . . . . . . . . . . 26

6.4 QueryHit減少の原因 2:a,bが#と接続する . . . . . . . . . . . . . . . . . . 27

6.5 QueryHit減少の原因 3:cは#に到達できなくなる . . . . . . . . . . . . . . 27

6.6 Posh減少の原因 1:#が Poshを発信する . . . . . . . . . . . . . . . . . . . . 28

6.7 Posh減少の原因 2:a,bが接続し，1,2が切断される . . . . . . . . . . . . . . 28

4

第1章 序論

1.1 研究の背景昨今，Peer-to-Peer(以下P2Pと略記)の技術を応用したソフトウェアが見かけられるようになった．その中でもとりわけファイル共有ソフトは従来のサーバクライアント型のファイル共有に代わる方法として注目を集めた．しかし，これらのファイル共有ソフトは参加するユーザの増加とともにファイルの共有や発見に手間がかかるようになってきた。その問題を解決する手法として実装されているものにクラスタリングと言うものがある．これは，ある条件に従ってノードをつなぎ替え，ファイルの共有・発見を円滑に行うための手法である。しかし，現時点でのクラスタリングでは収束までの時間がかかる問題点がある．また，クラスタリングが収束しても，その場所に欲しいファイルがあるとも限らないという問題点もある．

1.2 着眼点クラスタリングとは一定の条件にしたがって複数のノードをひとつにまとめる手法であ

る．ひとつにまとまることによって，ファイルの検索・共有にかかる手間やコストを軽減しようというものである．現在のクラスタリングの手法は，ファイルを所持していると思われるノードを捜し出

し，接続するものである．すなわち，Pull型の情報共有である．このときの，所持していると思われるという条件は単に，「自分と興味が同じ（もしくは似ている）」であったり「（欲しいファイルであるかは関係無く）大量のファイルを所持している」というだけであるため，実際には欲しいファイルを所持していない場合がある．また，ファイルを所持しているノードの方がファイルを欲しているノードより少ないと考えると，この効率はあまりよくないと考えられる．そこで，ファイルを持つノード自身がファイルの所持を周囲のノードに知らせ，それに興味のあるノードが集まるという手法が考えられる．すなわち，Push型の情報共有を行い，クラスタリングを実現するのである．

5

1.3 目的本研究では，Gnutella 0.4のプロトコルに拡張として，Push型の情報共有を提供する手法を追加する．その追加した手法によってクラスタリングを実現する．この拡張されたプロトコルに従って，シミュレーションを行い，それによって生成されるクラスタの状態や形状から提案する手法の有効性を検証する．

6

第2章 関連研究

2.1 Peer-to-Peer

Peer-to-Peerは従来のサーバ・クライアント方式 (図 2.1)に代わるネットワークの形態である．この P2Pはトポロジの形態と集中サーバの存在で大別される．

Hybrid P2P

集中サーバが存在するものが Hybrid P2P(図 2.2)である．従来のサーバ・クライアント方式では集中サーバにファイルと保持するファイルの情報が全て存在したが，Hybrid

P2Pの集中サーバには参加するノードが保持するファイル情報しか持っていない．これによって負荷を分散することができる．しかし，集中サーバに故障などが生じた場合ネットワーク全体が機能しなくなることはサーバ・クライアント方式と同じであり，フォルトトレランスでは無いといえる．例えば，Napster[1, 2]などがある．

Pure P2P

集中サーバが存在しないものが Pure P2P(図 2.3)である．全てのノードが平等に存在するため，フォルトトレランスはある．しかし，ファイル情報なども分散しているため，ファイルの発見などに手間やコストがかかってしまう．

図 2.1: サーバ・クライアント方式

7

図 2.2: Hybrid P2P

図 2.3: Pure P2P

2.2で述べるGnutellaなどがこの方式である．

Unstructured P2P

Unstructured P2P(図 2.4)はトポロジに明確な規則を持たず，自由に接続するようになっている．そのため，どのノードがどこにいるかを把握するのは極めて難しくなっている．しかし，自由な接続・切断を許しているため，ノードの参加・離脱が容易にできる．検索については正規表現などによる柔軟な検索が可能であるが，時間やトラフィックな

どのコストが大きくかかる欠点がある．これもGnutellaなどの方式である．

8

図 2.4: Unstructured P2P

図 2.5: Structured P2P

Structured P2P

Unstructured P2P(図2.5)ではファイルを所持するノードを発見することに手間が掛かったためその解決策としてトポロジに規則を与える Structurede P2Pがある．規則によってノードは円環状や格子状にトポロジを形成する．この形成に欠かせないの

が DHT(分散ハッシュ表)である．多くの Structured P2PはこのDHTに従ってノードの接続などを行う．ファイルの検索はハッシュによって行われる．しかも，あらかじめDHTに従ってトポロジを形成しているため，検索は高速に実現できる．しかし，ハッシュを用いるため，欲しいファイルの正確な名称を知っている必要があるため，Webなどの様に正規表現などによる柔軟な検索は出来ない．また，規則に従ったトポロジを形成しているため，ノードの参加・離脱によってトポロ

ジを再構成を必要とすることが多く，頻繁な参加・離脱によってトポロジが維持できなくなることもある．

9

例として Pastry[3]や Tapestry[4]などが挙げられる．

2.2 Gnutella 0.4 Protocol[5]

Gnutellaは Pure P2Pのファイル共有ソフトウェアである．Gnutella 0.4 Protocolはそのプロトコルを定めたものである．このプロトコルはデスクリプタ（通信されるメッセージ）とそのルーティングの方法を定義している．それ以外に定められているものは無いため，どのノードと切断・接続するかは開発者に任されている．本節ではこのGnutella 0.4 Protocolについて説明する．

2.2.1 Descriptor

デスクリプタはヘッダーとペイロードで構成されている．このヘッダーでは以下のような情報を扱っている．

• Descriptor ID : ネットワーク上で一意な ID．

• Payload Descriptor : デスクリプタの種類を示す．

• TTL : Time To Liveの略で有効なホップ数を示す．

• Hops : 現時点までのホップ数を記録している．

• Payload Length : Payloadの長さ．

Gnutella 0.4では 5つのデスクリプタを定めている．以下ではそれぞれのデスクリプタについて説明する．

Ping

近隣のノードを調べるために使用するデスクリプタ．ペイロードには何も記載されない．

Pong

Pingに対する返答．ペイロードには自分の IPアドレス，開放しているポート，公開しているファイルの総数と合計サイズが記載される．なお，Descriptor IDは返答するPing

と同じものを用いる．

10

Query

ファイルを検索するキーワードを送信するデスクリプタ．最低回線速度 (これを越えない回線速度しかないノードはこのデスクリプタに対して返答しない)とキーワードがペイロードに記載される．

QueryHit

Queryに対する返答．ただし，Queryの条件に当てはまらないと送信しない．ペイロードにはヒット件数，アドレス，開放しているポート，回線速度，検索の結果，サーバントID(ノードが持つネットワーク上で一意な ID)が記載される．なお，Pong同様にDescriptor

IDは返答するQueryと同じものを用いる．

Push

QueryHitの発信元がファイアーウォールによって隔てられている場合ファイルをダウンロードするために用いられるデスクリプタ．すでにコネクションが張られているノードを経由して送信することによって，通信し，QueryHitの発信元から接続要求を出してもらうようにする．ペイロードにはサーバント ID，ファイル番号，アドレス，ポート番号が記載される．なお，Descriptor IDは QueryHitと同じものを用いる．

2.2.2 デスクリプタのルーティング

デスクリプタのうちQuery，Pingは Floodingで送信される．これは，接続している全てのノードに対して同じデスクリプタを送信する．受信したノードは送信してきたノード以外で接続しているノード全てに受信したデスクリプタを転送する．この方法を用いることで近隣のノードにデスクリプタを送信することができる．しかし，これを際限なく繰り返すとやがてトラフィックが爆発するため，普通TTL(Time

To Live，生存時間)によって繰り返す回数を制限している．Gnutellaの場合，デフォルトのTTLの値は 7で，一回の転送ごとに数値を 1減らし，0

になったら転送を止めるというものである．それ以外にもデスクリプタ ID(Floodingされるデスクリプタは一意)を検査し，すでに送信したデスクリプタと同じデスクリプタ IDのメッセージが届いた場合はそのデスクリプタを送信しないようになっている．

QueryHit, PongのルーティングはQuery, Pingのルートを逆順でたどるようになっている．それぞれのノードは通過したデスクリプタの IDと送信元を記憶することで，実現している．

Pushのルーティングは QueryHitのルートを逆にたどることで実現される．

11

2.3 Gnutella 0.6 Protocol[6]

デスクリプタについては Gnutella 0.4と同じである．しかし，Gnutella 0.6では Ultra

Peerなどを追加し，無駄なトラフィックを抑えるようにしている．本節では Gnutella 0.6 Protocolについて説明する．

2.3.1 Ultra Peer

Gnutella 0.4では全てのノードが同等の役目を担っていた分，Pingや Queryの送信はトラフィックに大きな負担をかけていた．また，処理能力的に無理のあるノードも存在した．これらを回避するために考えられたのが Ultra Peerである．従来の全てのノードが複数のノードと接続する形から処理能力などが高いノードを中心

とした木構造に近いトポロジを構成するようになる．Ultra Peerは接続している下位のノードのファイル情報から下位のノードに流すQuery

のフィルタを行い，下位のノードから来た Queryを他の Ultra Peerに流す役目を担っている．こうすることで，大量になってしまうFloodingによるトラフィックを低減している．また，Ultra Peerは接続の要求があった場合，余裕があれば，Leafとして受け入れ，余裕が無い場合は他の Ultra Peerを斡旋することも行っている．

2.4 pushare[7]

pushareは Push型の情報共有を実現するP2Pファイル共有ソフトである．自分の所持するファイルの名前を隣接するノードに送信する．それを受信したノードは，隣接しているノードに転送する (すなわち，Flooding)．ただし，転送する際にすでにそのファイルをダウンロードしている場合は発信元を自分

に書き換える操作を行うようにしている．

12

第3章 提案手法

本節では Gnutella 0.4にクラスタリングの機能を追加するための手法について述べる．Gnutella 0.4プロトコルのデスクリプタのフォーマットに従い Poshデスクリプタを追加する．このデスクリプタはファイル（もしくはコンテンツ）のメタ情報とファイルを所持するノードのアドレスを保持するものである．このデスクリプタは Floodingで配信され，転送される際に興味を同じくするノードによってデスクリプタのファイルを所持するノードのアドレスが順次書き換えられる．この情報を元に接続を行い，クラスタリングを実現する．

3.1 デスクリプタGnutella 0.4プロトコルのデスクリプタのフォーマットに従い Poshデスクリプタを追加する．

Payloadには発信元と所持しているファイルのメタ情報が記載される．

3.2 送受信・転送このデスクリプタは以下の手順に従い送信される．

1. 所持するファイルからひとつをランダムに選択する．

2. そのファイルに関するメタ情報を payloadに記載する．

3. 発信元としてアドレスを同じく payloadに書き込む．

送信の手段として Flooding(図 3.1)を用いるが転送は以下の手順に従う．

1. 受信したデスクリプタのメタ情報に興味があるか調べる．

2. 興味があれば，発信元のアドレスに接続要求を送信し，payloadの発信元のアドレスを自分のアドレスに書き換える．(図 3.2)

3. TTLを 1減らし，Floodingを行う．

13

格子縞はファイルを所持するノード，斜線は同じ興味を持つノード

図 3.1: Poshの動作 1:メッセージは Floodingで送信される

図 3.2: Poshの動作 2:Poshに従って接続される

14

3.3 クラスタリングPoshの転送を行う際に興味が同じノード同士が接続している．しかも，そのデスクリ

プタはファイルを所持するノードを起点として発信されているので，興味が同じで欲しいファイルが存在するクラスタが生成されていると言える．

3.4 先行研究との違い本提案手法は 2.4節で示した pushareとは違う．pushareではファイルのやりとりがあっ

て初めて発信元のアドレスの書き換えが発生し，1つのノードへの接続の集中を回避した形になるのである．この点を Poshではファイルの所持は関係無く発信元のアドレスの書き換えを行うこと

で 1つのノードに接続が集中せず，収束までの時間が短いクラスタリングを実現しようとするものである．

3.4.1 QueryHitを利用したクラスタリング

比較対照としてQueryと QueryHitを利用したクラスタリングを実装する．クラスタリングの手順は以下のとおり

1. ファイルを発見するために Queryを発信する．

2. Floodingによってファイルを所持するノードへ届く．(図 3.3)

3. QueryHitをファイルを所持するノードが返す．

4. QueryHitは Queryの通ったルートを逆順に辿ってQueryの発信元へ．(図 3.4)

5. QueryHitのルート上で同じように興味を持つノードもQueryHitの情報に従い，ファイルを所持するノードへ接続要求を送信．(図 3.5)

3.4.2 ランダムに接続するクラスタリング

比較対照として Pingと Pong(接続状態を確認するデスクリプタ，未実装)によって生成される近隣 (通常 7ホップ以内)のノードのリストを用いたクラスタリングを実装する．クラスタリングの手順は以下のとおり

1. 近隣ノードのリストからランダムに 1ノードを選択する．

2. 選択したノードに接続要求といっしょに興味を判定するためのメタ情報を送信する．

3. 同じ興味を持っていたら接続する．(図 3.6)

15

図 3.3: QueryHitの動作 1:Queryを Floodingで送信

図 3.4: QueryHitの動作 2:QueryHitが送信される

16

図 3.5: QueryHitの動作 3:経路上のノードが接続する

図 3.6: Randomの動作:ランダムに選択し，接続する

17

第4章 シミュレーション

4.1 シミュレータの実装本研究では Javaでシミュレータを製作した．以下では仕様および実装した機能などに

ついて述べる．

4.1.1 初期接続

初期の接続状態をまず設定する．本研究ではノードの新規参加は考慮されていないので，初期の接続状態で全てのノードが連結である必要がある．また，実際のアプリケーションに近づけるため 1ノードあたりの接続数については上限を設けるようにしている．初期接続の生成は総ノード数と接続の総数を与えてランダムに生成している．

4.1.2 デスクリプタ

Gnutella 0.4については payload以外の情報は byte配列で情報を掲載することになっているが，本研究では簡単のため，整数や文字を利用することとする．また，デスクリプタIDについては java 5.0に実装されているUUIDをオブジェクトのまま使用している．

4.1.3 通信路

本研究では通信路の遅延については簡単のため，考慮しないことにする．また，ノードがデスクリプタを送信するのにかかる時間は 1単位時間より短いことにしている．そのため，全ての隣接しているノードにデスクリプタを送信するのにかかる時間はいくつのノードに接続していても 1単位時間しか消費しないこととしている．

4.1.4 興味

本研究では payloadにメタ情報を記載していない．その代わりに，興味の有無を判定するのはノード IDが 3で割り切れてなおかつ 1000以下のノードを同じ興味を持つノードとした．

18

4.1.5 ノード

実ネットワーク上ではノードはアドレスを持つが，シミュレーションではノード IDをアドレスとして利用する．また，ファイルを持つノードはノード ID 0, 300, 600, 900の 4

ノードとした．また，接続数の上限を持つ．これは，初期接続を生成したときと別にランダムな値がノード毎に定められている．シミュレーション中にこれが変化することはない．

4.2 シミュレーション

4.2.1 シミュレーション 1

まずは，それぞれのクラスタリングの手法で動作を確認した．パラメータは以下のとおりとし，それぞれの手法について 1回ずつ実行した．

• ノード数 1000

• 初期最大接続数 5

• 初期の枝の本数 (総ノード数) − 1

• 最大接続数の上限 5

• デスクリプタの発信間隔 1ノードあたりポワソン分布で 200単位時間あたり 1回．(QueryHit，ランダム)，2.4単位時間あたり 1回 (Posh)

3つの手法についてデスクリプタの発信される回数を揃えるため，以下のような理由によって発信間隔は定められている．まず，適度な発信間隔としてQueryHit，ランダムは 200単位時間あたり 1回と定めた．QueryHit，ランダムは 334個のノード (同じ興味を持つノード )が発信するのに対して，

Poshは 4個のノード (ファイルを所持するノード )しか発信しないので，2.4単位時間あたり 1回となっている．この結果から同じ興味を持つノード同士が接続しているノード (以下クラスタノード )

，ファイルを所持するノードから 7ホップ以内の同じ興味を持つノード (以下到達ノード )

の推移を 1単位時間毎に調べた．

4.2.2 シミュレーション 2

次に，以下のパラメータでシミュレーションを行った。同じパラメータで違う初期接続を 10回，全部で 1000回，シミュレーションを実行した．

• ノード数 1000から 10000(1000間隔)

19

• 初期最大接続数 5

• 初期の枝の本数 (総ノード数) − 1 + (総ノード数) × 0.001から 0.01(0.001刻み)

• 最大接続数の上限 5

• デスクリプタの発信間隔 4.2.1に同じ

この結果から 200単位時間後のクラスタノード数と到達ノード数を調べた．

20

第5章 結果

5.1 シミュレーション 1

到達ノード (ファイルを所持するノードから 7ホップ以内の興味が同じノード )とクラスタノード (興味が同じノードが少なくとも 1つ以上隣接しているノード )の推移を図 5.1,

5.2に示した．横軸は経過時間，縦軸は該当するノード数である．このグラフと実行結果のログから，接続・切断が発生して，該当するノード数が増減を

していることから，仕様通りにそれぞれの手法が動作していることを確認した．

5.2 シミュレーション 2

まずは，到達ノード数の増減 (図 5.3)を得た．横軸の密度とは，シミュレーション開始時点でのファイルを所持するノードから 7ホップ以内に存在する総ノード数をN，ファイ

40

50

60

70

80

90

100

110

120

130

0 50 100 150 200

Num

ber

of N

odes

Elapsed Time

PoshQueryHitRandom

図 5.1: 到達ノードの推移

21

150

160

170

180

190

200

210

220

0 50 100 150 200

Num

ber

of N

odes

Elapsed Time

PoshQueryHitRandom

図 5.2: クラスタノードの推移

ルを所持するノードから 7ホップ以内に存在する興味が同じノードの数をNfとしたときのNf/Nの値である．縦軸は 200単位時間後の到達ノード数の増減である．グラフの線はデータを密度 0.01刻みで平均をとったものである．次に，興味が同じノードが少なくとも 1つ以上隣接しているノード数の増減 (図 5.4)を得た．横軸の密度は前に得たグラフと異なり初期の総ノード数 (1000から 10000) に対して興味を持つノード (334で固定)の割合である．グラフの線は前述の到達ノードのグラフと同様に 0.01刻みで平均をとったものである．

22

-80

-60

-40

-20

0

20

40

60

80

0 0.1 0.2 0.3 0.4 0.5 0.6

A C

hang

e of

the

Num

ber

of th

e N

odes

Density

PoshQueryHitRandom

図 5.3: 到達ノードの増減

0

10

20

30

40

50

60

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35

A C

hang

e of

the

Num

ber

of th

e N

odes

Density

PoshQueryHitRandom

図 5.4: クラスタノードの増減

23

第6章 考察

6.1 それぞれの動作まず，シミュレーション 2のクラスタ化 (図 5.4) の様子であるが，334個のノード全て

がクラスタリングに向けてメッセージを発信し，通信の経路によらないランダムに接続するアルゴリズム (Random)が他より大きい，特に，密度が大きいときには大量のノードが興味が同じノードに隣接できている．しかし，このグラフからはファイルを所持しているノードに集合できたとは言えない．図 5.3の到達ノードの増減では，3つの手法，全てについて，ほとんどが減少している．密度が大きくなると大きく増加に転じている部分もあるが密度 0.3以降はデータ点が少ない為，あまり正確なデータとは言いがたい．図 5.3を見る限りでは，クラスタリングを実行すべきではないという結果に至ってし

まった．

6.2 シミュレーション 2における到達ノードの減少この節では図 5.3において，それぞれの手法が，なぜ減少に至ったのかを考察する．

6.2.1 Random

ランダムについては密度の増加とともに他の２つより減少が著しい．この原因は以下のような動作があったからである．

1. あるノード aが興味が同じノードの bを近隣のノードリストから選択する (ただし互いにファイルを所持していない)．(図 6.1)

2. 接続をする際に同じ興味を持たないノード cが切断される．(図 6.2)

3. 切断されたノード cがファイルを所持するノード#の 7ホップ以内であるため，以降 a,bは#と通信する手段を失い，7ホップの範囲から外れる．

ランダムについては接続・切断にファイルの所持は一切関係ない上に，接続を試みるノードはランダムに決定されるため，このような事態が起こり得るのである．

24

以下，図では TTL=3とする．

図 6.1: Random減少の原因 1:aが bに接続要求を出す

図 6.2: Random減少の原因 2:cが切断される

25

図 6.3: QueryHit減少の原因 1:aが Queryを発信する

6.2.2 QeuryHit

QueryHitは Random程では無いが，やはり減少している．この原因は以下のような動作があったからである．

1. あるノード aが Queryを送信する．(図 6.3)

2. QueryHitを受け取った a，QueryHitの経路上にあった bは#に接続する．(図 6.4)

その際にノード 1,2が切断される．

3. QueryHitの経路上になかった cは#と通信する手段を失い，7ホップの範囲から外れる．(図 6.5)

QueryHitは Floodingで送信されないため，適応される範囲が狭い．そのため，経路上になったノードが最終的にファイルを所持するノードの 7ホップの範囲から外れる．ただし，Randomほど減少しないのは接続・切断の発生はファイルを所持するノードとの間でしか発生せず，このシミュレーションに関しては多くても 20回程度の接続切断が発生するのみだからである．

6.2.3 Posh

提案手法であるPoshについても同様に減少している．ときには，QueryHit以上に減少していることがある．この原因は QueryHitと類似した動作が原因である．

1. ファイルを所持するノード#が Poshを送信する．(図 6.6)

26

図 6.4: QueryHit減少の原因 2:a,bが#と接続する

図 6.5: QueryHit減少の原因 3:cは#に到達できなくなる

2. 同じ興味を持つノード a,bがそれぞれ#に接続する．(図 6.7) その際にノード 1,2が切断される．

3. 遅れて Poshが到達した cが接続を要求するも，ノード#はすでに接続できず，cは#と通信する手段を失い，7ホップの範囲から外れる．

この動作はQueryHitではファイルを所持するノードでしか発生しなかったが，Poshではアドレスの書き換えがあるため，他の同じ興味を持つノードでも発生する．このため，

27

図 6.6: Posh減少の原因 1:#が Poshを発信する

図 6.7: Posh減少の原因 2:a,bが接続し，1,2が切断される

密度が濃い状況では頻発し，QueryHitよりも悪い結果となった．

6.3 収束までの時間今度は，それぞれのクラスタリングについて収束 (クラスタリングのための動作を行っ

てもトポロジが変化しない状態)までの時間を図 5.1, 5.2に示したグラフから考察する．

28

6.3.1 Random

ランダムの場合は 200単位時間の実行でも収束しなかった．この手法は，全ての同じ興味を持つノードがそれぞれの持つ，隣接ノードリストが全て同じ興味を持つノードにならない限り収束しないからである．この手法では，接続しようとするノードの決定はランダムであるため，選んだところで同じ興味を持つノードとは限らないため，収束に時間がかかる．

6.3.2 QueryHit

QueryHitを利用した場合は約 25単位時間程で収束した．この手法は，ファイルを所持するノードの隣接ノードリストが全て同じ興味を持つノードになった時点で収束となるからである．ただし，QueryHitはQueryの通ったルートを帰る形で通るため，時間がかかるといえる．

6.3.3 Posh

Poshを利用した場合は約 10単位時間で収束した．この手法は，ファイルを所持するノードから 7ホップ以内の同じ興味を持つノード (所持するノード自身も含む)の隣接ノードリストが全て同じ興味を持つノードになった時点で収束となる．しかし，QueryHitと違い，デスクリプタが Floodingされるため，周囲に伝わるまでの時間が非常に短く，よってクラスタリングが収束するまでの時間も短いものとなっている．

6.4 Poshの有効性今回のデータでは Poshが有効とまでは言い切れない状態である．この原因は切断のルールが的確ではなかったためである．今回の切断のルールは初期接続の時点で生成された隣接ノードリストについて先頭から順に同じ興味を持つノードかどうかを判断し，持たないノードを切断する方法をとっていたからである．ただ，収束までの時間の短さを考えると，その点については Poshは十分に有効である

と考えられる．

29

第7章 今後の課題

7.1 接続・切断のポリシー今回のシミュレーションで接続数に上限がある以上，切断は重要な要素であることが

わかった．単純に切断してしまうと，切断したコネクションより先にファイルを所持するノードや同じ興味を持つノードが存在する可能性が高いからである．その解決策として，1つは接続要求がどのノードを経由したものかがわかるようにする

ことである．今回の提案手法では切断されるノードの決定はほとんどランダムであった．しかし，ど

のノードを経由したかがわかることによって切断するノードを正しく選択できていればある程度減少は回避できると思われる．もう 1つの方法として，考察で述べたような事態を回避するため，もし接続数が上限に達しているならば，周囲のノードを斡旋すれば回避できるはずである．これは，Gnutella

0.6などに実装されているUltra Peerと同様の動作である．

7.2 実ネットワーク上での動作今回はシミュレーションで終わってしまった．実ネットワーク上で行った場合や実在の

アプリケーションを拡張して実装した場合はどうなるのかというところを確かめるべきだ．今回のシミュレーションでは通信の遅延なども想定していないし，複数あるはずの興味

もたった一つのものとしている．実ネットワークでは，これらの要素も考えなければならず，今回のシミュレーションだけでは有効とは言えないのではないだろうか．

30

第8章 謝辞

本研究は電気通信大学電気通信学部情報通信工学科寺田研究室の寺田実助教授の指導の下行われました．なかなか進まず，本論文もなかなか完成しない中辛抱強く指導してくださいました．この研究は寺田助教授なしには完成しませんでした．深く感謝します．また，情報基盤センターの丸山一貴助手も理論的におかしい点などについて丁寧に指導

してくださいました．深く感謝します．本研究の提案手法である Poshのネーミング，およびアルゴリズムの構築の手助けをし

てくれた河地崇之君．君が Posh me![8]のサイト名を”Push”と読み間違えてくれなければ，現在の Poshは無かったかもしれません．深く感謝いたします．また，同じ研究室の諸先輩方，同じ学年のみなさん，そして，かかわりのあった多くの方々の支えがあってこそ，無事にこの研究がやり遂げられたと思います．深く感謝します．ありがとうございました．

31

参考文献

[1] Napster, http://www.napster.com .

[2] 検証 ネットワーク管理者のための Napster入門,

http://www.atmarkit.co.jp/fwin2k/experiments/napster for admin/

napster for admin 1.html

[3] A. Rowstron and P. Druschel, “Pastry: Scalable, distributed object location and

routing for large-scale peer-to-peer systems,” in Proceedings of the Middleware, 2001.

.

[4] B. Y. Zhao, L. Huang, J. Stribling, S. C. Rhea, A. D. Joseph, and J. D. Kubiatowicz,

“Tapestry: A resilient global-scale overlay for service deployment,” IEEE Journal on

Selected Areas in Communications, vol. 22, no. 1, pp. 41-53, January 2004. .

[5] The Annotated Gnutella Protocol Specification v0.4,

http://rfc-gnutella.sourceforge.net/developer/stable/index.html .

[6] RFC-Gnutella 0.6,

http://rfc-gnutella.sourceforge.net/developer/testing/index.html .

[7] pushare, http://fuktommy.com/pushare/ .

[8] Posh me!, http://poshme.jp .

32