ファイル交換における配布効率について

00kc539 川岸 元気

指導教員 坂本直志助教授

はじめに


 近年、P2Pが注目をあつめています。P2Pとは、Peer-to-Peerを示す略語です。P2Pはクライアント 同士の接続方式で、お互いのノードがサーバを介さずに自律分散的に働くことによって、 サービスを提供することが可能なコンピュータ・ネットワークの一つの形態です。そのネットワー クを実現する技術やそれが実現された状態をP2Pと呼びます。 従来のインターネットを構成してきたクライアントサーバ型ネットワークは、ネットワークと 行きかう情報がサーバに蓄積され、サーバ同士の相互接続によってエンドユーザに蓄積され、 サーバ同士の相互接続によってエンドユーザに情報が行き渡るシステムです。 P2Pとは、集中管理を行うコンピュータであるサーバを利用せず、各ネットワーク端末が直接 つながって、資源を共有するネットワーク・システムを指します。P2Pネットワーク・システムで は、すべてのコンピュータがお互い対等に処理要求を受けるサーバでもあり、処理を要求する クライアントでもあるため、サーバント(Servant=Server+Client)と呼びます。従来、 P2Pネットワーク・システムは、小規模のLAN(Local Area Network)の中でコンピュータ同士を 直接接続することに利用されていました。しかし現在Peer-to-Peerネットワーク・システムは、 LANの中に限らず、インターネットを介してグローバルに存在するコンピュータ同士を直接結びつ けます。現在のP2Pネットワークは、各ノードがアプリケーションレベルで相互に接続を行って 形成されます。これはオーバーレイネットワークとも呼ばれ、TCP/IP層の上アプリケーション 層上に形成される論理ネットワークです。そしてP2Pネットワーク上にサーバが存在しないことに なるので、単一障害点がなく耐故障性に優れており、管理コストがかからないといった特徴をもちます。その一方でサーバやクライアントという明確な役割分担がないので、すべてのコンピュータがどちらの役割もかねます。そのため、サーバとして働けるだけの性能が要求されます。しかしここ数年のパソコンの高性能化と低価格化がこれに応えることを容易にしました。また、ADSLなどの高速回線と常時接続の普及がP2Pの普及を後押しするかたちとなりました。P2Pのシステムを具現化した有名なものとして、Napster[1]やGnutella[2]などがあげられます。P2Pのシステムは、サービスに参加する端末はピアと呼ばれ、集まってできた論理ネットワークにおいて、ピア上でサービス要求がされると、ピアはサービスを提供できる別のピアを探し出し、そのピアからサービスを受けます。また、自身の提供できるサービスを公開することで、そのサービスを欲する別のピアに提供することができます。しかし、提供する側のユーザに対して要求する側のユーザの方が多い場合、全員に提供するには、多くの時間を要します。又一方、一般にP2Pサービスは実行するアプリケーションソフトウェア上で動作するため、ユーザによる離脱が自由に行えます。そのためサービスの提供を待っていたユーザが、自分の番が回ってくる前に提供側が離脱してしまうことで、サービスを受けることが出来ないことがあります。その時は、サービスを提供してもらえる別のピアを探し出し順番の一番後ろに並ぶことになります。また、提供者側が同時に複数に提供すると、今度は、提供している人数で帯域を分けることになるので、送信速度が遅くなり、結果、一人あたりのサービス取収完了時間が遅くなります。これは、サービスの容量が多ければ多いほど、この現象は起こります。そこで本研究では、サービス提供までの遅延が長くなるので、サービスを得る確実性が低くなります。これは提供側に多くのユーザーが集めることにより起こる待ち時間を減らすことにより、解消する事ができると考えました。

1.背景及び関連事例

 P2Pの実現方法には、ピアの見つけ方により大きくわけて2つあります。

2.1 ピュア型P2P

 一つは、「ピュア型P2P」と呼ばれるものです。検索におけるすべての通信をバケツリレー式で行 うもので、P2Pの概念がそのまま形になったものです。ネットワークに繋がるコンピュータはすべ てが対等で、相互の通信状況に応じてサーバとクライアントの役割を分担します。ユーザの意思 でデータのやり取りをするので、それを管理するコンピュータが存在しないのが特徴です。実際 の動作としては、ユーザの持つホストリストから記載されているピアへコンテンツを要求し、 相手のピアがそのコンテンツを持っていれば接続が行われます。持っていない場合は、 相手ピアが自分のホットリストを参照して、記載されているピアへ要求をだし、コンテンツが あれば最初の要求をだしたピアへ所在を送信します。それに基づいて要求元のピアとコンテンツ を持つピアとの間で、接続が行われます。Gnutella[2]やWinny[3]がこの方式になります。

2.1.1 Gnutella

 Gnutella[2]はJustin FrankelとTom Pepperによって開発されたファイル共有アプリケーションで す。検索によってファイルが見つかった場合には、検索者とファイルの保持者が直接接続し HTTP[4]によって転送されます。Gnutellaはサーバを置かないピュア型P2Pシステムです。 サーバが無いためユーザ同士が接続することで、GnutellaNetという仮想的なネットワークを 形成します。そのネットワーク内でファイル共有を提供します。Gnutellaでの検索は後に 紹介するNapsterのサーバに相当するものがなく、仮想的なネットワークであるGnutellaNetに 検索要求をだします。GnutellaNetに接続されたサーバント群に検索要求を行うことで目的の ファイルを見つけだします。GnutellaNetに接続するために参加しているユーザの端末 [サーバント]と接続しますがユーザの頻繁な離脱があるためGnutellaでは、デフォルトで 常に4台のサーバントとの接続を想定しています。検索においてGnutellaはフォワード機能を 搭載しているので、自サーバントが要求する検索依頼を接続している4台のサーバントに依頼する ことで、このサーバントは自分のインデックスを検索します。同時に、自分が接続している次の 4台のサーバントにそれぞれの検索依頼をフォワードします。各サーバントがこのフォワードを 行うことで、Gnutellaは、直接接続しているサーバントだけでなく、その先にある多くの サーバントにも同じ検索依頼をかけることができます。検索結果によって目的のファイルを もつ サーバントにダウンロード要求を行います。このとき自サーバはダウンロードしたいファイルを 持っているサーバントを特定できているので、ファイルを持つサーバントに対して直接接続して ファイルをダウンロードします。

2.1.2 Winny

 Winny[3]は中継転送とキャッシュにより公開者や取得者の双方が匿名のままファイルの配布を 行 うことができるファイルの共有アプリケーションです。ファイルの保持者がオーバレイネット ワーク上の近隣のノードに保持情報を広告します。保持情報を受け取ったノードはそれぞれ 自分の所得条件に適合するかを調べ、適合すればそのファイルを取得します。保持情報を 各ノードが転送する際に保持者IPアドレスを書き換えるので、ファイル保持者の匿名性が 守られます。転送の際は、書き換えを行ったノードを逆にたどり保持者と接続します。 Winnyでは、帯域幅と優先度の二つのパラメータから動的に構成されます。高速な回線を持つ ノードがより多くの保持情報や検索要求を処理できるように帯域幅によって階段的にぶらさがる ようにノード間のリンクを張ります。さらに似た傾向のファイルを 持つノードをオーバレイネットワーク上で近くに配置するため任意に指定したクラスタ化 キーワードをリンク接続時に交換し、その類似度をノードの優先度とします。さらにその ノードからファイル転送が成功した場合に優先度を増加させます。決められた接続数上限を越えて接続された場合には、優先度の低いノードから順にリンクを切断します。通信者から中継者に至る経路上に狭い帯域幅や遅延の大きい回線があると直接転送する場合に比べて極めてパフォーマンスが落ちます。

2.2 ハイブリット型P2P

 もう一つは、「ハイブリット型P2P」と呼ばれるものです。完全なP2Pと、 クライアント・サーバー型の中間にあたるものです。サーバー・コンピュータを用いるので、 クライアント・サーバー型と違いがないように思われます。ハイブリット型P2Pの サーバー・コンピュータはユーザのコンピュータへの過度な干渉はしません。 サーバ−・コンピュータはピアのもつコンテンツと所在を管理し、ユーザからの問い合わせに 応えるだけです。実際のやり取りは、サーバーを介さずに、ユーザのピア同士で行います。 実際の動作としては、ユーザは、要求するコンテンツの所在をサーバー・コンピュータに 問い合わせます。サーバ−・コンピュータは一元的に保持している情報から要求されたものに そうコンテンツを持つピアの所在を要求側のピアに返します。その検索結果をもとに、 要求元のピアとコンテンツを持つピアとの間で、接続が行われますNapster[1]やWinMX[5]が、 この方式になります。ネットワークの一部をサーバー・コンピュータが管理するので、 通信が円滑に行われやすいという特徴をもちます。しかし、その反面、 サーバ・クライアントシステムと同じように、検索数が多くなるとサーバの負荷がまします。 そして、サーバーの事故が直接ネットワークの停止に結びついてしまします。

2.2.1 Napster

 Napster[1]は、初の共有ソフトです。ユーザーは必ずどこかのサーバに接続し検索やファイルのやり取りはそのサーバを経由します。NapsterはMP3専用のファイル共有システムです。Napsterは、中央にサーバをおくHybird型Peer-to-Peerシステムです。サーバはユーザのアカウント情報とユーザが共有しているmp3ファイルのインデックス情報を保持しているだけで、実際のmp3ファイルは各サーバントにあります。Napsterは、Napster.comのドメインにログインすべきサーバを割り当てるリダイレクトサーバと、実際にログインして検索処理を行うログインサーバがあります。リダイレクトサーバは、サーバに負荷分散と拡張性の配慮するために設置されたサーバで、ロードバランシングの役目を担っています。ユーザは、リダイレクトサーバの振り分け先に新たなログインサーバを追加する設定だけですむため、サーバの増設が簡単に行えます。ログインサーバは、ユーザのアカウント情報にしたがってログイン処理を行い、やー場ントから送られれくる情報を基に共有しているmp3ファイルのインデックスを作成します。サーバントからの検索要求に対しては、インデックス情報を検索して結果を返します。また、ダウンロードの処理を仲介したり、また、チャットサーバの役目もになっています。

2.2.2 WinMx

 WinMX[5]はユーザーとユーザーを繋ぐために、サーバを介する共有システムです。機能的な役割を見た場合、ほぼGnutellaと同一の機能を有しています。Gnutellaとの最大の違いは日本語ファイルの検索機能の能力に尽きます。Gnutellaでも、日本語ファイルの利用は可能でしたが、2バイト文字をアルファベット2文字と検知しているらしく、部分一致しているモノをすべてリストアップするといった特性上、日本語で検索をかけた場合、関係のない英語ファイルが見つかる場合が多く生じました。WinMXは元々Napsterのクローンソフトとして開発されました。Napsterとの違いはWinMXでは、サーバ機能もユーザーに任されている点です。Napsterはすべてのユーザーが設置されているサーバに接続するが、WinMXではある特定の条件が整っているユーザーは自動的にサーバになります。このサーバのことを日本では親サーバと呼ばれています。一般のユーザーは子と呼ばれ、子は親サーバに接続し、親サーバは大本のサーバに接続します。大本のサーバはWPNPと呼ばれます。WinMXピアネットワーキングプロトコルの略で、WinMX用のサーバの名称として使われます。子は自分の共有しているファイルリストや検索の要求などを親に送信します。親は子からの検索要求をWPNPに発信し、そこから他の親に送られ、その親に繋がっている子に届きます。WPNPはかなりの作業を親サーバにまかせることができ、負端を軽減することができます。しかし、親の回線速度、品質によって親がダウンロードやアップロードを開始すると、それに繋がっている子の検索要求が通らなくなることがあります。また、子の持つファイルに対する検索や接続の要求が通りにくくなることもあります。親もまた一般のユーザーであるため頻繁に離脱する。そりにより子のIDが変わってしまいます。どちらの方法にたいしても、いくつかの改善策が提案されています。サービスの安定した提供を実現するために、P2Pのシステム上、より多くの希望するコンテンツの所在を見つけることで、安定性がますというのが基本的な考え方であります。ここで、いくつか具体的な研究事例をあげます。

2.2.3 Amonphic Net

 さきほど、述べたようにHybrid P2Pの方式の問題点のサービスを提供するピアの所在を を管理するために置いたサーバへのアクセス集中の解決作として、必要に応じて所在を管理するサーバを動的に生成しなおかつ適宜再配置することで、負荷一極集中と、トラフィック増大ともに回避するP2Pシステム「AmorphicNet」[6]が提案されています。各ピアは、自身を通過するパケットから所在情報を取り出してキャッシュし、他からの問い合わせに合致するものがあれば返信することで、トラフィック軽減にも寄与します。そして、トラフィックが一定値を越えたノードは、自らのキャッシュ内容を位置情報として持つサーバに自らを格上げします。サーバへのアクセスが増加して負荷が高まった場合、自身を利用しているノードの一つにサーバ格上げ要請をして、自らのインデックス情報を渡します。これらのサーバ群は親子関係に従って階層を構成します。アクセスが減少して複数のサーバが必要なくなったら、平ノードに格下げします。

2.3 P2Pにおける様々な技術

 位置情報と実際の提供されるサービスを複製して別のピアに作成する、レプリケーションと呼ばれる方法があります[7]。レプリケーションとは、提供されたサービスの複製(レプリカ)を別のピアに配置することであり、たとえばファイル取得サービスであれば要求されたファイルの複製を一つまたは複数の別ピアにコピーすることを表します。レプリケーションの手法には幾つかありますが、サービス提供ピアおよび受信ピア間の経路上に存在するピアに複製を配置するPath Replicationを採用しています。レプリケーションにより、一つのサービスは複数のピアによって提供可能です。したがってそのうち一部のピアが論理ネットワークから離脱した場合でもサービスは複数のピアが検索にたいして応答できることから、サービス提供までの遅延の軽減が期待できます。さらに、検索の結果得られた複数のピアから、通信速度がもっとも大きいピアを選択することも実現可能です。レプリケーションはピアのP2P論理ネットワークからの離脱への耐性向上、検索時間の短縮などの利点があります。このレプリケーションの配置方法に着目し、物理ネットワークの特性を考慮した配置手法[8]が提案されています。特に、P2P論理ネットワークが持つべき法則(power-law)[9]の性質を利用し、ピアの離脱などによる論理ネットワークの安定性定価を向上させるレプリケーション配置手法が提案されています。
 実際のサービスを提供するうえで、遅延は安定性の低下をまねくおおきな要因の一つです。提供するサービスを持つピアが少ない場合、サービスを希望するピアが多ければ多いほど遅延は大きくなると思われます。なにより、P2Pの性質上、サービスを得る確実性を下げることになる。そこで、できるだけ、多くのピアに同時に配信することが、遅延を防ぐことに繋がります。 動画などのコンテンツ配信の分野にもちいて、送信効率を上げ、送信速度を向上させる方法として、オーバレイネットワークを用いて、擬似マルチキャストを実現するP2Pストリーミング配信システムがあります。これらはストリーミングを受信しているノードがさらに別の受信ノードに中継送信を行うことで動的に配信ツリ-を形成し、配信主の帯域を圧迫することなく大量のノードに同一のストリーミングを配信できます。このPeer-to-Peerストリーミングには、オーバレイネットワークへの参加ノードの一覧を保持する仲介サーバを利用するものと、仲介サーバなしで、配信ツリーを構築するものに分けられます。前者に含まれるものとしてシェアキャスト[10]、後者に含まれるものとしてPeerCast[11]があります。  1対多、多対多型通信形態を実現する層として、ネットワーク層[ルータ]とアプリケーション層[ホスト]の二つがあります。後者をALM[12](Application-Layer Multicast)と呼びます。ALMは、ホストだけを構成要素とするオーバレイネットワークの上にマルチキャストツリーを形成し、そのツリーに反ってホスト間をバケツリレー式にデータが転送される。これは、IPマルチキャストインフラを必要としない多地点ストリーム配信技術で、同一のデータを同時に複数のホストに配信することができます。

3 Gnutellaの詳細

 現在のGnutellaのファイル獲得の流れは、検索要求に応えたホストに接続要求をだし、その結果相手が接続が可能であればファイルのダウンロードが開始されます。この章では実験のモデルとした、Gnutellaの仕様について述べます。

3.1 .Gnutellaの動作概要

 Guntellaは、基本的なPure型Peer-to-Peerです。Gnutellaは、Serverを置きません。Serverがないため、サーバント同士が接続する事でGnutellaNetという仮想的なネットワークを形成し、ネットワーク内でファイル共有を提供します。 GnutellaNet に接続するためには、最初に接続するサーバントのアドレスを知る必要があります。このアドレスは、GnutellaNetのアドレスとしてインターネット上で公開されています。このアドレスをテキスト形式のGnutella.netファイルに記述することで、GnutellaNetへ接続することができます。GnutellaNetのアドレスにあるサーバントはいつも稼動している保証がないため、複数のGnutellaNetアドレスに対して接続を試み、応答があったサーバントをGnutellaNetの入り口として仮想ネットワークに接続します。このためGnutellaNetへの接続時に、いくつかのトライ・アンド・エラーが発生するため、ネットワークに参加するためにはある程度の時間がかかります。自サーバントに対してもほかのサーバントからの接続要求があるのでこれに応答することで自分を通してGnutellaNetへ接続するサーバントがあります。GnutellaNetへの入り口として利用していたサーバントがネットワークから離脱することがあります。その時は別の稼動しているサーバントを探して接続する必要があります。このため可変的なネットワークであるGnutellaNetへ接続するために、複数のサーバントと接続を維持しておきます。Gnutellaは常に4台のサーバントと接続を想定しています。また、転送速度の低速なサーバントはよりGnutellaNetの末端へ降格されます。これは転送速度の高速なサーバントがより多くのトラフィックを処理したほうが良いからです。  Gnutellaでは、ファイルを検索する際にインデックスを持つサーバに相当する機能を持つサーバントがないので、仮想的なネットワークであるGnutellaNetに検索要求をだします。GnutellaNetに接続されたサーバント群に検索要求をだすことでファイル検索を実現します。Gnutellaでは各サーバントにフォワード機能を搭載しています。自サーバントが要求する検索依頼を接続している4台のサーバントに依頼することで、このサーバントは自分のインデックスを検索します。同時に自分が接続している次の4台にサーバントにそれぞれの検索依頼をファワードします。各サーバントがこのフォワードを行うことで、Gnutellaは直接接続しているサーバントだけでなく、その先にあるサーバントに検索依頼をかけることができます。検索依頼にたいして一致するファイルを持つサーバントは検索結果を返信します。このとき検索依頼が運ばれてきた同じ経路をに沿って返信されます。 GnutellaでのファイルのダウンロードはGnutellaNet上で転送されることはありません。ファイルは直接ダウンロードされます。検索依頼にたいして返信されてきた内容をもとにサーバントは目的のサーバにダウンロード要求を出します。ファイルのダウンロードプロトコルはHTTP1.1です。 GnutellaNetへ接続やファイルの検索、その返信はGnutella独自のGnutellaプロトコルによって通信を行います。

3.2 Gnutellaのメッセージ

 GnutellaNetへ接続やファイルの検索、その返信はGnutella独自のGnutellaプロトコルによって通信を行います。通信メッセージはヘッダとペイロードにわけられています。

3.3 Gnutellaのプロトコル

 ここではGnutellaのプロトコルを例に用いて説明します。


 A:ダウンロード側

 B:アップロード側

1、	AはBの持つファイルをダウンロードしようとするがBに接続できない場合 GnutellaNetにPushを送ります。Pushには、Aのア
        ドレス、ポート、Bのダウンロードしたいファイルの
        インデックスを書いてあります。
2、 Bが運良くPushを受け取って自分のGUIDと一致すれば、BはAのアドレスのポートに直接 接続してGIVを送ります。
3、 Aの欲しいファイルがGIVのファイルと一致すれば、その接続をそのまま使って GETリクエストを送ります。後は通常のダウンロードと同じです。次に具体的な流れを説明します。


1 まず検索をかけて所在を見つけ出すところまでは、現在のシステムと同じです。 次に希望ファイルを持つサーバントがQueryを受け取りQueryHitを返します。 このときに提供側のサーバントはアップする側のサーバントのIPアドレスをキャッシュ しておきます。これにより、このサーバントに対してQueryが別のサーバントから来た場合 QueryHitのIPアドレスは現在アップをしているサーバントのIPアドレスで返します。 ダウンロード要求は現在アップをうけているサーバントに対して行います。原則として、 現在ダウンロードをしているファイルに対する他のサーバントからのダウンロード要求に 対しては提供を開始するようにします。また、その時にすでに他のサーバントに対して 提供を行っている場合は、そのサーバントのIPアドレスをのせたQueryを返すとします。 なお、Gnutella のくわしいプロトコルの内容は付録を参照してください。

4章 本研究

4.1 Gnutellaの問題点と本研究の目標

 ここでは、P2Pにおける、情報の伝達時間について考えます。 例えば、1対1の通信でT秒かかるファイルを1024人のパ−ティにおいて 1人だけが持っているとします。すると単純に全員が転送要求を同時に出した場合、 ネットワークを公平に使うことで、全員がファイルを獲得するのに1023T秒かかります。 一方、次の条件を考えます。
1. 転送は1度には1人にしか行わない

2. ファイルを獲得した人は、他人にファイル転送ができる

3. 転送要求は完璧にコントロールされ、転送可能になった人は必ず次からは他の人への 転送を行います。

このような条件では、最初のT秒でファイルを持つ人が2人になります。 次のT秒ではこの2人が別の2人に転送するため、ファイルを持つ人が4人になります。 最終的には10T秒で1024人にファイルが渡ります。この条件では、このようにファイルの分配者を 分散せせることができれば遅延を減らすことができます。 目的のファイルを持つノードを見つけたとしても必ず、 すぐにダウンロードが開始されるわけではありません。 これは、見つけたノードが他のノードに対して、 ファイルの提供の途中である場合です。この場合、最大接続数の制限により、 他のダウンロードが終わるまで接続を断られることがあります。 そこで、この待ち時間をいかに減らすかを考えます。 上記のような極端な仮定のもとでは単純な計算で、 情報が行き渡るまでの時間を調べることができましたが、 現実のP2Pのモデルとはかけ離れています。 そこで、本研究ではP2Pを単純化したモデルでシミュレーションを行い、 どのようなパラメータを設定すると情報伝達が早くなるかを調べました。 次節ではシミュレーションにおける、おもな条件について説明します。

4.2 シミュレーションの条件

ファイル交換をするネットワークの構成は、Gnutellaネットワークと同じタイプのPeer-to-Peer型を採用します。 ネットワークに参加する各ノードは複数の他のノードと繋がっています。最初の時点で、 ファイルを持つノードはネットワーク上にひとつとします。待ち時間は検索がヒットしてから ダウンロードが開始されるまでの時間と検索がヒットするまでの時間の合計とします。検索は毎回行い、 転送要求に対する返答はランダムに行われます。参加ノード数、転送時間、帯域(同時に送ることのできるノード数)、 検索範囲は実験の種類によって変化させて、シミュレーションを行います。GnutellaNetを次のように理想化してます。
・全サーバントの能力は等しい ・各通信リンクの伝送量、スループットは一定で等しい ・ファイルのダウンロードは検索結果が返ってきたら0秒で開始される。完了までにかかる時間を一定とします。 このような条件において、次の検索条件による転送効率を比較しました。 ・一度に全体に対して検索をかけられ、0秒で結果が返ってくる ・任意の距離以内にのみ検索をかられ、0秒で結果が返ってくる なお比較のため以下のような異なる状況についてそれぞれシミュレーションを行いました。 ・同時転送数と検索範囲を変えた時 ・同時転送数とノード数を変えた時 ・頂点数と同時転送数を変えた時

4.3 シミュレーションプログラムの概要

 シミュレーションプログラムはJava2SDKを使って作りました。バージョンは1.2.2です。 プログラムは大きく分けて4つから構成されています。newsim、ServantList、Servant、の 3つのクラスとシミュレーションの条件に関わる変数をまとめたConstantからできています。 プログラムは付録に添付しました。
・newsimクラス
 メインクラスです。ServantListのインスタンスを作り、シミュレーションの条件に合わせて
  ノードを生成した後、ノード間の通信を1ステップずつシミュレーションします。
  全体に情報が行きわたった時、かかったステップ数を出力して終了します。
・ServantListクラス
  ServantListクラスでは、要求中、転送中、完了の3つのグループからなります。
  Servanntのリストを保持し管理します。
  Servantをリストに追加するadd CarriedNod(),addEmptyNod()メソッド、
  ネットワークを作成するmakeRandamConnection()メソッド
  lstep通信をシミュレーションするplay()メソッドなどがあります。
・Servantクラス
 個々のノードを示します。隣接ノードと転送中のノードのリストを保持します。
  検索リストを作る lookup()メソッド
 転送を受けつける ack()メソッド
 lstep転送を行うdeliver()メソッドなどがあるます。
・Constant
 シミュレーションの条件を変える時に書き換える変数が5つあります。
 CarrideNod:情報をもっている頂点数
 EmptyNode:情報を持っていない頂点数
 Connections:各頂点の要求接続ノード数(平均接続数は×2)
 Distance  :検索の深さ
 MaxTrans :同時転送数
次に個々のサーバントの動作について説明します。
サーバントの状態はファイルを持っている状態と持っていない状態の2つです。
動作は要求中ノード、転送中ノード、完了ノードの3つの動作があります。

検索及び転送要求の処理はServantListクラスのprocessRequireで処理されます。

・検索の動作は要求中ノードのリストに対して以下を処理します。
・Distaneによって決められた範囲を指定して、lookup()メソッドで検索リストを得ます。
・得たリストからランダムに1つノードを選びます。
・そのノードに対して、ack()メソッドを送ります。
・もしack()メソッドが受けられたら要求中ノードを転送中ノードリストへ移します。

転送及び完了の処理はServantListクラスのprocessTransferringで処理されます。
・完了ノードが保持されているリストにあるServantに対してdeliver()を送ります。
・転送中のリストにあるServantに対して転送が終わってか調べ、終わっていたら、
完了ノードのリストに移します。

以上を参加するノードがすべてファイルを持つ状態になるまで
newsimクラスは処理を繰り返します。処理が終わると掛かった時間を表示して終了します。

4−4 結果


 実験1

 まず検索範囲を3にした場合と全体に検索を掛けた場合について実験をおこないました。 これにより検索範囲を限定することがファイルの配布効率を良くするかを調べました。

設定 参加ノード数5から1500まで変化させます。
     検索範囲3以内の頂点数は3とします。
     ファイルを持つノードは1つ。
   接続頂点数 1
   同時転送数 1




図1、全体検索と3ノード以内の検索における結果  
結果に大きな差が生じることはありませんでした。この条件では検索範囲の影響よりも、 参加ノード数の値がファイルの配布効率に与える影響が大きいと考えられます。

実験2

 次にそれ以外の設定がどう影響をもたらしているかを調べます。 まず同時転送数と頂点数の影響について調べました

設定 同時転送数1から101
   接続頂点数1から10
   参加ノード数=1000
   ファイルを持つノード=1
    検索範囲=1

   



図2 頂点数と同時転送数の関係
接続頂点数数が1の時はファイルが配布されるネットワーク網と繋がらない離れ島状態に なってしまい全体にファイルが行き渡らない状態が発生してしまうことがありました。 接続頂点数が同じ場合、同時転送数が増加するにともない完了時間は増加します。 小さい場合、接続頂点数が増加してもあまり差は生じませんでした。 しかし、同時転送数の値が大きい場合は完了時間の差は大きくなります。以上のことから  (1)同時転送数を増やすと配布効率が悪くなる  (2)接続頂点数が多くなると効率の悪くなりかたがひどくなる、少ない時には悪くなりにくくなる ことがわかりました。

実験3

 検索範囲と同時転送数の関係について調べました。 これにより、検索範囲に同時転送数が、どのように影響を与えるかを調べました。

設定  同時転送数1から100
     検索範囲1から5
     頂点数=2
     参加ノード数=2000
     ファイルを持つノード数=1





図3、同時転送数と検索範囲の関係

検索範囲が1の時はほとんど変化しませんでしたが、検索範囲が2以上になると 同時転送数の影響を受けるようになりました。 このことから、検索範囲を狭めると同時転送数の影響をあまり 受けなくなるという結果が得られました。

 実験4

 参加ノード数と同時転送数による変化を調べました。 検索範囲が1の場合と2の場合について調べました。

設定  同時転送数1から5
     参加ノード数1から1000
     ファイルを持つノード数=1
     頂点数=2
     検索範囲1または2





図4参加ノード数と同時転送数(検索範囲=1)の関係



図5 参加ノード数と同時転送数(検査範囲=2)の場合



図6 参加ノード数と同時転送数(検索範囲=1)の近時値曲線



図7 参加ノード数と同時転送数(検査範囲=2)の近時値曲線

検索範囲が1の場合も2の場合も参加ノード数の増加、 同時転送数の増加にともない完了時間は増加しました。 同時転送数がどの値であっても参加ノード数が一定以上になると 完了時間は大きく変化しなくなりました。 同時転送数によって参加ノード数の増加にともない完了時間は増加しています。 このことから、参加ノード数をnとして、完了時間をT、定数aとして、図6、図7から T=alog10nより、 定数aと同時転送数の関係をグラフに表しました。



図8 同時転送数と定数aの関係
以上の結果から、検索範囲1,2の完了時間Tを
T=(14+2.0×MaxTrans) )log10n
T=(4.2+0.8×MaxTrans)log10n
で求めることができました。

実験5

 最後に完了時間に影響の大きい同時転送数と頂点数を100にして、条件の悪い場合での完了時間を調べました。検索範囲を1と2の場合について行いました。

設定  参加ノード数を1から1500
     検索範囲を1の場合と2の場合
     ファイルを持つノード数=1
     同時転送数=100
     頂点数=100





図8 同時転送数と頂点数を100にした場合

条件が悪いので参加ノード数が少数であってもかなりの時間が掛かりました。 この設定の場合でも参加ノード数が少ない時点では急激に完了時間は増えていくが、 その後は緩やかな曲線になりました。また、検索範囲はあまり関係ありませんでした。

5 検討

5.1 結果について

 P2Pにおける仮想ネットワークや、サービスのパラメータとして 同時転送数、接続頂点数、検索範囲を変化させて、ネットワーク全体への情報、 伝搬速度をシミュレーションで解析しました。その結果予想とは大きく異なる結果がでました。 同時転送数、接続頂点数、検索範囲とも、 増やすほどサービスが向上するように思えますがどれも増やせば増やすほど速度は 低下していきました。特に同時転送数は増やすと顕著に速度は低下しました。 ただし、接続頂点数が少ない場合は同時転送数の影響は少なくなります。 原因について考えると、同時転送数を増やすと1回の転送にかかる時間が増えることが 考えられます。ここで、非常に理想的な条件で理論式を導きます。 全ての転送数が同時転送数に等しい場合を考えます。同時転送数をd,転送数の深さをk としましす。


@	d=2〜5の時のNとTの関係
A	Nを固定しておき、dとTの関係
以下の場合についてあげました。



図10 NとT の関係



図11 dとTの関係
Nが十分大きければTはほぼlognに比例して増加し又、 これは、dが増えるとTも増えるのが実験結果と一致します。

5.2 提案システムの実現可能性について

 検索範囲を限定することよりも同時転送数を少なくすることでファイルの配布効率を良くしたシステムを 実現することができると考えられます。また、同時転送数を増やした場合には検索範囲の値によって完了時間も増加するので 同時転送数が多い時には検索範囲を狭めることが効果を発揮するシステムを実現できると考えられます。

6,まとめ

 検索やダウンロードの範囲を限定することは、全体での完了までの時間を考えると、 効率をよくすることには繋がらないという結論になりました。効率を良くするためには、 同時転送数を少なくすることが最も配布効率を良くすることに繋がると考えられます。 これは同時転送数が多いほどファイルを持つノードが配布するノード数が増えることになるので、 一極集中と同じ状態になると考えられます。そのため同時転送数を少なくすることは要求を断ることにつながりそれが、 分散化に繋がったと考えられます。また、頂点数や検索範囲は同時転送数が大きい値なほど完了時間は増加します。 頂点数においては少なくとも1以上にしないと離れ島現象で全体にファイルが行き渡らないことがあります。 以上のことから、同時転送数を少なくし、より早い時間でファイルを持つノードを確実に増やしていくことが 配布効率を良くすることに繋がるという結論になりました。

参考文献

[1]http://napster.com/
[2]http://gnutella.wego.com/
[3] http://winny.info/
[4] http://www.studyinghttp.net/
[5]http://www.xinmx.com/
[6]インデクスサーバを動的生成配置するP2PシステムAmorphicNet
  内田良隆 吉田紀彦 樽崎修二
[7]Q.Lv,P.Cao,E.Cohen,K.Li,and S.Shenker,”Search and replication in unstructured peer-to-peer networks”,in Proceedings of 16th ACM International Clnference on Supercomputing(ICS’02),June 2002.

[8]]P2Pネットワークにおけるサービス安定性向上のためのレプリケーション配置手法
    後藤嘉宏 阿多信吾 村田正幸
[9] A-L.Barabasi and R.Albert, “Emergence of scaling in random networks,”Science,vol.286,pp.509-512,1999.

[10]  http://www.scast.tv/scast/
[11]  http://peercast.gooside.com/
[12] RelayCast:ピアツ−ピア型ストリーム配信のためのミドルウェア
    三村 和  中内 清秀  森川 博之  青山 友紀


付録

ヘッダー
byte概要説明
0〜15メッセージ識別子これはWindowsのGUIDだ。私はこれがどのように globally-uniqueであるべきなのか本当に理解しているわけではない. それは特定のメッセージを既に見たものかどうか判断するのに使われている。
16ペイロード識別子(function identifier)値 機能
0x00 Ping
0x01 Pong (Pingへの応答)
0x40 Push request
0x80 Query
0x81 Query hits (Queryへの応答)
17TTLTime to live. TTL値はフォワードされる度に1づつ減算される。 もし1より小さいTTLをもつ受け取ったメッセージは、 フォワードされるべきではない。
18Hopeこのメッセージがフォワードされた回数
19〜22<ペイロード長/TD>続くペイロードの長さ。

PINGはペイロードはありません。
ペイロード:pong
byte概要説明
0-1ポート番号IPv4でのポート番号
2-5IPアドレス IPv4でのIPアドレス。x86のバイトオーダーでリトルエンディアンです
6-9ファイル数そのホストが共有しているファイルの数。
10-13キロバイト数そのホストが共有しているキロバイト数

ペイロード:query
byte概要説明
0-1最低速度この要求に応答するべきサーバの最低速度(キロビット/秒)
2検索基準検索キーワード、あるいは他の判断基準。NULLで終了

ペイロード長:query hit
byte概要説明
0ヒット件数 (N)この設定でのヒット件数。後述する"検索結果の集合"を参照。
1-2ポート番号IPv4でのポート番号
3-6IPアドレスIPv4 でのIPアドレス。x86 のバイトオーダーはリトルエンディアンです
7-10速度応答中のホストの速度(キロビット/秒)
11+検索結果の集合これらの属性がN個ある (上述の"ヒット件数" を参照).

bytes   概要      説明
0-3   インデックス   ファイルのインデックス番号
4-7    サイズ      バイト単位のファイルサイズ
8     ファイル名    ファイルの名前。終端は二重のNULL。
Last 16bytesクライアント識別子応答中のホストのGUID。PUSHで使われる

ペイロード長:push request
byte概要説明
0-15クライアント識別子プッシュすべきホストのGUID
16-19インデックスファイルのインデックス番号(クエリーヒットで与えられたもの)
20-23IPアドレスIPv4でのプッシュ先アドレス
24-25ポートIPv4でのプッシュ先のポート番号


プログラムリスト


   
import java.util.*;
interface Constant {
    final static int CarriedNode=1;//the number of nodes that have the information
    final static int EmptyNode=1000;//the number of nodes that want the information
    final static int Connections=2;//the number of connections
    final static int Distance=7;//the depth of searching
    final static int MaxTrans=8;//the number of accepting transferring
}
class newsim implements Constant {
    public static void main(String args[]){
ServantList sl=new ServantList();
sl.addCarriedNode(CarriedNode);
sl.addEmptyNode(EmptyNode);
sl.makeRandomConnection(Connections);
//sl.showMap();
int timer=0;
while(!sl.finished()){
    sl.play();
    System.out.println(timer);
    sl.show();
    timer++;
}
System.out.println(timer);
    }
}
class ServantList implements Constant {
    ArrayList requiring;
    ArrayList receiving;
    ArrayList carried;
    static Random random=new Random();
    ServantList(){
requiring=new ArrayList();
receiving=new ArrayList();
carried=new ArrayList();
    }
    void makeRandomConnection(int width){
ArrayList l=new ArrayList(requiring);
l.addAll(carried);
for(Iterator i=l.iterator();i.hasNext();){
    Servant s=(Servant) i.next();
    for(int j=0; jMaxTrans){
    return false;
}
transferring.add(s);
return true;
    }
    void deliver(){
double amount=1.0/(double)transferring.size();
for(Iterator i=transferring.iterator(); i.hasNext();){
    Servant s=(Servant) i.next();
    if((s.receiving+=amount)>=1.0){
i.remove();
    }
}
    }
    boolean finished(){
return receiving>=1.0;
    }
    int getID(){
return no;
    }
    ArrayList lookup(int distance){
ArrayList l=new ArrayList();
if(distance>0){
    for(Iterator i=neighbor.iterator(); i.hasNext();){
Servant n = (Servant) i.next();
if(n.finished()){
    l.add(n);
}
l.addAll(n.lookup(distance-1));
    }
}
return l;
    }
    void join(Servant s){
neighbor.add(s);
    }
    void showNeighbor(){
for(Iterator i=neighbor.iterator(); i.hasNext();){
    Servant n = (Servant) i.next();
    System.out.print(n.getID()+" ");
}
System.out.println();
    }
}