2008-02-29
「情報共有(P2P）研究会」より、ウタゴエ首藤一幸氏の講演「Proof of Conceptのその先に〜オーバレイネットワークの実際〜」
講演者の「工学」的なセンスを感じた講演。工学とは、理論の美しさだけでなく、実地運用の諸問題を解決する馬力も要求されるジャンルなのだ。
p2p技術の動向、P2PミドルウエアOverlay Weaverの経験と、アプリケーション層マルチキャスト（ALM）技術Ocean Gridの経験を中心に語る。情報量が多く、やや高速の講演となった。懇親会では、「首藤氏の話をまる1日聴く首藤カンファレンスはどう？」といった冗談が出たほど。
DHT（分散ハッシュテーブル）の弱点の一つは範囲検索ができないこと。DHT対抗技術のSkip Graphは範囲検索が可能。DHTで範囲検索を可能とする研究も。
Overla Weaver、産総研時代に作ったものだが、オープンソースにしてSourceforgeにホスティングすることで、転職後もメンテナンスできるように考えた。2005年1月のリリースから45回のリビジョンアップ（すごい）。
配信トポロジーにはツリー型とメッシュ型がある。メッシュ型は2005年に初めて論文が出た。香港の大学とカナダの大学が執筆。
配信技術の「うれしい」実績。アーティストaccessのライブ配信では、Ocean Gridを使うことで、91〜93%のトラフィック削減効果があったとのこと。
ほか、Ocean Gridによる動画配信の実績の紹介。早稲田祭2007の中継を2Mbpsで。超高速インターネット衛星「きずな（WINDS）」の打ち上げ中継を1Mbpsで、等々。私は「きずな」の打ち上げ中継は見ようと思っていたのだが、打ち上げ遅延の影響で見逃したのだった。残念。
「実地運用ではじめてわかること」というものがある。その中からピックアップしていくつかの話題を説明。
- 離脱したノードをblask listに登録。そうしないと、離脱したノードへの問い合わせが頻発し、タイムアウト待ちが繰り返される。
- 時計の不正確さ。PC内蔵の時計は想像以上に不正確で、1時間で55分しか進まない時計もある。ハードウエアが信頼できないため、ソフトウエアで回避。
- ネットワーク越しのデッドロックの伝染。
- 脆弱性問題。一度JPCERT/CCから通告がきた。その対処が大変。勝手にバージョンアップもできなくなる。
- ログサーバー。商用には全体の状況把握が不可欠。特に視聴PC数。
- バックアップ。メッシュ型では、再生時刻までにデータを取得できる保証がない。
- ソフトの自動更新、更新通知。例えばSETI@homeにセキュリティホールがあったが、この種のソフトに穴が空いていると危険。
- 変なものを流されるリスク。DRM、暗号化、緊急時に根本で止める仕組み。
- Flash、Windows Media、プロトコル非公開だが、対応しなければならない。
（まとまっていないけれども、講演を聴きながらのメモということでご容赦）
ところで、私は前職でOverlay Weaverの記事を書いたことがある。この話もさりげなく触れていただいた。ちょっとうれしい。
「情報共有(P2P)研究会」より、吉田鎌ヶ迫 林雄一郎氏の講演「携帯用P2Pフレームワーク」
吉田鎌ヶ迫のケータイ用（BREW用）P2PフレームワークSpear、SpearMultiの紹介。KDDIの網は携帯電話間のIP接続が可能。とはいえ制約は多い。その制約の中では「常時接続を前提としない、通信データ量の軽いアプリケーション」が適している。具体的にはオンラインゲーム、メッセンジャーなど。ケータイ網でIP接続が可能でない場合には、HTTPとポーリングを組み合わせる。
4台のケータイが対戦できるゲーム、などの事例を紹介。
クライアント/サーバー型の通信では、ケータイ網の外にあるインターネット上のサーバーを経由するため、無駄な通信が発生する。P2Pのチャットでは0.15秒程度で相手に届くが、クライアント/サーバーでは1〜2秒のタイムラグが発生する。
将来的には、キャリア間P2P通信の可能性も。IPv6でグローバルIP問題は解決したので、あとはキャリアのポリシーか。3.9Gケータイで20Mbps程度の速度が出ることもいい材料。
追記：
BREW（au/KDDIが採用する携帯電話プラットフォーム）で動くP2Pミドルウエアが彼らの主力製品だが、BREWは認可が厳しい。しかも彼らが開発を始めた当時はP2P機能はまだ使えなかった。この条件下でよく会社を育てたものだと感心した。
「情報共有(P2P)研究会」より、藤田昭人氏の講演「Inside Bamboo DHT」
藤田昭人氏の講演「Inside Bamboo DHT」を聴いた。
藤田氏はオムロンのUNIXワークステーションの事業部で、UNIXカーネル、Machカーネルをいじっていた人である。現在はフリーランス・プログラマ兼博士課程の学生。話が面白い。余人を以て代え難い味わいがある。
Bamboo DHTはUCB（カリフォルニア大学バークレイ校）の学生だったSean Rheaが開発したDHT（分散ハッシュテーブル実装。アルゴリズムは、Churn耐性を考慮したPastryの拡張、とのこと（Churn耐性は構造が乱れた場合の復元に関わる性質、PastryはDHTアルゴリズムの一種）。
Bamboo DHTはJavaで書かれているのだが、「JavaとC++の勉強のため」という理由で、JavaからC++に翻訳しながら構造を理解したとのこと。普通の人ならまず採用しないアプローチだと思うが、藤田氏のキャラクターと合わせると、なんとなく納得するものがある。
Bamboo DHTの実装は、次の4つから成る。
(1)SEDA（Staged Event-Driven Architecture）。イベント・ドリブンの非同期並列処理フレームワーク。ハーバード大学の博士課程の学生Matt Welshが作った。コンポーネントの単位をStageと呼ぶ。それぞれのStageはSinkと呼ぶイベント・キューを備える。コンポーネントの非同期連携が可能。
(2)OceanStore。イベントを適切なStageに配送するディスパッチャClassfierと、イベントを定義するクラスを定義したテーブルTypeTableをもつ。「正直いってよくわからん」内容とのこと。
(3)libasync。ライブラリ・レベルで非同期通信を実現。カーネルで実現するスレッドを使う非同期通信ではノードが増えると効率が下がる事が観測されているため、ライブラリ・レベルで実装したとのこと。へえ。
(4)BambooDHTのオリジナル・コード。
話がいちいち、UNIX/Cの低レベルな所に落ちていくのが面白い（注：後でうかがったところでは、ご本人は、「そういう意識はないんだけどなあ」とのこと。むしろ当方が面白いと感じたポイントが低レベルな部分ということだったのかもしれない）。
藤田氏は、いったんBrodckenと名づけたC++実装を完成させたのだが、「我ながらコードが最悪」という理由で再実装「Gryffon」の開発に着手したとのこと。これを勉強会の形で情報公開しながら、開発を進めていく方向性とのこと。「一人で『コンダラ』はつかれたので」と藤田氏。
首藤一幸氏が、「Bamboo DHTより僕のOverlay Weaverを使った方が良かったと思うんですけど」と質問していて、ちょっと吹きそうになった。Bamboo DHTの実装が今ひとつ、ということは藤田氏も認めているが、C++に書き直して勉強して自分のものにする、というコンセプトで作っていたとのことなので、そこは目的が違うということなのだろう。
東京タワーのふもと
久しぶりに（！）都会に出た。東京タワーのふもと。
ここで、P2P（peer-to-peer）、特に構造化オーバレイやDHTと呼ばれる分野の勉強会に参加中（関連エントリーあり）。
P2Pの最先端の話を聞いて勉強中。今やっている新サービスと直接関係がある訳ではないのだが、この世界の空気に触れることが、自分の刺激になるのである。
子供がバージョンアップ
2歳8カ月の息子が、寝かせている時に着せている上着のボタンを、自分で外して脱ぐことに成功。
母親が手を叩いて褒めると、「どんなもんだい」という顔をする。
少しずつ、能力が上がっている。母親によると「バージョン0.48ぐらい」とのこと。
