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

■[P2P勉強会]第2回P2P勉強会の情報

• 日時：2005年2月26日（土） 10:00〜18:30
• 会場：電通大調布キャンパス 東5号館241号室
• 参加者：89名（懇親会は44名）
• 各講演者の持ち時間は講演40分、質疑応答10分
• 今回から始まったミニプレゼンは講演5分、質疑応答5分
• 第2回P2P勉強会プレゼン資料
• P2P勉強会 関連リンク集(P2P today ダブルスラッシュ)
• P2P勉強会Wiki

今回も、第1回と同様に議事録を作成してみました。勉強会に参加された方は当日の復習に、そして不幸にも参加できなかった方はインターネット上で公開されているプレゼン資料と併せてお使いください（ミニプレゼンについては関連サイトのみを示しています）。

なお、この議事録をお読みになる際は以下の点にご注意ください。

• 講演の内容は、編者の判断で一部検閲、修正しています（インターネット上で公開された資料にない部分が主な対象です）。
• この議事録はあくまで編者の個人的なメモとして公開するもので、編者の勝手な解釈が入っている可能性があります。
• 編者による追記は脚注として示しました。
• 質疑応答のQは質問、Aはそれに対する回答、そしてCはコメントです。質問者の名前は伏せてあります。

加筆・修正などの提案がありましたら、コメント欄または個別にメールでご連絡お願いいたします。

■目次

• 開会の挨拶（Tomo's Hotline管理人 西谷氏）
• 分散ハッシュテーブル(DHT)入門とP2Pにおける認証について（Tomo's Hotline管理人 西谷氏）
• アドホックネットワークの概要と技術動向（千葉大学 阪田氏）
• SIPの最新動向と技術課題 〜NAT/ファイアウォール越えを中心に〜（株式会社フラクタリスト 山田氏）
• P2Pでマルチプレイヤ・ゲームを行うには: 理想と現実（奈良先端科学技術大学院大学 飯村氏）
• グリッドとP2P（首藤氏）
• ミニプレゼン1：井戸端会議スタイルがP2Pコミュニティを変える（慶応大学 山本氏、望月氏、森本氏）
• ミニプレゼン2：新月の現状報告（電気通信大学 福冨氏）
• ミニプレゼン3：P2P情報家電の試作と報告（株式会社アルファシステムズ 江守氏）
• ファイル交換サービスと著作権問題（国際大学GLOCOM リサーチアソシエイト 福島氏）
• P2Pビジネスの将来を考える（アリエル・ネットワーク株式会社 徳力氏）
• 閉会の挨拶（Tomo's Hotline管理人 西谷氏）
• 謝辞

■開会の挨拶（Tomo's Hotline管理人 西谷氏）

▼概要

P2P勉強会開催の経緯

1. P2Pに関する横断的な会合として
   P2Pの対象分野は非常に広い。技術的な面だけでなく、ビジネスや法学の面でも興味を持っている人が居る。しかし、P2Pに関する横断的な会合は今まで無かったため、勉強会を開催した。
2. リアルな交流の場として
   ネット以外でもコミュニケーションが必要ではないか。P2Pだけでなくプライベートも含めて、今後に繋がるような関係を構築したい。

■[P2P]分散ハッシュテーブル(DHT)入門とP2Pにおける認証について（Tomo's Hotline管理人 西谷氏）

▼概要

分散ハッシュテーブル（Distributed Hash Table; DHT）は、データの所在を全てのノードで分散的に管理する技術である。本講演では、簡単な分散テーブルとして考案した「あいうえおDHT」を取り上げて、DHTの原理について簡単に説明する。また、DHTを用いた電子証明書の管理方法を提案する。

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• Tomo's Hotline
• P2Pとは何か？〜基礎から研究紹介まで〜

▼講演内容補足

今回の講演の前半（あいうえおDHTなど）は、Tomo’s HotLineでの以下のエントリが元になっています*1。

• 分散ハッシュ（DHT)入門〜その１
• 分散ハッシュ（DHT)入門〜その２
• 分散ハッシュ（DHT)入門〜その３
• 分散ハッシュ（DHT)入門〜その４
• 分散ハッシュ（DHT)入門〜その５
• 分散ハッシュ（DHT)入門〜その６
• 分散ハッシュ（DHT)入門〜その７

また、後半はTomo's Homepageの以下のページが元になっています。

• P2Pと認証

以下は、講演中のコメントです。

• 資料p.7

  • DHTのルーティングはかなり工夫されているので、是非とも一回論文を見てもらいたい*2。
  • 【講演者による補足】
    Chordについてはタネンバウム著「コンピュータネットワーク第4版」（p.362-366）にて、図入りで分かりやすく解説されています（ちなみに、この本にはアドホックルーティングについての解説も載っています）。

• 資料p.20

  • DHTでblogを作ると、特定ノード（トップページなど）に負荷が集中すると考えられる。
    →DHTといってもあるノードに負荷が集中の予感。
  • DHTルーティングのホップ数削減に、スモールワールドの考えは使えないか？

▼質疑応答

• C)スモールワールドのDHTへの応用には、スタンフォード大グループが研究しているSymphonyというシステムがある。シミュレーションだけでなく、開発まで行っている*3。
• 【講演者による補足】
  Symphonyの検索ホップ数は、リンク数を2k+2とした場合にO([log(N)^2]/k)です。スモールワールドを応用したDHT：Symphony(Tomo’s HotLine)。

• Q)PKIの話があったが、自己署名証明書ベースの認証基盤では何故ダメなのか。
  認証には「組織ないし個人が確かに存在するという社会的信用を得るためのモデル」と「PGPのように、チェーントラストを辿ることで存在は検証できる（ただし、誰と結びついているかは分からない）モデル」の2つが考えられるが、DHTと組み合わせて楽しそうなのは後者に思えた。
• A)ビジネスモデルによってどちらの認証を利用するかは変わると思う。PGPのようなモデルも今後は考えてみたいが、今回は課金に利用できる前者のモデルを考えた。

• Q)DHTのルーティング部分だけDNSを用いて効率化すると、ENUMのようなインターネットのインフラとして使えるようにならないか？　そういう研究をしている人はいないか。
• A)そのような研究があるかは分からない。P2Pの初期ノード発見をDNSで解決する、という研究は良く聞く。
• 【講演者による補足】
  ノードIDはDHTに参加する度に変わる可能性があるので、ノードIDの管理とユーザからの参照をサーバに任せると、サーバに非常に重い処理が走ります。サーバでは初期ノードだけ管理させ、他はDHTに任せた方が負荷が分散して良いと考えています。

■[adhoc]アドホックネットワークの概要と技術動向（千葉大学 阪田氏）

▼概要

本公演はアドホックネットワークのチュートリアルである。まず、アドホックネットワークの現状と主な研究課題について述べた後に、アドホックネットワークを実現するルーティングプロトコルとして代表的な、Reactive型のAODVとDSR、そしてProactive型のOLSRとTBRPFの特徴を簡単に説明する。

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）

▼講演内容補足

• 資料p.4

  • 「制御メッセージ数削減」と「高信頼化」はトレードオフの関係にある。ルーティングプロトコルは、以下のいずれかになる。

    • 制御メッセージを減らしながら、出来るだけ高信頼化する
    • 高信頼化を目指すけれど、制御メッセージは短くする

  • 実際にはアドホックネットワークの実用版はあまりない。実体としては、無線LANのメッシュネットワークから入っていくのではないかと思っている（802.11sで議論が活発化している）。

• 資料p.5

  • IETFのMANETは1997年頃から標準化が始められた。（MANETは画家のマネから取っている。ヨーロッパ人は大抵「マネ」と発音する。アメリカ人は「マネ」「マネット」のどちらかで発音。）
  • 当初は見込み無しと思い、注視していなかったが、最近は日本でもここ2年くらいでフィーバーし始めた。

• 資料p.6

  • アドホックネットワークは、すぐビジネスにはならない。
    ユビキタス系のビジネスが本当に立ち上がるのは2010年頃と言われている。まして、アドホックネットワークはもっと先だろうと言われている。
  • 80年代までは軍事利用。90年代には災害時利用まで広がってきて、IETFの議論開始。2000年移行に各種サービスの話題が出てきた。
    センサネットに近い分野（商品倉庫管理、建設工事現場、農場まで）はビジネスモデルも作られ始めているが、コンシューマ系（ショッピングモールなど）に広がらないとなかなかビジネスにならない。

• 資料p.8

  • 【参加者からの指摘】
    米Mesh Networksの製品は、今はMEA（ミーア）という名称になっている。MeshLANは、あまり動きを仮定していない製品。

• 資料p.10

  • DSRは1994年に提案された一番古いプロトコルだが、RFC化は一番遅れている*4。

• 資料p.11

  • 標準化開始からRFCまで6〜7年もかかった。
  • 無線LANと携帯電話の普及によって、2001年頃から真剣な議論が始まった。
  • 昨年の6月にIEEE802.11sというのが出来て、まずは位置局のメッシュから検討。移動というのはあまり考えられていないが、ここでまず実証して、移動系に展開。

• 資料p.12

  • 千葉大の研究でも、卒論生がルーティングプロトコルの解析・シミュレーションを行っている。

• 資料p.14

  • アドホックネットワークでの重要なファクター

    • 高信頼…まず届ける
    • 省電力…無駄な制御パケットをたくさん送って、センサの電池を消費しない

• 資料p.18

  • Reactive型は言葉の通り「リアクション」。自分からは動かない。
  • Proactive型は普段から自発的にルーティングテーブルを作る。
  • アドホックネットワークを研究する方は頭に入れておいて欲しいのだが、Proactive型はトポロジーを計算して、グラフとして理解し、最短経路をDijkstra（ダイクストラ）アルゴリズムで決定する。DijkstraはOSPFでも使われているアルゴリズム。Reactive型ではこのようなことは行わない。

• 資料p.22

  • AODVは、OSPFのようなインターネットのルーティングプロトコルに近い。
  • DSRは、ルーティングテーブルを持たずに、発信元が経路を指定する。

• 資料p.24

  • Charles PerkinsはMobile IPを標準化した張本人。
  • Mobile IPの標準化が一段落したあとの2000年頃に提案されたため、比較的遅かった。

• 資料p.31

  • DSRの名前と結び付けた、プロトコルの特徴の覚え方。
    S→Source routing
    D→Distance Vector（枝に重みがない。ホップ数でカウント）

• 資料p.37

  • 細かいところは元の論文（またはInternet Draft）を読むと良い。かなり重たい論文になっている。

  • OLSRとTBRPFは、制御メッセージを減らすためのアプローチが異なる。

    • OLSRは制限的なフラッディングによって、制御メッセージを減らす。何も考えずにフラッディングを行うと制御メッセージが爆発してしまうため、グラフ理論的な仕掛けを入れて、制御メッセージを最小にしている。
    • TBRPFはトポロジーが変化した時だけ制御メッセージを送ることで、ルーティングテーブルを作る時の制御メッセージを減らす。

• 資料p.40

  • 古くからあるグラフの問題。NP完全なので、準最適解を求めている。

• 資料p.43

  • Willingnessとは、そのノードがどれくらい中継ノードになりやすいかを定量的に示す値。

• 資料p.53

  • ユニキャストプロトコル自体がRFCになったばかりで実環境での評価がされていないため、今はまだマルチキャストプロトコルの評価をしっかりやろうという気運はない。

• 資料p.54

  • マルチキャストに関しては(1)の本に詳しい（ただし少し古い）。また、先週発売した(14)では、m2m-xやSIPにおけるNAT越え（UPnP）の紹介、ホームネットワークでのアドホック通信の検討を行っている。

▼質疑応答

• Q)アドホックでのマルチキャストの具体的な利用イメージについて聞かせて欲しい。
• A)アドホックで、リライアブルなマルチキャストは非常に難しい。まず「戦場で、出来るだけ多くの前線の兵士に命令を伝達したい」というところから起こっている。一般のアプリとしては、災害時の利用が考えられている（出来るだけ多くの人に緊急メッセージを伝える）。他には、コンテンツ配信や広告配信など。

• Q)アドホックネットワークは特にインターネットと関連しないように見えるが、何故IETFで仕様が策定されているのか？
• A)IETFのMANETはUDP/IPを前提にしている。IPを使っているが、IPルーティングは行っていない。IEEEの方はMACレイヤでルーティングをしようと考えている。

• Q)質問者の方でも、802.11bを使ってどの程度スループットが出るか実験してみたのだが、2〜3ホップでスループットが非常に下がってしまった。そのようなことが起こる原因について何か知っているか。
• A)私の方でも実際に作ってはいないのでよく分からないが、802.11sの方では周波数の干渉の問題（隠れ端末や晒し端末）でスループットががくんと落ちると言われていて、それを解決するための検討が行われている。802.11sではこれが最大の問題と言われていて、色々な提案が今年の6月までに出されて、1年かけて選択が行われる予定。

• C)アドホックに関して色々と文献を調べたところ、スループットの下がる一番の理由はパケット衝突とある。いろいろなところで研究が行われていて、最近では福井大の方がどこかの企業と行っている研究で、線形振動子を使ってタイミングを調整するというものがあった（既にプロトタイプ版を作っている）。
  1月に計測自動制御学会で発表された。

• Q)アドホックルーティングのNP問題に遺伝的アルゴリズム(GA)を使うという議論はあるか？
• A)学会の発表では、去年のFITでそのような発表があった気がする（阪田氏が座長を行った）。

■[NAT][VoIP]SIPの最新動向と技術課題 〜NAT/ファイアウォール越えを中心に〜（株式会社フラクタリスト 山田氏）

▼概要

本講演では、NAT越え問題に対する従来の解決策とその課題、そして株式会社フラクタリストが開発しているNAT越え技術について解説する。また、そのNAT越え技術をSIPへと適用した製品やソリューション事例を示す。

▼関連サイト

• NAT トラバーサル SDK
• SIP UA SDK

▼講演内容

プレゼン資料が非公開のため、差し障りのない範囲で内容の一部を紹介します。

• 我々の仕事のテーマはP2P＋ユビキタス

  • 端末が遍在化
  • 「インターネットに繋がっているPCにサービスを取りに行く」形から「身の回りにある端末がインターネットに繋がる」形へ変化

• 我々が解決する問題
  IPv4ではNAT越え問題が発生

  • P2Pにおける問題
    双方のノードがNAT環境にある場合のP2P通信
  • サーバのクライアント管理における問題
    ポーリングの負荷問題

• 従来の解決策1（P2Pにおける問題）

  • サーバによるデータ中継
    サーバへの負荷が大きく、スケーラビリティに難
    （例：MSNメッセンジャーはデータ中継サーバを多数用意している）
  • STUN、UPnP
    これらの技術だけでは、対応率と開発難易度に問題が残る
    （市販のブロードバンドルータの一部で安定動作しない。時にはルータのハングアップの原因に）

• NAT Traversal Technology

  • STUNの拡張（特願2003-35290）
    STUNやUPnPで対応できない環境でも安定動作
    国内のコンシューマ向けブロードバンドルータには全対応（実証実験済み）
  • RUDP
    UDP/IPの上に独自プロトコルを実装し、TCPライクな信頼性を確保

• 従来の解決策2（サーバのクライアント管理における問題）

  • ポーリング
    クライアントが定期的にサーバへ問い合わせる（データを要求する）
    以下の2項目はトレードオフの関係にある
    （ポーリングの間隔を長くすると負荷が下がるが、リアルタイム性も下がる）

    • サーバのCPU・メモリ負荷、帯域負荷
    • リアルタイム性

  • キープアライブ
    クライアント側から定期的にキープアライブパケットを送り、NATのアドレス変換ルールを維持
    UDP hole punchingと同じ仕組み

• Lightweight Polling System（特願2005-13291）
  サーバへの負荷を下げ、クライアントを同時に5万台以上管理可能

  • キープアライブの再送タイミング
  • サーバに負荷をかけずにキープアライブ
    キープアライブパケットをサーバまで届けない
  • ルータのブロッキング機能
    シーケンスを工夫して、ルータのセキュリティ機能を逃れる
  • ルータのパケットロスへの対策

• SIPへの適用：SIP UA SDK

  • SIPシグナリング
    SIPサーバにNAT越え機能を実装（UDP hole punchingをベースに対応）
    SIPシグナリングのNAT越えは標準化が進んでいないが、オープンソースのSERなどは独自の手法でNAT越えを実現しているため、そういう製品に合わせた形でNAT越えを実現する
  • メディアセッション
    NAT Traversal SDKで対応
    SIPサーバはほとんど介在しないため、独自技術でも問題はない
  • メリット："border controller"より安定

• ソリューション事例1
  WiFi携帯電話に、NAT越えを解決したSIPミドルウェアを提供
  →無線LAN実環境での実証実験を準備中

• ソリューション事例2
  ネットワークカメラ、ホームセキュリティ
  従来…DDNS＋グローバルIPアドレス（アドレスの更新頻度が低い）
  当社…NAT越えミドルウェアを提供、NAT越えサーバをASP提供

• ソリューション事例3
  ネット家電リモコン
  LPS(Lightweight Polling System)サーバを通して、携帯などから宅内の家電機器にアクセス

▼質疑応答

• Q)UDP hole punchingは以前から聞いたことがあったが、Lightweight Polling Systemはどのように動作しているのか？
• A)UDP hole punchingの手法をベースにカスタマイズした技術の、クライアントとサーバのセットをLightweight Polling Systemと呼んでいる。サーバに負荷をかけずにキープアライブを実行する。

• Q)IPv4でNATのある環境が前提になっている技術と思われるが、公衆無線LANや家電のように、今後作られるネットワークはIPv6対応になる可能性がかなりあると思う。IPv6に対する御社のスタンスは？
• A)IPv6にする具体的なメリットが生まれないことには、IPv6が普及するかどうかは疑問。また、通信相手がIPv6に対応していない場合はIPv4を使わざるを得ないため、すぐにコンシューマでIPv6が普及する、ということはないと考えている。

• Q)RUDPを標準化する予定などはあるか。
• A)現状ではまだあまり考えていない。このような技術がP2Pで使われるようになった場合は、他社の機器との相互接続を考える必要がある。

■[P2P]P2Pでマルチプレイヤ・ゲームを行うには: 理想と現実（奈良先端科学技術大学院大学 飯村氏）

▼概要

本講演では、「サーバが無くなっても好きなネットゲームで遊び続けたい」という講演者の理想と、その理想に対して現実に存在する問題について論ずる。講演者の提案するZone Federation Modelは、データの局所性と構造を元にしてサーバの機能を分散し、DHT（Pastry）を用いてデータの管理を行うことを特徴とする。

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• [P2P]P2Pゲームの可能性について(Tomo's HotLine)

▼講演内容補足

• Multi-player Online Game(MOG)：複数人が同時に遊ぶネットワークゲーム

• 1ユーザの立場から…サーバがあると困る

  • 大きな問題意識
    「ネットゲームは、今までのゲームと違ってサーバが無くなると遊べなくなる」
    （例：半年しかサービスしないとパッケージに書いてある鉄騎大戦）

• サーバの役割：ゲームの進行役、データの管理

  • サーバが消滅することで、ゲームの進行を妨げる

• サーバをなくそう…どうやって？

  • ゲームを遊びたい人がいる限り、ユーザノードは1つ以上存在する
    →ゲームの進行役も、データの管理もユーザが行う
    →これってP2P？

• 当面の目標と解決策

  • 目標：ゲームの進行を妨げる要因を中央集権化させない
  • 提案：Zone Federation Model

• Zone Federation Modelが解決する4つの問題

  • (1)サーバ機能の分散
    局所性と構造を元に、Zoneという形でデータを分割
    （局所性…1つのノードが必要なデータは全体の一部分）
  • (2)分割されたデータの一貫性保持
    調停ノードによるZoneの分割統治（調停ノードにはゲームの理解が必要）
    単純化のために、調停ノードの選択には指名制でなく立候補制を採用
  • (3)応答性の維持
    200ms以下の応答性が目標（関連する論文の中で一番シビアな値）
    C/S型と同等のレスポンスを期待して、調停ノードとノードを直接接続
  • (4)データの保管
    DHTを利用（データの管理と異なり、ゲームの理解は不要）

• 現在の実装

  • libcookai - Massive Multiplayer Online Game infrastructure library
  • DHTは、MOGに必要なPastryの一部の機能を実装

• 問題点

  • 悪意のあるノード
    データの改竄、DDoS、個人情報の扱い（どこまでが個人情報？）
  • お金の取らせ方
    課金サーバは出来るだけ導入したくないが、ゲームベンダーはお金を取る必要がある
    アイテム課金（課金した人だけが使えるデータ）の実現には、個々のデータへの認証が必要
  • ゲーム参加ノードの一定量確保
    一日の変化と、長い期間での変化
    対策：データ保管サービス（ゲームの理解は不要なので、ISP等が提供できる）
  • 速度の確保
  • サーバ機能分離による問題
    課金なしで遊べる可能性がある（当初の目的そのもの）
  • その他の問題
    自分達のサポートを離れたゲームの存在を、ゲームベンダーは許すのか？
    ゲームよりもサービスの方に魅力を感じることもある。問題の本質は別かも？

• 未来像

  • ユーザの少ない時間帯（昼間）は地球の裏側のノード（夜）がゲームデータを保管して、ゲームデータが地球をぐるぐる回る
  • 複数のゲームで同じプラットフォームを使用することで、ゲーム間の情報共有が可能
  • 作り捨てのMOG（サポートはありません、と豪語したMOG）

▼質疑応答

• Q)ユーザがゲームをプレイする時間帯は大体固まっているため、ユーザは一斉に居なくなると思われる。その場合にサーバ機能をどう再配置するか。
• A)このモデルでは、DHTの上に各ゾーンが別れていて、その上にゾーンオーナ（データの管理ノード）とゾーンメンバ（データを必要とするノード）がある。
  ゾーンメンバはゾーンオーナが消えるとすぐ気付くため、迅速に次のゾーンオーナを決定できる。ゾーンメンバが一人も居なくなった場合は、データを必要とするノードがいないということなので、ゾーンオーナを作る必要はない。これによって、ユーザが一斉にいなくなった場合の問題は一部解決する。
  また、データを持っているノードが消えてしまった場合の問題は、DHTのレイヤで解決するべき問題と思っている。他のノードやサーバが重複したデータを持つことで対処可能。

• Q)目的とするゲームのジャンルによって、チューニングが必要ではないか。
• A)速度（応答性）を最重視。ピア間を直接接続することで、マッチングサーバ形式のFPSと同等の応答性は確保できると考えている。
  データの保管は、ゲームのデータ形式に関わらずある程度対応できると考えている。また、それぞれのデータの保管量はゲーム毎に異なるため、ゾーンをうまく分割する必要がある。実際にゲームを作ってみて前例を蓄積していく。

• Q)当初の目的と、ゲームベンダーによる課金やサポートの話は対立しているが、このモデルはゲームでビジネスをやろうとする企業の存在が前提なのか、それともサポート終了したゲームをユーザ側に運営委譲することが目的なのか？
• A)ユーザ側へ運営委譲することが目的なのだが、多くのゲームベンダーがゲームを作ってくれることが望ましいため、ビジネスで繋げる方向で検討している。

■[P2P]グリッドとP2P（首藤氏）

▼概要

本講演では、グリッドとP2Pという関連の深い2つの技術について、近年になって注目されるに至った経緯を解説する。特に、グリッドの歴史――グリッドの源流と、コンセプト登場当時の期待、そして現在に至る流れ――について深く掘り下げる。

▼関連サイト

• 「グリッドを支える P2P 技術」

  • ウェブページ (42 ページ)
  • PDF ファイル (2220 KB)
  • このスライドは 3パートから構成されてます。P2P 勉強会向けには、2パート目として「Grid とは何か」というパートを追加して使いました（当日のプレゼン資料そのものは非公開）。

▼講演内容

プレゼン資料が非公開のため、差し障りのない範囲で内容の一部を紹介します（P2P勉強会後に、資料の一部は公開されました）。

• P2P：明確な定義なし。様々な主張がある

• P2Pソフトウェア

  • P2Pファイル交換ソフトウェア
    Pure P2Pも使えることをWinnyで実証
  • P2Pコンテンツ配信、ストリーミング
    末端のPCが配信に協力
  • P2P分散コンピューティング
    SETI@home：基盤はBOINCとして分離、どこがP2Pなのか？
    P3: Personal Power Plant（産総研）→提供者・利用者の関係が固定的でない

• P2Pとは何か？
  （上は厳しい定義で、下に向かうほど緩い定義）

  • 集中的なサーバが存在しない（←Pure P2P）
  • 各ノードの役割が同じ（←Hybrid P2P）
    IRTF P2P Research Groupの憲章
  • ネットワークに参加しているピア同士が直接通信すること
    日経BYTE 2004.8「P2Pの真実」での定義（記事全文（会員登録が必要））
  • 末端の機器が重要な役割を果たすシステム（←分散コンピューティング）

• P2Pの性質

  • スケーラビリティが高い
  • 耐故障性
  • 集中サーバの管理コスト低
  • 利用の追跡／管理が困難

• Peer-to-peerからP2Pへ

• Peer-to-peer:

  • 遅くとも1980年代には使われていた単語（MacintoshのLocalTalk、UUCPを用いたUSENET）

• P2P:

  • 2000年前後に生み出された
  • ウェブの反動？
  • P2Pの技術的性質を、社会的意義として捉える人が多い
    ・直接通信→人と人を直接繋ぐ(person to person)
    ・末端ノードが重要→個人中心の社会
    ・各ノードの役割が同じ→フラットな社会（個人ネットワーク）
    「P2P」には、暗に社会的な期待が込められている

• Grid

• お決まりの「Gridの語源」

  • 電力(Electric Power Grid)からの連想で、コンピューティング資源（処理能力、データ、ストレージ等々）を電気のようなユーティリティとして扱うというコンセプト
    …ユーティリティコンピューティングは、グリッドを支える基盤

• コンセプトの萌芽

  • Metacomputer：資源を1台のコンピュータとして扱う
    "Metacomputing." Communications of the ACM, June, 1992, p.45*5

• グリッドの源流

  • 高性能計算（HPC）
  • 広帯域な広域ネットワーク
    I-WAY（1995〜）
    地理的に分散したスパコン群を束ねる米国のプロジェクト
    I-WAYのためのミドルウェアがGlobus Toolkitの元

• お決まりの「Grid本」

  • "The Grid: Blueprint for a New Computing Infrastructure", Nov, 1998*6
    Ian Foster, Carl Kesselman
    Gridに関連した論文を集めた本。Gridのコンセプトが知られるきっかけとなった
  • Building a Computational Grid Workshop, Sep 8-10, 1997
    上記書籍の著者を募る目的で開催された

• Gridへの要望（1997年のGrid観）

  • 実験(experimental)科学者からの要望
    ・MRIの結果を可視化
    ・CAVE…没入空間（中に入って体験する）
    にリソースがかかる
  • 観測(observation)科学者からの要望
    大容量データを運ぶためのネットワークも必要
  • Virtual ManufacturingでもGrid
    Designer、Supplier、Manufacturing Facility、Customerを結び付ける
  • 環境問題もGrid

• グリッドの定義

  • 「ネットワーク上に分散した異なる管理組織の異なる情報資源を動的に連携させて、ユーザに情報通信サービスを提供する技術」（産総研の関口智嗣氏）*7
  • コンピューティンググリッド、データグリッド、ビジネスグリッド

• 2002〜2004年、グリッドの現状

  • Extensible Terascale Facility(TeraGrid)
    スパコン群の集合
  • 気象予報グリッドポータル
    AISTスーパークラスタ―米国NCSA Cluster
    Webブラウザでポータルサイトにアクセスして利用
  • ATLAS/Grid Datafarm project
    実験データが膨大（1秒あたり数十MBのデータ。年間ではPB単位）
    大規模実験は2003年11月と2004年11月に、それぞれSC2003、SC2004に合わせて実施した
  • Karaoke Grid
    AIST+XING(JOYSOUND)+早稲田で開発。学会でも大盛況

• Gridに対する誤解

  • Grid = SETI@homeではない
    SETI@homeは遊休PCを利用している
    SETI@home自体はGridとは名乗っておらず、Public Resource Computingと言っている
  • PCクラスタ = Gridではない
    PCクラスタはGridの足回り
    計算のグリッドはPCクラスタで構築

• その他のトピック

  • Web ServiceベースのGrid

  • Globus Toolkit

    • OGSA
    • OGSI(v3)→WSRF(v4)

  • 標準化

    • Global Grid Forum(GGF)
    • OASIS Grid…WSRFの標準化
    • EGA

（講演時間が超過していたため、ここで終了）

▼質疑応答

• C)Peer-to-peerという単語の明確な定義はないという話があったが、「第5世代マネジメント」*8という本にpeer-to-peerという単語が出てくる。

• Q)残りの講演はどういう内容を予定していた？
• A)グリッドを構築するためのレイヤは複数存在し、その中の「リソース発見」のレイヤではP2Pの技術が使われる（ここでグリッドとP2Pが関連する）。この辺りの話については、上記関連サイトのプレゼン資料を参照。

■[P2P]ミニプレゼン1：井戸端会議スタイルがP2Pコミュニティを変える（慶応大学 山本氏、望月氏、森本氏）

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）

■[P2P]ミニプレゼン2：新月の現状報告（電気通信大学 福冨氏）

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• 新月 - P2P匿名掲示板

■[P2P][IPv6]ミニプレゼン3：P2P情報家電の試作と報告（株式会社アルファシステムズ 江守氏）

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• IPv6普及に向けた人に優しい生活エリアネットワークサービス実現のための研究開発の公募採択について（プレスリリース）

■[P2P]ファイル交換サービスと著作権問題（国際大学GLOCOM リサーチアソシエイト 福島氏）

▼概要

本講演では、ファイル交換サービスに関する近年の訴訟について、法律家の間での学説や現在の議論を元に解説する。

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• iSession Creative

▼講演内容補足

• 資料p.3〜5

  • プレゼン資料の中で「合法判決」とあるのは、あくまでサービスの提供が合法という意味。

• 資料p.4

  • ファイルローグ事件の東京地裁中間判決（2003.01.29）と判決（2003.12.19）の違いは、中間判決では法律的な判断だけを行い、判決では損害賠償額を確定した（現在控訴中）

• 資料p.5

  • ファイルローグ事件高裁判決（2005.03.30）は既に弁論が終了していて、高裁判決待ち。

• 資料p.7

  • Webのようにオンデマンドでデータを送信するという行為は、送信者が一斉にデータの送信（放送）を行うことを想定した「公衆送信」とは類型が異なる。そのため、「自動公衆送信」という類型を新たに作った。
  • 送信可能化＝自動公衆送信の前段階

• 資料p.8

  • プロバイダ責任法では、プロバイダにユーザの個人情報を開示する義務はない。

• 資料p.9

  • サービス運営者に対する訴訟の話。

• 資料p.10

  • Napster型が何故違法と判断されたか。
  • 寄与侵害責任：
    盗品の売買が行われていると知っていながら、場所を提供し犯罪を助長している場合など。
  • 代位責任：
    犯罪行為を代わってやってあげるという考え方。Napsterの場合は中央管理サーバを持っているので、特定ファイルを全て遮断することが出来るはずだということが問われた（実際に、Napsterには何万曲というリストが送られた）

• 資料p.11

  • クラブキャッツアイとは、カラオケ喫茶の名前。
  • カラオケの歌唱データを店が不正利用している場合、歌唱データを利用している（著作権侵害をしている）のはユーザである。しかし一人一人のユーザを訴えることは難しいため、その場所を用意している（利益を上げている）管理者が直接侵害していると見なす。

• 資料p.12

  • ファイルローグにおける図利性：
    「受信の対価を徴収するシステムに変更を予定していることが認められる」
    「将来、有料化したときには顧客数の増加に繋がる」
    などとして、将来の営利性をもって図利性を認めてしまっている（実際には、ほとんど営利は上がっていなかった）。この点は高裁で争っていると思われる。

• 資料p.13

  • 侵害に当たらない使用

    • グーテンベルクプロジェクト（日本の「青空文庫」に相当）
    • ファイル交換サービスに曲を流した後に、CD販売したバンドの事例

  • 敷地と設備

    • Groksterが利用しているFastTrack NetworkはGroksterの管理下にはない（別の会社のものである）ために寄与侵害責任ではない、という話になっている

• 資料p.14

  • この判決を紹介したのは、被告人（の弁護士）の主張が面白いから。
  • 「初期ノードは1個しか使っていない」と主張。裁判所もそれを認めている
    （Winnyの構造上ありえないのでは？）
  • 「被告人のインターネット回線は光ファイバーである。光は電気ではないから、自動公衆送信権で言う有線電気通信には該当しない」と主張。
    公衆送信は、基本的に有線電気通信を行っていることと定義されている。
    裁判所は「光も電磁波の一種」と言って公衆送信権の侵害を認めた
    （電磁波を使わない通信を発明したら現行の著作権法では著作権侵害にはならない？）

• 資料p.15

  • 犯罪を唆した場合は幇助ではなく教唆。

• 資料p.16

  • そもそも幇助にあたるのか？
    →法律家の間でも議論になっており、判決が出るまで分からない
  • 幇助の故意
    幇助の故意があったかどうかで判決が決まると予想されているが、概括的故意や未必の故意で、作者が知らない人の行為に対して幇助を問えるか？
  • 中立的行為
    価値中立的なものに対して幇助を問えるか？

• 資料p.17

  • Induce Act：著作権侵害の幇助行為、教唆行為を違法にする法律
    逆に、もっと著作権法を緩くする法律を提案する反対勢力もある
  • 日本では、来年に著作権法改正があるといわれる。それにつながるパブリックコメント等で中立的な行為については違法としないように求める提案も行われていた。
  • 合法的な行為の割合が多ければ多いほど、サービス運営者が罪に問われる可能性は低くなる。

• 資料p.18

  • 訴訟の対象にならない方法は、よく分からない。
  • ファイルローグは"notice & take down"*9の手順を取ることで、単なるインフラの形を取ろうとしたが、それは裁判所に認められなかった。
    （理由）プレゼン資料を参照
  • 逆に言うと……
    サービス運営者がユーザの個人情報を持っていれば、抑止効果として認められるのか？
    （最近では個人情報保護法の問題があるため、メリットがあるかは分からない）

▼質疑応答

• Q)（資料p.19について）P2Pのファイル転送は、常に著作権侵害の可能性を含む。ファイル管理を強し、著作権侵害が判明した際にそれを防ぐシステムを作り、サービス運営者がどこまで努力したかを明確にすることで、訴訟の危険を免れないか？
• A)基本的にはそういうことを考えている。
  しかし、ファイルローグの時は「著作権侵害を100%防ぐ必要がある」という話があったため、どこまで努力すればいいという線引きは難しい。
• Q)Pure P2Pの場合は？
• A)Pure P2Pの場合に、著作権侵害を管理できるかが分からない。ユーザがソフトウェアをハックした場合の責任の所在などを、裁判官がどう考えるか次第だろう。

• Q)Winnyのキャッシュは暗号化されており、ユーザはファイルの中身が分からない。そのような状態で、Winnyを起動しているだけの人は罪に問われるかどうか？
• A)Winny利用者の裁判（2004.11.30）では、中継者は単なる通路に過ぎないと言っている。ただし、違法なファイルをキャッシュに入れたのが自分ではないと立証する必要があるのではないか。
• Q)それは被告、原告のどちらが立証する必要がある？
• A)著作権侵害は民法709条（不法行為の要件と効果）で判断されるため、原則的には原告が立証する。
  しかし、著作権侵害は絶対権侵害であるために、裁判官が過失の推定を行う可能性があり、その場合は被告が自分で立証する必要がある。ただし、キャッシュ内の違法ファイルと同じファイルがPC上に無ければ立証しやすいのでは。

• Q)著作権法の第113条第2項によって、違法ファイルをキャッシュに入れたのが誰であろうと著作権侵害になるのではないか？
• A)Winnyに参加していること自体が問題、という説を採る人もいる。その説が裁判所に採用されるようなら、侵害になるだろう。

■[P2P]P2Pビジネスの将来を考える（アリエル・ネットワーク株式会社 徳力氏）

▼概要

本講演では、P2Pモデルが向くアプリケーションを「コンテンツデリバリー」「コミュニケーション」「コミュニティ」の3つのモデルに分類し、それぞれの事例を元に、P2Pモデルを採用することによるメリットを解説する。

▼関連サイト

• プレゼン資料（別ウィンドウで開きます）
• アリエル・ネットワーク株式会社

▼講演内容補足

• 資料p.6

  • GrooveがMicrosoftからの出資を受けた（2001年10月）頃がP2Pバブルのピークで、その後はアングラなP2Pアプリケーションこそ数多く登場しているが、ビジネスとしては停滞期に入ってしまった。
  • しかしその後、Skypeの登場やWinny開発者の逮捕を転機にビジネスの問い合わせが多くなってきた、と感じている。Skypeの利用者は指数関数的に増加中で、P2Pをビジネスやサービスに使う議論が活発になってきている、というのが現在の流れ（日立やNECでのP2Pプラットフォーム開発、BitTorrentを使ったエルゴブレインズのコンテンツ配信システムなど）。

• 資料p.9

  • distributeとdeliveryを一緒にした、大まかな分類になっている。
  • SNOCAPとPeer Impactは、大手の音楽事業者と提携して、著作権を考慮したファイル配信。一説によると、音楽事業者公認のサービスを作ることで法律のレベルを一段上げようとしているらしいという噂もある（公認のサービス以外は全て違法）。

• 資料p.10

  • Kontikiは、著作権管理が可能な大容量コンテンツ配信システムとして開発された。
  • Kontikiもコンシューマ向けのサービスを考えていたが、著作権関係の問題が大きかったために、当初はビジネス向けにフォーカスした事業展開をしている（社長の訓話を配信、トレーニングビデオのアーカイブなど。最近はコンシューマ向けも）。
  • 【講演者による補足】
    『シネクエスト映画祭』、P2Pで出品作をダウンロード提供(Hotwired Japan)

• 資料p.13

  • コンテンツ配信で一番難しいのは、配信ピークのコントロール。Kontokiは配信コストを平準化することで、設備コストを下げる。

• 資料p.15

  • 今回紹介するアプリケーションについて、どの場合も「ビジネス系にはサーバがある」ということを強調したい。
  • Kontikiでも、コンテンツ配信の大本になるサーバが存在している。また、サーバ側は冗長化されている。

• 資料p.19

  • Skypeでも、ユーザ情報やスーパーノードを管理するサーバが存在している。
  • また、SkypeOutではインターネットとPSTN（公衆電話交換網）の中継地点にサーバが必要になるため、そこにかかる負荷が問題になっているらしい*10。

• 資料p.23

  • ここまでの「コンテンツデリバリー」と「コミュニケーション」はヒットしたソフトウェアが既にあるため、P2Pが向いている分野と認められているが、「コミュニティ」というアプローチは今後の分野と考えている（アリエルの製品もこの分野に該当）。

• 資料p.24

  • 個人的に面白いと思っているのはmercora。
  • 音楽事業者の許諾を受けた上で、ネットラジオサービスを提供（ユーザ間で音楽をストリーミング配信）。音楽のジャンル毎にコミュニティが出来る仕組みがある。

• 資料p.28

  • アリエルのコーポレートソリューションでも、ファイアウォールを越えた通信などをサーバ（パブリックノード）で実現している。

• 資料p.29

  • Skypeの場合は複数ユーザが同時にログインしている必要はないが、グループウェアの場合はお互いのスケジュールを共有する必要があるため、ワークグループ・ノードというバックアップサーバを設置することでデータの同期機能を提供。

• 資料p.32

  • 静的なデータを扱う場合と、リアルタイムなデータを扱う場合では、求められる特徴が全く違う。

• 資料p.34

  • 普通の通信事業者はARPU(Average Revenue Per User)を考えているが、SkypeはARPE(Average Revenue Per Employee)を考えている。社員1人当たりの売り上げが上がれば良い、と発想を変えることでビジネスになった。
  • なんといってもP2Pの魅力は一人で開発したソフトが世の中に大きな影響を与えられること。もっといろんなアプリが出てくるようになって欲しい。

▼質疑応答

• Q)アリエルでは、SNSなどのP2P的なビジネスモデルを検討しているかどうか？
  また、検討は行ったがビジネスになる目処が立たないと判断しているのか？
• A)理由は2つある。
  1. 単純に人が足りないという点。
  2. コンシューマ向けのアプリでは、WinnyやNapsterのような道を辿るリスクがある。
  そのため、現状はビジネス向けにフォーカスしている。

• Q)ビジネスアプリでP2Pを利用することによる、コスト的なメリットはあるか。
• A)サーバ機器は安いため、グループウェアの場合に機器コストの面ではメリットは少ない。しかし、部門内にサーバを分かる人がいない場合は、人的コストの面でメリットがある。また、大容量のコンテンツを扱うところではメリットが出る場合もある（CADの図面など）。

• Q)社内で既に導入されているサーバ型グループウェアから、アリエルの製品へ移行する際のノウハウを教えてほしい。
• A)サーバ型グループウェアの置き換えは、現在の製品ではあまりメインのターゲットにしていない。
  既存のグループウェアはそのまま残して、アリエルの製品と併用することでユーザの利便性が向上する点をアピール（オフラインでのデータ閲覧、自宅から社内へのアクセス、トラフィックの平準化、など）。
  また、社内での情報共有には既存のグループウェアを使い、社外のプロジェクト関係者との情報共有に使うためにアリエルの製品を買ってもらうというケースも多い。

• Q)社内の情報と社外の情報を切り分けることはできるか。
• A)Ariel AirOneでは「ルーム」という単位で情報を切り分けることが可能で、異なるルーム同士は、別のグループウェアであるかのように分離される。
  ただし、「何か予定が入っている」という情報は、詳細を隠してルーム間で共有する。

• Q)企業では情報漏洩対策として、シンクライアント化＋サーバ一極集中という強い潮流があるが、そのような動きに対してはどう対処していくか。
• A)ポリシーの問題なので、そういう情報漏洩対策が重要な企業はサーバー型のほうが良いと思う。ただ全てがそうなるとは思っておらず、シンクライアントではモバイル時にオフラインでのデータ利用ができないなど利用者に不便な面がいろいろ出てくるはず。現在はそういう利用者の利便性を向上したい企業が主なターゲットになる。
  また、集中と分散の議論は昔から延々と続けられている議論なので、今後また逆の方向に流れる可能性もあると考えている。

■閉会の挨拶（Tomo's Hotline管理人 西谷氏）

• 第3回P2P勉強会

  • 1人で100名以上をまとめるのは大変なので、次回からは事務局を作りたい。
  • 出来れば大学生や若手社会人に参加してもらいたい。講演者も募集中。

• 第2回mixi P2Pコミュニティオフ会

  • 次回はコンテンツ配信の話題を中心にしたいと思っているのだが、こちらも講演者を募集中。
  • 会場を提供してくれる方も募集中。

■謝辞

今回は、議事録を公開するに当たって、事前に講演者の方々に内容をチェックして頂きました。お忙しい中、お時間を割いて頂いてどうもありがとうございます。また、議事録作成中にご相談頂いたP2P todayの横田氏、そして勉強会参加者の皆様にも感謝します。今回もいろいろと勉強になりました。

個人的に今回は、議事録を取るなら講演者の方々に前もって話を通しておくべきだった、と反省しています。加えて、これ以上P2P勉強会が拡大化すると個人で議事録を作り込むのはもう無理そうなので、第3回前には、どこまでの記録が必要かも含めて事前にいろいろ考えておきたいと思います。その際はご協力頂ければ幸いです_|￣|○

■更新履歴

2005/03/13

初版を公開しました。

2005/03/14

飯村氏のプレゼン資料が公開されましたので、関連サイトに追加しました。

2005/03/14

首藤氏の講演を追加しました。

2005/03/15

福島氏の講演を追加しました。

2005/03/17

山田氏の講演を追加しました。未公開分の議事録は以上です。

■[Wiki]WikiばなVol.4

3月12日（土）のWikiばなVol.4に参加してきましたので、感想を書いておきます。10日も前のイベントなのに、物凄く今更で申し訳ありません。10日のうち5日はインフルエンザで寝込んでいたので勘弁してください……残りの5日分は見逃してください_|￣|○

WikiBana/VOL.4 - Wiki博覧会
http://wikibana.socoda.net/wiki.cgi?WikiBana%2fVOL%2e4#i1

WikiBana/VOL.4/レポートリンク集
http://wikibana.socoda.net/wiki.cgi?WikiBana%2fVOL%2e4%2f%a5%ec%a5%dd%a1%bc%a5%c8%a5%ea%a5%f3%a5%af%bd%b8

今回のWikiばなは、各種国産Wikiが怒濤の勢いで（12種類×10分）紹介される『Wiki博覧会』ということだったので、仕事場で使えそうなWikiの新機能とか聞けたらと思って参加しました。全体的な感想としては……「Wikiの多機能化は着々と進んでいるなぁ」という感じです。勉強になります。

以下は、各講演の簡単なメモです。

----

▽ Hiki

アジャイル。特大フォントを使って要点のみを言い切る高橋メソッドによるプレゼンテーション。

Hiki本体より、プレゼン手法の方が強烈に印象に残りました。短いプレゼンでは、話に引き込むのに有効そうです。ただ、常にクライマックスみたいなプレゼン手法なので、（今回は10分だから良かったけど）あまり長いプレゼンでこれをやられたら、ちょっと疲れるかも……。

----

▽ PukiWiki

PukiWikiは活用事例が豊富。書き込む人の心理的な障害をなくす方向に進化させていきたいらしい（見た目を掲示板っぽくする、など）。

PukiWiki本を7月リリース予定（まだ1ページも書いてない）。

----

▽ FreeStyleWiki

FreeStyleWiki以外にも、FSWikiLiteやしょぼしょぼ日記システム（sns）などを開発中。

今後はInterWikiシステムの進化を考えているとか。

----

▽ MoinMoin

海外でメジャー。強力なユーザ管理機能を持つ（ユーザ登録しないとIPアドレスが晒される）。Wikiの中でも強力なバージョン管理機能を備え、任意の2バージョンのdiffをViewCVS風に表示できる。また、特定ページの更新状況を監視可能（e-mailで通知）。

----

▽ NOTA

Flashによるウェブサイト作成ツール（Wikiとは少し違う）。保存→公開のタイムラグが無い。読む前に書く、発信型インタフェイス。

パワーポイントのようにオブジェクトを組み合わせてサイトを作り、オブジェクト単位で作成者（管理者）情報を持つ。外部のswfファイルを読み込むことで、追加機能をプラグイン。教育現場での事例あり。

将来的には、スタンドアロンNOTAを開発。

見た目の感想としては、なんだか昔のワープロソフトみたいです。個人的にはあまり使う気は起こらないのですが、年配の方が町内会のパンフレットを喜んで作りそうというかなんというか……。パソコンを使いこなせていない人（ネット中毒じゃない普通の人）には結構受けそうな気がしました。

----

▽ wema2

文字を追加するたびに付箋が減っていくインクリメンタルサーチがインパクト大。wema2の用途としては、howmの覚え書き（プラグイン）や本棚wemaなどなど、何にでも使って欲しい、とのこと。

今後は、高速化、Wema Farm（ドメイン取得済み）、OOPLソースの可視化を予定。

----

▽ ContentEditableWiki

WYSIWYG編集。他のサイトの内容をD&Dで取り込み可能（！？）

----

▽ ThreadWiki

特徴は名前空間。名前空間が違えば、同じ名前のページを複数登録可能。名前空間はテキストだと重いので、データベースを利用している。

名前空間によってページをXML出力可能なので、今後はこれを活かした機能を追加したい。

• ThreadWiki内でXMLを交換→SNS？
• Webサービスのリソースを利用
• Office（XML出力）とのコラボ

----

▽ RandomNote

メモツールとしてWikiを使っていたが、うまくいかなかったので自分で開発した。WikiYallowで使われている。

----

▽ MirrorMan*1

人の思考をミラーするのでミラーマン。多人数の同時リアルタイム編集（編集内容を即座に反映）。見出しの上にマウスカーソルが載るとページ内容をリアルタイムに取得する、などなど、Ajaxの固まり。

JavaScriptで全ての処理を実行するコンセプトで、最終的にはCGIは5行に収まる予定。サーバレス化、P2P化を見越してJavaScript化を進めている。

Wiki機能のほとんどをJavaScriptで実現することが、どうしてP2Pに繋がるのか、を聞きたかったのですが、体調不良のために懇親会参加できなかったので未だによく分かりません（というか、誰とも喋らずに帰って来ちゃったんですけどね……はぁ）。

----

▽ Clockworks

ページの内容だけでなく、機能までもが「誰でも編集可能」なWiki。WikiEngineがスクリプトのインタプリタとして動作する。Lisp好きだったら物凄く楽しそう……。

----

▽ qwikWeb

ML参加者だけが見られるWiki。MLのログをWikiで参照。MLとWikiを行ったり来たりする。

アドホックにグループ（MLとそれに対応したWiki）を生成できる、オープンなWebとBasic認証の中間のようなサービス。コンセプト的にSNSに似ている。過去の履歴表示が独特（タイムマシーンモード）。また、ビデオ編集のプラグインを備えており、芸大での講義のビデオから要点のみ切り出すのに利用している。

徹底したモジュール化。一緒に作りたい人募集中。

■[P2P]Bloom filterの解説文

最近、アリエルエリアのホームページがリニューアルされたのをきっかけにサイト内のドキュメントをいろいろ覗いていたら、チーフアーキテクト井上氏によるBloom filterの解説文がありました。去年の11月には既に公開されていたようなので今更ですけど、参考になりそうなのでご紹介します。

Bloom filterの説明(アリエルエリア)
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=18

前半はBloom filterの分かりやすい動作イメージの話で、後半はこの技術がどのように役立つかという応用の話です。前半については原文を読んでもらうとして、後半部分を一部引用します。

Bloom filterには、以下の特性があります。

• 少ないデータを転送するだけで、存在チェックのヒントを相手に渡せる
• Bloom filterの和は、ビット和を取るだけでできる
• 秘密を保ったまま、自分の手札をさらせる
• Bloom filterを比較(同じビットが立っているか否か。つまりXOR演算)することで、近さの判定ができる

去年の9月に開催された第1回P2P勉強会での福冨氏の講演にて「TapestryというDHTアルゴリズムがBloom filterを用いて検索を最適化している」というコメントがあったのですが、1番目の特性はそれに相当するものですね（2番目の特性も多少関係するのかも）。

一方、3番目と4番目の特性はだいぶ毛色が違って、大雑把にまとめると「自分が持つ情報の具体的な内容は秘密にしたままで、その情報との類似性を判定するための材料を提供できる」という特性です。

例えば、文中で取り上げられているLOAFは、アドレス帳（メールアドレスの集合）をBloom filterにかけた結果を友達の間で共有することで、初めて送られてきたメールの送り主が「友達の友達」かどうかを判定できるというもののようです。それでFOAFに似た名前が付けられているのか、と。

僕は今まで、こういう類似性の判定は信頼できる第三者が居なければ不可能なことだと思っていたのですが、第三者に頼らずBloom filterでこういうことが出来るなら、P2Pソフトウェアの幅も広がりそうですね。