P2Pとかプログラミング全般とか

P2Pアプリ開発を目指していこうかと。
基本、週末更新なので遅々として進まず。

広告

※このエリアは、60日間投稿が無い場合に表示されます。記事を投稿すると、表示されなくなります。

「情報共有(P2P)研究会」感想

2008-03-02 12:21:41 | P2P
感想として、全体に駆け足の講演が多かった。もうちょっと突っ込んで話してほしいと思うこともしばしば。

(1)P2Pアーキテクチャ概要(西谷智広さん)
一発目は西谷さんによる P2P 概要。P2P の概念が生まれた黎明期から現在までの
道筋とキーワードの解説。P2P に詳しく無い人でも楽しめた講演だった。技術系の
情報も織り交ぜていたので、プログラマにも楽しい。
特に力を入れて解説してたのが P2PSIP。あの人は(ネットワーク上の)どこに居る、
ってのを教えるロケーションサーバを置くとなるとコストがかかるから、P2P で
解決すればお安くなりますね、ってのが大きな動機だそうな。
位置情報は P2P の DHT で良いとして、SIP の動作で2つに分かれるらしい。
・位置だけ教えてもらって自前で INVITE する。
・INVITE までしてもらっちゃう。
SIP の動作的には後者がもともとの考えとしては近いと感じた。なんにせよ、現状の
インターネット環境からすると NAT 越えが重要ということだった。

あとアドホックネットワークについても解説してた。MADPastry や T・DHT などは
ネットワークそのものの距離を意識したネットワーク構築をするそうだが、主に
ビーコンを打ってそれを調整するそうだ(T・DHT は CAN を使い、MADPastry は
ビーコンで得た距離の近さに応じて ID の上位桁からあわせていくんだそうだ)。

DHT 等、構造化 P2P の問題もあげていた。
・ネットワークの分断
 レプリケーションでは完全には対応できないそうだ。確かに大きなエリアが
 分断されちゃうと痛いかも。
・ネットワークの統合
 真面目に統合をやると帯域コストがバカ高になる。代わりに Gateway を置いて
 それがネットワークグループ間を中継する方法も考えられるが、どのノードがそれを担当するのか
 をどう決定するのか、という問題が残っている。

最後に NAT 越えについて解説があった。正直、もうちょっとここを解説してほしかった。
今まで聞いたことのなかった方法で ICE というのがあるそうだ。SIP の SDP で通信の候補に
なりそうな IP アドレスとポートの組を調べてそこにドカドカ送りつけて試してみる、
っていうちょっと聞いただけだとなんだか力技な方法。ノート取るのに忙しくて
キーワードしか覚えられなかった…。

(2)Inside Bamboo DHT(藤田昭人さん)
マイク使わず地声で講演。すげぇ。
概念の話が多くなる中、ベタベタの実装を話すよという前置きで興味をそそられた。
Java 実装の Bamboo を C++ に移植しようという、なんともパワフルな方。
Pastry + churn 耐性 = Bamboo DHT ということだそうな。UCバークレイの Sean Rhea
が作成。Ocean Store の製作メンバーの一人らしい。
Bamboo の要素技術について講演。
・Staged Event Driven Architecture(SEDA)
 処理単位を分離(これを Stage と言う)し、おのおのをメッセージの受け渡しで
 通信させようというもの。各 Stage を並列処理できるようにしてマルチスレッド処理
 すれば効率あがるよね、っていう思想。
 正直、そんな上手くいかねぇよ&手間かけてどんだけ効果でるのって感じで興味ナシ。
・Ocean Store
 Bamboo 作者が書いたコードを再利用してるそうだ。しかもちょこちょこ直してあるんで、
 Ocean Store の公開コードとつき合わせてどれがちゃんと動くのか探すのが大変だったそうだ。
・libasync
 I/O 処理の並列化。ようするに select 関数を使ってやってることだそうだ。
 Sean Rhea はこれにいたく感銘を受けたらしく、コメントのそこかしこに書いていたらしい。
 って TCP/IP やってて select 使わないとか知らないとかありえないんじゃ…。
 まあ Java だと New I/O まで無かったから、Java 一辺倒だとそういうことがおきるんかいな…?
 http://itpro.nikkeibp.co.jp/article/COLUMN/20060403/234326/?ST=develop
 ベンチマークもあるんで、New I/O 知らない人は読もう。
 https://glassfish.dev.java.net/javaee5/webtier/webtierhome.html
 Grizzly にも使われてます。
・オリジナルコード
 いわずもがな

質疑応答で首藤さんが衒いなく OW を薦めていたのが印象的。あと Bamboo DHT に
Key をいっぱい投げつけると簡単に落ちちゃうんです、って情報にびっくり。
そんなこと P2P 教科書に書いてねぇよ。さすが使用経験のある人の知識は違う。
本読んだだけじゃわからんね、そういう情報は。

(3)ネットワークから見たP2P技術のインパクトと課題(亀井聡さん)
P2P のことで新聞取材に応じたら後で呼び出しを食らっちゃいました、というとっても
ステキな亀井さんの講演。大変興味深かった。
P2P 開発者の講演となると「〜技術で今までの労力が半分に!」とか「家の PC で万人規模の
映像配信できちゃってサーバ代浮くぜウハウハ」とか P2P 利用者の利益が強調
されることが多いが、じゃあ物理的に回線提供している側からみてどうよ?って
視点の情報はかなり新鮮だった。
現状のトラフィックだと、ニコニコとかようつべとか動画配信がかなり多くなってて
P2P は目立たなくなってきているそうな。ただ、今後は合法 P2P による CDN
(Contents Deriverly/Distributed Network)が本格化してきてまた問題浮上するんじゃ
ない?って予想。
インフラ側からすると、
・トラフィック量増加
・トラフィックマトリクスの変化
が問題らしい。両方ともコンテンツ転送レイヤの話で、制御レイヤは情報量としてたいした
ことがない。
トラフィック量増加はいわずもがな。特に上りトラフィックの増加が目立つんだそうだ。
まあ Web ブラウズがいまんとこ中心だから、上りを大量に使ってたら目立つよね。
で、インフラ側からすると、上りは絞ってもいいんじゃね?って考えになりやすいそうだ。
なぜなら上りトラフィックはユーザが望んでそうしている事が少ないから。要は他の誰かが
「そのキャッシュ転送して!」って言ってるから「はいよ」って渡しているんであって、
ユーザ本人が「アンタに送りつけてやるよ!」って言ってるわけじゃないから。
だからユーザ本人望んでないんだから別に絞ってもいいよね?ってことになるんだそうだ。
インターネットに直接繋がっていない(直接繋がっている1次プロバイダに繋がる)2次以降
のプロバイダにとって、上位プロバイダから買っている回線(トランジット)の料金
はかなりのものなんだそうだ(従量課金なんだって)。上りを絞りたくなる気持ちも
理解できる。

トラフィックマトリクスの変化、これは P2P 開発者なら誰しも心のどこかでは感じて
いて、でもなかなか意識してこなかった部分だと思う。
今までは上(サーバ)から下(クライアント)に流すことがほとんど。だから大容量配信
のサーバは ISP の上位におけば良かった。源流から支流へ流すように配置するのが
基本だったから、そういうふうにネットワークは物理的に繋がってた。
でも P2P だと誰しもがサーバになる。支流から源流へと昇り、さらに別の支流へ、という
今までなかった流れ方をするようになる。これがマトリクス変化。
それに本当に源流経由で別支流の PC に取りに行かなければならないのか、というのも
問題。本当なら、すぐ近く(支流の内部とか)にそのキャッシュを持っている PC が
あるのかもしれないのに、めちゃ遠いところまで取りにいっちゃって帯域を食っちゃう
ということがありうる。
これは確かに問題だよね。今後はネットワーク的な近さを P2P に取り入れていくことが
前提になっていくかも…、と思った。

P2P CDN が本格普及すると帯域を食い潰す可能性が出てくる。P2P 事業者と ISP 事業者、
双方が好きに行動すると「規制 vs 回避」のいたちごっこで双方大ダメージになる
危険がある、という警告が結構リアルに感じて怖かった。

うーん、現時点では完全な解決策は無いにせよ、今後はその方面での研究が進むと
いいなぁ…。

最後に亀井さんから有用情報。コンシューマのゲームメーカさんからの情報で、
コンシューマで使用されているネットワークの9割は Symmetric NAT じゃない、
つまり NAT 越え可能なものなのだそうだ。NAT 越え技術、もうちょっと身につけ
ようかしらん。

(4)携帯用P2Pフレームワーク(林雄一郎さん)
http://www.yoshidakamagasako.com/
(株)吉田鎌ヶ迫の副社長さん登場。社長の鎌ヶ迫さんも来たんでびっくり。
以前、@IT かどこかで記事を読んだことがあったんだけど、実際に見て
確かにレスポンスの速さにさらにびっくり。
と、ここで実は寝てしまって…。ノート取れませんでした。ごめん。
ちなみに質疑応答でドワンゴの人が質問してたよ。今後ゲームに使用するのかしら。

(5)Proof of concept のその先に オーバーレイネットワークの実際(首藤一幸さん)
イケメン登場。首藤さんカコイイよ、首藤さん。
OW 情報として興味をそそったのが、離脱ノードへ何度も接続しちゃうよ問題。
recursive だとメッセージが他ノードへ渡ると、受け取ったノードが次の転送先へと
渡す。ここでもし次の転送先ノードが離脱していたら…?
離脱ノードへ転送しようとして失敗。別ノードへ転送する。別ノードがまた離脱ノード
へ転送しようとして失敗。あと繰り返し。
もし離脱ノードがメッセージの宛先として最もマッチしていたら…。各ノードで
何度も何度も転送しようと試みちゃうわけだ。
Iterative ならメッセージを転送するのは常に自分だから、離脱ノードとわかれば
転送しないってことも可能だけど、Recursive だとそうはいかない。
結局、転送メッセージに離脱ノードを載せていくことで解決したんだそうだ。
首藤さんの言うとおり、これは確かに実地で動かして見なきゃわからない問題だよな…。

P2P とは一見関係ないようで、実はいろいろ影響があるのが時計。PC の内部時計は
かなり狂うんだよ、だからすごく苦労したよ、と何度も言っていた。よほど
辛い目にあったんだろう…。Linux でも時計は狂う(というかジャンプするというか)
んだそうだ。Windows ならさらにおきるんだろうなぁ。

特に Application Layer Multicast による CDN、たとえば動画配信だと時計はもちろん
重要。いろいろ苦労したんだそうだ。
・CDN がいくら近場までキャッシュを持ってきてくれるとはいえ、間に合わないこともある
 緊急サーバに問い合わせてデータをもらう、という機能で対処。
・ファイアウォールがギッチギチ。
 Unicast に fall back。
・アプリの自動更新機能は入れるべきだね。
・ヤバいコンテンツを流されない対応もしようね。
 DRM や末端を強制的に止める機能を入れよう。

最後に OW の今後は?って質問してる人がいた。ノート必死に取ってたんで上手く聞き取れなかった
んだけど、構造化オーバーレイによるルーティングについて何かやりたいらしい。
あと、P2P の適応として分散ストレージがあるんじゃないか、って言ってた。9.11 以降、
データを分散して置く事の重要性が出てきたんだそうな。
確かにネットワークそのものは分散してきて、いまや回線そのものは耐障害性があがってる。
でもそこに乗っかるデータは未だサーバに溜め込むのが中心。そこも分散して耐障害性
あげようって方向は、インターネットを生んだもともとの理念からして当然かも、って思った。
ジャンル:
ウェブログ
コメント (2)   トラックバック (1)   この記事についてブログを書く
この記事をはてなブックマークに追加
« 「情報共有(P2P)研究会」お... | トップ | キャッシュ共有 今晩の更新 »

2 コメント

コメント日が  古い順  |   新しい順
NAT越えについて (Tomo)
2008-03-02 22:41:46
感想ありがとうございます。講演一発目をやったものです。

NAT越えはやっぱり色々な人が興味あるようですね。次回はもうちょっと詳しく講演したいです。

亀井さんの質問時に代理で答えたNAT越えの情報は先月主催したVoIP Conferenceの講演で詳しく書いてあります。たぶんこの資料が日本で一番NATに詳しいと重います。ご参考に。

http://homepage3.nifty.com/toremoro/study/voip2008.html

研究会のプレゼン資料は近日公表になると思います。
コメントありがとうございます (scalar_001)
2008-03-09 11:12:04
返信が遅れてごめんなさい。

講演お疲れ様です。導入として、大変すばらしい内容だったと思います。
資料、拝見しました。KONAMIさんの資料を見る限り、NAT 越えは固有の
苦労があって、資料から苦労が見て取れるようです。すぐにでも IPv6 に
移行してすべてのピアが対称なネットワークを構築したくなります(もちろん
IPv6 環境においても簡易なファイアウォールとしての NAPT 利用がありうる
だろうことは承知しています)。
全てを解決する方法は無いにしても、せめてもう少し P2P にやさしい
ネットワーク構造になってほしいですね…。PC を使う人全員がネットワーク
に詳しいわけではないですし。

プレゼン資料の公開、期待しております。個人的には首藤さんのスライドで
グレイアウトしていた項目がすごく気になってます。もしその部分を話す
機会があるならぜひ参加したいですね。

コメントを投稿


コメント利用規約に同意の上コメント投稿を行ってください。

数字4桁を入力し、投稿ボタンを押してください。

あわせて読む

トラックバック

この記事のトラックバック  Ping-URL
JIPDEC 情報共有(P2P)勉強会@機械振興会館/東京タワーそば (かめいぬ)
Click to continue reading “”Go straight to Post ...