平成20年度

筑波大学第三学群情報学類

卒業研究論文

題目各種ルータに対応する

ユーザ透過なP2P通信環境

に関する研究

主専攻 情報科学主専攻

著者 鈴木良平

指導教員 朴泰祐

要　　旨

P2P通信環境でノード間通信を行う場合，NATやファイアウォールなどの機能によってノードが保護されているため，簡単に通信できないという問題に直面する．もし多数の PCを効率的に接続，通信することができれば大きな計算資源を手に入れることができる．そこで本研究ではUPnPとUDP hole punchingの 2つのNAT越え技術を用いて，NATbox（家庭用ルータ）の種類や P2P通信環境に合わせて自動的に最適な通信方式を選択することでユーザ透過な P2P通信を可能にする．まず，UPnP機能を利用することで，UPnP対応のNATboxの特定のポートを開け，そのポートを使って，NAT 内側へのインバウンドの TCP通信をした．次に，UDPパケットを何回か送信することで，UDP hole punchingにより，UDP通信を可能にした．さらに 2つの通信方式をユーザ透過に選択，決定するシステムと，一般ノードの情報を自動登録し，相手ノードの検索を行うためのスーパーノードのシステムを実装した．UDP

hole punchingを行った場合のノード間のスループットは，手動でポートを開けた場合に比べ，約半分まで低下した．また，UPnP機能を利用して行った TCP通信と，手動で NATboxの設定をして NAT 越え問題を回避した TCP通信とのスループットの差はほとんどなかった．以上の結果より，UPnPの優先度を高く設定し，システムの実装を行い正しく動作することを確認した．しかし，UPnP機能を用いてポートを開けるのに 6秒ほどかかったため，UPnP機能を用いて通信する場合には接続する一般ノード数のスケーラビリティに関し、さらに詳細に検討する必要があることがわかった．

目次

第 1章 序論 1

第 2章 研究背景と目的 22.1 P2Pとその分類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 NAT技術とその問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 NAT越え技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 リレー方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Universal Plug and Play. . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.3 UDP hole punching. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.4 TCP hole punching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 各種 NATboxに対応する NAT越え技術の実現 . . . . . . . . . . . . . . . . . 8

2.5 関連研究 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

第 3章 ユーザ透過に NAT 越えを行う通信システムの設計 103.1 システムの全体構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 スーパーノード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 通信モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1 リレーモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.2 UPnPモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.3 UDP hole punchingモジュール . . . . . . . . . . . . . . . . . . . . . . 13

3.3.4 RUDPモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.5 TCP hole punchingモジュール . . . . . . . . . . . . . . . . . . . . . . 15

3.4 通信方法の優先度付け . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

第 4章 実装 184.1 UPnPモジュールの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2 UDP hole punchingモジュールの実装 . . . . . . . . . . . . . . . . . . . . . . 22

4.3 スーパーノードの実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

第 5章 評価 245.1 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.2 動作確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.3 評価方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

i

5.4 結果と考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

第 6章 結論 296.1 まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.2 今後の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

謝辞 31

参考文献 32

ii

図目次

2.1 制限付き Cone NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Symmetric NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 TCP通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 リレーノード方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 TCP hole punching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 想定するシステムの全体構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 リレーノードモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 UDP hole punching:ERROR. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.4 UDP hole punching:SUCCESS. . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.5 TCP hole punching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 M-SEARCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 DeviceDescriptionの例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 DeviceDescriptionの木構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Action命令のレスポンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 評価環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.2 before UPnPモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 after UPnPモジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 各通信方式のスループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iii

第1章 序論

現在非常に多くのPCが家庭や企業，学校などに散在している．それらのうち遊休状態にある PCを，何らかの方法で統合し相互通信させる P2P (Peer-to-Peer)環境で接続して分散コンピューティングに利用する，Volunteer Computingに関する研究が盛んに行われている．これらのPC同士を接続し，アプリケーションにとって使いやすくするためにはP2Pによるスケーラブルなネットワークが必要である．しかし，それらのPCの多くはNetwork Address Translation

(以下，NATと呼ぶ)やファイアウォール機能を持つルータに接続され，外部ネットワークからはその裏に隠された状態にあるため，他の PCからのインバウンド接続を受けることが容易ではない．P2Pによるスケーラブルなネットワークを実現するためにはファイアウォールや NAT を超えて直接接続する必要がある．今まで NAT 越えを実現する技術として UPnPやUDP hole punching，TCP hole punchingなどの技術が提案，実装されている．本研究では，複数の通信方式をNATbox（家庭用ルータ）の種類や，P2P通信環境に合わせて自動的に選択するシステムの実装を目的とする．複数の通信方式を実装した後は，信頼性が必要な場合，スループットが必要な場合など状況に合わせて自動的に通信方式を選択する．そのため，各通信方式に優先度をつけるために，あらかじめ各通信方式の十分な評価が必要となる．また，ハイブリッド P2P上でスーパーノードに一般ノードの情報を自動的に登録させ，通

信相手の検索時間を削減する．更にそのスーパーノードにおいて，負荷を分散させるために独自の DHT (Distributed Hash Table)についても検討を行う．本論文の構成は以下の通りである．2章ではP2P通信環境とNATの問題点について述べ，3

章ではユーザ透過に NAT越えを実現するシステムの設計について述べる．4章では，3章で設計したシステムの実装について述べ，5章では設計したシステムについて評価を行う．最後に 6章で結論を述べる．

1

第2章 研究背景と目的

本章では，P2P通信環境と，そこで発生するNAT越え問題について述べる．またその問題の解決方法を提案する．

2.1 P2Pとその分類

一般的に P2P (Peer-to-Peer)とは，不特定多数の PCがネットワーク上に参加し，それら PC

同士が特定のサーバを介さずに通信するネットワーク形態のことである．また，P2Pのネットワーク形態はいくつかの種類に分類される．以下では代表例として “

ピュア P2P”と “ハイブリッド型 P2P”について説明する．

ピュア P2P 特定のサーバを介さずにノード間で通信を行うネットワーク形態を示す．例をあげると，Winny[1]やKaZaA[2]などのファイル共有ソフトはピュアP2Pネットワーク形態である．

ハイブリッド型 P2P 一部の処理だけクライアント・サーバモデルを利用して行い，残りの処理をピュア P2P上で行うネットワーク形態を一般的にハイブリッド型 P2Pと呼んでいる．例えばNapster[3]のように，サーバに検索をかける時だけは，特定のサーバを介して通信し，ファイルを直接ダウンロードするときなどは，ピュア P2P上で通信を行うネットワーク形態がこれに当たる．

しかしこのような P2P通信環境でノード間通信を行う場合，NATやファイアウォール機能が問題になってくる．この問題を解決するための通信方式は複数存在しているにも関わらず，そのための手続きが一般化されていないため，現在ユーザは単純な通信方式を用いてシステムソフトウェア及びアプリケーションを利用していることが多い．そこで本研究では P2P環境のもと，いくつかの通信方式を用いて効率的なNAT/ファイアウォール越え通信を自動的に選択し，これをユーザ透過に使えるようにするシステムを提供し，大規模P2Pアプリケーションを簡便に実行する環境を実現する．

2.2 NAT技術とその問題点

NATとは，一般的に 1つのグローバルアドレスを複数のPCが共有することができるように，NATboxの内側でプライベートアドレスを管理し，外部との通信に関連付けを行う技術のこと

2

である．厳密には，NATは１つの IPアドレスを別の IPアドレスに変換し、両端点間の相互通信を行わせる技術のことであり、一般的な利用形態としては、１つの IPアドレスがインターネット上のグローバルアドレスで、他方がローカルな IPアドレスである場合が多い．また，1

つのグローバルアドレスを複数の PCが共有する技術として Network Address Port Translation

(NAPT) [4]が存在する．NAPTでは，IPアドレスの変換だけでなく，ポート番号の変換も行うため，1つのグローバルアドレスとポート番号の組み合わせに対して，複数のプライベートアドレスとポート番号の組に対して関連付けを行うことが可能である．これは，IPマスカレードとも呼ばれている．一般に，NAPTを指してNATと呼ぶことが多いため，以下NATと表現するときはNAPTを含んだ広義のものを指すとする．またNATには，外部との通信の仕方によっていくつかの種類に分けられる．ここでは “Cone NAT”と “Symmetric NAT”の 2つについて詳しく述べる．

Cone NAT 1つのプライベートアドレス，ポート番号を 1つのグローバルアドレスとポート番号に変換し，変換されたグローバルアドレスとポート番号を用いることで，外部と通信する．更にCone NATは “完全Cone NAT”と “制限付きCone NAT”に分類される．完全Cone NATとは，変換されたグローバルアドレスとポート番号に対して送信されたパケットは全てNAT内側にある一般ノードに送信される．また，制限付きCone NATは，NAT内側の一般ノードがデータを送信するとき，NAT内側のプライベートアドレスとポート番号，NAT 外側のグローバルアドレスとポート番号，さらに送信先のアドレスとポート番号の組を関連付けする．その関連付けが行われていない送信先からのデータはNATによって破棄される．図 2.1のように，Node A, Node B, Node Cがそれぞれ制限付きConeNAT機能を持つNATboxを経由して外部ネットワークに接続されている場合を考える．Node Aは一度データを送信したことがあるNode Bからのデータは，Global

Address:Portにデータを送信されれば Node Bから受信することができる．しかし、一度もデータを送信したことがないNode CからのデータはGlobal Address:Portに送信されたとしても，NATboxが破棄する．しかし，NAT内側の一般ノードがデータを送信したことが一度もない外部のノードからのデータは受け取れない．

3

図 2.1:制限付き Cone NAT

Symmetric NAT 1つのプライベートアドレスとポート番号の組に対し，通信相手毎に異なるグローバルアドレスとポート番号の組に変換を行う手法のことである．図2.2を用いて詳しく説明する．Node AはNode Bと通信したとき，アドレスとポート番号はNode-a1:ga1

に変換され，また，Node cと通信したとき，Node-a2:ga2に変換されているとする．この場合，一度も通信したことのないノード（例ではNode D)からがNode Aに対してパケットを送信しても Cone NATと同様 NATboxによって破棄され，Node Aにパケットが届くことはない．また，Node Bが，Node-a1:ga1に対してパケットを送信したときには通信は成立するが，Node-a2:ga2に対してデータを送信しても同様にNATで破棄されNode Aにはデータは届かない．Node CからNode Aにデータを送る場合も同様であり，Node-a2:ga2に対してデータを送ればNode Aに届くが，Node-a1:ga2に対してデータを送信しても Node Aに届かずに破棄される．

4

図 2.2: Symmetric NAT

以上で説明したように，図 2.3のような異なるNAT環境の中にあるノード同士が TCP通信を行う場合，その NAT 環境が制限付き Cone NAT，もしくは Symmetric NATであるならば，単純に通信したいノードのアドレスを指定しただけでは通信できないことがわかる．そのため，多くのNAT越えの技術が確立され，実際に様々なアプリケーションやシステムが用いられている．次節では NAT越えの技術について詳しく説明する．

5

図 2.3: TCP通信

2.3 NAT越え技術

ここでは，NAT越え技術のうち，代表的な 4つについて説明する．

2.3.1 リレー方式

この通信方式は通信を確立したい 2ノード間で TCP通信を行う場合に，通信を中継するノード (以後，リレーノードと呼ぶ)を介して通信を行う方式である．図 2.4の様に直接通信を行う場合よりも 1つ多くのノードを挟むため，スループットの低下，レイテンシの増加，さらに多数のノード間通信をリレーノードで処理するためノード数の拡張性の限界など不利な点が多い．

6

図 2.4:リレーノード方式

2.3.2 Universal Plug and Play

Universal Plug and Play (UPnP) [5]はネットワークを通してNATboxや家電製品の設定を行うため，UPnP Forum[5]によって定められたプロトコルである．SSDP (Simple Service Discover

Protocol)というプロトコルを用いて，UPnP対応のデバイスを探索し，そのデバイスを操作する．UPnPに対応したNATbox（家庭用ルータ）を用いることでプログラムから自動的にNAT

の設定を変更できる．UPnP機能を用いることで，NATの設定を変更し，NATboxに特定ポートを開け，そのポートを用いて通信したいノードと通信することが可能である．通信し合うノード間でポートは開いているため，TCP通信，もしくは UDP通信が可能である．これはWindows Messenger[6]やオンラインゲーム等に用いられている．

2.3.3 UDP hole punching

UDP hole punching[7]はNATのUDP機能を利用して実現する手法で，多くのNATboxで利用できる．しかし，UDP/IPによる通信しか行うことができないため，ユーザアプリケーションにおいて信頼性のある通信を提供するには, パケットの再送や順序制御等の処理が必要となる．実際の通信では，NATboxの内側に存在するノードから何度かUDPパケットを送信するこ

とで NATboxに特定のポートを開け，通信相手のノードと開いたポートを用いて通信する方法である．これは通信し合う 2ノードがお互いにNATで保護された状況でも通信可能な手法である．

2.3.4 TCP hole punching

TCP hole punching[8]とは，TCP通信を用いた NAT 越え技術である．以下では図 2.5を用いて順を追って説明する．まず，図 2.5の I を TCP通信で行う．次に通信相手の情報を手に入れたら，サーバとの通信を打ち切り II を TCPを用いて行う．このとき，サーバとの通信に使っていたポート番号を用いる．UDP hole punchingは UDPパケットによって NATboxに特定のポートを開けるのに対して，TCP hole punchingは SYNパケットで特定のポートを開ける．また，ノード間通信に TCPを用いるため，信頼性のある通信を行うことができる．

7

図 2.5: TCP hole punching

2.4 各種NATboxに対応するNAT越え技術の実現

2.3節で例に示した NAT/ファイアウォール越えの技術は，P2Pを行いたい 2ノードの通信環境やNATboxの種類によって異なる．そのため，環境に応じたNAT/ファイアウォール越え技術の選択が必要である．NAT/ファイアウォール越えを試す際，まず最も通信効率の高いものを試し，それが使えなければ次の方法を試す，というように，複数の可能性を順次試みる必要がある．以下ではこれを “通信方法の優先度” と呼ぶ．通信方法の優先度は，広域ネットワークを用いて測定したNAT越え技術毎のスループットとレイテンシを元に設定する．ただし，TCP通信を行うときノード間にリレーノードが存在している場合にはリレーノードという余分な資源を挟むためスループットが下がる．従って，リレーノードを常に利用する TCP

通信は，最後の手段として考えるべきである．

2.5 関連研究

Skype[9]は IP電話やテレビ会議を行うアプリケーションである．SkypeはUDP hole punching

を用いてNAT越え通信を実現している．具体的には図 2.5の Iにあたる通信をUDP通信で行

8

い，通信相手の情報を取得した後は，実際に通信を行いたい 2ノード間でUDP hole punching

を用いて行う．Skypeは全ての通信をUDPで行うため，スループットは得られるが，通信を行っている際にパケットロスや，接続が切れるなど不安定な動作を起こす可能性がある．Skype

はUDP通信しか選択できないが，本研究がターゲットとするアプリケーションと異なりSkype

の主な通信目的である音声通信などにはこのようなパケットロスは大きな問題にならない．ただし，本研究が目的とするシステムでは，ユーザアプリケーションに対して TCPのような信頼性のある通信を提供することを目的としている．その為，パケットロスが発生する Skype

のような通信は問題になる．先行研究として，岡本らによる “UDPによるファイアウォール越えを用いた P2Pオーバー

レイネットワーク”[10] がある．この研究では，物理ネットワークに依存せず，参加するすべてのノードを接続するためのオーバレイネットワークを提案している．オーバレイネットワークを実現するために UDP hole punchingを利用し，また，独自のライブラリを用いることでノード間の UDP通信を TCPライクに行った．本研究では，オーバレイネットワークを実現するために，UDP hole punchingとUPnPを用いる．さらに，複数の通信方式に優先度を付けることでユーザ透過に通信を行うシステムを提案する．次章では，システムの設計について述べる．

9

第3章 ユーザ透過にNAT越えを行う通信システムの設計

3.1 システムの全体構成

本研究ではハイブリッド型 P2Pを用いて，状況に合わせたNAT越え通信方式の選択をユーザ透過に行うシステムの設計を最終的な目的としている．さらに，サーバの負荷を分散させるために独自の DHT (Destributed Hash Table)を用いて通信を行うことを検討している．本論文では世の中に広く散在している PCを一般ノードとし，全ての一般ノードから IP-

reachableで，一般ノード間のP2P通信を司る管理用ノードをスーパーノードとして定義する．図 3.1にシステムの全体像を示す．まずこのスーパーノードは一般ノードを管理するものとする．一般ノードは，通信したいノードが現れるとスーパーノードに接続し通信相手の情報を問い合わせる．一般ノードは通信を開始するときスーパーノードによって与えられた通信方式を実行することでユーザ透過な P2P通信をする．また，一般ノードが他の一般ノードと通信をするとき，接続開始時にはスーパーノードを介した通信になるが，実際のデータ通信はNAT越え技術を用いた一般ノード間の直接接続による通信を行うため，スーパーノードとの通信はボトルネックにはならない．まずユーザ透過にNAT越えを行う通信システムを実現するために，NAT越え技術が複数必要となってくる．

図 3.1:想定するシステムの全体構成

10

次節より，スーパーノードと本システムが対象とする主な 4つのNAT越え技術に対応する各通信モジュールについての設計を示す．

3.2 スーパーノード

本システムではスーパーノードの役割は以下に示す 3つである．

• 一般ノードの情報を登録する

• 一般ノードに対して，適切な通信方式を選択する

• 一般ノードに通信相手の情報を教える

スーパーノードはインバウンド接続を許可し，その管理下に複数の一般ノードがある．またスーパーノード同士は図 3.1の様にネットワークで繋がっている．一般ノードが通信相手の情報検索をするとき，スーパーノードはインバウンド接続される．このとき，スーパーノードは一般ノードの情報を自動登録し，一般ノードに目的の情報を返す．一般ノードに返す情報の中には，通信相手の一般ノードの NATboxの種類や，P2P環境などから判断して選択可能な通信方式を伝える必要がある．もし一般ノードだけで通信モジュールを選択すると相手との通信方式が合わない可能性があるためである．

3.3 通信モジュール

本システムでは，NAT越えを行う各種通信方式をモジュールとして扱い，適宜これらの通信モジュールをシステムに組み込むことで，様々な通信方式に対応させる．本節では．これらの通信モジュールの中で主に本システムで実装すべきモジュールについて述べる．

3.3.1 リレーモジュール

リレー方式は通信し合う一般ノードの間に各一般ノードからインバウンド接続を許可するリレーノードが存在する．本システムでは，リレーノードとしてスーパーノード，又はインバウンド接続可能な一般ノードを用いることを検討している．各一般ノードはリレーノードと接続し，そのリレーノードが情報交換の仲介をしてあげることでNAT越えを実現する．図3.2にリレーモジュールの概要を示す．リレーモジュールは通信し合うノード間にリレーノードを用いて，リレーノードが通信の仲介をする機能を実現する．一般ノードがこのモジュールを用いる場合，スーパーノードはリレーノードに一般ノードの情報を送信し，リレーノードは送信された各一般ノードの情報を関連付ける必要がある．その手順を踏まえた上で通信し合う 2ノードが共に同一のリレーノードに TCP接続することで，1つのコネクションを形成する．そのコネクションにより，一般ノード間で通信する．しかし，このモジュールでスループットや，レイテンシがボトルネックになる．また，リレーノードがインバウンド接続

11

を許可していることが必要である．さらに，リレーノードに対して，リレーを要求する一般ノード数が増加することでリレーノードの負荷が増大し，その結果システムのスケーラビリティが低下する．

図 3.2:リレーノードモジュール

3.3.2 UPnPモジュール

特定の設定をNATに行い，その設定を用いることで通信を確立する機能を “UPnPモジュール” とする．

UPnPとは基本的にネットワーク上に存在するUPnPデバイスを操作するためのプロトコルである．UPnP Forum[5]では，このプロトコルで行える命令アクションの一部分を定義しており，本命令を用いてNATboxへの設定変更を行うことができる．今回使用した Action命令は「GetExternalIPAddress」，「AddPortMapping」，「GetGenericPortMappingEntry」の 3つである．

GetExternalIPAddress NATboxのグローバル側のアドレスを取得する命令

AddPortMapping NATboxのポート開けることができる命令

GetGenericPortMappingEntry グローバル側のポート番号を取得する命令

12

まず SSDP (Simple Service Discovery Protocol) [5]を用いてUPnP対応NATboxを検出する．次に，応答があったら，その中にデバイスの情報 (Device Discripution)が記述されているURL

が載っているので，そのURLを参照する．そのDevice Descriptionの中に，controlURLが存在するので，そこに対してAction命令を出す．以上の 3つのAction命令を出すことによって，NATboxの情報取得し，スーパーノードに送信する．

3.3.3 UDP hole punchingモジュール

UDP hole punchingとは，NATboxの内側にあるノードから UDPパケットを送信することでNATboxにポートを開け，通信相手のノードと開いたポートを通して通信する方法である．UDP hole punchingを用いて通信を確立する機能を “UDP hole punchingモジュール” とする．ただし，本研究ではその方法を利用できる制限付きCone NATを想定しており，以下NATと表現するときは制限付き Cone NATを指す．

NATは，内側のノードからパケットが送出されたとき，プライベートアドレスとポート番号の組とNATによって変換されたグローバルアドレスとポート番号の組を関連付けし，一定期間記憶する．片方のノードだけがNATの内側に存在する場合は，通信相手の情報があれば問題なく通信することはできる．しかし，通信を行うノードが両方ともNATの内側に存在した場合，工夫が必要である．この場合の解決方法を図 3.3，3.4を用いて説明する．図 3.3，3.4の Node-a,bはノードのローカルアドレスで，la，lbはそれぞれのローカルポー

ト番号である，また，NAT-a,bは変換された後のグローバルアドレスで，ga，gbはそれぞれのグローバルポート番号である．図 3.3の様に Node-aから Node-bにパケットを送信したいとき，Node-aはNAT-b:gbに対して送信する．しかし，NAT-bはそのパケットをどのノードに送ればいいかわからずに破棄してしまう．そのため，Node-aからNode-bにパケットは届かないことになる．

Node-bがNode-aからパケットを受け取るためには，図 3.4の様に一度Node-bがNAT-a:ga

に対してパケットを送信する必要がある．NAT-a:gaに対してパケットを送信することでそのパケット自体は破棄されてしまうが NAT-bは NAT-a:gaから受け取ったパケットを Node-b:lb

に送ることが可能になる．これは NAT-bが，NAT-a:gaと Node-b:lbを関連付けするためである．Node-aも同様の手順を追うことでノード間の通信を可能にする．以上のようなことから，UDP hole punchingモジュールでは，まず一般ノードはスーパー

ノードから通信相手の情報を取得する必要がある．次に通信相手の情報を取得したらその宛先に対して UDPパケットを送信し続ける必要がある．これにより送信元の NATは関連付けが行われ，送信先の一般ノードも同様の手順を追うことでノード間の直接通信を実現する．

13

図 3.3: UDP hole punching:ERROR

3.3.4 RUDPモジュール

UDP hole punchingモジュールでは，UDPパケットを用いて通信を行うことができるが，UDPでは信頼性のある通信経路を確立することができない．そこで UDP上で信頼性のある通信を行うために Reliable UDP[11]が提案されている．しかし，Reliable UDPは再送処理と到達確認についてしか規定されておらず，また利用可能な実装システムも公開されていない．そこで，本研究では先行研究 [10]において開発された RI2N/UDPの実装を応用する．RI2N

(Redundant Interconnection with Inexpensive Network) [12]とは．Ethernetのマルチリンクを利用して耐故障性と高バンド幅化を実現したネットワークである．これを UDP/IP上のユーザレベルで実装したものが RI2N/UDPである．RI2N/UDPは UDPによる実装ではあるものの，ライブラリ内でパケットの再送処理や到達確認を行い通信の信頼性を確立しており，ユーザから見れば TCP通信とほぼ等価な通信機能を実現している．このRI2N/UDPの通信機能を応用し，UDPを用いた場合でも TCPと同様に信頼性のある UDP通信を実現する．本機能に加えて，3.2.3節で示した UDP hole punchingの機能を加えることで通信する 2ノードが互いにNAT内部にあったとしても通信を確立することができる．本機能を実現する通信ライブラリをRUDPライブラリと呼ぶ．本システムの “RUDPモジュール” は，このRUDPライブラリを用いる．

14

図 3.4: UDP hole punching:SUCCESS

3.3.5 TCP hole punchingモジュール

TCP hole punchingは基本動作原理はUDP hole punchingと同じであるが，通信に TCPを用いることで信頼性を確立する．また，この通信モジュールを “TCP hole punchingモジュール”

とする．図 3.5を用いて説明する．また，ノード間通信における送信元をNode-a:laとし，送信先を Node-b:lbとする．

1. 2つのNATの内側のノードがスーパーノード (Server:s)に対して通信相手の情報を検索する．

2. スーパーノードは，accept()を呼び出したとき，ソケットの値をみることで接続元のアドレスとポート番号 (NAT-a:gaと NAT-b:gb)を登録する．

3. スーパーノードはNAT-a:gaに通信したい相手の IPアドレスとポート番号 (NAT-b:gb)を送り返す．

4. Node-Aはスーパーノードから取得した相手の情報 (NAT-b:gb)に対して SYNパケットを送信する．SYNパケットは Node-Bには届かないが，NATにポートが開く．Node-B

でも同様に SYNパケットを送信する．

5. 通信したいノードの情報を受け取ったら，スーパーノードとの接続を切り，スーパー

15

ノードとの通信に使っていたポート番号を使って，片方のノードは通信の待ち受け状態になり，もう片方のノードが connect()を呼び出す．

図 3.5: TCP hole punching

以上の様な順序を追うことで，一般ノード間は TCPを用いて直接接続できる．

3.4 通信方法の優先度付け

基本的には通信に信頼性は必要なものとして，UPnPモジュールを用いた TCP通信方式やTCP hole punchingモジュールなどの TCPを用いた通信方式の優先度は高いものとする．また，RUDPモジュールを用いて通信することもあるため，RUDPの優先度は TCPと UDPの間に位置付けし，システムを設計していくことを検討している．しかし，これらの優先度は，実際に用いるネットワーク環境によって最適な通信方式が異なり，一概には決定できない．本研究では，これら複数の通信モジュールの評価を行い，その結果を参考に優先度付けを行うことを検討する．補足すると，リレーモジュールに関しては，余分な通信資源を介して通信を行い，レイテンシの増加や，スループットの低下などが起こる．そのためリレーモジュールの優先度は一番低いものとする．また，通信方式のユーザリクエストがあったときは，その通信方式を選択する．例えばユーザが通信にUDPだけ必要とリクエストしたら，通信方式にはUDP hole punchingモジュールを用いる．TCPが必要というリクエストだったら，UPnPモジュール，もしくは TCP hole punchingモジュール，リレーモジュールの中からユーザに選択してもらう．ある通信方式を選択しているとき，手動で他の通信方式に選択できる機能の実

16

装や，TCPやRUDPを用いることでスループットが低下するのを避けるために，手動でUDP

通信を行う機能についても検討している．

17

第4章 実装

3章で示した設計指針に基づき，まず本研究ではUPnPモジュールとUDP hole punchingモジュールの 2つの通信モジュールを実装する．また，2つの通信モジュールをユーザ透過に使用するためのシステムを実装する．本章では，これら 2つの通信モジュールの実装と，スーパーノードの実装について示す．また，今回システムで用いた一般ノードの通信方式の選択方法について示す．

4.1 UPnPモジュールの実装

UPnPモジュールを用いた TCP通信について述べていく．既存の UPnPデバイス開発用のライブラリとしてUPnP SDK[13]と呼ばれる Linux向けのSoftware Development Kit (SDK)がある．UPnPモジュールの実装ではこれを用いることで，C言語によるプログラム上で UPnP

デバイスを探索し，操作を行う．今回用いた実験環境では UPnPデバイスは NATboxしかないと想定するが，他のUPnPデバイスがあったとしてもUPnP Forumによって定義されたデバイスのタイプ，サービスのタイプをNATbox用に指定することで，UPnP対応NATboxだけを操作することが可能である．以下では UPnPモジュールの動作の大まかな流れを示す．

1. UPnPを UPnP Forum[5]によって定義されたプロトコルで検索し，UPnP対応 NATbox

が発見できたら，その NATboxの XML で記述された情報を参照

2. XML 中に記載された controlURLに対して Action命令を送信する．これによって，グローバルなアドレスを取得し，特定のポートを開けることが可能になる．

3. UPnP機能によって取得した情報をスーパーノードに送信し，スーパーノードはその情報を内部のデータベースに登録する．

UPnPデバイスのうち一般的な家庭用のNATboxに標準的に備わっているとされるサービスに基づいて，UPnP対応NATboxの操作をする．以下にUPnP対応NATboxを操作する一般的な手順を示す．

UPnPデバイスを操作するためには，まずUPnP対応のデバイスを見つけなくてはならない．そのため一般的には，SSDP (Simple Service Discovery Protocol)というプロトコルを用いる．SSDPを使うために，まず図 4.1に示すようなメッセージをマルチキャストする．UPnPデバイスは UPnP Forumが定めた様々なサービスをもっているため，このサービスを指定して図

18

4.1中の識別子の “ST” に操作したいデバイスのサービスを指定し，これをマルチキャストすることで，操作したいデバイスを決定することができる．

UPnP対応デバイスからは，“Device Descripution”と呼ばれる URLなど書かれたメッセージが返信され，Device Description中の URLを参照することで，操作したいデバイスの細かい情報を得ることができる．Device Descriptionは全て XML で記述されている．また Device

Descriptionにはデバイスの製品名，UPnP Forumが定めたデバイスのタイプ，サービスのタイプなどが含まれている．そのサービスの中に，controlURLというものが存在し，このURLにAction命令をだすことで，UPnPデバイスを操作することが可能である．

M-SEARCH * HTTP/1.1

HOST: 239.255.255.250:1900

MAN: ”ssdp:discover”

MX: 3

ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1

図 4.1: M-SEARCH

UPnPSDK[13]は，これらの手続きをライブラリ化したもので，本研究では，SDKに用意されている APIを用いて UPnP対応 NATboxを操作する．

19

<?xml version="1.0"?><root xmlns="urn:schemas-upnp-org:device-1-0"><specVersion><major>1</major><minor>0</minor></specVersion><URLBase>http://192.168.*.*</URLBase><device><deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType><friendlyName>BUFFALO BBR-4HG Broad Station</friendlyName><manufacturer>BUFFALO INC.</manufacturer><manufacturerURL>http://www.melcoinc.co.jp/</manufacturerURL><modelDescription>Internet Gateway Device with UPnP support</modelDescription><modelName>BBR-4HG</modelName><modelNumber>1.20 Release 0011</modelNumber><modelURL>http://www.melcoinc.co.jp/</modelURL>・・・<deviceList><device><deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType><friendlyName>BUFFALO BBR-4HG Broad Station(WAN Con)</friendlyName><manufacturer>BUFFALO INC.</manufacturer><manufacturerURL>http://www.melcoinc.co.jp/</manufacturerURL><modelDescription>Internet Gateway Device with UPnP support (WAN Connection Device)</modelDescription><modelName>BBR-4HG WAN Connector</modelName><modelNumber>1.20 Release 0011</modelNumber><modelURL>http://www.melcoinc.co.jp/</modelURL><serialNumber>**********</serialNumber><UDN>uuid:00000000-0000-0001-0002-000d0bdcb23a</UDN><UPC>494125014380</UPC><serviceList><service><serviceType>urn:schemas-upnp-org:service:WANEthernetLinkConfig:1</serviceType><serviceId>urn:upnp-org:serviceId:WANEthLinkC1</serviceId><SCPDURL>/igd_wec.xml</SCPDURL><controlURL>http://192.168.*.*:5440/upnp/control?WANEthernetLinkConfig</controlURL><eventSubURL>http://192.168.*.*:5440/upnp/event?WANEthernetLinkConfig</eventSubURL></service><service><serviceType>urn:schemas-upnp-org:service:WANPPPConnection:1</serviceType><serviceId>urn:upnp-org:serviceId:WANPPPConn1</serviceId><SCPDURL>/igd_wpc.xml</SCPDURL><controlURL>http://192.168.*.*:5440/upnp/control?WANPPPConnection</controlURL><eventSubURL>http://192.168.*.*:5440/upnp/event?WANPPPConnection</eventSubURL></service><service><serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType><serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId><SCPDURL>/igd_wic.xml</SCPDURL><controlURL>http://192.168.*.*:5440/upnp/control?WANIPConnection</controlURL><eventSubURL>http://192.168.*.*:5440/upnp/control?WANIPConnection</eventSubURL></service></serviceList><presentationURL>/igd_wc.html</presentationURL></device></deviceList><presentationURL>/igd_w.html</presentationURL></device></deviceList><presentationURL>/</presentationURL></device></root>

図 4.2: DeviceDescriptionの例

20

以下，UPnPモジュールにおける操作について順を追って説明していく．

1. UPnP対応 NATboxの探索UpnpSearchAsync( DeviceType )によりDeviceTypeを指定することでUPnP対応NATbox

を検索し，その NATboxからのレスポンスがあるか調べる

2. Device Descriptionの取得UPnP対応 NATboxが発見され，そのレスポンスによって Device Description中の URL

を参照し，UpnpDownloadXmlDoc( DeviceDescription’s URL )により，XML で記述された Device Descriptionを取得する．

3. controlURLの取得XML で記述された Device Descriptionは図 4.2の様なもので，この中から DeviceType

「urn:schemas-upnp-org:device:WANConnectionDevice:1」の中のServiceType「urn:schema

s-upnp-org:service:WANPPPConnection:1」，もしくは「urn:schemas-upnp-org:service:WAN

IPConnection:1」を見つけ，更に，このサービスの controlURLを見つける．実際の con-

trolURLの探索の方法として．まずライブラリ関数中びパーサーを用いることで，Device

Desicriptionを図 4.3に示す木構造として解析する．そこから，目的のDevice，Service，controlURlと順を追って探索し，必要な情報を取得する．

図 4.3: DeviceDescriptionの木構造

21

4. Actionの送信取得した controlURLに対して，Actionのリクエストメッセージを送信する．メッセージは UpnpMakeAction()，もしくは UpnpAddToAction()によって作成し，UpnpSendAc-

tionAsync()によって送信する．操作が可能なUPnP対応NATboxであれば，図 4.4のようなレスポンスを受信することができる．Actionに対するレスポンスによって Action

の終了を確認する．

UPnP対応NATboxが操作可能か不可能かの情報，グローバルアドレスとポート番号の情報などをスーパーノードへ登録する．

<?xml version="1.0"?><u:GetExternalIPAddressResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewExternalIPAddress>***.***.***.***</NewExternalIPAddress></u:GetExternalIPAddressResponse>

<?xml version="1.0"?><u:AddPortMappingResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"></u:AddPortMappingResponse>

<?xml version="1.0"?><u:GetGenericPortMappingEntryResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>*****</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>*****</NewInternalPort><NewInternalClient>192.168.*.*</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>sample</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:GetGenericPortMappingEntryResponse>

図 4.4: Action命令のレスポンス

4.2 UDP hole punchingモジュールの実装

UDP hole punchingを行うために，まず通信相手の情報を知らなくてはならない．そして，通信相手の情報を取得したら，実際UDP hole punchingを行うためにUDPパケットを送り続ける，UDPモジュールでは，3．3．3節で述べたUDP hole punchingの手順に従い，以下の手続きで通信を確立する．

1. スーパーノードと TCP接続し，情報の交換をする．このとき，通信相手の情報を検索，取得する，

2. 通信相手の情報を取得できたら，通信相手に対して，UDPパケットを投げ続ける．

3. NATの関連付けが上手くいったとき，通信相手に情報が届き，また通信相手からパケットを受け取ることもできる．

22

4.3 スーパーノードの実装

本研究ではP2P通信環境におけるNAT越え通信をユーザ透過に行うことを目的としている．そのためスーパーノードとの通信を減らすため，スーパーノードは可能ならば一般ノードの情報を自動登録する必要がある．本研究で実装するシステムでは，一般ノードは通信したい一般ノードの情報を取得するためにスーパーノードと情報交換を行う．このとき一般ノードとスーパーノードは TCPを用いて情報交換を行う．スーパーノードは最初に接続されたとき，ソケットの情報を参照することで一般ノードの情報を自動的に登録する．また，本研究において実装を行うシステムでは，スーパーノードが一般ノード間の通信手法

を選択する，今回，実装上UPnPモジュールとUDP hole punchingモジュールのどちらかを選択する形になる．TCP，もしくはUDP通信をしたい，というユーザのリクエストがあったら従う必要があるが，今回はユーザからリクエストのないものとして選択方法を実装する．選択方法として，まず一般ノードがUPnPモジュールを用いることで，その一般ノードがUPnP

対応 NATboxに保護されているかどうかを調べる．一般ノードは UPnP対応 NATboxに保護されているかどうかの情報も含めてスーパーノードとやり取りを行う．スーパーノードは一般ノードのうち，どちらか一方でも UPnP対応 NATboxによって保護されていればモジュールを用いた TCP通信を行い，どちらの一般ノードもUPnP対応NATboxに保護されていなければ UDP hole punching通信を行うように指示する．

23

第5章 評価

本研究で実装する UPnPモジュール及び UDPモジュールが正しく動作することを確認し，通信方法の優先度を決めるために，通信モジュール毎のスループット，また，一般ノードが 1

つの通信方式を決定するまでの時間を測定する．今回は家庭用の NATboxを用いて UPnPモジュールも用いた TCP通信性能，UDP hole punchingモジュールの通信性能を測定した．

5.1 評価環境

評価は図 5.1の様なインバウンド接続が可能なノードを Serverとし，2つの NATboxの内側にあるそれぞれのNodeを一般ノードとして LAN 上で評価を行った．また，一般ノードとServerのスペックを表 5.1に示した．今回用いたNATboxは一般的に売られている家庭用ルータであるBUFFALO BroadStation BBR-4HGと I-O DATA ETX-Rの 2種類のNATboxを用意した．BBR-4HGはUPnPの操作ができたが，ETX-RはUPnPの操作を行うことができなかった．

表 5.1: SPEC

Server 一般ノードCPU Intel R⃝PentiumR⃝4 2.40GHZ Intel R⃝PentiumR⃝M 1.20GHZ

memory 1024Mbyte 512Mbyte

NIC Intel R⃝PRO/100 Intel R⃝PRO/1000

24

LAN

図 5.1:評価環境

5.2 動作確認

まず，回線速度測定ツールである Iperf 2.0.2を用いてUPnPモジュールの動作確認を行った．適当なポートを使って，ノード間の通信を行ったところ図 5.2のようなログが検出された．ここで，UPnPモジュールを用いて 20000番ポートを開けて，再び同じ操作をしたところ，

図 5.3のようなログが表示された．以上より，UPnPモジュールによりポートが開けられたことが確認できる．次に UDP hole

punchingモジュールの動作確認を行うが，UPnPモジュールと異なり任意のポートを開けることができないため，今回は両ノード間で通信が確立されたことで，動作したとする．何度かお互いに UDPパケットを送ることで通信でき，5．4節で示すような結果が得られた．

25

connect failed: Connection refused

write1 failed: Broken pipe

write2 failed: Broken pipe

————————————————————

Client connecting to通信相手のグローバルアドレス, TCP port 20000

TCP window size: 16.0 KByte (default)

————————————————————

3 local 0.0.0.0 port 52260 connected with通信相手のグローバルアドレス port 20000

3 0.0- 0.0 sec 0.00 Bytes 0.00 bits/sec

図 5.2: before UPnPモジュール

————————————————————

Client connecting to通信相手のグローバルアドレス, TCP port 20000

TCP window size: 16.0 KByte (default)

————————————————————

3 local 192.168.1.2 port 54075 connected with通信相手のグローバルアドレス port 20000

3 0.0-10.0 sec 54.2 MBytes 45.5 Mbits/sec

図 5.3: after UPnPモジュール

5.3 評価方法

図 5.1の一般ノード間の通信性能を以下の 4つの通信方式について測定し，評価する．

TCP DMZ グローバルアドレスとローカルアドレスの変換を明示的に行うように，NATbox

を手動で設定して TCP通信を行う．

UPnP normal UPnPモジュールを用いた結果，UPnP対応NATboxが操作可能な方を accept()

側とし，操作不可能な方を connect()側として TCP通信を行う．

今回実装したシステムでは，UPnPモジュールを用いて TCP通信を行う上でこれが標準となる．

UDP DMZ TCP DMZと同様，NATboxを手動設定することでポートを開け，UDP通信を行う．

UDP hole punching UDP hole punchingモジュールを使用する．

26

また，評価内容は最大スループットと各通信方法を決定するまでの時間の 2点である．スループットと各通信方式に切り替わるまでかかる時間を測定することで通信方法の優先度を検討する．しかし今回のシステムではUPnPモジュールを使用できない場合，UDP hole punching

を行うシステムであるため，UDP hole punchingを選択するまでの時間はUPnPモジュールが使用できるか調べ，使用できなかったと判断するまでの時間と同意である．そのため，今回，通信方式を決定するまでの時間の測定は UPnPモジュールを選択し，通信を開始するまでの時間の測定だけとする．

5.4 結果と考察

評価を非対称で，LAN 上に余計なパケットが存在するような環境で行ったため性能は不十分であるが，図 5.4に各通信方式のスループットを示す．

0

10

20

30

40

50

60

TCP DMZ TCP normal UDP DMZ UDP hole

punching

(Mbps)

図 5.4:各通信方式のスループット

TCP normalと TCP DMZのスループットに大きな差が見られない．この結果より，UPnP対応 NATboxを操作できる場合，本研究で実装した UPnPモジュールを用いて TCP通信を行っても通信に影響はないことがわかる．また，UDP hole punchingとUDP DMZのスループットを比較してみても，同じようなことが言える．UDP DMZを用いた場合，パケットの再送処理や到達確認を行っている TCP通信よりはスループットが高い．以上より各モジュールが正しく動作したことが確認できる．またスループットを求める通

信を行いたい場合の手法として，UDP hole punchingが有効であることがわかる．

27

次に，UPnPモジュールを用いて通信を開始するまでにかかる時間と，UDP hole punching

モジュールの通信を開始するまでの時間を測定した．

表 5.2:通信開始にかかる時間

UPnPモジュール 6.2秒

表 5.2より，UPnPモジュールを使用して TCP通信を行うまでに平均 6.2秒かかった．このため，UPnPモジュールが使用できないと判断するまでのタイムアウトは約 6.2秒より長くする必要がある．ただし，ここで測定した結果はあくまで今回使用した機器におけるものであるため，一般的なタイムアウト値を設定するには，さらに多くの機器でのテストが必要である．

28

第6章 結論

6.1 まとめ

本研究では，UPnP対応 NATboxを UPnPライブラリを用いることで操作し，操作できなかった場合はUDP hole punchingを行うといったシステムを設計，実装した．手動でNATbox

を設定し，NAT 越えを行わない TCP通信と，UPnPモジュールを用いた TCP通信のスループットではほぼ同じ性能が得られた．以上の結果から，本システムでは TCP通信を行う場合，UPnPによりNATboxを操作可能であればUPnPモジュールを用いることでNAT越えを選択する．しかし，UPnPモジュールによって，使用しているNATboxがUPnP対応か調べる時間が6秒程度かかることがわかった．もし P2P通信環境上で大規模計算を行う場合，6秒は非常に大きなレイテンシを生む可能性が十分にある．今回実装したシステムではまずUPnPモジュールを使用するが，システムのスケーラビリティを確保するために，このレイテンシを何らかの方法でできるだけ隠蔽する工夫が必要である．一方，UDP hole punchingはUDP DMZに比べて 2割程度低下したスループットが出る．しかし，NAT越えを行う上で，あらゆるNATbox

に対応できる点では UDP hole punchingモジュールは有効に利用できると考えられる．ただし，今回の性能評価ではUDP hole punchingによるUDP性能のみを測っているため，ユーザが TCP通信（ストリーム通信）を欲している場合，RUDPモジュールと組み合わせて全体的な性能がどの程度になるかについて，さらに詳細な評価が必要である。

6.2 今後の課題

本研究ではUPnPモジュールと，UDP hole punchingモジュール，そしてスーパーノードの機能を実装した．しかし，まだRUDPモジュールと，独自DHTが実装されていない．更に，現在選択できる NAT越え通信方式は UPnPモジュールを用いた TCP通信と UDP hole punching

モジュールの 2つだけである．今後は，RUDPモジュールを実装し，モジュールを更に増やすことも必要である．現在，実装を検討している通信方式は TCP hole punchingモジュールであり，接続にかかる時間が UPnPモジュールを使用するのにかかる時間より短ければ有効になると予想される．また，今回制限付き Cone NATで評価を行ったが，実装を行った 2つの通信方式では Symmetric NATは越えられない．今後は Symmetric NATを越える通信方式の実装も必要である．また，今回は特定の２つの NATboxを実験対象として用いた．これらの NATboxは市場で

簡単に入手可能なもので，その意味では標準的な実験が行えたと言えるが，家庭用ネットワー

29

ク環境等の需要に伴い，非常に多種のNATboxが存在し，また技術の進歩によってスループットや接続設定時間の改善が進んでいる．今後，さらにいろいろな NATboxを用いた検証と実験が必要である．

30

謝辞

本研究を進めるにあたり，多大なるご助言とご指導を頂いた筑波大学システム情報工学研究科朴泰祐教授に心からお礼を申し上げます．そして，日頃より研究に対するご助言を頂いた筑波大学システム情報工学研究科佐藤三久教授，同高橋大介准教授，同建部修見准教授，同塙敏博准教授，同多田野寛人助教に深く感謝いたします．また，日頃より研究生活における様々な面においてお世話になりました三浦信一氏や，HPCS研究室の皆様にこの場を借りて感謝を述べさせていただきます．

31

参考文献

[1] 金子勇. Winnyの技術.

[2] KaZaA. http://www.kazaa.com/us/.

[3] napster. http://www.napster.jp/.

[4] M. Holdrege and P. Srisuresh. NAT Terminology and Considerations. InRequest for Com-

ments (RFC) 2663, August. 1999.

[5] UPnP Forum. UPnP.http://www.upnp.org.

[6] Microsoft. Windows Messenger.http://messenger.live.jp.

[7] M. Holdrege and P. Srisuresh. Protocol Complications with the IP Network Address Transla-

tor. In Request for Comments (RFC) 3027, January. 2001.

[8] B. Ford, P. Srisuresh, and D. Kegel. Peer-to-Peer Communication Across Network Address

Translators. InProceedings of the 2005 USENIX Annual Technical Conference.

[9] Skype Technologies SA. skype.http://www.skype.com.

[10] Takayuki Okamoto, Taisuke Boku, Mitsuhisa Sato, and Osamu Tatebe. P2P Overlay Network

for TCP Programming with UDP Hole Punching. InInternational Conference on Network and

Pararellel Computing(NPC) 2006, pp.199-204.

[11] T. Bova and T. Krivoruchka. Reliable UDP Protocol, ”draft-ietf-sigtran-reliable-udp-

00.txt”(1999).

[12] Shinichi Miura, Takayuki Okamoto, Taisuke Boku, Toshihiro Hanawa, and Mitsuhisa Sato.

RI2N: High-Bandwidth and Fault-Tolerant Network with Multi-link Ethernet for PC Clus-

ters. InProc. 10th IEEE International Conference on Cluster Computing (CLUSTER 2008),

pp.274-279.

[13] Linux SDK for UPnP Devices. http://upnp.sourceforge.net/.

32