無印吉澤（※新エントリはhatenablogに掲載中）

■[P2P]NECとP2P

セキュリティ強化したP2Pファイル共有ソフト、NECが開発(IT Pro)
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20041203/153427/

NECが、P2Pファイル共有ソフト「P2PWeb」というものを開発していたそうです。ちなみに、うちの日記でも以前話題にしたP2Pwebとは全く別物です（向こうはそんなこと知らずに名前付けたんだろうけど、紛らわしいなぁ……）。

P2Pソフトには、どのパソコンにどのファイルが保存されているかをサーバーで管理する方式と、端末側で分散して管理する方式があるが、P2PWebは後者の方式を採る。サーバーに処理が集中してボトルネックになる問題を回避できる。格納場所の検索を高速化するために分散ハッシュ技術を用いる。

注目点は、ファイルの管理を分散ハッシュ（Distributed Hash Table; DHT）で行っている点です。記事中には「来年後半に、P2PWebを使ったシステム構築サービスなどを開始する計画である」とありますが、この計画通りに行けば、DHTが大規模な製品に使われる初めての例になる……のかも。DHTの専門家のコメントを待ちたいところです。

それと、最近NECのサイトでもP2P技術に関するプレスリリースが公開されていました。

部門、企業の枠に制約されない安全なコラボレーション環境を容易に構築可能なネットワーク技術を開発(NECプレスリリース)
http://www.nec.co.jp/press/ja/0411/2904.html

このプレスリリースに書かれている技術の主な特長は以下の3つ。

1. 通信内容の暗号化や仮想ネットワーク生成のための複雑な設定を自動化
2. ピアツーピア型通信の利点を活かしたユーザ端末間直接通信技術を開発
3. DNSを拡張した仮想ネットワーク設定情報取得方式を開発

IT Proの記事に書かれている「アクセス権限」「通信記録」「検索を高速化」「分散ハッシュ技術」といった主なキーワードが全く入っていないので、ひょっとしたらこちらはP2PWebとは違う技術なのかもしれませんけど、それはそれでまた気になります。

うーん。同じ技術にしろ違う技術にしろ、早く詳細を知りたいなぁ……。こんなのがあるならiEXPO行けばよかったー！

■[gadget]「超」整理手帳2005

「超」整理手帳2005をAmazonで買ってみました。「超」整理法（３）を読んでわかっていたことではあるんですけど、実際に見てみるとA4横四つ折サイズの手帳って物凄くインパクトがありますね……。縦長すぎ。

■[位置情報][P2P]位置情報サービスとP2Pの親和性について考える

今日の日記は、Tomo's HotLineのエントリ「位置情報とP2P」への反応です。

僕は分散ハッシュ(DHT)のことがあまりよく分かってないので、Tomo's HotLineは読んでてもあまり反応できないのですが、今回の内容はちょっと気になりました。このエントリでは、前半部分で「位置情報を共有するにはP2Pが望ましい」と結論づけて、後半ではDHTの話に移っているのですが……しかし、位置情報とP2P型の情報共有ってホントに親和性が高いんでしょうか？

結論から言うと、位置情報の流通にP2Pが適しているかどうかは、その位置情報を利用するサービス（以下、位置情報サービス）の種類によると思います。

----

そこで、まずは位置情報を利用したサービス（以下、位置情報サービス）の分類について考えてみます。多少乱暴ですが、既存のものだけでなく将来的に考えられているものも含めて、位置情報サービスは大まかに分けると以下の2種類になります。

1. 位置情報の通知
2. 位置情報に基づく検索

前者は、移動端末を持つユーザが自発的に位置情報を通知するもの（例：auのGPS携帯から利用できるEZナビで「現在地メール」を送信）や、ユーザが遠隔地にある移動端末の位置情報を要求するもの（例：ココセコム）などです。他にも、最近各メーカが試験的に開発している、RFIDタグで取得した各ユーザの位置情報を表示するIM、といったものもこの分類に入ります。

後者は、移動端末を持つユーザが要求すると、位置情報に応じたコンテンツが配信されるサービス（例：「近くのお店検索」を実行できるEZweb版のぐるなび）や、移動端末を持つユーザが要求を出さなくても、位置情報に応じたコンテンツがプッシュ配信されるサービス（例：ボーダフォンのステーション）などです。

Tomoさんのエントリでも、GPSを利用した位置情報サービスを同じように分類されていて、以下の(1)と(2)が「位置情報の通知」、(3)が「位置情報に基づく検索」に対応しています。

１）位置情報を知人に伝える
２）位置情報を所属組織に伝える
３）位置情報を渡して、それを使ったアプリケーションの結果をもらう

----

で、本題のP2Pの話に戻りますと……。

位置情報の通知、については（そのままですが）位置情報を相手に知らせることが目的なので、位置情報の提供者と受信者が、第三者を介さないP2Pの関係であっても良いと思います。位置情報の提供者が、相手によって通知する位置情報の精度を変えるのもありでしょう。

一方、位置情報に基づく検索、については少し話が違います。こちらのサービスは、

• 位置情報の提供者（複数）
• 位置情報を元にしたサービスの提供者（複数）

の二者から構成されるもので、サービスの提供者は「ユーザの位置情報が特定の条件を満たした時に、その条件に対応した行動（位置に応じたコンテンツ配信など）を行う」ことが目的です。つまり、実際のところ、サービス提供者は相手の位置を知る必要がありません。それにも関わらず、サービス提供者は位置情報を渡されてしまっているわけです。ここに、「位置情報の通知」の場合とは異なり、第三者が介入する余地があります。

そこで、上で示した位置情報に基づく検索の構成を以下のように変えてみます。

• 位置情報の提供者（複数）
• 「条件」と「行動」の組からなる「ルール」を提供する、サービスの提供者（複数）
• 上記二者から受け取った位置情報とルールを比較する仲介者（1つ）

ぐるなびを例に取ると、位置情報の提供者は一般ユーザ、サービスの提供者は店舗情報を提供する広告主で、仲介者はぐるなびに相当します。まぁ、長々と書いてしまいましたけど、要するに、これは従来のサービスのモデルと同じものです。

しかし、このような構成にすることで、ユーザが提供する位置情報は仲介者にのみ渡され、サービス提供者の方まで位置情報が不必要に拡散することを防ぐ事ができます。位置情報の提供者とサービス提供者の間で位置情報をP2Pにやり取りするよりは、個人的にはこちらの方が「個人情報が漏洩する危険性が低い」と言えると思うのですが……皆さんはどう思われるでしょうか。是非感想をお聞かせください。

■[位置情報]プライバシを考慮する分散型位置管理機構Tachyonの開発

http://www.ipa.go.jp/jinzai/esp/15mito/mdata/16-12.html

今回の日記を書くために調べものをしていて見つけた、平成15年度の未踏ソフトです。上記URLの採択案件評価書以外にも、Tachyonプロジェクトのウェブサイトにてプレゼン資料が公開されています。

このTachyonのメリットは、位置情報を管理するサーバが分散しているために、ある1つのサーバに蓄えられた位置情報を管理者が覗いてもユーザの行動を推測しづらい、という点にあるようです。上記の「位置情報の提供者/サービスの提供者/仲介者」モデルについても、仲介者の部分をこのように分散するなどして、悪意による情報漏洩の危険を低くするアプローチはあり得ると思います。

■[blog]アルファブロガーが全然思い付かない

日本のアルファーブロガーを探せ２００４(FPN)
http://www.future-planning.net/x/modules/news/article.php?storyid=311

先週の土曜日にとあるインタビュー会（座談会？）に出た時から考えているんですけど……これが全然思い付きません。家に帰ってきて改めてRSSリーダを見てみれば思い付くと思ったんですが、3人なんて選べないし、おまけのブログも全然選べなくて困ってます。

というのも、最近はCNet Japanやネット業界の人のような一部の職業ブロガーを除くと、みんなそんなに頻繁にサイト更新してないんですよね。僕は今RSSリーダにブログを100個くらい登録しているんですけど、そのほとんどは更新ペースが週に1〜2回のもので、あまり突出したものはありません。

----

少し話はズレますけど……僕はここ最近、ウェブサイトを作る側から見たブログ（というかRSS）の利点って「あまり記事を更新しなくても人が来てくれる」ことにあるのではないか、と思ってます。RSSが普及する以前は、

サイトの更新頻度が低い
→サイトを訪れても大抵更新されてなくてがっかりする（※１）
→加えて、更新された記事がつまらないとショックが大きい（※２）
→人が来なくなる

という流れがありましたけど、RSS普及後は（※１）の状況がまず無くなり、それに加えて事前に記事の要約を読めるので（※２）の状況も回避できます。そのため、うちのような週一ペースで更新しているサイトでも、ほどほどに1日100ユニークアクセスくらい閲覧してくれる人がいるのだと思っています。

昔からある程度注目されているサイトを運営していた人はあまり感じないことかと思いますけど、これって、4年程前にもウェブ上で日記を書いていたのに1日10アクセスくらいしかなかった、なんて切ない過去を持つ僕みたいな人間には信じられない状況です。

----

で、逆にウェブサイトを見る側から見たブログの利点としては、そういう更新頻度の低いブログを大量にRSSリーダへ登録しておく事で、広い範囲の情報を容易にチェックできることかと思ってます。そして「電車男」のように本当に注目すべき面白いサイトが登場したら、それらのブログのどれかが取り上げてくれるから絶対気付くだろう、と。今はそういう妙な確信があります。

少なくとも僕にとって今はそういう状況なので、代表的なサイトを取り上げろっていわれても全然思い付かないんですよねぇ……。締め切りはだいぶ先（1月10日予定）なので、もうちょっとよく考えます。

# 徳力さんごめんなさいm(_ _)m

■[NAT][P2P]UDP hole punchingとSkype

[skype]skypeの分析論文(Tomo’s HotLine)
http://toremoro.tea-nifty.com/tomos_hotline/2004/12/skypeskype_1.html

最近、Tomo's HotLineにて紹介されたSkypeの分析論文"An Analysis of the Skype Peer-to-Peer Internet Telephony Protocol"とそれに対する反応を読んでいて、どうも「UDP hole punching」という用語の定義が曖昧なまま使われているように感じましたので、一度ここで整理してみます。

UDP hole punchingという単語がIETF(Internet Engineering Task Force)の文章に登場したのは、僕の知る限りではdraft-ford-natp2p-00（期限切れ）です。このインターネットドラフトの最新稿"Peer-to-Peer(P2P) communication across Network Address Translators(NATs)"(draft-ford-midcom-p2p-03)（12月26日現在）の3.3節"UDP hole punching"では、UDP hole punchingについて以下のように書かれています。

The "UDP hole punching" technique is the most popular and effective
of all the techniques described thus far. UDP hole punching
relies on the properties of common firewalls and cone NATs to allow
appropriately designed peer-to-peer applications to "punch holes"
through the NAT device and establish direct connectivity with each
other, even when both communicating hosts lie behind NAT devices.
This technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-
PROT], described in [KEGEL], and used in some recent protocols
[TEREDO, ICE].

この定義の前半を読んだだけでは、UDP hole punchingという用語の定義が以下の2者のどちらであるのかが明確ではありません。

• NATの背後にいるピアが内側からUDPパケットを送信して、NATに穴を開ける（＝NATが応答のUDPパケットを転送できるようにする）こと
• NATの背後にいるピアが内側からUDPパケットを送信してNATに穴を開け、NATの中にいるピア同士が第三者を介さずにUDPで通信できるようにすること

しかし、このインターネットドラフトでは、その後で

• Peers behind different NATs（3.3.1節）
• Peers behind the same NAT（3.3.2節）
• Peers separated by multiple NATs（3.3.3節）

と、両側のピアがNATの背後にいる例を挙げています。また、このインターネットドラフトから参照されているRFC3027[NAT-PROT]やNAT and Peer-to-peer networking[KEGEL]でも同様の例を取り上げているため、僕はUDP hole punchingの定義は後者であると思っていました。Skypeの分析論文に対する反応を見ていると、以下のサイトの方も同様に考えていたようです。

steps to phantasien t(2004-12-19)
http://www.dodgson.org/omo/t/?date=20041219#p01

一方、前述のTomoさんのエントリでは、UDP hole punchingの定義として前者を選択しています。上記の例では「片側のピアだけがNATの背後にいる」というパターンが触れられていませんが、この場合も、まずNATの背後にいるピアが先にUDPパケットを送信するという特殊な動作が必要になるため、これをUDP hole punchingと呼ぶ事も理に適っていると思います。元々の定義が曖昧なので、どちらが正しいとも言い切れないところです。

----

ただ、今回はUDP hole punchingという単語の定義が曖昧なために、同じSkypeの分析論文を読んでも「SkypeはUDP hole punchingをしている」と解釈する人と、「SkypeはUDP hole punchingをしていない」と解釈する人に別れてしまったのが問題です。そこで、誤解を防ぐために、Skypeの分析論文に書かれていることを「UDP hole punching」という単語を使わずに書き直すと、以下のようになります（4.4節"Call Establishment and Teardown"のFigure 10）。

• 呼び出す側のピアがport-restricted NATの背後にいて、呼び出される側のピアがグローバルIPアドレスを持っている場合、

  • ピア間の音声通信は、メディアプロクシとして動作するピア（図中のN5）によってリレーされる
  • 呼び出し側のピアは、N5に向かってUDPパケットを送信して、呼び出し側にあるNATに穴を開ける（UDP hole punchingの前者の定義）

つまり、この実験結果を信じるなら「少なくとも一方のピアがNATの背後に居る場合は、第三者によるリレーが発生する」ということなので、全セッションの中で音声通信がリレーされる割合はかなり高そうな気がします。Skypeが動作しているピア（日本/世界）の何割くらいがNATの背後にいるかについてはデータがないので、実際の所はよくわかりませんけどね。

しかし、これだけSkypeがリレーに頼っていそうだとなると、動画をサポートしたときにSkypeネットワークが保つのかどうかがやや不安です。

参考サイト：P2Pとファイアウォール
http://homepage3.nifty.com/toremoro/p2p/firewall.html

----

（2004-12-27追記）
draft-ford-midcom-p2p-03の3.3.4節を見ると「UDP hole punchingはCone NATのようなP2P-friendly NATでしか動作しない」という記述があるので、やっぱり「UDP hole punching」という単語を使う時は後者の定義で使わないと混乱しそうです。

■[P2P][検索]JXTA Search White Paperの日本語訳

IPAの未踏ソフト事業、「源氏物語の鑑賞支援ツール」など46件を採択(INTERNET Watch)
http://internet.watch.impress.co.jp/cda/news/2004/12/21/5901.html

今回採択されたプロジェクトには、「共同体的P2P全文検索システムの開発」「逆PROXY型Webサーバ拡張システム」「ユーザ間の主観的センス共感度を用いたWeblog検索システムの開発」「源氏物語の鑑賞支援ツールの開発・整備」などの興味深いテーマが並んでいる。

「P2P」と「検索」という単語の組み合わせを見ると、僕なんかは真っ先に、JXTAの黎明期に開発されていたJXTA Searchというサーチエンジンを連想してしまいます。

で、それと同時に、以前にJXTA Searchのwhite paperを日本語訳していたのを思い出しました。まるで売れ残ったクリスマスケーキのように旬の過ぎた代物ですが、何かの参考になるかもしれませんので再び公開してみます*1。僕が学生時代に作った資料そのままなのでいろいろ変なところがあると思いますが、適宜修正しますのでお気付きになりましたらツッコミ下さい。

JXTA Search: 分散ネットワークのための分散検索
http://muziyoshiz.jp/archives/JXTAsearch_whitepaper.html

文書の日付を見れば分かる通り、これはもう4年近く前の文章です。JXTA Search自体の開発は開発者のGene Kanの死去によって完全に終了してしまっており、これに続くようなプロジェクトも僕の知る限りでは登場していないようです。せつない……。

というわけで、「共同体的P2P全文検索システムの開発」は是非頑張って欲しいですね。

■[P2P]続・NECとP2P

今日（12/29）の朝日新聞朝刊に、NECのP2Pに関する記事が出ていました。どうやら以前紹介したP2Pwebについての記事のようで、その詳細は、とか氏のサイトにて詳しく紹介されています。

P2Pもブランド力(Proxyとか)
http://x.plala.jp/cgi-bin/blog/index.php?no=r492

Skypeも順調に普及しつつあるし、そろそろP2P製品が世間に受け入れられる準備が出来たってことなんですかねえ。

----

（2005/01/04追記）
＠IT：悪玉PtoPを安全・安心な善玉に、NEC(@IT)
http://www.atmarkit.co.jp/news/200501/05/p2p.html

同社では分散したコンピュータ・ネットワーク資源を共有することによるPtoPの拡張性のメリットを最大限に追及し、将来的には100億人規模のネットワークでも情報交換が行えることを目標としている。