[Skype]Skype勉強会を開催しようかと。

P2P勉強会の分会というわけではないけども、Skype勉強会を近々開こうと思っています。
Skype勉強会では
・基調講演
・技術面の講演（DHT,SIP,FW越え,VoIP等）
・Skypeの通信業界に与えた影響
の講演を有識者にお願いしたいと考えています。

そして、Skype勉強会としての特徴として参加者の皆様に発表できる時間を設けようと思います。（もしかすると代表者のみになるかもしれませんが。）
例えばこんなテーマなんてどうでしょう？
■Skypeをこんな風に使っています！
■Skypeにこんな機能を追加して欲しい！
■Skypeってこんな事に使えるのでは？

などなど。。

もちろん講演者が参加する懇親会も企画する予定です。
まずは勉強会の方針のコメントを頂きたいと思いますし、会場等を提供して頂ける方はご連絡をお願い致します。

[P2P]DHTを使ったスパムメール＆コメント対策の提案

スパムメールやｂlogのスパムコメント、本当に嫌ですよね。これをどうやって対処するかというのが今回の課題です。
最近でばベイズ理論を使ってスパムかどうか判断するらしいです。私はその辺の事はあまりよく知らないので勉強しようと思いますが。今回はまず単純な仕組みを使ってスパムフィルタリングをしてみましょう。

まずPCにDHTのミドルウェアを搭載しておくとします。また、メーラーが（あるいはBlogの作成ソフト）がDHTのミドルウェアと連携できるようにしておきます。

仕組みは簡単で、メールの内容（ヘッダーは除く）についてハッシュ値h1を取ります。また、同時にタイトルもハッシュ値h2を計算します。ちなみにヘッダーから最初に転送したホップ元アドレスのハッシュ値h3も計算しておきましょう。

スパムと思われたメールが来た際、あるいはメーラーが自動的に全てのメール（あるいはある程度ベイズ理論でスパムと判断したメール）については上記の手順に沿ってDHTのネットワークにNode_ID=h1となるノードに｛h1,h2,h3}を格納します。
（あるいは、{h1,h2,h3,count}というのがあって、スパムとみなした回数をcountとし、スパムが見つかった度にcount++をします。そしてcount ＞　count_limを超えた場合、本当にスパムと取る方法もあるでしょう。）

メールを受け取る際には、自動的にメールから{h1,h2,h3}を計算して、それらがスパムメールかどうか、DHTのノードから自動的に判断するというわけです。つまり、{h1,h2,h3}のうち、少なくとも2つが一致した場合スパムとみなします。

ここでハッシュ値を取る事がポイントです。というのはある文cetのハッシュ値をh_cetとすると、h_cetからcetを復元するのは非常に困難です。そのため、メールの内容はハッシュ値をDHTに格納しても解読できないと言う事です。
これはタイトル、ホップ元IPアドレスもいえます。（もっともホップ元IPアドレスは公開しても良さそうですが。。。）

ただ、この方法ももちろん欠点があって、メール毎に少し内容を変えているとこの手法の有効性は薄れます。
他のスパム対処方法と併用すると効果は上がると思います。

[P2P]位置情報とDHTの関連付けについて

ちょっと昔の話になるが、タクシーを使って面白い実験があった。
タクシーに通信機搭載、ワイパーがサイン
これは、タクシーに通信機能がついていて、ワイパーを動かすとその地域が雨である事を知る事ができるのだ。
つまり、非常に細かい精度で現在の降雨の状態が観測できる。

そうなると、タクシーの通信端末のミドルウェアにDHTを搭載して、日本中の降雨状態を細かく網羅できれば面白そう！ということを考えたわけです。

一番面白そうなのは、携帯端末（with GPS)で位置情報＋そこで取った写真とリンクさせる、コメントを書く、地図とリンクさせる、且つ他の人と情報を共有する！携帯端末にDHTのミドルウェアを載せるのは面白そうですが、定額制にならないといけないので、例えばウィルコムの端末がそういう機能を載せると面白そうです。（もっとも、データのアップデート、ダウンロードだけなら端末にDHTをミドルウェアを入れる必要はありませんが。）

もっと抽象化すると、ある位置情報とそれに関する情報をP2P、それもDHTを使ってどう扱えば良いのかということが面白くなりそうだ。そこでDHTで位置情報の取り扱いをどうするということを考えてみたい。

位置情報は基本的には2次元なので、2次元のハッシュ空間を利用すればこれらを収容できそうだ。
つまり、あるメッシュの大きさを決めて、そこに単位長さを導入する。ハッシュ空間(0,0)は、あるポイントを中心に単位面積をカバーする位置情報を保持する。(0,0)から北へ単位長さ１、東へ単位長さ１へ移動したエリアは例えば（1,1)tと定義する事ができるだろう。

ただ、2次元ハッシュ空間は扱いにくいのでこれを1次元ハッシュ空間に閉じ込める。例えばSHA-1は160ビットなので、上位80ビットを南北方向、下位80ビットを東西方向に割り当てる事ができる。こうすれば、Chord,Symphony,Pastryなどでも扱える事ができる。

ビジネスモデルだが、例えばこんな事が考えられる。
情報をDHTにアップロード、ダウンロードするだけであれば、無料でユーザに提供できる。例えば、自分の住んでいる今のエリアの面白い情報などを入手することができる。ただし、もし地図を使ってユーザにその場所についてわかりやすく図示するには、（地図を接続するサーバと接続させて）お金を回収するということが考えられる。
それだけでなく、プレミアムな情報を提供する時にお金を取る事も考えられるだろう。
こうすれば、業者が大きなストレージを管理することもなく、また多くのトラフィックを捌く事もなくなる。

携帯（モバイル端末）＋DHTはまだ先の話だが、面白いビジネスモデルが生まれそうである。

[英会話]英会話学校の粋な計らい

英会話が趣味と言うレベルまでいかないし、現在の業務上英会話が必ずし必要とも限らないのだが、それでも英会話学校に行っている。

その理由は、海外旅行によく行っているのでもうちょっときちんと喋りたいと思っているのと、TOEIC対策の2点である。今はイーオンに行っているのだが、ココは基本的に担当の先生・時間が決まっているのだが、振り替えが可能だることが嬉しい。

そこで今更ながら気づいた事なのだが、英字新聞やTIMEなどの英語雑誌が無料で持ち帰れる棚がある。
（新聞とかは恐らく誰かが読んだ後のものだろうけども。）
これはとてもうれしい計らいだ。英字新聞や英語雑誌は有料だとやる気がないとき以外には買う気にならないが、無料だったらレッスンついでに持ち帰って読もうかなっと思う。これから継続的に利用しようと思う。

さて英語ライティング能力をつけるために、他のBlogで英語の日記をつけようと思う。プライベートな内容となるので、ここではそのBlogのURLを紹介することはないだろうけども、そのうち探してみて下さいね。

簡単にライティング能力を上げるには、英語でメールを交わすことが上達の早道だと思うのだけどもなぁ。しかし相手がいないのが残念。。だれか気長（1週間に1～2通ぐらい？）に英語メールを交わしませんか？

[P2P]日本発のDHT型分散ストレージ？

2chのdatファイルを共有するP2Pソフトというのがo2on projectで進められている。
o2on project

最近、派生のThe o2on Networkでネットワーク図が掲載されたが、DHTを使うらしい。
（書き込んだ人にコンタクトを取ったら、DHTとして最初はchordを想定していたが、実装がより楽なSymphonyを考えているようだ。）

The o2on Networkネットワーク図
≪参考≫The o2on Network ～F99a.q80VE::WEBlog

2chとなると書き込みが多いから、その情報をサーバで管理するとなると大変なコストがかかるはずだ。となるとP2Pでそれらを蓄積するのは自然な流れである。
もしこれが完成すればコンシューマ向けとしては初の大規模DHT型分散ストレージとなる。そしてこの成功後は2chは完全なDHT型分散掲示板に移行していくのかもしれない。随分先の話になるが。。
いずれにせよDHTが日本でブレークするきっかけになれば嬉しい。

ところで、DHTのストレージというと、OceanStoreやPASTが有名である。
OceanSoreはTapestry、PASTはPastryを使っている。

OceanStore
http://www.jiten.com/dicmi/docs/o/8708.htm
http://oceanstore.cs.berkeley.edu/

PAST
http://research.microsoft.com/~antr/PAST/default.htm

DHTでの分散ストレージの仕組みだが、PASTを例に取って簡単に説明しよう。
あるデータのハッシュをhash(data)とすると、Node_ID=hash(data)となるノードにデータを格納するのだが、ノードの突然の離脱からデータの散逸するのを防止するため、先ほどデータを格納したノードをAとすると、Nextnode(A),Nextnode(Nextnode(A))...にもデータを格納する。ちまみにNextnodeとは、ノードAのハッシュ値が大きい方の隣のノードを指すこととした。

これらの論文を元に、色々と改良を加えて欲しい。
最終的にはP2P-ProxyやP2P-Wiki,Blogを加えた総合コミュニティサイトに変貌するんだろうなあ。
もし、そのようなサイトに成長したならセキュリティ問題（匿名性のバランス、DoS対策等）をどう扱うかが大変興味がある。
今後も頑張って欲しいプロジェクトである。

[ヴァイオリン]重音の練習

夏の発表会にタルティーニのソナタを弾くのですが、（※有名な「悪魔のトリル」ではありません。。）重音が多いので、小野アンナのヴァイオリン音階教本で3度の重音によるスケールの練習を開始。重音の連続した曲はあまりしてなかったので、基礎をみっちりつけないと、と思っています。

弦楽アンサンブルの方はヴィヴァルディの「四季」から「夏」を弾く予定。あまり印象がなかったのですが、久しぶりに聞くとこれがイイ曲なんです！早いパッセージなどが多くて大変ですが、こちらも頑張りたいと思います。
そういえば、ギトン＝クレーメル演奏の「四季」のCDあったよなぁ。(確かピアソラの「ブエノスアイレスの四季」がカップリング」）探してみようと。

余談：
今、ケージの「プリペアド・ピアノのためのソナタとインターリュード」を高橋悠治氏の録音で聴いています。他の人の演奏も聞いたことあるのですが、こっちの方が全然カッコいい！アフリカンな感じがしてなかなか良いですね。

[P2P]DHTコミュオフ会について

MixiのDHTコミュが50人弱になりましたので、オフ会でも開こうと思います。
Mixi　DHTコミュ

まだ全然決まっていませんが、
１）懇親会のみ
２）ミニプレゼン＋懇親会
のいずれかを予定しています。ミニプレゼンがあると会場を手配しないといけないので、プロジェクターなど用意できる！会場なら手配できる!と言う方ご連絡をお願い致します。

予定は５，６月の金、土、日のいずれか。（ミニプレゼンがあるとすれば日曜日。）
おそらく10～20名ぐらいの参加になると思います。
連絡・調整についてはDHTコミュで行って頂ければと思います。

[P2P]DHTによるサーバレス・マルチキャストシステムの提案

今回はサーバがなくても、DHT（分散ハッシュテーブル）を使って自律的にマルチキャストNWを修復するシステムのシンプルな例を提案したい。PeercastのようなものをDHTで実現するためにはどうすればよいか？という問題である。

◇マルチキャストの基礎知識
DHTでマルチキャストを行うのであれば、アプリケーションレベルのマルチキャストとなる。
ところで、マルチキャストを行うには配信先ノードを頂点としたツリー構造が望ましい。つまり、この問題はDHTでツリー構造を構築し、さらに自動的にそれを修復するモデルを提案できれば良いことになる。

■基本原理
まずはスマートさなどを考えずに素朴にDHTでマルチキャストを実現する方法を考えてみよう。

１）配信元ノードA0はNノードに対して配信することができるとしよう。一般に自分の帯域、CPUパワーによってマルチキャストできるノード（つまり子ノード）は限定すべきである。これを各ノードXの配信ノード数N_Xと定義する。

２）配信ノードA0と接続したいノードはまず、A0に聞いて、配信ノードの子ノード数がN_A0に達してないか確認する。達してなければ、A0の子ノードとなる。このとき配信ノードA0の子ノードなので、A1_iとしよう。（iはA1のノードのi番目とする）

３）もし、A0の子ノード数が配信ノード数N_A0に達してれば、A0の子ノードA1_jに対して接続要求を掛ける。これもA0と同じようにN_(a1_j)以上に子ノードが存在するか確認する。

...このようなことを再帰的に行う。

４）マルチキャストツリーに参加できると、ノードA(i)_jはA(i-2),A(i-1)のノードを知っている事になる。つまり、直接の親ノードA(i-1)がなくなってもその親ノードA(i-2)からまた再帰的に接続要求を掛けて、新たなノードにつなげればマルチキャストツリーは修復する。

■応用編
基本原理でもマルチキャストツリーを構築する事ができたが、これは結構面倒だ。例えば親ノードが離脱した場合、
マルチキャストツリーに再参加するには時間がかかる。

そこで、DHTを使ってよりスマートなことを考える。
つまり、あるノードにマルチキャストツリーのトポロジー状態を記録させてしまうということだ。

１）配信元ノードA0は、充分帯域があり既に長時間DHTに参加しているノードZにマルチキャストツリーの状態を記録させるようにする。なお、A0がZを兼ねても良い。

2)参加するノードはノードZのマルチキャストツリー情報を入手する。この情報より最適なノードと接続交渉をする。

3)接続交渉がうまく行けば、マルチキャストツリーに参加できる。また、ノードZにマルチキャストツリーの変更を申し出る。参加したノードPは、まだ新たに接続が可能なノードをノードZの情報からランダムにQだけ抽出すること。これをノード群Qとしよう。ノードPはノードQとリンクをしておく。

4)ノードPは親ノードが落ちた場合、速やかにノードZに知らせてマルチキャストツリーの変化を申告する。それとともに
ノードPはノード群Qからノードをひとつを選び、マルチキャストに参加する。その情報を元に、マルチキャストツリーの変化をノードZに申告する。

マルチキャストツリーを管理するノードZには多くのノードから参照がかかる可能性があるので、マルチキャストツリーの情報を分割して、あるノード群で管理するのも良いだろう。

今回の提案では接続するノード数を端末毎に異なる事により、ノードによる性能の大小を有る程度考慮している。ただし、例えばCPUの負荷が他のアプリケーションによって突発的に変わったりした時の対処は考えていない。
このときには子ノードとの接続を強制的に切断することで、自分の負荷を下げる事などが考えられるだろう。
また、ノード間の遅延についても考慮すべきだろう。これをどのように対処するかは皆様のコメントを頂きたい。

[P2P]自己署名証明書を用いたDHTにおける認証について

P2P勉強会ではP2Pの認証でPKIのアプローチを取ると、容易且つ正確に認証が行える事を講演した。
詳しくは以下のページを見て欲しい
P2Pによる認証

ところで、P2P勉強会で、自己署名証明書を使ったアプローチがあるのでは、というコメントがあった。
自己署名証明書はCAなどによく使われる証明書であり、自分の公開鍵を自分自身の秘密鍵で署名した物である。
つまり、自分自身の存在を自分自ら表明したものである。
自己署名証明書とは？

コレを使うと、CAがなくても自分自身の存在を表明できる。DHTで自己署名証明書を使って認証をする方法は以前提案したPKIと同様なアプローチなので省略する。つまり、ある人nameの自己署名証明書dig(name)はNode_ID=hash(name)となるノードに格納され、これが全てのノードから参照できるようにすれば良い。

では、自己署名証明書を使ったメリット・デメリットを整理しよう。

・メリット
☆CAなどのサーバが不要。よって運用コスト、初期費用はほぼ０。
☆だれもが自分自身の存在を証明する事が可能。

・デメリット
☆同じ名前の自己署名証明書を意図的にたくさん作ることができる。
☆ある悪意を持ったユーザの証明書の無効を完全には難しい。
☆あるユーザの秘密鍵がもれた場合の証明書の無効を完全に行うのは難しい。
☆本当にDHTに参加して良いノードかどうか審査することができない
☆あるユーザが多数の証明書を使い分けていることを検証するのが難しい。

ただし、デメリットの数点は改善することができる。
☆同じ名前の自己署名証明書を意図的にたくさん作ることができる
⇒自己署名証明書をNode_ID=hash(name)に登録する場合、既に登録されているnameでは、登録ノードがその登録をはじくようにすれば良い。

☆ある悪意を持ったユーザの証明書の無効を完全には難しい。
ユーザの中からスーパーユーザを募集し、スーパーユーザ権限を与える。これはスーパーユーザが悪意のあるユーザの証明書についてCRL（失効リスト）をつくり、それをDHTに格納する。この方法だとスーパーユーザに悪意のある人がいると、破綻する可能性がある。

☆あるユーザの秘密鍵がもれた場合の証明書の無効を完全に行うのは難しい。
方法は２つある。
方法１）自らの秘密鍵を使って、スーパーユーザに失効届けを出す。スーパーユーザは失効届が正当であることを検証してから、CRLを作成する。
方法２）自らの秘密鍵を使って、失効したという証明書をNode_ID=hash(name)に格納する。

これらの方法はお互い補完的で、まず方法２でユーザの影響を最小限に留め、時間が経つとスーパーユーザによるCRLによってブロックするとすれば良いだろう。

☆本当にDHTに参加して良いノードかどうか審査することができない
この辺は難しい問題だ。一つのアプローチとしてEigenTrustを使う事があるだろう。
EigenTrust～「今日の井原」から

自己署名証明書によると緩やかな信頼の和、コミュニティができることが期待できる。またこの方法ではとてもコストが低い事が魅力的である。ただし課金を行う、ビジネス的に信頼性を保障するとなると、このアプローチでは限界があって、信頼性を担保する人または機関、すなわちPKI的なアプローチを取るべきである。

[P2P]DHTによるコンテンツ管理システムの提案

先日P2P Todayで紹介されたcedさんのBlog「分散ハッシュテーブルとクリエイティブ・コモンズ」に触発されて、これを技術面で議論したいと考えている。

基本的には私のHPに書いてある2つの記事がベースとなる技術である。
「P2Pによるコンテンツ流通、課金」
「P2Pと認証」

大きな流れは次のとおり：

１）著作権者はコンテンツについて、コンテンツの流通条件、利用条件、購入価格等を書いたメタデータを作成する。
コンテンツとメタデータのバインド方法は、コンテンツのハッシュ値を使う。すなわち、メタデータにハッシュ値を入れ、このメタデータを著作権者によって電子署名することにより、第三者による改ざんを防止する。なお、著作権者の公開鍵は著作権者用CAによって保障されている。

２）コンテンツが流通するときには基本的にはメタデータも一緒に流通させる。なお、著作権者はDHT（分散ハッシュテーブル）上にメタデータを蓄積させて置く。

３）DHTに著作権者の電子証明書を公開させておく。

４）ユーザがコンテンツを利用する時にはメタデータを参照することになる。なお、メタデータが一緒に流通してない場合には、コンテンツのハッシュ値からDHTに蓄積されているそのコンテンツのメタデータを検索することになる。

５）ユーザはメタデータが本当に正しいかどうか、DHTに蓄積されている著作権者の電子証明書によって検証する。
検証がうまく行けば、ユーザはコンテンツを利用することができる。

５’）ここで、新たなDRMを導入することが考えられる。そのDRMは導入したメタデータによって利用、課金が出来るシステムである。また、メタデータをコンテンツ編集ソフトが理解することにより、新しい著作物＋メタデータが生まれ、それがコンテンツ流通させる事が考えられる。

※例えば、コンテンツの2次利用をする場合、コンテンツの再編集した人の電子署名に、さらに再度コンテンツを作成した1次著作権者の承諾（つまり電子署名）をして、コンテンツ流通させることが考えられる。この場合、メタデータは著作権者に対して入れ子（ネスト）構造となる。なお、メタデータに2次利用が無条件で認められている場合はこのような承諾は必要ない。

ざっとこんな感じである。
このモデルの上手い点はコンテンツのハッシュ値がキーになって、コンテンツとメタデータのバインドができるだけでなく、サーバレースでもメタデータの検索を行う事が出来る点である。（つまり、最悪の場合ノードがDHTに参加できればコンテンツと一緒にメタデータを流通させる必要はない。）

[P2P]Mixi分散ハッシュテーブル（DHT)コミュニティ作りました

DHTについて、いろいろと気軽に情報交換、ディスカッションできるようにMixiにコミュニティを作りました。
気軽に参加して頂ければと思います。
http://mixi.jp/view_community.pl?id=128733

※Mixiに入っていないけども、上記コミュニティに関心がある方はDHTのエピソードを添えてご連絡をお願い致します。

[P2P]DHT+SmallWorld講演資料

3/11（金）のMixiべき乗則とネット信頼通貨オフ会で、「DHT（分散ハッシュテーブル）とスモールワールドの関係」というタイトルでミニプレゼンをしました。
内容は先日紹介した、DHTのSymphonyを簡単に説明したものです。

プレゼン資料置き場
http://homepage3.nifty.com/toremoro/study/study.html

コメント等ございましたらご連絡をお願い致します。

[P2P]スモールワールドを応用したDHT：Symphony

P2P勉強会でDHT（分散ハッシュテーブル）について講演した際、DHTにスモールワールドを応用したら面白そう、と言ったら既にそういう論文があるということを教わった。その代表例がSymphony。

スモールワールドといえば、全世界のランダムに選んだ人間同士が6人の知り合いを介すれば実は繋がっているということを説明した事で有名で、現在とても盛んに研究されている分野だ。経済物理学や社会学にも応用されているとのこと。

Symphony：Distributed Hashing In A Small World(2003) Gurmeet Singh Manku,Mayank Bawa,Prabhakar Raghavan

論文
プレゼン資料

特徴：
・ハッシュ空間は1次元。Chordのようにリング型。
・隣接ノードについてはリンクが必要。他のリンクについてはランダムに決める。
ただし、その確率分布は基本的に自分のノードからの距離（ハッシュ的な）に反比例。つまり、距離が近いほどリンク先（元）になる確率は高くなる。
・ルーティングはリンクされているノードのうち、そのハッシュについて（時計回りで）近い方へルーティング。
・ホップ数はリンク数を2k+2とすると、O（[log(N)]²/k)　残念ながらChordよりは効率悪そう。
・リンク数が少なくてよい。ChordなどはO(log(N))だが、リンクが数10あれば充分のようだ。
・ルーティングテーブルが少ないのと、仕組みが簡単なので実装は他のDHTよりも容易そう。誰か実装やってみない？またノードの負担も少ないだろう。。

とても面白い論文なので是非チェックしてね！
※明日はMixiのオフ会でこの話題を講演する予定です。
http://mixi.jp/view_event.pl?id=545107

[セキュリティ]匿名性は必要か？

匿名というと、なんだかあまり良い感じを受けない人も多いだろう。例えばWinny,Shareのようなコンテンツアップロード者を隠蔽するシステムを連想される方もいると思う。

では匿名性は果たして必要なのか？私の答えは「Yes」だ。ただし、その匿名性の強さはケースバイケースであることをはじめに言っておく。

そもそもなぜこのようなことを今回書くかというと、私の会社で自分の業績に対する報酬や評価、上司に対する評価に対するアンケートをすることになったからだ。このようなアンケートをフェアに答えるには、やはり回答者を保護をするべくきちんとした匿名システムを介したほうがアンケート回答者にとっても望ましいし、企業にとってもそのような匿名が担保しておけばきちんとした回答が得られ良いフィードバックが生まれると思う。

要するに自分に不利益が与える可能性があるアクションを促進させるには匿名をきちんと考慮したシステムが必要となる。
今回のような、率直な意見をいうことができるためのアンケート、内部告発のためのシステム、電子投票に対してはどうしても強固な匿名システムが必要である。

では、強固な匿名システムを例えばWEBアクセスなどに用いれば良いのかというと、これはちょっと疑問だと思う。
というのは、もし強固な匿名システムができたとすれば、掲示板は悪質なコメントが増加する可能性もあるし、あるいは犯罪の温床になるかもしれない。このような、ある程度匿名性が要求されるものについては、管理者によって必要とあれば送信元が特定できるのが望ましいと考えられる。

P2Pになると状況はよりシリアスになる。DHTだろうがHybrid-P2Pであろうが、最終的にはP2Pで通信するから相手のIPアドレスを見ると所属等が判明する場合がある。これには場合によっては、プロキシなど弱い匿名性が必要なのかもしれない。（※注意：上記P2Pで私が示しているケースはファイル交換でなく、インスタントメッセンジャーやVoIPなどを意味しています。）IPv6の時代になればP2Pはもはや普通のシステムとなるだろう。

結論としては、ユーザのプライバシ・利便性を考慮して、それに適した匿名性レベルを持ちうるシステムを使う事が必要であるということだ。匿名性を最初から「悪」のように決め付けるのは全くのナンセンスである。
とはいえ、強固な匿名性を持ったシステムが犯罪などの温床になることは確かであり、PGPがゲリラの通信に使われ問題になったことがNHKの特集で放送されたことを強く記憶に残っている。
匿名性のメリット・デメリットについてはユーザ（特に開発、技術者）に対して情報教育をしっかり行うしかないのかもしれない。

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

P2P勉強会で首藤氏がP2Pとグリッドとの関連について話した。
それとはほとんど関係ないのだが、DHTを使ってグリッドを構築する事は可能なのかな？と少し思ったのでメモしてみる。
※ちなみにグリッドについてはほとんど知らないので、全然的外れだったらゴメンナサイ。。。

あるノードAについてはジョブを持っていて、それを数個のタスクに分解する。そのタスクをあるノード群に処理させて、
それをまたノードAに戻す。。基本的にはこんな流れだ。

DHTを使えば全てのノードに対してタスクを投げる事が可能だ。今のグリッドではどのぐらいのノードまで管理できるかわからないが、DHTを使えば数10億ノードに対してタスクを分解して処理を任せることができる。ルーティングについてはDHTに任せてしまい、タスクについてはランダムに振ったハッシュ値の管理するノードに任せようとするわけである。

こう考えると色々と課題があります。

１）ノードは処理能力についてバラバラである。どうすればよいか？
例えば、あるタスクを複数ノードに投げる。ここで一番早く処理が帰ってきたノードの結果を採用する。
処理のターンアラウンド時間とノードがDHTに留まっている時間を考慮すれば、いずれはノードがそれを学習して処理スピードが早いノード群に分散して処理を投げると言う事になる。あるいは、簡単な処理だが数が多いものについては、多少処理時間が遅いノードに任せると言う手もある。
こういうことが自律的にできればいいなぁ。

２）DHTからノードが離脱する場合があります。どうすればいい？
これも複数ノードに同じタスクをさせることで回避できます。

３）複数ノードに対して処理を投げるとその処理が大変そうですが。。。
これは、アプリケーションマルチキャストをすることで行えば大丈夫だと思います。
つまり、ノードAはノードBに処理を委託しますが、実際にはノードB⇒ノードC,D,E,Fだったりします。
またノードCがその処理が重く、その処理を分割できそうであれば更にノードC⇒ノードG,H,I,Jなどに分割してタスクを渡します。
このようにタスクに応じて、マルチキャストみたいに処理がノードに「自律的に」分割できれば面白そうですね。

４）タスクはきちんと分散されるの？
ハッシュ値は乱数で決まるので最初は分散されるはずです。ノードがレスポンス状態を学習していくと、性能良いノードにある程度負荷をかけ、性能に劣るノードは軽い処理を主に行うようにします。ただし、ノードに対してある閾値い以上に負荷をかけないようにします。

５）学習した結果はどうするの？
DHTを使って、性能が良いノードについては登録できるようにすれば良いと思います。とは言え、登録されたノードだけ処理がかかるのはまずいので、最初はランダムで負荷分散処理をさせ、性能が劣化した場合登録されたノードを使用するということが考えられます。そうすれば、新しいノードで性能の良いノードが見つかる可能性があります。

こんな感じかな。個人的には面白そうなんですけども、だれかやってみる方いらっしゃいませんか？

[P2P]P2Pプロキシでなにか面白いことができるか？

昨日書いた、「ソーシャルブックマーク＋WEBブラウザ＋P2Pで何ができる？」の続編。
WEBブラウザにP2Pミドルウェアを埋め込むと、色々と可能性が出てくるのだが、今回はP2Pプロキシに焦点をあてる。

昨日のBlogに唯石さんからトラックバックを頂いた。ありがとうございます。
面白いなと思ったのは、プロキシのキャッシュと同様に、一定時間WEB内容を蓄積して、ユーザからWEBサーバへの負荷を軽減すること。これはApacheでもできているので、作ろうと思えば出来そうだ。

さらに話はここで終わらない。ある時系列毎にそのキャッシュを保存しておく。すると、訂正された前の情報や削除された内容も見えるということだ。これは大変面白い。

WEBを丸ごと時系列に保存するということはサーバモデルで既に存在しているのだが、何よりもストレージにお金がかかる。これはP2Pによってそのようなコストを気にしないくてよいことになる。

ちなみにDHTを使ってP2Pストレージを作る話は論文ベースで既にある(例えばOceanstoreなど）ので、出来ない話ではない。また時間を使って、どの時点のプロキシにキャッシュされたページを溜めておくかについてはそんなに難しい話ではないだろう。

私はこの話をもっと発展させたい。すなわち、DHTに蓄積された（というかキャッシュ）WEBページを使って検索するサービスである。これはユーザが多ければ多いほど発展性のあるサービスである。
ユーザが参照したデータということは、ユーザが見たくてみたデータである。というとそれ自体が価値が高いデータ、あるいは人気が有るデータということなる。つまり、キャッシュされたデータはロボットで収集された一般的なWEBサイトのデータよりも内容が濃い可能性が高い。そこから検索されたデータはやはり内容的に濃い物だろう。

それだけでなく、何人が参照したか、どの時間帯に参照したかなどのデータを併せて表示するととても面白いサービスになるだろう。これでもDHTを使ってできると思われる。

P2Pプロキシは単に匿名性を高めるだけでなく、面白いビジネスモデルが生まれるかもしれない。

[P2P]ソーシャルブックマーク＋WEBブラウザ＋P2Pで何ができる？

最近ソーシャルブックマークの話題が活発である。私も先日のBlogでDHTによるソーシャルブックマーク（というかタギング）の構築について書いたところだ。
分散ハッシュ（DHT)によるソーシャルタギングの考察
ソーシャルタギングとBlogの組み合わせ（関連記事）

ところで、ソーシャルブックマークをWEBブラウザに搭載させることを考えている人がいるようだ。これにRSSリーダを搭載させてソーシャルブックマークと関連付ければかなり強力な情報収集の手段となりうる。
（ところで、ソーシャルブックマークも足跡みたいなものがあればイイと思いませんか？Mixiの足跡も結構気になるので、人と人との繋がりを生み出すのには良いのでは、と思います。）

WEBブラウザは多くの人が使っているのだから、DHTのようなP2Pミドルウェアを組み込むと、P2Pインフラとして巨大なシステムができいる。先ほど言った、ソーシャルブックマークはもちろんDHTで実現できる。それだけでなく、コレだけ多くの人が参加できるとP2PストレージやGrid的なアプローチも面白くなるはずだ。

RSSリーダもDHTを使って共有できることになる。（これはP2Pである必要はないが。）例えばあるカテゴリのRSSリーダについてはAさん、他のカテゴリーはBさんのを使う、なんてこともできる。

WEBブラウザがP2P的なアプローチを取ると一番便利なのは恐らくP2Pプロキシのことだろう。ユーザ自身がプロキシになるから、誰からアクセスしたか全く分からない事が可能だ。ユーザはカスタマイズが可能で、あるURLに対してはP2Pプロキシ、他は通常の接続にするなどが可能である。

他で面白いとすれば、ユーザの履歴をデータマイニングすることもできる。データマイニング自体はサーバでも可能だが、多くの計算の必要があるので、Grid的なアプローチを取るといいだろう。もっともユーザ履歴をどこまで使うかは問題があるが、例えばこのP2Pソフト作成者への利益報酬の一つの形になるかもしれない。

WEBブラウザはユーザが必ず入れているものだから、これにP2Pミドルウェアが入れば、劇的にインターネットの世界が変わるかもしれない。今はサーバでできることを単にP2Pに落とし込む程度のものしか考えていないが、もっと面白い世界がきっと生まれるだろう。

話に筋が通っていませんがちょっとしたメモでした。

[P2P]DHTの時間的考慮

P2P勉強会では様々なテーマを元に講演が行われたが、特に今回興味深かったのはNAISTの飯村氏の「P2Pゲーム」についての講演だった。資料については、下記のページに置いてあるので参考にして欲しい。
http://homepage3.nifty.com/toremoro/study/study2.html

そこで飯村氏が注目していたのは、時間によるユーザ数の変化である。
つまり、夜はユーザが多く朝は少ない。

DHTでゲームを構成する場合、ゲーム人数が多い夜はもちろん考慮しないといけないのだが、ユーザ数が少ない朝だと、他のプレイヤーの保持しているデータを少ないユーザで分割統治する必要があるので、ユーザ負担が大きくなる事が考えられるのだ。この辺のことをきちんと考慮しているDHT研究開発者は少ないのではないだろうか？

となると、これを解消するには以下の2つのアプローチが考えられる。

１．事業者等がサーバを用意し、サーバがDHTに参加する。このときにサーバがバーチャルで複数のノードを管理するように見れれば、ユーザ数変化によるユーザ負担が少なくなる。

２．事業者等（またはユーザの協力の下）が常にDHTに参加しているノードをある程度用意する。

いずれにせよ難しいのだが、１．のアプローチだと事業者の負担が重いので、ビジネス的には問題があるのかもしれない。

飯村氏は講演を締めくくるにあたり、全世界にユーザが散らばれば、時差の関係からそのような時間によるノード数の変化はおこりにくくなるだろうと主張した。確かにそうで、凄い発想だなぁ、と思った。

今後も飯村氏の研究に注目していきたい。