無印吉澤(※新エントリはhatenablogに掲載中)

吉澤です。このサイトではIPv6やP2Pなどの通信技術から、SNSやナレッジマネジメントなどの理論まで、広い意味での「ネットワーク」に関する話題を扱っていたのですが、はてなブログに引っ越しました
最新の記事は http://muziyoshiz.hatenablog.com/ でご覧ください。
RSSフィードは http://muziyoshiz.hatenablog.com/feed に手動で変更するか、
Feedly or Live Dwango Reader を使っている方は以下のボタンで変更ください。
follow us in feedly Subscribe with Live Dwango Reader
最新 追記

2005/10/09

[書評]Winnyの技術

Winnyの技術(金子 勇) Winnyの技術(金子 勇)

Winny開発者の金子氏による、Winnyの技術解説書です。

開発者自身による本だけあって、初期のP2Pファイル共有ソフトとWinnyの比較、Winnyの設計と実装の詳細、そしてWinny開発の経験から生まれたP2Pアプリケーション開発のノウハウの紹介、と盛り沢山の内容になっています。

で、こう書くとすごく難しそうな本に見えてしまいますが、中の文章は、平易な表現で基本的な話から順を追って書かれていて、とても読みやすくて驚きました。Winnyに関する事前知識が無い人でも、これならすんなり読めるんじゃないでしょうか。

個人的に読んでいて面白かったのは、Winnyの設計に関する話と、P2Pアプリ開発のノウハウのところでした。そのあたりの感想をつらつらと書いてみます。

■ Winnyの設計

「上流と下流」「クラスタリング」という概念は一応知ってたのですが、この2つの概念を組み合わせた場合の効果は、本書の説明文と図を見てようやく理解できました。

どうやらWinnyは、下位のピアが上位のピアに検索を依頼すると――Winnyの用語で言うと下流と上流になるんですが――上位のピアはその上位のピア群の中で検索処理を行う、という設計になっているようです(105ページの図4-16などを参照)。これは、Skypeのスーパーノード群(Global Index)と一般ノードの関係と非常によく似ています。

また、この上位のピア群の中での検索処理についても、当初は「上位のピア群で一次元トーラスを形成して、検索クエリに方向性を持たせる」ということを検討していたそうです。2002年の4月にWinny 1の開発を宣言したあたりで、既にDHTに似た方式を考えていた、というのも結構スゴイ話です(そういえば代表的なDHTアルゴリズムが発表され出したのも2002年でした)。Structured P2Pと呼ばれるたぐいの技術を使わなくても、十分実用的な検索効率を持つ階層ネットワークを構築できる、というのは面白いですね。

その他の詳細は本を読んでもらうとして、以下は個人的に意外だった点のメモ。

  • 上流のピアは検索クエリを(ほとんど)下流に転送しない

    • ほとんどの検索クエリは下流から上流、または上流のピア間で流れる(1段下流のピアに転送することもある)。そのため、検索クエリが下流→上流→下流と流れることはほとんど無い。
    • その代わりに、ファイルの情報を格納した「キー」は下流のピアから上流のピアに集まる仕組みになっていて、結果的に、異なるクラスタに属する下流のピア間でのファイル検索も実現している。

  • Winnyは検索クエリをフラッディングしていない

    • 検索効率を上げるためには、検索クエリを実行するたびになるべく別のルートを経由するという方法を取っている。

  • 自動ダウンロードを実現できるのは、Winny独自の特徴

    • Winnyでは、あらかじめ拡散によってネットワーク上にキーが広まっているため、検索クエリの頻度を減らせる。そのため、各クライアントが自動ダウンロードを実行しても、ネットワークへの負荷は問題にならない程度に収まる。

■ P2Pアプリケーション開発のノウハウ

P2Pアプリの開発には十分な大きさのP2Pネットワークが必要で、そのためにはユーザの協力が欠かせない。また、そのようにして作り上げたP2Pネットワークは貴重なので、上位互換性が無くなるような大きな変更はなかなか加えられない。そのため、プロトコルの変更を出来るだけ最小限にするためには、初期の設計が重要で、問題が発生した場合は早い段階で対処する必要がある。初期の設計には、シミュレーションに一定の効果があった……。

5章「P2Pソフトの開発手法」の冒頭では、そんな話が述べられています。実際にうまく動作するP2Pアプリケーションを作り上げた人の言葉だけに、説得力があります。P2Pアプリケーションは、金さえ積めば誰でも作れるという類のものではないわけですね。

で、そう考えると……大規模なP2Pネットワークを構築する技術は、僕みたいな普通の人が考える以上に価値のあるものなのかもしれません。

最近eBayに26億ドルというとんでもない額で買収されたSkypeは、P2Pファイル共有ソフトのKaZaAで培ったFastTrack技術があった上で、大規模なネットワークを構築しています。現在では、同時に300万人ものユーザがオンラインするようになりましたが、特に動作が遅くなったという話も聞きません(ソフトのバグは増えた気がしますが)。

一方、金子氏はP2Pファイル共有ソフトのWinny 1で培われた技術を改良して、P2P掲示板ソフトのWinny 2を開発しようとしていたわけですが、著作権法違反幇助なんていうワケの分からない罪で逮捕されています。金子氏自身、173ページに

いまにしてみると、Winny 2にはファイル共有機能はなくてよかったのだと思います。BBS専用に設計していれば、また別の展開が考えられたでしょう。

と書いていますが、確かにWinnyがBBS専用ソフトになっていれば、もしくはこの「Winnyの技術」がもっと早く発表されていれば、P2Pネットワークを構築する技術の重要さがもっと多くの人に認識されていたかもしれません。それが、なんだか残念です。


2005/10/16

[VoIP][P2P]damakaを使ってみました

P2P SIP ソフトフォン damaka(HK's Page)
http://hkspage.livedoor.biz/archives/50071902.html

HKさんのサイトの記事を見て気になったので、ちょっと使ってみました。damakaのサイトのトップページには

damaka is the world's most innovative and secure Peer-to-Peer, SIP-based collaborative communication platform

なんて書いてあって、思わず期待感も高まります。

----

で、例のようにP2Pニュースサイトの偉い人に手伝ってもらって、パケットをキャプチャしてみたんですけど……これはIMや音声だけpeer-to-peerでやり取りする、ハイブリッドP2P型のソフトフォンでした(がっかり)。PeerMeと同じタイプの「P2P電話」ですね。

まず、NAT/ファイアウォール越えについてはログイン前に以下のような動作を行っていました。

  • デフォルトルートにICMP Echo Requestを投げる
  • STUNプロトコルを用いて、NATの有無、NATの種類、NATのグローバルアドレスを検査
  • STUNプロトコルを用いて、NATがhairpin動作*1をサポートするかどうかを検査

次にセキュリティですが、サーバとの接続はSSL経由で行っていました。その上ではSIPが動作していると思われますが、暗号化されてるので実際のところは分かりません。IMと音声はUDPパケットとして、クライアント間で直接やり取りされていました。こちらも暗号化(形式は不明)されていて中身は分かりませんでしたが、IMにはSIPのMESSAGE/200 OKを用いているのではないでしょうか。推測ですけど。

あと、SIPについては、メニューの「Activity」の中に「Other SIP Networks」という項目があり、ここの設定によって他のSIPネットワークとも接続できるようです。

この他にも、ソフトフォンなのに何故かメディアプレーヤーの機能が付いていたりして、かなり多くの機能が詰め込まれている、という印象を受けました。ただ、技術的に見るべきところは特に無いかな……。

*1 プライベートアドレスからNAT上のグローバルアドレスに送られたパケットを、再びプライベートアドレスへと転送する動作のこと(NATでヘアピンカーブするイメージ)。


2005/10/24

[SNS]videntity.org:WebサイトのURLを識別子に使うSNS

以前にvoid GraphicWizardsLair( void ); //経由で以下の記事を見て気になっていたサービス、videntity.orgを試してみました。

OpenIDで個人サイト同士が繋がるSNS - Social_Networking_Unlimited(ここギコ!)
http://kokogiko.net/m/archives/001353.html

OpenIDのメーリングリストで、OpenIDでのアカウントをベースに、自分のBlogサイト等メインURLをベースに繋がれるSNS実装ができた事を知った。
Videntity.orgという、OpenIDの認証サーバサービスが始めたサービスなのだが、すごい面白い。

詳しくは、ここギコ!の記事を読んでもらうとして。つまりvidentityというのは、

  • 今まではブログにコメントを書き込む際の認証くらいにしか使われていなかったOpenID(≒TypeKeyの機能を標準化したもの)を、SNSにログインする際の認証に使った
  • ユーザの識別子として、OpenIDそのものを使うのではなく、ユーザが管理しているWebサイトのURLを使った

という2点が新しいSNSサービスのようです。特に面白いのは後者? とりあえず僕も自分の情報を登録してみたので、しばらく使って色々考えてみます。

Videntity.org : OpenID Identity: muziyoshiz.jp
http://videntity.org/profile/muziyoshiz.jp

あ。それと、videntityのもう1つ変わった点を。

なんと、友達のサイトのURL(ブログに限らず)を指定することで、このサービスをまだ使っていない友達にもリンク出来てしまいます。例えば、P2P todayの横田さんにリンクするとwslash.com用のページが出来たり、Tomo's HotlineのTomoさんにリンクするとtoremoro.tea-nifty.com/tomos_hotline/用のページが出来ちゃったりします。

そんなわけで、videntityをこれから試す(または試してる)人は無印吉澤にも適当にリンクしてやってOKです。

[tDiary]openidプラグイン

上でちらっと書きましたが、videntityを使うためには、自分のサイトにOpenIDを埋め込む必要があります。これは、HTMLのhead部に

<link rel="openid.server" href="http://videntity.org/serverlogin?action=openid">
<link rel="openid.delegate" href="http://muziyoshiz.videntity.org/">

のような感じで埋め込まないといけないので、ホスティング型のブログでは使えないところが結構ありそうです。が、tDiaryを使っている人は、openidプラグインを使えば簡単に設定できます。

tDiaryドキュメント - openid.rb
http://docs.tdiary.org/ja/?openid.rb

僕はcontrib/plugin/openidからダウンロードして、インストールしました。

ちなみに、このopenidプラグインを普通にインストールしたあとでOpenIDの設定画面を表示しようとすると、

undefined method `call' for "etc":String (NoMethodError)

./tdiary.rb:761:in `conf_proc'
./tdiary.rb:75:in `join'
./tdiary.rb:75:in `safe'
./tdiary.rb:657:in `eval_src'
./tdiary.rb:904:in `do_eval_rhtml'
./tdiary.rb:854:in `eval_rhtml'
update.rb:63

というエラーが出てしまったので、openid.rbの26行目を

add_conf_proc( 'openid', @openid_conf_label ) do

に変えて動かしました。こちらの環境が悪いのかなんなのか、原因は分からないですけど、まあ動いてるからいいですよね……。


2004|06|07|09|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|09|10|11|
2009|01|02|03|04|05|07|08|10|
2010|01|03|
2015|03|
スパム対策のため、60日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。