[P2P]Websocketでブラウザ間P2P通信は実現できるか？

□WebsocketでP2P通信ができるのか？を検討するきっかけ

第２回Websocket勉強会の開催を来年度また開催しようと考えています。今度は自分としても何か講演できるネタがないか少しずつ考えているところです。その一つのネタはWebsocketで実現できること、できないことはなにか？を解説することです。

さてWebsocketはブラウザ等によって双方向な通信を行うプロトコルとなります。Websokcetを使うことによって従来の技術では困難であった、サーバからのPush通信が容易になります。この考え方を拡張し、Websocketを用いてブラウザ間の直接通信を実施すること、すなわちP2P通信の実現を考えることは自然なことです。

ただWebsocketは現在の仕様を見る限りクライアント-サーバ間通信を基本としており、P2P通信を意識したプロトコルとは残念ながら考えにくいことは事実です。それを承知としてP2P通信をWebsocketとしてできるのか、もしできないなら何故なのかを今回思考実験してみます。

また自分が方式検討/開発として関わった050plusを世に出した後、この検討によってP2P、NAT越え技術を改めて振り返る良いきっかけになると考えています。皆様のコメントを是非頂きたいと考えています。

なお、今回は非常にラフな検討ですので（今夜思いついたアイデアをサラっと書いています）後日詳細な分析結果を改めて書きたいと考えています。

＊本検討範囲はブラウザ単体で簡単に処理できるWebsocketとJavascriptの組合せまでとします。

□Weboskcetを用いたP2P通信を実現するための課題

Websocketではクライアント-サーバ間で通信する場合、HTTPのようなプロトコルにて通信を行います。P2P通信をする場合、互いの端末（ここでは端末をノードと呼ぶことにしましょう）はクライアントとサーバ機能を両方持つ必要があります。

これを実現するには以下の課題があります。

[課題1]ノード間でTCPによる接続を実現させるための技術が必要
[課題2]課題1を実現した後Websocketレイヤにおいてクライアント-サーバ間のハンドシェイクを実現するための技術が必要

まず課題１についてです。WebsocketはTCPを使う以上、ノード間でTCP接続をする必要があります。ブラウザはHTTPクライアント機能はありますがサーバ機能は一般的にはないため、どのようにしてブラウザにてサーバ機能を実現できるかが大きな課題となります。

残念ながらJavascriptだけではブラウザ間でP2P通信を行うことは2008年当時で困難であることを過去の記事で纏めています。
ブラウザー間直接通信で広がる世界と課題

すなわち、TCPにおけるブラウザ間P2P接続が実現しない限りWebsoketによるP2P通信の実現までたどり着くことはできません。ブラウザ間P2P接続を実現する可能性の一つとしてTCPのNAT越えで利用するTCP hole punchingを使い、お互い同時にTCPのハンドシェイクを開始することによってP2P実現をすることが考えられます。これを実現するにはJavascriptがTCPのsokcetレベルまでコントロールする必要があり、現在のJavascriptの規定を超えています。

仮にNATがない状態においてブラウザ間P2P接続ができたとしても、サーバレスでNAT越えを行うにはTCP hole punchingを使う必要があります。そのため、商用レベルでブラウザ間P2P通信を行うには、どうしてもブラウザにてTCPのsocketレベルでのコントロールが必須と考えられます。

課題1の解決ができた前提で課題2についても説明します。Websokcetではクライアント/サーバの役割がきっちりと明確化しています。仮にTCP hole punchingでブラウザ間P2P通信がうまく行った場合、どちらのノードがクライアントか、サーバかを決定する必要があります。Websocketのハンドシェイク前に独自プロトコルでクライアント/サーバを決定する、あるいはWebsokcetのハンドシェイク信号の受信タイミングによって役割を決定する等が考えられます。（*後者は受信タイミングによって色々なノード状態がありうるので慎重に実装の検討をする必要があります。）

そして課題１、２をクリアしてもWebsocketの実装によってはセキュリティ対策によってP2P通信が抑止される可能性もあります。参考にJavaAppletによってP2P通信を行う場合、このセキュリティ対策を回避するために、ちょっとしたおまじないをする必要があります。

□結論

上記の検討結果を踏まえると現時点でのWebsokcet＋Javascirptの仕様においてはブラウザ間P2P通信の実現は困難だと考えられます。

ところで、信学会の研究会において「WebSocketを用いたWebブラウザ間P2P通信の実現とその応用に関する研究」という発表が既に行われています。サマリーを見るとJavascriptを「独自に拡張する」ことによってWebsocketにおけるブラウザ間P2P通信を実現しているようです。まだこの発表内容は未読ですが、どの程度のJavascriptの拡張をしているのか、それは今後仕様として実現できる見込みがある拡張なのか気になります。近々チェックしたいと考えています。

また、ブラウザ間でP2Pを実現することについては、W3Cのワーキンググループとして「Web Real-Time Communications Working Group」が立ち上がっていますので、本記事に興味がある方はこちらの動向をウォッチすると良いでしょう。機会があったらこの手の情報を随時ご紹介します。

TwitterをP2Pで実現する方法をもう少し考えてみる

第2回Twitter研究会は今年7月～9月に開催する予定になりそうだ。ということで、そろそろ講師用MLを作ることを考えている。次回のTwitter研究会では私も講師陣に加わってTwitterライクなサービスをP2P（というよりもクラウドと言ったほうが適切かもしれない）で実現するための手法について議論したいと考えている。本記事はその議論のためのメモである。

さて、TwitterをP2Pで実現する方法については、既に本Blogにおいてほぼ3年前に議論している。本記事はその記事に対して実現方式等を補足したものである。

Tomo's Hotline [P2P]TwitterのP2P化を考えてみる

TwitterのようなサービスをP2Pあるいはクラウドで実現するメリットはスケーラビリティの向上と運用コストの抑制である。

P2PシステムとしてDHTを利用する。今で言うとkey-valueストレージをイメージしてもらえば充分だ。DHTはkeyを引数としてvalueを引き出すことができる。つまりDHTとは分散化されたデータベースようなものだ。

DHTの詳細な説明は拙著「P2P教科書」を読んでもらうこととして、本論に移ろう。
なお、今回はアイデアを紹介するのが目的であるので、各種用語の定義、議論の厳密さよりもわかりやすさを優先する。

[1]基本的なツイートのデータ蓄積方法

前提として各ユーザに対してユニークなアカウントを払い出しているとする。（ユニークな払い出しの実現方法については後述。）
例として@toremoro21というアカウントのユーザがいたとする。今ハッシュ関数をhash()と定義する。

各ノードには一意のノードＩＤがDHTによって割り当てられている。
@toremoro21に対する各ツイートはノードID=hash(@toremo21)となるノードに格納する。

次の目標は各ツイートにユニークな識別子をつけることである。
今ツイート識別子としてアカウント名＋（各アカウントに対するユニークな識別子）で割り当てることを考える。この（各アカウントに対するユニークな識別子）として一番単純なのは、世界標準時(GMT)だろう。GMTを使うと各ツイートの時系列が簡単に把握できる。つまり、タイムライン等における時系列表示が容易に実現できる。当然端末の時間の誤差などが課題であるが、ツイートのように順番が多少ずれていても、あまり問題のならないサービスであればＧＭＴで事足りるだろう。なお、BOTのように大量にツイートを作成するアカウントがいる場合は、ＧＭＴの後に各ＧＭＴ内単位時間内での発言に対するシーケンス番号を付け加えることが考えられる。

話を単純にするため、各ツイートの識別子はアカウント名+区切り文字+発言したGMTで記述することにする。区切り文字を*とすれば、ツイートの識別子の例は@toremoro21*20100503となる。区切り文字より前の情報から、ツイートを発言したアカウント名及びこのツイートを格納しているノードが判明する。区切り文字以降から発言した時間がわかる。

次に、アカウントを一意に作成する方法について述べる。議論を単純にするため、Ｐ２Ｐシステムに悪意のあるノードがいないとする。今、あるノードAがアカウント@toremoro21を作成しようとする。ノードＡはノードID=hash(@toremoro21)となるノードと通信を行い、アカウント@toremoro21がまだ作成されていないことを確かめる。もし、既に@toremoro21のアカウントが作成されていたら、別のアカウントを作成し先ほどと同様な手順で既存アカウントと重複していないか確認を行う。

[2]タイムラインの表示
タイムラインを表示する方法として、各ユーザがフォローしている各アカウントのツイートを管理しているノードに対して情報の更新を定期的に確認することが一番シンプルである。ただ、この方法はDHTシステムに対して大きな負荷が掛かる。

よりスマートなタイムラインの実現方法は次のとおり。タイムラインを表示したいノード（ノードＰとする）はフォローしている各アカウント（@toremoro21とする。）のツイートを管理しているノード（その一つをノードＱとする）に対して、ツイートが更新したときに自ノードに対してプッシュ通知を行うように、指令を出す。つまり、ノードＱは@toremoro21に関わるツイートの情報更新が行われた場合、ノードＰに対してプッシュ通知を行う。通知方法としては、単にツイートが更新されたことを知らせる方法、更新されたツイートに関わる識別子を知らせる方法、更新されたツイートの内容全体を通知させる方法などがあるだろう。

[3]リツイートに対する処理

リツイートについては、引用したツイートに対する識別子情報も含めてDHTシステムに格納する。これによって、引用したツイートを他人が参照することが容易に可能である。なお、引用するときに引用元のアカウントを含めるため、後述の[6]の処理も行う。引用元ツイートにハッシュタグが含まれた場合、後述の[5]の処理も行う。

[4]ダイレクトメッセージに対する処理

@toremoro21に対してダイレクトメッセージを送信をする場合、hash(@toremo21)をノードＩＤとするノードにダイレクトメッセージを格納する要求をする。

[5]ハッシュタグに対する処理

@toremoro21が#twitterconfを含むツイートを行う場合、hash(@toremoro21)をノードＩＤとするノードに当該ツイートを格納するだけでなく、hash(#twitterconf)をノードＩＤとするノードにもツイートを格納する。これによって、#twitterconfを含んだ発言を他人が容易に参照できる。

[6]アカウントを含むツイートを含む処理

これも先ほどのハッシュタグIDと同じ議論である。あるアカウントを含んだツイートは、hash(アカウント）をノードＩＤとするノードにも格納する。これによって、各アカウントを含んだ発言を他人が容易に参照できる。

このようにP2PであってもDHTを使えば、Twitterライクなサービスはある程度容易に実現できると考えられる。

オフィスツアー（ビットメディア）を振り返る

10/16(金）にP2Pライブ配信で有名なビットメディアでオフィスツアーを開催しました。参加者数は10名でP2P配信談義で大いに盛り上がりました。

オフィスツアーに関わる周知情報は以下のURLをご覧下さい。
http://toremoro.tea-nifty.com/tomos_hotline/2009/08/post-c2f4.html

以下概要と感想です。

□ビジョン先行の企業

ビットメディアといえば、P2Pライブ配信企業として有名ですが、それだけでなくポイントシステムやスマートグリッドに関わるシステムを開発しています。（スマートグリッドについては現在プロジェクト進行中とのこと。）

ビットメディアのビジョンは「地産地消」「徹底的にニッチ」ということで、ローカルなエリア対象にそこに根付いた小中規模な事業を手がけるところがユニークだと考えました。このビジョンは開発方針（システムの規模やコスト）にも反映され、結果的に

・「ニッチ」なため競合他社が入りにくい
・リーズナブルなシステムなため、小中規模なイベントでも利用できる
・「ニッチ」だがペイできる収益を確保できる

という好循環を生み出しています。ビジョンを通して更にユニークな分野に事業が広がるところを期待しています。

□P2P配信の話

いよいよ今回の目玉であるP2Pライブ配信の話です。P2Pライブ配信はツリー上で行います。つまり、ツリー（いわゆる配信木）に端末が存在し、端末はその下位の端末にコンテンツを渡します。このことで、コンテンツ配信サーバのネットワーク負荷と各種リソースを大幅に削減することができます。

ところで、コンテンツ配信サーバ自体をより動的に利用できるのが、ビットメディアの売りです。コンテンツ配信サーバとしてなんとAmzon EC2を使います。このことによって、本当にライブ配信をしたい前後だけにAmazon EC2を利用することで、配信コストを大幅にコストダウンすることができます。またAmazon EC2を使うことにより、配信をすぐに開始でき、（デモではAmazon EC2の設定を含め数分でコンテンツ配信が可能となりました。）また配信スケールも簡単に変えることができます。

つまり、ビットメディアのP2P配信システムはP2P+Amazon EC2によって

・コンテンツ配信のイニシャル/ランニングコストの低下
・高スケーラビリティなコンテンツ配信
・機動力のあるコンテンツ配信

を実現しているわけです。

Amazon EC2をコンテンツ配信サーバとして利用すると、やはり遅延が発生します。ただし、双方向性のコンテンツではないので、遅延は個人的には気になりませんでした。

最近ではネットワーク高度利用協議会で提案しているヒントサーバを利用して、トラフィックをISP内で閉じ込める工夫もしています。

□より収益のある事業に向けて

NHK合唱コンクールの地域予選をP2Pライブ配信したところ、各種から問い合わせがきたとのことです。中継では数１００ぐらいの同時視聴者数があって、安定的に配信できたとのことです。この程度の視聴者数を見込められるライブ配信であれば、ビットメディアの配信システムも候補に入れた方が良いでしょう。

ビットメディアのライブ配信の良さはなんといってもコストパフォーマンスです。１ヶ月１チャネルを利用するときの配信料金はたった１０万円です。これはP2PとAmazon EC2を採用しないと実現できない料金体系です。

また配信料金の低価格を活かして、個人によるコンテンツ配信事業の検討をしているとのことです。料金体系は３０分１００円～で誰でもコンテンツをライブ配信可能な模様です。こうなるとビデオカメラを使って誰もが簡単にライブ配信ができる日がもうすぐやってくるのでしょう。なお個人配信のコンテンツとして、少年スポーツ団や結婚式のライブ配信などを想定しているようです。

□終わりに

今回のツアーはビジョンとマーケティングとの密接な関わり合いについて考えさせられました。ビジョンからマーケティングに落として、それから技術を生み出すというトップダウンの仕組みがビットメディアでは実践されています。その結果、ニッチだけれどもユーザから感謝される新たなサービスが数多く実現しているのです。このオフィスツアーを通して、技術者であってもマーケティングや経営戦略をもっと勉強しなければ消費者に訴えられるサービスは作れない、という気持ちが沸いてきました。

□追記＋次回のオフィスツアーは？

今回のオフィスツアーのTwitterハッシュタグは#officetour です。また感想記事はSBMで「オフィスツアー」タグでまとめられています。

はてブで「オフィスツアー」タグ　

次回のオフィスツアーは2010年２月開催予定です。ユニークさ企業としてとても有名なのでお楽しみに。

本Blogではオフィスツアーにご協力頂ける企業、団体の方をお待ちしています。ユニークな企業の方、先進的な企業な方、楽しい雰囲気の企業、地域に貢献している団体等ご連絡をお待ちしております。また今後は大学、大学院の研究室のツアーもやりたいと考えています。

[開催日変更]オフィスツアー（株式会社ビットメディア）参加者募集のご案内

久しぶりにオフィスツアーを開催します。
今回はP2Pライブ配信の「ビットメディア」にお邪魔します。

P2Pライブ配信の実装でJavaアプレットを採用しているため、
インストールレスでコンテンツの視聴ができるのが特徴です。
つまりブラウザーだけでP2P通信を行っています。
最近ではクラウドとの連携でも話題になっています。

オフィスツアー概要

□日時：10/16(金） 19:30～21:00（開催日が変更になりました）
□開催場所：下記の場所に直接お越し下さい
渋谷区渋谷2-7-5　URD渋谷第2ビル　6F受付
http://www.bitmedia.co.jp/map.html
□参加定員
10名
□参加費用
無料（軽食をご用意しています。飲み物は各自持参でお願いします。）
□参加表明方法
Mixiのイベントトピで受け付けます。
http://mixi.jp/view_event.pl?id=45394576

□参加条件
Blog、Twitter、Mixi等でオフィスツアーの感想を書いて頂くこと
□お願い
・首かけストラップ＋名刺をお持ち下さい。
・飲み物は各自持参でお願いします。
・おつまみの持ち込みを歓迎します！

以上です。皆様のご参加、心よりお待ちしています！

[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エンジンがマルチスレッドであれば問題ないかもしれない。

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