P2P

Channel 9 ビデオ「ソフトイーサ登さんとの対談」

ウィンドウズ開発統括部 — Fri, 29 Sep 2006 14:18:00 GMT

お久しぶりです。及川です。

Windows Vista の RC1、IE7 の日本語版 RC1 の作業に埋もれておりました。今は RTM に向けての開発最終段階です。

さて、Channel9 で行っている対談シリーズですが、第２回目も編集が終わり、公開されましたので、お知らせします。今回は、ソフトイーサ株式会社代表取締役会長登大遊さんをゲストに迎えて、登さんがコンピュータプログラミングにかかわるようになったきっかけの話から、IPA の未踏プロジェクトの話、Windows プログラミングの話にネットワークセキュリティまで多岐にわたるお話をさせていただいております。話し始めたら、止まらずに、なんと１時間２２分近くもの大作となっております。

時間配分は以下の通りです。

0:00～: ご挨拶＆登さんの紹介
1:30～: 登さんと及川の馴れ初め
2:45～: 登さんのプログラミングとの出会いから今まで

7:28～: IPA 未踏プロジェクト応募からソフトイーサの開発まで
14:30～: P2P の課題
17:40～: 内部統制について
26:15～: ベンチャー会社設立について

29:20～: PacketiX の紹介

33:36～: ASP サービス
36:12～: パフォーマンス向上のための工夫
42:40～: ソースコードの移植性
44:25～: Windows Vista への対応

48:15～: セキュアジャパン 2006 でのセキュア VM 開発への参画
－－－ここからいくつかトピックを取り上げて話しています－－－
54:00～: トピック１）ネットワークセキュリティについて
1:02:00～: トピック２） Windows の良い点と悪い点
1:09:00～: トピック３）コミュニティについて
1:10:35～: トピック４）ソフトウェア開発者に向けて
1:17:20～: トピック５）マイクロソフトへの期待

（全 : 約１時間２２分）

なお、対談の中で、Windows Vista は６４ビットではデジタル署名されたドライバしか許さないという話題に触れていますが、それについては、こちらをご覧ください。また、Windows Vista をセルフホストしているという話の中で、「生産性が落ちる」と言ってしまっている部分がありますが、これはまだ修正すべき問題を抱えている開発中の製品であるためであり、Windows Vista による生産性が低いわけではもちろんありません。

ビデオ版はこちらからご覧ください。また、音声版もこちらに用意してあります。

マイクロソフト
及川卓也

IPv6 - Windows Vista での Teredo の改良

ウィンドウズ開発統括部 — Tue, 13 Jun 2006 14:39:00 GMT

及川です。

以前のTeredo の投稿で、次のように書きました。

一口に NAT と言っても、その種類は Cone NAT、Restricted Cone NAT、Port-restricted Cone NAT、Symmetric NAT の４つに大別することができます。Teredoは、このうち、Symmetric NAT には残念ながら対応できません。

Windows Vista では、この部分が改善されています。Teredo クライアントのうちの一方が Symmetric NAT の背後にいる場合でも、Teredo が利用できるようになりました。The Cable Guy – 2005 年 10 月 Windows Vista および Windows Server "Longhorn" の IPv6 への変更?においても以下のように書かれています。

現在 Teredo は、1 台の Teredo クライアントが、1 つまたは複数のシンメトリック NAT の背後に存在する場合、動作することができます。(送信トラフィックの) 外部の宛先アドレスにより、シンメトリック NAT は同じ内部 (プライベート) アドレスおよびポート番号を異なる外部（パブリック）アドレスおよびポートにマップします。Windows XP および Windows Server 2003 の Teredo は、それ自体がシンメトリック NAT の背後にあると検出すると、それ自体を無効にします。この新しい動作により、Teredo はインターネット接続しているホストのより大きいセット間で動作することができます。

また、Windows XP では Teredo は既定状態では有効になっていませんでしたが、Windows Vista では規定で有効となります。ただし、RTM 版では、既定で有効であるものの、実際に使うためには、Windows Firewall の設定を手動で変更するか、Teredo を使うアプリケーションをインストールする必要があります。

マイクロソフト
及川卓也

IPv6 - LLMNR

ウィンドウズ開発統括部 — Mon, 05 Jun 2006 10:59:00 GMT

及川です。

Windows Vista および Windows Server "Longhorn" には LLMNR (Linklocal Multicast Name Resolution) と呼ばれるプロトコルが実装されています。これはDNSサーバーの無い１つのサブネット上で互いの名前の解決を行うためのプロトコルです。１つのサブネットで構成されることの多い家庭や SOHO のネットワークやアドホックネットワークなどで利用されます。

IPv4 では

IPv4において、DNS名が無い場合、従来の Windows では NetBIOS over TCP/IP (NetBT または NBT) を用いてこの問題に対処していました。Windows のファイルとプリンタの共有で用いられるプロトコルである SMB/CIFS に詳しい方ならばご存知だと思いますが、NetBT では NetBIOS 名前クエリ要求メッセージをローカルサブネットのブロードキャストアドレスに送る（ブロードキャストする）ことで名前解決を図ります。問い合わせを受けた名前を保持するシステムは、このメッセージを受けると、元の名前解決要求を送信したシステムに、ユニキャストで NetBIOS 名前クエリ応答を送信します。このように、IPv4 では DNS の無いローカルサブネット上での名前解決にはブロードキャストを用いた方法がとられていました。

IPv6 ではこの方法を用いることはできません。まず、ご存知のように、IPv6 にはブロードキャストが用意されていません。また、IPv6 上での NetBIOS の操作は定義されておりません。したがって、IPv6 ではこの方法に変わる別の手段が必要となります。

IPv6 での解 - LLMNR

IPv6 では、DNS サーバーに DNS クエリメッセージをユニキャスト送信する代わりに、マルチキャストアドレスに DNS クエリメッセージを送信します。サブネット上の LLMNR 対応ノードはこのマルチキャストメッセージを受け取り、自分がその問い合わせられた名前を保持している場合、それに対して応答メッセージを送信します。これがざっくりとした LLMNR の動きとなります。DNS メッセージをそのまま用いて、DNS サーバーの無いローカルサブネットでの名前解決を実現するというのが重要な部分です。

LLMNR は IETF の DNSEXT (DNS Extensions) WG で議論されています。最新のインターネットドラフトは draft-ietf-dnsext-mdns-46.txt になります。

誤解しないでいただきたいのですが、LLMNR は DNS の置き換えではありません。これはインターネットドラフトでも次のように明確に説明されています。

3.? Usage Model

LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS; rather, it enables name resolution in scenarios in which conventional DNS name resolution is not possible. This includes situations in which hosts are not configured with the address of a DNS server; where the DNS server is unavailable or unreachable; where there is no DNS server authoritative for the name of a host, or where the authoritative DNS server does not have the? desired RRs.

なお、この LLMNR に対応するために、アプリケーション側での対応は不要です。アプリケーションは DNS サーバーが存在する環境であっても、DNS が存在しない環境であっても、WSAConnectByName() または GetAddrInfoW() を使って名前解決を図ることができます。なお、LLMNR 自身の API 問題についてはインターネットドラフトの中の "4.4. API Issues" で言及されています。また、インターネットドラフトの著者の１人である Bernard Aboba が LLMNR Issues List という Web ページで LLMNR の現状をまとめているのですが、そこにある FAQ でも次のように書かれています。

Will LLMNR break applications?

Not if used properly. The main way that a bad LLMNR implementation could break applications is by advertising a IPv4 Link-Local address inappropriately. Since LLMNR can only be used for name resolution on the local link, LLMNR responders can only respond to queries for names valid on the interface on which they are received, with information that is valid on the link on which the query is received. For example, if a host had two interfaces, one which had an IPv4 linklocal address, and another with a routable address, then it would be a bad idea to respond to an LLMNR query on the interface with the routable address with an A RR including the IPv4 linklocal address which was not valid on that interface. This would encourage the LLMNR sender to attempt to contact the host on an interface that was not reachable on the local link -- causing the application to break.

簡単に言うと、正しく使われていれば、アプリケーションの互換性は保証されるということですね。

Windows CE での対応状況

実は LLMNR はすでに Windows CE で対応されています。Windows CE ではバージョン 5.0 より LLMNR の対応が行われています。

マイクロソフト
及川卓也

Windows Vista/Windows Server "Longhorn" の IPv6 サポート続き

ウィンドウズ開発統括部 — Thu, 01 Jun 2006 03:56:00 GMT

及川です。

前回、Windows Vista/Windows Server "Longhorn" の IPv6 サポートというポストをしたときに、なぜか見つからなかったのですが、Cable Guy に Windows Vista および Windows Server "Longhorn" での IPv6 機能についての紹介がされていたのを見つけましたので、リンクを貼っておきます。

The Cable Guy – 2005 年 10 月: Windows Vista および Windows Server "Longhorn" の IPv6 への変更

ただ、この記事、少し日本語訳がおかしいところがあります（お恥ずかしい）。しかも、なぜか内容も少し足りません。もし英語が苦手でなければ、~~元の英語の記事をお読みいただければと思います。日本語訳がおかしい点については、至急社内で対応いたします。~~［6/13 更新: 新しい日本語訳がアップロードされました。]

~~英語のほうで~~書かれている内容は、ほぼ前回の私の投稿で書かれているものと同じです。ただ、Teredo の改善やLLMNRについて解説されていますので、これについては別途投稿しようと思います。

マイクロソフト
及川卓也

Windows Vista/Windows Server "Longhorn" の IPv6 サポート

ウィンドウズ開発統括部 — Tue, 30 May 2006 02:38:00 GMT

及川です。

Windows Vista の IPv6 サポートの話は何度かしているのですが、整理して話したことがありませんでした。お約束していたにも関わらず、大変失礼しました。今日は、Windows Vista および Windows Server "Longhorn" の IPv6 サポートについて概略を解説します。

IPv6 は既定でインストールされ、有効であり、そして優先して使用されます

Windows XP や Windows Server 2003 までの IPv6 はプロトコルスタックの追加インストールが必要でした。Windows Vista（Windows Server "Longhorn" も含む。以下同じ）では違います。既定の状態でインストールされ、逆に GUI から簡単にアンインストールすることはできなくなっています。

また、アプリケーションもマイクロソフトが推奨するインターフェイス、たとえば、.NET Framework や上位 API をお使いの場合には、IPv6 がそのまま使えるようになっています。WinSock アプリケーションの場合もプロトコルを意識しない関数（Address Agnostic API）を使う場合には、IPv6 がそのまま使えます。さらに、IPv4 および IPv6 が両方使える場合は、IPv6 が優先して使われるようになっています。

この方針はたとえば DNS の名前解決の際にも適用されます。DNS に名前解決する際、A レコードと AAAA レコードの両方を問い合わせますが、AAAA レコードが返ってきた場合には、AAAA レコードが優先して使われます。

デュアル IP 層アーキテクチャ

Windows XP（Windows Server 2003 を含む。以下同じ）では、IPv4 と IPv6 で異なるプロトコルドライバが使われていました。具体的には %windir%\system32\drivers にある tcpip.sys（IPv4用）とtcpip6.sys（IPv6用）です。このため、これをデュアルスタックアーキテクチャと呼びます。IPv4 と IPv6 では同じフレーミングのサポートや TCP & UDP のサポートがあるにも関わらず、別の実装がそれぞれのプロトコルドライバで行われていたのです。

Windows Vista ではこれがデュアル IP 層アーキテクチャに変更されます。１つのプロトコルドライバ（tcpip.sys）には共通の TCP & UDP のサポートとフレーミングのサポートが含まれ、唯一 IP 層の部分だけが、プロトコルドライバ内で異なる実装になっています。

Windows Vista の IP スタックは１から書き直されており、パフォーマンスも劇的に向上していますが、そのメリットは IPv4 だけでなく、IPv6 にも適用されています。

GUI による構成

Windows XP での IPv6 の構成は netsh で行うコマンドラインのものが唯一のものでしたが、Windows Vista からは GUI により IPv6 の構成（アドレス設定なども含む）が行えるようになっています。

Windows XP で実装されていなかった基本機能のサポート

Windows XP ではいくつか実装されていなかった IPv6 の機能がありましたが、それらのほとんどが Windows Vista では実装されています。代表的なものを以下に列挙します。

DNS トランスポート: Windows Server 2003 では実装されていましたが、Windows XP では DNS の問い合わせが、たとえ AAAA レコードの問い合わせであっても、すべて IPv4 で行われていました。これにより、ピュア IPv6 の環境では DNS への問い合わせができないという問題がありました。Windows Vista ではこれがきちんと実装されています。
IE での IPv6 リテラルアドレス: IE で URL のアドレス部分に IPv6 アドレスを利用できないという制限がありました。Windows Vista ではこれが解決されています。
IPsec のサポート: Windows XP では IPv6 用の IPsec がサポートはされているものの、IPv4 用の IPsec と異なり、コマンドライン（それも netsh ではない独自コマンドラインツール）でのみ構成可能であり、さらに IKE がサポートされていませんでした。また、ESP において NULL 暗号化しかサポートされておらず、実質ペイロードに暗号化ができない実装となっていました。Windows Vista の IPsec では IPv4 と IPv6 の差はありません。GUI（MMCのスナップイン）において IPv6 用の IPsec も構成できるようになっていますし、IKE のサポートも、ESP での暗号化もサポートしています。
MLDv2 のサポート: MLDv1 に加えて、MLDv2 もサポートします。
PPP のサポート: PPP において IPv6 がサポートされるようになります。具体的には IPCP に加えて、IPV6CP がサポートされます。
DHCPv6 のサポート: Windows XP のリリースのタイミングでは間に合わなかったのですが、今回は DHCPv6 がクライアントとサーバーともサポートされます。また、ISP の IPv6 接続サービスを利用する場合、ブロードバンドルーターに DHCPv6PD でプレフィックスを取得し、ルーターが RA を発行するという環境を構築することもあると思いますが、Windows Vista のインターネット接続共有では、DHCPv6PD をサポートしていますので、ブロードバンドルーター代わりに利用することもできます。

Windows のコンポーネントのほとんどが IPv6 対応に

そして、最後に申し上げたいのが、Windows Vista ではネットワーク機能を持つコンポーネントのほとんどが IPv6 対応になるということです。Windows XP ではプラットフォームと API の IPv6 化は完了していましたが、その上で動作するアプリケーションは IE と Windows Media Player、FTP クライアントなどとお世辞にも多くはありませんでした。Windows Vista では開発方針として、すべてのネットワーク機能を持つコンポーネントが IPv6 にも対応すると決められています。Active Directory や DNS（クライアントとサーバー）、DHCP を含み、基本的には、すべてのコンポーネントが IPv6 になると期待していただいて結構です。

さらには、ピュア IPv6 モードでの動作も可能です。これはマイクロソフト社内でのテスト目的の意味合いも大きいのですが、本当にそのコンポーネントが IPv6 で動作しているかどうかを確認するために、IPv6 のみのモード（ピュア IPv6 モード）で構成し、コンポーネントをテストしています。したがって、アカデミックな環境などで、IPv6 のみで操作する場合にも、十分実用になる OS となっています。

以上、ざっと Windows Vista での IPv6 対応について解説させていただきました。もちろん、以前、解説した Teredo なども引き続きサポートされています（実は、Teredo は Teredo で改良が加えられているのですが）。まだ、何か説明し忘れているような気もするのですが、もし思い出したら、ここで皆さんにお知らせしたいと思います。

マイクロソフト
及川卓也

Teredo 対応のアプリケーション開発

ウィンドウズ開発統括部 — Sat, 25 Mar 2006 09:59:00 GMT

及川です。

以前、Teredo について紹介しました。Teredo によりピアツーピアに必要な NAT 越えが実現できることについて説明させていただきましたが、では Teredo 対応のアプリケーションはどのように開発すれば良いのでしょうか？

方法は２つあります。１つは Windows Peer-to-Peer API を用いてアプリケーションを作成する方法。もう１つは WinSock でソケット作成時にソケットオプションとして IPV6_PROTECTION_LEVEL? を設定する方法です。

前者の Windows Peer-to-Peer API は IPv6 を前提としています。もし IPv6 のネイティブ接続環境があれば、それをそのまま利用しますが、もし無かった場合には Teredo の接続を用います。したがって、Windows Peer-to-Peer API を使っている場合には、特別な処理は必要ありません。

WinSock アプリケーションの場合には、setsockopt() で IPV6_PROTECTION_LEVEL? を設定します。 IPV6_PROTECTION_LEVEL は次のいずれかの値をとります。

PROTECTION_LEVEL_UNRESTRICTED
PROTECTION_LEVEL_DEFAULT
PROTECTION_LEVEL_RESTRICTED

PROTECTION_LEVEL_UNRESTRICTED は同一サイトにおける接続のみを許可するオプションです。ここで言う「同一サイト」とは IPv6 のリンクローカルアドレスで接続できる場合、IPv6 グローバルアドレスを使っている場合は、プレフィックスから同一サイトと判断できる接続の場合、そして IPv6 サイトローカルアドレスで接続できる場合となります。ただし、IPv6 サイトローカルアドレスは廃止されています（RFC 3879 Deprecating Site Local Addresses）。Windows では互換性のために機能としては残っていますが、使用は推奨されていません。ご注意ください。

PROTECTION_LEVEL_DEFAULT は同一サイトおよび外部との接続を許可するオプションです。現在の主な IPv4 アプリケーションと同じ挙動をするオプションになります。

PROTECTION_LEVEL_RESTRICTED は PROTECTION_LEVEL_DEFAULT の動作に加えて、NAT を介しての通信、すなわち Teredo での通信を許可するオプションとなります。

以上のことを整理したのが以下の表となります。

保護レベル	受信トラフィックの制限の有無
保護レベル	同一サイト	外部	NAT?越え (Teredo)
PROTECTION_LEVEL_RESTRICTED	無	有	不可
PROTECTION_LEVEL_DEFAULT	無	無	不可
PROTECTION_LEVEL_UNRESTRICTED	無	無	可

オプションを指定しなかった場合は、PROTECTION_LEVEL_DEFAULT の挙動となります。つまり、開発者の意図しない NAT を越えての受信は起こりえないようになっています。

詳しくは MSDN のサイトの説明をご覧ください。

また、.NET の System.Net を使っている場合は、Socket.SetSocketOption メソッドを使ってオプションを指定することになります。

Windows Collaboration technology on Channel9

ウィンドウズ開発統括部 — Wed, 22 Mar 2006 06:48:00 GMT

及川です。

Windows Peer-to-Peer の連載ですが、進みがゆっくりなので、Windows Vista での新機能について紹介するまで、少し時間がかかりそうです。その代わりと言ってはなんですが、マイクロソフト本社の担当者による Windows Vista のピアツーピアや Collaboration 技術についての WebCast があります。英語で恐縮ですが、興味のある方は是非ご覧ください。

Channel 9 >> The Videos >> Vista Collaboration

Teredo

ウィンドウズ開発統括部 — Tue, 21 Mar 2006 06:44:00 GMT

及川です。

Windows Peer-to-Peer や MAX の解説でも出てきたように、マイクロソフトではピアツーピア通信を実現するために IPv6 の利用を推進しています。

ご存知のように、現在の IPv4 での通信ではすべてのホスト（ノードと言ったほうがピアツーピアの説明では良いかもしれません）にグローバルアドレスを割り当てることは現実的ではありません。特に家庭内のネットワークでは、複数の PC や情報家電を持っていたとしても、２つ以上のグローバルアドレスを ISP から取得していることは稀でしょう。そのため、NAT と言われる技術が使われることになります。

NAT は１つのグローバルアドレスで複数のホストをインターネットに接続することを実現しましたし、また家庭内外のセキュリティバウンダリとして、不必要なインバウンドの接続を遮断することにも成功しました。しかし、その一方で、NAT が介在することにより、インターネットでの通信が非対称となり、それによりもともとインターネットが持っていたピアツーピアの環境が失われてしまったこともまた事実です。

現在、もっとも一般的なインターネットの使われ方と言われる Web アクセスやメールなどでは、NAT は問題にはなりません。なぜなら、これらはクライアント/サーバー形アプリケーションであり、NAT 配下のホストがクライアントとして振る舞い、サーバーである HTTP サーバーや POP?および SMTP サーバーにアクセスするからです。NAT では NAT 配下のホストから通信が発生する場合には、そのアウトバウンド通信に対応するインバウンド通信のためのルールが NAT 内のマッピングテーブルに生成されます。しかし、ピアツーピアアプリケーションのように、どのアプリケーションからインバウンドの通信が発生するかわからない状況では、NAT はその通信を阻害する要因となります。

この NAT によりピアツーピア通信が阻害されてしまうことを俗に「NAT 越え問題」もしくは「NAT トラバーサル (NAT Traversal)」と呼びます。マイクロソフトでは、この NAT 越え問題を解決するために、UPnP (Universal Plug and Play) の IGD (Internet Gateway Device) を利用したルータの普及を業界各社とともに進めてまいりました。Windows XP?が UPnP のコントロールポイントとして動作することにより、必要なマッピングルールを IGD、すなわち NAT ルーター（またはブロードバンドルーター）に生成することができます。この UPnP を用いた NAT 対応のピアツーピア機能は MSN Messenger や Windows XP のリモートアシスタンスなどに使われています。

このように、UPnP?を利用することで NAT 対策が可能になったのですが、これにもまだ問題がありました。１つはすべてのルーターが UPnP 対応になっていることは期待できないことです。残念ながら、市場には UPnP 対応と言いながらも、実態は MSN Messenger など一部の主要なアプリケーションの動作だけしか保証していない NAT ルーターが多くあります。このような場合、アプリケーションが UPnP 対応をしても、NAT ルーターによって、動作したりしなかったり、その結果は神のみぞ知るということになりかねません。また、もう１つの問題は、アプリケーション側の対応が必要という点です。アプリケーション開発者にとっては、単にインターネットアプリケーションを書くだけで、NAT が介在しようが、それとも直接インターネットに接続されていようが、同じ挙動をしてくれたほうが良いに決まっています。しかし、UPnP に対応するためには、開発者が UPnP を意識したコードを書く必要があります。

そこで、マイクロソフトが考えたのが、IPv6 を用いたピアツーピアを実現する方法です。ただ、IPv6 は一般には ISP をはじめとする通信事業者により提供されている回線を購入する必要があります。これはネイティブ IPv6 環境と言われるものです。マイクロソフトはこのネイティブ IPv6 が無い環境、つまり IPv4 環境でも IPv6 を使えるようにするトンネリング技術を実装しました。トンネリング技術には、6to4 や ISATAP などいくつかの技術がありますが、どれも NAT が介在する家庭のような環境では簡単には使うことはできません。そこで、マイクロソフトが新たに開発したのが、Teredo という IPv4 の UDP を使うトンネリング技術です。

簡単に説明すると、Tereodo は UDP を使うことで、NAT 越えを実現します。Teredo Server と呼ばれるインターネット上のサーバーを仲介者とすることで、NAT のマッピングテーブルに「穴」を開け、それを利用して UDP/IPv4 通信を実現し、その上に IPv6 トンネルを構築します。一口に NAT と言っても、その種類は Cone NAT、Restricted Cone NAT、Port-restricted Cone NAT、Symmetric NAT の４つに大別することができます。Teredoは、このうち、Symmetric NAT には残念ながら対応できません。しかし、マイクロソフトの実装では、UPnP IGD の技術を併用していますので、市場の NAT ルーターのおよそ９５％ほどに対応できています。

今回は、ピアツーピアを実現するにあたって、必要となる IPv6 トンネリング技術－Teredo について書かせていただきました。本来でしたら、Teredo の仕組みについて書くべきなのですが、少し複雑で１回で書くことはできそうにありません。実は、以前、IPv6 Style に記事を書かせていただきましたので、詳しくはそちらを参照していただければと思います。なお、この記事では、Advanced Networking Pack for Windows XP をインストールすることで Teredo が利用できるようになると解説していますが、以前の投稿で書かせていただいたように、Advanced Networking Pack for Windows XP の機能はすべて Windows XP SP2 に含まれています。したがって、現在、SP2 を利用されているユーザーの方は追加でのパッケージの導入は必要ありません。

そのほか参考資料を以下に紹介しますので、あわせてご参照ください。

Windows Peer-to-Peer 概要（その２）

ウィンドウズ開発統括部 — Mon, 20 Mar 2006 14:46:00 GMT

及川です。

本日はWindows Peer-to-Peer のアーキテクチャを解説します。

Windows Peer-to-Peer は以下の図にある６つのコンポーネントにより構成されます。

グラフィング (Graphing)
「グラフ（Graph）」とは接続されたノードの集合を示します。グラフィングコンポーネントはこのグラフの管理とグラフ内のデータの配送と管理を行います。
グルーピング (Grouping)
グルーピングコンポーネントはグループの作成、グループへの招待、グループへの参加などのセキュリティ機能をグラフに対して提供します。グルーピングコンポーネントは次に説明する PNRP (Peer Name Resolution Protocol) による名前解決と探索を利用しています。そのため、複数のアプリケーションが同一のグラフを共有することができます。
NSP (Name Service Provider)
NSP はその名が示すように、名前空間を実現するサービスプロバイダです。Windows Peer-to-Peer では NSP を介して PNRP が利用されます。
PNRP (Peer Name Resolution Protocol)
Windows Peer-to-Peer における名前解決を実現します。ピアツーピア環境では DNS 名 (FQDN) を使えません。そこで PNRP を用いた名前解決が実現されています。
識別マネージャ (Identity Manager)
識別マネージャはピアツーピアにおける識別子の作成や管理を行います。
Microsoft TCP/IP バージョン 6 プロトコル (IPv6 プロトコル)
Windows Peer-to-Peer では IPv6 通信が利用されます。IPv6 のネイティブ通信が実現されていない環境では、UDP/IPv4 を用いたトンネリング技術である Teredo を利用して IPv6 接続を行います。

以上の６コンポーネントが Windows Peer-to-Peer を構成するコアコンポーネントとなります。Windows Peer-to-Peer コンポーネントは通常の Win32 のアーキテクチャに沿って設計されているため、上位のアプリケーションインターフェイスは Win32 を、下位のネットワーク部分は WinSock を用いています。また、今後の連載で解説しますが、ピア間の認証については、CAPI (Crypto API) を用いた公開鍵暗号方式が採用されています。

次回からはそれぞれのコンポーネントについてさらに解説を行います。

Windows Peer-to-Peer 概要（その１）

ウィンドウズ開発統括部 — Fri, 17 Mar 2006 15:26:00 GMT

及川です。

Winny ウィルスが猛威を振るっているときになんともタイミングが悪いという噂もありますが、あまり気にせずに Windows Peer-to-Peer の（不定期）連載を開始します。

さて、Windows XP SP2 を使われている方が多いと思いますが、皆さんのその Windows の中に Windows Peer-to-Peer という機能が含まれていることにどれくらいの方が気づかれているでしょうか。SP2 を導入してある Windows で [Windows コンポーネントの追加と削除] から [ネットワークサービス] の [詳細] を見てみてください。次の図のように、「ピアツーピア」というコンポーネントが見つかると思います。

実は、この Winodws Peer-to-Peer は SP2 の前に Advanced Networking Pack for Windows XP という名称の追加ソフトウェアとしてリリースされていました。SP2 では、この Advanced Networking Pack の機能がすべて含まれています。

Windows Peer-to-Peer はその名のとおり、Peer-to-Peer 通信を実現するためのインフラ機能を提供します。Peer-to-Peer 通信を利用したアプリケーションとして、マイクロソフトでは次のようなものを想定しています。

リアルタイムコミュニケーション
コラボレーション
コンテンツ配信
?分散処理

リアルタイムコミュニケーションは MSN Messenger をはじめとするインスタントメッセンジャーや VoIP のようなアプリケーションです。現在、多くのリアルタイムコミュニケーションは見た目は Peer-to-Peer であっても、実態はサーバーを介した、いわゆる「なんちゃって Peer-to-Peer」で実現されています。たとえば、MSN Messenger の場合でも .NET Messenger Service により通信は行われています（実際にはサービスやユーザーの通信環境によりその通信方法は異なります）。このようなリアルタイムコミュニケーションも Peer-to-Peer で実現することができたならば、たとえばインターネットに接続できないようなアドホックネットワークの環境でも利用することができます。

コラボレーションはユーザー間の共同作業や情報共有のためのアプリケーションです。マイクロソフトの Exchange Server のようなグループウェアはいわゆるクライアント/サーバーのアプリケーションですが、一方で Peer-to-Peer をベースとした Groove Virtual Office のようなものも提供されています。Groove では Exchange Server のような専用のサーバーは不要ですので、たとえば複数の企業のメンバーにより構成されるプロジェクトでの情報交換や共同作業のための環境を簡単に構築することができます。また、悪いイメージが定着してしまっているようですが、ファイル交換アプリケーションなどもコラボレーションの一種と考えることができます。

コンテンツ配信はストリーミングやパッケージの配信や配布を行うような利用形態になります。たとえば、Windows Update や Microsoft Update ではマイクロソフトのサーバーから更新パッケージをダウンロードします。たとえ、すぐ隣のマシンにすでにその更新パッケージがダウンロードされていても、サーバーからダウンロードするしか方法がありません。もし Peer-to-Peer でこの更新パッケージの配信を行うことができたならば、近くにすでにそのパッケージを保持するマシンがあったならば、そこから入手することができるようになります。

分散処理はグリッドコンピューティングとも呼ばれるアプリケーション形態です。複数のマシンの空いた時間を利用して、大規模な数値計算を行うようなアプリケーションは現在でも多く提供されています。しかし、これらは基本的にサーバーからタスクを分割し、それをクライアントマシンに配布し、結果を再度サーバーにアップロードするという方法がとられています。もし、Peer-to-Peer を用いることができれば、隣接するマシンの負荷状況に合わせてタスクを効率よく分散することもできるようになるでしょう。

ここでは４つほど一般的に考えられる Peer-to-Peer アプリケーション例を説明しましたが、実際にはこれら以外にも多くのアプリケーションが出てくることが期待されます。現在のインターネットアプリケーションは、NAT などにより Peer-to-Peer の実現が阻害されていることもあったため、クライアント/サーバーの形態をとることが多くなってしまっています。Peer-to-Peer が利用できるようになれば、今までに考え付かなかったような新しい形態のアプリケーションが出てくることが期待できます。

今回はマイクロソフトの考える Peer-to-Peer のシナリオについて紹介させていただきましたが、次回は Windows Peer-to-Peer の構成要素について説明する予定です。

P2P

Channel 9 ビデオ「ソフトイーサ登さんとの対談」

IPv6 - Windows Vista での Teredo の改良

IPv6 - LLMNR

Windows Vista/Windows Server "Longhorn" の IPv6 サポート 続き

Windows Vista/Windows Server "Longhorn" の IPv6 サポート

Teredo 対応のアプリケーション開発

Windows Collaboration technology on Channel9

Teredo

Windows Peer-to-Peer 概要（その２）

Windows Peer-to-Peer 概要（その１）

Windows Vista/Windows Server "Longhorn" の IPv6 サポート続き