無印吉澤(※新エントリは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/02/27) 最新 次の日記(2005/03/22)» 編集

2005/03/13 第2回 P2P勉強会議事録

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

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

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

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

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

開会の挨拶(Tomo's Hotline管理人 西谷氏)

▼概要

P2P勉強会開催の経緯

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

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

▼概要

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

▼関連サイト

▼講演内容補足

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

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

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

  • 資料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へと適用した製品やソリューション事例を示す。

▼関連サイト

▼講演内容

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

  • 我々の仕事のテーマは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)を用いてデータの管理を行うことを特徴とする。

▼関連サイト

▼講演内容補足

  • 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を利用(データの管理と異なり、ゲームの理解は不要)

  • 問題点

    • 悪意のあるノード
      データの改竄、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とは何か?
    (上は厳しい定義で、下に向かうほど緩い定義)

  • 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][IPv6]ミニプレゼン3:P2P情報家電の試作と報告(株式会社アルファシステムズ 江守氏)

▼関連サイト

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

▼概要

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

▼関連サイト

▼講演内容補足

  • 資料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
山田氏の講演を追加しました。未公開分の議事録は以上です。

*1 あいうえおDHTはハッシュを使っていないので、厳密な意味ではDHTではありません(西谷氏談)。適切な名前を勝手に考えるならDistributed Initial Table(分散頭文字テーブル)とか、Distributed Iroha Table(分散いろはテーブル)とか……?

*2 XFsection-DHT(Distributed Hash Table)メモ & リンク集(アリエル エリア)

*3 P2PとComplex Network理論の接点(TellaGate Project)

*4 Mobile Ad-hoc Networks (manet) Charterを見る限りでは、DSRはまだRFC化されていません(2005年3月現在)

*5 Metacomputing

*6 The Grid: Blueprint for a New Computing Infrastructure(邦訳なし)。現在は第2版(The Grid 2)が出版済み。

*7 第41回 基調講演「グリッドの可能性と現実」(wisdom Business Leaders Square)

*8 第5世代マネジメント―ネットワークが企業を変える

*9 ノーティス・アンド・テイクダウン(マルチメディア/インターネット事典)

*10 急成長を続けるスカイプに思わぬ落とし穴(CNET Japan)

[]

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日以上前の日記へのコメント及びトラックバックは管理者が確認後に表示します。
また、この日記に無関係と判断したコメント及びトラックバックは削除する可能性があります。ご了承ください。