P4Pについての論文の日本語紹介があった

Geekなぺーじ : P4P : P2Pの進化系？

P2P ソフトウェア側からでは調べきれない情報をプロバイダが提供することで、
プロバイダへの負荷を下げ、利用効率をもっと上げることを目的とする P2P が
P4P ってことになるのかな。なんで 2 の次が 3 じゃないのかと思ったが、
よくよく考えてみれば P3P ってもう単語として存在するよね。

「P4Pのモチベーション」の欄を見てもらうのが一番わかり易いんだけど、要するに
P4P をやるとこんな良い事が！だからお互い手を取り合って頑張っちゃおうよ！
ってのが書かれてる。
「情報共有（Ｐ２Ｐ）研究会」感想の (3) で亀井さんが発表していた懸念に
一緒に対処していこうよ、ってのが P4P なんだろうなと思った。

ただ「やろうよ！」って言ってるだけじゃなく、実際にやってみて、計測して、論文
で出しているのが良い。証拠がちゃんとあるよ、検証できるよ、って姿勢を示す
ことでプロバイダ側のモチベーション、やる気を引き出そうとしている。
日本でもこういう運動を進めていくべきなんだろうな。文句を言うだけじゃ変わらない。
アプリ開発者の端くれとして、微力だけど動いていかなければ。

ちょっとだけ更新

http://cid-7862a61060e90b1f.skydrive.live.com/self.aspx/NicoCacheWithOverlayWeaver

だんだん実装が面倒なところに近づいてきた。
エラー処理やら、要求失敗時の処理とかにも気をつけないと。
それより風邪をこじらせてる自分の体調に気をつけないと。

キャッシュ取得要求をタスクとしてくくりだして実装中。取得したキャッシュをどう
プロキシ側に渡そうか考え中。プロキシ側とは別スレッドで動かして、BlockingQueue
あたりでデータを受け渡すのが一応の案。あとはプロキシ側でタイムアウト判定をする
のと、タイムアウトしたことをどうタスク側に伝えて停止させるか。

「P2Pは回線の利用効率が悪い」ってホント？

「ニコ動」ドワンゴ会長がJASRACシンポに　著作権やビジネス語る

記事のほかの部分については保留するけど、「P2Pは回線の利用効率が悪い」って発言はなんか間違ってない？
Winnyを引き合いに出してるけど、Winny は CDN を中心に据えて無いんだから利用効率が悪くても当たり前。
ドワンゴの川上会長は CDN としての P2P については明るくないご様子。だからこういう発言も仕方ないとは思うけど。

> Winnyはユーザー数が少ないのに、日本のネット回線のトラフィック量に占める割合は大きい。
これもどうかな。「情報共有（Ｐ２Ｐ）研究会」での亀井さんのお話によれば、今は Winny よりも
動画サイトのトラフィックが多いという話。となると、本当にトラフィック量の多くを
Winny ユーザが占めているかどうかは怪しい。

総括：川上会長は P2P の中にも種類があることを勉強しましょう。Winny は CDN じゃありません。

キャッシュ共有 今日の夜の更新

http://cid-7862a61060e90b1f.skydrive.live.com/self.aspx/NicoCacheWithOverlayWeaver
キャッシュ送信部を実装。といっても受信側を書いて無いしデバッグしてないしでまだまだ動くもんじゃないんだけど。

キャッシュ共有 なんでか朝の更新

風邪で会社休んでるのに何やってんだか…。
週末が忙しくてなかなか更新できないのがイライラする。休日はほんと休みたいよな。
http://cid-7862a61060e90b1f.skydrive.live.com/self.aspx/NicoCacheWithOverlayWeaver
flvファイル情報を DHT に put するタスクを追加。なんでタスクにするかというと、TCP による送信部を１スレッドに限定するため。
送信部はマルチスレッド対応してないみたい（最低限、synchronize してないように見える）だから、
複数スレッドからアクセスしないようタスクスレッドでのみ送信するようにしようかと。

キャッシュ共有 今晩の更新

もうブログにソース乗っけるの面倒なんで、SkyDrive にファイル置くことにした。
http://cid-7862a61060e90b1f.skydrive.live.com/self.aspx/NicoCacheWithOverlayWeaver
ライセンスは Overlay Weaver とあわせて、Apache License Version 2.0 とするんで、
ライセンスに違反しない程度に利用するように（本当はソースの頭にライセンス文を
掲載しないといけないんだろうけど、今は面倒なんで省略）。

まだこの時点ではぜんぜんキャッシュ共有としては動かないんで、そういう目的では
期待しないように。今は堀を埋める作業ってところ。
一応シミュレータ上ではちゃんと接続ができて put, get できるようにはデバッグ
したんで、Main クラスあたりは他へ流用できると思う。

「情報共有（Ｐ２Ｐ）研究会」感想

感想として、全体に駆け足の講演が多かった。もうちょっと突っ込んで話してほしいと思うこともしばしば。

(1)P2Pアーキテクチャ概要（西谷智広さん）
一発目は西谷さんによる P2P 概要。P2P の概念が生まれた黎明期から現在までの
道筋とキーワードの解説。P2P に詳しく無い人でも楽しめた講演だった。技術系の
情報も織り交ぜていたので、プログラマにも楽しい。
特に力を入れて解説してたのが P2PSIP。あの人は（ネットワーク上の）どこに居る、
ってのを教えるロケーションサーバを置くとなるとコストがかかるから、P2P で
解決すればお安くなりますね、ってのが大きな動機だそうな。
位置情報は P2P の DHT で良いとして、SIP の動作で２つに分かれるらしい。
・位置だけ教えてもらって自前で 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 ブラウズがいまんとこ中心だから、上りを大量に使ってたら目立つよね。
で、インフラ側からすると、上りは絞ってもいいんじゃね？って考えになりやすいそうだ。
なぜなら上りトラフィックはユーザが望んでそうしている事が少ないから。要は他の誰かが
「そのキャッシュ転送して！」って言ってるから「はいよ」って渡しているんであって、
ユーザ本人が「アンタに送りつけてやるよ！」って言ってるわけじゃないから。
だからユーザ本人望んでないんだから別に絞ってもいいよね？ってことになるんだそうだ。
インターネットに直接繋がっていない（直接繋がっている１次プロバイダに繋がる）２次以降
のプロバイダにとって、上位プロバイダから買っている回線（トランジット）の料金
はかなりのものなんだそうだ（従量課金なんだって）。上りを絞りたくなる気持ちも
理解できる。

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

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

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

最後に亀井さんから有用情報。コンシューマのゲームメーカさんからの情報で、
コンシューマで使用されているネットワークの９割は 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 以降、
データを分散して置く事の重要性が出てきたんだそうな。
確かにネットワークそのものは分散してきて、いまや回線そのものは耐障害性があがってる。
でもそこに乗っかるデータは未だサーバに溜め込むのが中心。そこも分散して耐障害性
あげようって方向は、インターネットを生んだもともとの理念からして当然かも、って思った。

「情報共有（Ｐ２Ｐ）研究会」おつかれさまでした

行ってきた。
細かい感想は後日。全体的には、P2P入門からトラフィック量問題まで幅広い内容で楽しめた。
もっとディープに実装レベルの解説とかするのかとドキドキしてたがそんなことはなく、
P2P入門編なお話も多かったのでP2Pにあまり詳しく無い人でもわかりやすかった
と思う。もちろん実装レベルの話もあったので、そのあたりはプログラミングやって
ないとチンプンカンプンだったと思う。
ちなみにかなりボケナスな質問してたのが私。あはは…。

参加者はざっと４０人ほどだったと思う。申し込み自体は８７人あったそうだ。さすがに８０人は来てなかったと思う。
女性もちらほら見受けられた。オスばっかりだと思ってたのでちょっと吃驚。
質問してた人は NEC とか NTT グループとかドワンゴ（！）とかそういう人たち。なんかいろんな人が来てるんだな。

懇親会は当日申し込みでも参加できたんだけど、よくよく考えたら何かしゃべれるほどの
知識もないのに参加したら、部屋の隅でウーロン茶ちびちび飲んでるだけになるかと思って
参加しなかった。

ところで、誰も JXTA について言及してなかった。たまには思い出してあげてくださいね。JXTA だって構造化オーバーレイの実装なんだから。

あ、あと首藤さんが延々とキーボード打ってたのが印象的。すごい量だったけど、何を打ってたんだろう？

「情報共有（Ｐ２Ｐ）研究会」に行って来ます

明日29日は「情報共有（Ｐ２Ｐ）研究会」。
申し込んだんで行って来ます。

懇親会のほうは mixi に入ってないんで申し込めなかった。
残念。

DHTインスタンスを作る （ソースは分割して掲載 その２）

        // 初期接続アドレス
        String contactHostAndPort = null;
        int contactPort = -1;
        String contactString = null;
        if (cmd.getArgs().length >= 1) {
            contactHostAndPort = cmd.getArgs()[0];
            join = true;

            if (args.length >= 2)
                contactPort = Integer.parseInt(args[1]);
        }

        // initialize a DHT
        DHTConfiguration config = DHTFactory.getDefaultConfiguration();
        if (transport != null) config.setMessagingTransport(transport);
        if (algorithm != null) config.setRoutingAlgorithm(algorithm);
        if (routingStyle != null) config.setRoutingStyle(routingStyle);
        if (fWorkDir != null) config.setWorkingDirectory(fWorkDir.getPath());
        if (selfAddressAndPort != null) {
            MessagingUtility.HostAndPort hostAndPort =
                MessagingUtility.parseHostnameAndPort(selfAddressAndPort, config.getSelfPort());

            config.setSelfAddress(hostAndPort.getHostName());
            config.setSelfPort(hostAndPort.getPort());
        }
        if (noUPnP) config.setDoUPnPNATTraversal(false);

        DHT<Serializable> dht = DHTFactory.getDHT((short)0, (short)0, config, selfID);  // throws Exception

        StringBuilder sb = new StringBuilder();
        sb.append("DHT configuration:\n");
        sb.append("  hostname:port:     ").append(dht.getSelfIDAddressPair().getAddress()).append('\n');
        sb.append("  transport type:    ").append(config.getMessagingTransport()).append('\n');
        sb.append("  routing algorithm: ").append(config.getRoutingAlgorithm()).append('\n');
        sb.append("  routing style:     ").append(config.getRoutingStyle()).append('\n');
        sb.append("  directory type:    ").append(config.getDirectoryType()).append('\n');
        sb.append("  working directory: ").append(config.getWorkingDirectory()).append('\n');
        System.out.print(sb);

        try {
            if (statCollectorAddressAndPort != null) {
                MessagingUtility.HostAndPort hostAndPort =
                    MessagingUtility.parseHostnameAndPort(statCollectorAddressAndPort, config.getSelfPort());

                dht.setStatCollectorAddress(hostAndPort.getHostName(), hostAndPort.getPort());
            }

            if (join) {
                if (contactPort >= 0) {
                    dht.joinOverlay(contactHostAndPort, contactPort);
                    contactString = contactHostAndPort + " : " + contactPort;
                }
                else {
                    try {
                        dht.joinOverlay(contactHostAndPort);
                        contactString = contactHostAndPort;
                    }
                    catch (IllegalArgumentException e) {    // port is not specified
                        contactPort = config.getContactPort();
                        dht.joinOverlay(contactHostAndPort, contactPort);
                        contactString = contactHostAndPort + ":" + contactPort;
                    }
                }
            }
        }
        catch (UnknownHostException e) {
            System.err.println("A hostname could not be resolved: " + contactHostAndPort);
            e.printStackTrace();
            System.exit(1);
        }

        if (join) {
            System.out.println("  initial contact:   " + contactString);
        }

        System.out.println("A DHT started.");
        System.out.flush();

        return dht;
    }

}

だぁ、文字数制限があるとめんどくせぇ！
どっか別のブログに移動しようかしらん。

来週は put データ、送信メッセージを決めることにしよう。では。