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

■[P2P][音楽配信]オープンソースの音楽配信サービスFurthur Network（FurthurNet）

結構前の話になるのですが、日経エレクトロニクス2004年12月22日号のp.32-33に「帰ってきたP2Pサービス　米レコード業界が容認へ」というP2P型音楽配信サービスに関する記事が載っていました。

この記事のメインは、Napster開発者のShawn Fanning氏が操業したSNOCAP,Inc.（とSNOCAPのシステムを利用したMashBoxX）なのですが、それについてはネット上の記事を適当に（Universal Music、「Napsterの生みの親」と手を組む(ITmedia)とか）参照して済ませてもらうとして……。この記事で、僕が一番驚いたのはFurthur Networkというプロジェクトの話でした。

サイトでの説明によると、Furthur Network（FurthurNet）は2001年に開始されたプロジェクトで、非商用に限ってライブの録音・録画とその交換を許可しているミュージシャン（FurthurNetでのリスト）のライブ音源を合法的に共有するためのファイル共有サービス、とのことです。不正なコンテンツの流通を防ぐためにユーザによる通報の機能が備えられており、また、ダウンロード時にはMD5による完全性のチェックも行います。

それと、FurthurNetはボランティアによるプロジェクトでもあり、そのソースコードはGPLライセンスでsourceforge.netにて公開されているそうです（執筆時点ではsourceforge.net自体にアクセスできなかったので、まだ確認はしてませんが……）。

日本では一部のサイトでしか取り上げられてないFurthurNetですが、これは結構面白いんじゃないでしょうか。

----

（追記）
日経エレクトロニクスの記事によると、このFurthurNetの開発には、Wurld Media社の子会社のLX Systems,Inc.でCTOを務めるJamie Addessi氏が協力したのだとか。そのこともあって、日経の記者はPeer ImpactとFurthurNetのシステムの類似性を仄めかしています。

参考：P2Pで合法の音楽ファイル交換!? SONY BMG/Universal/Warnerが協賛して準備 (MYCOM PC WEB)
http://pcweb.mycom.co.jp/news/2004/11/25/005.html

米Wurld Mediaは、同社が準備を進めているP2P(Peer-to-Peer)ネットワークを利用した音楽ファイル交換サービス「Peer Impact」に対して、大手レーベル会社と楽曲提供に関する契約を結んだことを明らかにした。来年初めより正式サービスの開始が予定されている。

■[NAT]IPsecのNAT越えに関するRFC

NAT機器を挟んだノード間でIPsec通信をするための方法に関する2つのインターネットドラフトが、ようやっとRFCになりました。このドラフトについては以前のサイトでもTeredo関係の話題として取り上げたことがありますが、ここで改めて振り返ってみます。

RFC 3947: Negotiation of NAT-Traversal in the IKE
http://www.ietf.org/rfc/rfc3947.txt

こちらは、IPsecのNAT越えを実現するために必要なIKE（Internet Key Exchange）の拡張について書かれたRFCです。IKEのシーケンス中にNAT機器の有無を検査し、ノード間にNAT機器が存在する場合にIPsecのUDPカプセル化へ移行するための手順が書かれています。要点は以下の通り。

• Phase 1でNAT機器の有無を検査し、後に続くQuick ModeでUDPカプセル化に必要な情報を交換する
• NATの存在を検知するための、NAT-Dペイロードを新たに定義する
• NAT変換前のアドレス（Original Address）を通知するための、NAT-OAペイロードを新たに定義する
• 一部NAT製品の特殊な機能（IPsecパススルーなど）を避けるために、シーケンスの途中からポート番号を500から4500に切り替える

RFC 3948: UDP Encapsulation of IPsec ESP Packets
http://www.ietf.org/rfc/rfc3948.txt

IPsecのNAT越えと言っても、正確に言うとIPsec ESPでなければNAT機器を越えた通信は実現できません*1。こちらは、RFC 3947のシーケンスで取得した情報を利用して、IPsec ESP暗号化されたペイロードをUDPヘッダでカプセル化するための方法について書かれたRFCです。要点は以下の通り。

• RFC 3947のシーケンスで利用したポート4500番を引き続き用いて、UDPカプセル化されたパケットを送受信する
• トンネルモードの場合は、カプセル解放後に別途NAT変換が必要な場合がある
• トランスポートモードの場合は、カプセル化されたパケットを受信した側でトランスポートヘッダのチェックサムを再計算する。この計算にはRFC 3947のシーケンスで通知されたOriginal Addressを用いる
• ESPヘッダによって暗号化されたトランスポートヘッダのポート番号は、各ノードが勝手に選択したものである。そのため、あるNAT機器の背後にある複数のノードが同時に特定の外部サーバへアクセスした場合、カプセル解放後のポート番号がノード間で重複する可能性がある

最後の話はこの説明だと分かりづらいと思うので、詳しく知りたい方は本文の方を参照してください。また、こちらのRFCについては日本語訳がYAMDAS Projectにて公開されています。

yomoyomo氏による、RFC3948の日本語訳
http://www.yamdas.org/column/technique/rfc3948j.txt

----

（2004/01/14追記）
"UDP Encapsulation of IPsec ESP"日本語訳のリンク先を、最新のものに修正しました。

■[Web]グループウェアAipo

ここの普段の話題とはあまり関係がないのですが、学生時代の友達がベンチャー企業を立ち上げてグループウェアを開発・販売し始めたと聞いたので、ここでも宣伝しておきます。

グループウェア 『Aipo（アイポ）』
http://aipo.aimluck.com/

Windowsでソフトウェアをインストールするだけで、簡単にグループウェアを運用できるソフトウェアです。僕も試しに自宅のマシンに導入してみたのですが、このサイトに書いてある「3分」もかからずにインストール終了しました。

ユーザ管理や情報共有（スケジュールやToDo）など、グループウェアに必要な機能は一通り揃っているようですので、少しでも興味を持たれた方は是非お試し下さい。最初の60日間は無料で使えて、それ以降はライセンスを購入しての利用になるそうです。

あ、ちなみに僕はお金とか貰ってませんよ。ただ、今週末に大学OBの飲み会があるので、その時は期待してますけどねぇ……（意味ありげに）。

参考：Aipo開発者のブログ - グループウェア 『Aipo』ブログ
http://aipo.aimluck.com/blog/

■[IPv6]IPv6 FIX(v6fix)

IPv6 Fix homepage
http://v6fix.net/

世の中には、IPv6を利用できない端末だと何ともないのに、IPv6対応の端末を利用しているときだけ起こる不具合というものがあります。そういう不具合とは、例えば以下のようなものです。

ある日、男が仕事で安いビジネスホテルに宿泊すると、そこは無料インターネット接続が利用できるホテルだった。彼は喜び、備え付けのLANケーブルをノートPCに刺したが、何故かどこのサイトにもアクセスできない。

彼はまずノートPCにインストールされているWindows XPを疑い、OSを再起動したが直らない。次にホテルの設備が壊れているのではないかと疑い、フロントに電話をかけて、ボーイを部屋に呼ぶ。すると、そのボーイは対応マニュアルを手にして、こう言った。

「コマンドプロンプトでipv6 uninstallとタイプして、再起動してください。」

その通りにすると、確かに外のサイトが見られるようになった。IPv6のせいだったのか……？*1

上記サイトのIPv6 Fix(v6fix)分科会は、このようにIPv6の印象を悪くしかねない、仕様、実装または運用での問題を解決するべく活動している団体です（ちなみに、ホテルの例はWindows XPが悪いのではなくて、おそらくDNSサーバの問題だとのこと）。このサイト自体は去年からあったのですが、つい最近になって、v6fixの活動について日本語で解説した文章が公開されましたのでご紹介します。

IPv6 Fix（日本語での解説文）
http://v6fix.net/wide-draft-v6fix

目次

    第1章 動機と全体像              山本和彦
    第2章 IPv6 の仕様の不備         国武功一
    第3章 DNS サーバ とリゾルバ     神明達哉、竹内奏吾
    第4章 TCP のコネクション確立    長健二朗
    第5章 IPv6インターネットの品質  長健二朗
    第6章 Firewall                  下條敏男

信頼できる筋の某WIDE関係者が言うには「今IPv6で一番ホットな話題はコレ」。現状の問題点と、それを解決するために提案中の改善案が詳しく書かれていて、読んでみると結構面白いですよ。

■[SNS][blog]del.isio.us ＞ 個人ニュースサイト

最近気になっていた、ソーシャルブックマークのdel.isio.usというサービスを使い始めました。

とりあえず、日記のネタ候補にあげたまま放置していたサイトを一通り放り込んでみましたので、まだ使ったことの無い方はサンプルとしてご覧下さい。

del.icio.us/muziyoshiz
http://del.icio.us/muziyoshiz

正直に言うと、最初にdel.isio.usを見た時は「まぁ、多分MyClipみたいなものなんだろうなぁ」程度で済ませてしまってたんですが、実際使ってみるとMyClipとは全然違いますね。

まだ1日しか使ってませんけど、恐らくdel.icio.usの特徴は以下のようなところにありそうです。

• サイトをブックマークする時に、ユーザが定義したタグ（カテゴリのようなもの）を自由に付けられる*1
• タグを軸にして、同じタグに関連付けられた他のサイトを辿れる
• サイトを軸にして、同じサイトをブックマークしているユーザを辿れる
• ユーザを軸にして、同じユーザがブックマークしているサイトやタグを辿れる

mixiなどのSNS（ソーシャルネットワークサービス）では、ユーザやコミュニティを軸にしてどこまでも情報を辿っていくことができますが、del.icio.usも正にその感覚がある……と言えば一部の人には分かってもらえるでしょうか。ともかく実際に使ってその感覚を味わってみれば、「ソーシャルブックマーク」という謎の名称にも納得できます。

他にも、del.icio.usには以下のような特徴があって、まだまだ奥が深そうです。

• googleを思わせる、シンプルなインタフェイス
• 注目したいタグを登録（subscribe）すると、他の人がブックマークしたサイトが自動的にinboxへ貯まっていく

----

で、しばらくの間は無邪気にいじって楽しんでたんですけど、ふと我に返ってぞっとしました。

というのも、このdel.icio.usのようなソーシャルブックマークが普及したら、単にサイトを羅列して紹介するだけの個人ニュースサイトは、del.icio.us以上のメリットを出せずに軒並み潰れてしまうのではないか、と思って……。内輪向けの日記の一部がSNS（主にmixi）に移行していったように、今後は個人ニュースサイトの一部もソーシャルブックマークに移行していくのかもしれません。

----

参考サイト（del.icio.usを見直すきっかけになりました）：
なぜソーシャル・ブックマークのdel.icio.usが面白いのか(Goodpic)
http://www.goodpic.com/mt/archives2/2005/01/delicious.html

Folksonomy : del.icio.usとFlickrを支える情報アーキテクチャ(Goodpic)
http://www.goodpic.com/mt/archives2/2005/01/folksonomy_deli.html

■[blog]「日本のアルファブロガーを探せ2004」に駆け込み投票

日本のアルファブロガーを探せ２００４(FPN)
http://www.future-planning.net/x/modules/news/article.php?storyid=311

去年からずっと悩んでいたのですが（去年の12月20日の日記を参照）、とうとう決めました。有名なサイトばかりで、意外性が全然無くて申し訳ありません……。

　（１）「会社のオフィスでは『３つだけ』しかブログを読んではいけない」と言われたら、どれを読みますか（一つだけでももちろんOKです）
　・ブログ名１と（簡単な理由）
　・ブログ名２と（簡単な理由）
　・ブログ名３と（簡単な理由）

ブログ名１：高木浩光＠自宅の日記
http://takagi-hiromitsu.jp/diary/

実は、ここは僕が日記を始めるきっかけになったブログでもあります。（今は亡き）高木浩光＠茨城県つくば市の日記に、「Web日記なのに専門的な話題を延々と書き続ける」というスタイルが成立することを強烈に印象づけられて始めたのが、無印吉澤の前身である無印吉澤＠はてなダイアリー（現在は跡地）だったりします。そんな思い入れがあったので、はてなの住所登録騒ぎのときに、図らずも同じタイミングで引っ越ししていたのにはホントにびっくりしました*1。

最近は地方公共団体のオレオレ証明書にツッコミを入れたりと、相変わらず絶好調ですね。

ブログ名２：圏外からのひとこと
http://amrita.s14.xrea.com/d/

自分では全然興味を持てなそうな分野も含めて、幅広い分野から話題を持ってきてくれるので重宝してます。P2P関係では以前にノードレイティングP2Pというエントリを書かれているのですが、いつかちゃんと考えようと思っているうちに四半期も経過してしまいました……。

ブログ名３：Passion For The Future
http://www.ringolab.com/note/daiya/

こちらも超有名サイト。僕は主に、質の高い書評＆ソフト紹介目当てで読んでいます。

　（２）上記の３つのブログを除いて、２００４年にあなたが最も影響されたブロガーの記事を教えてください。
　・URL
　・簡単な理由

質問が「最も影響されたブロガー」なら、P2P関係ニュースサイトのP2P today ダブルスラッシュとNext Today ダブルスラッシュを運営している横田さんを推すところなんですけど……特定の「記事」がちょっと思い当たらなかったので、今回は該当無しということにしておきますね。残念。

■[tDiary]counter.rbのカウントアップ制限

うちのサイトのカウンターは実質的にユニークアクセスしかカウントしない設定になっているのですが、サイトを更新してから1週間後でも平均100アクセスくらいあります。

で「これは絶対おかしい！」とずっと思っていたのですが、今日tDiaryのcounterプラグイン（counter.rb）のソースコードを読んでやっと原因が分かりました。counterプラグインって、デフォルトではGooogleBotすらカウントしてしまうみたいです……tdiary.confでゼロからちゃんと設定しないとダメだったんですね。

そこで、どれくらいボット（robotの略；サーチエンジンやアンテナからのクローラ）が来ているのか実態調査するために、

• GETメソッドでトップページまたはHTMLを要求しているログだけを取り出す
• 既に見つけているUser-Agent文字列を含むログは除去

という簡単なRubyスクリプトを書いて、Apacheのアクセスログ過去2週間分に対して実行してみました（我ながら暇人だなぁ）。その調査結果を反映させた、tdiary.confの設定結果はこちら（↓）。

# counter
# カウントアップ制限
@options['counter.deny_user_agents'] = ["Googlebot", "Bulkfeeds", "msnbot", "Hatena Antenna", "Infoseek SideWinder", "Comaneci_bot", "BlogRanking", "ichiro", "Technoratibot", "CaptainNAMAAN", "Download Ninja", "ping.blogger.jp", "ia_archiver", "NaverBot", "ndl-japan-research-robot", "Wget", "Nutch", "nAntenna", "Mediapartners-Google", "lwp-trivial", "nomadscafe_ra", "ConveraCrawler", "KMHTTP", "Tarantula", "Pockey", "Microsoft URL Control", "Livedoor SF", "Bloglines"]

ボットって、結構いろいろあるものなんですねえ……。これでしばらく様子を見ます。

----

（2005/01/21追記）
後からよく見たら、MUTOPON7 ANNEX - アクセスカウンタ表示プラグインの説明に

また、@options['bot']もカウントしません(@options['counter.deny_user_agents']と同じ)。

と書いてありました。botはちゃんとある程度弾いてたみたいです……文章もソースコードも読めないのか僕は（汗）　というわけで、@options['bot']に元々入ってなかった分だけ、そちらへ移動させました。

■[P2P][VoIP]P2P SIPの勉強中 / Columbia Universityの場合

ここ最近、標準的なIP電話プロトコルであるSIP(Session Initiation Protocol)を改良して、P2Pネットワーク上でIP電話を実現しようとする動きがいくつかあります。SIPをP2Pネットワークに乗せた時点で、それはもはやSIPと呼べないような気もするんですけど……まぁ、面白そうなのでちょっと調べ始めてみました*1。

僕が知っている限りでは、アメリカの2つの大学が個別に実装を進めているそうです。以下は、僕が活動を知った順。

P2P-SIP(Columbia University)
http://www1.cs.columbia.edu/~kns10/research/p2p-sip/

P2P SIP(College of William and Mary)
http://www.p2psip.org/

そこで、まずはコロンビア大学のP2P SIPの論文を読んでみました。ざっと読んだだけですが、要点と思えるところだけ書き出してみます。

Kundan Singh and Henning Schulzrinne, "Peer-to-peer Internet Telephony using SIP", Columbia University Technical Report CUCS-044-04, New York, NY, Oct 2004.
http://www.cs.columbia.edu/~library/TR-repository/reports/reports-2004/cucs-044-04.pdf

• ネットワーク構造

  • 安定して動作できるsuper nodeと、それ以外のordinary nodeによる2層構成（Skypeと同様）
  • ordinary nodeからsuper nodeになるかどうかは、ローカルに判断する（これもSkypeと同様）
  • ordinary nodeはsuper nodeにREGISTERすることで、SIP/P2Pネットワークに参加する
  • 固定的なREGISTER先（DNS NAPTR or SRV）や、super nodeが見つからない場合は、アプリケーションに予め設定された既知のドメイン（例：sip-p2p.net）を利用する
  • OPTIONメソッドを利用してノード間の生存確認を行う

• registrationの管理（SIPで言うところのロケーションサーバの役割）

  • Chord(DHT)を使ってユーザのregistrationを管理する
  • super node間でのみDHTを管理する中間モデル(Intermediate model)を採用

• SIPメッセージの送受信

  • INVITE（ダイアログを生成するSIPメッセージ）はsuper nodeを介してやり取りされる
  • その他のSIPメッセージは基本的にordinary node間で直接やりとりされる

• 発展

  • NAT/ファイアウォール越えの方法は、まだあまり検討されていない様子（ICEを使う、とだけ書いてある）
  • ボイスメールは、Oceanstoreのように複数のノードに保存するか、発信側で保存して後ほど送信するか、有料の集中型サービスプロバイダを利用して実現する
  • セキュリティ対策としては、リアルタイム通信向けの評判システムが必要（従来のP2P評判システムはファイル共有が対象だった）

• その他

  • 通常のSIP UAと、SIP/P2P対応のSIP UAを区別するためにRequireヘッダを利用する

ということで、まだ基本的なところしか決まっていないようですね。正直、これを読んだだけでは、通常のSIPとSIP/P2Pがホントに共存できるのかはよく分かりません。普通のSIPプロクシをsuper nodeとして扱うにしても、そのドメインで扱っているユーザの情報(registration)もDHTに乗せるのかどうか、などの点が書かれていないので……。

----

一方、ウィリアム・アンド・メアリー大学のP2P SIPに関する情報は、IETFのインターネットドラフトとして最近公開されました。次はこちらを読んでみます。

David A. Bryan and Cullen Jennings, P2P SIP IETF internet draft : A P2P Approach to SIP Registration
http://www.employees.org/~dbryan/p2psip/draft-bryan-sipping-p2p-00.txt

（たぶん続く）