[NAT]NAT越え入門１-NATとは何か？

今日から私が一番得意とする研究開発分野である、NAT越えとNATに対するレクチャーを連載したい。もちろん、NAT越えやNATはP2Pにも大いに関連がある分野である。期待して欲しい。

そもそもNAT越えに関わったのは、現在の会社に異動後企画書を作り、VoIP(IP電話）のNAT越えの研究を自ら始めたからである。開発コードは「シームレスコネクション」と呼び、研究開発成果は信学会のNS研究会や全国大会で投稿しているので、関心のある方は図書館等で見て欲しい。またそれが縁でキャリアグレードNATのインターネットドラフト作成にも携わっている。

この連載の目標はNATとNAT越えの基本的な部分をレクチャーすることであるが、最終的には一番技術的に困難で複雑なVoIPのNAT越えまで話を進めたい。（体力と時間があれば）

またコメントや質問は基本的にはてブでお願いしたい。適宜連載途中で回答します。

さて、NAT越えを解説するまえにNATについて説明しよう。いつものように定義等は厳密でない。わかりやすさ優先であるので、そこはご容赦願いたい。

□NATとはなにか？

NATとは、Network Address Translatorの略で、文字通り訳するとネットワークアドレス変換装置となる。実際には、NATは家庭用のネットワーク領域（LAN)とインターネット用接続用のネットワーク領域（WAN)の境界に存在し、NATがLAN⇔WAN間の通信において、LANに存在する端末のIPアドレスをNATのWAN側に割り当てられたIPアドレスに変換する役割をする。ここでWANの規定は曖昧なのだが、あくまでもNAT解説ということでお許し頂きたい。

そもそもNATはIPアドレスの枯渇を解消する目的で作られた。インターネット上で使用できるIPアドレスは一意的で、通常グローバルIPアドレスと呼ぶ。これをみんなが使ってしまうとIPアドレスがなくなってしまい、結果的にインターネットを使えるユーザに制限がでてしまう。このグローバルIPアドレスは組織的に管理されていて、通常はISPから払い出されることになる。逆にインターネット上でない場所で使えるIPアドレスはプライベートIPアドレスと呼び、これはLAN等のネットワーク管理者が独自に管理することになる。

「みなさん、端末はグローバルIPアドレスを使う代わりにプライベートIPアドレスを使いましょう。ただインターネット上もつなぎたい場合があるでしょうから、そのときにはNATがLAN内の端末プライベートIPアドレスをNATに割り当てられているグローバルIPアドレスに変換してから接続してあげるよ。」というのがNATの「本来」の利用目的なのである。

ネットワーク図をざっくり書くとこんな感じである。
端末(プライベートIPアドレス）-LAN--NAT(グローバルIPアドレス)-WAN-インターネット

ところでNATは副次的に次の効果を生み出す。というか、むしろ以下に書いてあるNATの便利さがNATの存在意義を非常に複雑にしている。

1.セキュリティの確保

後日の連載にて説明するが、NATはWAN側からLAN側への通信をブロックすることが原則である。NATは多様なネットワーク攻撃を「結果的に」防御することになる。ここで注意することは、NATとファイアウォールを混同しないこと。NATはあくまでもIPアドレスの変換装置であり、後日書くNATタイマーやフィルタリングの効果によりWAN側からLAN側への通信を「結果的に」ブロックすることになる。特にブロードバンドルータはNATとファイアウォール機能を両方具備していることがあるので、多くのネットワーク技術者（ネットワーク管理者や研究者ですら！）を混乱させる原因となっている。

もうひとつのNATのセキュリティ効果は、実際にLANに存在してる端末のIPアドレスをインターネットで通信しているサーバor端末側から隠蔽できることである。このことはNAT66と呼ばれるIPv6のNATの提案でも議論されている事項である。NAT66については時間があれば解説したい。

2.ネットワーク設計の容易さ

NATのLAN側はプライベートIPアドレスを使うことができる。このことによって、管理者が簡単にLAN内のネットワーク設計を行うことができる。なぜならWAN側はグローバルIPアドレスが必要なので、ISPにIPアドレス利用申請等をしなければならなからだ。NAT66のインターネットドラフトでもネットワーク設計を容易にするために、IPv6でもNATが必要なんだ、と書かれている。

□NAPTとは何か？

NAPTはNATと違い、IPアドレスだけでなくポート番号までNAPTが変換してしまう。ポート番号まで変換することで、グローバルIPアドレスの利用効率を更に加速させることを意味する。

利用効率についてもう少し考えてみよう。

例えば、LAN内に４つの端末があるとする。この端末がすべてインターネット上のサーバと通信するとする。NATであれば、IPアドレスを変換するだけの機能なので、NATに割り当てられているWAN側のグローバルIPアドレスが４つ必要である。ところが、NAPTの場合は、ポート番号まで変換するので（ほとんどの場合）実はグローバルIPアドレスが１つで十分である。

例えば、｛IPアドレス:ポート番号｝という表記においてLANのネットワーク情報が端末１=｛192.168.1.1:1000},端末2={192.168.1.2:2000},端末3={192.168.1.3:3000},端末4={192.168.1.4:3000}の場合、NATのWAN側では端末１=｛1.1.1.1:1000}、端末2={1.1.1.1:2000}、端末3={1.1.1.1:3000},端末4={1.1.1.1:3001}と対応する。つまりLAN内に端末が４つあっても、WAN側のグローバルIPアドレスは１個しか消費しない。これはNAPTの変換例である。

このようにポート番号を変換することにより、グローバルIPアドレスの消費を大幅に減少させることに成功した。しかしながらネットワーク管理者はもはやNATのIPアドレスだけでなく、ポート番号まで管理する必要がでてくる。ここがNAPTの難しいところである。

通常、ブロードバンドルータで使われているのはNAPTであるので、今後は断りがなければNAPTをNATと呼ぶことにする。

そして、NATが一番ややこしいのは、つい最近までNATの詳細仕様が決まってなかったのである。これがNAT越えの問題を非常に面倒なものにしている。

以下簡単にまとめておこう。
[1]通常NATと呼ばれるのはNAPTのことである。
[2]NATはIPアドレスとポート番号の変換をするのがメインであるが、セキュリティの確保とネットワーク設計の容易さを提供する。
[3]NATの詳細仕様は最近まで決まってないため、NAT越えの仕様が複雑となっている

次回はNATの詳細仕様について簡単にウォッチしてみよう。

Ｐ２Ｐネットワーク実験協議会第２回シンポジウムのご案内

久しぶりにP2P関連イベントをご紹介します。昨年私も講演したＰ２Ｐネットワーク実験協議会シンポジウムが今年も開催します。残念ながら今年は私は講演しませんが、P2Pトラヒックの最適化等興味深い講演がありますので、P2P研究者やP2P技術フリークの方は是非お越しください。私も当日会場にいる予定ですので、気軽にお声掛け＋名刺交換しちゃって下さい。色々技術面のディスカッション＋相談に乗りますよ。

＊ちなみに私はP2Pネットワーク実験協議会のメンバです。（きちんとお仕事で。趣味でやってないです。）

Ｐ２Ｐネットワーク実験協議会　第２回シンポジウム
「コンテンツ配信ビジネスを変革する商用Ｐ２Ｐの最新動向」の開催について

http://www.fmmc.or.jp/news/H101index.html

日時:２００９年２月１９日（木）１０：１５～１７：００（１０：００開場）
場所:東京大学 本郷キャンパス　工学部（新）２号館　１階　２１３講義室

技術屋さんとしての目玉はNTT研の亀井さんとBitTorrent Inc. CEO Eric Klinkerの講演。どちらもP2Pトラヒックの話ですが、前者は私も関わっている日本におけるP2Pトラヒック最適化の話、後者はIETFでのP2Pトラヒック最適化に関わる動向の講演です。P2Pトラヒック最適化はあまり国内で情報が流れていませんので、どちらも刺激的な話となること必死です。

多分国内のP2P研究者、技術者が結構集まるので、そんな人たちと名刺交換やディスカッションしても楽しいことでしょう。

せっかくなので、シンポジウムの後、勝手にP2P技術オフ会企画しても良いかもね。参加希望者が相当数集まるなら企画しようかな。本郷あたりによさげな飲み屋あるかな？

オフィスツアーのご案内：スカイリー・ネットワークス(1/30[金])

今回のオフィスツアーは、通常と違いeffyさんが企画しています。

オフィスツアーの訪問先は、スカイリー・ネットワークスさんです。 無線LAN等のワイヤレス技術と、P2P技術の組み合わせを可能にする 独自開発のマルチホップ型無線ネットワーク技術により「ワイヤレスP2P」 を実現するソフトウェアや開発キットなどを手掛けています。

株式会社スカイリー・ネットワークス
http://www.skyley.com/

オフィスツアー概要
□日時：2009年1月30日(金) 19:30-
□場所：スカイリー・ネットワークス オフィス
東京都港区芝公園3丁目6番22号　JCビル3階
http://www.skyley.com/company/map.html
（直接会場にお越しください）
□定員：８名
□参加条件：Blogかmixiに感想を書いていただける方
□参加費：無料、ただし各自飲み物とおつまみをお持ちください。
□参加方法：mixi経由でお願いいたします。
http://mixi.jp/view_event.pl?id=38899119

当日は、1/23に行われる総務省の実証実験の結果の報告や、 デモなどを行っていただける予定です。
http://www.kanto-bt.go.jp/if/press/p20/p2101/p210107r.html

P2P研究者は全て知っておきたい５つの最新キーワード

最近FlashのP2P通信対応など、P2Pの応用技術が非常に注目されています。更にP2Pの技術要素もここ数年少しずつ変化しています。ここではP2P研究者は知っておきたい、最新キーワードをやさしく掻い摘んで解説します。

□サーバサイドP2P

歴史的から言うとP2P技術はWinnyやSkypeのように個人の端末のリソースを上手に利用する技術でした。しかし最近、このP2P技術をサーバに応用することが盛んに行われています。これがサーバサイドP2Pと呼ばれる技術です。

サーバサイドP2Pが注目されるきっかけはAmazonやGoogleのような大規模WEBサイトの登場です。超大量な処理を行うためには既存の分散技術だけでは対応できなくなりつつあるのです。特に分散ストレージや分散データーベースにおいてサーバサイドP2Pは活躍します。ここ最近一番P2P界を賑わせているトピックなので、関連論文には目を通した方が良いでしょう。

代表例がAmazonのDynamo、楽天のROMAです。

□P2Pトラフィックの最適化

P2Pシステムは現在も大量のネットワークリソースを消費しています。この消費を抑制するために一部のISPではP2Pトラフィックを独自に絞っています。しかしこの手法では合法的なP2Pシステムにまで影響を与えてしまいます。

そこで考え出されたのが、ノードのネットワーク情報をうまく使ってP2Pトラフィックを最適化することです。具体的な例を示しましょう。今ISP1にノードA,ノードB,ISP２にノードCがあるとします。そしてノードBとノードCはコンテンツPを持っているとします。ここでノードAがコンテンツPが欲しいとしましょう。まず、ノードAはノード情報を管理しているサーバZにコンテンツPを持っているノードを検索するように依頼します。サーバZはノードA～Cのネットワーク情報を用いて、ノードAからネットワーク的に最短であるノードBを回答します。（＊これはP2Pトラフィックを最適化をする実現方法の一例です。）

代表的なものがアメリカのP4P、日本のP2Pネットワーク実証実験です。私もこのプロジェクトに関わっています。IETFにおいてもTANA(P2Pが利用するトラスポートプロトコルの議論）、ALTO(ノードのネットワーク情報を管理するサーバとのインターフェース規定の議論）が設立されています。

□WEBブラウザー間P2P通信

WEBブラウザーにプラグインなどをインストールしてWEBブラウザー間でP2P通信を行うことです。FlashがP２P通信を実現したことで一躍注目を浴びました。日本ではbitmediaがJavaアプレットを使ってP2Pライブ配信を行っています。ActiveXでも同様のことが実施できるでしょう。

□IPｖ４アドレス枯渇

IPｖ４アドレス枯渇に伴い、P2PシステムはIPｖ６化する必要が出てくるでしょう。IPｖ６に対応しているP２P製品として、アリエルのグループウェアが知られています。

一方IPｖ４を使うユーザにはキャリアグレードNATの影響が懸念されます。P2PシステムはUDP/TCP hole punchingなどのNAT越え技術をインプリする必要があるでしょう。

□P2PSIP

SkypeのようにP2Pを使ってVoIPを行うことを標準化する、IETFのWGです。以前よりは注目度が下火になりましたが、議論を重ねたドキュメントが少しずつリリースされています。P2P技術の課題等がまとまっているので、時間があれば目を通すと良いでしょう。

===
如何だったでしょうか？P2Pに関心がある人は、この５つはある程度説明できるぐらいには情報収集すると良いでしょう。

SBM標準データの考察～SBM研究の再現性を実現するために

第２回SBM研究会の内容について、少しずつ感想や考察を書いていこう。

まず、運営者側としての今回の研究会の目玉は「パネルディスカッション」であった。各SBM事業者と研究者が揃う機会はあまりないし、ここでSBMの標準データを議論することは、とても有意義であったと思う。

当然運営者側としても、各SBM事業者が「SBMデータ」を何らかの形で提出することをコミットすることが、このパネルディスカッションを企画した時から一番重要な目的だと考えていたが、それが果たせて正直ホッとしている。（＊パネルディスカッションで標準データの議論を、何で徹頭徹尾私がしたのか、これでわかって頂けるかと思う。）

さて、SBMの標準データの話をする前に、ここで重要な情報を書いておこう。SBMを研究する人がデータ収集をしたい場合、各SBM事業者の広報と相談しよう。各事業者は広報を通せばデータを送付するとのこと。ただし、最低限のマナーとして、そのSBMデータを使ってどういうことをしたいのか、とか、その研究成果（例えば全国大会、研究会、論文等）はSBM事業者に伝えておこうね。

*補足：SBMデータの入手についてはCS系の学会等で直接SBM事業者にお声を掛けた方が、早く作業が進むかもしれませんし、SBM事業者の方と実際話もできるので、良いかもしれません。（SBM事業者とコネがある教授等を通すという手もあります。）

では本題のSBMの標準データについて。
まず、大きなテーマとしてパネラーの大向さんが指摘した再現性の問題がある。ある研究者がデータAを使い、他の研究者がデータBを使う場合、お互いの研究をフェアに考察することが難しい。おまけにそのデータは各研究者が独自に入手（場合によって独自にツールを作成している！）場合が多いので比較するすべがない。

もし、研究者同士が同じデータXを使えば、各研究者は研究を比較しやすくなるし、結果的にSBM研究が促進されるだろう。

研究の再現性の議論については、ここも参考にしてほしい。

ウェブサイエンスの抱える「再現性」の問題

では、標準データとはなんだろうか？
画像の世界では、標準データというのが既にあって、これによってノイズ耐性や電子透かしの影響について調べられている。例えば、画像電子学会のページに具体的な情報が掲載されている。

標準データを議論するときには、個人的には以下の条件を満たす必要があると考えている。

(1)誰もがデータを入手できること（入手可能性）
(2)データ項目が汎用的な研究に耐えられること（データ汎用性）
(3)データ内容が研究の再現性に耐えられること（データ再現性）
(4)データ内容が最新データに更新可能であること（データ更新性）
(5)個人情報が保護されること（ID秘匿性）

この条件はジャストアイデアなので、もしかすると上記の条件をマージあるいは更に分割する必要があるかもしれない。

（１）については場合によってはNDA等の契約あるいはフォームの研究目的を記入する必要があるかもしれない。研究目的であれば、なるべく障壁を少なくして入手可能とすることが必要である。

（２）データ汎用性については、データ項目の内容である。データ項目としては以下のようなものが考えられる。

a)クリップしたURL
b)クリップした人のID
c)クリップした日時
d)クリップしたときのタグ
e)コメント
f)クリップした人と（SBM上で）つながりがある人（例えばお気に入りなど）

aとbが決まればc,d,eは原則一意に決まる。（*１URLに対して複数コメントを許している事業者は違う。）ｆはa～eとは独立の概念であり、事業者によってはｆのデータがないだろう。となると、もしかするとa～dあるいはa～eの情報で標準データとしては十分かもしれない。

(3)データ再現性とは、そのデータを使って研究者同士が研究成果を比較できるかどうかである。これを決めるパラメーターとして

-標準データにおけるデータ取得期間
-標準データにおける参加者数
（データ量の関係からランダムに公開データを間引く可能性あり）
-標準データにおけるクリップ数閾値
（あるURLに対してXクリップ以上でないと公開しない、あるいは、あるユーザにおいてクリップ数がX以上でないと公開しない[下限値の閾値、→逆に上限の閾値もありうる。SBMスパマーをフィルタリングする目的で。]）

が挙げられるだろう。当然研究者としてはデータ期間は大きいほうが良いし、参加者数も多い方が良い。閾値もなるべくないほうが良い。ただし、その場合SBM事業者が大変になる。そもそもどの程度の情報があれば、研究として十分なのかを議論する必要があるかもしれない。

人によっては１日の情報だけでよいと思う人がいるかもしれない。私はその意見には、あまり賛成ではない。というのは、１日という期間では、外部要因（例えば政治、経済など）に大きく左右されるからである。また曜日、時間帯によってクリップする人が違うと思われる。よって、曜日変動も踏まえると少なくとも１週間分のデータは必要ではないだろうか？

また期間が少ないと、アノマリーなデータが出にくい。ここで指しているアノマリーとは、ある意味「標準的とは外れた」データのことである。例えばスパマーによる大量投稿、あるいは関心の大きい事件やイベントに対する記事へのブックマークである。このようなアノマリーを十分抽出することができれば、例えばスパマー対策や時系列によるブックマークの研究などの活かせることができるだろう。

(4)データをどのタイミングで更新するかということだが、多くても１年に１回ぐらいあれば十分かと考えられる。この辺りはSBM研究者の意見を考えたい。逆に更新頻度が上がりすぎると、同じデータにおける研究が少なくなる可能性が高い。

(5)参加者ID（場合のよってはURLの一部も？）をランダム値にすることが望まれられる。他にも（１）と関連するがNDAによって公開を縛ってしまうことも手だろう。

以上を踏まえてSBM標準データとはどうすべきか、ということを考えて行きたい。
当然、他の分野（例えばSNS)などの動向を見ながら、どうすべきかは参考にしたい。

なお、標準データのあり方がきっちり決まる前にとりあえず各事業者がデータを公開するのは「アリ」であると考えている。公開しながら標準データのあり方を議論するのも一つの戦略だろう。

この議論は現在第２回のSBM研究会講師らによってクローズドMLにより行われている。ただし、MLには講師あるいは私の招待があれば参加できるようにはしたい。（興味のある方は講師か私に連絡してください。）方向性が決まれば、いずれオープンなMLやイベントで議論したいと考えている。

ブラウザー間直接通信で広がる世界と課題

先日、「P2Pアプリがブラウザー上で動作する！？」 というエントリーを書いたが、Skypeの解説本著者として知られ、今はアメリカで某検索エンジン企業に勤めているIKeJIさんから興味深い記事を紹介してもらった。

ブラウザというプラットフォームの為の基礎技術～ブラウザ間通信～

とても興味深い。是非P2P勉強会で講師として話して欲しいぐらいだ。
技術的には
・JavascriptだけでなくActionscriptも併用。
・ユーザはProxyサーバを立てる
といった感じ。Proxyサーバを使うのは、Javascript+ActionscriptだけではTCPの待ちうけができないため。（現在の検討では。）

本当はProxyサーバを立てずにできればすごいのだけども。この辺りは他の人の考察待ちかな。JavascriptやActionscriptでUDPがうまく使えれば話はまた変わるかも。UDPができればUDP hole punchingとかもできてNAT越えがやりやすいのだけども。あとは接続の問題も簡略化できる。

さて、仮にJavascriptやActionscriptだけでブラウザー間通信ができたらどのような世界が広がるだろうか？今日会社から家に戻る間に考えてみた。

□何ができるのだろうか？

☆Webサーバの負荷分散、キャッシュ
Webサーバからのリダイレクトによって、一部の処理を他のブラウザーが肩代わりすることはできそうだ。既に閲覧したコンテンツを他のユーザに見せたり、重いページの表示を軽くするために使ったり。これが一番実用的かも。

Ajaxとかに応用できると楽しいけども、ブラウザーがそのコンテンツを利用している時間（生存時間）が課題かな。生存時間が短いようなコンテンツにはこの方法は向かない。ブラウザーがもう他のページに移っているとこのシステムが利用できないので。

☆双方向コミュニケーション
紹介した記事にもあるようにチャットができるだろう。Javascriptだと音声を扱うのは難しいけども、Actionscriptをうまく駆使したらなんとかなるかな？（楽観的な予想というよりも希望）

☆コラボレーション
複数人で編集できるような簡易なページ（例えばWikiやスケジューラー）を作ることも可能だろう。BBSやアンケートページもこのカテゴリーかな。

☆グリッド的なアプローチ
ブラウザーによってなんらの計算をさせることも可能だろう。でも何をさせるとうれしいのかはまだ自分の中で整理できてない。

□何が課題なのか？

☆NAT越え
TCP hole punchingのようなSocket周りをゴリゴリいじる事をJavascirptやActionscriptによって実現するには正直厳しい。端末がグローバルIPアドレスを使えるかどうかで、適切な端末が通信をリレーしてあげることが必要だろう。（Skypeのリレーノードみたいな感じ。）ちなみにTCP hole punchingはそのうち解説する予定。

☆セキュリティ
Javascriptでサーバ機能を作るとなると、当然その部分がソースが平文で見える。となると、攻撃者によってソースを解析して意図しない動作をさせることは比較的容易に実現できると考えられる。対策としてJascriptソースの隠蔽が考えられるが残念ながら完全に隠蔽できることは難しい。

ええもん屋 ラボ:Javascriptの隠蔽

ゆえにJavascriptの完全性の担保をすることが解として考えられるが、これも難しそうだ。
不測の事態に備えてクライアント側でJavascriptによるセキュリティ対策が必要となるだろう。

☆コンテンツの永続性
たとえばチャットやWikiなどをこのページで作ったとしても、この機能だけではその内容を維持することは難しい。なぜならあるページにおいて閲覧している全員のブラウザーを閉じてしまったらコンテンツは消えてしまうから。何らかの形でコンテンツをサーバにアップすることが必要だろう。

☆Javascriptエンジンにまつわる課題
ブラウザーの作りにもよるが、Javascript＋Actionscriptによるプログラムの暴走、多くのブラウザーからのアクセス、攻撃者によるアタック等によってブラウザーが耐えられるかという課題がある。ChromeのようにJavascriptエンジンがマルチスレッドであれば問題ないかもしれない。

時間があまりなかったので今日はここまで。もうちょっと考えてみよう。
いずれにせよ、ブラウザー間通信は旬になりつつある。考えてみると研究的にも開発的にも面白いと思うよ。

P2Pアプリがブラウザー上で動作する！？

一般的なP2Pサービスを利用するうえで障害となる理由のひとつが、専用アプリケーションをインストールする必要があることである。ユーザにとってブラウザーで完結するサービスがほとんどである中、専用アプリケーションを入れることは大きな負担である。

アプリケーションをインストールすることは一般的な人には抵抗がある。はてな村の人には信じられないかもしれないが、メールやブラウザーを専ら使う利用者にとって余程の理由がない限りアプリケーションのインストールとその設定は避けたい事項なのだ。ルーターのポート番号開放なんてものは一般的なユーザにとってとんでもない「アクシデント」なのだ。

さて専用アプリケーションをユーザにインストールされるには、ユーザに何らかのインセンティブを設ける必要があるだろう。Winnyを未だに利用しているユーザが多数いるのには、不正に著作権を侵害しているコンテンツを無料でダウンロードできるという「インセンティブ」があるからだ。一方合法的なP2Pでも専用アプリケーションの利用を成功されている例がある。Skypeは無料で通話できるという魅力的な「インセンティブ」でこの障害をクリアした。しかし、普通のP2Pソフトウェアでその障害を越えることはなかなか難しい。なぜなら一般的なユーザにインストールを迫るだけの魅力的なインセンティブが十分でないからだ。ユーザにとってインセンティブとは魅力的なサービスをクリエイトすることや魅力的なコンテンツを扱うことに他ならないだろう。

そこで、P2P事業者はユニークなアプローチを取り始めつつある。それはP2PサービスとWebサービスの使い方をユーザにとって同一にすることである。具体的に言うと、あるP2P事業者はブラウザー上で動作するP2Pアプリケーションを作成している。

P2PアプリケーションをWebブラウザーで動作させるには、ActiveXやJavaアプレットを使うことが考えられる。残念ながらここでは申し上げられないのだが、ActiveXやJavaをP2Pとして使うには色々なテクニックが必要である。ちなみにFlashは現在のところP2Pを実現できないのだが、将来的にはサポートするという情報はある。

Peer to Peer (P2P) in Flash Player 10 beta

FlashがP2Pに対応すればP2P事業者はより簡易にP2Pサービスを提供できるようになるだろう。また違うアプローチだとブラウザーのツールバーでP2Pを動作させるというのも考えられる。

Firefox用BitTorrentのアドオン「FoxTorrent 1.0」、Akamaiよりデビュー

では実際ブラウザーによってP2Pサービスを提供しているところを紹介してみよう。

□Sharecast2（bitmedia)
P2Pでライブ中継を行うシステム。具体的にはツリー形のアプリケーションレイヤーマルチキャストを行う。
デモコンテンツの視聴
http://scast.tv/brk/ceatec/view_login.jsp
左側に実際の中継しているトポロジーが表示される。
※Java Runtime Environment がインストールされている必要がある。

ユーザにP2Pシステムをより簡便に使ってもらうための別アプローチとして、コアユーザは専用P2Pアプリケーションを利用し、単純機能だけを使うユーザはFlash（つまりP2Pを使わない）を使って利用するというのもある。これはJoostなどが既に実践している。まずは簡単に利用できるFlashによってサービスに馴染んでもらい、その後専用アプリケーションを使ってもらおうという戦略だ。

Joostが全Flash対応の新サイト公開。みんな観てる？

このFlash戦略は一見良さそうに見えるが、デメリットもある。それはFlashで利用するユーザが増えるとP2P配信システムの負荷が増えるのである。つまり、ある程度P2Pで利用してくれるユーザが存在しないと、ビジネスモデル自体が破綻する。
そのため、このような状況での常套手段して、P2Pユーザには特別なサービスが利用できる等何らかのインセンティブを設ける必要があるだろう。

ところで、Web上でP2Pシステムを動作するサービスも、このFlash戦略に近いデメリットを持つ。というのはブラウザーを閉じたら（タブブラウザの場合はそのタブを閉じたら）ユーザの端末内で動作しているP2Pシステムが終了してしまうからである。ということは、ユーザがP2Pシステムに参加している時間は専用アプリケーションを利用するよりも短くなり、結果としてP2Pシステムのメリットを十分使えない可能性がある。

ただしP2Pライブ配信の場合は同時に多数のユーザが利用することが想定されるため、Webブラウザー上でP2Pシステムを動作しても問題ないだろう。つまり、コンテンツが配信されている時間だけユーザ端末内のP2Pシステムが動作すればよいし、それにコンテンツ自体はユーザがまさに見ているからだ。つまりコンテンツ閲覧時間＝端末内でのP2Pシステム動作時間となる。オンデマンド配信の場合にはP2Pシステム内の負荷について注意深く検討する必要があるだろう。

HTTPだけでP2Pシステムを構築できないか？

現状大抵のシステムがＨＴＴＰで実現できているので、P2PもＨＴＴＰでかなりの部分構築できないのかな、と考えています。これは先日のエントリーの「Ｐ２Ｐシステムのインターフェース共通化の提案」の発展版です。

まずこの目論見を説明するためにＰ２Ｐを２つのタイプの機能にブレイクダウンします。

・Ｐ２Ｐクライアント機能
・Ｐ２Ｐサーバ機能

Ｐ２Ｐなのにクライアント、サーバと名づけるには違和感がある人もいるとは思うが、まずはこれで説明しよう。クライアント、サーバが意味することは後ほど説明します。

Ｐ２Ｐクライアント機能は「ＨＴＴＰクライアント」です。もっと具体的に言うと、ＨＴＴＰでＰ２Ｐサーバに「リンク」を張り、維持し、ＨＴＴＰで各種「要求」を行います。
要求とはリンクの形成・維持（Ｊｏｉｎなど）、ＤＨＴで言うＰＵＴやＧＥＴ要求などです。

Ｐ２Ｐサーバは「ＨＴＴＰサーバ」です。もっと具体的に言うとＨＴＴＰでＰ２Ｐクライアントからのリンクを待ちうけ、維持し、ＨＴＴＰで各種「要求」を処理します。

通常のＰ２ＰノードはＰ２Ｐクライアント機能＋Ｐ２Ｐサーバ機能と考えられます。この亜種としてＰ２Ｐサーバ機能しかないノードやＰ２Ｐクライアント機能しかないノードというのも考えられます。これらを含めてＰ２Ｐシステムと呼ぶことにしよう。

もう少し説明を続けます。

今すべてのノードがグローバルＩＰアドレスを保有しているものとします。ノードはＨＴＴＰサーバ機能を持っているので仮にすべてのノードが８０番ポートでＨＴＴＰを待ち受けるとします。
つまり、Ｐ２Ｐに関するリンクを８０番で待ち受けるものとします。

ノードＡ、ノードＢが存在した場合のリンクの形成を考えてみます。

ノードＡはノードＢに対してあて先８０番ポートで接続します。ノードＢは８０番ポートでノードＡのリンクを待ち受けます。

逆にノードＢはノードＡに対してあて先８０番ポートで接続します。ノードＡは８０番ポートでノードＢのリンクを待ち受けます。このようにすることでＨＴＴＰのセッションは２つできるが、２つまとめてみると「双方向」のリンクが構築できます。

（本来ＴＣＰコネクション１本でも双方向リンクを構築できるが、それは本質的ではないので、ここでは説明しません。）

Ｐ２Ｐサーバ機能は、リンクの接続を受けることと要求の返答をするだけではありません。各種要求を必要に応じて他のノードに転送する役割を持ちます。構造化オーバーレイであれば転送経路はひとつのリンクだし、非構造化オーバーレイでは複数のリンクを各種要求が転送するかもしれません。ここが通常のＷＥＢサーバと違うところです。Ｐ２ＰサーバはＷＥＢサーバというよりもＳＩＰサーバの機能に近いかもしれません。

ではＨＴＴＰを使ってどう要求を行う、あるいは要求を返答するかということですが、これはＳＯＡＰやＲＥＳＴのような既存技術を使えばよいでしょう。

つまり、ＮＡＴがない前提あるいはＵＰｎＰが使える前提であればＨＴＴＰだけでＰ２Ｐシステムが構築できることが考えられます。

話は元に戻って、先ほど「Ｐ２Ｐシステムのインターフェース共通化の提案」について話しましたが、そうなるとＰ２Ｐの共通インターフェースを記述する方法というのはＳＯＡＰかＲＥＳＴの方がよいかもしれません。興味ある人で勉強会を実施してＳＯＡＰやＲＥＳＴを使ってＰ２Ｐシステムのインターフェースを規定したり、実装してみませんか？

なお、今回の提案は、ＩＥＴＦのNAT越え技術に関するドラフトＮＩＣＥにインスパイヤされて検討したものです。

P2Pシステムのインターフェース規定共通化の提案

P2Pシステムについては各アプリケーションが最適に動くように実装されており、インターフェースやAPIが共通化、標準化されていないのが現状だ。

ただし構造化オーバーレイのAPIについては抽象化の検討を行った著名な論文がある。
Towards a Common API for Structured Peer-to-Peer Overlays

構造化オーバレイを研究する人には避けては通れない論文で、各種構造化オーバーレイをどのようなAPIで規定すると動作できるかを検討している。Overlay Weaverの設計に大きな影響を与えている。

ネットワークインターフェースというと、共通化しようとする試みや抽象化して検討するという研究を少なくとも私は知らない。ここで言うネットワークインターフェースとは構造化オーバーレイ（あるいは非構造化オーバーレイも含めることができるかもしれない。）のピア間で流通するコマンド、データ構造を規定することである。

制御信号の帯域はデータ転送用の帯域に比べて無視できるほど少ないので、インターフェースの規定には可読性の高いXMLが望ましいだろう。そうなると、分散システムでよく使われているSOAPや、あるいはRESTのようなものがうまく使えるかもしれない。

問題は構造化オーバーレイの制御信号について、どのようにすれば分類・網羅できるかということである。これは先ほど紹介したAPIの抽象化の検討が大きな参考になると思う。

まだ数分考えただけだが、以下のようなことがインターフェースとして考えられる。

・ピア操作系
-ピアの参加
-ピアの離脱

・（オーバーレイを維持するための）リンク操作系
-リンクの確認
-リンクの形成
-リンクの切断

・（オーバーレイ内に格納している）データ操作系
-データの格納（put)
-データの入手（get)
-データの削除(remove)

・ピア間で直接通信している場合のデータ操作系
-リンク確立
-データ送信/受信
-データ送受信終了
-リンク切断

・検索方法
-recursive
-iterative

・NAT越え系
-リレーノード検索
-ネットワーク（NAT)情報交換（ICEライク）

・スーパーノード系
-スーパーノード検索

・認証系
-認証

もう少し考えて見ます。
インターフェースの規定を決めることで、汎用的なシステムができ且つ開発期間が短縮できると思います。

第３回DHT勉強会講師陣のお知らせ

第３回DHT勉強会の講師陣が大体揃ってきたので、ここで一旦中間発表をします。
まだ本決定でないので、名前や所属は伏せておきます。

□某ISPに最近就職した勉強会の常連
・今回もDHTの実装に関する話題を講演することになると思います。

□武蔵野方面にある某研究機関のとある方
・ドロネーネットワークといわれる位置考慮したP2Pネットワークの話がメインの予定です。

□某北関東にある大学の大学生の方
・最近話題のDHTによる分散ストレージの話をして頂く予定です。

□某ゲーム会社のとある開発者
・BitTorrentの実装の話をしていただく予定です。

なお、私は今回P2PSIPを技術的な面から詳しく話そうと思います。

まだ講師は受付中ですので、興味がある方は
http://mixi.jp/view_bbs.pl?id=30727842
に書き込みを。個人的に問い合わせして頂いてももちろん可能です。

また場所を提供して頂く方も絶賛募集中です。今回も土日祝で行う予定です。
できれば今年中に開催したいです。

JANOGでIPv4アドレス枯渇対策について講演します（7/10[木]、品川）

7/10（木）から開催されるJANOG 22（品川）にて、IPv4アドレス枯渇対策について説明します。

IPｖ４アドレス枯渇対策としてはIPv6移行するのが基本戦略ですが、IPｖ４しか対応しない端末を救済するために移行過渡期にISPが巨大なNATを設置してグローバルIPアドレスを節約しよう、という話です。このNATによる影響はP2PはもちろんWebサービスも含めて非常に広範囲におよびます。

私はこの巨大なNAT(キャリアグレードNATと呼びます）の要求条件の検討やサービス影響を調査しているメンバですが、講演では

・キャリアグレードNATの要求条件とは何か？
・キャリアグレードNATで影響が出るサービスとは？
・キャリアグレードNATでサービスへの影響を出にくくする方法とは？

等を話せればと考えています。今まで明らかになってなかったキャリアグレードNATの技術的詳細を語る予定です。

サービスのことから技術的な詳細なことまで当日の質問はウェルカムなので、興味のある方は是非ご参加願います。懇親会にも参加予定です。

また、パネラーにはVoIP Conference 2008でもおなじみNAT越えのスペシャリスト、コナミの佐藤　良氏も同席されます。

IPv4アドレス販売終了のお知らせ？～ISPのNATで起きること～
http://www.janog.gr.jp/meeting/janog22/program/day1/day1-5.html

総務省やJPNICによる報告書においてIPv4アドレス枯渇への対策として最も有力な候補とされているのがIPv6です。
また、合わせてIPv6までのツナギの移行方式としてIPv6 と「ISPによるNAT」による IPv4アドレス変換の共存が記載されていますが、これについて 各方面と協力して乗り越えていくべき課題が多々あることがより明確になってきました。

まず「ISPによるNAT」についての検討状況を提示し、詳細な課題の共有と、対策について議論進めていきたいと考えています。

・利用できなくなるアプリケーション、サービスとは何か？
・既に宅内で使ってるプライベートアドレスとの衝突は？
・NATテーブルのログをとっていれば、アクセスを追跡できるのか？
・ISPのNATにはどのような機能が必要なのか？ 総務省やJPNICによる報告書において

オフィスツアーのご案内：コミュニティエンジン(7/4[金])

今回のオフィスツアーはコミュニティエンジンさんです。
ネットワークミドルウェアを中心に開発している企業ですが、最近ゲーム機器用P2PミドルウェアLiquidSyncをリリースして多方面から注目を浴びています。

またCEOの中嶋 謙互氏はIPAのスーパークリエータとしても知られています。

LiquidSync
https://plus.ce-lab.net/liquidsync

オフィスツアー概要
□日時：2008年7月4日（金)19:30～
□場所：コミュニティエンジン初台オフィス
http://www.ce-lab.net/ja/profile.html
（直接会場にお越しください）
□定員：１２名
□参加条件：BlogかMixiに感想を書いていただける方
□参加費：無料、ただし各自飲み物とおつまみをお持ちください。
□参加方法
Mixi経由でお願いします。
http://mixi.jp/view_event.pl?id=31995555

当日は携帯ゲーム端末を使ったP2Pミドルウェアのデモ等を見せて頂く予定です。

NAT技術者にお勧めするRFCとドラフト

P2Pを含めた通信サービスにおいて、NATは外部からの通信を遮断する厄介なネットワーク機構です。そのため昔からNAT越えをするための研究が行われていました。

しかし、結構泥臭い研究開発のせいか、日本ではあまりNATに関する研究開発がありませんし、NAT越え研究の意義があまり世間に知られてないようです。これは大変残念なことです。

私は昔からNAT越えに興味があり、Skypeが出たころからBlogでUDP  Hole Punchingを使っている可能性があることを指摘したことがあります。現在ではNAT越えがまさしく本業になっていて、IP電話のNAT越えや最近有名になっているIPｖ４アドレス枯渇のためにISPが設置する「キャリアグレードNAT」の研究開発に携わっています。

2010年の冬には日本のIPv4アドレスがなくなる

なお、余談ですがキャリアグレードNATについては近日技術的な内容のプレゼンをとある有名なイベントで行う予定です。是非ご期待ください。

さて、 RFCやインターネットドラフトには様々なNATやNAT越えに関わるドキュメントがあります。今回はNATに関心がある人が特に読んで欲しいRFC、ドラフトを紹介します。

□日本語によるドキュメント
RFCをいきなり読むのもしんどいので、まずは日本語によるドキュメントを紹介します。
VoIP Conference ２００８プレゼン資料
コナミの佐藤さんによるNATの分類方法とUDP Hole Punching等の解説記事です。特に市場におけるNATシェアのグラフは国内外で非常に注目されています。

□STUN(RFC3489)
STUNの役目は大きく分けて３つあります。
役割１：NATの外側に割り当てられたIPアドレスとポート番号を通知する
役割２：NATの外側に割り当てられたIPアドレスとポート番号を維持する（キープアライブ）
役割３：NAT種別をチェックする

役割１，２はUPnPで行うことをサーバを使って行っていると考えるとわかりやすいでしょう。
役割３は少し特殊です。NAT種別がわかるとUDP Hole Punchingができるかどうか判別することができます。ここでは詳細内容を割愛しますが、NAT種別には
・Full Cone NAT
・Restricted Cone NAT
・Port Restricted Cone NAT
・Symmetric NAT
というのがあり、後に書くほど外部との透過性が薄れます。Symmetric NATがあるとUDP Hole Punchingができない場合があるというは覚えておいた方がいいです。
なお、STUNの後継プロトコルにSTUN-bis(draft-ietf-behave-rfc3489bis-15)があります。
STUN-bisはUDPだけでなくTCPにも対応していること、STUNで言うところの役割３を削除したところがSTUNとの主な違いです。

□TURN（Traversal Using Relays around NAT）
現段階の最新ドラフト名はdraft-ietf-behave-turn-07
TURNはTURNサーバを使って端末間のデータを中継する。データ中継はTCP/UDPのどちらも可能で、更にTCP→UDPのようなトランスポート変換も可能。データを中継する前に、まずはサーバ中継用のIPアドレス、ポート番号の払い出し要求を端末からするのが特徴。
TURNはIP電話を意識した作りとなっているので、IP電話とは相性が良い。

□ICE（Interactive Connectivity Establishment)
現段階の最新ドラフト名はdraft-ietf-mmusic-ice-19
ICEは複数のNAT越え方式を端末間で自律的に選択する仕組みを持つ。またICEはSIP（SDP）を使って自端末のNAT関連情報を交換する。
SIPの知識が必要なので、やや難しいドキュメントだがこれがわかれば大抵のNAT越え技術は理解できるはず。

私が今年信学会全国大会で発表したテーマはTURNを拡張したHTTPトンネリングを作り、それをICEに対応させることでした。（つまり、UDP非透過のネットワーク環境でもIP電話ができる）

☆上記３つがまずは内容を押さえて欲しいドキュメントですが、次に重要となる２つドキュメントも参考としてあげます。

□Network Address Translation (NAT) Behavioral Requirements　for Unicast UDP(RFC4787)

NATのUDPに対する要求条件が書かれています。STUNではNATタイプは４タイプですが、このRFCではより厳密に
・ポートマッピング（ポート番号の割り当て方）
・フィルタリング（外部からの通信の遮断の仕方）
の２軸によって分類します。またこの２つの概念以外にもヘアピンやキープアライブに必要な時間等NATに関わる技術的要素が網羅されているので、読むことをお勧めします。
なお、TCPとICMPに関するNAT要求条件のドラフトもあります。
draft-ietf-behave-tcp-07
draft-ietf-behave-nat-icmp-07

□Best Current Practices for NAT Traversal for SIP
ドラフト名はdraft-ietf-sipping-nat-scenarios-08
TURNやICEを使った場合の例とシーケンスが載っています。TURNやICEと併用して読むと理解が深まるでしょう。

なお、本記事でNATに興味をもたれた方にうれしい情報です。
6/27(金）　新宿にて私とコナミの佐藤さんによるNAT技術講座が開催されます。
詳しくは第１０回SIProp勉強会の案内をご覧ください。参加費無料です。

(*開催日が変更になりました。ご注意願います。）

SIPのNAT越えについては、これより高度な内容になるので、そのうち掲載します。
また９月の信学会NS研究会（東北大）でSIPやRTPなどのNAT越え技術について発表する予定ですのでご興味ある方は是非ご参加を。

この記事を通して多くの人がNATに興味を持って頂ければうれしいです。

第３回DHT勉強会の講師募集について

お待たせしました、第３回DHT勉強会の講師を募集します。
DHTに関心のある方、有識者が多数集まる場でプレゼンテーションしませんか？

□講師応募資格

（ロング）
-DHTに関する研究開発をされている方（学生含む）
-40分程度のプレゼンテーションが可能な方
-4名程度
-プレゼン資料をWebで公開できること（抜粋でも可能）

（ショート）
-DHTに関する研究開発をされている方（学生含む）
-15分程度のプレゼンテーションが可能な方
-4名程度
-プレゼン資料をWebで公開できること（抜粋でも可能）

なお、ロング、ショートともに今までの学会発表等と同一内容でも構いません。
ただし企業の宣伝に特化した発表は控えてください。

またDHTに関連してなくても、P2Pに関して重要な発表と事務局が判断した場合には講演することができます。

□開催時期
２００８年冬～２００９年春
（講師が集まり次第、時期を調整します。講師の集まり具合によっては開催時期を早める可能性があります。）
平日開催か土日開催かは決めていません。

□開催場所
都内を予定しています。開催に協力して頂ける大学、企業の方ご連絡をお願いいたします。

□講演料について
イベントが無料開催の場合は講演料や旅費補助は出ません。ただし、懇親会で補助を致します。イベントが有料開催の場合については講師陣で調整します。

□注意事項
P2P教科書が出たこともあり、DHT勉強会は今回から参加者がDHTに対して一般的な知識がある前提でプレゼンテーションを行うことを考えています。

□応募方法
Mixiの講師応募トピック
http://mixi.jp/view_bbs.pl?id=30727842
で連絡頂くかtnishita@yahoo.co.jpにタイトル「第３回DHT勉強会講演」と書いてメールして下さい。

皆様奮って応募してください！

グリッドソリューションズオフィスツアー感想

4/25(金）にP2Pコンテンツ配信企業で注目を集めているグリッドソリューションズにお邪魔しました。

＜Mixiでの応募フォーム＞
http://mixi.jp/view_event.pl?id=29237655

参加者は９名。P2P関してグリッドソリューションズ社員も含めて段々白熱した議論が展開されました。

グリッドソリューションズには料理部というのがあって、パーティ毎においしい料理を振舞うのが恒例とのことです。

今回は
・グリーンカレー
・チーズ入り春巻き
を頂きました。ごちそうさまでした！
（写真は誰かがアップしてくれるはず。）

グリーンカレーはココナッツが効いているのですが、辛さも適度で参加者全員が一斉に食べて、瞬間的になくなってしまいました。（社員にタイに一年間在住されていた方がいました。）

また、チーズ入り春巻きはエスニックなスイートチリソースをつけて食べるのですが、こちらもソースとの相性が抜群で参加者から大絶賛の嵐でした。

P2Pについては、昨年度の実証実験のことやP4Pのことを話したり、今後P2Pでどうすればビジネスとして成り立つのだろうか？というテーマを中心に議論が交わされました。

また、グリッドソリューションズのウリのひとつである、P2Pを使いながら簡単にダウンロードができるサービスのデモがありました。ダウンロード したEXEファイルを実行すると、特定コンテンツをP2Pでダウンロードができます。これなら普通のユーザでもP2Pを簡単に使えます。
ActiveXを使うことは検討しなかったのですか？と質問したら技術陣がActiveXが好きでない！ということで却下だったそうです。

GDライト
http://www.gridsolutions.co.jp/products/gd/index.html

社歴についても紹介がありました。昨年に続いて今年もInteropで展示があるそうです。特典？があるかもしれないので、P2Pに興味がある方は是非ブースへ。

さらにいつものオフィスツアーの如く、ここでは書けない話題もたっぷりと。

グリッドソリューションズでは定期的にパーティを開くとのことです。またこのようなオフ会ノバを提供して頂けるかもしれません。グリッドソリューションズ様、ありがとうございました！

＊ブロガーが参加できるオフィス見学＋懇親会の開催が可能なIT企業の皆様、是非ご連絡をお願いいたします。

オフィスツアー(グリッドソリューションズ）のご案内（4/25[金]渋谷）[再周知]

今回のオフィスツアーはグリッドソリューションズさんです。
BitTorrentベースのコンテンツ配信システムを開発しているベンチャーです。
私もメンバとして参加しているP2Pネットワーク実験協議会にて、実証実験を実施中です。

最近ではインストールレスでファイルをダウンロードできる「使い捨てワンタイムダウンローダ」で注目を浴びています。

オフィスツアー概要
□日時：2008年４月25日（金)19:30～
□場所：グリッドソリューションズ渋谷オフィス
（直接会場にお越しください）
□定員：１０名
□参加条件：BlogかMixiに感想を書いていただける方
□参加費：無料、ただし各自飲み物とおつまみをお持ちください。

若手社員中心の活気のある会社です！皆様の参加をお待ちしております。
当日はP2Pコンテンツ配信のデモ等を見せていただく予定です。

参加申し込みは
http://mixi.jp/view_event.pl?id=29237655

からお願いいたします。（Mixi)

[P2P]第２回関西P2P勉強会のご案内

直前の周知になりましたが、主催者側の依頼によってBlogにてご案内します。
ご都合のつく方は是非。

＝＝＝

第2回関西P2P勉強会を下記の日程で行います。
皆様、お誘い合わせの上、是非ご参加ください。

□日時: 2008年3月29日(土） 13:30-17:30

□場所: キャンパスプラザ京都6F 大学院共同サテライト 第2講習室
http://www.jarl.com/kcwa/2005/kyanpas.html

□参加費：無料

□当日スケジュール
13:00- 準備
13:15- 開場
13:30- 開会の挨拶 (木浦)

13:35-14:20 「構造化オーバレイ Skip Graph と PIAX における活用」
(株) BBR CTO　吉田 幹

構造化オーバレイの中でも non-DHT として分類される Skip Graph について、
その特徴とアルゴリズムの紹介をする。Skip Graph は、Skip Listと呼ばれる
検索技術をP2Pネットワークに応用した構造化オーバレイで、DHTと同等のスケ
ーラビリティを持つだけでなく、範囲検索にも威力を発揮する。本講演では、
この Skip Graph が、DHTや地理的検索、さらには多次元範囲検索に応用でき
ることを、PIAX における実装を交えて紹介する。

14:20-15:05 「幾何学的な接続経路を持つP2Pドロネーネットワークについて」
関西大学　奥 智照

幾何学におけるドロネー図をP2Pネットワークに適用したP2Pドロネーネットワー
クについて、その構成アルゴリズムと特徴について紹介する。さらに、
Skip Graphの構造をP2Pドロネーネットワークに適用することにより、２次元
平面上を低いHOP数で結ぶことが可能にし、スケーラビリティを持つだけでなく、
範囲探索への応用についても解説する。

15:05-15:15（休憩）

15:15-16:00 「Inside Bamboo DHT」
大阪市立大学　藤田昭人
(講演内容については現在調節中です)

16:00-16:45 「Network Aware OverlayとNetwork Coordinate」
同志社大学　木浦正博

近年のオーバーレイ研究では、データの検索やダウンロードの高速化のために、
実ネットワークの状態を考慮する方法が盛んに研究されている。本講演では、
これまでのオーバーレイ研究とその分類について紹介するとともに、
オーバーレイにおいて実ネットワークの状態を考慮するためのアルゴリズムである
Network Coordinateとその例について解説する。またNetwork Coordinateの一つ
であるVivaldiを用いた実験結果などについても紹介する。

16:45-17:30 「P2P手法によるインターネットノードの階層的クラスタリング」
大阪市立大学　上田達也

インターネット上のノードを距離に基づいてクラスタリングすることができる
と、様々なネットワークアプリケーションで有用である。本講演ではインター
ネット上のノード集合をP2P方式を用いて階層的にクラスタリングする手法につ
いて考察する。

17:30- 後片付け

参加表明は
http://mixi.jp/view_event.pl?id=28294339

□備考
■定員
会場の関係上、講師の方々を除いて
定員は30名となります。(変更の可能性あり)
31人目以降はキャンセル待ちとなります。

■懇親会
当日は勉強会終了後、懇親会を予定しております。
詳しい内容につきましては、決定し次第追記いたします。

■ボランティア
当日のボランティアを募集します。
希望者は当日13時に会場にお集まりください。
受付等の簡単な軽作業です。

以上、よろしくお願いいたします。

グリッドソリューションズオフィスツアーのご案内（4/25[金]渋谷）

次回のオフィスツアーはグリッドソリューションズさんです。
BitTorrentベースのコンテンツ配信システムを開発しているベンチャーです。
私も参加しているP2Pネットワーク実験協議会にて、実証実験を実施中です。

オフィスツアー概要
□日時：2008年４月25日（金)19:30～
□場所：グリッドソリューションズ渋谷オフィス
（直接会場にお越しください）
□定員：１０名
□参加条件：BlogかMixiに感想を書いていただける方
□参加費：無料、ただし各自飲み物とおつまみをお持ちください。

若手社員中心の活気のある会社です！皆様の参加をお待ちしております。
当日はP2Pコンテンツ配信のデモ等を見せていただく予定です。

参加申し込みは
http://mixi.jp/view_event.pl?id=29237655

からお願いいたします。（Mixi)

Continue reading "グリッドソリューションズオフィスツアーのご案内（4/25[金]渋谷）"

情報共有（Ｐ２Ｐ）研究会[2/29（金）]懇親会開催について

情報共有（Ｐ２Ｐ）研究会[2/29（金）]の後に懇親会を開催します。
情報共有（P2P）研究会の講師やスタッフも参加します。
情報共有研究会に参加する方はもちろん、懇親会のみの参加も可能です。

□日時：2/29(金） 18:00から2時間程度（時間が変更になっています。ご注意願います。）
□場所：北海道　新橋四丁目
http://r.gnavi.co.jp/g306003

□定員20名（講師・スタッフを除く）
□参加費：出来高見合い
□参加方法
Mixiのイベントトピックから参加表明してください。
（20名を超えた場合にはキャンセル待ちとなります。）
http://mixi.jp/view_event.pl?id=28143282

皆様、奮ってご参加願います！

[P2P]情報共有（Ｐ２Ｐ）研究会[2/29（金）]のご案内

おまたせしました、P2P勉強会の後継となるイベント、情報共有（Ｐ２Ｐ）研究会のお知らせです。私も講演します。参加者募集もすでに始まっています。

http://www.jipdec.or.jp/ov/p2pjipdec/index.html

□研究会名称：
「情報共有（Ｐ２Ｐ）研究会」

□主催：
財団法人 日本情報処理開発協会(JIPDEC)

□講師：
・首藤 一幸 氏
　ウタゴエ株式会社 取締役 ＣＴＯ
　★Proof of conceptのその先に ～ オーバレイネットワークの実際 ～

・藤田 昭人 氏
　大阪市立大学大学院　創造都市研究科
　★Inside Bamboo DHT

・亀井 聡 氏
　日本電信電話株式会社 ＮＴＴサービスインテグレーション基盤研究所
　★ネットワークインフラストラクチャー★

・林 雄一郎 氏
　株式会社吉田鎌ヶ迫 取締役副社長
　★携帯用Ｐ２Ｐフレームワーク

・西谷 智広
　エヌ・ティ・ティ・コミュニケーションズ株式会社 先端IPアーキテクチャセンタ
　★Ｐ２Ｐの動向を振り返り、今後のＰ２Ｐサービスを予想する

□場　所：
機械振興会館：東京都港区芝公園３－５－８ ６階（６Ｄ－１会議室）

□日　時：
２００８年２月２９日（金）9:30-17:00

□参加費：
無料

奮ってご参加ください！
＊私の方で懇親会を企画する予定です。

吉田鎌ケ迫オフィスツアー(1/18)感想

1/18（金）携帯用P2Pフレームワークのリーディングカンパニー、吉田鎌ケ迫におじゃましました。吉田鎌ケ迫ではP2Pミドルウェア「Spear」を開発し、携帯ゲームメーカ等にミドルウェアを提供しています。またSpearを拡張して多人数でP2P通信が可能な「Spear Multi」も開発しています。

募集者は７名（吉田鎌ケ迫スタッフを除く）で、更に吉田鎌ケ迫からは３名参加して頂きました。

（参考）募集の周知の記事

□会社の雰囲気

スタッフはまだ１０名にも満たない会社ですが、色々な会社から非常に問い合わせが多いという事で、やはり注目されている会社だと感じました。目下開発者を募集中で、欲しいエンジニアはアリエル同様「きれいなプログラムを書ける人」だそうです。また近いうちに、今より広いオフィスに転居したいとの事です。なお、社名は社長（吉田氏）と副社長（鎌ケ迫氏）の名前を続けてインパクトのあるものにしたとのことです。

□P2Pだけでない？

吉田鎌ケ迫というと携帯P2Pフレームワークで有名ですが、P2Pに固執しているわけではないそうです。当初はニッチなものに注力したいために携帯＋P2Pという軸で取り組んできましたが、今後は更なる展開を考えているとの事です。もっとも起業時は携帯＋P2Pでうまくいくと踏んで詳細調査をしたとこと、その当時はまだP2Pに対応している携帯がなくて愕然としたとのことです。一時は赤字寸前までなったとか。

□Spearのデモ

いよいよ携帯フレームワークSpearのデモです。クライアント＝サーバ方式だと携帯間で１秒程度の遅延が発生するにもかかわらず、Spearだとほぼ瞬時に応答するのがわかります。Spearがオンラインゲームに採用される所以です。
なお、Spearでは一度携帯間をマッチングした後は原則はクライアント＝サーバ間で通信をしないとのことです。そのため、クライアント＝サーバ方式の携帯ゲームシステムに比べて、大幅なコスト削減が期待できます。

その後Windows Moblile上でのSpearのデモがありました。Google Mapsの上でペンで経路等をなぞると瞬時に相手の端末にその経路（すなわちペン情報）が伝わります。これは便利！と参加者全員が頷きました。

Spearの今後の展開ですが、他キャリアにも対応したいとのことです。もっともP2Pに対応しているキャリアは現状KDDIだけなので、実際に展開できるかどうかはキャリアの動向次第ということになりそうです。

□携帯＋P2Pはブレークするか？

最後にまとめとして個人的な感想を書いておきます。
携帯＋P2Pはブレークするかどうかですが、
[1]大手キャリア（Docomo,ソフトバンク）がP2P対応すること
[2]P2P対応する際にトラフィックを充分活用できる事（すなわち規制がないこと）
[3]P2Pのトラフィックに対して追加料金を課金しない事

の３点が必要だと考えています。[1]はもちろんのことですが、[2][3]ができないとP2Pでのファイル共有やVoIP等のP2Pを最大限活用できるサービスが実現できません。

携帯を使えば
[A]位置情報連携
[B]メール・電話連携
[C]カメラを使ったサービス（動画配信、静止画のファイル共有）
[D]携帯な個体識別子情報によるユーザ認証
を使ったP2Pサービスが実現できるでしょう。P2Pは認証が弱いことが欠点の一つですが、Dを使えば非常に強固なP2Pインフラが構築できるかも知れません。

ユビキタスな世界になれば携帯を使ったサービスの市場規模は更に大きくなるでしょう。携帯＋P2Pはこれらのサービスの構築のコストを抑える事によって、ユビキタス世界の拡大を支援することになると信じます。

参加者のBlog

吉田鎌ケ迫の鎌ケ迫さん
http://blog.yoshidakamagasako.com/kamagasako/item/572#more

SIProp 今村さん
http://www.noritsuna.com/archives/2008/01/post_100.html

[P2P]吉田鎌ヶ迫オフィスツアー（1/18[金])

オフィスツアー第４弾はP2P携帯フレームワークで注目を集めている吉田鎌ヶ迫です。
当日は携帯やスマートフォンを使ったP2Pゲームなどをデモしてもらえる予定です。

吉田鎌ヶ迫
http://www.yoshidakamagasako.com/index.html

◇日時：
2008年１月18日（金）19:30～

◇場所
吉田鎌ヶ迫オフィス
http://www.yoshidakamagasako.com/company/map.html
＊直接オフィスに集合してください。

◇参加人数定員
８名

◇参加費
無料。ただし、ドリンクは各自持参してください。またおつまみの持参も大歓迎です！

◇参加条件
ＢｌｏｇかＭｉｘｉに感想を書いて頂ける方

◇参加フォーム
以下のＭｉｘｉのイベントトピから参加表明してください。
http://mixi.jp/view_event.pl?id=26762063

皆様のご参加、お待ちしております！

P2P教科書感想文キャンペーンについて

P2P教科書が12/26に発売されて以来、Blogにも色々な方の感想がアップされるようになりました。執筆者としてはうれしい限りです。本屋で大量に陳列されている様子を見ると、執筆していたときの苦労が吹き飛びます。

そこで、次のようなP2P教科書感想文キャンペーンを行いたいと思います。

[応募方法]
BlogにP2P教科書の感想を書いて、本エントリーへトラックバックをしてください。
ただしBlogの感想には必ず

・良かった点
・欠点あるいは要望（こんなことも書いて欲しい、この内容を更に充実して欲しい、誤字脱字の報告等）

の両方を含めてください。

[景品]
まだ詳細を決めていませんが、２，３人の方に
・私が主催する勉強会系イベントの無料招待券か懇親会の優待券（1回分）
・某P2P企業さんから頂く（予定）のTシャツ
等を贈呈したいと考えています。人数も応募総数見合いで増減します。

[応募期間]
2008年2月28日（金）まで

＊３月中に当選者の方には私から連絡致します。

皆様のご応募、心よりお待ちしています！

[P2P]DHTにおける部分一致検索の間接参照による解決法の提案

２００７年ももう少しで終わりですね。今年は娘の誕生、P2P教科書の出版、総務省支援のP2P実証実験への技術検討メンバ参加など、プライベート・仕事ともに節目の年でした。

来年もP2Pに関する講演等が決まりつつあるので後ほど紹介致します。

さて、２月末にとある団体が主催によるP2P研究会にて講演を行う予定です。その中でDynamoなどのP2Pデータベースの話も触れたいので、少しずつネタをBlogに書いておこうと思います。仕事でP2Pに関する業務が正式に認められましたが、アイデアベースで出せるものは今後もBlogで公開したいと思いますので皆様のコメントを是非お寄せ下さい。

□部分一致検索とDHTの親和性
DHTはご存知の通りハッシュ関数を使います。通常使うハッシュ関数は暗号的ハッシュ関数といわれるもので、これはハッシュ関数H()においてH[A]=Bというときに、BからAを推定できない性質があります。もう少し噛み砕いて言うと、Aにちょっとだけデータが変化したA'とすると、H[A']=B'という値が出力しますが、BとB'は全然違う値になります。

つまり、暗号的ハッシュ関数を使うと完全一致検索は容易ですが、部分一致検索は非常に難しいという事になります。

□部分一致検索への模索
ではどのようにすれば部分一致検索が可能なのでしょうか？
私のBlogでも何回か提案しました。スマートな方法の一つが形態素解析を使う事です。形態素解析を使う事で、文章から単語を抽出して単語ベースでの検索可能とします。

[DHT]DHTによるデータの部分列検索の考察
SkipGraphを利用した部分一致検索の提案

この方法の欠点は形態素解析用の辞書を持つ必要があることです。このため、新しいキーワードに対して検索するのは難しい事が予測されます。（ただし形態素解析自体の技術が向上しているので、この課題は解決できるかもしれません。）

他のアイデアとしては暗号化ハッシュ関数ではないハッシュ関数を使う事です。それは例えばハッシュ関数に線形性を持たせる事です。このようにすることで、あるキーワードKに対して、H(K)=Dとすれば、Dに近いハッシュ値に関連付けられた情報を引っ張る事でキーワードをある程度検索できるかもしれません。ただし、この方法ではキーワード数とハッシュ空間の大きさを慎重に吟味する必要があるでしょう。私は単純なハッシュ関数ではなく、Bloom Filterを使って解決を模索したことあります。先ほど紹介した[DHT]DHTによるデータの部分列検索の考察もBloom Filterを使っています。

どちらの方法にしてもオーバーレイマルチキャストを使う事で、効率的な検索ができることが期待されます。

さて、いずれ方法にしても複数のKeyに対するValueにはデータをそのものを格納していました。ということはかなりの数のノードにデータのレプリカをする必要があり、ノードのストレージに対して相当の負担がかかります。

□DHTにおける間接参照の導入

そこで、DHTにおける間接参照を導入します。
先ほど書いたように今まではKeyとして検索するキーワード、Valueとして検索対象のデータそのものが入っていました。そこで、新たな方法としてValueに格納するものを検索対象データへのポインタとします。

このとき、Get(Key=P2P）とすれば、Valueとして、P2Pという文字列を含むデータへのポインターのリスト（具体的にはデータのハッシュ値）帰ってきます。そこで、実際のデータにアクセスしたければ再度DHTを使ってデータを取得すれば良いのです。

この方法でもAND検索やOR検索も容易です。なぜなら
Get(Key=P2P　AND KEY=DHT)=GET(Key=P2P) AND GET(Key=DHT)
Get(Key=P2P  OR KEY=DHT)=GET(Key=P2P) OR GET(Key=DHT)
だからです。

ノードにはポインターの情報が色々とばら撒かれますが、そもそもデータそのものではないので、今までの方法よりもノードに対する（ストレージ的な）負荷は下がると予想されます。そのかわり、実際のデータにたどり着くまでの時間や信号数は増えます。

□通常の検索システムへの置き換えへ

ポインターを導入する事で、ノードへのストレージ負荷を大幅に下げる事に成功しました。となると検索としてわざわざ形態素解析を導入しなくても、通常の検索システムで使うNグラム法でOK！ということになります。これなら通常の検索システムのソースを使ってDHTに簡単に移植できるかもしれません。

全文検索-Wikipedia

□来年に向けて
今考えているのはDynamoのようなP2Pな分散データベースで、どのような適用範囲なら使えるか、あるいはどのような実装なら容易に実現できるかということを考えています。データベースはあまり詳しくないのですが、そのうち講演等でディスカッションさせて頂ければと思います。

今後の予定ですが、
・１月１８日：吉田鎌ケ迫へのオフィスツアー
・２月末：P2P研究会で講演（P2Pのアーキテクチャと最新動向について）
・３月上旬：信学会の研究会で招待講演（P2Pのアーキテクチャとユビキタスとの関連）
・３月中旬：信学会の全国大会で講演（NAT越え）

となっています。業務でP2Pの研究会開発が正式に認められたので今まで以上に活動できそうです。また私への講演や技術打ち合わせを御検討されている方はお気軽にメールかMixi経由でご連絡下さい。

P2P教科書は12/26(水）に発売です！

先日からお知らせしているインプレスR&DのP2P教科書がいよいよ12/26(水）に発売されます！東大　江崎先生が監修しています。３７６Pというボリューム満載の一冊です。

Amazonで既に予約を受け付けています。興味のある方は是非予約を！

詳細情報はインプレスダイレクトのページから見れます。
インプレスダイレクトのページ

目次は以下の通りです。
本書へのメッセージ
「ピア・ツー・ピアとBitTorrent」
ブラム・コーエン（Bram Cohen）、ビットトレント、チーフ・サイエンティスト（BitTorrent Inc., Chief Scientist、BitTorrent 開発者）

「ピア・ツー・ピアは幅広い応用の可能性をもつ」
金子　勇（Isamu Kaneko）、（株）ドリームボート、技術顧問（Winny制作者）

第1章　Q&Aで学ぶP2P（ピア・ツー・ピア）の基礎知識

第2章　P2Pの歴史と発展
＝ 合法的なビジネス活用に進展したP2P技術 ＝

第3章　著作権の現状とP2Pにおける著作権侵害の課題
＝ 諸外国の裁判内容からWinny事件まで ＝

第4章　P2Pのアーキテクチャの分類とその応用例

第5章　構造化オーバーレイとP2Pアーキテクチャの研究動向

第6章　CDNシステムとP2Pシステムはどこが違うのか？
＝ Webサーバの基本動作からCDN/P2Pまで ＝

第7章　Winnyをベースに商用化されたコンテンツ配信システム「SkeedCast」

第8章　P2Pに関するコミュニケーション・システム
＝ SIP/P2P SIP、IMSの仕組みからSkypeまで ＝

第9章　実例で学ぶP2P型マルチキャスト技術
＝ オーバーレイ・マルチキャスト方式の「BBブロードキャスト」 ＝

第10章　モバイル（携帯電話）におけるオールIP化とP2Pへの展開
＝ PHS/無線LAN/WiMAXなどもP2Pへ ＝

第11章　P2Pアプリケーションのインターネット・トラフィック特性への影響

第12章　P2Pによる新ビジネス・モデルと商用サービス

12-1　P2Pによる新ビジネス・モデルの展開事例
＝ デジタルミュージシャン・ネット（DMN）/Joost/FMO/orz（がっくし） ＝

12-2　P2Pによる商用ファイル配信サービス「BitTorrent DNA」

私が取りまとめ（一部執筆）を担当したのは３章で、うち２章はP2Pアーキテクチャの説明、残り１章はコミュニケーション関連（SIP、IMS、Skype）となっています。今回のP2P教科書を執筆する上で、初期メンバとして目次作りから関わる事ができ、大変貴重な経験ができたと思います。

とりまとめ＋執筆した章：

第4章　P2Pのアーキテクチャの分類とその応用例
第5章　構造化オーバーレイとP2Pアーキテクチャの研究動向
第8章　P2Pに関するコミュニケーション・システム

特に構造化オーバーレイの説明には力をいれ、おなじみのP2P勉強会講師陣メンバやUNIX　Magazine　P2P特集執筆者によるChord,Pasty,Kedemlia,Skipgraphの説明、Overlay WeaverやPlanet lab、複雑系との関連の記事など最新動向も踏まえた内容となっています。ページ数の関係上、深く入れなかった部分が多々ありますが執筆陣による渾身の章となっていますので是非ご期待下さい。

思えば用語の定義、章内の目次、執筆陣の決定、スケジュール管理等非常に難しい調整が続きましたが、ようやく形になる事ができてホッとしています。私のP2Pな人生にも一つの区切りができたと思います。

是非ご覧になったら感想をお寄せ下さい。次回の改訂版リリースや講演時の参考とさせていただきます。

最後になりましたが、監修の江崎先生、編集部の皆様、執筆陣の皆様、草稿を読んでコメントを頂いた方には大変お世話になりました。この貴重な体験を今後のキャリアアップに活かしたいと考えています。

アリエルネットワーク・オフィスツアー感想

先日の周知の通り、第３回目オフィスツアーとしてアリエルネットワークさんのオフィスを訪れました。参加者は８名でした。またアリエル側も６人参加して頂きました。

アリエルネットワークのオフィシャルBlogで取りあげられました。

アリエルネットワークオフィスツアー周知文
http://toremoro.tea-nifty.com/tomos_hotline/2007/10/11_a3f4.html

前半は自己紹介とフリーディスカッション、後半はSIPropの今村さんとアリエルの井上さんによるプレゼンという構成です。最後にオフィスの様子を見学しました。

以下概要＆感想です。

☆ロケーション
中目黒のとあるビルにあります。会議室からは東京タワーが見えてとても景観がよいです。ランチは近場で食べるそうですが、結構昼食代にかかって困っているようです。なおアリエルがきちんとしたオフィスを設立した以来、ロケーションは変わってないそうです。オフィスは現在中目黒一箇所です。

☆次期バージョン？
次期バージョンを開発中とのことです。残念ながら詳細は明らかにしていただけませんでしたが、大いに期待しましょう！

☆はてブとアリエルブログ
アリエルさんのブログ(ありえるえりあ）では、つい最近も井上さんが書いたRubyの記事が人気を集めていました。

プログラミング言語Ruby
http://dev.ariel-networks.com/articles/workshop/ruby/

はてブのブックマーク数が気になりますか？という質問ですが、井上さんはあまりはてブを意識してないようです。寧ろ昔書いたEmacsの記事が全然ブックマークされなかった事に違和感を感じていたようです。Emacs+LispよりRubyが技術者に人気なんて。。。ということらしいです。昔は秀丸をエディターとしている人を相当毛嫌いしていたようですが、最近は丸くなったとか。

☆SIProp今村さんのプレゼン
VoIPに関連したとても興味深いものでした。本当は雷電を絡めたVoIPとグループウェアの連携を期待していたのですが、残念ながら時間なくてプログラミングが間に合わなかったそうです。

☆アリエル井上さんによる「アリエルの歴史」
これは非常に興味深いです。アリエル社員も知らないアリエルネットワークの初期の歴史が明らかになりました。

・ロータス元社員による会社設立、ロータスが縁となって初期メンバが集まる。そしてベンチャーキャピタルもロータスが縁。
・ベンチャーキャピタルが縁で徳力さんも参加。
・最初は派遣＋契約社員、しかしきれいなコードを書けるように新人を採用して教育する事に。動ければいいや、というコードは完全にNG。
・面談の際には課題をCのコードで解くこと。所用時間は数秒以内。
・IT関連の時事用語も面談試験に。５年前の問題を見ましたが、相当IT動向をウォッチしないと厳しいものも。
・幹部の方は低レイヤーをバリバリプログラミングできる人が大好きなようです。そして、プログラミングが大好きできれいなコードを書ける人を大募集！とのことです。
・仕事をしないと海外に飛ばされるという噂も。

☆オフィス見学
・各デスクにフィギュアーや色々なおもちゃなどがありました。
・徳力さんの書棚だけ他の人と本が違う？

アリエルネットワーク様、ご協力ありがとうございました！

＊他の方の感想
http://www.noritsuna.com/archives/2007/11/post_95.html
http://d.hatena.ne.jp/hirokidaichi/20071119/1195455215

次回オフィスツアーは携帯用P2Pフレームワーク開発の株式会社吉田鎌ケ迫さんを予定しています。

第３回Ｐ２Ｐ勉強会は多分２００８年３月開催！

第２回勉強会からだいぶ経ってしましましたが、第３回Ｐ２Ｐ勉強会をやります。
諸事情のため、講師陣は決まっていたのですが開催時期の調整が遅れていました。申し訳ございません。

今年中に私やＰ２Ｐ勉強会講師陣らが執筆したインプレスＲ＆Ｄの「Ｐ２Ｐ教科書」が発刊されるので、なるべく今年度中に開催したいという意思が強くありました。
http://direct.ips.co.jp/book/impressrd.cfm
（ちょっとだけＰ２Ｐ教科書に関する記事が書いてあります。）
Ｐ２Ｐ教科書発刊記念になるような、すばらしい講師陣と講演内容を予定しています。

今回は主催者が変わるのでイベントのネーミングがＰ２Ｐ勉強会ではない可能性があります。ただし、雰囲気はなるべくＰ２Ｐ勉強会のノリを保ちたいと考えています。３月末までには開催したいということで調整はしています。
また最近Ｐ２Ｐ関連が業務として認められたので、私は会社の名前で出るかもしれません。私は講師、パネルディスカッションのモデレーター、プログラム編成委員のひとつ、あるいは複数の担当として出るかもしれません。

更に発刊記念として執筆陣らと意見交換できる「忘年会」か「新年会」も考えています。
最近業務もプライベートも忙しいので、企画倒れになるかもしれませんが。

今年度はＰ２Ｐに始まり、Ｐ２Ｐで終わる、業務もプライベートも充実した一年になりそうです。

オフィスツアー（アリエルネットワーク）は11月開催！

オフィスツアー第３弾はＰ２Ｐグループウェアで有名なアリエルネットワークです。

これまで同様Ｍｉｘｉで参加者を募集しています。ただし、参加ルールが少し変更になっていますのでご注意下さい。

◇アリエルネットワーク　オフィスツアー概要
☆日時：2007年11月16日（金）20時～
☆場所：アリエルネットワーク（中目黒）
http://www.ariel-networks.com/company/map.html
☆参加定員：１０名
☆参加費：無料
☆参加条件：
１．誰でもアクセスできるＢｌｏｇあるいはＷｅｂ上で感想を書くこと（Ｍｉｘｉのみは不可。）
２．飲み物は各自持ち込むこと。（ビールであれば500ml×２本相当）
３．軽食は用意されていますが、おつまみを少なくとも１個以上お持ち下さい。
（スナック菓子よりも、お惣菜系の方が望ましいです。）
☆参加フォーム
MixiのTomo's Hotlineコミュニティからお願いいたします。
http://mixi.jp/view_event.pl?id=24179056

[P2P]BitTorrent Conference 2007のご案内

来週月曜日（10/22[月])ですが、日本初のBitTorrentにテーマを絞った講演会、BitTorrent Conference 2007が開かれます。

BitTorrent Conference 2007概要
http://www.bittorrent.co.jp/agenda.html

日本法人が設立されたことにより日本でのビジネス展開が気になるところですがConferenceではコンテンツ提供側パートナーの角川グループおよび日本法人代表取締役の脇山氏の講演があり、今後の営業活動戦略を垣間見ることができると思います。

また特に注目したいのは、共同創業者のBram CohenとAshwin Navinが講演をすることです。BitTorrentはDNAクライアントを開発中であり、総務省支援のP2P実証実験でも使われます。もしかするとDNAクライアントの開発スケジュールや搭載予定機能等が発表されるかもしれません。オフィスツアー等を通して、搭載予定機能の一部は内々に聞いているのですが、果たしてこのＣｏｎｆｅｒｅｎｃｅでオフィシャルに発表されるのか、個人的には非常に興味を持っています。

BitTorrent P2P実証実験
http://bittorrent.netmovie-fes.jp/

夜には懇親会が開かれます。私は講演会および懇親会共に参加する予定ですので、もし私を見かけたらお気軽にお声掛け願います。ぜひ名刺交換とディスカッションをさせて下さい。

BitTorrentには動画配信に対する期待も高まっていますが、個人的には日本ではゲームやソフトウェアの配信の方が動画配信よりも先行して本格的になるのではないかと考えています。

事実、コナミはBitTorrentネットワーク（ただし商用のBitTorrentではない）を使ってソフトウェア(パッチ）の配信をしています。個人的には初音ミクの試用版を配布する際にBitTorrentを使って欲しい！と思っています。一時的にダウンロードが集中するソフトウェアには、やはりＰ２Ｐが向いていると思います。特にパッチはよい例でしょう。

参考：無印吉澤：BitTorrentオフィスツアーに行ってきました
http://muziyoshiz.jp/20071007.html

さて私事ですが業務のほうでもＰ２Ｐに一部携わることになりました。総務省支援のP2P実証実験において技術支援ということでメンバに参加しています。

再来週にはボストンで行われるFall ＶＯＮに参加する予定です。ここではP2PSIP等の情報を収集したいと考えています。P2Pに関する興味深い話題があればＢｌｏｇに書きたいと考えています。ＶＯＮに参加される方はぜひＭｉｘｉ経由でご連絡をお願い致します。

P2P上のSNSでマイミクをどう表現するか？

◇はじめに
MixiでSNS on P2Pコミュニティというものがある。これはP2PでSNSを実装するために各種の検討をするためのコミュニティである。（個人的にはSNS over P2Pと言ったほうがしっくりくるけども。）

かなり以前となるが、MixiのP2PコミュニティでP2PでSNSは構築できるのか？という話題があった。私がその際に考えたのはFOAFを使ってマイミク情報を記述することである。
今回SNS on P2Pコミュニティに加入することによって改めてFOAFを使うことの利点と課題を考えてみたので、SNSでP2Pを実現したいと考えている方は参考にして欲しい。

◇ＦＯＡＦとは？
ＦＯＡＦは簡単に言うと自分に関する各種プロフィールをＸＭＬで記述する方式である。この各種プロフィールには友達リストを書くことが出来る。すなわち、ユーザＡがＦＯＡＦで友達リストを書き、そのＦＯＡＦが信頼できるのであれば、ユーザＡのマイミクが誰なのか簡単にわかることになる。詳しくは
P2Pと認証、P2PでのSNS
をご覧下さい。

DHTを使った場合を少し書いておこう。ユーザＡのユーザＩＤをID_Aとすれば、Hash(ID_A)となるノードＩＤを管理するノードがユーザＡのＦＯＡＦを保有することになる。つまりＦＯＡＦを保有するノードにアクセスすれば、ユーザＡのプロフィールや友達リストを入手できる。なおＦＯＡＦは電子署名をつけることが可能なので、これを用いれば改ざんは防止できる。（ただし、わざとＦＯＡＦをロストさせる攻撃は可能である。この攻撃に対抗する手段として、レプリケーションを使うことが考えられる。）

◇マイミクのマイミクを探す
Mixiではあるユーザがマイミクのマイミクだと、その旨を表示することができる。これをFOAFを使って実現してみよう。

今ユーザＡのＦＯＡＦとユーザＢのＦＯＡＦがあるとする。ユーザＡのＦＯＡＦにある友達リストとユーザＢのＦＯＡＦにある友達リストを照らし合わせ、共通の友人がいればユーザＡとユーザＢはマイミクのマイミクであることがわかる。

◇提案方法の課題点
ＦＯＡＦを使うとマイミクの繋がりやマイミクのマイミクを簡単に判定することがわかった。しかし大きな問題点がある。それは友達関係の非対称性である。

ユーザＡはユーザＢをマイミクだと思っていても、実はユーザＢがユーザＡをマイミクだと思ってない場合も考えられる。すなわちユーザＡはＦＯＡＦの友達リストにユーザＢを掲載しているが、逆にユーザＢはユーザＡを友達リストに載せてない場合がある。

この友人の非対象関係を検証する簡単な方法はユーザＡとユーザＢのＦＯＡＦをつき合わし、ユーザＡが友達リストにユーザＢが書いてあり、且つユーザＢが友達リストにユーザＡが書いてあるときのみ、ユーザＡとユーザＢはマイミクだと認めるとすることである。この方法は簡単だが、ＤＨＴへのアクセス回数が増える懸念がある。すなわちユーザＡの友達リストに１００人いた場合、マイミクの検証をするにはＤＨＴに１００回以上アクセスする必要がある。友達リストの検証をどのタイミングで行うか、あるいは検証自体を実施しないのか、実装をする上で検討が必要であろう。最後にマイミクのマイミクを検証するときにはＤＨＴへのアクセス数が膨大になる可能性があることを指摘しておこう。

◇コミュニティの管理
ＦＯＡＦを使うとコミュニティの管理も楽である。コミュニティと「特別な人」（これをユーザＰとしよう）として考え、コミュニティの参加者はユーザＰの友達リストに掲載することになる。ユーザＰのＦＯＡＦはコミュニティの管理人が電子署名する。これによって、ある人が本当にコミュニティに参加しているかどうか判定することができるし、コミュニティ情報（たとえばトピックなど）に関する閲覧制御も「ある程度」可能である。
「ある程度」というのは、コミュニティ情報を管理するノード（レプリケーションをしているノードを含む）が能動的な攻撃をすればコミュニティ参加者以外も情報を閲覧できるという意味である。

BitTorrentオフィスツアー開催しました！

10/5(金）夜にBitTorrent日本オフィスと意見交換会を実施しました。
参加者は22名でした。（BitTorrentスタッフ5名を含む）

イベント参加者は以下のＭｉｘｉイベントトピで募りました。
http://mixi.jp/view_event.pl?id=22663347

◆オフィスの様子
御茶ノ水や秋葉原の近くにあるビルの一室にオフィスが構えてあります。フロア全体はとても綺麗で、特にビル共用のロビーはホテルのようです。
今回はオフィスの中で意見交換会を行いました。

◆BitTorrentカンファレンス
日本法人が設立され、ますます注目されるBitTorrentですが、今月いよいよBitTorrentに関する講演会が開かれます。

BitTorrent Conference 2007

まだアジェンダには書かれてないようですが、BitTorrent本社の方も講演予定です。
もちろん私も参加します！

◆社員数
現在のところスタッフは5名。（顧問含める）Skype日本オフィス立ち上げに関わったVince氏もスタッフです。

現在業務拡張により技術スタッフを大募集とのことです。少なくとも3名は欲しいと発言していました。

◆著作権とビジネス
特に参加者からの質問があったのが著作権との絡みです。デジタル配信ビジネスは現在の著作権制度がマッチしていないのではないか？コンテンツはうまく供給されるのか？、あるいは日本の動画配信ビジネスの現状をどう思うか？等です。
ここでは詳しく書けませんが、活発な意見交換がされました。

◆感想
日本法人代表の脇山氏やVince氏を含めBitTorrentスタッフの全員が参加者の質疑に丁寧に回答していたのが印象的でした。スタッフはカジュアル且つフランクリーだったので、参加者も気軽に意見交換できたようです。技術スタッフを増員することによって本格的な業務が早急に開始し、参加者を驚かせるようなビジネスが行われると確信しています。

◆P.S.
今後はアリエルネットワーク、吉田鎌ヶ迫のオフィスツアーを予定しています。お楽しみに。
いずれは、はてなやＭｉｘｉでもオフィスツアーを開催したいです。オフィスツアーにご興味のある企業、組織の方は是非ご連絡下さい。調整します。

また私事ですが業務においてもP2P関連に少しずつ手を染めつつあります。

[P2P]Bittorrent日本オフィスツアー参加者募集のご案内

お待たせしました、オフィスツアー第2弾はBittorrentです。（＊第１弾はSkypeでした。）
日本本格進出に伴う戦略やトラッカーレスなどの最新動向、スタッフとの意見交換など内容盛りだくさんです！もちろん、今回も懇親会を兼ねたパーティがあります。
オフィスが見学できる滅多にないチャンスですので、お見逃しなく！

＊Bittorrent日本オフィスツアー概要＊

□日時：10/5(金） 19:30～
□場所:Bittorrent日本オフィス
⇒集合場所については下記の参加申し込みトピック（Mixi)を参照してください。
□参加者数：15名
□参加条件：BlogかMixiにイベントの感想を書いて頂ける方

□参加費用：無料
ただしパーティー用に１人あたり

・シェアできるデリかおつまみ　２点以上
・ノンアルコールのペットボトル２リットル１本（紙コップも購入のこと）かビール（350ml）２本相当以上のアルコールを持参すること

参加申込みは
http://mixi.jp/view_event.pl?id=22663347
からお願い致します。
（日時等は急遽変更する場合があります。ご了承願います。）

＊P2PやWeb2.0関連の企業の方でオフィスツアーを実施してもいいよ！という方は是非ご連絡をお願い致します。詳細は後日調整させて下さい。

[P2P]DHTのグリッドへの応用を考える

□はじめに
プライベートな事ですが、昨日バイオリンの発表会で演奏をしました。弾いたのはハイドンの有名なストリングカルテット（弦楽四重奏）「ひばり」です。ストリングカルテットとはバイオリン×2人、ビオラ×1人、チェロ×1人の構成で演奏を行うのですが、それぞれのパートが有機的に絡み合うので、お互いの演奏を聴きながら弾かないと、きれいな演奏はできません。今回は初めての挑戦だったのか、7割ぐらいの出来でした。やっぱり本番だと緊張してうまく弾けないですね。またチャレンジしてみたいものです。

プログラムの分散処理もストリングカルテットに近いのかもしれません。プログラムを並列化、小さなタスクに分割し、それぞれのノードに渡し、さらに結果を統合します。ノード間の協調がうまく行かないと、処理が滞ってしまいます。

今回はDHTと使ってグリッド（ここでは分散処理と言う意味）への応用を考えてみます。なおグリッドについては、それほど知識がないので、的をはずした指摘をしている可能性があります。

□ノードＩＤとタスクの関係
実はかなり前にＤＨＴとグリッドの関係は私のBlogで指摘しています。

[P2P]DHTとグリッドは結びつくのか？

今回の話は上記の記事の抽象化及び簡潔化をしたものです。

DHTでは（あるいはKBRでは）ノードにノードＩＤと言われる一意のＩＤが振られています。通常、ノードＩＤを使ってデータの格納や入手を行う事になります。

ここで大切なのはノードＩＤが一意のＩＤであることです。

少し発想を飛ばしてみましょう。パソコンのメモリ空間を考えるとメモリ空間もアドレスと呼ばれる一意のＩＤのようなものがあります。メモリ空間の住所です。すると、メモリ空間とノードＩＤの間に類似性が生じます。つまり、ノードの状態がある程度理想的であれば、メモリ空間をノードＩＤに対応できるのではないかということです。つまり、ＤＨＴをうまく利用できれば複数のノードでプログラミング処理が可能となります。

このアイデアに更に応用を加えましょう。せっかく複数のノードがあるので、うまく並列化をすれば、各ノードに対して小さなタスクに分割して処理を与える事が可能です。プログラミングを並列化するのは、単一ノードの方が単純だと思いますが、もしかすると複数ノードでもできるのかもしれません。

さて、あるノードが落ちた場合はどうでしょうか？単純なＤＨＴを使うとそのノードが処理していたタスクは途中で終了してしまいます。そこで、ＤＨＴでよく使われるレプリカの応用をしましょう。

あるノードＩＤ＝Ｘが管理しているタスクTask_ＺをノードID=X+A(Ａはある整数）となるノードにも実行させます。するとノードＩＤ＝ＸがＤＨＴから抜けてもノードＩＤ＝Ｘ＋Ａは処理を終了できます。あるいはノードＩＤ＝ＸかノードＩＤ＝Ｘ＋Ａのどちらかで処理回答が早いノードの結果を採用するという手もあります。タスクのレプリケーションが増えれば、処理が高速化しますし、ノードの離脱に対する耐性にも強くなるでしょう。ただしそれだけシステムとして見た場合のリソース消費に繋がります。

分散コンピューティングで有名なものとしてSETIがあります。実はDHTをうまく使うと、分散コンピューティングアーキテクチャの構築が今までより容易に実現できる可能性があります。

P2Pでファイル共有、あるいは分散ストレージの開発・実装が現在でもホットな状況ですが、このような分散コンピューティングにも開発の視野を広げると意外と世間（特に政府や企業）から注目されるかもしれません。

書籍執筆に大活躍したプロジェクト管理ツール「ｔrac」

□はじめに

P2P技術入門書を書く上で大変だったのは10人弱もの執筆者の原稿を管理することでした。毎日、あるいは毎時改訂される原稿の差分をチェックしたり、あるいはレビューをすることは、とても大変なことです。

そこで今回活用したのが無料のプロジェクト管理ツール「trac」です。tracのおかげでドキュメント管理やレビューがスムーズに行われ、執筆プロジェクトがデスマーチにならずに済みました。

使ってる? Issue Tracking - trac 楽々ことはじめ

通常、この手のプロジェクト管理ツールはソフトウェア開発の進捗管理・ソースコード管理に使われる事が多いのですが、複数人のドキュメント執筆にも大いに活躍できる例として今回の執筆の状況を説明します。なお、tracの導入を推薦し、実際導入したのはP2P技術入門書執筆者の1人の亀井様であることを書いておきます。

□trac導入前
当初は執筆陣でMLを作り、MLに最新ドキュメントを配布するという手法を取っていました。しかしこの方法には3つの欠点があります。

[欠点１]ドキュメントの差分がわからない
[欠点２]どのドキュメントが最新版だかわからなくなる
[欠点３]ドキュメントを参照しづらい場合がある

欠点１はWordファイルのコメント機能を使えば補えるかもしれません。しかしtxtファイルではコメント機能は使えません。また大量のドキュメントがあると、差分をチェックするのも大変です。

欠点２はＭＬにコメント等が大量に送信されるとドキュメントが埋もれる場合を指します。またタイトル等によっては最新のドキュメントが検索に引っかからなかったりする場合もあります。

欠点３の要因は大きく分けて２つあります。ひとつはファイルサイズの大きなドキュメントはメールできないこと、もうひとつはメインのメーラーがないパソコン以外からの参照ができないことです。もちろん後者はＷｅｂメールを使えば解消できます。

□trac導入後
ではtrac導入後では３つの欠点はどのように解消されたのでしょうか？

[特徴１]ドキュメントの差分が簡単にわかる

tracを導入すると、ドキュメントの差分が発生する度にリビジョン番号が振られます。差分発生毎にリビジョン番号はインクリメントします。２つのリビジョン番号を入力すると、両者のリビジョンの差分が一覧表示されます。さらに過去のリビジョンのドキュメントも参照できます。うっかり変更しすぎたり、削除しても簡単に元に戻せます。

[特徴2]ドキュメントの最新版が一目で分かる

tracにログインすると、最新版のドキュメントリストが一覧で見ることが出来ます。またドキュメントのアップロードや更新に私はIEのプラグインで利用できるTortoiseCVSを利用しました。これならIEを使って最新版を簡単にチェックできます。

ただし、TortoiseCVSはWebDAVを使っているので、社内網からアクセスする場合にはＷｅｂプロキシの一部が通過できない場合があります。私の会社ではうまく利用できなかったので、専ら自宅で最新版をチェックする時に利用しました。

[特徴3]インターネットが通じればどこでもチェック可能

tracにはリポジトリブラウザ機能があり、ドキュメントをWeb上からチェックできます。このリポジトリブラウザ機能の優れているところにWordファイルもブラウザ上で表示してくれることにあります。Wordの表もきちんと表示します。（＊ただし表示が崩れる場合がありますが。）
残念ながらPowerPointや図入りのWordファイルはリポジトリブラウザから閲覧することができませんでした。なおTortoiseCVSなどを使えば、ファイルサイズが大きいドキュメントも楽々アップロードできます。

□利用後の感想
３つの特徴を説明しましたが、Web上にドキュメントを置く事で複数人によるレビューが同時並行でできたのが一番うれしかったです。やはり複数人の執筆者が居る時にはドキュメント管理は重要です。またwiki機能を使って目次や執筆者肩書き等も管理しました。

コメントについてはドキュメントに書き込む方法もありましたが、結局ＭＬに流す事としました。ＭＬに流す事で全員がコメントを読むことができ、且つコメントに対して執筆者全員でディスカッションできる、素早くレスできるのが理由の一つです。

Tracを使えば簡単にドキュメント管理ができます。複数人、特に4人を超えたドキュメント執筆プロジェクトがあれば、効果は絶大です。結局ドキュメント管理に重要なのはドキュメントとドキュメントのメタデータの集中管理なのです。

最後にtracに対する要望を挙げておくと、一番欲しい機能はブラウザ上からファイルの編集が可能である事です。ソースコードと違ってWordやPowerPointでドキュメントを作成していたということもあるのですが、企業用の多くのドキュメントがWordやPowerPointで作成させている現在、なんとか機能として盛り込んで頂きたいものです。

今回はtracの一部機能しか有効活用してなかったので、次回はもっとtracを使い倒したいと思います。

P2P技術解説書の執筆が終わりました!

先週、P2P技術解説書の執筆が終わりました。今年の夏もP2Pに関する執筆で終わった。。。（＊昨年はUNIX Magazine)でも大変貴重な経験も得たと思います。最近Blogの更新が遅くて申し訳ございませんでした。

とある人気技術入門書シリーズの一巻で、すくなくとも私が取りまとめている分は結構本格的な内容も含まれています。おそらく技術入門書（＊一般雑誌を含む）としては国内初掲載の内容も多数あると思います。

執筆及び取りまとめた章は2章で

・P2Pアーキテクチャとファイル共有
・P2Pコミュニケーションシステム

となっています。

前者は構造化オーバーレイの話（DHT[Chord,Pastry,Kademlia]、KBR、Skipgraphなど）やシミュレーター、実装の話も書いてあります。もちろんファイル共有の仕組みについても。

後者はP2PSIPやSkypeのことにも参照しています。なお執筆陣はP2P勉強会でおなじみのメンバーが含まれています。

紙面が限られていた（といっても2章で100ページ弱程度）ことと、入門者向けということで詳細まで書くことは難しいかったのですが、好評であればＰ２Ｐアーキテクチャに特化した、より専門的な技術解説書の執筆もチャレンジしたいと、執筆陣では意気込んでいます。

個人的には肩書きとして会社の名前が出せたのがうれしいです。最近ではP2P関連についても名目次第では業務として認められるようになりました。近いうちに再び信学会か情処で学会発表ができれば。

発刊は今秋～冬の予定です。詳しい情報が入り次第、またご連絡致します。

また第3回P2P勉強会の調整も既に開始しており、講師陣は大体決まっています。
開催時期は発刊時期に合わせられればと思っています。

Skypeオフィスツアーを開催しました！

以前から企画していたSkype日本オフィスへのカジュアルツアーを8/10(金）に開催しました。

イベント概要は以下の通りです。
□日時：2007年8月10日（金）19:30～22:00
□場所：Skype日本オフィス
□参加者：8名(+Skype社員3人）
□参加費：無料
□参加条件：blogかMixiに感想を書いて頂ける方
□参加者募集方法：Mixiイベントトピ　http://mixi.jp/view_event.pl?id=20461977

なお、今回はオフィスツアーの第１弾ということと、オフィスのキャパの関係上参加できる人数が限りがあることから本イベントの周知は私のMixi日記とMixiのTomo's Hotlineコミュニティだけと致しました。また岩田さんの粋な計らいでアリエルネットワークの方も参加して頂きました。

次回オフィスツアーを開催する際にはMixiの関連コミュニティ及びTomo's Hotlineで周知いたします。

印象に残った事を挙げておきましょう。（写真を載せてなくてすみません。他の参加者がバンバン載せてくれるはず。）

□その１、デザイナーズマンション？

Skypeの岩田さんとはP2P絡みでアリエルネットワーク時代からのお付き合いだったのですが、実際Skypeのオフィスに伺うのは今回が初めてでした。もともとSkypeとしてもユーザーとの交流会を計画していたのですが、その検討時期に今回の企画を私が持ち出したので、是非やりましょう！ということになったのです。

現在執筆しているP2P技術入門書のレビューのために私だけ早めにオフィスに入りました。

オフィスは六本木から少し離れたマンションの一室となっています。地図から場所がわかりにくいらしく、参加者の数人は３０分ぐらい場所を探していたようです。オフィスの中はまるでデザイナーズマンションのようで、快適なリビングやキッチン、シャワールーム、そして仕事場があります。

この日のためにコンクリート打ちっぱなしのリビングにSkypeのフラッグを貼り付けていただきました。（多分どなたか写真をアップしてくれるはず。）

Skypeオフィスツアーまもなく開催（Skype 岩田さんのBlog)
http://siwata.typepad.jp/blog/2007/08/skype_56d4.html

□その２、社員は３人

Skypeの日本オフィス社員はよく知られているように３人しかいません。男性２人、女性１人の構成です。仕事としてはローカライズや戦略的パートナーシップの締結、広報活動等多岐に渡ります。またヨーロッパ（※Skypeは本社がルクセンブルグ、開発拠点はエストニアのタリン）との会議が多いようで、昼から会議が始まり、深夜まで続くときもあるようです。
またSkype自体は日本法人が現状なく、現在は駐在所的な位置づけだそうです。

□その３、タリンの風景

開発拠点であるエストニアのタリンには社員の方がよく行かれるそうです。リビングのパーティにおいて、プロジェクターでタリンの風景やエピソードを説明して頂きました。毎年１月には全社員がタリンに集結するミーティングがあります。冬になるとマイナス４０度ぐらいになるところで、まだソ連時代の面影が街の風景として残っています。また最近ではチェコのプラハにも開発拠点ができるそうで、目下開発スタッフを募集しているとの事です。（※チェコ語ができるとベター！）全社員は世界中で６００人ぐらいだそうです。

□その４、Skype vs SIP
SIPropでおなじみの今村さんがSIPはSkypeよりも優れている！ということをアピールするため、このイベントのためにプレゼンして頂きました♪プレゼンはとても素晴らしく拍手喝采でした。ご興味のある方は是非彼のBlogを見てください。

音声などただの飾りです！偉い人にはそれがわからんですよ←結論
http://www.noritsuna.com/archives/2007/08/post_84.html

意味深なタイトルですが、まあ参加者しかわらかないアレです。

ちなみに今村さんが最近執筆された「俺流プロトコル実装入門」の抽選大会が実施されました。私も見事あたりました！SIPをベースとした俺流RFC(nRFC)を実際に実装するノウハウが書いてあり、RFCや要求定義に興味がある方は買いでしょう。

□その５、P2P Today 横田さん参戦

もちろん横田さんも本イベントに参戦して頂きました。無印吉澤さんがいないせいか、いつものようなテンションでなかったです。（本調子じゃなかったかな？）結婚生活秘話？も色々と聞かせて頂きました。

＝＝＝

パーティーではスマートフォンのことからWeb２．０やゲーム機との連携等色々な質問が飛び出し、ユーザのSkypeに対する期待の高さが伺えました。

本当は色々と書きたいことがこの１０倍ぐらいあるのですが、オフレコとのことなので、ここで書くのは止めておきましょう。（＊コレが聞けるのが参加者の特権です！）

Skypeとユーザとの懇親会は定期的に開きたいとのことなので、また少し経ってからカジュアルツアーを開催したいと思います。

次回のオフィスツアーはBittorrent日本オフィスの予定です。（今秋の金曜日夜を予定）
ご期待下さい！

[P2P]論文で発表か、それともBlogで発表か？

□はじめに

もともとP2Pに関わったのは所属していた研究所でP2Pをテーマに研究をしなさいと指示されたからである。当時はNapsterやGnutellaがリリースされ、P2Pが過剰なほど注目を集めていた。（業界ではP2P第一次ブームと呼んでいる。）

しばらくするとそのブームは終焉したのだが、その理由としてP2Pに対して研究者が冷静になったことと、P2Pに対する技術的限界がわかってきたことが挙げられる。（もっとも後者はDHTが知られるようになって、一部の壁は突破できるようになったのだが。）ブームが過ぎ去るとほぼ同時に私は別会社でネットワーク関連の設計や開発をするようになる。

研究所にいたころは、もちろん論文を書いて発表をしていたし、また関連特許をとっていた。しかし、それは業務としてである。別会社に異動すれば、論文や特許は業務ではないし、P2Pと業務との関連が薄くなる。とはいえ、個人的にはP2Pの魅力が忘れなれないことと、この魅力をほかの人に伝えたくてＷｅｂページやBlogでP2P技術の紹介や新たなP2P技術の提案を行ってきた。これは業務でなく、プライベートである。

現在は第二次P2Pブーム真っ盛りであるが、第一次P2Pブームから生き残った人はほとんどいなく、私のようなページが色々なところでリンクされたり紹介されたりするのは、なんだか不思議な感じがする。またP2Pのおかげで本の出版を予定したりと、逆に業務というよりP2Pで会社での知名度が上がり、色々な人に出会えたり、業務も良い方向に回っている。好きな技術は世間で何と言われようと徹底的に追い求めた方が良い、そんな教訓を学んだような気がする。

□発表する媒体は論文、Blogのどちらが良いか？

会社を異動してから論文を発表する機会はほとんど失われたといっても良い。というのは論文を出すには肩書きが必要なのだが、業務と関連がなければ会社の名前を使うことは難しい。となると結局肩書きなしで発表せざるを得ない。少なくとも肩書きなしで発表する人はかなりレアケースだ。

論文で発表するメリットは、その論文がある程度のレベルに達していることを第三者が認めていることだ。副次的な効果として他者から論文を引用しやすくなるし、自分の業績として堂々と掲載できる。またＷｅｂページと違って永続的に引用できることも挙げられるだろう。

ただしデメリットも忘れてはならない。まずはその労力である。一語一語吟味することや、必要があれば特許申請をしなければならない。次にその機会である。発表する機会は随時あるわけではない。全国大会なら年２回だし、海外発表なら、それに見合い且つ相当レベルの機会を見つけなければならない。そして忘れてはならないのは、発表する機会が失われることがあることだ。自分としては満足なのだが、審査員によって論文が却下されることがある。（もちろんこれは論文の一定レベルの確保と表裏一体のわけだが。）

一番大切なのは多くの人が論文を閲覧できるかということである。良い論文があっても多くの人に知られなければ価値は半減以下である。残念ながら日本の論文の多くはＧｏｏｇｌｅ等の検索で引っかからない。

ではBlogでの発表はどうだろう？まず好きなタイミングで好きなトピックを書くことができる。審査などはないので、自分の書いたことが即公表できる。またBlogに書いて発表するということで、自分の発表であることを明確化するとともに、公知の技術にすることができる。ただし、Blogに書いた技術がどの程度のレベルかというものは読者自身が判断することになる。（もっとも論文誌によっては結構いい加減なレベルなものもあるようだが。）

最大の利点は検索エンジンで上位に掲載されることである。あらゆる情報がWeb上に集まっている中、検索エンジンを活用することは重要である。

作成期間という視点も大切である。たとえば論文を発表するには、取り掛かってから発表するまで数ヶ月かかる。一方Blogはアイデアが沸けばその日のうちに公表できる。つまり、論文に投稿する人が３ヶ月前に暖めていたアイデアも、一方ではＢｌｏｇでその日のうちに発表され、結果的にBlogに書いた人が最初にそのアイデアを発表したということにもなる。このようなケースは増えていくだろう。

個人的にはBlogで一定レベルの記事を投稿すれば、そこそこ書かれている論文よりもBlogの記事の重要性のほうが高くなるのではないかと思っている。

□終わりに
今回このようなテーマを考えたのは、多くの人がレベルの高い論文を書いているのに、なぜ一旦P2Pの世界から「業務としては」離れた人間が書くBlogやWebページの方が注目を浴びているのだろう？とふと疑問に思ったからである。それは情報の入手が人づたいや論文というメディアから検索エンジンにシフトしているからではないかと考えている。

論文の存在意義はまだまだ大きいと思っている。ただし検索エンジン世界の今、すなわちすべての情報がWeb上にあふれている今、その意義は少しずつ薄れているのではないのだろうか？論文誌がさらにオープンになることにより、論文の魅力を高めることができ、投稿者と論文誌双方にメリットがあると考えている。

もし私が論文誌改革をするなら、すべての論文を公表し、Google等で引っ掛けられるようにすることと、自分の出した論文をpdf等で自分のサイトや会 社のサイトで公表できるようにすることだと思っている。ライトなユーザは論文検索エンジンなど使わず、Google検索を使うからである。

[P2P]Skype&BitTorrent日本オフィスツアーの開催について

先日、BitTorrentの日本オフィスの方と意見交換を行う機会がありました。現在日本オフィスでは2人の方が働いていて、近い将来日本でも本格的にコンテンツ配信事業やルータに関するライセンス認証事業を行いたいとのことです。

Joostのような海外動画配信動向についても話題に挙がり、近い将来それらの配信にはBitTorrentが使われるだろうとの意見を頂きました。BitTorrentはインフラである、その思想がとても強く伝わる意見交換会だったと考えています。

また日本における動画配信や著作権の動向についても議論を交えました。近い将来、BitTorrentを活用した新たなサービスが日本でも展開されることでしょう。私からはBitTorrentとビジネスができそうな日本の各種配信サービスの現状と戦略をお伝えしました。

意見交換会の場でBitTorrent日本オフィスに対するカジュアルな意見交換会を兼ねたオフィスツアーについて提案をしたところ、快諾して頂きました。現在の想定ではオフィスツアーを8月、9月の金曜日の夜開催する予定です。参加定員は20名程度です。BitTorrentさんとしては、コアなユーザと是非意見交換をしたいと共に、この機会にユーザを増やしたいとの事です。デザイナーマンションのような非常にきれいなオフィスなので一見の価値があります。

これに先立ち、Skypeの岩田さんと連絡してSkype日本オフィスツアーについて快諾して頂きました。Skypeについてビジネスから技術について質問したい方は是非参加表明をして下さいね。

詳しい参加方法や開催日時は本Ｂｌｏｇで公表します。BitTorrentツアーとSkypeツアーは別の日になる予定です。

また私の近況ですが、色々な方と共同でＰ２Ｐに関する技術入門書を執筆しています。Ｐ２Ｐアーキテクチャ、特にＤＨＴ絡みについても執筆しているのでご期待下さい。

[数学]グラフ（図形）の頂点を一意に番号付けする方法の提案

Ｐ２Ｐの関連で複雑系ネットワークについても色々と考えているのだが、あるとき図形やグラフの頂点を一意に番号付けできるか、もしできるのであればその方法はなんだろうか、と考えることがあった。この前の土曜日の夜ふと今の問題が頭に浮かび、２時間ぐらい眠れなくなった。今回はある制限下で図形またはグラフの頂点を番号付けする方法を提案したい。またこの番号付けは平行移動、回転する変換（すなわち図形の形を崩さない変換、アフィン変換の例）に対して不変としたい。

制限は以下の通り
・ユークリッド空間に図形は存在する
・同一座標には高々ひとつの頂点しか存在しない

ただし、後でわかるように距離空間で内積が定義できれば、今回の方式は成り立つ（あるいは拡張できる）事が予想される。

ここでは２次元を考えてみる。おそらく多次元でも拡張可能だろう。

番号付けの手順
１．各頂点の座標の平均（すわなち重心）を求める。これをＧと呼ぶ事にする。
２．各頂点の中でＧから一番近い（＊距離）点を求める。この点をＡとする。
３．ＧからみてＡを基点に時計回りの方向に存在する各頂点について順次番号付けをする。ただし、ＧからみてＡを基点に同じ角度に複数頂点が存在する場合、Ｇから近い点から番号付けをする。

この方法で問題になるのは、Ｇから一番近い点が複数存在する場合である。今その点をＢ、Ｃとしよう。次のような処理でどちらを最初に番号付けするか決める。

１．ＧからみてＢを基点に時計回りの方向に存在する各頂点を順次番号付けする。これをB1,B2....とする。
２．ＧからみてＣを基点に時計回りの方向に存在する各頂点を順次番号付けする。これをＣ1,Ｃ2....とする。
３．b1=（B－Ｇ）・(B1-G)、c1=(C-G)・（C1-G)を計算する。ただし・は内積を表す。b1<c1であれば、Bを最初に番号付けする。b1=c1ならb2,c2を計算し同様の処理をする。
４．頂点の数をＮとすると、b1=c1、b2=c2、.....b{n-1}=c{n-1}ならＧを中心Ｂ⇒Ｃに回転することにおける対称性（回転対称性）が存在することになる。ゆえに BとＣをどちらを最初に番号付けしても問題ない。

回転や平行移動に対して距離や内積は不変である事に注意。今回の方法は実は相似変換（拡大・縮小）しても番号付けは不変である。興味のある方は一般的なアフィン変換について考えて欲しい。

＊ただしここで言う不変のニュアンスについては注意が必要。というのは、重心から一番近い点が複数ある場合で回転対称性がある図形の一部では、番号付けの始点が複数パターンありうるからである。

問題はＮ次元に拡張した場合、角度をどう考えるか、あるいはＧから一番近い点が複数存在するときのロジックをどう拡張するかということが課題である。もしかすると外積やそのノルムなどを利用する事になるかもしれない。

なお一番やりたかったのは、リンクの情報しかない一般的なグラフの頂点の番号付けである。もはや頂点には座標の概念がない。おそらく隣接行列を用い、Jordanの標準形をうまく利用して番号付けをすることになるだろう。こちらももう少し考えてみたい。

[P2P]TwitterのP2P化を考えてみる

□はじめに
自分の状態や短いコメントを表示させるTwitterが非常に人気である。国内でも「もぐもぐ」等のサービスが出現し、SNSのように多くの人に広がるのも時間の問題のように思える。しかしながら急激な参加人数の増加のためにTwitterが度々メンテナンスをしているのも事実である。

今、Twitterのようなサービスを「プレゼンス系サービス」と呼ぶ事にしよう。本エントリーではプレゼンス系サービスの技術的課題を考えるとともに、P2P化した場合のモデルについて提案してみたい。

□プレゼンス系サービスの技術
Twitterをはじめてみると、おや？と思う事がある。自分がブラウザをリロードせずとも友人の新しいプレゼンス情報が随時表示されるからである。

この手のサービスを実現するには以下の２つの技術を使う事が考えられる。
-Javascript等を使って定期的にプレゼンス情報をサーバから取得する。
-Comet等を使ってサーバがプッシュ的にプレゼンス情報を送信する。

両者ともに、サイト側にトラフィックと処理が継続的に発生することがわかる。ゆえにある程度参加者数が存在し且つプレゼンス情報の更新が頻繁な場合、高価なランニングコストが必要と考えられる。

□プレゼンス系サービスのP2P化を考える
トラフィックと処理の分散が得意なのがP2Pであるので、P2P化すると先ほどの課題が解決されることが期待される。そこでプレゼンス系サービスのP2P化を考えてみよう。

ここではDHTを使ってプレゼンス系サービスをP2P化してみる。

準備：
ノードIDをNode_ID、ハッシュ関数をHash()とする。またプレゼンス系サービスのユーザIDをTwitter_IDとし、Twitter_IDの友人のＩＤをTwitter_Friend_IDとする。

システム構築方法：
Twitter_IDのプレゼンス情報及び端末のIPアドレスはNode_ID=Hash(Twitter_ID)に格納する。またTwitter_IDの友達リスト、すなわちTwitter_Friend_IDもNode_IDに格納する。

シーケンス
[1]Twitter_IDの端末はDHTネットワークを使って新しいプレゼンス情報をNode_ID=Hash(Twitter_ID)に格納する。
[2]Node_ID=Hash(Twitter_ID)は自ノードに格納しているTwitter_Friend_IDを用いてNode_ID=Hash(Twitter_Friend_ID）にTwitter_IDのプレゼンス情報が更新されたことを知らせる。
[3]Node_IDHash(Twitter_Friend_ID)は自ノードに格納しているTwitter_Friend_IDのIPアドレスを使って、Twitter_Friend_IDの端末にTwitter_IDのプレゼンス情報を通知する。

以外に簡単に実現できそうである。ただし実際にはＮＡＴ越え、認証、データの改ざん防止等の処理が必要である。

プレゼンス系サービスをＤＨＴで実現した場合の課題は情報取得の効率化である。lookupするノードや情報をgetするノードはほとんど変わらないので、特定ノードに対するIPアドレスを一定期間保有する等の仕組みが必要だろう。

□終わりに
プレゼンス系サービスにおけるP2P化の有効性とP2P化するためのモデルを考えてみた。個人的にはFireFoxのアドオン機能にこのP2P化したシステムが搭載すると、とてもスマートだと思っている。是非とも実装にチャレンジしてみて下さい。

[P2P]P2Pを応用した仮想世界の提案

□はじめに
仮想世界というと「セカンドライフ」を思い出す人が多いだろう。日本ではまだそれほどブレークしてはいないが、今後有名人が参加する事で多くの人がトライするきっかけになるかもしれない。「セカンドライフ」はクライアント＝サーバ型モデルであるが、Ｐ２Ｐ型にした場合、仮想世界がどのように発展するのか考えてみよう。

□負荷分散という利点もあるが。。
クライアント＝サーバ型からＰ２Ｐ型にした場合、一番のメリットは負荷分散であろう。大きなサーバや太い帯域の回線は必要ないので、結果的に事業者側のランニングコストは大きく下がる。しかしこれではＰ２Ｐのメリットを充分活かしてない。

□ユーザ数に応じて仮想世界が広がっていくというストーリーはどうだろう？
仮想世界に参加するときにユーザはＰ２Ｐソフトをインストールするとしよう。ユーザの参加者数が増えればＰ２Ｐソフトのインストール数が増え、それだけ仮想世界全体のシステム処理能力が向上するはずだ。この現象を使用してインストール数（あるいは処理能力）に応じて仮想空間が増加するというのはどうだろうか？例えば仮想世界で当初東京都だけあったものが、あるユーザ数が増えると神奈川県もエリアとして広がる、のようなものだ。すなわち、ユーザ数が増加すればするほど、仮想世界は広大になる。

仮想世界が興味深ければユーザ数は一定期間増加し、その結果ユーザは巨大な仮想世界を満喫することができる。そうすれば、口コミでユーザ数がまた増えるという好循環が生まれることが想定される。ユーザ数が増えれば全体の処理能力が増えるというＰ２Ｐならではの仮想世界のモデルだ。

□仮想統治という世界
ユーザ数が増えると仮想世界は広がるのだが、ユーザはＰＣの処理能力×処理時間に応じて、統治できる領土の広さあるいは仮想マネーが与えられるするのも面白いアイデアだろう。セカンドライフが仮想マネーを使うように、私が提案する仮想世界ではＰＣの処理能力×処理時間が領土の広さまたは仮想マネーの割り当てとなる。もちろん、仮想世界で独自のビジネスを立ち上げて仮想マネーを稼ぐ事も可能だ。処理時間というファクターを与える事により、多くのユーザが長時間Ｐ２Ｐネットワークに参加しやすくなる、。（インセンティブ効果）このことは仮想空間が（ネットワーク的に）安定して存在しやすくなることを意味し、事業者側にもメリットがある。

□ヘビーユーザならではの楽しみ「モジュール開発」
ヘビーユーザであれば、自分なりにカスタマイズをするのもよいだろう。ここではＰ２Ｐならではの楽しみ方法を提案してみよう。Ｐ２Ｐソフトウェアに自分の開発した（あるいは他人からもらった）追加モジュールをプラスする。すると、自分が得た領土では標準的な仮想世界以上のことができるようになる。例えばチャットやメールなどのコミュニケーションサービスである。開発者はこのモジュールを仮想マネーで他ユーザに販売も可能だ。事業者側は自ら開発しなくても新たなサービスが生まれる「エコシステム」によるメリットを享受する事が可能だ。

□事業者のビジネスモデル
事業者は広告モデル以外に分散処理をユーザに課することによって、ある一定の収益を得る事ができるかもしれない。いわゆるグリッドビジネスである。更にヘビーユーザが作った開発プロダクトに事業者の認証ライセンスを与えるというライセンスビジネスも可能だろう。

□終わりに
仮想世界でP2Pを使う事でクライアント＝サーバ型では難しかった楽しみが広がってくると考えている。この考え方はMMORPGのようなオンラインゲームにも応用できるはずだ。P2Pを単に負荷分散のためのシステムと捉えるのではなく、さらにもう一歩考える事によって今までにないユニークなサービスが生まれる事を期待している。

[P2P]日本で一番使われているP2PサービスはIP電話!?

□はじめに
P2Pというと、一番有名な利用形態としてWinnyのようなファイル共有サービスを思い浮かべる人が多いだろう。ある程度P2Pについて知っている人はSkypeのようなインターネット電話もサービス例として挙げることができる。しかしIP電話がP2Pを使っている事を知る人は、なぜか少数派である。

□IP電話のプロトコル
IP電話で使われているプロトコルは大きく分けて
[1]呼制御
[2]音声・動画データの送受信
の2つに分かれる。呼制御とはなじみのない言葉かもしれないが、電話を掛けたり、あるいは着信を知らせるためのプロトコルだとイメージをつかめばＯＫだ。呼制御には一般的にSIP、音声・動画データの送受信はRTPというプロトコルが使われる。なおどちらもUDPを使って通信する事が一般的である。なお、Skypeのプロトコル内容は一般に公開されていない。

□音声・動画データはP2P通信
呼制御は通信事業者（キャリア）が集中管理をするため、おなじみのクライアント＝サーバモデルを通常使う。呼制御をキャリアが集中管理するメリットとして、課金が可能、付加サービスの提供が容易などが挙げられる。しかし音声・動画データは基本的にP2P通信だ。これはなぜだろうか？

理由は大きく分類すると以下の通りである。
[1]遅延を避ける
音声品質は遅延によって劣化する。例えばテレビの衛星中継は遅延が大きいために、スムーズに会話ができないことがある。そのため、遅延を極力小さくするためにP2P通信を行う。

[2]パケットロスを少なくする
音声品質を劣化する要因として、データの欠落（パケットロス）が挙げられる。基本的にはネットワークの経路が小さいほどパケットロスは少なくなる傾向がある。P2P通信ならネットワークの経路長を抑えることができるので結果的にパケットロスも抑えられる。

[3]キャリアの設備投資コスト削減
仮に音声データをキャリアで一括管理した場合、全ての音声データがキャリアに集まる事になる。音声データ自体はそれほどの大きな帯域が必要ないのだが、仮に数10万通話が同時に成立したら、キャリアはとてつもないデータ量を処理しないといけない。もちろん、データを処理するサーバを収容する拠点は大きな帯域の回線を契約しないといけない。

つまり、音声データはP2Pを使う事で、品質劣化を抑える事ができ且つキャリア側の投資コストを大きく削減することができるのだ。このようにP2Pは生活の中で確実に使われているのだ。

□P2Pの大きな壁、ＮＡＴ越え
音声データはP2Pを使うのだが、P2Pの厄介な壁としてＮＡＴ越えが挙げられる。キャリアがＮＡＴ越えを克服するのに使われているのが、以下の2つである。
[1]ブロードバンドルータ自体に電話アダプター機能が装着している
[2]UPnP機能を利用する

[1]を使えば、そもそもＮＡＴ越えを考慮する必要がない。なぜならブロードバンドルータ自体が音声データを送受信するからである。[2]はＮＡＴ越えを克服するためによく使われる手段である。興味のある方はNAT越えについて拙著のWebページに書いてあるで参考にして欲しい。
P2PとＩＰアドレスの関係
P2Pとファイアウォール

□IP電話がP2Pを利用している事を知られてないワケは？
ではどうしてIP電話がP2Pを利用している事を多くの人が知らないのだろうか？VoIPを知っている人は音声データ通信がP2Pを使っている事は常識だ。
とりあえず推測を含めて理由を3つ書いてみた。

[1]IP電話はクライアント＝サーバモデルも利用しているから
音声データ通信はP2Pだが呼制御はクライアント＝サーバモデルを利用している。だからP2Pとして記事として紹介するには、抵抗がある執筆者が多かったのかもしれない。

[2]P2P＝悪のような書き方をしないと雑誌や新聞のウケが悪い
P2P＝悪のようなイメージが一般に定着してしまった今、P2P=良い事に使われる、と書くと雑誌や新聞の売り上げが上がらないし、あるいは読者のウケが悪いのかもしれない。それよりもP2Pに関するセキュリティの記事を書いた方が一般の人は興味を引くのかもしれない。

[3]P2Pに関する記事の執筆者の多くがIP電話がP2Pを使っていることをリサーチ不足で知らなかった
まさか！？しかしそのまさか、かもしれない。

□最後に
ＩＰ電話を提供しているほとんどのキャリアがP2P通信を利用していると考えられる。各キャリアのＩＰ電話ユーザ数を計算すればわかるが、ＩＰ電話ユーザ数はファイル共有をしているユーザ数を超えると考えている。さらにSkypeも含めると相当数のユーザが知らず知らずのうちにP2P通信を利用しているのだ。しかしこの事実を知らない人が多いのが残念でならない。
P2P⇒ファイル共有ではなく、P2P⇒ＩＰ電話のように、P2Pを好意的に（あるいは客観的に）捉える記事が増える事を願うばかりである。特に新聞記者や雑誌記者の方、お願いします！

□P.S. Twitterはじめました。
興味がある人は是非。ぽつぽつと更新しています。
http://twitter.com/toremoro21

[P2P]ノード数と最大ホップ数の関係～その１

DHTの研究をしていくと、平均ホップ数や最大ホップ数を気にするようになります。すると、平均ホップ数や最大ホップ数はどこまで改善できるようになるのか、一度は考えて見たかたもいると思います。実は私もその一人です。

そこで、今回はノード数と最大ホップ数の一般的な関係について考えてみましょう。

以下の問題について考えてみてください。答えは近日中に公表します。解答案を作った方は是非トラックバック等をしてくださいね。

□問題
Pure P2Pに参加しているノード群を考えてみる。各ノードは一定の数のリンクを持っている。１ノードあたりのリンク数をＰとする。またノードの総数はＮとする。ノードがホップできる先はリンクしているノードに限られるとする。このとき、最大ホップ数はＮ，Ｐをつかってどのような関係にあるのか示してください。なお、任意の2ノード間はリンクにより辿り着くことができることとする。

Ｐ２Ｐは複雑ネットワークやグラフ理論と深い結びつきがありますが、今回の問題はグラフ理論の応用です。グラフ理論でいうと、リンク数は「次数」、最大ホップ数は「直径」に相当します。任意の2ノード間がリンクを使って辿れる事は連結グラフに相当します。
実を言うと、考えやすいように今回の問題は次数が一定＝Ｐの場合を書いていますが、次数が一定でなくてもノードにおける最大次数がＰの場合も答えは同じになります。もちろん、Structured P2PでもUnstructured P2Pでも当てはまる関係式となります。

是非チャレンジしてみてくださいね。

[P2P]P2Pによるbotnetの可能性について

□botnetとは？
最近ウィルスと並んでbotnetが話題になっている。botnetとは簡単に言うと、ある攻撃者からの命令を受け付ける事が可能で、更にそれを実行することができる不正なプログラム（bot）によって形成されたネットワークである。
botnetについては以下のリンクを参考にして下さい。
http://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%83%E3%83%88%E3%83%8D%E3%83%83%E3%83%88
http://www.atmarkit.co.jp/fsecurity/special/76bot/bot01.html

botnetを使うと攻撃者によってスパムメールを送出したり、あるいはDDoS攻撃を起こす事もできます。

□botnetの仕組み
botは攻撃者からの命令を受ける際にＩＲＣサーバを利用すします。ＩＲＣサーバとはチャットの際に利用するサーバです。ＩＲＣサーバ経由で命令を受けたbotはその命令どおりに実行を行います。スパムメールやDDoS攻撃以外に情報漏えいを引き起こす事もあります。

□P2Pとbotnet
先ほど書いたようにbotnetは一般的にはクライアント＝サーバモデルと考えられます。ここでbotnetがP2Pを利用すると攻撃者側にとって色々と都合がよいことがあります。以下に簡単にまとめてみます。

[メリット1]攻撃者用サーバが不要
[メリット2]攻撃者の匿名性が高まる
[メリット3]botを多数収容できるbotnetが構築できる
[メリット4]botnetを通信面で組織が遮断することが難しい

メリット１ですが、P2PですからＩＲＣサーバが不要です。ですから、ＩＲＣサーバを設置あるいはクラックする必要がありません。ただし、botがP2P-botnetに新規に参加する場合には、既にP2P-botnetに参加しているbotのＩＰアドレスを知る必要があります。これを解決するにはbotのプログラム自体に初期接続用ノードＩＰアドレスを配布するなど、工夫が必要です。もちろん、この他ノードにbotを感染させる際にはＩＰアドレスリストの最新版を渡す等更なる工夫も可能です。

メリット２ですが、Ｗｉｎｎｙのようにbotに感染したノードをプロキシ的に扱う事で攻撃者の匿名性を非常に高める事が可能です。高度に発展したP2P-botnetでは攻撃者を特定する事は極めて難しいでしょう。

メリット３ですが、サーバレスということで、スケーラビリティに優れたbotnetを構築することができます。DHTやSkipgraphを使えば単にスケーラビリティに優れたbotnetでなく、botに割り当てられたNode_ID毎に命令を割り振るなど高度な攻撃も可能でしょう。

メリット４ですが、WinnyやShareを通信的に遮断することが難しい事と同じようにP2P-botnetを遮断することが難しいと考えられます。つまり、P2P-botnetを完全になくすには困難を伴います。

botの作者がP2Pに目をつけるのも時間の問題でしょう。

[P2P]第3回P2P勉強会の講演内容調整について

VoIP Conferenceが終わりましたので、そろそろ第3回P2P勉強会の調整をしたいと考えています。
まずは会場と講師の方の募集です。皆様協力をお願いします。

□会場
100人以上入る会場が望ましいです。費用については相談させてください。
⇒会場を廉価で提供して頂ける方募集中です。

□開催期間
来年度後半

□講演形式
講師による講演+パネルディスカッション。会場によってはパネル発表やブース発表もあるかも。

□講演内容
今のところ以下のうちの何点かをピックアップしようかと思います。まだ私案ですので、追加して欲しいものがあればコメントを下さい。

・Ｐ２Ｐの基礎～DHT・ＳｋｉｐＧｒａｐｈの基礎（これは講演実施を予定）
・Ｐ２Ｐマルチキャスト
・Ｐ２Ｐ掲示板～新月・Ringoch等
・o2on～2ch-P2P化プロジェクト
・分散ストレージ
・分散データーベース
・Ｐ２Ｐ地震情報
・ＮＡＴ越え
・Ｓｋｙｐｅの最新動向・Ｐ２Ｐ－ＳＩＰ
・著作権関連の最新トピック
・Ｐ２Ｐ関連の政策動向
・Ｐ２Ｐとセキュリティ
・アドホックネットワークの最新動向
・Ｐ２Ｐ最新動向

講師については自薦・他薦を問いません。質問等ございましたらtnishita@yahoo.co.jpまで。

[P2P]WikipediaのP2P適用について

新年明けましておめでとうございます。1月にはVoIP Conferenceを開くなど今年も各種イベントを開催予定ですので今年も是非ご期待下さい。

さて本年最初のエントリーはP2Pについてです。

□WikipediaとP2P
Wikipediaはご存知の方も多いと思うが、世界の有志によって作成されている大規模なインターネット上の百科事典である。最近ではWikipediaの知名度も上がりアクセスも急増している。それに伴いサーバや回線の増強が必要とされている。もちろん増強に対しては資金が必要でWikipediaでは寄付のページを開設している。

サーバ＝クライアント方式では負荷が集中した際にはサーバ等の増強が必要である。そこでP2Pの出番である。ユーザあるいはボランティアがWikipedia用のP2Pソフトをインストールし、負荷を分散させてしまおうということが今回の目的である。アクセス数が多くてもユーザ数あるいはボランティア数が多くなれば低コストで充分に対処できる。

なお今後P2P上のWikipediaをP2Pediaと呼ぶことにする。P2PediaはDHT(分散ハッシュテーブル）を使えれば構築できるだろう。もちろん分散ストレージの技術も必須となる。

□案１：P2Pネットワーク参加者のみP2Pediaを提供

一つの案は、ユーザが必ずP2Pネットワークに参加する事である。ユーザ数が増えればそれに応じてP2Pソフトインストール数が増えアクセス増加に充分耐えうるはずだ。しかしこれには欠点がある。一般ユーザがP2Pediaを利用する上で専用P2Pソフトをインストールするには大きな抵抗あるからだ。

□案2:ボランティアがP2Pネットワーク参加し、一般ユーザはブラウザでP2Pediaにアクセスする

そこで一般ユーザは引き続きブラウザでP2Pediaにアクセスすることが考えられる。P2Pediaを支援したいボランティアの人は専用P2Pソフトをインストールする。専用P2Pソフトアクティブ数を増強する目的として、P2Pedia項目の追記・修正・削除をできるには専用P2Pソフトをインストールする必要があると条件をつけると良いだろう。

案2の実行案として、専用P2Pソフトは一般ユーザにP2Pediaを表示させるためにWebサーバをいれることを想定している。実行案についてもう少し詳しく考えてみよう。今、「P2P」というP2Pedia項目が表示されているとする。ここで「P2P」項目のページには「DHT」や「Winny」などの項目のリンクが張られているとする。

□解決したい課題：専用P2Pソフトはどのようにリンク処理を実行するばよいだろうか？

案A:項目のWebページソースを読み、リンク部分のハッシュ値を計算する。その後該当ハッシュ値を格納しているIPアドレスを検索し、該当リンク部分のWebページを書き換える

項目を一般ユーザに表示する前にWebページソースを解析する。このときリンク部分が「Winny」と書かれていたとしよう。するとハッシュ関数Hash（）においてHash(Winny)を計算する。ハッシュ値を使って「Winny」の項目を格納しているノードのIPアドレス等を専用P2Pソフトを用いてDHTネットワーク（P2Pネットワークの一種）に質問する。帰ってきたIPアドレス（10.1.1.1としよう）を使ってリンク情報を修正する。

例えば、＜a　href="localhost"＞Winny＜/a＞というソースを＜a　href="10.1.1.1"＞Winny＜/a＞と書き換える。

案Aの場合、一般ユーザにWebページを表示させる前に、リンク先のページを格納しているノードをP2Pネットワークで検索する必要がある。そのため、Webページを表示する際に時間がかかる場合がある。

案B:リダイレクトを利用する

HTTPの機能としてリダイレクトがある。リダイレクトとは、簡単に言うブラウザとサーバが連携することにより、リンク先とは本来違うサイトにリンクが飛ぶ機能である。
HTTPリダイレクト

リダイレクトを利用する事で、リンク先のページを格納しているノードをP2Pネットワークで確認しないままWebページを一般ユーザに表示することができる。ただし一般ユーザがリンク先がアクセスした場合は該当サーバ、つまり専用P2PソフトはDHTネットワークでリンク先Webページが格納しているノードを検索し、その後リダイレクト処理を行う。

案Aと案Bを比較すると、Web表示時間が高速な案Bの方が望ましいだろう。

今回はP2Pネットワークを利用してWebサーバの負荷分散を行うことを検討した。
このような技術を使えばP2Pをうまく使いながらWebサーバ以外のサーバの負荷分散を行う事が可能になるだろう。

[P2P]P2P・DHT勉強会 IN 関西プレゼン資料

12/3(日）に新大阪で開かれた「P2P・DHT勉強会　IN 関西」のプレゼン資料を公開しました。
なお、当日の会場の雰囲気ですが30人超もの人が集まり、活発なディスカッションがされました。

当日の講師・講演概要
http://toremoro.tea-nifty.com/tomos_hotline/2006/11/p2pp2pdht_in__eec0.html

資料公開ページ
http://homepage3.nifty.com/toremoro/study/study.html

なお、これに合わせて第2回DHT勉強会の加藤氏の資料もアップしました。これで第2回ＤＨＴ勉強会プレゼン資料は全てアップしました。

＊＊＊
P2P・DHT勉強会感想集：

Blog
http://www.ais.cmc.osaka-u.ac.jp/~y-konishi/study_diary/diary.cgi?date=20061203

Mixi
エボ蔵さん
たでぃーさん
つきすぶさん
こにさん
山葵さん
boogalooさん
yasuさん

*参加者以外の方からの反応
無印吉澤

次回イベントはVoIP Conference(1/21(日）、金沢工業大学虎ノ門キャンパス）です。Skype Conferenceの後継イベントです。近日中に講師の方をＢｌｏｇ等で紹介致します。

[P2P]P2Pを議論するML「Overlay Network」

P2P,DHTのMixiコミュニティはありますが、もっと積極的にP2Pについて議論を展開するために、最近首藤さんがMLを作成しました。

Overlay Network
http://groups-beta.google.com/group/overlay-network-ja

既にDHTやSkypeなどについて熱いディスカッションが繰り広げられています！
是非ホットな議論に参加してくださいね！

[P2P]P2P・DHT勉強会 in 関西（講師・時間ＦＩＸ版）

12/3(日）新大阪開催のP2P・DHT勉強会 in 関西の講師・講演時間がＦＩＸしました。
お昼時の開催ですので、お弁当などをお持ちになった方がベターだと思います。

□日時：2006年12/3(日）11：30～15：00（開始時間が変更しています！）
□場所：新大阪丸ビル本館（１Ｆに会場の案内表示がでます）　
http://www.japan-life.co.jp/jp/conference/map.html

□講演スケジュール
11：00準備
11：15開場
11：30～開会の挨拶（西谷）

11：35～
☆講師：
小西佑治氏 大阪大学工学部電子情報エネルギー工学科
吉田 幹氏 (株) BBR
☆講演タイトル：
Skip Graph の仕組みと関連研究
☆講演概要：
範囲検索のサポートなど、オーバレイネットワークとして、DHTとは異なる側面を持つ Skip Graph についての解説と、Skip Graph をベースとした他の関連研究の紹介をします。併せて、実装例として、PIAX における地理検索機能 LL-Netが、Skip Graphによりどのように実現されているかも紹介します。

12:35～
☆講師
藤田 昭人氏　大阪市立大学大学院創造都市研究科
☆講演タイトル：
Work in Progress ～　P2P DB開発への道
☆講演概要：
第2回ＤＨＴ勉強会での発表の続編です。
構造化オーバーレイを活用した分散データベースの開発を目指したものの、Pond(Ocean Store Prototype) に始まり、MIT Chord 実装、i3 実装と挫折を繰り返していたわけですが、Overlay Weaver という実装のベースを手にして実装作業が実質的に進展し始めました。今回は Overlay Weaver と Bamboo の２つのお勧めの構造化オーバーレイ実装について概要を説明します。

13：15～
☆講師　上田達也　氏
大阪市立大学大学院創造都市研究科、（有）うえだうえおうぇあ
☆講演タイトル
「分散ネットワーク座標系Vivaldi」の仕組み
☆講演概要
ネットワーク通信に於いて，ノード間のネットワーク的距離を知ることができれば，より近い経路選択が可能になるなど，効率的な通信を行う事が可能となる。しかしノード間の距離を実測することは，それ自身がネットワークトラフィックを発生し，通信のオーバヘッドとなる。

ネットワークトポロジーを仮想的な座標系（仮想ネットワーク座標系）で表現することができれば，実測すること無しに，ノード間のネットワーク距離を座標系におけるユークリッド距離から推測することが可能である。

本講演では，仮想ネットワーク座標系を完全に分散的な手法（P2P的手法）で構築するアルゴリズムである，Vivaldiについて解説を行う。

14：10～　
☆講師　西谷　智広（Tomo's Hotline)
☆講演タイトル
P2Pにおける文字列検索と認証について
☆講演概要
P2Pで文字列検索は重要な研究要素として位置づけられている。また認証技術としてPKIやPGPの応用が研究されているが、より簡易な認証方法についても模索がされている。本講演ではSkipgraphを用いた文字列検索方式とPKIやPGPに頼らない認証方式について提案を行う。

14：40～　後片付け

*ボランティアの募集をします。希望者は当日11時に会場にお集まり下さい。受付等簡単な軽作業です。

もうすぐ定員に達しますので、申込み（Ｍｉｘｉ経由）はお早めに。。。
☆申込みページ☆
http://mixi.jp/view_event.pl?id=11883753

[P2P]Skypeに死角はないのか？

□はじめに
無料VoIPツールの代表例であるSkypeが一般PCユーザにも認知されつつある。Mixiの日記検索で「Skype」と検索すると山ほどエントリーがヒットする。SkypeINやSkypeOutが出た今、050電話番号でPSTN接続ができる状態まできている。ではそんな「絶好調」なSkypeに死角はないのだろうか？

□SkypeがP2Pで得たメリット
Skypeは各ユーザがあたかもVoIPのサーバのように振舞う、すなわちP2Pモデルを採用している。P2Pを使う事によって、Skype社は大規模なサーバを立てることなく、安定的にVoIPサービスを運用できる。なぜならユーザ数が増えれば、その一定比率のクライアントがVoIPサーバに「自律的」になるからである。このようなVoIP関連サーバをSkypeでは用途に応じてスーパーノードやリレーノードと呼ぶ。

□P2Pならではの「デメリット」
ここまではメディア等でSkypeが絶賛される理由である。しかし本当にSkypeは死角がないのだろうか？
私は大きく分けて死角が２つあると思う。それは

[デメリット１]クライアントがクラッキングされる可能性がある
[デメリット2]NAT越えがしにくい環境になりつつある

ということである。

□P2Pとセキュリティ
デメリット１のSkypeのセキュリティについて考えてみよう。Skypeは電子証明書を用いて通信内容を暗号化している。しかしクライアントをクラッキングすることによって、悪意のあるスーパーノードやリレーノードを生成する事が可能となれば、プレゼンス情報やチャット情報が改ざんされたり、場合によっては盗聴できる可能性もある。また意図してないユーザと通信する可能性もある。P2Pにとってセキュリティ対策は現在でもとても難しい問題なのだ。

Skypeのプロトコルがオープンでない現状では、Skypeがどの程度のセキュリティ対策が行われているかは不明である。

□P2PとNAT越え
しかし、日本に限ってみるとデメリット２の方を考慮する必要があると私は考えている。

一般にスーパーノードやリレーノードはその性質上グローバルIPアドレスを取得する必要がある。ところで現在FTTHサービスが非常に盛んで、更にひかり電話の場合ルーターをユーザに配布している現状がある。ちなみにFTTHサービス加入者の大半がひかり電話加入者だという。

となると、必然的にグローバルIPアドレスを保有できる環境が激減する事が考えられる。つまりスーパーノードやリレーノードになれる可能性のあるノード数が減ってきているのである。また高性能なPCを保有したり長時間接続するユーザはルーターを用いて接続するようになってきている。となるとスーパーノードやリレーノードになる候補ノード数は更に少なくなる。

ただでさえスーパーノードやリレーノードの候補ノード数が少なくなるのに、Skypeの高機能化に併せてスーパーノードやリレーノードの負荷は高まることが予想される。その環境に加えSkypeのユーザ数が増加しているのが現状である。

□終わりに
Skypeはユーザ数の激増と日本のブロードバンド環境の変化に果たして耐えられるのだろうか？私としては、もちろんSkypeが次の一手を考える事に期待している。そしてその技術はきっと研究者を驚嘆させてくれる事だろう。

[P2P]P2P・DHT勉強会 in 関西

12/3（日）にP2P・DHT勉強会が新大阪で開催されます。
関西でのP2P、DHT勉強会は初めてですので是非とも参加して下さい。

□日時：2006年12/3(日）12：00～15：00
□場所：新大阪丸ビル本館（１Ｆに会場の案内表示がでます）　
http://www.japan-life.co.jp/jp/conference/map.html

□講演スケジュール
12：00開場
12：15～開会の挨拶
12：20～
☆講師：
小西佑治氏 大阪大学工学部電子情報エネルギー工学科
吉田 幹氏 (株) BBR
☆講演タイトル：
Skip Graph の仕組みと関連研究
☆講演概要：
範囲検索のサポートなど、オーバレイネットワークとして、DHTとは異なる側面を持つ Skip Graph についての解説と、Skip Graph をベースとした他の関連研究の紹介をします。併せて、実装例として、PIAX における地理検索機能 LL-Netが、Skip Graphによりどのように実現されているかも紹介します。

13：20～
☆講師　上田達也　氏（11/24追記）
大阪市立大学大学院創造都市研究科、（有）うえだうえおうぇあ
☆講演タイトル
「分散ネットワーク座標系Vivaldi」の仕組み
☆講演概要
ネットワーク通信に於いて，ノード間のネットワーク的距離を知ることができれば，より近い経路選択が可能になるなど，効率的な通信を行う事が可能となる。しかしノード間の距離を実測することは，それ自身がネットワークトラフィックを発生し，通信のオーバヘッドとなる。

ネットワークトポロジーを仮想的な座標系（仮想ネットワーク座標系）で表現することができれば，実測すること無しに，ノード間のネットワーク距離を座標系におけるユークリッド距離から推測することが可能である。

本講演では，仮想ネットワーク座標系を完全に分散的な手法（P2P的手法）で構築するアルゴリズムである，Vivaldiについて解説を行う。

14：10～　
☆講師　西谷　智広（Tomo's Hotline)
☆講演タイトル
Ｐ２Ｐにおける文字列検索と認証について
☆講演概要
P2Pで文字列検索は重要な研究要素として位置づけられている。また認証技術としてＰＫＩやＰＧＰの応用が研究されているが、より簡易な認証方法についても模索がされている。本講演ではSkipgraphを用いた文字列検索方式とＰＫＩやＰＧＰに頼らない認証方式について提案を行う。

14：40～　後片付け

＊現在更に講師を調整中で、時間が拡大する可能性があります。

申込みは以下のページからお願いします。（Ｍｉｘｉ）
http://mixi.jp/view_event.pl?id=11883753

[P2P][DHT]サーバレスなP2P認証方法の提案

□はじめに

先日はゼロ知識証明を応用した認証方法を提案した。

このエントリーには色々とコメントを頂きその後改良を加えた。しかし以下の2つが欠点でとして残っている。

[欠点1]中間侵入攻撃を許す。
[欠点2]ノードIDをそのノードが保有していることを完全には証明できない。

そこで上記2点を改良した方法を提案する。今回の基本的アイデアはある条件化で自己証明書を作る事である。

□ノードが事前に実施すべきアルゴリズム

これから各ノードが事前に実施すべきアルゴリズム案を書いておく。

[手順1]ノード1は大きな素数a1,b1を選び、c1=a1×b1を計算する。nodeID1=hash(c)とする。ただしhash()はハッシュ関数。nodeID1はノードIDに相当する。
[手順2]ノード1はc1を利用してRSA暗号アルゴリズムから公開鍵e1と秘密鍵d1のペアを生成する。
[手順3]ノード１はpublicinfo1=(nodeID1,c1,e1,sgn1)を公開する。この際、sgn1はhash(node1,e1)をd1で暗号化したもの、つまり自己証明書相当のものを意味する。

□ノードの認証

次にノード2がノード1を認証するアルゴリズムを書く。ノード2はpublicinfo2(nodeID2,c2,e2,sgn2)を公開している。

[手順1]ノード2はDHTを使ってノード1のpublicinfo1を入手する。
[手順2]ノード2はnodeID1,c1よりc1を検証し且つnodeID1,c1,e1,sgn1を使ってpublicinfo1を検証する。
[手順3]ノード１はc1,d1を使い、ノード2はc1,e1を使ってRSA暗号通信を開始する。
[手順4]上位RSA暗号通信はプロトコルが決まっており、随時「暗号通信路内」でノード２からノード１へのチャレンジレスポンス、ノード１からノード２へのチャレンジレスポンスを実施する。なおノード１がノード２にチャレンジレスポンスをする際には(c2,e2)を利用する。これでノード１とノード２が相互認証されたことになる。

□制約条件
今回のアルゴリズムが有効なのは各ｃの素因数分解が複数ユーザが知らない事が前提である。
ユーザ3がｃを作成したときに、たまたまユーザ１が既にｃを保有した場合には、ユーザ３はユーザ１の成りすましが可能である。

P2P・DHTオフ会 in 関西(12/3[日]開催)

12/3（日）にP2P・DHTオフ会を開催で初めて関西（大阪予定）で開催します。
会場・定員等は未定です。（日中帯を予定）
皆様是非。ミニプレゼン講師も募集中！

http://mixi.jp/view_event.pl?id=11883753

詳細が決まり次第後日紹介します。

[P2P][DHT]ゼロ知識証明によるP2P認証方法の提案

□はじめに
セキュリティの興味深いトピックとしてゼロ知識証明というテクニックがある。
ゼロ知識証明
http://www.venture.nict.go.jp/series/cryptography/chapter2/2_4.html

ゼロ知識証明は簡単に言うとつぎのようなものである。
[1]ユーザＡは大きな素数A,BよりC=Ａ×Ｂを作成する。
[2]ユーザＢはユーザＡとある通信をすることで、ユーザＡがＣの素因数分解ができるか否かを検証することができる。（それもユーザＡがユーザＢにＡ，Ｂの情報を提示せず！）

筆者はゼロ知識証明について昔から興味を頂き、この技術の応用を模索していた。今回はゼロ知識証明を使う事でP2P(具体的にはＤＨＴ）認証方法として応用する事を提案する。

以下については11/4に大幅修正を加えています。

□認証プトロコル
プロトコルは次のとおり

☆ノードＩＤ作成プロトコル
[1]各ユーザは大きな素数Ａ，ＢよりＣ＝Ａ×Ｂを作成する。ただし、Ｃはハッシュ空間Ｈの最大値よりも小さい事が必要である。今、ユーザＡがＣを作成したとする。
[2]ＩＰアドレスとポート番号の組み合わせをDとしてこのハッシュ値Z＝Hash(D)をノード固有情報とする。
[3]ユーザＡはＤＨＴに参加する際に、ノードＩＤ＝Hash(C^m×Z mod T)とする。ここでHash()とはハッシュ関数である。今、C^mとはCのm乗を意味する。mはべき乗数と呼ぶ事にしよう。mは各ノードが乱数で決定し、十分大きい数とする。またID、Z、mをDHTノードに公開する。Tは各ノード共通である。

なおノードＩＤにZという要素が必要な理由は、大きく分けて２つである。
理由１：たまたまノードＩＤ＝ＣでユーザＡとユーザＢが一致した場合、ユーザＢはユーザＡの成りすましが可能である。（ユーザＡもユーザＢもＣを素因数分解できるため。ちなみにある数Ｒは一意に素因数分解できることが知られている）
理由２：ノードＩＤ＝Ｃとすると、ノードＩＤは相当大きな数になってしまい、ハッシュ空間にノードＩＤを均一に存在させる事が難しくなる。
＊こちらの理由は正しくありませんでした。削除します。（11/4)
☆認証プロトコル
今、ユーザＢがユーザＡを認証しようとする。ユーザAはノードID=P、固有情報=Q,べき乗数＝RをDHT参加ノードに公開している。

[1]ユーザＢはユーザAを認証したい。ユーザBはDHTよりユーザAの公開情報（P,Q,R)を入手する。このとき、ユーザBはユーザAと直接通信することで、ユーザのIPアドレス及びポート番号の情報Eを手に入れ、Q=Hash(E)を検証する。Q≠Hash(E)ならMan-in-the-middle atatckをされる可能性がある。
[2]ユーザAは（ユーザBの求めに応じて）ユーザBにCを通知する。ここでユーザBはHash(C^R×Q mod T）を計算しPと合致するか計算する。
[3]ユーザＢはゼロ知識証明よりユーザＡが確かにCを素因数分解できることを証明する。
[4]結果としてユーザＢはユーザＡが（P,Q,R..C）の組を保有し且つCの素因数分解ができる正当性を検証できる。

□終わりに

今回提案したプロトコルを使えば、認証の際にＰＫＩやＰＧＰを使う必要がない。非常にシンプルなプロトコルなので、実装も容易である。簡易なＰ２Ｐの認証方法として期待できそうだ。

なお、この提案に対するBlogコメントがあります。コメントに対するレスは後ほど書いてみます。(11/4追記）
http://d.hatena.ne.jp/smoking186/20061104

[P2P]SkipGraphを利用した部分一致検索の提案

□はじめに
最近Structured P2Pの一種であるSkipGraphが注目されている。SkipGraphの特徴の一つとして、ある範囲のNodeIDを保有するノードに対して一斉に各種クエリーを届ける事が出来る事が挙げられる。

SkipGraphのわかりやすい解説は後日として、今回はこのSkipGraphの特徴を利用した部分一致検索を提案する。

□定義
今ハッシュ空間をＸとし、ハッシュ空間のノルム（大きさ）を|X|としよう。Ｘを出力するハッシュ関数をHash()とする。
Ｘにおいて、prefix1()、prefix2(),prefix3(),prefix4()を定義する。これはp=|X|/4の桁に対して、
prefix1(A)＝Aの上位p桁を抽出する関数
prefix2(Ａ)＝Ａの上位p+1～2p桁を抽出する関数
prefixn(A)＝Aの上位(n-1)p+1～np桁を抽出する関数

とする。なお、|prefixn(A)|=|X|/4であることに注意。いま、prefixn(A)が覆う空間をX(n)として、そのハッシュ関数をhash(X(n))とする。
また、A=sum(prefix1(A),prefix2(A),prefix3(A),prefix4(A))となるsum関数を定義する。

□部分一致検索の方法

☆Skipgraphへの情報Ｐ登録

ある情報ＰをSkipgrapghに登録するために、まず、Ｐを形態素解析で単語pに分解し、更にハッシュ関数hash(p))を掛ける。

今、Pに含まれる単語が４つしかないとすると、p={p1,p2,p3,p4}となる。
ここで、p(n)=hash(pn)とする、更にp(n)の大きさ順にpをソートする。例えばp1>p2>p3>p4としよう。
次にＲの計算をする。
R1=sum(p(1),p(2),p(3),p(4))
R2=sum(p(2),p(1),p(3),p(4))
R3=sum(p(3),p(1),p(2),p(4))
R4=sum(p(4),p(1),p(2),p(3))

Rnにおいて、sum(pn,pnを含まない残りの元でp(n)の大きい順にソート）となる。
Ｐについては、NodeID=Rnとなるノードに格納することになる。

☆情報Ｐの検索

今、Ｐを構成する単語Sがあった場合、Ｐは見つけられるのだろうか？答えはＹｅｓである。
まず、s=hash(S)とする。
この際、Skipgraphを使ってsum(s+1,0,0,0)>NodeID≧sum(s,0,0,0)となるノードに検索クエリをPush型でマルチキャストすれば良い。

では、単語S,TのAND検索はどうすればよいか？
この時には
[手順1]s=hash(S)、t=hash(T）を計算する。
[手順2]t>sの場合、Skipnetを使ってsum(s+1,0,0,0)>NodeID≧sum(s,t,0,0）となるノードに検索クエリをPush型でマルチキャストすれば良い。

更に複数単語のＡＮＤ検索も同様である。

prefixnにおいてn=4としたが、nを大きくすると検索計算量と情報登録するための処理数が大きくなる。nをどの程度にするかはAND検索の頻度や単語数を考慮する必要があるだろう。

□終わりに
部分一致検索をSkipgraphを利用して解決した。Skipgraphの特徴であるPush型マルチキャストを利用してたＰ２Ｐシステムは今後増えるだろう。

[DHT]第2回DHT勉強会議事録について

先月行われた第2回DHT勉強会は非常に活発な議論が行われ、とても盛り上がりました。
この度、無印吉澤さんが議事録の公開をしましたので、是非ともDHT勉強会の復習にご覧下さい。
出席されなかった方も、当日の雰囲気が味わえるはずです。

とても詳細な議事録となっています。

無印吉澤：第2回DHT勉強会議事録

[Winny]Winnyネットワークをダウンさせる方法の提案

第2回DHT勉強会の講師として、DHT（分散ハッシュテーブル）のセキュリティ対策についてレクチャーを行ったが、オーバーレイなシステムについては、セキュリティの研究をもっと積極的に行うべきだと思った。意外にこの分野で研究をしている人が日本では少なかったりする。

ところで、DHTのセキュリティ対策を考えている際にWinnyのネットワークをダウンさせる効率のよい方法も考えたので、皆様の意見を聞きたいと思う。

□悪意のノードの混入でシステムダウンは可能か？

そもそもの考察の発端はDHTにおいてどの程度悪意のノードが混入した場合、システムがダウンするかを検討したことである。実は相当数の悪意ノードが混入しない限りシステムはダウンしない。この結論に従うと、たとえWinnyに悪意のノードを混入しても相当数の悪意のノードがない限りシステムはダウンしないことになる。

上流のノードを選択的に悪意のノードに置き換える攻撃方法を検討している人がいる。しかしながら上流ノードにおける隣接ノード数を考えてみると、ネットワーク全体レベルでのダウンを実際に実行しようとすれば、相当のリソースが必要となるだろう。このようなリソースが確保できるのは現状国家レベルの機関しかないだろう。

□P2Pならではの特徴を利用したアタック

ところが、P2Pならではの特徴を利用すると、一人のスーパークラッカーがいればオーバーレイ系、例えばWinnyのネットワークをダウンできる可能性がある。
ヒントはeEye社の鵜飼氏によるWinnyのプロトコル、脆弱性に関する講演である。
Winnyの解析とそのセキュリティ脅威分析セミナー概要
http://toremoro.tea-nifty.com/tomos_hotline/2006/05/winnywinny_21c2.html
鵜飼氏は上記講演にてWinnyにおける脆弱性について説明するとともに、近い将来P2Pネットワークを使ったワームが発生した場合、きわめて短時間でワームがP2Pネットワーク全体に蔓延するだろうと予測している。

Winnyのシステムをダウンさせるには、このようなP2Pワームを利用することとなる。
具体的にはスーパークラッカーが次のようなワームを作成すればよい。

☆ワームの機能
ワームの機能として
・特定時間以降はWinnyにおいてすべてのノードと接続しない機能
・アプリを常駐させ特定時間以降はWinnyのプロセス立ち上がりを妨害するorプロセスをダウンさせる機能
・P2Pシステムのメッセージ機能を利用してワームをP2Pシステムに拡散する機能
等が挙げられる。

この「特定時間」の設定が大切である。特定時間の設定の狙いはワームをP2Pシステム全体に可能な限り蔓延させ、ある時間に「一気に」P2Pシステムが崩壊させることが狙いである。このようにすれば、ある特定時間以降はWinnyの各ノードは、他のノードと接続できる可能性が極端に低下する。つまり、Winnyネットワークは１から立ち上がる必要があり、そのネットワーク成長は非常に遅いと考えられる。Winnyネットワークが現状のような規模に復活するには時間がかかるだろうし、それまでにワームの亜種が発生すれば、現在のようなネットワークサイズまで回復しないかもしれない。

もちろん、このようなワームが本当に現在のWinnyで作成可能かどうかは注意深い検討が必要だろう。

□終わりに

オーバーレイのネットワークにおいては、非常に短期間でワームが蔓延する恐れがある。特にDHTのようなホップ数が低いシステムではそのような特徴が顕著になる。
P2Pアプリを作成する際には、脆弱性について細心の注意が払う必要があると考えられる。

[DHT]第2回DHT勉強会お疲れ様でした！

今日は第2回DHT勉強会でした。悪天候にも関わらず60人強もの参加者が集まり、熱心にDHTに関してディスカッションを行いました。

こんなニッチな勉強会にも関わらず、多くの人が集まるとは正直思っていませんでした。DHTへの関心の高さが伺えます。また講演の質の高さも素晴らしかったです。

私が特に関心を持ったのは吉田さんのSkipGraphの話題です。吉田さん曰く、DHTよりSkipGragphの方が長所が多いとのことです。ところで吉田さんのシステムはSkipGraphの上でDHTをまわしているのですが、もし吉田さんの主張が正しいなら、なぜSkipGraphで系全体を作らないのか疑問を感じました。（質問するのを忘れてしまいましたが。）またDHTよりSkipGraphのほうがどの点で優位なのか、私もきっちり考察してみたいと思います。

もう一つは加藤さんのDe Bruijn Graphの話。なるほどな！とうなづけるグラフ理論の興味深い応用です。この手法を使うとDHTとしてコンパクトなルーティングテーブルを持ち且つホップ数を抑えることができるようです。こちらも調べてあとでBlogに書きたいな。

なおプレゼン資料は順次以下のサイトにアップします。
http://homepage3.nifty.com/toremoro/study/study.html

また議事メモは無印吉澤さんが作成するとの事です。

次は第3回P2P勉強会 or VoIP Conferenceですね。こちらも是非注目してください。
その前にP2P新年会 or 忘年会かな？

[P2P]UNIX MagazineにDHT入門記事を執筆しました！

本日（9/16[土])発売のUNIX Magazineは、なんとP2P特集です！
私もDHT入門ということで執筆させて頂きました。（夏休みは専らこの執筆作業をしていました。）
UNIX Magazineの目次については下記のリンクを参考して下さいね。
http://www.ascii.co.jp/books/magazines/unix.shtml

★総力特集　P2Pアーキテクチャ
・P2P技術の再考　浜辺将太
・分散ハッシュテーブル入門　西谷智広
・アプリケーション層マルチキャスト：基本と応用　首藤一幸
・地産地消P2Pネットワーク　斉藤賢爾
・P2Pと2つの「アーキテクチャ」　土井裕介
・【インタビュー】問題点の抽出と整理　山口 英
・P2P今後のアーキテクチャ　覆面座談会

（P2P関連部分のみ抜粋）

是非ともDHT勉強会の予習・復習用に活用してください。

[DHT]第2回DHT勉強会懇親会

第2回DHT勉強会の後に懇親会を開きます。
基本的にはDHT勉強会参加者のための懇親会ですが、懇親会のみの参加もOKです。
DHT勉強会の講師と直で話せるチャンスですので是非とも参加して下さい。

□日時：9/18(月・祝）18：30～20：30
□場所：北海道　渋谷駅前店
http://r.gnavi.co.jp/g086283/
（個室を確保しました！）
□会費：出来高制ですが、4000円前後を想定
□定員：25名程度

参加申し込みはMixi経由です。
http://mixi.jp/view_event.pl?id=10188468&comm_id=128733

よろしくお願い致します。

[DHT]DHTとホップ数の関係[その2]～Chordの平均ホップ数を考えよう

前回は直感的な方法でDHTのホップ数について推定した。今度はChordに絞ってホップ数を調べる事でより理解を深める事にしよう。

□Chordのリンク数からホップ数を推定

まず、Chordのノード参加数をN=2^xとしよう。2^ｘとは２のｘ乗を表す事とする。ここで1ノード当たりのリンク数はlog(N)＝ｘである事に注意。

平均ホップ数を計算するときに発想を転換しよう。今1ノードｘあたりのリンクがある。すると、P回ホップ数すると、ホップ可能な総ノード数LはだいたいL=x^Pとなる。x^P=Nであれば、P回ですべてのノードにアクセスできると大体考えられる事ができる。つまり、平均ホップ数P=log(N)/log(x)=log(N)/log(log(N))～O(log(N))となる。
最後の近似はやや荒っぽい。計算がlog(N)より小さく出たのはホップ時に到達するノード数の仮定が甘いからである。

□もう少し解析的にホップ数求める方法

今度は違った見方をしてみよう。この手法によるホップ数算定はこのBlogが初発表になるはずだ。

今ノード０からのリンクを考えると、総ノード数を2^xとして距離2^0、2^1・・・2^{x-1}のノードとリンクを張るはずだ。
ところで、ハッシュ空間にすべてノードが埋まっている場合、あるノードへ到達する際に次ホップする距離はホップ毎に単調減少するはずだ。（この証明は読者にお任せする。）
つまり、次ホップまでの距離をR、ホップ数をｔとするとR(t+1)＜R(t)である。
ところが、R(ｔ）として取れる数は、{2^0、2^1・・・・2^{x-1}}というlog(N)個しかない。つまり、最大ホップ数はO（log(N))より超える事がないはずである。

ここで問題なのは、O(log(N))というステップ数で本当に2^xの空間のすべてのノードに到達できるかということである。

そのために補題を作る。
補題：
2^{x-1}+1≦P＜2^x となる整数Pは、集合S{2^0、2^1、・・・2^{x-1}}の和で表される。ただし、この和において、集合Sの各元は高々1回しか現れないとする。

証明：帰納法により証明可能。

この補題により、O(log(N))のステップ数以内に、任意のノードに必ず到達できることが証明できた。
今はハッシュ空間にすべてのノードが参加していることを仮定した。ノードが部分的に参加してない場合の証明については読者にお任せする。

[DHT]第2回DHT勉強会講演概要＆タイムスケジュール

お待たせしました、第2回ＤＨＴ勉強会講演概要をお知らせします。

講演概要
＝＝＝

◇日時：9/18(月、祝）　
開場：9：30
講演時間：10：00～16：30

◇場所：金沢工業大学東京虎ノ門キャンパス1F (93.101)
アクセス方法：
http://www.kanazawa-it.ac.jp/tokyo/map.htm
◇定員：60人
◇参加費：1000円程度（調整中）
◇参加申込フォーム（お手数ですがＭｉｘｉ経由でお願いします）
http://mixi.jp/view_event.pl?id=8168327

講演タイムスケジュール、講演概要

9:00～　開場準備開始

9:30～　開場

10：00～　開会の挨拶

10：10～
加藤　大志　氏：ＮＥＣ
「世界規模情報共有プラットフォームの実現に向けて」
(概要)
ユーザが主体となって形成する情報共有プラットフォーム構想を紹介する。これを実現するための一つの技術としてDHTに着目し、低通信量を達成するためにconstant-degree DHTと呼ばれる方式を説明する。
また、DHT実装をエミュレートする基盤を使って複数の既存DHTを比較する実験およびその結果を紹介する。

11：10～
西谷　智広：Tomo's Hotline
「ＤＨＴにおけるセキュリティ対策」
（概要）
DHT におけるセキュリティ対策が近年注目を浴びている。本講演はルーティングテーブル及び登録データの改ざん、登録データの意図的ロスト、PKIを用いた認証、運用管理性の向上、システム可用性等について議論を行う。また上記対策を用いたアプリケーション構築方法についても提案を行う。

12：00～13：10　ランチタイム

13：10～
吉田　幹　氏：(株)BBR 取締役CTO
「P2Pエージェントプラットフォーム PIAX の理念と実装」
（概要）
ユビキタスサービスに狙いを置いた P2Pエージェントプラットフォーム PIAXについて、理念と実装の面からお話します。PIAXの特徴は、マルチオーバレイのサポートと分散エージェント機構にあり、とりわけ地理的情報探索のためのオーバレイ（LL-Net）を持つ点に特色があります。今回はPIAX技術に加え、実装で用いたSkip Graphと呼ばれる技術の紹介をします。

14:10～
池嶋　俊　氏：筑波大
「AsagumoWeb Web over P2Pシステムの設計と実装」
（概要）
AsagumoWebはP2P技術を利用したWebシステムである。AsagumoWebは既存のWebシステムにある負荷が集中するという問題を解決する事ができる、分散型Webシステムである。
今回は、何故分散型Webシステムが必要である背景から、Webシステムの実装の概略、P2PおよびDHT技術がAsagumoWeb内でどのように使われているかを説明する。

14：50～
藤田 昭人　氏：大阪市立大学
「Chord プロトコルを活用したシステム開発の実際」
（概要）
構造化オーバーレイの研究領域では著名な研究成果が発表されている Chord プロトコルだが、それを活用したシステム事例が増えない一因には Chord の開発元である MIT が実装コードを文字通りの AS-IS （リリースエンジニアリングしていない）で公開していることによる。本発表では主に構造化オーバーレイの研究を目指す学部学生およびその指導教官のみなさま、および構造化オーバーレイの実験を計画している一般プログラマーのみなさまへの参考情報の提供を目的として、MIT が公開している Chord 実装の概要、その代替として活用できる実装
事例、そして発表者自身の手で進めている i3 Chord を活用したシステム開発の実際について文献を含めて紹介する。

15：40～
首藤　一幸　氏：ウタゴエ(株) 取締役 最高技術責任者
「オーバレイ構築ツールキット Overlay Weaver 」
(概要）
Overlay Weaver はオーバレイ構築ツールキットです。
アプリケーション開発に加えて、オーバレイのアルゴリズム設計もサポートします。

アプリケーション開発者に対しては、分散ハッシュ表 (DHT) やマルチキャストといった高レベルサービスに対する共通 API を提供します。この API を用いることで、特定のトランスポートプロトコル、データベース、ルーティングアルゴリズムに依存しないアプリケーションを開発できます。

Overlay Weaver は、ルーティングアルゴリズムとして Chord、Kademlia、Koorde、Pastry、Tapestry の実装を提供しています。ルーティング層の分割によって、これらのアルゴリズムをたかだか数百ステップで実装することが可能となりました。ルーティング層は高レベルサービスの下位に位置し、ルーティングドライバ、ルーティングアルゴリズム、およびメッセージングサービスから構成されます。この分割によって、新規アルゴリズムの実装も容易になっています。

Overlay Weaver はまた、新たに実装したアルゴリズムを試験、評価、比較するためのエミュレータも提供しています。このエミュレータは数千の (仮想) ノードを扱うことができ、大規模エミュレーションによるアルゴリズム間の公正な比較を可能にします。

16：30　閉会の挨拶

17：00　後片付け終了

＝＝＝＝

皆様のご参加を心よりお待ちしています。

[P2P]P2P納涼会のお知らせ（8/25[金]開催：新宿）

P2Pコミュニティにおいて新年会に引き続き、納涼会を開きます。
P2Pに関心がある方であれば誰でも参加ＯＫです！
奮ってご参加願います。
なお、応募はMixi経由でお願い致します。

□日時：2006年8月25日（金）19：00～
□場所：北海道　新宿三越前店（場所が変更になりました！ご注意願います）
http://r.gnavi.co.jp/g306019/
□会費：4000円程度を想定（出来高制）

申込みは以下のページからお願い致します。
http://mixi.jp/view_event.pl?id=7924684&comm_id=6936

皆様の参加を心よりお待ちしています！

DHTのセキュリティ考察～その５ ノードIDの偽装対策

今回はＤＨＴのNodeIDの偽装対策について検討しよう。

□Ｃｈｏｒｄの実装
ＣｈｏｒｄはＮｏｄｅＩＤとして、ＩＰアドレスのハッシュ値を取っている。
ＩＰアドレスは（グローバルなら）一意だし、また通信ノードのＩＰアドレスが分かれば、ＮｏｄｅＩＤとＩＰアドレスからノードの正当性が簡単に確認できる。

しかしこの方法は次のような課題点がある

[課題点]プライベートアドレスのノードが存在すると、NodeIDが衝突する恐れがある
[課題点1-1]NAT-FW、プロキシがある場合、仮にグローバルアドレスをノードが
取得しても
ＮｏｄｅＩＤが衝突してしまう。
[課題点1-1-1]グローバルアドレスをノードが自動的に取得する方法がない場合
がある
[課題点1-2]固定ＩＰ払い出しサービスでない限り、ＩＰアドレスは変動する

ではどのようにすれば良いのか？

□Chord実装の拡張

ひとつの方法はＩＰアドレスとポートを組み合わせた数値のハッシュ値をＮｏｄｅＩＤとする方法である。これにより課題点１－１はクリアする。ただし、やはり[課題点1-1-1]を検討する必要がある。

課題点1-1-1,1-2の解決方法としてはSTUNやＴＵＲＮサーバを使って、ノードがインターネットで通信する際のグローバルアドレスとポートを定期的に取得することが必要だろう。もちろんＵＰｎＰを利用する方法もある。

□電子証明書による正当性確認

もうひとつの正当性確認方法は電子証明書を利用する方法である。
各ノードに配布した電子証明書のシリアル番号と名前の組み合わせを数値化し、そのハッシュ値をＮｏｄｅＩＤとする。検証する際には電子証明書を参照し、検証するノードとチャレンジレスポンスをすればよい。
（チャレンジレスポンスをする理由は電子証明書を持っている人が本当に発行元のノードであることを確認するため）上記方法はノードがプライベートアドレスでもグローバルアドレスでもまったく関係なく正当性が確認できる利点がある。

ただし、この方法はノードに負担かかることは言うまでもないだろう。

[DHT]DHTのセキュリティ考察～その４

ＤＨＴのセキュリティにおいて、少し見方を変えてみよう。

P2Pシステム代表例であるWinnyではキャッシュが管理者等によって削除されな
かったのが問題であった。ＤＨＴで掲示板等を作成すると管理者によってコメン
ト変更あるいは削除することが必要であろう。

ここでは管理者（スーパーユーザ）によるＰ２Ｐシステムを管理を提案する。

まず、管理者は付与された電子証明書に管理権限があることを明記される。
これは第三者に管理権限があることを確認させるためである。

今、管理権限があるユーザをスーパーユーザと呼ぶことにする。
スーパーユーザは、データの削除、変更が可能である。

データを削除する際には、該当データを保有する登録ノードに削除依頼をする。
登録ノードは管理者の電子証明書を参照して管理権限があることを確認し、デー
タを削除する。

□スーパーユーザの分散管理

上記のような仕組みの場合、悪意のあるスーパーユーザはデータを簡単に削除、
改ざんできる。このような悪意のユーザがいる場合でもシステムが保持できる仕
組みを提案する。

先ほど、管理者は登録ノードにデータ削除依頼ができるとした。ここで、管理者
から登録ノードにはＸＭＬベースでメッセージを投げるとする。
このとき、ＸＭＬに複数の管理者の多重電子署名がない限り登録ノードは削除を
実行しないようにすることもできる。つまり、複数のスーパーユーザの同意が取
れない限りデータの削除はできない。

□スーパーユーザの権限剥奪

スーパーユーザに対して権限の剥奪も可能だ。トラストと考えられるユーザを
トップユーザとして、スーパーユーザの権限の付与を与える。
スーパーユーザの権限を剥奪する場合には、該当ユーザの電子証明書を失効する
手続きを行う。ＣＡはＣＲＬをＤＨＴに配布する。

□まとめ
ＰＫＩをうまく使うことにより、複数の管理者によってＰ２Ｐシステム管理が可
能であることがわかる。多重電子署名を使えば、管理者による権限逸脱を防止す
ることも可能だ。

[DHT]DHTのセキュリティ考察～その2

今回はＤＨＴにおける完全性対策について提案を行ってみたい。

□完全性に対する脅威
ＤＨＴにおいて、情報ＸはＮｏｄｅ_ID=hash(X)というノードに登録される。（これを登録ノードと呼ぶことにしよう）
この方法だけではざっと検討しただけでも以下のような脅威が考えられる。
[脅威1]登録ノードによって登録データが消去される
[脅威2]登録ノードによって登録データが改ざんされる
[脅威3]登録ノード以外の第三者によって登録データが消去される
[脅威4]登録ノード以外の第三者によって登録データが改ざんされる

今回は脅威2～脅威4の対策を説明する。

□電子証明書のノードへの配布

セキュリティ対策の基本的テクニックとして電子証明書を利用することが挙げられる。
例えばＤＨＴの各ノードに電子証明書を配布することにしよう。ＣＲＬについてもＤＨＴ各ノードに配布、あるいは取得できるようにする。なお、証明書発行ノードがＤＨＴノードとは別途必要である。

電子証明書には氏名（あるいはニックネーム）や発行日等が記載される。ここで提案として各ノードのノードＩＤを電子証明書に掲載することが考えられる。そうすれば、各ノードは自らのノードＩＤの正当性証明することができる。もちろんノードＩＤは証明書発行ノードが払い出しを行う。ノードＩＤはハッシュ空間を均一に埋めるように発行しなければならない。（ノードＩＤを電子証明書に格納するメリットは次回以降詳細に説明します。）

各ノードの電子証明書はあるサーバに対して参照できるようにしても良いし、せっかくＤＨＴがあるので、ＤＨＴに電子証明書を分散させて格納するのも良いだろう。

□登録ノードへの情報登録

いま、ノードＡがＸという情報をNode_ID=hash(X）となる登録ノードＢに格納したい。
すると次のような手順を行う。

[手順1]ノードＡはノードＢに電子証明書を提示する。ノードＢは電子証明書が有効であることを確認すると同時にノードＡが本当に電子証明書所持者と同一か確認する。
確認方法としてチャレンジレスポンス等が挙げられる。
[手順2]ノードＡはノードＡの秘密鍵S_Keyでhash(X)を暗号化する。これをS_hash(X)としよう。
[手順3]ノードＡはＸ、S_hash(X)をノードＢに登録依頼する。
[手順4]ノードＢはノードＡのノードＩＤ、Ｘ，S_hash(X)を格納する。

S_hash(X)はＸに対する一種の電子署名と考えてもらっても良い。
Ｘが改ざんされているかどうかはノードＡの電子証明書を取得して、その公開鍵を使ってS_hash(X)からhash(X)を復号すればよい。

なお、データの削除手順は以下の通りである。

[手順1]ノードＡはノードＢに電子証明書を提示する。ノードＢは電子証明書が有効であることを確認すると同時にノードＡが本当に電子証明書所持者と同一か確認する。
確認方法としてチャレンジレスポンス等が挙げられる。
[手順２]ノードＡはＸ、S_hash(X)をノードＢに削除要求をする。

上記手続きにより脅威2～４は防止できる。脅威１については、データを隣接ノードでレプリケーションするので、この部分を工夫すればある程度防止できるかもしれない。今後は脅威1の対策を検討したい。

[DHT]DHTにおけるセキュリティ考察～その１

P2Pの基幹技術としてDHTが随分認知されてきたが、セキュリティの話になると活発な議論がされてない状況である。

ここでは、9月に開催される第2回DHT勉強会で私が講演する内容の概要をBlogにまとめたいと思う。

□DHTのセキュリティ対策

セキュリティ対策には3要素あり、通称CIAと呼ばれている。
Cは機密性、Ｉは完全性、Ａは可用性である。今回はCIA各要素に対してＤＨＴではどのようなセキュリティ対策をすれば良いのか提案あるいは考察をする予定である。

□DHTの大局的な観点における可用性について

全ノードが信頼できるノードである状況はまれで、通常は悪意のあるノードが存在する可能性がある。この際に悪意のあるノードが何％紛れた場合にネットワークが分断されるかが気になるところである。

ここではパーコレーションという物性物理理論のテクニックを使って上記問題を考察してみよう。

□パーコレーションとは？

パーコレーションという語彙を説明するにはまずは下記のサイトを見たほうが早いだろう。
http://www.mi.ics.saitama-u.ac.jp/~yas/research/network/percolation/

パーコレーションは「系全体におけるつながり」を議論する。どのような状況のときに系全体がつながるか、その条件を決めることがパーコレーションにとって重要なことである。このように書いてみると、パーコレーションにおける「つながり」≒ＤＨＴでシステムを維持することであることが分かるだろう。

今、DHTとして2次元CANを考えてみる。CANにおいて、悪意のあるノードがあって、悪意のノードは他ノードからのリクエストを破棄してしまうとしよう。このとき、悪意のノードがどの程度含まれていれば、システムはダウンするだろうか？

パーコレーションはこれに対して明確な答えを出す。答えは50%以上の悪意のノードがあればダウンするということである。（この問題はサイトパーコレーションと呼ばれる）

では、今度は別の見方からパーコレーションを活用してみる。
今、各ノードはリンクがＮ個出ているとする。では各ノードのリンク総数が何％ダウンした場合、システムはダウンするだろうか？

2次元CANであれば、既に答えは判明している。それは、約4割のリンクがダウンすればシステムがダウンしてしまうことである。（この問題はボンドパーコレーションと呼ばれる）

2次元CANで解析した結果から分かるように、DHTでシステム全体をダウンさせるには相当数の悪意のあるノードが必要であることがご理解頂けるだろう。
実は、この結果はWinnyのような多リンクでノードが繋がるシステムをダウンさせることが極めて難しいことを意味している。

□Chordとパーコレーション

では、PastryやChordといわれる、より多リンクのノードの場合、どのぐらいでシステムをダウンできるだろうか？直感的にサイトパーコレーションでも少なくとも50%以上の悪意のノードが必要であることがわかるだろう。

事実、サイトパーコレーションでもボンドパーコレーションでも、多次元になればなるほど悪意のノードが相当多くないとシステムがダウンしないことがわかっている。詳細は下記を見て欲しい。
http://www.geocities.jp/ikuro_kotaro/koramu/kousi2.htm

つまり、悪意のノードがいてもシステムの可用性を極力下げない方法として各ノードにおけるリンク数を増やせばよいことが挙げられる。実際的には50％以上も悪意のあるノードが存在する可能性は少ないので、通常のＤＨＴを使い、さらにそれなりにノード数が存在する場合についてはシステム全体がダウンすることはほとんどないだろう。システムダウンがあるとすれば、DHT経由で各ノードがワームに感染する場合ことが考えられる。

今後は悪意のあるノードが存在した場合の局所的な影響を考察してみたい。

[P2P][DHT]第2回DHT勉強会参加募集開始のお知らせ

第2回DHT勉強会を以下の通り開催します。
皆様の参加をお待ちしております！

◇日時：9/18(月、祝）　
10：00～15：00（時間は調整中）

◇場所：金沢工業大学東京虎ノ門キャンパス1F (93.101)
アクセス方法：
http://www.kanazawa-it.ac.jp/tokyo/map.htm
◇定員：60人
◇参加費：1000円程度（調整中）
⇒講師のお足代等に充当します。

◇講師陣のお知らせ（7/1現在）

-首藤 一幸　氏 ：ウタゴエ(株) 取締役 最高技術責任者
「オーバレイ構築ツールキット Overlay Weaver (仮)」
⇒ご存知Overlay Weaverの開発者の方です。

-加藤　大志　氏：NEC
「プロトコルとして見たDHTの設計と実装 (仮)」
⇒P2P-Webの開発者の方です。

-池嶋　俊 氏：筑波大
「AsagumoWebの開発・実装について（仮）」
⇒SoftEther開発者、「入門Skypeの仕組み」著者です。

-吉田 幹 氏：(株)BBR 取締役CTO（7/1追記）
「P2Pエージェントプラットフォーム PIAX の理念と実装」
⇒ 地理的range searchのための LL-Net と、汎用的オーバレイである Skip Graph の2つの技術について紹介します

-西谷　智広:Tomo's Hotline
「DHTにおけるセキュリティ対策を考察する～DHTプラットフォームの信頼性向上にむけて（仮）」

＊講演者、ミニプレゼン講演者を引き続き募集中です。
＊懇親会等も予定しています。参加者を別途募集します。
＊スタッフ希望の方は別途ご連絡下さい。スタッフ用の特典をご用意しています。

参加募集は以下のページ（Mixi）からお願い致します。
http://mixi.jp/view_event.pl?id=8168327

[DHT]DHT勉強会ミニプレゼン講演者募集について

先日お知らせしたように９月に東京にて第2回DHT勉強会を開きます。
http://toremoro.tea-nifty.com/tomos_hotline/2006/04/p2pdht2dht_b1ab.html
それに合せて、ミニプレゼン講演者を募集します。

□ミニプレゼン概要

・内容：DHT関連であれば問いません
・プレゼン時間：プレゼン15分、質問5分（目安、内容・ボリュームにより時間調整可）
・募集人数：4人程度
・特典：DHT勉強会参加費無料、懇親会費減額あるいは無料

なお、DHTプレゼンはどなたでも参加可能です。大学生～社会人まで皆様参加して下さい！
学会や卒論・修論で書いた内容を簡単にまとめてもOKです。またジャストインアイデアなものや、提案等でもかまいません。

DHT勉強会を通して是非情報発信をしてみませんか？

なお、参加に興味のある方はtnishita@yahoo.co.jpまでご連絡をお願い致します。

[DHT]DHTとホップ数の関係[その１]～直感的な方法

DHTの論文を見るとホップ数についての記述があるが、その計算根拠について書いてない場合が多い。
ここでは簡単な方法を使ってホップ数のオーダーを考えてみよう。
なお、次回以降には微分方程式・数列等を使うことにより、より詳細な考察を行う予定である。

今回はCANとChordについて書いてみることにする。

□CAN
CANについての概要は以下のサイトをご覧になってほしい。
P2Pと分散ハッシュテーブル～その１

今、２次元空間のCANを考える。縦、横ともnの大きさがあるとすると、ノード数はN=n^2である。ただし、^2は二乗を表すこととする。

ホップ数については、（0,0)というノードから（論理的に）一番遠いノードに対するホップ数とほぼ同じオーダーであろう。一番遠いノードは（n,n)である。
注※正確には(n-1,n-1)。ホップ数のオーダーにはあまり関係ないこと、見た目が複雑なので(n,n)で書いていく。

(0,0)から(n,n)までは2nホップかかる。ここでCANではリンクが縦または横にしかないことに注意！斜めにホップすることはできない。

結局ホップ数は　2n=2√（N)となる。つまりO(N^｛1/2})である。

ちなみに同様な方法で計算すると、d次元の空間においてホップ数はO(N^{1/d})である。

□Chord
Chordの概要は以下のサイトをご覧になって欲しい。
P2Pと分散ハッシュテーブル～その2

今ノード数をNとして、n=log₂Nとする。
ノードAからはリンクをnだけ出していることに注意。

Chordは2^p離れたノードに対してリンクをする。（pは０以上の整数）
つまり、１回リンクを辿ると、次にホップできる空間を1/2に絞ることができる。
するとホップ数qは、リンクを辿ることでホップできる空間があるノードに限定してしまう状態、つまり次にホップできる空間が１に辿りつくホップ数が分かれば良い。

結局N*(1/2)^q = 1であり、これを解いてq= n = log₂ Nとなる。つまりq= O(log ₂N)

次回は数列や微分方程式を使ってよりエレガントにホップ数を計算できる方法を提案したいと考えている。　

[DHT]DHTはスモールワールドか？

スモールワールドが流行してた時に、DHTもスモールワールドであるかどうか議論が盛んであった。そこでDHTが本当にスモールワールドかどうか私なりの議論をしておきたい。

□クラスタリング係数
各種ネットワークを分類するときに、平均到達ホップ数とクラスタリング係数を算出することになる。
ここでクラスタリング係数とは、あるノードAに対してリンクを張ってあるノード群PがP内のノード間でどの程度リンクを張っているか示す数値である。クラスタリング係数Cは一般に０から１まで取り、C=1ならノード間は完全グラフ、つまりとても密にリンクされていることになる。

□スモールワールドとは？
スモールワールドとは平均ホップ数が小さいのにCが大きいグラフを指す。ワッツ＝ストロガッツモデルが有名である。平均ホップ数が小さいモデルとしてはスケールフリーネットワークが有名であるが、こちらはCが小さい。

□Chordにおけるクラスタリング係数の導出

さて、これからが本題である。DHTの手法として有名なChordについてクラスタリング係数を計算してみる。
当初、Chordにおけるクラスタリング係数について具体的な計算を行っている論文を探していたが見つからなかったので、今回の方法は私が独自で計算したものである。間違い等があれば指摘してほしい。

なお、数式を簡略化するため、AのB乗をA^Bと書くこととする。

Chordにおいてハッシュ空間を2^nとする。今、Node_ID=０から見ると、リンクはAノード群：Node_ID=2^0、2^1....2^(n-1)にあることになる。また、Node_ID=0にリンクしているノードも忘れてはいけない。これはBノード群：Node_ID=-2^0,-2^1....-2^(n-1)
である。ただし、簡略化のため　-P=2^n-Pを指すこととした。クラスタリング係数を出すには、
Node_ID=2^0,2^1.....2^(n-1)、-2^0,-2^1......-2^(n-2)間でリンクがいくつあるか計算することになる。ただし、左記で-2^(n-1)=2^(n-1)であることに注意してほしい。

＊Aノード群からAノード群へのリンク数
例えば、Node_ID=2^0は自身から距離2^0,2^1.......2^(n-1)までのリンクを張っている。それではAノード群からAノード群へのリンク総数はいくらだろうか？

ここで一つ補題を出す。
□補題１：
2^a-2^b=2^cが成り立つのはa,b,cが正の整数ならa=b+1、c=a-1に限る。
証明は簡単なので省略。

すると、補題を使って、Node_ID=2^0が他のAノード群とリンクをするノードはNode_ID=2^1に限られる。
同じように、Node_ID=2^aは2^(a+1)のみAノード群とリンクを張る。
つまり、Aノード群からAノード群へのリンク数はn-1である。なお、Node_ID=2^(n-1)から上記方法でリンクをするとNode_ID=0とリンクするので、この部分はリンク数からはずしている。

＊Bノード群からBノード群へのリンク数

先ほどと同じ手順で考えればよい。
□補題2
2^n-2^a-(2^n-2^b)=-2^a +2^b=2^c
はa,b,cが正の整数ならb=a+1,c=aに限る。　

よって、Bノード群からBノード群へのリンク数はn-1である。ここで上記方法だと、Node_ID=-2^1がNode_ID=0とリンクされるので、その部分をリンク数からはずしている。

*Bノード群からAノード群へのリンク数

これも同様な手順を考えばよい。

□補題３
2^a+2^b=2^c となるには、a,b,cが正の整数なら
a=b、c=a+1になる時に限る。

つまり、Node_ID=-2^aはNode_ID=2^aとリンクをすることなる。
リンク数は結局n-1

＊Aノード群からBノード群へのリンク数
リンクで一番距離が長いのは2^(n-1)のときである。Node__ID=2^(n-1)=-2^(n-1)におけるリンク計算はBノード群からBノード群へのリンク計算に既に入っているので、ここでは考慮しなくてよい。

すると、計算で関係するのはNode_ID=2^(n-2)のときである。これよりNode_IDが小さいAノード群はBノード群まで距離が足りないからである。Node_ID=2^(n-2)は距離2^(n-1)でNode_ID=-2^(n-2)とリンクを張る。ところが、このリンクは前述のBノードからAノードへのリンク計算に既に加味されている。

結局、ノード間のリンクは3(n-1)となる。クラスタリンク係数はNode_ID=0からのリンク数が2n-1であることを考えて、

C=3(n+1)/[(2n-1)(2n-2)/2]=3/(2n-1)となる。

□Chordはスモールワールドか？

Cを見てもらうとわかるが、nが十分大きいとCはかなり小さくなる。つまりChordをスモールワールドと考えるのは難しい。Chordにスモールワールド性を取り入れたSymphonyについては同様に計算ができるはずだが、（積分計算が必要）面倒なので途中で計算を止めてしまった。興味のある方はチャレンジしてほしい。

□Pastryはスモールワールドか？

今回は具体的な計算を出さないが、適当な仮定をするとPastryのCは簡単に求まる。こちらもハッシュ空間が大きいとCが小さいという結果になる。興味のある方はチャレンジして欲しい。

□DHTとスモールワールドの関係
DHTとスモールワールドはどちらも平均ホップ数が小さい。今回わかったことはDHTだからといって、スモールワールドであるとは言えないことである。DHTがネットワーク的にどのようなネットワークに分類できるのか、グラフ論的に調査すると、きっと興味深い結論がでるだろう。

[P2P][DHT]第2回DHT勉強会のご案内

昨年、ＤＨＴオフ会を開きましたが今回は勉強会と名前を変え、規模も大きくして開催します！
また、参加者の方が発表できるセッションも設け、勉強会後には希望者懇親会を開く予定です。
ＤＨＴ関連有識者と交流できる貴重な機会ですので、興味のある方は是非とも参加をお願い致します。

今回のＤＨＴ勉強会の意図はＰ２Ｐ勉強会からＤＨＴ関連を一部切り離し、より突っ込んだ内容・議論の場を設けることです。

なお、第1回ＤＨＴオフ会の模様は下記をご覧下さい。
＃オフ会講演模様
http://muziyoshiz.jp/20050627.html
＃講演資料
http://d.hatena.ne.jp/KazuhiroKojima/20050628
http://homepage3.nifty.com/toremoro/study/study.html

＊＊＊＊＊＊＊＊＊＊＊＊
第2回ＤＨＴ勉強会概要：
＊＊＊＊＊＊＊＊＊＊＊＊

◇日時：9/18(月、祝）　10：00～15：00
◇場所：金沢工業大学　虎ノ門キャンパス（ほぼ決定）
◇定員：50人
◇参加費：1000円程度（調整中）
⇒講師のお足代等に充当します。

◇講師（調整中）

-首藤 一幸　氏 ：ウタゴエ(株) 取締役 最高技術責任者
「オーバレイ構築ツールキット Overlay Weaver (仮)」
⇒ご存知Overlay Weaverの開発者の方です。

-加藤　大志　氏：NEC
「プロトコルとして見たDHTの設計と実装 (仮)」
⇒P2P-Webの開発者の方です。

-西谷　智広:Tomo's Hotline
「DHTにおけるセキュリティ対策を考察する～DHTプラットフォームの信頼性向上にむけて（仮）」

※引き続き講演者の方を募集しています。自薦・他薦は問いません。
ご連絡先はtnishita@yahoo.co.jpです、

なお、最新情報はＭｉｘｉのＤＨＴコミュニティにて随時ご連絡致します。
Mixi ＤＨＴコミュニティ
http://mixi.jp/view_community.pl?id=128733

参加者の募集事項については後日周知します。

よろしくお願い致します。

[Winny][P2P]Winny事件で露呈したP2Pソフト開発の難しさ

やはり起きてしまったかといった感である。昨日例のWinnyのバグ発見報道である。

Winnyにバッファオーバーフローの脆弱性、回避策は「利用の中止」のみ

このバグ報道は起こるべきして起こったというしかない。それはP2P開発の難しさにある。それは何だろうか？

□ソフトウェア開発中止 ほぼイコール 利用すべきでないソフト

簡単に説明するために有償のソフトを購入した場合を考えてみる。基本的にはソフトにはサポート期間が決まっており、その範囲であればバグの修正、あるいは別途サポート費用を積むと障害時の切り分けをすることできる。
フリーソフトの場合、サポートの範囲はあいまいだ。

しかしながら、[一般的な暗黙の了解だと]ユーザサービスに影響に大きな影響が出た場合には開発者はバグ修正などに動くことだろう。もしそれができなければ、[その件についてはサポートできない]と宣言することになる。後者の場合、ユーザ側がリスクを取ることになる。当然ユーザはそのソフトを使うか他のソフトを使うか選択することになる。

私が言いたいのは、基本的にサポートされていないソフトで重大なリスクが発生した場合には、すぐにソフトの使用を中止すべきであることだ。例え重大なリスクが発生しない場合でも速やかに開発サポートがあるソフトに乗り換えるのが望ましい。

□Winnyならではの特殊事情

情報漏えい事件は金子氏の逮捕によりWinnyのサポートができなかったのが大きな要因であった。その時点で本来であればソフトの使用の中止または他のソフトの乗り換えをユーザ自身が判断すべきだった。
しかし、ユーザはそうしなかった。それはなぜか？大きく分けて２点考えられる。

[事情1]日本人がソフト、特にサポートに対する考えが甘い
[事情2]Winnyシステムとしてのの脆弱性（情報漏えい）を敢て楽しんでいた

事情１は日本人が今だソフトというのは、何にせよ誰かがサポートしてくれるという[淡い期待]をどこかで持っていることだ。例え深刻な事象が発生してもウィルス会社や有志、あるいは国がなんとかしてくれるのだろうと。
しかしながら、それは本質的な解ではない。サポートが切れた時点でそのソフトを本来使うべきでないという基本的な意識が、ユーザにはあまりないのではないだろうか？ITリテラシーに対する教育が広まっているが、ソフトのサポートについてもきっちりとした教育を受けさせるべきだと思う。

事情２はいうまでもないかもしれない。Antinnyによる情報漏えいを楽しむ初心者ユーザが被害者になる、いわゆるミイラ取りがミイラになる悪循環だ。

このようなソフトサポート切れによる重大なリスク発生は、今後も起こることだろう。
皆様はどのようなことをしたら、今回のような事件を防げると思うだろうか？私は本質的にはユーザのセキュリティ教育をきっちりと行うしかないと考えている。

□P2Pソフト開発はなぜ難しいのか？

これからが本題である。
P2Pソフトの開発は特にセキュリティ分野に比べて通常のソフトの開発とは比べ物にならないほど大変だ。
それはなぜか？
P2Pソフトを使ったことのある多くの人は次のようなことを意識したことがないかもしれない。

「P2Pソフトは時に応じてクライアントにもなるし、サーバにもなる！」

つまりP2Pソフトは基本的にサーバとほぼ同じようなセキュリティ対策をする必要があるのだ。

□P2Pソフトはサーバである！

P2Pソフトはサーバである、この意味について補足しよう。
通常のソフトは特定のサイトに対してアクセスを許可する。そのサイトというのは基本的にセキュリティ対策をしているので、通信をしてもそれほど被害が出るものでない。ソフト側でも対策ができる。
しかしP2Pソフトについては次のことを忘れてはならない。

「P2Pソフトは不特定多数から複数種類の通信を受け付けるサービスである。」

複数種類の通信とは例えばVoIPであったりIMであったり内容が違う通信を受けるということである。
つまり、複数の通信があれば、一つのP2Pソフトの中に複数のサーバが入っているのものとほぼ同様である。
P2Pソフトは一つの機能だけにセキュリティ対策をするのではなく、全機能にセキュリティ対策をすべきだ。

□Winnyのバグ発見が遅れた理由

さて今回のWinny事件に振り返ってみよう。どうしてバグ発見がこんなにも遅れたのか？
理由は主に2つあるだろう。

[理由１]仕様が完全にクローズドだった
[理由2]通信が暗号化されていた

暗号のメカニズムがわかった今、仕様についても解明が続くだろう。その際にはより大きなバグが報告されるに違いない。もしかするとそのバグをついた深刻な攻撃が行われる可能性がある。

このようなことを考えるといつも一つのことを頭に浮かぶ。仮にWinnyがオープンソースならどのような進化を遂げていたのだろか？

Winnyは技術的に興味深いシステムであった。もしWinnyがオープンソースであったら日本のP2P技術は格段に進歩していただろう。オープンソースであったらAntinny対策も誰かが行っていて、深刻な事態にはならなかったかもしれない。しかし逆により大きなバグがすぐに発見されていて、それを悪用された攻撃が行われたかもしれない。どちらに世界は動いていたのだろうか。

[P2P]Winny規制！？というかメール＋ＷＥＢだけの超低料金プロバイダがあってもいいんじゃない？

先日Blogに書いた[P2P][Winny]プロバイダがWinnyを規制する本当の思惑とは？は大きな反響を頂き、とても嬉しく思います。

さて、Blogでのコメントを一部紹介します。

■BlockCombさんのコメント
「Winny規制する代わりに、月額料金を値下げしてくれればいいですが…。」

Winny規制をすることによってトラフィックが大幅に減り、プロバイダのラーニングコストが下がるので、それをユーザ還元すればよいのでは？というアイデアである。まさにそのような意見が出ても良いと思っている。

今回はプロバイダの料金とサービスについて、このアイデアを基に議論を進めていくことにする。

なお、この記事は
ぷららの「Winny遮断」はISPの産業革命だ-ITProへのコメントでもある。

■特定のサービス通信の許可＝超定額インターネット接続サービス？

Ｗｉｎｎｙ規制を極端に考えると、

メール：STMP,POP3（それもプロバイダのメールサーバへのみ許可！）
Web：:http,https,DNS
ストリーミング関連（オプション、追加料金発生）

の通信だけユーザに許可するサービスがあっても良いと思う。ただし超低料金で。
なぜなら、この手の通信はほとんど帯域を消費しないし、それほど通信時間がかからないから。ストリーミングについては、議論の余地があるが。

この「スーパー規制プロバイダ」ではユーザはサーバになることはできず、P2Pすらできない。ユーザがインターネットへ出る通信（同プロバイダユーザ間の通信含む）は全てプロバイダのファイアウォール、それもステートフルインスペクション（ダイナミックパケットフィルタリング）で、「ユーザから要求する通信のみ可」となる。これはセキュリティ的にはかなり良いのでは？もうワーム対策もバッチリですよ。

これだけだとP2P対策は完全ではない。というのは最近のソフトは任意ポート（例えば80番で）ＮＡＴ越えができちゃうかもしれないので。
やっぱりP2P帯域管理装置か一定時間内の総パケット数をチェックしてで帯域を絞る装置が必要かな。
この「スーパー規制プロバイダ」ではＳｋｙｐe、インスタントメッセンジャー（一部）、オンラインゲーム（一部）はできなくなる。まあ、その辺は料金が料金なので。

ただし、日本の未来を考えるとちょっと不安だ。だってWebとメール以外の新たなサービスを使う時に大きな障害となるのだから。P2Pの新サービスが出現しても、このような規制プロバイダが出現するとサービスの展開が遅くなるかもしれない。

プロバイダの通信障害切り分けやクレームが大変かもしれないけども、プロバイダのインフラ的にはかなりコストかけずに済みそう。おまけにセキュアと聞いたら初心者はウハウハ来る可能性大。

プロバイダも差別化の時代なんだろうね。

そもそも、プロバイダさんはこのようにP2Pによって帯域があふれることは数年間では想定してなかったはず。5年前ならhttpによってファイルダウンロードするのがメインな通信だと思っていただろう。
実は現在のインターネットのネットワーク構造はP2P通信に向いてない。この辺は例のインフラ「ただ乗り」論にも関係するので、また今度書きます。

[P2P][Winny]プロバイダがWinnyを規制する本当の思惑とは？

AntinnyによるWinny経路の情報暴露が引き続き続いている。
Winny情報暴露されている個人情報を見たいために、初心者がWinnyを利用し、その利用者がAntinnyに感染して情報暴露されるという悪循環が起きているためだ。

上記の悪循環を絶やすためにはWinnyをアンインストールするということも叫ばれているが、そもそもの根本対策として、重要な情報については、厳重に管理することが挙げられるだろう。またWinny自体が悪いのではなく、Antinny自体が問題であることも、少しずつ認識されてきたと思う。

■Winnyトラフィック規制の難しさ

さて、プロバイダ側もWinny対策を本格的に検討し始めている。その対策はWinnyのトラフィックを規制することである。しかし、この対策は色々と問題があることを無印吉澤さんが既に指摘している。

無印吉澤：[P2P]ネットワーク技術の発展を阻害するのは警察か、それともISPか？

Winnyのトラフィックを規制することは一見正しいように見えるが、とても慎重にならないといけない。
例えば、オンラインゲームを利用していたユーザが突然作動が遅くなった場合、この原因がゲーム会社なのかプロバイダなのか障害切り分けが難しくなる。

つまり、Winnyのトラフィック規制をしたことにより、プロバイダ側が今まで以上に通信障害に対する切り分けをする必要がでるのである。その際には果たしてプロバイダ側がきちんと障害切り分けの対応・説明ができるのか、とても心配である。場合によってはゲーム会社は推奨プロバイダ等をマニュアルに明示する必要があるだろう。

プロバイダはWinny規制をする際に、今までの通信がうまくいかなくなる「かもしれない」リスクをきちんとユーザに説明し、もしそのような事象が発生した場合、きちんとプロバイダ側で対策することを明確に宣言する必要があるだろう。

■本当の「帯域規制」目的はWinny規制によるセキュリティ向上ではないかも！？

さてこれからが本題である。

今回Winny規制をするために、プロバイダはWinnyの帯域管理装置を導入することになる。この帯域管理装置は大型のファイアウォールみたいなものを想像すればよいだろう。
ただファイアウォール以上に帯域管理装置は高い。スループットによるが、数100万円～数1000万円する。

ここで一つ疑問が生ずる。このような値段が高い帯域管理装置を購入してプロバイダは果たして利益を上げることができるのか？答えは「◎」である。「○」ではなく。

そもそもプロバイダを通過する80パーセント以上のトラフィックはP2P、それもファイル共有によることが、色々な調査から判明している。仮に帯域管理装置を入れれば、今までの20%のトラフィックしかプロバイダに流れない事になる！これはプロバイダにとっては「おいしい」話である。

プロバイダは自分のネットワークを作るためにバックボーンと呼ばれる回線を調達する必要がある。この回線は基本的には他社から借りて、それも帯域見合いで価格が決まる場合が多い。そうなると、プロバイダを通る帯域が少なくなれば、プロバイダとしては利益を大幅に上げることができる。
それだけでなく、プロバイダは他のプロバイダへの通信の際に他のプロバイダへ通信費用を支払う場合がある。これもトラフィック見合いで費用が決まるので、コチラの費用も大幅減となる。

結論を言うと、帯域管理装置を入れればプロバイダを流れるトラフィックが大幅に減少して、その分プロバイダは利益を得ることになる。

それでは、なぜもっと早く帯域装置を入れてなかったのか？という話になる。実はこれにも事情がありそうだ。
確かに1年前以上からケーブルテレビ局等については回線費用削減のために帯域管理装置を入れていた。しかし大手のプロバイダは結局装置を入れなかった。この理由を推測するに、プロバイダ都合で帯域管理装置を入れることは、ユーザ説明がつかないと考えた事が挙げられる。

最初の章で書いたように、帯域管理装置を入れると様々なリスクがある。帯域管理装置をいれることは「Ｐ２Ｐトラフィックを削減して、回線費用を安くする」という「プロバイダのメリット」のためであり、それによってユーザがリスクを持つ事は説明しにくかったのだろう。しかしWinnyによる情報暴露というキーワードが最近出てきたために、プロバイダも堂々と「ユーザ」のために帯域規制をすると「説明できる」ことが可能になった。

もちろん、プロバイダがWinnyの情報暴露を防ぐために帯域管理装置を導入するという説明はよくわかる。このような装置を入れることで多くのユーザに対する「安心感」が増して、プロバイダ価値を上げることになるだろう。

しかし、プロバイダは

☆ユーザにとって、通信がうまく出来ない等リスクが発生する場合がある
☆帯域管理装置の導入は「ユーザメリット」のためであり、「プロバイダメリット」のためでない

ことを明確に説明する必要がある。そうしないと、今回Blogに書いた内容は多くの組織から繰り返し指摘される可能性がある。

個人的には、ユーザの希望者のみWinny規制をして欲しかったというのが本音である。それがユーザにとってもプロバイダにとっても一番納得する解決案であろう。

[P2P][DHT]ＤＨＴベースの新しいP2Pファイル共有ソフトを開発中です！

今日から4月です。今年度は私にとって仕事でもP2P関連でも大きく変わる年だと思います。
早速Ｐ２Ｐ関連の話ですが、DHT（分散ハッシュテーブル）ベースの新しいP2Pファイル共有ソフトを開発中なので、ここで紹介します。
なおＧＷ明け頃にはベータ版をお見せでききると思います。

そもそもＤＨＴベースのＰ２Ｐファイル共有ソフトを作ったきっかけですが、

・金子氏がＷｉｎｎｙにおいて「効率性」と「匿名性」を考慮していること。私は逆に「効率性」と「ある程度の匿名性」と「認証」を実現したい。
・Ａｎｔｉｎｎｙ対策を実施したい。

という2点があります。

それでは、現在開発中のファイル共有ソフトの内容について説明します。コメントは随時受け付けますのでよろしくお願い致します！

≪新しいファイル共有ソフト「Kenny」（開発コード）について≫

□PKIベースの認証を行います。PGPベースについては次期開発の予定です。

□最初に認証サーバから証明書の発行を受けます。DHTのNode_IDは証明書に記述されています。つまり証明書を提示した段階でNode_IDと証明書内のNode_IDが一致しなければ不正なノードということになります。
それ以降は、基本的に各ノードは認証サーバにアクセスしません。ＣＲＬについては認証サーバによって電子署名がされており、ＣＲＬはＤＨＴノードに対して分散して配置されます。

□DHTはノード負荷を考えてSymphonyを検討していますが、とりあえずはPastyで開発しています。Overlay Weaverで実装している最中です。

□ファイルは複数に断片化されます。ハッシュファイルが、その断片ファイル毎にどのノードにキャッシュするか記述されます。そのため、キャッシュされるノードは特定されます。
なお、キャッシュノードに対するアクセスが多くなった場合、キャッシュノードは近隣のノードへキャッシュを複製します。（これをレプリケーションノードと呼ぶ）。上記によってキャッシュダウンロードによる負荷を大幅に削減することを実施しています。

□ファイル共有は非匿名です。ファイルアップロードする際には、キャッシュノードがアップロード元のNode_IDを一定時間蓄積します。この際、アップロード元ノードは証明書をキャッシュノードに提示します。

□BBSは匿名モードと非匿名モードがあります。非匿名モードの場合にはスレッドを管理するノードに書き込み者は証明書を提示する必要があります。なおこの場合、後から自分の書いた書き込みを修正・削除が可能です。

□BBS匿名モードはP2P-Proxyによって匿名書き込みをします。ただし、一定時間Proxyノードに書き込んだIDをログとして蓄積します。これはスパムや嫌がらせ書き込み防止のためです。

□PKIによって様々な権限をユーザに委譲、破棄することが可能です。
具体的には
・スーパーユーザ（管理ユーザの管理をする）
・管理ユーザ（ファイル、キャッシュの削除、BBSの書き込みの削除をする。）
・一般ユーザ
となります。今後はさらに権限の細かい分割を検討しています。

□スーパーユーザはCAにCRLの発行依頼をすることで管理ユーザの権限を剥奪したり、特定の一般ユーザについて行動を制限することができます。

□ユーザがアップデートする際に
・文字数が異常に長いもの
・EXEファイル
はアップデートできません。ダウンロードもできません。
後々はヒューステリックソフトと連携して、ウィルス感染の可能性のあるファイルはアップデート・ダウンロードできないようにする予定です。

□ファイル名については形態素解析を利用する事で部分文字列検索ができるようになっています。ただし、検索効率を上げるために、ファイル名は現状25字までとしています。

□将来的にはＡＰＩを提供予定です。PKIを使うのでP2P-SNSや特定グループ内の掲示板等に活用できる事が考えられます。

２、3週間後にはベータ版テスターの募集を行いますのでよろしくお願い致します。

P.S.1.今日は4/1です。
P.S.2.といっても、このようなファイル共有の思想は悪くないと思う。本当の意味でファイル共有するのであれば、認証等が出来るシステムが必要だろう。

[P2P][DHT]第２回DHT（分散ハッシュテーブル）勉強会を開催します！

昨年、筑波大学でＤＨＴオフ会を主催しました。
私や産総研の小島さんがＤＨＴに関するプレゼンを行いました。
参加者は40人を超え、積極的に意見交流ができました。

※当日の様子やプレゼン資料は以下のページをご覧下さい。
http://muziyoshiz.jp/20050627.html
http://homepage3.nifty.com/toremoro/study/study.html
http://d.hatena.ne.jp/KazuhiroKojima/20050628

好評につき、今年は「ＤＨＴ勉強会」と名称もパワーアップして開催します。

講師陣と講演内容は現在調整中です。
また講師は随時募集です。自薦、他薦は問いません。
私もDHT-VPNかセキュリティの話で講演する予定です。

なお開催日時は5月～7月の土または日、会場は現在調整中です。

□募集していること
・協力して頂くスタッフの方
・５０名程度が収容できる場所を提供して頂ける方
・講師陣を推薦あるいは紹介して頂ける方

皆様のご協力の程、よろしくお願い致します！

＜関連＞
DHT勉強会準備トピック（Mixi)

[Skype]Skypeの本質は多対多VPN

SkypeはVoIPとしてとても有名なシステムだが、その本質は多対多VPNだと考えている。
Skype自体はセキュアなVPNインフラであって、その上に対してVoIP,チャット,データ等どのようなものでも流通してもよいのである。SkypeがAPIを提供してから、私はますますそのような見方が強まってきた。

多対多VPNを多くの人に提供するのは、コスト面やスケーラビリティからサーバ＝クライアント方式では厳しい。ということで、P2Pシステムを採用したと推測できる。もちろん、NAT越えなどユーザを意識したシステム作りもシステム的には興味があるのだが、本質的にはVPNサービスであることを忘れてはならない。
このように書くとSkype社がSkypeをインフラと強調している理由がわかるだろう。

Skypeの戦略はコンタクトリストを武器にして、相手に対するコネクティビリティ（接続性）をぎっちり握ってしまうことである。Skype APIを使えば相手と連携するシステムが簡単に構築できる。ただし接続するには相手とコンタクトリストを共有する必要がある。これはとても重要な意味がある。

例えばメールアドレスがあれば、他人とメールすることができる。つまりコネクティビリティはメールアドレスを保持すれば有することができる。このメールアドレスは各ISPが払い出す。

しかしSkypeやSkype APIを使ったシステムはSkypeが完全にコンタクトリストを管理していることに注意してほしい。Skypeはコンタクトリストを利用してユーザに対する様々な分析やそれを使った広告ビジネス等を展開できる可能性がある。

話を少しずらしてWeb2.0のことについて考えてみよう。Googleはインターネットというオープンな世界をうまく利用して情報共有という企業メリットを生かしてWeb2.0の覇者になった。ではWeb2.0の後の展開は何だろうか？個人的には個々があらゆるサービスを「ある特定の人」と共有することと考えている。つまり完全なオープンでなく、半クローズドな世界である。これはSNSの世界に近い。
このような世界を仮にWeb3.0とすると、それを今実現できるのはSkypeだ。Skype APIを使えばどのようなサービスも基本的には「知人」と共有することができる。

このようなことをMixiの日記に書いたら、マイミクの方から意見を頂いた。
それはWeb3.0の世界はなんらかのIDを元にすべてのサービスのコネクティビリティを保証する時代がくるのでは？ということである。IDを使ってメール、チャット、ファイル共有、あるいはWordやExcelなどのアプリケーションの同時共有などが「特定の人と」できるのである。

このような概念はP2Pの世界で言う分散ハッシュテーブル（DHT)の思想にかなり近い。
ただし通常のDHTとSkypeで違うのは
□Skypeは知人同士でしかコネクティビリティがない。
□DHTはどんな人ともコネクティビリティが可能。

ということである。もちろんDHTがSkypeのようなコネクティビリティを実装することは可能だ。
SkypeとDHTのどちらがWeb3.0の覇者になるのか、まだ私には見えない。ただし、オープンな世界とクローズドの世界というのは、交互に現れるものだから、今度はSkypeのような知人だけにしかコネクティビリティがないシステムのほうが人気が出るかもしれない。

[P2P]P2Pインフラ研究会～「Winnyの技術」著者 金子勇氏講演 ～その2

前回はWinny1とWinny2について金子氏の講演を紹介したが、今回はWinnyの将来
ビジョンについて取り上げたい。

前回の記事：
http://toremoro.tea-nifty.com/tomos_hotline/2006/02/p2pp2pwinny_f793.html

金子氏は、Winnyの課題として

[課題1]オープンソース化が可能か？
[課題２]Ｗｉｎｎｙ(というかP2P-NW)を管理する事は可能か？

の2点を取り上げた。

まずは課題１からである。

Winnyは金子氏の方針でオープンソース化をすることはしなかった。
ところが、効率性がウリのBittorentや匿名性が特徴であるFreenetはどちらも
オープンソース化している。

Ｗｉｎｎｙをオープンソース化できないのは訳がある。
というのは、Winnyは効率性を保ちながらも匿名性を「ある程度」担保できる、
いわゆる「効率性」且つ「匿名性」と追求したシステムなのである。

仮に効率性を高めると匿名性は低下するし、匿名性を高めれば逆に効率性を低下
させることになる。

Winnyがオープンソースになれば、ユーザによっては「自分の都合の良い」ノー
ドに仕立てて、システムに悪影響がでることが懸念される。

しかしながら金子氏は、BittorentとＦｒｅｅｎｅｔがオープンソース化されて
いる今、いずれは効率性と匿名性が両立するシステムがオープンソース化される
事はあるだろうと述べている。

ただし、講演ではオープンソース化することによって、例えば自分都合の良い
ノードが多くなり、効率性と匿名性のバランスが崩れるのではないか？という問
いに対して明確な答えを出していない。

本当にオープンソースにして、（ほぼ）対立する「効率性」と「匿名性」が両立
するかは個人的にはとても興味がある問題である。一つの解としては、ある部分
だけブラックボックス化して、そこに対してＡＰＩを自由に提供するという事が
考えられる。

次に課題の2番目である「管理性」である。

この管理性についてはPure-P2Pが登場してから何度も問題になってきた。残念な
がら未だに根本的な解決策は現状なさそうだ。
金子氏は講演において、P2P-NWを管理することは可能であると述べた。またそれ
に対するアイデアも「あるらしい」が明確な答えはなかった。

管理性については、色々な考えがあるだろう。
一つは、ＰＧＰ、あるいはＰＫＩ的な手法を電子署名を組み合わせう方法である。

例えば、Ｗｉｎｎｙのネットワークに対して、管理者があるＫｅｙを流通させる
と、その中にあるコマンドが実行されることが考えられる。なおそのＫeyには電
子署名がされており、管理者が発行したＫｅｙのみ各ノードが実行出来る事が考
えられる。

他案として、あるユーザだけ特権を与える事ができるだろう。ただし、ある特権
を与えたユーザの特権を失効させるには難しい。一つの方法として、ある時間内
だけにその特権が行使できる等を使うと面白いだろう。（またはある管理者から
Ｎホップまで離れたノードまでに管理を与える等）

この特権は階層的になっていて、ソフト製作者は全特権が与えられ、ある特権は
他のユーザに譲渡できる等が考えられる。ＤＨＴを使えば、ハッシュ値と特権が
関連付けられ、うまくシステムとして作動するかもしれない。

金子氏の講演は以上である。個人的には、「今ならＤＨＴを使っていたかもしれ
ないが、Ｗｉｎｎｙ１のシステムで検索システムとしては充分だと考えてい
る」、との発言が印象的であった。

なお、この後パネラーによる講演が続くのだが、この内容はまた次回に書きます。

[P2P]P2Pインフラ研究会～「Winnyの技術」著者 金子勇氏講演 ～その１

先月１/28（土）に注目すべきイベントがあった。
P2Pインフラ研究会にて「Winnyの技術」金子氏の講演会があったからである。
今回はその模様を簡単に書いておきたい。

なお講演模様はＩＴmediaで既に取り上げられているので参考にして頂きたい。
http://www.itmedia.co.jp/news/articles/0601/30/news047.html

金子氏の講演は
◇Ｗｉｎｎｙの技術面
　-Winny1 ファイル共有システムとして
-Winny2 大規模ＢＢＳシステムとして
◇Ｗｉｎｎｙの将来性

と構成されていた。

Winny1については金子氏の著作「Ｗｉｎｎｙの技術」と同じ内容なので割愛したい。
ただし、面白い話として、
「自動ダウンロード機能をつけたことで、多くのノードが長時間Ｗｉｎｎｙネットワークに接続された」が挙げられる。
つまりＷｉｎｎｙの成功というのは参加者数のアップだけでなく、いかに同時に多くのノードが接続されるか（それもできるだけ長時間接続で）というのが重要なキーであったのだ。
Ｐ２Ｐシステムでノードが長時間接続される工夫は、他のシステムでも必要であろう。
（例えばＳｋｙｐｅがその成功例の一つである。）

次にＷｉｎｎｙ２である。
Ｗｉｎｎｙ２はそもそも大規模Ｐ２Ｐ-BBSの検証のために開発された。結局現時点ではベータバージョンで終わっている。
金子氏はWinny1でファイル共有ではほとんどのことをやりつくしたと語っていた。つまりＷｉｎｎｙ２はＢＢＳ開発に注力を注いでいた事になる。

ここでＢＢＳの仕組みを書いておこう。これは「Ｗｉｎｎｙの技術」には書いてない。

・スレッドは一つのファイルで成り立つ。
・1つのスレッドは1つのノードで管理される。（これを管理ノードと定義しよう）
（私もP2P-ＢＢＳを検討したことがあったが、第2世代Ｐ２Ｐシステムで複数ノードで管理するとファイルの内容のアンマッチがありとても大変！http://homepage3.nifty.com/toremoro/p2p/bbs1.html
ちなみにＤＨＴを使うと簡単にスレッドを管理させることが可能。）
・スレッドはＷｉｎｎｙ１のファイルダウンロードのように拡散。
・書き込むときには、あるノードを介してから必ず管理ノードに書き込む。
・上記のお陰で匿名性をある程度担保しているが、実はノードが検索ボタンを連打すると管理ノードに直接繋がるというバグで、匿名性は実は実現できない場合があったりする。
⇒ということはファイルアップロードをＷｉｎｎｙ掲示板で宣言した多くの人が逮捕される可能性がある？

「Ｗｉｎｎｙの将来性」やパネルディスカッションについては次回書きます。

[P2P][DHT]Pastry入門～その１

今回から数回に渡りＤＨＴでとても有名な方法である「Pastry」について紹介します。
なるべく分かりやすく書くために、部分的には不適切な記述があるかもしれません。そのため、詳細については原論文を見ると良いでしょう。

原論文
Pastry:Scalable,decentralized lbject location and routing for large-scale peer-to-peer systems
http://research.microsoft.com/~antr/PAST/pastry.pdf

Pastryと何か？

PastryはChordやKademliaと並んで著名なＤＨＴシステムです。
ChordがSkiplistと呼ばれるショートカット的なアプローチをするのに対してPastryはPlaxtonアルゴリズムを使って特定のノードへすばやく到達できるように工夫しています。なおＴａｐｅｓｔｒｙもPlaxtonアルゴリズムを使っているのでPastryをチェックした後にTapestryの論文を読むと理解が深まるでしょう。

Pastryを使ってPAST（分散ストレージ）等のアプリケーションが考えられています。詳細は下記のページをご覧下さい。
http://research.microsoft.com/~antr/Pastry/default.htm

Pastryのノード検索の仕方

ＤＨＴで一番重要なのはノードの検索の方法です。どのような方法なのか、ざっくり書いてみます。
ルーティングテーブル等の詳細は後日紹介します。

Pastryでは2のＮ乗でルーティングテーブルを構築し検索を行います。しかし、これだと分かりにくいので、とりあえず10進法にして「イメージ」を掴んで下さい。

今、ID_A=19325というノードがあります。これがID_Z=233521と通信するにはどうすればよいのでしょうか？

Plaxtonアルゴリズムはとてもユニークな方法でこの通信を可能にします。

まずＩD_A=193245は自分の知っているノードでID=2xxxxxと言うノードを探します。(xは任意の数字）つまり、ID_Aのノードの中でID_Zの「一番上の数字」が同じノードを探すのです。
今、ID_AがID_B1=282539を知っていたとします。すると今度はID_B1がID=23xxxxとなるノードを探す事になります。
これは、ＩＤ_Zで「一番上と2番目が同じ数字」のノードを探す事になります。

つまり、
（1回目の検索）ID_B1=2xxxxx　（例えば214256)
（2回目の検索）ID_B2=23xxxx (例えば234623)
（3回目の検索）ID_B3=233xxx (例えば233901)
（4回目の検索）ID_B4=2335xx (例えば233591)
（5回目の検索）ID_B5=23352x （例えば233527)
（6回目の検索）ID_B6=233521=ID_Z
ということで、IDの桁数と同じ数で検索が可能でした。ですから、Pastryも大体Log(N)のオーダーで検索が可能である事が分かります。

しかしながら、今回のように6回でうまく検索できるとは限りません。Pastryは色々な工夫をしていて、できるだけ早く目的のノードへ到達しようと努力します。

ざっくりとルーティングの方法を書くと
(STEP1)目的のノードのIDに近づくようにＩＤの数字を上記方法で近づけていく。
(STEP2)ある程度目的ノードに近づいたら、自分の近くのノードの場所を記憶している表(これをLeaf setと呼ぶ）を使って、目的ノードに近いノードへジャンプする。

の2種類でどんどん目的ノードへ近づくことになります。

次回はルーティングテーブル等を実際見ながら、どのような方法でルーティングが行われているか見てみましょう。

[P2P]P2P新年会無事終了！

昨日（1/20[金])東京オペラシティでP2P新年会が盛大に行われました。
最終的には30人を超える人が参加して盛り上がりました。
Mixi-P2P新年会トピック
http://mixi.jp/view_event.pl?id=3318592

久しく会ってない方も何人も居たので、近況等を話し合っていたり、またP2Pのコアな話もしました。

実を言うと開始時間の7時ちょっと過ぎまでほとんど人が集まらなかったので、「まずい、キャンセル者続出で主催者は大赤字覚悟か？」とブルブルモードでしたが、その後続々と参加者が会場に来て頂きとてもほっとしました。

2次会は、当初の予定では10人ぐらい参加かと思ったのですが、ふたを開けると20人ぐらいの方が参加希望でした。
とりあえず近くのおいしい中華料理屋さんに行ったのですが、残念ながら15人ぐらいしか入れないとの事。

仕方がないので、そのほとんどが一旦東京オペラシティに戻ってファミレス（ＣＡＳＡ）でケーキセット＋ドリンクバーでまったりとしていました。
夜9時半のファミレスに男性16人がどかっとテーブル1列を占拠するのは、なかなか豪快な眺めでした。（笑）

個人的には2次会の方がコアな話ができて楽しかったです。
（1次会は参加費の集計や司会進行をしないといけなかったのでなかなかゆっくりと話せなかったので。）
P2Pの将来ビジョンや現在のゲームにおけるP2P通信の工夫の仕方など、とても貴重な情報でした。

次回のP2P勉強会は9月ごろ某山手線エリアの大学で行いたいと思います。こちらも是非参加して下さい！

またスタッフの方、手伝って頂きありがとうございました。とても感謝しています。

[P2P]P2P(DHT)ソフト開発＋シミュレーションが簡単にできるミドルウェア「Overlay Weaver」誕生！

今年は1月からP2P業界にとってビッグニュースです！
その前にP2Pについてちょっとした話を。

P2Pといえば、昔はGnutellaのようなUnstructure-P2Pソフトしかありませんでしたが、最近ではＤＨＴと呼ばれる Structure-P2Pの研究が流行しています。私のＢｌｏｇやHPでもＳｔｒｕｃｔｕｒｅ-P2Pのトピックを盛ん
に取り上げています。

ではUnStructure-P2PとＳｔｒｕｃｔｕｒｅ-P2Pの違いとは？というと、UnStructure-P2Pは構造が単純化しているためソフトが作りやすい反面、期待していた検索結果はうまく帰ってこない等のデメリットがあります。

Structure-P2Pはこのデメリットは解消しているのですが、その反面実装がとても複雑でソフトが作りにくいことがデメリットとして挙げられます。

そこで登場したのが簡単にＤＨＴソフト（つまりStructure-P2Pアプリケーション）が開発できるキットです。というよりも寧ろＰ２Ｐミドルウェア＋開発キットといえばよいでしょうか。その名は「Overlay Weaver」！！

産総研の首藤さんたちが開発したもので、今週リリースされたばかりです。

開発する人はＤＨＴのことは気にせず、提供されているＡＰＩを使えば簡単に
Ｐ２Ｐソフトができます。これを応用すればP2P-VoIPやＩＭ、ＶＰＮが簡単に作成できるでしょう。
またＤＨＴとして開発者はChordやPastry,Kademlia等を指定して実行できます。つまりどのＤＨＴがそのソフトに最適か検討することができるのです。これはスゴイですね～。またＤＨＴのアルゴリズムの追加も簡単に実装できるような仕組みを用意しているようです。

もうひとつこのソフトがすごいのは、1台で数１０００ノードのP2P動作シミュレーションが可能なこと。さらに複数ノードでのシミュレーションも可能です。さらにどのノードがどのノードとリンクしているか簡単に図示することが可能です。公式ページにはその様子がスクリーンショットとして掲載されています。

今年はこのミドルウェアでＰ２Ｐソフトを作るという動きがホットトピックとして挙げれそうです。あるコミュニティではこのミドルウェアを使ったＤＨＴソフトのコンテストを実施しよう！と考えているようです。面白いですね～

SkypeもＡ２Ａを使ってP2Pソフトを作れますが、利用に制限があります。（例えばコンタクトリストに居る人としか通信できない等）
このミドルウェアは利用制限がないので、いろんなソフトができそうですね。また日本発のミドルウェアなので、ミドルウェア開発者からユーザへのフィードバックが早いことも期待できます。

詳しくはこちら。
オーバレイ構築ツールキット Overlay Weaver
http://overlayweaver.sf.net/index-j.html

後でより詳細なレビューを書くつもりです。

[P2P]SkypeInのセミナー

2/3(金）にSkype社の岩田さんやVincentさんが出席するセミナーがあります。
私も参加する予定です。講演概要から見ると番号問題の話やFusionの人の講演もあってかなりイイ感じです。
ただし、参加費用は1名\49,800-ですが。。。

日　時：平成18年２月３日 (金)　10時00分～16時35分
会　場：アイビーホール 青学会館(青山学院大学横）

マルチメディア推進フォーラム
｢インターネット転送の実現に向けたボイスサービス最前線」
http://www.ahri.co.jp/business/seminar/information/060203.html

以下、講演概要抜粋を上記サイトから引用：

「我が国の電気通信番号の現状」

* 電気通信番号の現状
* 番号研究会における検討状況
－ＦＭＣの電気通信番号－
－インターネット電話への転送－
* その他(ＭＮＰ、ＥＮＵＭ)

総務省　総合通信基盤局　電気通信事業部　電気通信技術システム課　番号企画室長　門馬　弘氏

「普及拡大するSkypeのサービス」

* Skypeが切り開くP2Pサービスの現状
* Skypeのサービス変遷
* 諸外国におけるサービス状況
* Skypeが進める更なるサービス戦略
－新サービス－
－エンタープライズユース－
－家電、セルラー、その他機器へのエンベデッド－
* Skypeのエコシステム
－Skype Public API の無償公開によるパートナー戦略－
－Skype Certification Program－
* 単なる音声アプリケーションではないSkype
－プロジェクトツール－
－ビジネスアプリケーション連携－
－Webとの統合－
－プラットフォームの開放と今後－

Skype Technologies S.A.　日本ビジネス開発部長　Vincent Shortino 氏
Skype Technologies S.A.　Developer Relations　岩田　真一氏

「フュージョンのskypeとの融合戦略」

* 日本で開始された、skype inサービスとは
* 一般着信をインターネット転送する上での仕組み
* インターネット伝送するための様々な課題と解決方法
* 既存VoIPサービスとのミックスアンドマッチによる新たな顧客獲得戦略

フュージョン・コミュニケーションズ㈱　ＩＰ商品開発部　担当課長　鶴田　光則氏

[P2P]情報共有（P2P)研究会

日本情報処理開発協会主催で情報共有(P2P)研究会を行うとのことです。
1/13(金）の夜開催でしかも無料（100人収容）です。
お時間のある方は是非。私も参加予定です。

以下、JＸＴＡのＭＬに流れた案内文から引用：

＝＝＝

情報共有(P2P)研究会

会 費：無料(社会人、学生を問わず)
日　　時：2006年1月13日(金) 18:00～20:00
会　　場：機械振興会館　東京都港区芝公園3-5-8
http://www.jspmi.or.jp/map/mapright.htm
内　　容：
Javaで著名な丸山先生によるコミュニケーション論やP2Pへの期待について、独自の考察を交えながらお話しして頂ける予定です。
また、最新のP2Pの技術動向を、P2Pの最先端の研究をされている産業技術総合研究所グリッド研究センターの著名な研究者である首藤一幸氏が、基礎知識から、P2Pなネットワーク形態を概観し、最新技術動向と今後の可能性までをわかりやすく解説して頂ける予定です。

稚内北星学園大学
学長 丸山不二夫 氏
「情報の共有とコミュニケーション」
- ネットワーク技術の与えた影響とこれからのP2Pへの期待 -

産業技術総合研究所 グリッド研究センター
首藤 一幸 氏
「unstructured overlay と structured overlay」
- 基礎知識からP2Pなネットワーク形態と研究・応用の両面から論じます -

お申込み方法：
P2P@rd.jipdec.jpまでメールにて申込みをお願いします。

お問い合わせ：（財）日本情報処理開発協会開発部業務課
e-mail：P2P at rd.jipdec.jp

[P2P]Mixi-P2Pコミュニティ新年会の開催日を変更します

先日お伝えしたP2Pコミュニティ新年会ですが、開催日を一週間遅らせます。

□日時：2006年1月20日（金）19：00～21：00
□場所：新宿界隈某所（参加者の方には事前に連絡します。）
□会費：4000円（当日受付にて頂きます。飲み放題です。）

なお現在20名程の方が参加表明をしています。P2P界隈の方とコネクションができる良い機会ですので是非参加してみて下さい！

参加表明は
http://mixi.jp/view_event.pl?id=3318592&comm_id=6936
まで。
1/13(金）まで募集予定ですが、とりあえず参加表明して前々日までにキャンセルすることはＯＫです。
皆様の参加を心よりお待ちしています！

P.S.Ｍｉｘｉ会員でないけども参加したい！と言う方は私までメールにてご連絡をお願い致します。
メールはtnishita@yahoo.co.jpまで。

[Skype]Skype API 資料

Skype APIについては日本語ベースで情報源がまとまってない状態なので、簡単
なリストを作ってみました。

「APIを使えばSkypeにより便利な機能を拡張できます」pdf
http://skypejournal.com/downloads/2005/001/SJ200500101jp_WorkingWithTheSkypeAPI.pdf

「Skype APIとその使い方」pdf
http://share.skype.com/media/1.2_api_doc_jp.pdf

「API reference Skype API 1.4」
http://share.skype.com/developer_zone/documentation/api_reference

「Introduction to the skype API」Video
http://share.skype.com/directory/introduction_to_the_skype_api/view/

「Training Chanell」Video
http://share.skype.com/directory/training_channel/

「Skype Public API Forum」
http://forum.skype.com/viewforum.php?f=16

「Skypeはどこに行く？」インタビュー記事
http://itpro.nikkeibp.co.jp/article/DENWA/20051026/223477/?ST=denwa_print
⇒Skype社岩田様へのインタビュー記事。課金用APIを提供することを明言しています！

※岩田様、「P2Pがわかる本」のレビュー、もう少々お待ち下さい。。。

[Skype]Skypeがインフラに近づく日～その１ SkypeWebGateway

ソフトフォンのSkypeは特定メンバによるチャットが可能である。
これを旨く使えばプライベートな掲示版を作成することができる。私もこのようなプライベートな掲示版は良く活用
しており、Skype Conference 2005を調整するときにも愛用した。

ところで、Skypeに近い人＋Skypeに注目している人の中では、このプライベートな掲示版を利用して、幅広い意見交換を行っている。私もその参加メンバである。

その掲示版の議論の中で提唱されたのが今回紹介する日本発の技術、SkypeWebGateWayである。概要を簡単に説明しよう。

そもそもSkypeは複数メンバ間でのチャットやVoIPを行うためのソフトである。
最近ではVideoチャットが出来る事でも話題になった。

Skype社は今年の9月からA2A APIをSkypeに加えた。
これは Application to Applicationの略で、Skypeを使ってユーザ間通信＋アプリケーション連携をしてしまおうというものである。

もう少し噛み砕くと、通常ユーザ間通信はHTTPやHTTPS等を使って制御する必要がある。しかし、このようなレイヤの通信をプログラマーが１から実装するのは大変だ。特にNAT越えの処理は厄介である。
しかしSkypeのA2A　APIを使うと、もはや通信の実装を意識する必要がない。
つまり、通信路の制御はSkypeが行うので、プログラマが行うのはアプリケーションの開発と、Skype経由でどのデータを伝送するかということになる。

このA2Aにより、ユーザ間でオセロを行うようなゲームが既にリリースしている。

http://forum.skype.com/viewtopic.php?t=35337&sid=3c7437a7a5a36490229122de755b1182

さてこのA2Aのような概念を拡張すると面白い事ができる。

通常、Skypeは人と人とのコミュニケーションを行うものである。
ではSkypeのチャットにA2A APIを使ってサーバを参加させたらどうなるだろうか？

例えば、Skypeのチャット内容をA2Aを使って翻訳サーバに通信させて、サーバはSkypeを通してチャット参加者に翻訳内容を返答したら。。
ユーザは言葉の壁を越えてコミュニケーションをすることができるようになるだろう！

ただこの方法は欠点がある。
翻訳サーバを1から構築するのは大変なことである。ところがWebサーバベースの翻訳サイトは色々とある。
ということは、Skypeに参加させるサーバとして通常のWebサーバベースの翻訳サーバを使えばよい事に気が付く。つまり、チャット内容をWebサーバに伝える方さえあれば、誰もが簡単に翻訳機能付きチャットができる。

実はこのようなAPIが既に発表されている。これがSkypeWebGatewayである。
（※SkypeWebGatewayはA2A APIを使用していません。）　

http://forum.skype.com/viewtopic.php?t=40519&sid=3c7437a7a5a36490229122de755b1182

SkypeWebGatewayを使えば、ユーザは容易にWebサービスを利用できる事ができる。例えば、郵便番号検索、あるいは天気予報。。。将来は VoIPベースで翻訳するサービスも可能だろう。

今後はSkypeのサードパーティ等はA2AやSkypeWebGateWayを使ったアプリケーション、サービスを大量に生み出すだろう。そのことがSkype成長の大きな力になる。

ただ欠点がないわけではない。
それはSkypeWebGatewayで通信を行うサーバ側（つまりサービス提供者側）にメリットがないことである。
上記を改善するためには例えばSkypeに返答する文章の後に広告メッセージを付加させる、あるいは特定の有償サポートのユーザだけにプレミアムサービスを提供するということが考えられるだろう。

[Skype]Skypeがインフラになる日[メモ]

今後のSkype関連の連載のためのメモ。

第1世代：人と人とのコミュニケーションとしてのSkype（1対１）
VoIP、Video通話、チャット
第2世代：人と複数人とのコミュニケーションとしてのSkype(多対多）
VoIP,Video通話、チャット（Conference機能）
第3世代：複数人と複数人＋サーバとのコミュニケーションとしてのSkype(A2Aを活用）
チャットを自動的に日⇒英語等に翻訳、天気予報等の情報をコマンドラインからチャットに出力
（最近話題のSkypeWebGatewayの例)[現時点]
ただし、サーバは人間のコミュニケーションを「サポート」するレベルに留まる
第4世代：インフラとしてのSkype
方向性としては大きく３つ。
[1]サーバ間通信をA2Aで活用
[2]人とサーバのシームレスな連携
[3]アプリケーションサービス課金としてのSkype

[1]の例：分散システムをskypeで統合。低レイヤの通信はすべてがSkypeに任せ、当然NAT等の作りこみや最適なNWを判断する方法を意識する必要はなくなる。プログラマも簡単に分散ネットワークシステムを構築可能。
ただし、ネットワークエンジニアにとっては必ずしも幸福ではない？（自分でネットワークを管理できない。）
[2]の例：会話をサーバが自動的に解析し、それを元に各種データがチャットやVoIPで出力。コミュニケーションとしてサーバが「バーチャルな人」として存在するようになる。
[3]全てのアプリケーションサービスがSkypeで課金をするシステム。Skypeは課金APIだけを「信頼されたソフトウェア」あるいは「企業」に提供

[P2P]Mixi P2Pコミュニティ新年会

P2Pオフ会が開かれて大分経っているので新年会を開きたいと考えています。

≪P2Pコミュ新年会概要≫
□日時　2006年1月13日（金）　19：00～21：00
□場所　新宿近辺
（詳細は参加者の方にご連絡します。）
□会費　4000円
※立食パーティで飲み放題です。

P2P界隈の方が一同に集まるイベントです。是非参加して下さい！

なお、参加応募はMixi経由限定です。下記のURLから申込みをお願いします☆
http://mixi.jp/view_event.pl?id=3318592&comm_id=6936

新年会の詳細内容については参加者の方にメールします。

[DHT]DHT（分散ハッシュテーブル）ショートクイズ３

好評を頂いているDHTショートクイズですが、
「現在DHTを勉強中なので答えの公表は待って！」
という声を何人かから頂きましたので、年末年始あたりに
答えを公表したいと思います。皆さんも是非考えてみてくださいね。

さて、今回はNAT処理について考えてみます。

クイズ４：NAT処理（その１）

ある通信企業がDHTによってSNSを構築しようと考えている。
参加したいユーザは通信企業のWeｂサーバを経由してソフトをダウンロードできる。
またソフトの初回起動時にユーザ登録をする必要がある他、
ソフト自体が定期的にバージョンアップを自動的に行う。
ソフト利用条件としてブロードバンドの回線速度とOS、PCスペック等があるが、通常のファイアウォールやルータ環境下でも使用できるように設計したいと考えている。

A君は通信企業に働く研究者であり、評価版について作成している。
NAT環境でもこのソフトが動くために、プライベートアドレスのPC_AはグローバルアドレスのPC_B、1台と常にTCP接続をさせることにした。

4-1:
今、PC_AがグローバルアドレスのPC_Cと通信したいとする。
その時にはこのように動作するように設計した。
フェーズ１：PC_AがPC_BにPC_Cとの接続要求をする
フェーズ２：PC_BがPC_CのIPアドレスをDHTを使って取得する
フェーズ３：PC_BがPC_AにPC_CのIPアドレスを回答する
フェーズ４：PC_AがPC_CとTCPで接続、リンク確立

逆にPC_CがPC_Aと接続する時にはどのようなフェーズがあるか答えて下さい。
上記の作動フェーズとの違いを特に明確にして下さい。

4-2:
PC_AがPC_Cに通信する場合、４-１でのフェーズだけでは、セキュアな通信はできない。
どうしてセキュアな通信ができないか問題点を抽出してセキュアな通信ができるように設計を行って下さい。
またA君はこれを解決する方法としてIPSecを使おうと考えましが、上司からIPSecの使用は止めた方が良いといわれました。それはどうしてでしょうか？

4-3:
今、プライベードアドレスノードPC_AとPC_Dが通信するために、PC_A ⇔　PC_B ⇔ PC_C ⇔ PC_Dとするように設計を行った。いずれもTCP通信である。ただし、PC_BとPC_Cはグローバルアドレスのノードである。

状況を単純化にするためPC_AはPC_Bと一度接続したら、PC_BがDHTから抜けるまでPC_Bと接続することとする。PC_DとPC_Cの関係も同様である。

今、PC_BとPC_CのようなグローバルアドレスノードがDHTから離脱しないことを考える。（グローバルアドレスノードのDHTへの新規参入はありうる）

この時にPC_A、Dのような任意のプライベートアドレスノード間と通信するには、どのような設計なら実現できそうでしょか？DHTを使いどのノードがどのようなデータを保持するか等の設計の概案を書いてください。

なお、プライベードアドレスのノードはシステムからの参加、離脱はあり得えます。
グローバルアドレスノードのIPは参加者によって自発的にWEB等で公開されています。
（条件としてプライベードアドレスノードはDHTに参加させても参加させなくても良いとします。どちらにするかは回答者の皆様にお任せします。）

[P2P]DHT（分散ハッシュテーブル）ショートクイズ2

私も妻も風邪で体調が悪いです。今日は社宅でゆっくりしていました。皆様も風邪には気をつけてくださいね。
さてDHTショートクイズの第２弾です。（第１弾クイズの回答は後日ということで。。。）
皆様コメント欄あるいはトラックバックで奮って御回答をお願い致します。

クイズ３：DHT（分散ハッシュテーブル）に参加しているノード数の推定

3-1:DHTに参加しているノード数をおおざっぱに推定したい。
今、DHTとしてPastryを使っている。自ノードの情報だけでPastryに参加しているノード数を推定するにはどうすればよいか？

3-2:DHTとしてChordを使用している場合は自ノードだけの情報では参加ノード数を推定するのはキツイ。
そこでChordの実装に「簡単に手を」をいれることで参加ノード数を容易に推定できるようにしたい。
あなたなら、どのような実装をしますか？
※自ノードだけの情報に頼る必要はない。他ノードと通信をしてもOKとする。

[P2P]DHT（分散ハッシュテーブル）ショートクイズ

これから不定期にP2P関するクイズを出します。
皆さんで考えてみてね。
（コメント等で回答を寄せて頂けるとありがたいです。）

クイズ１：
DHT（分散ハッシュ）でハッシュ関数hash_Aを使用していた。
しかし、ハッシュ関数hash_Aが不完全で、異なる数字y,zに対してhash_A(y)=hash_A(z)になる場合があることがわかった。
この時にDHT系全体としてどのような問題が生ずるだろうか？

クイズ２：
ノードAの名前をA_nameとする。
ノードAの保持するハッシュ値（hash_IDとしよう）を完全なハッシュ関数hash(）を使って
hash_ID=hash(name)
で定義する時、しばしばDHT系として不具合が生じる可能性がある。それはどうしてか？
またそれを回避する方法を考えて下さい。ただし、回避方法としてなるべくnameを活用して欲しい。

ここで言う完全なハッシュ関数とは異なる数字y,zの時にhash(y)とhash(z)が異なる事を指す。

さて皆さんはどのように考えるでしょか？
（P2Pの講義があったら大学のレポートに出されそうだなぁ。。。）

[P2P]P2P入門講座、参加したいですか？

もしP2Pの入門講座を開催する場合、参加する方はどの程度いらっしゃるでしょうか？

P2Pの歴史から入り、一般的な通信（IPアドレス、ポート）の話からDHTの基礎と簡単な応用まで説明しようかと思います。最後の方は今後の将来の展望など。
レクチャー時間は土or日or祝日の一日みっちりです。（若しくは午後のみ。）
講師は私（＋アルファの講師陣は調整するかも）で構いません。
教科書・副読本としてskype社の岩田氏や筑波大の池嶋氏、アリエル社の徳力氏のP2P本などを使うかもしれません。参加費用は基本的に実費程度です。

今まで入門者～中級者をターゲットにしている丁寧でわかりやすいレクチャーって余り開かれてないような気がしたので。
人数が集まれば数１０人規模で行うかも知れません。（数人程度なら開催しないかも。）
参加者で、最後に懇親会等が開ければベストだと思います。

参加者の方がP2P勉強会までによりステップアップして頂ければと思います。

[P2P]「Winnyの技術」を読み解く～その１ 世代とは？

新婚旅行のウィーンから帰ってきました。久しく離れていたP2Pの話題を少しずつBlogに書こうと思う。

当分の間は
・「Winnyの技術」を読んで
・Skypeがインフラになる日
・P2P勉強会のトピック
が中心になると思う。

まずは標題通り、「Winnyの技術」を読んだ感想＋意見について書いてみたいと思う。
ただ感想を書くだけでは面白くないので、周辺技術などを絡めてみればと考えている。

「Winnyの技術」はご存知の通り、Winnyの開発者の金子氏が書いた書籍である。
これまで、P2Pに関する技術的書籍は少なかったので、金子氏のこの本はP2Pの研究そして啓蒙にもとても重要な役割を果たすと思われる。P2Pの技術的側面に関心がある人は必読の本である。

この本の感想をblog１日分で書くのにはあまりにも少なすぎる。そこで少しずつだが、書籍を所々引用しながら感想、解説、意見を書いていきたい。

まずこの本ではP2Pの形態について「世代」と言う言葉を通して整理している。具体的には

・第１世代：Hybrid-P2P：Napsterなど
・第２世代：Pure-P2P:Gnutellaなど
・第３世代：Puer-P2P:Freenet,Winnyなど

ここで、第２世代と第３世代の違いが気になるところだ。32Pによれば、金子氏は第３世代をPure-P2Pの中でもキャッシュ機構が入っているシステムと定義している。

まずここでキャッシュを使って第２世代と第３世代となにが違うのか考えてみよう。

私が第２世代との違いの特徴として挙げるのは
特徴1.匿名性の強化
特徴2.システム全体における.トラフィック効率の上昇
特徴3.オリジン（元祖ノード）が非オンラインでも情報提供が可能
の３つである。

特徴1.2.については「Winnyの技術」を読んで欲しい。特徴３についてはここで少し補足しよう。
そもそも、第２世代のPure-P2Pではオンラインしているノードのファイルしか共有ができない。しかし、キャッシュ機構によって、オリジンのノードがオフラインでもファイルが共有できる。
特徴３がWinnyの人気を押し上げた事を忘れがちであるが、とても重要が概念であると個人的には思っている。（もしかすると金子氏は利点３を突き詰めてWinnyのBBS機能を具備しようとしたと考えたのかもしれない。）

では金子氏が唱えたキャッシュ機構＋Pure-P2PをP2P研究者が第３世代と考えているかと言うと、実は違う。
一般的にはP2Pの第３世代とは

・第３世代：DHT(分散ハッシュテーブル）を使ったPure-P2P：Skype(恐らく）、一部のファイル共有ソフトの部分機構

と言われている。DHTについては本blogやHPを見て欲しいが、第２世代とは明らかに違う特徴がある。
それは、

・全てのオンラインノードのコンテンツを検索可能である
・検索に伴うトラフィック負荷がとても軽い、検索が高速（log[O]程度）
・多数のノードの参入、離脱に耐えられる
・数１０億以上のノード参加に耐えられる
ことが挙げられる。

(参考）
分散ハッシュテーブル（DHT）入門～その１
P2Pと分散ハッシュテーブル～その１

では、Winnyは第２世代のP2Pシステムか、というと、これは色々議論があるだろう。
大枠で区切ると確かにWinnyはGnutellaの延長である。この点でWinnyを第２世代と呼ぶのは間違いないかもしれない。しかし、何点か第２世代の先を行くシステムが見受けられる。その主たるものは、

・上流、下流の組織化による、検索トラフィック負荷の軽減
・クラスタリングによる、「意味」による自己組織化

の２点だろう。

まずは上流、下流について。
そもそもGnutellaに見られる第２世代はバケツリレーによって検索情報を伝播している。その特徴としてTTLと呼ばれる数字によって、検索できるノードを制限している。もしTTLがないと、検索トラフィックが膨大になりP2Pネットワークがダウンしてしまうからである。
この点でWinnyは先端的であった。上流、下流ノードを配する事で非常に効率的にコンテンツを検索することに成功したのだ。ノードに重みをつけて、自己組織化することはとてもユニークである。（それまでのP2Pシステムは、ノードの重みが全てフラットであることが多かった。）

そして、後者は更に重要な概念だ。現在でも意味によって自己組織することは大変なことである。
実はP2Pの第４世代というのは、意味情報によってルーティングすることを指す人がいる。例えばNTT研究所が開発したSIONetがそれである。
意味組織化を３つのキーワードの部分一致の大きさによって意味によるノードの自己組織化を行った事はとても大きな結果である。なによりもシステムの概念が明確であり、その実装も比較的容易と考えられる。
キーワードによる意味組織化は第３世代のDHTによるシステムにも、重要な影響を及ぼす事だろう。

このように実はWinnyはGnutellaの意味する自己組織化をさらにユニークな形でパワーアップしていて、当時として（そして現在でも）先端的なシステムであることがわかる。そこで私はWinnyを2.5世代のP2Pシステムと呼びたい。

本書を読むと金子氏はDHTシステムに近いモデルを模索していた事がわかる。（159P)もし、金子氏が当時DHT
に関する文献を読んでいたら一体どんなシステムになっていたのだろうか？とても興味が沸くところである。
本書の同じページにはこのようなことが書かれている。

「いまなら分散ハッシュテーブル(DHT)を使う事も考えられますし、現在のWinnyはP2Pネットワーク上で遠方にあるノードへの検索を諦めてしまっているので、もう少し効率のよい方法もあるでしょう。」

次回は上流、下流について考えてみたい。

[Skype][GoogleMaps]SkypeとGoogleMapsの連携を強化させてみよう！その２

前回はJyveを導入し、Goolemaps上でskypeの相手のステータスをイメージで表示させる方法を説明した。
[Skype][GoogleMaps]SkypeとGoogleMapsの連携を強化させてみよう！

今回は更にそれをパワーアップする事を考えてみる。
前回はポインターを表示しないとskypeの相手の状態が表示できなかった。そこで、デフォルトでskypeの相手のステータスを表示し、且つステータス画面を押すと、その人の詳細情報がわかるようにしよう。

まずはイメージを掴んで欲しい。以下が例である。
Skype+Jyve Example

このようなことを実現するには数点注意する必要がある。

□ポインターを変えることはGoolgeMapsEditorではできないので、HTMLソースを手作業で修正する必要がある。
詳細はgoogleMaps APIのGIconクラスの所を見て欲しい。
⇒Jyveの画像を張り(GIcon.image)、そしてサイズ(GIcon.imagesize)の調整をすれば良い。
参考：GoogleMaps　API　Document
GIconクラス

□GoogleMapsEditorで出力するHTMLソースはUTF-8なので、エディターでHTMLソースを加工する場合には、UTF-8対応のエディターを使う事。例えばMeadowはパッチを当てればUTF-8の文章を加工できる。

□表示する画像はJyveの画像のうち、押してもskypeが掛からない物を選ぶ。そうしないと、画像を押しても詳細情報が表示されなくなる。（逆に相手にskypeが掛かってしまう。）

画像に自分の名前などが表示できるようになれば、様々なシステムに応用ができそうです。
まだまだ工夫の余地があると思いますので、皆さんもチャレンジしてみてくださいね。

[P2P]第3回P2P勉強会の時期について

第3回P2P勉強会ですが、来年の4月～7月で考えています。現在、会場の確保に向けて少しずつ調整をしています。会場について安価で御提供して頂ける方がいらっしゃればご連絡をお願い致します。

私はプライベートでここ数ヶ月は忙しいので、第３回P2P勉強会からSkype Conferenceのように事務局を作って企画・運用をしたいと考えています。立ち上げ時は私が事務局長をするかもしれませんが、ある時点で事務局スタッフが事務局長を引き継ぐ事を考えています。事務局はSkype Conferenceより規模を拡大して、組織化する予定です。

1月頃から事務局立ち上げを行い、講師陣について本格的な調整を開始する事を考えています。
事務局スタッフに関心がある方はコメントを頂ければ幸いです。12月頃にご連絡する予定です。

講演テーマの候補を挙げておきました。まだ全然調整していません。私の思いだけです。（笑）

□P2Pの最新動向
□DHTの最新動向、応用
□P2Pアプリケーション（P2P-SNS、P2P-VPN、P2P地震情報等）
□P2Pミドルウェア（JXTA,SOBA,SIONet等）
□Skype APIとその応用例
□P2Pとセキュリティ
□著作権関連
□コンテンツ流通の課題、ビジネス面の状況(音楽配信、動画配信、放送と通信の融合等）

本当はWinnyのあの人を呼べれば良いのだけども、ムリかな。。。

[Skype]SkypeAPIとスパム電話（SPIT)の考察

SkypeはＡＰＩが公開されていて、簡単にアプリケーションと実装できるようになっている。
一番簡単なSkype連携は恐らく誰でもできるはずだ。それは、HTMLにcalltoタグを書くことだ。これでWebからある人に簡単にskypeをかけることが出来る。また、Jyveを使えれば、相手のステータスをWeb上で確認することができる。
参考に以前紹介したGoogleMapsとSkypeの連携の例を見て欲しい。

さて、このようにSkypeAPIはとても使いやすく有効なのだが、もう一方で非常に厄介な問題を抱える可能性がある。それはSkypeによるスパムだ。

Skypeユーザ間のSkypeは無料なので、今までも突然見知らぬ人からSkypeをされることがあった。しかしcalltoタグをWebに書くと、自動的にロボットで情報を収集され、SkypeAPIをうまく使ったツールを使って、自動的にテープ録音されたメッセージをSkypeされることになるだろう。

実は、これに近い現象が既に発生している。それはＩＰ電話によるスパムだ。
ＩＰ電話は、Skypeと同じようにＩＰ電話間が無料、あるいは非常に廉価に電話をかけることが出来る。
calltoタグのようにロボットによる情報収集はできないが、その代わりにＩＰ電話の番号は範囲が限定できるので、その中で無差別に電話をかける戦略がある。（一時期の携帯へのスパムメールのようなものだ。）

このようなIP電話によるスパムは略してSPIT（SPAM over IP Telephony）と呼ばれる。
参考：IP電話のスパム「SPIT」を警告、ISSのCTOが「来年出現」
既にVoIP業界ではSPITにどのような対策をすべきか検討を始めているようだ。

では、Skypeによるスパムはどうだろうか？まず、SkypeによるスパムをSPOS(SPAM Over Skype)と呼ぶことにする。

SPOSを抑制するには、認証サーバを活用する事が必要と考えられる。つまり、なんらかの方法でSPOSを行っているユーザに対して、ログインをさせないことである。

ただ、問題はどのようにしてSPOSユーザかどうか判別するかである。例えば相手のコール毎に全ユーザ認証サーバにアクセスするのであれば、認証サーバのログ解析から簡単に判別できる。（恐らくこれはSkypeの挙動ではないはず。）

上記が難しい場合には、SPOSユーザがぶら下がっているスーパーノードが各ユーザのコールのログ解析して、認証サーバにSPOSユーザであることを通知する事になるだろう。ただしユーザの個人情報を解析するというセキュリティ的な問題もあるし、実装をどうするかは多くの課題を抱えるだろう。また、ＰＣの電源を全く切らないスパムユーザに対しては全く有効でない可能性がある。（認証サーバとの接続は通常ログインする時の一回きりだったはず。）

さらに何よりもSkypeAPIが巧妙に利用されて、多くのダミーユーザからSPOSが出ているように見えると、対策方法もかなり複雑になるはずだ。

無料電話及びSkypeAPIによる公開で着実に力をつけてきたSkypeだが、スパム対策を今の段階から考慮しないと、一般ユーザからSkypeが電話相当と認められる日が遠のくに違いない。