« 2004年3月 | トップページ | 2004年5月 »

2004年4月の27件の投稿

2004.04.27

[P2P]信頼されたメッセージの処理について

P2Pについての認証について今までいろいろと書いてきた。さて、今度は信頼できるメッセージ処理について書いてみたい。

分散ハッシュの場合、ある人の名前nameについての公開鍵p_keyはNode_ID=hash(name)のノードに蓄えられるようにしたほうが良い。自ノードが公開鍵を配布しようとすると、他ノードは自ノードのIPアドレスを知る必要があるので匿名性が弱まるばかりか、簡単に該当ノードを検索できない場合があるためである。その理由の一つとしてノードがいつもネットワークに参加しているとは限らない事が挙げられる。

さて、あるノードが他ノードに処理を依頼する場合、そのノードが確かに処理する権利があるか確かめる必要がある。例えば、メールの削除、掲示板への登録、削除、BLOGへの登録・削除などである。このときに有効なのがメッセージとしてXMLを利用し、それに電子署名を行う事である。つまりメッセージについてはXMLで柔軟に記述し、これを秘密鍵s_keyで電子署名をする。メッセージを受け取ったノードは分散ハッシュの原理から簡単に公開鍵p_keyを取得でき、これから電子署名の正当性(つまりメッセージの正当性)を確認する。

また、信頼されたメッセージを使って公開鍵の更改をすることでも重要である。つまり、公開鍵の有効期限前に、新たな公開鍵に更新する作業である。何らかの原因で秘密鍵が他ノードに漏れた場合や秘密鍵を紛失した場合(鍵の失効)についてどう対処するか今後検討しなければならない課題だろう。(PKIでは、これらの方法については解決方法がある。
詳しくは「証明書の有効性」を見て欲しい。)

XMLの電子署名は既に幅広く行われている。詳しくは下記のURLを参照。後者の方がより詳しい解説がある。
XML暗号化の基礎と実践
XMLデジタル署名とXML暗号

P.S.P2P勉強会についてですが、今のところ複数の知人に交渉をしているところです。DRMの話やネットワークの話について講演をして頂くように調整中です。また講演して頂く方を引き続き募集中です。BLOGについては帰省等により一週間弱お休みさせて頂きます。

| | コメント (0) | トラックバック (0)

2004.04.25

[P2P]P2Pとマジックプロトコル

昨日のBLOGでセキュリティの話を講演するかもしれないと書いたので、セキュリティ関係の話題を探していたのだが、一回紹介してみたいネタがあったので今日はそのことについて書いてみたい。

さて、P2Pで通信することになると、当然サーバはいない。クライアント=サーバモデルの良いところはサーバが認証や公平性等を担保してくれる機能があることである。P2Pは不特定多数の人がノードとなるので、当然認証や公平性の話はややこしくなる。

ところで、セキュリティの世界にはマジックプロトコルという面白い分野がある。例えばP2Pでオセロをしたいとする。このとき、先攻と後攻のじゃんけんをするとしよう。クライアント=サーバモデルであれば、このじゃんけんは公平性があるものになる。しかし、普通に考えるとP2Pでじゃんけんを実現するには難しそうだ。

その理由として例えば相手がパーを出したとしても、後出してチョキを出す事が可能だからだ。なにかあったらネットワークの遅延だなんだと理由をつけて、後出しでないと文句を言う事ができる。ところがマジックプロトコルを使うとそのようなことはできなくなる。

この話はブルーバックスの「情報セキュリティの科学」に書いてあるので、詳しくはそれを見て欲しいが(非常に読みやすくて良書である。)、ここでじゃんけんプロトコルの概要を書いておこう。今、P2PでAさんとBさんが通信していることとする。

1.Aさんは桁が同じ程度の大きな素数p,qを探し、r=pqとする。rのみをBに伝える。ただし、p>qとしよう。
2.Bさんはqの上から4桁目の数が偶数か奇数かを予想し、Aに伝える。(この時点でBはp,qが分からない事に注意する)
3.Aさんはp,qをBに伝える。Bは自分の答えが正しいかどうかチェックできる。

素因数分解が難しいことを利用したうまいプロトコルである。P2Pの世界では公平性を担保するためにこのようなマジックプロトコルが使われる事が期待できる。マジックプロトコルは、他にA、Bの2人のユーザがどちらがお金持ちか、相手に自分の所持金を言わずに分かるものなど、なかなか楽しいものが多い。

では、もう少しつっこんでゼロ知識証明についても話そう。これはA、Bがいて、BがAに対してパスワードを実際に言わなくても、Aに対してパスワードを持っている事を証明できるプロトコルである。なんだか奇妙に思えるかもしれないが、実際そのようなことが可能である。原理については下記のページを参照して下さい。
ゼロ知識証明の原理

不特定多数のノードに対して、自分のパスワードを教える事についてはそれを利用される可能性があるため危険である。このゼロ知識証明を使えば、パスワードが無くても自分がその権利を行使できるように主張できる。そのためP2Pソフトに認証等を行う部分があって、ソフト自体のハッキング等の耐性が強ければ、このようなゼロ知識証明は非常に意義があることだろう。もちろん、ゼロ知識証明を行っている時に中間侵入攻撃などは困難である。

マジックプロトコルやゼロ知識証明は一般にマルチパーティプロトコルと言って、非常に興味深い分野であるが、なかなか実用面に応用されておらず、電子選挙等に応用が限られている。不特定多数が存在し、サーバレスであるP2Pの世界でこそ、マルチパーティプロトコルは活かされるかも知れない。

もっとマルチパーティプロトコルを知りたい方は
「暗号・ゼロ知識証明・数論」共立出版が良書であるので、それを読んで欲しい。

| | コメント (0) | トラックバック (0)

P2P勉強会について

先日お知らせいたしました、P2P勉強会ですがP2P Todayの横田さんも講演に参加していただける事になりました。横田さん、大変ありがとうございました!

場所、日時等は調整していますが、多くの人が参加できるように現在6~8月の土曜日または日曜日の午後で東京近郊を予定しています。また、匿名での参加も可能です。

勉強会については、こんな感じでしょうか。

・13:00ぐらい 
横田さん(P2P Today) 「最近のP2Pの動向について」(仮)

・13:30ぐらい
Tomo 分散ハッシュの概要とその応用について(仮)

・14:00-14:30ぐらい
質問タイム、休憩(情報交換等)

・14:30-15:00ぐらい
Tomo P2Pとセキュリティ~認証、匿名性、課金、コンテンツ流通技術について(仮)

・15:00~17:00ぐらい
講演者求む!!(2、3人ぐらい講演者がいればいいなぁ。。)
⇒どなたか講演者を紹介して頂けないでしょうか?
講演者がいなかったら、
Tomo P2Pのホットトピックス(ファイアウォールやNAT越えの話など。)(仮)

・18:00-
希望者で軽く打ち上げ?アイデア交換会など。

講演したい方は是非ご連絡をお願い致します。もちろん匿名でも可です。
P2Pに関係すれば分野は何でも良いです。学会資料や卒論、修論等を発表しても、
自分のアイデアを発表しても大丈夫です。一応、私も講演者を探してみますが。。。
私の講演ですが、入門者からでも理解できるように資料は作る予定です。
(もちろん、P2Pの研究者にも関心を持って頂けるように資料は工夫したいと思います。)

プレゼン資料については、後日HPにアップする予定です。
P2Pストリームによる配信はできたらいいな、というレベルです。

みなさまの勉強会に対するアイデアお待ちしております♪

| | コメント (1) | トラックバック (0)

2004.04.23

[P2P]分散ハッシュPastry

さて、昨日のBlogでは分散ハッシュを使ってファイル共有にネットワーク近さの概念を取り入れる事を試みた。今回は分散ハッシュにネットワークの近さの概念を取り入れているPastryを紹介していきたい。
Pastryについては以下のページ、文献が参考になる。

Pastryについて
http://freepastry.rice.edu/
http://freepastry.rice.edu/PAST/overview.pdf

PastryはルーティングにPlaxtonアルゴリズムという面白い方法を取り入れている。例えばNode_ID=123456というノードのルーティングテーブルは、1番上の数字(つまり上から1桁目)が1以外であるノードの集合(これを集合1とする)、1番目の数字が1だが2番目の数字が2以外であるノードの集合(これを集合2とする)、1番目の数字が1で2番目の数字が2だが3番目の数字が3以外であるノードの集合(これを集合3とする),,,,というもので構成されている。上から最長一致したノードへ検索が転送されるわけである。

さて、上記の文献ではネットワークの近さを取り入れた方法について書いていない。これは以下の文献を見て欲しい。
Pastry

これを見ると、ノードが参加するときにルーティングテーブルを構築する方法が上手い。今、AとB、BとC、CとDがそれぞれネットワーク的に近いとしよう。そのときにZと言うネットワークが参加する。ただし、ZはAと近いとする。今、ZのNode_IDがDのNode_IDと近いとしよう。検索はZ⇒A⇒B⇒C⇒Dといくとする。このとき、ZはAからルーティングテーブル集合1を得る。次にZはBから集合2、Cから集合3...と得ることにする。ZとA、AとBが近いからといって必ずしもZとBがお互い近いとは言えないが、論文では結果的にZとBは近い関係であることを示している。そのため、このようなルーティングテーブルを持てば、ノードのネットワークに近い順に検索が行われる事が期待できる。

もっとこのことに知りたい方は次の論文を見て欲しい。

Topology-aware routing in stuctured peer to peer overlay networks

このような手法はP2Pマルチキャストを分散ハッシュで構築する時に活かされるはずだ。

| | コメント (0) | トラックバック (0)

2004.04.22

[P2P]ネットワーク負荷を意識したファイル共有

いろいろなブログで書かれているが、P2PにおいてISPのリソースをかなり消費している。そこで、自分のノードとネットワーク的に近いノードでファイル共有等が行われる事がネットワーク負荷の観点から望ましい。

以前、自分のブログでもそのようなネットワーク構成を意識したCDNを提案したが、今回は分散ハッシュを使ってもっとスマートにネットワーク情報を考慮したファイル共有を提案したい。

今、分散ハッシュを120bitとしよう。これを上位100bitと下位20bitにわける。上位100bitは通常の分散ハッシュのやり方通り、コンテンツの名前titleにおいてhash(title)を入れておく。

さて、下位20bitにはプロバイダ情報を入れておく。具体的にはネットワーク的に近ければ下位20bitのハッシュ値は近い事にする。例えば、同じISPで同じエリアであればハッシュ値は同じ、同じISPだがエリアが違う場合、ハッシュ値はお互い近く、国内ISPと国外ISPの接続であればハッシュ値は大きく違うようにハッシュ値の値を設計しておく。このハッシュ値の設計については、確かどこかの雑誌(INTERNET MAGAZINE?)に複数ISPのネットワーク関係が載っているので、それを使えばできるであろう。

このようにすれば、同じコンテンツを持っていても、検索結果はネットワーク的に近いノードとの通信へ誘導されることになる。ただし、この方法ではノードのISPによって検索しているコンテンツがあったりなかったりするので、それを考慮する必要がある。(最悪の場合、他のISPにはコンテンツがあっても検索できない)それを回避する方法を考えてみたが、例えばChordにおいてはハッシュ空間において右回りに近い順について複数ノードのIP情報があるので、同じISPにコンテンツがなくても検索要求を隣接ノードに投げる事で他のISPおける同じコンテンツの情報を入手する事が可能である。(それもネットワーク的に近い順に!)これでも最悪の場合はコンテンツ情報が入手できないことがあるが、そもそも120bitのハッシュ空間において、ノードの数は2^120よりずっと小さい事ので、そのような事態に陥る確率はかなり小さいだろう。

※あるコンテンツ名titleを要求するためには上位100bitをhash(title)に必ず下位20bitを自分のISPのハッシュ値を付けることが必要。

あるいはもっと単純に{hash(title),hash_ISP,Node_IP_Adress}をNode_ID=hash(title)に格納し、後はhash_ISPから一番ネットワークに近いノードを探索するということも考えられる。

いずれにせよ、ユーザの目でISP情報を追わなくても自動的にネットワークに近いところとファイル共有が可能となる。

今回のアイデアは不特定多数の通信よりも、むしろ全国的に事業を展開している会社内でのファイル共有等に使われるかもしれない。例えば、同事業所にあるファイルを優先的に取得することにより事業所間のネットワーク負荷を抑える事が可能である。

紹介したアイデアはまだ素案レベルを脱してははないが、今後ネットワークを意識した分散ハッシュの研究は盛んになる事だろう。

| | コメント (0) | トラックバック (1)

2004.04.20

[P2P]P2Pと分散ハッシュその2アップしました。

さて、ようやくChordを特集した「P2Pと分散ハッシュその2」をアップしました。

Chordについてはタネンバウム著の「コンピュータネットワーク第四版」にも詳しく載っているので、お時間がある方は目を通した方が良いでしょう。

さて、先日P2Pの講演会(というか勉強会)をやってみませんか?といったらP2P Todayの横田さんらからコメントを頂きました。確かに小規模の意見交換会の方がお互いためになるかもしれませんね。もし、私が参加する事になれば、セキュリティの話と分散ハッシュとその応用について紹介したいと思います。

問題は機器(プロジェクター、スクリーン)と部屋(都内の公民館とかでOK?)ですね。ボランティアベースで運営してもいいし、P2Pに関心のある企業・組織の方のご好意でお部屋を貸して頂けると助かります。

また、できればスペシャリストだけでなく、学生さんや面白いアイデアを持っている若手の方も是非参加しやすいようにしたいと思います。講演会のような一方的なコミュニケーションでなく、双方向的な意見交換がしたいのですから。

PeerCastなどを使って色々な人が意見交換間の模様を見てもらったり、匿名でパワーポイントの画面を同期させて、ボイスチャットを使いながら遠隔地からプレゼンを行うなんていうのも面白いかも知れせんね。何せP2Pの勉強会ですから(笑)

勉強会に対する皆様のアイデアや是非勉強会に参加したいと言う方はコメント、ご連絡をお待ちしております。

| | コメント (2) | トラックバック (1)

2004.04.19

[P2P]分散ハッシュによるP2P型Blogの考察

Noras氏のページから当Blogにリンクされているようです。リンク有り難うございます♪

リンク元のページではP2PによるBlogについても書かれていた。ということで早速考察してみました。(笑)

今回もChordを使ってBlogを作ることにしましょう。さて、先日P2P匿名掲示板について記事を書いた。Blogの場合は掲示板と違って、Blogの管理人のみがBlogを追記、訂正、削除できる権限がある。つまり、認証が必要なのである。P2Pについての認証は、まだ多くの人が検討してないようなので、今回はその辺を議論したい。

まず、管理人ノードAはP2Pネットワークに参加するため、GUIDを作成する。このとき、ノードAのNode_IDはGUIDである。また、鍵のペア(公開鍵、秘密鍵)を作成しておく。今、Blogのタイトルをtitleとしよう。Node_ID=hash(title)となるノードBに{title,公開鍵,GUID}を格納しておく。ただし、公開鍵は秘密鍵によって署名されている。

ここで、Blogの内容をblogとしよう。Blogは秘密鍵で追記毎に電子署名をしておく。また、Node_ID=GUIDとなるノード(これをノードCとする)に{GUID,blog}を格納しておく。つまり、ノードAがネットワークに参加している時には、ノードA=ノードCとなり、ノードAがBlogの配信ノードとなる。ノードAはChordのハッシュ空間でノードAから時計回りにr個に{GUID,blog}を複製しておく。これはノードAがネットワークから離脱してもBlogが見られるようにする処置である。

さて、ノードZがBlogを見るにはどうすればよいのだろうか?まず、titleを見つけ、それからノードBにアクセスする。
次にノードBから得たGUIDからノードCを見つける。ノードCからblogを得て、ノードBから得た公開鍵からblogの電子署名を確認し、blogを閲覧する。

電子署名を使う事により、他ノードによる改ざんはできない。また、Blogの追記ができるのはノードAだけである。ただし、ノードBやノードCによる積極的な攻撃、すなわちデータの消去によるアクセス不能状態を回避する事は難しそうだ。また、ノードCとノードBの協力の下ではBlogの「成りすまし」が可能である。この辺はまだ改良する余地がありそうだ。

P2Pによる認証というのはまだあまり研究が進んでない分野なので、もっと面白いことができるかもしれない。


| | コメント (1) | トラックバック (2)

2004.04.18

[P2P]次世代P2Pアプリの気になる動向。。

Ringochを見ていたら、821氏仕様メモのページに私のHPの分散ハッシュ記事へのリンクが。。(821仕様メモのページは多分直リンクはダメなので、各自でお探し下さい。)ちょっとびっくりしました。いろいろな人が分散ハッシュに関心を持ち始めたようです。これがうまく行けば検索効率が上がるだけでなく、P2Pメールやチャット、IM、掲示板も簡単に実装できそうですね。

ところで、
>まず、ハッシュの数値の大きさで、1次元平面を想定する。
これは多分近日中に紹介するChordという分散ハッシュを使えばできると思います。Chordは円状の一次元でハッシュ空間を形成します。先日もChordの資料を紹介しましたが、本で言うとタネンバウム著「コンピュータネットワーク第4版」に詳しく書いてあります。価格は高いですが。。。

>二次元平面・3次元空間にするともっと効率がいいかもしれない。
例えば、HPで紹介したCANの場合は検索時間でいうとノード数がNに対し、O(N^{1/d})程度です。ただし、dは次元数を表わします。ですから確かに高次元にした方が検索スピードは早い。(それだけ、仕組みを複雑にする必要があります。)しかしChordの場合はO(log(N))なので、非常に高速に検索できます。私はChordを勧める理由の一つがこの高速性にあります。

ちょっと気になったのでとりあえず、メモ。

| | コメント (0) | トラックバック (1)

パイプオルガンの響き。

今日は三鷹のICU(国際基督教大学)内のチャペルで行われるパイプオルガンの演奏会に行ってきた。
その前に、先日行けなかった三鷹北口のビストロ「グラン・ソレーユ」でランチ。知人からボリュームがあって美味しい!と聞いていたので期待が高まる。ランチは2種類あって、Aランチをチョイス。魚料理がメインで、2種類のグリルがあって、ボリュームも満点。これで2,000円(確か。。)なのは驚く質の高さ。是非近くの方は行って欲しい。

その後、初めてICUに行ったのだが本当に緑あふれるキャンパスでびっくりした。母校の大学はビルばっかりなのでこういう芝生があり、森に囲まれるキャンパスは憧れるなぁ。入り口からチャペルにまっすぐ伸びる緑のトンネルは優し雰囲気を漂いながら且つ荘厳で、神秘的な空間であった。

さてチャペルの演奏会ではバッハ、メンデルスゾーン、メシアンの曲が演奏された。まず、パイプオルガンからダイレクトに客席に音が届くのには驚いた。大ホールによくパイプオルガンがあり、その演奏会にも行った事が何度もあるのだが、音がこもったり柔らかすぎてしまいあまり気に入らなかった。このチャペルでは音が適度にシャープに聞こえて心地良かった。このような素晴らしい音響なのは武蔵野文化会館の小ホールのオルガン以来だ。

メンデルスゾーンのソナタが演奏されたが、これはパリの教会で聞いたことがある。今回改めて聞くと随分変化に富んでいる曲だなと思った。後でCDを買いたくなった。

さて、一番楽しみにしていたのはメシアンの「聖霊降臨祭のミサ」。もちろん、現代音楽に興味があることもあったが、実は以前武蔵野国際パイプオルガンコンクール入賞者のコンサートでミサ曲の終曲「閉祭:聖霊の風」を聞いて、その曲調の激しさに驚いたことがあったのだ。

実際にメシアンの曲を聞いてみると、やはりというか高音での鳥の鳴き声のモチーフが使われていた。あまりメシアンは聞かないしそれほど好きではないのだが、終曲での全ストップでの荘厳な音響の中で激しい動きを奏でられるありさまは素晴らしく、感動した。もっとも後ろにいた老夫婦はメシアンなんか興味ない!という感じだったが。(笑)
面白かったのは相当の数の音色を複雑に組み合わせながら演奏していたところ。音色がこのように変化に富むのは久しぶりなので、貴重な体験だったと思う。

ここでちょっと良い情報。このチャペルのパイプオルガンを秋のある一日、一般の人が演奏できるそうです。私はパイプオルガンを一度しか弾いてないので、今度はこの機会を逃さずちゃんと練習してきちんと弾いてみたいと思います。

| | コメント (0) | トラックバック (0)

[P2P]分散ハッシュによる匿名P2P掲示板

さて、近日中に分散ハッシュの一つであるChordついて解説するので、これを使ったアプリケーションを説明しよう。Chordについては先日のBlogを見て下さい。

P2P掲示板を作ろうということは既に積極的に行われている。特に、RinGochの皆様、リンクありがとうございます!P2P掲示板については、以前HPで議論したのだが、レスの順番等の合致性など結構厄介な問題が起こる。ところが、分散ハッシュを使うとこれを簡単に解決できる。

まず、スレッドについてGUIDをつける。レスはNode_ID=GUIDまたはhash(GUID)となるようなノードに蓄積する。(今後はNode_ID=GUIDとなるノードとしよう。)ノードには{GUID,タイトル,スレッド全体}が格納されている。これによってP2P全ネットワークから全く同じ内容のレス(それも一意的な)が参照できることに注意。つまり、今まで分散ネットワークでは解決が難しかったスレッド内のレスの順番や、欠落等の問題はもはや起こらない。

問題はNode_ID=GUIDとなるノードがネットワークから離脱した場合である。しかし、これもChordであれば簡単に解決できる。Chordはノードが欠落してデータがなくなることを防止するため、右回り(つまりノードが存在しているNode_IDで大きくなる方)でr個分のノードだけ自ノードにデータをレプリカすれば、そのr個全てがネットワークから同時に離脱しない限り、データは保持できることが提案されている。これを使えば、まずスレッドが半永久的になくなることはできない。

またスレッドを完全になくすには、Node_ID=GUIDとそれから右回りr個のノードが協力すればできる。といっても匿名空間ではなかなか難しそうですが。先日提案したP2P型IMやメールなどを使えばできないこともない。

P2Pアプリに興味がある方は分散ハッシュの導入を一度ご検討をお願いしたい。

| | コメント (0) | トラックバック (0)

2004.04.17

[P2P]ひとりごと。。

P2Pアプリで有名なArielさんのBlogから私のBlogについてのコメントを頂きました。tokurikiさん、ありがとうございます。
Ariel Blog

ここで、tokurikiさんは次のような事をコメントしている:

>エアワンの社内ルームでやっている議論をもっと発信していっても良いのかもしれないなぁと思ってしまいました。
特許やノウハウの絡みもあるので、全部は出せないと思いますが、有益な情報を資料化して頂くと大変助かります。このような事によりP2Pコミュニティも活性化すると思います。ちなみにGrooveは既に本が出版されているので、Airone関連の本を出版したらどうでしょうか?

特許絡みで思い出しました。最近Blogで書いている話題において私のアイデアをいろいろと書いていますが、これについては特許を申請していません。(HPに書いている技術は一部特許を申請しています。)現在、特許を書くだけのリソースがないことと、今の部署が特許に関して積極的でないこともありますが、アイデアを積極的に活用して頂きたいという狙いもあります。もっともアイデアをあまり精査していないので、自分のアイデアがかなりショボいネタだなというのも特許申請してない理由の一つですが。(笑)

Blogだと記事を書いた日付が載せられますから、防衛特許を書くよりは効率が良いのかもしれません。自分のアイデア等を主張するのもBlogの良いところですが、これらのアイデアが勝手に第三者によって特許申請されるのを防止するため、信用できる機関がそのブログについて電子書名、タイムスタンプする事ができれば面白いと思います。そのうち、著名人が書くブログ向けのそのようなサービスができたりして。

さて、だいぶ話がそれてしまいました。P2Pの情報共有についてだが、なかなか最近の技術動向をカバーしている雑誌や本がなくて非常に困っている。特にSTUNなどのファイアウォール越えの技術や分散ハッシュについては雑誌で積極的に特集してもいいのではないか、と個人的には思っている。最終的にはこれらの技術が本として売られるとうれしい。もちろん、WEBの情報でも良いのだが、やはりWEBだと載せられる情報ボリュームが少ないので、紙でのメディアが重要だと感じている。

AmazonでP2Pを検索して思うのだが、現在出版されている本はP2Pの萌芽期の技術については述べられいるが、それ以降のトピックについてはなかなか詳しく述べられていない。ただし、最近アドホックネットワークやグリッドに関する本が出てきた事は大変意義があることである。

どなたか、P2Pの技術面についてつっこんだ本あるいは雑誌の特集を書きませんか?そうすればもっとP2Pコミュニティは発展すると思うのですが。。。Janogみたいに誰かがスポンサーになってP2Pのカンファレンスを開き、後で資料をWEBで配布するというのも良いアイデアだと思います。P2P Todayの横田さん、どこかの雑誌でP2Pネタを連載してみませんか?

| | コメント (3) | トラックバック (0)

2004.04.15

[P2P]分散ハッシュとP2Pマルチキャスト

先日、オーバレイネットワークの統合分散環境という資料を紹介したが、この資料内で分散ハッシュを応用して簡単にP2Pマルチキャストができる方法が書いてあったので、噛み砕いて説明することにする。

さて、今ノードAがB、C,Dに対してP2Pマルチキャストをすると仮定する。このマルチキャストにIDを設定することにしよう。マルチキャストに振るユニークなIDをmulticast_IDとする。B,C,DはNode_ID=hash(multicast_ID)(これをノードPとしよう)にmulticast_IDと次ノードIPのペアを格納する。つまり、ノードPに格納するデータは{(multicast_ID,IPadress_A),(multicast_ID,IPadress_B),(multicast_ID,IPadress_C)}となる。

AがB,C,Dにマルチキャストする場合、A⇒Pにデータを投げる。Pはデータを複製してB,C、Dにデータをマルチキャストする。(もちろん、PからB,C,DのIPAdressを入手してAが直接B,C,Dにマルチキャストする事も可能)マルチキャスト先ノードの追加、離脱が簡単にできることがわかるだろう。

この方法が面白いところは、マルチキャストをツリー階層にすることが可能な事である。つまり、今はmulticast_IDを使ってA⇒P⇒B,C,Dとしたが、新たにmulticast_ID2(E,F,GへのマルチキャストのID)というものを設け、これをPに(multicast_ID,multicast_ID2)と登録すれば、Node_ID=hash(multicast_ID2)のノードをQとしてA⇒P⇒B,C,D,Qとなり、さらにQ⇒E,F,Gとすることが可能である。この考えをうまく使えば自律的にP2Pマルチキャストを制御すること(例えばノードの離脱に対して自律的にすみやかにマルチキャストのツリー構造復元する)も可能かもしれない。

分散ハッシュによるP2Pマルチキャストはノードの頻繁な離脱、参加にも耐え、また多くのノードが参加できる点で魅力的なモデルと思える。まだまだ研究する余地はあるだろう。


| | コメント (0) | トラックバック (0)

ロボットとバイオリン

本日、4000Hitを達成しました!ありがとうございます。今後も興味深い話題(このところP2Pばっかりですが。笑)を取り上げていきますので、是非チェックして下さいね。

さて、今までで一番コメントを頂いた記事はP2P関連ではなく、意外にも「ロボットと楽器」という記事だった。ということで本日はその話題について書いていきたいと思う。

Blogではバイオリンを演奏させるのは難しそうだな、と思っていました。ただ、昔から機械仕掛けでバイオリンを弾く装置はあったので、できなくはないのかなぁと感じてはいました。
伊豆オルゴール館 自動演奏楽器
アンティーク オルガン コンサート
これは弓ではなく、ローラーを使うことで、若干本当の演奏とは言えないかもしれない。といっても見事なものです。
一度聞いてみたいな。

オルゴールでよくあるのがピアノの銘器、スタインウェイを使ったものです。これはペーパーロールで動くもので、非常によくできたものです。かのガーシュインらがペーパーロールに演奏を残していて、いまでもこのような機械で演奏を再現できます。

ちょっとわき道にそれてしまいました。では、今の研究状況はどのようなものでしょうか?
一つ目はこれ。

楽器演奏ロボットMUBOTに関する研究
ちゃんと弓を使って演奏しているようです。音の記述はMIDIで、ヴィヴラートやスラーもできるとの事です。もちろん音の強弱もできる。これはすごいなあ。人間のようにスタッカートやスピッカート、マルカートのような表現もできるようになれば、それなりの演奏もできそう。

バイオリンをやっている人ならすぐわかりますが、弓の速さや弓のどこを使うか、どのくらい量を使うか、弓をどのくらい傾けるか、弓と駒の位置をどのくらいの距離を保つか等で音色は随分変わります。まずはこのような動きを全て記述し、いずれはMIDIを解析して自動的に演奏できれば凄い研究になるなぁと思いました。

もう一つがこれ。
早稲田大学 知能機械学研究

なるほど。運動パラメータの違いによって音色の変化、感性を研究するのか。これも面白いアプローチです。

楽譜から演奏解釈を自動的に行うことを研究している人もいるようなので、これらがミックスできればそれなりの演奏ができそうです。多分パラメータ設定によって演奏がハイフェッツ風とかクレーメル風とかなるんだろうなぁ。

| | コメント (0) | トラックバック (0)

2004.04.13

[P2P]資料

今日は時間がないので、P2Pの分散ハッシュの分かりやすい資料を一つ紹介します。

オーバレイネットワークの統合分散環境

分散ハッシュ、特にChordについては非常にわかりやすく解説しています。多分、WEB上で今存在する日本語資料でChordについて一番わかりやすく書いてあるのではないでしょうか?Plaxtonアルゴリズムも述べられているのも興味深いです。また最新の話題にも触れているので、分散ハッシュに興味がある方は是非読んで頂きたいと思います。

この資料では「i3」と呼ばれるP2Pマルチキャストやエニイキャストの方法にも述べられています。原理が単純なだけに非常に面白いと思いました。

| | コメント (0) | トラックバック (0)

2004.04.12

[P2P]分散ハッシュによるP2P-CDNの考察

先日Blogで書いたように今日はP2P-CDNについて説明したいと思います。

さて、Winny,Gnutellaを代表するような「数珠つなぎ」ネットワークでは、コンテンツのダウンロード元の分散はしにくいことがわかります。分散の概念があるとすれば、各ダウンロード元の回線の帯域などのデータ手がかりにユーザがダウンロード元を決定し、これが結果的に負荷の分散という事になります。

では分散ハッシュを使えばではどのようなことが期待できるでしょうか?
まず、分散ハッシュを使えばP2Pネットワーク全体を「検索」できます。これはすなわち、だれかがダウンロードしたコンテンツがあれば、それをダウンロードしたユーザを基本的には検索できることになります。もちろん、Winnyでもそのような効果があるが、それはブロードキャストした範囲にダウンロードをしたユーザがいる場合です。そのような意味で分散ハッシュはネットワーク等の負荷分散に優れたシステムと言えます。

さて、これからが問題です。どのようにネットワークに対して負荷分散を図るのかということです。

まず、興味深いBlogを紹介しよう。以前P2P Todayにも紹介された無印吉澤@はてなダイアリーさんの記事である。
ファイル交換ソフトに起こるトラフィック問題は技術では解決できない?(2004年2月26日)
(無印吉澤さん、この記事でのリンクありがとうございます!)

概要は、P2Pでは「特定のユーザ」をターゲットにしているため、負荷分散が図れないと言う事です。

また、今年行われたJanog13でも同じような議論がありました。
「広がるP2Pサービスとインターネットインフラへの影響」NEC 中原一彦 氏

ではこの問題を分散ハッシュを使って一部解決する事を検討しましょう。(あくまでも一部です。。。)
先ほど書いたように、例えばコンテンツを所有している人(ダウンロードした人も含む)はネットワークに繋がっていればそれを全て検索可能です。コンテンツの名前をnameとすれば、Node_ID=hash(name)というノードはnameというコンテンツを持っている人全てのIPアドレスがわかるのです!ということは分散ハッシュは特定のコンテンツに対する情報は集中管理的であると言えます。ここがポイントです。

つまり、ノードPがnameというコンテンツが欲しければ、最終的にはNode_ID=hash(name)というノード(これをノードQとしましょう。)に尋ねる必要があるのです。そこで、ノードPがnameを効率的(具体的にはネットワークに負荷をかけずに)にダウンロードする仕組みを考えましょう。

まず、ノードPがノードQに対してコンテンツnameのダウンロード要求をします。ノードQはコンテンツnameを保持しているノード(X1,X2.....X100)を知っています。方法として以下のことが考えられます。

方法1)ノードQはノードPに(X1,X2.....X100)の部分集合のIPアドレスを教える。ノードQは(X1.X2.....X100)の部分集合にpingを打ち、その応答速度から最小なものからダウンロード。あまりスマートではないが、最も効果的。ただし匿名性は弱い。

方法2)ノードQはノードPにIPアドレスを教える。ノードPはDNSを使って逆引きを行いドメイン名を判断。ノードQは(X1.X2....X100)のIPアドレスを知っているから、それらは既に逆引きでドメイン名を知っている。そこでドメイン名から最適だと思われるノードをノードPに教える。少なくとも、同じISPや組織間でのコンテンツ配信にはうまくいく。

方法1,2ともにノードのリソースを無視しています。きちんとしたシステムを作るには、ノードのCPU使用率やダウンロード数を考慮する必要があります。

両者の方法ともP2Pを行う両者のネットワーク情報がないと負荷分散ができないので、あまり匿名性を高める事ができません。しかし、P2P-CDNを使うのはそもそも違法性がないコンテンツを大量に流通させる時に最も有効な手段だと考えています。

例えば、オンラインゲームソフトあるいはパッチの配布。オンラインゲームのファイルサイズは数100MBにも及び、そのため配信サーバに対する負荷が高く、回線帯域も大きく確保する必要があります。しかしこのような分散ハッシュのP2P-CDNを使えばその配布システムは最小限にする事ができます。また、パッチの配布では、特定の狭い日時にダウンロードが集中する事が考えられます。特にマイクロソフトでは相当大きなサーバ群や回線を確保しているでしょう。

しかし、P2P-CDNを使えば、ダウンロード数が多ければ負荷分散の効果は上がると言う魔法のシステムとなるのです。例えばオンラインゲームであれば、ノードがネットワークに繋いでいる時間が多いので、ソフトに分散ハッシュのシステムを入れれば、パッチ配布をバックグラウンドで行うにはもってこいでしょう。ソフトやパッチに対してはノードによる改ざん防止のため、電子署名することも必要でしょう。

いつの日か、コンテンツの著作権問題が解決すれば、P2Pコンテンツ流通はごく当たり前の事となるでしょう。そのような時代になれば帯域を効果的に消費するP2Pシステムには今回書いた負荷分散の話はますます重要になるでしょうし、分散ハッシュは有効なシステムとして議論されることになるでしょう。Netleaderのような著作権問題が解決しているソリューションでは是非分散ハッシュによるコンテンツ流通を実現して欲しい、と私は思っています。

P2Pストリームに対するCDNも今少しずつ検討していますが、面白い結果があればBlogに書きます。

次回は「分散ハッシュによる匿名性の強化」について説明したいと思います。


| | コメント (0) | トラックバック (0)

2004.04.11

[P2P]分散ハッシュによるP2PインスタントメッセージとP2Pメール

久しぶりに朝にBLOGをつけてみます。

さて、HPで分散ハッシュの原理を取り上げたので、その応用を近日中に何個が提案していきたい。

ちなみに以前、分散ハッシュによるP2P WEB匿名プロキシも書いているので、そちらもチェックして下さい。

まずはP2Pインスタントメッセージから説明します。
分散ハッシュでは一般にノードにユニークなNode_IDを振り、あるコンテンツ名Aにおいて、そのメタデータ(属性、IPアドレス等)をNode_ID=hash(A)となるノードに格納するものでした。hash()はハッシュ関数を表わします。

さて、インスタントメッセージを分散ハッシュで行うにはどのようにすればよいのでしょうか?原理は非常にシンプルです。自分のニックネームをnameとすれば、Node_ID=hash(name)となるノードにメタデータ(自分のプロフィール、ステータス、IPアドレス等)を書き込みます。nameという人と通信するには、Node_ID=hash(name)となるノードを分散ハッシュのアルゴリズムで検索し、そのノードからnameであるノードのIPアドレスを教えてもらえば良いのです。

注意しなければいけないのは、メタデータのステータス機能です。これは自分が今端末いるかどうか等状態を他人が知る事ができる機能です。これについては、各ノードがNode_ID=hasn(name)となるノードに定期的に自分のステータス情報を送る事で解決します。こうすれば、サーバレスでも通常と同じようなインスタントメッセージ機能を具備することができます。

ではもう一つのP2Pメール機能についても説明しましょう。
メールがインスタントメッセージと違う点として、相手がネットワークから離脱してもメールをだれかが蓄積しなければならない点が挙げられます。
仕組み自体はメールもインスタントメッセージとほぼ同じ原理で実現可能です。すなわち、Node_ID=hash(name)に対して、自分のメタデータを登録します。nameにメールを送りたい人はNode_ID=hash(name)となるノードに対して通信を行い、メールを送ります。このノードNode_ID=hash(name)はメールを蓄積しています。あとはNode_ID=hash(name)がニックネームがnameノードとネットワークに繋がった場合にメールをnameノードにpushすればよいことになります。(もちろんpullでも可)

ただし、このままではNode_ID=hash(name)がネットワークから離脱するとname宛てのメールがなくなってしまいます。これを解決する手段として、Node_ID=hash(name)となるノードは、直接ルーティングしているノード(CANで言うと、ハッシュ空間での隣接ノード)へメールをレプリケーション(複製)することが考えられます。

また、ノードがSMTPサーバ+POPサーバになるわけですが、このままでは他人のメールが丸見え状態であり、メールを成りすまして取られてしまう可能性があります。これを防止する手段としてPGP的な発想が有効であると考えています。

次回は分散ハッシュによるP2P-CDNについて説明したいと考えています。

| | コメント (0) | トラックバック (0)

2004.04.10

韓国旅行。

GWに韓国に行くということで、どの辺を行くか相談していた。
自分は以前明洞など中心部を出かけていたので、今度は郊外を行こうと思っている。
また、B級グルメや屋台にもチャレンジしたい。

その後、久しぶりに地元のバーでゆっくりしていた。あいかわらず、お通しの量が多い。今日はスクリュードライバ一杯で切り上げた。

| | コメント (0) | トラックバック (0)

2004.04.09

[P2P]「P2Pと分散ハッシュ~その1」アップしました!

ようやく、待望の分散ハッシュとP2Pの関係について、HPにアップしました。ふ~。
P2Pと分散ハッシュ~その1

分散ハッシュ自体はP2Pに非常に有効な手段なのに、まだ多くの人がこの技術を知りません。このHPを通して多くの人が分散ハッシュに関心を持って頂ければ幸いです。

また、今までBlogで分散ハッシュに関して度々書いてきましたが、「ナンダコリャ」と言う目で見ていた方も多いはず。一度HPを見てもらって、もう一度過去のBlogを見れば理解しやすいと思います。

なお、今日NetLeaderに携わっている人からBlogにコメントを頂きました。P2Pの開発者、ユーザでいろいろと意見が交換できれば良いですね。私は著作権が守れて、著作権者にも収益が生まれる、そのようなP2Pモデルには大賛成です。今まで著作権権とP2Pの関連については避けてきましたが、今後は少しずつ書いていきたいと思います。

明日は気分転換にプールでも行こうと♪


| | コメント (0) | トラックバック (0)

2004.04.08

それにしても。

昨日(といっても4/7[水]の 0:00~24:00と言う意味で)は3つ(P2P関連2つ、その他1)も記事を書いたのか。なんだかんだいってもBlogをこうも続ける事、特にP2Pネタでここまで持つとは思わなかった。でもそろそろネタ切れかな(笑)研究レベルの話はP2Pマルチキャストやグリッドの話がまだ触れてないが、最新技術の論文等を読んでキャッチアップするのもしんどいので。

アクセス数もここ最近、急に伸びている。多数の人が見ていると思うと、こちらもちゃんとした記事を書かないと、と思います。また今後のBLOG作りの参考のために、もしよければコメントやトラックバックをよろしくお願いします。あとネタ(P2Pに限らず)も大募集です。(笑)特に、大学生、院生、研究者の方、P2P関連で面白い研究があれば是非ご連絡を。お待ちしております♪

| | コメント (0) | トラックバック (0)

2004.04.07

ワイヤレスな電源

このごろP2Pのトピックばかり書いていたので、ちょっとブレイク的な記事を書きたい。

ホットスポットあるいはPHSを使う事でノートパソコンユーザにとっては非常に便利な時代が来た。特にホテルや空港などれはホットスポットが設置されつつあるので、今後はますますワイヤレスということが重要になる時代になるだろう。

ところで、情報インフラはワイヤレスなのだが、PCにはもうひとつ忘れてはならない利用mustのインフラがある。それは「電源」である。せっかくノートパソコンを買っても電源の配線で一苦労したり、ホットスポットを利用しても電源が切れて困った、と言う人は多いのではないだろうか?あるいは海外出張などでコンセントが合わなくて、電源が供給されないと言う事もある。

また、コンセントがあってもユーザによるコンセントの奪い合いが起こるだろう。コンセントをいろんなところに配置するのは景観を損ねることも考えられる。電池で電源を代理することも考えられるが、それはかなり無理があるだろう。またバックアップ用のバッテリーを持っていく事は、ユーザに体力の消耗をさせるだけである。

そこで、ワイヤレスな電源というのがあれば便利だな、と思った。それも世界共通の規格である。パソコンに必要な電圧、電流を上手く分配できればかなりいいシステムができそうだ。といっても書いている自分でも、ちょっと無理そうかなと思う。少なくとも日本に限定すればなんとか実施できそうな気もする。

まず、ワイヤレスで電源自体を供給できるかというと、これはYesである。昔から、宇宙に太陽電池を多数置いて、それをワイヤレスで地球に電源を供給しようとするアイデアはあった。だから、できなくはなさそうである。

と思って、WEBを調べてみたら、既にそういう試みを行っている企業があって驚いた!
ついにノートPCの電源までもワイヤレス?
MobileWiseのワイヤレス電源搭載PCがAcerから発売
体への影響もほとんどないようである。実物を見たいものだ。。。。

ちなみにこっちは違う意味で面白い。
ワイヤレス電源規格802.11vを制定
ちゃんと読めば、ふ~んと思うはず。記事の作成日に注意!

もっと研究されてもいい分野だと思うのだが。

| | コメント (0) | トラックバック (0)

[P2P] 分散ハッシュによる匿名性向上の検討

先日、分散ハッシュChordと匿名性という記事を書いた。その後、分散ハッシュによる匿名性を検討したので、それを書いてみたい。

まず、先日の議論の概要を書いておく。
一般的に、分散ハッシュでは、あるハッシュキーhash_keyを持っているノードがユニークに存在する。今、あるノードのIPアドレスをnode_IP、そのノードが所有しているコンテンツのハッシュをhash_contentとすると、hash_contentsに一番近いhash_keyをもつノードに、<hash_content,node_IP>のペアを渡す。分散ハッシュのアルゴリズムはこの<hash_content,node_IP>のペアを高速に検索する手段である。

ところで、問題としては<hash_content,node_IP>のように、あるノードのIPアドレスを記憶している点が匿名性を低下させる要因となっている。そのためもし他のノードがこのnode_IPを知るには、まず、hash_contentを知り、それに近い数hash_content_nearというハッシュキーでノードが参加することをネットワークに宣言すれば、かなりの高い確率でhash_contentを持つハッシュキーのノードのIPアドレスを知る事ができる。後は、このノードを分析すればhash_contentをhash(content)とするコンテンツを所有するnode_IPがわかってしまう。

さて、匿名性を高めるにはどうするか?その一つとして<hash_content,node_IP>の中にあるnode_IPを周知することを行わない事が考えられる。その解決の一つは、ノードのコンテンツ自体をhash_contentをもつノードにコピーしてしまうことである。つまり、<hash_content,content>という対を作る。

コピーする方法としては、分散ハッシュの検索時のルートでバケツリレーすることが考えられる。こうすれば、コピー元は隠蔽できる。hash_contentをハッシュキーとして持つノードIPはわかるが、このノードを問い詰めても、コピー元は判別できない。また、hash_contentを持つハッシュキーがダウンすると、contentがネットワークから無くなる事も考えられるが、論理的に隣接しているノードにcontentをコピーしたり、Winnyのように途中のノードにキャッシュすることで、ある程度はこの課題をカバーすることは可能である。

もちろん、この方法はネットワークに負荷をかけ、またマシンに対してもリソース低下が考えられる。Winnyのようなpull的ではなく、push的なコンテンツ流通であるが、このような方法もいろいろなところで考えられる事だろう。

| | コメント (0) | トラックバック (0)

[P2P]分散ハッシュと2分木

分散ハッシュとしては、円状のChordやN次元トーラスのCANが有名である。だが、最近では2分木を使った方法もある。これがP-GridとKademliaである。

私も文献を読んでいる途中なのだが、関係資料を紹介する。

P-Grid
公式HP
http://www.p-grid.org/Papers/IC2002.pdf
http://lsirpeople.epfl.ch/hauswirth/talks/P-Grid-Sbg.pdf
http://seminars.home.cern.ch/seminars/2002/2002-OtherFormats/t-20020731.pdf

Kademlia
http://ntrg.cs.tcd.ie/undergrad/4ba2.02-03/p9.html
http://www.sics.se/~sameh/research/P2P/Kademlia/Kademlia%20Presentation/kpres.pdf
Kademila用語

面白いのはP-GridをGnutellaに応用する試みがされている事である。
Gridella

ところで、Kademliaで検索すると欧州や韓国で有名なファイル共有アプリeDonkeyの改良版eMuleにヒットするので、両者は関係があるのかもしれない。(たまたま一致?どなたかご存知の方、いらっしゃるでしょうか?)

いずれにせよ、スケーラビリティを考えるとファイル共有など多数のノードが存在するサービスには分散ハッシュを使う事は重要になりそうだ。


| | コメント (1) | トラックバック (0)

2004.04.05

[P2P]コンテンツ流通とメタデータ

P2Pのコンテンツ流通というとNTTコミュニケーションのNetLeaderを思い出す人が多いだろう。今回はコンテンツ流通とそのコンテンツの使用を調整できる技術である。

さて、コンテンツの使用許諾情報を示すメタデータとしてXMLベースのXrML(eXtesible Rights Markup Language)がある。XrMLはPrincipal(許諾される実体)、Right(許諾される権利)、Resource(許諾対象のリソース)、Condition(許諾条件)の4つのカテゴリーがある。具体的には次のとおりになる。
Principal:ある暗号鍵を持っている人が
Rights:聞くことができる
Resource:バイオリン協奏曲というコンテンツを
Condition:3回まで
と言う風に。
詳しくはIDG ディジタル放送教科書(下)を見て下さい。

さて、このようなXrMLのようなメタデータとコンテンツを一緒に流通させるとどういうことが考えられるだろうか?例えばコンテンツ会社から閲覧チケットを買った人はコンテンツがフルに利用できるが、チケットを買ってない人はその一部しか利用できない、と言った事が可能である。XrMLは柔軟に使用条件が記述できるから、2次流通や広告付きコンテンツなど新たなP2P流通モデルが生まれるかもしれない。

ちなみに、XrMLをベースとして、ディジタル放送の一種であるTV-AnytimeではREL(Right Expression Language)を検討している。TV-anytimeではコンテンツはもはや放送波だけでなく、通信から入手することも考慮されている。いずれはTVのコンテンツがP2Pで流れ、他人が視聴する時課金するなどのモデルを考える事も必要だろう。そうすれば、テレビ番組を見逃しても、P2Pで通信路からいつでも見る事ができる。

XrMLはゼロックス社やマイクロソフトが強力に推進している。例えばマイクロソフトはWindows 2003 Serverに対して、コンテンツの使用条件を細かく設定できるRMSを既に世に出している。このようなコンテンツマネジメントはセキュリティの観点からも広く使われる技術となるだろう。

さて、P2PネットワークでXrMLを活用しようとする資料がこれ。
「P2PネットワークにおけるオープンDRMシステム」

ところで、XrMLはコンテンツとなんらかの方法でバインドしなければならない。この方法として電子透かしが提案されているが、動画の電子透かしはなかなか難しいようである。後述する私の研究では、電子透かしではなくコンテンツのハッシュ値を使ってバインドする方法を提案している。

XMLベースでP2Pコンテンツ流通を促進、課金する方法は私も研究した事があるので、関心のある方はHPを見て欲しい。

| | コメント (2) | トラックバック (0)

2004.04.04

GW

今日はHISとJTBに巡ってGWどこに行こうかと検討していました。GWのちょっと前に有休を取って、なるべく格安で海外に行こうと考えていたのです。

HISに行くと、予定日は既に満席とのこと。そこでJTBに行ってようやく予約をしました。JTBでは格安ツアーPASEOを扱っていて、これだとかなりお手頃で海外旅行に行く事ができるのです。行く場所はソウル。2度目なので、今度は以前行ったときにできなかったアカスリもやってみたい。郊外に足を伸ばしたあとは世界遺産巡りかな。

さて、今日からBLOGにもアクセス解析(NINJA)を使っています。使い勝手が良ければHPのアクセス解析もNINJAに巻き取ろうと思います。

| | コメント (0) | トラックバック (0)

[P2P]分散ハッシュによるP2P型WEB匿名プロキシ

先日の予告どおり、今日はP2PのWEB匿名プロキシについて説明します。
これを書くきっかけはP2PによるWEB匿名プロキシに関するページを以前見たことです。
Aerie
でも、どうやって実現するかってシステム概要について全然書いてないじゃない。。。(´・ω・`)ショボーン。

ということで、私がこんな感じかな?ってちょっと考えて見ましたので説明します。(笑)

まず、「おさらい」ですが、プロキシを使うと外部からIPアドレスが隠蔽できます。これを多重にすると匿名性は非常に強くなります。

今回、私がモデルにしたのは匿名通信路の一種である「Crowds」です。
Crowdsはあるユーザグループにおいて、ユーザ自体がプロキシとなり、WEBアクセスする際にユーザ間を何度もホッピングすることで、外部からは元々誰からWEBにアクセスしているか困難にする技術です。
Crowdsに関する参考文献は下記の通り。
http://www.scs.cs.nyu.edu/G22.3033-001/notes/l11.pdf

さて、Crowdsの問題としては、他のユーザのIPアドレスを複数(匿名性を高めるなら、たくさん)知っている必要があることになります。また、URLごとにホッピング先を変えたりすると結構システムが煩雑になったり、さらにユーザの頻繁な参加や離脱をあまり考慮されていません。さらに、ユーザの参加人数が巨大になった際もあまり検討されていません。そこで今回は分散ハッシュをうまう使う事でこの問題を解決しましょう。

今回のシステムでは、分散ハッシュはChordだろうがCANだろうがあまり関係ありませんが、以前ChordをBlogで紹介したので今回はChordを使いましょう。分散ハッシュやChordについては以前の記事をご覧になって下さい。

さて、まずユーザAがWEBサーバにアクセスするとしましょう。今、ハッシュ関数hash()において、アクセスしたいURLをurl1として、hash_url1=hash(url1)を計算します。これをChordによって、ハッシュキーがhash_url1のノードを探します。
[※注意:各ノードはP2Pネットワーク参加する際、ランダムなnumberをハッシュキーとして保持しておきます。タネンバウム著の「コンピュータネットワーク」ではハッシュキーをノード識別子と読んでいます。]

今、hash_url1をハッシュキーとするノードをZとすれば、
A⇒B⇒E⇒G⇒P⇒Z
のようにZを検索する際に何人ものノードを介するはずです。これが、WEBへの通信そのものになります。
すなわち、B,E,G,P,ZはURL=url1へのAのアクセスのプロキシとなります。

さて、今度はAがURL=url2のアクセスをした場合どうなるでしょう?今度はhash(url2)をハッシュキーととしてもつノードXを探す必要があります。かなりの高い確率でXはZではありませんし、また検索する際には違うノードをたどる可能性が高いこともわかるでしょう。つまり、
A⇒C⇒F⇒M⇒Q⇒R⇒S⇒U⇒Y⇒X
のようになります。ここでプロキシの数及びプロキシとなるノードがurl1にアクセスする時とurl2にアクセスする時には一般に異なる事に注意!これによって、「URL毎に多重するプロキシ数、プロキシとなるノードが異なる」非常に匿名性の高いシステムができあがりました。

また、このシステムは分散ハッシュの性質を活かし、負荷分散の効率が良く、スケーラビリティにも優れています。それだけでなく、ノードの頻繁なネットワーク参加、離脱にも耐えられます。また、ノード自体はいつもネットワークに参加しているとは限らないので、アクセス先サーバからアクセス元をたどるのは非常に困難である事もわかります。

現在、掲示板書き込みにはプロキシが良く使われますが、将来はこのようなP2Pプロキシが広く使われる事になるかもしれません。そんなに実装も難しそうではないので、近いうちにこのシステムのフリーソフトが出回りそうな予感。

| | コメント (0) | トラックバック (0)

2004.04.03

バイオリン購入。

今日、バイオリンレッスンに行ったら、先生に「これ弾いてみない?」といってあるバイオリンを試奏。低音も高音もなかなか響き音の通るバイオリンだ。いいバイオリンですね、と言ったら先生曰く、「これ、問屋さんから預かっているものなんだ。買う気がなければもう戻すけどもどうする?」と。値段を聞くと業者を値切ってもらい19万。

うーん微妙な値段。ボーナス前だし、GWで海外行こうと思ったので買うとなるとかなりの出費。ただし、先生が言うには、もし店に並ぶとすれば50万は下らない値段だそう。確かに、今までいろんな値段のバイオリンを弾いてきたけども、これだけ音が通るバイオリンは値が張る。いずれはそれなりのバイオリンを買おうと思っているし、もうこんな品質で安いバイオリンを買うチャンスはないかもしれないので結局購入することになった。もっとも、今使っているバイオリンは修理に出そうと思っていて、修理費は5万程度とのことだったので、それを考慮すると安い買い物なのかもしれない。

早速バッハのバイオリン協奏曲を練習したが、非常に音が透き通って練習しやすいし、耳にも心地良い。これで弓が良ければなぁ。ただ、弓は10万程度でそこそこのものは買えるので、もう少し買うのを待とうと思う。

ちょっと気になる点としては、スケールの練習をすると前のバイオリンの大きさと微妙に違うので5ポジあたりがしっくりいかない。当分はスケールを練習して今のバイオリンに慣れていこうと思う。

| | コメント (0) | トラックバック (0)

2004.04.02

予告。

今日も深夜まで飲み会だった。明日はもっと大変そうな飲み会なのでかなりヤバイ。土曜日のバイオリンのレッスンがどうなることやら。。最近、バイオリンのレッスンは高度な指示がでてしっかり練習しないと大変な状況である。

さて、今夜は時間がないし酔っているので書かないが、近いうち(多分土曜日か日曜日)にBlogでP2Pと分散ハッシュによる匿名WEBプロキシのシステムの概要を説明する予定である。またできればこのごろ書いてあるWinnyなどのキャッシュにおける分散化と効率性の相関についても書きたい。WEBではなるべくはやいうちに分散ハッシュの有名な方法であるChordとCANの説明をする予定です。お楽しみに。

今日はもう寝ます。。。ではでは。

| | コメント (0) | トラックバック (0)

« 2004年3月 | トップページ | 2004年5月 »