宛先を 担当するノード ルーティング 結果の経路 ! 配信元 配信木 同一 ID へ向けた経路群の集合が配信木を構成する 図 4 ツリーベース (tree-based) の方式 図 5 構造化オーバレイを使った配信木の構築 には Narada や ALMI が該当します。例 ツリーベースのデータ転送 えば Narada は、 IP マルチキャストの配 ツリーベースの手法では、ノード群 信木構築プロトコルである DVMRP と同 がマルチキャストのためのデータ配信 様の手法で、配信木を構築します。 木 (distribution tree) を構築し、木構 また木構造の構築に、構造化オーノヾー 造に沿って根から葉に向かってデータを レイを用いる方法もあります。構造化 転送します ( 図 4 ) 。マルチキャストと聞 オーバーレイとは、ノード間の隣接関係 いて最初に思いっく、もっとも素直な方 にアルゴリズム上の制約が設けてある 法ではないでしようか。データが流れる オーバーレイを指します。その上で、ノー 前に配信木という経路が定まっているた ドとオプジェクト ( ファイルなど ) の双方 め、データがノードに到達するまでの時 に振られた ID の値に基づいて、ルーティ 間、つまり遅延と、遅延の揺らぎ ( ジッ ングが行なわれます。構造化オーバーレ タ ) を抑えやすいという利点がありま イの応用としてもっとも有名なのは、分 す。また、配信木の形状がすなわちデー 散ハッシュ表 (Distributed HashtabIe 、 タの流路なので、配信木の構築をとおし 以下 DHT) でしよう。ほかにもメッセー てデータの流路を厳密に制御できるとい ジ配送や、これから述べるようなマル う利点もあります。帯域幅の狭い経路、 チキャストやェニーキャストへの応用が 不安定な経路を明示的に避けるといった 可能です。構造化オーバーレイのアルゴ ことも素直に行なえます。一方でノード リズムは 2001 年から多数の発表があり、 の故障や、日常的に発生する突然の離脱 代表的なものに Chord 、 CAN 、 Pastry 、 に際しては、素早く配信木を修復する必 Tapestry 、 Kademlia があります。 要があり、こで問題が生じると配信が 構造化オーバーレイでは、各ノードに ID 失敗します。故障もしくは離脱したノー が振られます。 ID は 160 ビットや 128 ビット ドが配信木の根に近い場合、その影響は の非負整数であることが多く、 SHAI な 大きいものとなります。 どの暗号学的ハッシュ関数の出力が使わ ツリーベースの手法でます問題となる れることも多いです。各ノードは ID 空 のは、配信木を構築する方法です。マル 間 ( リング ) の一部、一般的には自らの チキャスト用のオーバーレイにノードが ID の周辺を担当します。ここで例えば 直接参加する方法もあれば、事前にノー DHT であれば、各ノードはキーの値が ド群でメッシュ ( グラフ ) を構成し、そ 自らの担当である場合に、そのキーと値 の上に配信木を構築する方法もありま の組を保持します。そして検索の段階で す。前者には Overcast や Yoid が、後者 は、キーの値を宛先としたルーティング SPECIRL C 36 UNIX magazine 2006 Autumn

信木に参加することになります。各ノー ら 10 ノードに対して転送でき、受信可 が行なわれます。このルーティングは、 ドはどれかただ 1 つの配信木で子を持ち 能なノードの数をそれだけ増やすことが 該当するキーと値の組を保持している ます。複数配信木を構築する ALM には、 できます。 ノードに到達するというわけです。 ほかに Chunkyspread などがあります。 ここで同一の ID を宛先として、複数 ここで、配信木を構成する各ノードの 上り帯域幅について考えます。子を持つ の異なるノードからルーティングを行 メッシュべースのデータ転送 ノードは、データを子に転送するために なった場合を考えます。各ルーティング 上り帯域幅を活用しています。持ち得る 木構造には、親が 1 つである、ノード の経路は、最終的には同一の担当ノード 間に親・子という方向がある、といった 子の数が、上り帯域幅によって制限され に収束します。これら複数の経路の和集 いくつかの制約があり、この制約に従っ 合は、木構造を構成します ( 図 5 ) 。 る点にも注意してください。このことは 配信木を構成する際に、各ノードの帯域 てデータが流れます。これに対し、より の木構造を配信木として使おうという 緩やかなノード間の関係に基づいてデー 幅、特に上り帯域幅を考慮する必要があ のが、構造化オーバーレイを使ったマ タを転送していくメッシュべースの方式 ることを意味します。続いて子を持たな ルチキャストの基本的なアイデアです。 も提案されています。ここでは、ノード いノード、つまり配信木の葉の場合はど Scribe は、構造化オーバーレイのアルゴ うでしよう。ほかのノードに対してデー 間に親子関係がなかったり、ノード間の リズムである Pastry を使って配信木を タを転送していないということは、上 関係が枝の有無といったゼロ / イチでは 構築します。それは配信木の根をランデ 定まらなかったりする、比較的ノード間 プーポイント (Rendezvous point) と り帯域幅を活用していないことになりま の関係が緩やかな構造を大雑把にメッ す。木構造において、葉となるノードの して、そこから葉に向けてデータを転送 シュと呼びます 数は案外多いものです。各ノードが 2 つ していくという ALM です。 メシ上全ノードに対してデー の子を持っバイナリツリーですら、半分 上り帯域幅を活用しつくすための 複数ツリー タを配布する方式として、 flooding とい 強のノードが葉となります。各ノード う単純な方式がよく知られています ( 図 が 16 の子を持っとしたら、 9 割を超える 昨今のインターネットは Web 向きに 6 ) 。 flooding は日本語で「洪水」「氾濫」 数のノードが葉となります。 ALM にお 設計されており、 P2P ソフトウェアの であり、文字どおり、メッシュ上にデー いて、系全体にとっての貴重な資源であ 動作に適さない構造が各所にあります。 タを氾濫させます。 P2P 関係では、ファ る上り帯域幅を活用しないというのは、 アクセス系ネットワークについていえ イル共有プロトコル Gnutella で検索クエ もったいないことです。 ば、 NAT の普及による双方向通信の阻 リの拡散に fl 。 oding が使われていること そこで、複数の配信木を構築して、 害や、非対称 DSL (ADSL) での上り方 が有名です。 それぞれの配信木ではデータの一部分 向帯域幅の狭さがその例です。特に上り flooding では、各ノードは隣接ノード を流すという手法が考えられました。 帯域幅の狭さは、 ALM で非常に大きな SplitStream は、複数の配信 問題となります。 ALM では、各ノード 木を構築する ALM です。 が受信したデータをほかのノードに提供 で構築される複数の配信木は するので、受信のための下り帯域幅だけ forest と呼ばれます。それぞれ でなく、送信のための上り帯域幅が重要 の配信木は Scribe の手法で構 となります。上り帯域幅が広いほど、ト 築し、データストリームを時間 ラフィックをより大きく増幅できると 方向に分割したものを、複数 いうことです。例えば、 500kbps のトラ の配信木に分散して流します。 フィックを受信している場合、上り帯域 つまり、ノードは必要なデー 幅が 500kbps なら 1 ノードに対してしか タを揃えるために、複数の配 転送できません。しかし 5Mbps だとした ー②未送信 & 転送 3 未送信 & 転送 2 ②受信済 & 転送せす 3 3 図 6 flooding 37 UNIX magazine 2006 Autumn

する論理的な空間を構築し、これをハッ 見するルーティングプロトコル (AODV * 13 や DSR * 14 など ) が使われている。一方 シュ関数などを用いて分割統治する。同 時に、全空間に対して n 分木探索がかけ で、 DHT 的な論理構造の考え方をアド ホックネットワークに適用している研究 られるように、ノードごとの隣接関係を * 15 もある。これは通信の不自由さの中で 構築する。例えば図 6 は、 Chord アルゴ リズムに則った、 8 ノード間の理想的な も、ノード間で合意した論理構造を用い ネットワーク ( 論理空間上のノード間の 通信できる可能性を示している。 隣接関係 ) を示したものである。ノード 2 つの「アーキテクチャ」 は仮想的な円周上に配置され、アルゴリ ズムによって定められたノード間を接続 これまで、一見関係のない 2 つの「アー キテクチャ」について述べてきた。 する。その結果、すべての空間に対し て 2 分木探索することが可能になり、探 でその論点に共通する「構造」を整理し 索のコストはノード数を N としたときに てみようと思う。 構造には、中心を持つものと持たない ん g2 N に比例する。 ものがある。中心を持つものには、ヨー 理想的には、 DHT のノード間のつな がりは幾何的に対称となり、負荷は均等 ロッパの教会を中心とした街、単純なテ ントや大黒柱を中心とした古典的日本家 に分散する。その結果、処理能力が低い ノードの集合でも、システム全体で高い 屋、中心にエレベータシャフトと巨大な 処理能力を達成できる。ちょうど、強度 柱を持つ一般的な高層ビルが挙げられ の低い集成材で巨大な空間を構築した樹 る。そして単純なクライアント / サーバ 海ドームのごとく、あるいは幾何的に対 システムや、その結合物である DNS 全 称に張られたサーカスの巨大テントのご 体の構造、あるいはクライアント同士も 「梁」にあたる通信を行なうハイプリッ とく、軽くて大きい構造を作ることがで ド P2P も同じく中心を持つ。 きる。 このような構造の利点は、まず設計 なお DHT の動作原理の詳細な説明は、 と実装 ( 施工 ) が簡単なことである。特 本誌の西谷智広氏による解説や、過去の 特集にあるため割愛する。なお、この に、外部からの攻撃から構造を守るため ような構造化オーバーレイネットワーク の事前の設計は、大黒柱となる中心部を に対して、 GnuteIIa などの古典的な P2P 守る設計を達成することで概ね達成され ネットワークを、非構造オーバーレイ る。また、システムという意味では管理 ネットワーク (Unstructured Overlay も簡単である。建築とは異なり、計算機 システムは頻繁にリニューアルする ( 建 Network) などと呼ぶことがある。 築物の寿命を考えれば、建築も頻繁にリ また特殊な構造の例としては、通信に 対する強い制約下で研究・利用されてい ニューアルするという前提に立つべきだ という考え方もある ) 。そのとき、更新 る、アドホックネットワークで利用され するのは中央のサーバのみか、それとも る構造がある。古典的には、近隣のノー ドとの局所的通信を繰り返し、宛先ノー すべてのノードあるいはクライアントを 更新しなければならないかで、手間やコ ドにメッセージを届けるための経路を発 図 6 理想的な Cho 「 d ネットワーク (N=8) SPECIRL E' * 13 C. Perkins, et. al., Ad-hoc On-Demand Distance Vector Routing, 2nd IEEE Workshop of MobiIe Computer Systems and Applications, 1 999 * 14 D. B. Johnson, et. al., DSR: The Dynamic Source Routing Protoco け 0 「 Multi-Hop Wireless Ad Hoc Networks, in Ad Hoc Netwo 「 king, pp. 139-172 , Addison-WesIey, 2001 * 15 M. Caesar, et. al., Virtual Ring Routing: Network routing inspired by DHTS, ACM SIGCOMM 2006 60 UNIX magazine 2006 Autumn

うに中心を持たず対称な構造、クライア ント / サーバのような単一の中心を持つ 構造、サーバロードバランサのような多 心構造、アドホックネットワークのよう な通信に制約がある環境に適した構造な どがある。すべては、与えられた条件の 中で、与えられた荷重を適切に支えるた めの構造である。 実際に我々が「生活」するユビキタス ネット社会は、これらの構造で支えられ ている。そして情報量が増大する可能性 を考えると、多量な ID やデータを、広 域かっ分散したシステムの上で適切に処 理する必要がある。特に実際の生活空間 を支えるためには、実践の積み重ねが重 要になってくるだろう。 自律分散アーキテクチャでは、従来 サーバサイド技術やクライアントサイド 技術などと分類されていた多様な技術を 組み合わせ、より高度な構造を作りあ げる必要がある。特に実践面では、シス テム構築に携わる多くの方に、 P2P や DHT を用いたアプリケーションの構築 を体験していただきたい。そういった意 味で、 OpenDHT*28 や OverIayWeaver といった環境やツールキットが充実して きたことは喜ばしく、また心強く思う。 また具体的なテーマとして、トレーサ ビリティというフィールドにおける、識 別子 ( 商品 (D) と意味のあるデータの 対応関係 ( メタデータ ) を取り扱う名前 空間と、それを支える構造についての取 り組みを紹介した。個人的には、この構 造は目的に沿って階層化することで効果 を引き出したものであり、広域分散アプ リケーションにおける複合構造の 1 つだ と思っている。 大規模を目指す、ある意味個性のない * 29 複合構造によるシステムを現代的である とすれば、次世代的の方向は、ソーシャ ルネットワークサービスに萌芽がみられ るような、属人的で、個性的で、きめ 細かいネットワークへの回帰かもしれな い。個人の信用というものに、ネット ワーク構造や計算により価値が決められ る通貨 (WAT 券 ) を対応付ける斉藤賢 爾氏の研究 * 30 ( 本誌にも関連記事が掲 載 ) は、そのような意味で次世代的な仕 事の端緒であるといえるだろう。 さて今回の記事は、勇気を出して本来 私が専門としない領域の議論を援用しな がら、今まで曖味にされていた P2P の 構造的な位置づけの明確化に挑戦した。 したがって、特に専門外である建築関連 の議論については強引な部分もあるかも しれない。そういった誤りの部分のご指 摘も含めて、建築・都市・計算機ネット ワーク・ヒューマンネットワークなどの 議論を深めたいと思っている。当面は、 私も属する WIDE Project IDEON-wg などで議論を行なっていくつもりだが、 このような議論に興味がある方は、是非 コンタクトをしていただければと思う。 謝辞 オーバーレイ研究についてつねに刺激 と進むべき道への手がかりを与えてく れ、また私の妙な思いつきに真剣に向き 合ってくれる WIDE Project IDEON- wg の皆様、建築領域のよい「はじめの一 歩」を教えてくれた藤原徹平氏、そして 今回の機会を与えてくださった皆様に感 謝いたします。なお、本研究の一部は総 務省による平成 17 年度「電子タグ高度利 活用技術に関する研究開発」事業にかか る委託研究の成果によるものです。 * 四首藤ー幸ほか、オーバーレイ構 築ツールキット Overlay Weavers SACS 旧 2006 論文集、 2006 * 30 K. Saito, Peer-to-Peer Money: Free Currency ove 「 the lnternet, HSI 2003, 2003 UNIX magazine 2006 Autumn 65

ストは段違いとなる。 一方、中心を持たないものは 2 種類に 分かれる。 1 つは明確な全体構造を持た ないもので、建築ではダンポールハウス の集団や無計画に発展する都市、あるい は黒川氏が提唱したモジュール化された 局所的構造である。そしてネットワーク においては、 Gnutella や Winny などのい わゆる P2P ソフトウェア、アドホック ネットワークなどが挙げられる。 こういった局所的構造あるいは非構造 は、外乱に対して柔軟に形を変えてい くことができる。黒川氏の設計には、モ ジュール化されたユニットを発展に応じ て結合することで、中心を持たずに全体 が形を変えていくという発想が随所に 見られる。アドホックネットワークはま さにそのものを目指したものである。そ して GnuteIIa 的なネットワークは構造化 オーバーレイに比べ、ノードのネット ワークへの参加離脱が多数発生する場 合に、より対応しやすいといわれる * 16 一方で、ラゴスの交通が麻痺状態である ように、 GnuteIIa のような設計の介在し ない構造も、簡単に通信を輻輳させる可 能性がある。 中心を持たない構造のもう 1 種には、 明確な構造がある。幾何的には中心があ るものの、そこには柱などが存在しない という意味で、建築ではアーチやドーム 構造が挙げられる。また DHT のような 構造化オーバーレイは、ネットワーク側 からの代表といえるだろう。 このような構造は、中心を持つ構造に 比べて軽量であったり、巨大化が可能で あったりという利点がある。これは主に 材料あるいはノードに均等に負荷がかか るためである。一方で、構造を一時的に 崩してしまったり、外乱や攻撃などによ り一部に集中的に負荷がかかったりすれ ば、バランスが乱れ崩壊するリスクもあ る。非構造オーバーレイに比べて、ノー ドの参加離脱が多数発生する場合に不利 であるといわれる理由も、同様の理由か らである。なお、構造化オーバーレイが 不利なケースのいくつかについては、反 論も存在する * 17 大館樹海ドームの外周部にはコンク リートの堅固な足場があるように、一定 以上の建築物あるいはシステムは、用途 に応じて構造を組み合わせている。前述 の東京都庁舎のような構造は、現在のイ ンターネットのいくつかの場面でみられ る。例えば GoogIe は安価な PC べースの 機材を組み合わせて、専用の巨大なシス テム * 18 を構築している。また、 DNS の うち一部のルートネームサーバは、 IP Anycasting と呼ばれる経路制御上の技法 を用いて、多数のサーバを 1 つのサーノヾ であるかのようにみせている * 19 。 DNS の 例は、ある 1 本の柱にかかる負荷を、多 数の支柱を組み合わせて分散させたよう な事例に相当するだろう。 忘れてはならないもの : 視線の高さ これまでの議論では、まったく異種の 存在を意図的に同じ視線で語った。しか し実際にはこのような議論は、視線の高 さをどこに定めるかによってまったく異な る像を結ぶ。代表的な例は WWW であ る。 Tim Berners Lee の発明は、テント のごとく単純なクライアント / サーバシ ステムを多数組み合わせて、その間に「リ ンク」という回廊を設置し、システム間 の断絶を消し去ったことにある。 WWW はクライアント / サーバシステムという * 16 」 . Risson, et. al., Survey of Research towards Robust Peer-to-Peer Networks: Search Meth0ds, University of New South Wales Technical Report, UNSW-EE-P2P-1-1 , 2004 * 17 M. Castro, et. al., Debunking some myths about structured and unstructured overlays, NSDl'05, 2005 * 18 L A. Ba 「「 0S0 , et. al., Web Search fo 「 PIanet: The Goog Cluster Architecture, IEE Micro, 2003 * 19 http://www.root-servers.org/ UNIX magazine 2006 Autumn

ど、多額の費用がかかりました。そこ に ALM を利用することで、極めて安価 な配信が可能となります。例えば、単純 なクライアント / サーバ型のライプ配信 では、配信元には視聴者の数に比例した ネットワーク帯域幅が必要となります。 それに対し ALM では、 1 ~ 数ノードに対 して配信する能力があれば充分です。 れによって、誰でも世界中に向けた大規 模発信が可能となります。これまで Web が実現してきた文書や静止画についての 総発信社会が、ライプ映像についても現 実のものとなります。 技術的特徴 ウタゴ工株式会社の Ocean Grid の技 術的特徴を挙げます。とにかく実用本位 という方針で開発しています。 単一配信木 間、または測定サーバを相手として帯域 応じて設計します。必要に応じてノード 配信木の構造は、各ノードの帯域幅に までの遅延を抑えることができます。 間が比較的短く、それだけ配信から再生 あるため、末端にデータが届くまでの時 りません。また、ツリーベースの手法で 起きても映像・音声が途切れることはあ 少の間保持しているため、木の再構築が 木を再構築します。受信したデータを多 脱があった場合は、数十ミリ秒のうちに 向けてデータを転送します。ノードの離 構築した配信木に沿って、根から葉に ています。 法も、プロトタイプ実装および試験をし とっています。ツリーベースではない手 単一の配信木を構築するという手法を 比較的古く、また確立されつつある、 幅を測定し、その結果に応じて、ほかの ノードへの中継をするかしないかを決め ています。 ハイブリッド P2P P2P システムとしての構造は、ハイ プリッド P2P です。つまり、配信木の 構造はトボロジ管理サーバが集中的に決 めて、各ノードに指示を出します。ハイ プリッド P2P のシステムは、サーバが 単一故障点となることが弱点ですが、そ こはトボロジ管理サーバの冗長構成でカ ノヾーします。トボロジ管理サーバは、バッ クアップを含めた複数台を動作させるこ とができます。 N AT 越え UPnP を利用したルータの穴開け、 NAT 越えを行ないます。これによって、 NAT ルータが UPnP に対応していれば、 NAT の内側にある PC にもデータの中継 を行なわせることが可能です。 NAT 越 えができなかった場合でも、中継を行な わないだけで受信は可能です。 Web との親和性・多チャネル 同時受信 / 再生 Mbps 程度の比較的高品質な映像であり、 画面上部のウインドウは数 100kbps ~ 数 同時受信 / 再生が可能です。この例では、 貼っています。このような多チャネルの Web/< ージに 5 つの再生ウインドウを 図 9 に示している再生画面の例では、 ることが可能です。 サービスに、 Ocean Grid を組み合わせ べースとしたあらゆるシステムやネット ことが可能です。これにより、 Web を Media PIayer など ) を WebvX—ジに貼る 動画再生ソフトウェア (Windows その下の 4 つのウインドウは数 10kbps 程 度の低ビットレートの映像です。スト リーミングでは映像の再生開始時に、ど うしても数秒程度のバッファリング待ち 時間が必要です。チャネルをザッピング する際、切り替えのたびに数秒待たされ るのは、非常に大きなストレスとなりま す。図 9 の例で低ビットレート映像を複 数再生しているのは、ザッピングせずと もチャネルの選択ができるようにという 数百ノードの試験 配慮からです。 なっています。 しての狭帯域・高遅延環境での試験も行 試験、ネットワーク帯域幅や遅延を調整 でなく、ノードの頻繁な出入りを模した しています。多ノードの試験というだけ の PC を用いて数百ノードの動作を試験 ア、実験環境を用意してあり、十数台 大規模な試験をするためのソフトウェ まとめ ら、使われていくこととなるでしよう。 きには組み合わせられ補完し合いなが らはそれぞれの性質が活きる領域で、と 発信し得るという利点があります。これ 備・費用が安価、すなわち、誰もが広く リケーション層マルチキャストには、設 という利点があります。それに対しアプ 努力で信頼性を向上させることができる された基盤を用いる配信方式には、運用 IP マルチキャストや CDN などの整備 よび実際のシステム例を紹介しました。 ケーション層マルチキャストの手法、お 信の手段として注目されているアプリ 本稿では、マルチキャスト、ライプ配 UNIX magazine 2006 Autumn 43

はいえ、「根」にはすべての名前空間に かかる負荷が集中する。 DNS は大きな成功を収めているもの の、その適用領域はドメイン名という限 定的なものである。しかし、無数のタグ がさまざまな文脈において登場し、サー ビスの実行を要求する場合、 DNS は耐 えられるだろうか。「根」にすべての負 荷が集中する構造が、ユビキタス社会に おいても名前空間として活用できるとい う保証はない。そこで、 P2P というキー ワードを中心に、この世界にどのような 構造があり、我々の世界を支えるために どのような構造が必要かを考察する。 P2P = 対称な構造による 分散環境 P2P とは何か。 P2P という言葉には 最初から技術的な定義などなく、参加者 となるノードが平等な立場でシステムを 構成する、という程度の意味しかない。 実際に P2P に対して「インターネットは もともと P2P であり、何 1 つ新しいもの はない」と切って捨てる立場もある。 では P2P という言葉が、あたかも技 術的な領域における大きなパラダイムシ ( 「 00 ゆ C 0 ー net 図 2 —i.ascii ドメイン木 フトであるかのように語られるのはなぜ だろうか * 4 。また実際にさまざまな新し い技術やアーキテクチャが開発されてき たのはなぜだろうか。 この問に答えるには、「 P2P といわれ る技術」が、技術の中でどこに位置づけ られるかを考えるとよい。だがその前に 一歩引いて、アーキテクチャとは何かに ついてここで考える。 アーキテクトの先達 : 建築と都市 2004 年の SFC Open Research Forum * 5 で、坂茂教授 ( 専門 : 建築 ) と村井純 教授 ( 専門 : インターネット ) による異 業種対談が行なわれた。人づてに聞いた 話によると、坂教授から村井教授に対し て、コンピュータの世界で「アーキテク チャ」という言葉を軽々しく使ってほし くない、という趣旨の発言がなされたら しい。しかし今となっては、この言葉な くして計算機科学の議論を成立させるの は難しい。それほどアーキテクチャとは 基礎的な概念である。 基礎的な概念を共有しているのであれ ば、他にもある程度共通する概念がある だろう。恐らく我々は、建築や構造、都 物理的な構造には、 のレイヤに注目する。 と都市構造という 2 つ こでは、物理的な構造 る研究が存在する。 くつものレイヤに関す 設計などといった、い 設計・空間設計・都市 料・土木・構造・建築 の建築においては、材 学ぶことができる。そ 市設計などからもっと * 4 A. Oram, et. al., Pee 「•to-Pee 「 : Harnessing the Power Of DisruptiveTechnologies, O'Reilly, 2001 * 5 村井純、坂茂、アーキテクチャと 社会デザイン ( 対談 ) 、 SFC Open Research Forum 2004 http://www.kri.sfc.keio.ac.jp/OR F/2004/prog 「 am/ind ex. htm ー UNIX magazine 2006 Autumn 57

アプリケーション層 マルチキャスト : 基本と応用 アプリケーション層でマルチキャストを行なう各種手法を、豊富な例とともに 紹介する。後半の「 P2P 実用ソフトウェアへの道」では、実用化にあたって 配慮すべき点をまとめた。 IP マルチキャストは、その提案から multicast) 、エンドホストマルチキャス ウタゴ工株式会社 ト (end-host multicast) という呼び名も 10 数年を経た今でも、インターネット 取締役最高技術責任者 の津々浦々で使えるという状況には至っ あります。 ・博士 ( 情報科学 ) ていません。そこで、インターネット自 ALM とファイル共有 体ではなく、その上で動作するアプリ 首藤ー幸 ソフトウェアの違い ケーションにマルチキャストをさせよう SYUDO Kazuyuki という研究が、 2000 年頃から盛んに行 ALM では、受信側のコンピュータが なわれています。このようなマルチキャ 相互に直接データをやりとりします。っ 技術フェチ。工ンジニアとして スト手法は、アプリケーション層マルチ まり、典型的な P2P システムです。 「人には作れないものを作る」 をモットーに、 Java スレッド キャスト * 1 ( 以下、 ALM) と呼ばれます P2P システムでもっとも有名なのは、 移送システム MOBA 、 Just- GnuteIIa や eMule 、 Winny 、 BitTorrent in-Time コンバイラ shuJlT 、 ALM に参加するコンピュータ、すな などに代表されるファイル共有ソフト オーバレイ構築ツールキット OverIay Weaver などのソフ わちノード群が構成する構造・トボロジ ウェアでしようか。ファイル共有ソフト トウェアを開発してきた。 ウェアの主なコンテンツは、今のところ は、インターネットのそれとは異なり ます ( 図 2 ) 。このようなアプリケーショ 動画像や楽曲であり、 ALM も同様です。 ン層のネットワークは、 ALM に限らず、 しかし、 ALM とファイル共有ソフトウェ オーバーレイ * 2 と呼ばれます。 ALM は、 アとでは技術的な要件がかなり異なり、 オーバーレイ上で行なわれるマルチキャ 難しい点も異なります。 根本的な違いは、事前にコンテンツを ストという観点から、オーバーレイマ ルチキャスト (overlay multicast) とも バラまいておくことができるか否かです ( 図 3 ) 。ファイル共有ソフトウェアは一 呼ばれます。 ALM にはほかにもエンド システムマルチキャスト (end-system 般に、コンテンツまたはその断片を、複 例えばライプ映像 導→ 図 1 アプリケーション層マルチキャスト SPECIRL C ( 図 1 ) 。 オーバーレイ データ配信元 ( ストリーム ) インターネットの構造・トホロジ * 1 AppIication-LeveI MuIticast もしくは Application-Layer Multicast * 2 オーバーレイネットワークもし くはネットワークオーバーレイ 図 2 オーノ←レイ UNIX magazine 2006 Autumn

写真 1 大館樹海ドーム 黒川紀章氏による 図 3 菱野ニュータウンのスケッチ ( 黒川紀章氏提供 ) 写真 2 大館樹海ドームを外から望む テントのように柱ですべてを支えるも により、鉛直方向にかかる荷重をドーム の、一般的な家屋のように柱と梁で支え 周囲にある外殻に分散している。した るもの、ツーバイフォーエ法のように壁 がって 1 ヶ所に荷重がかかりすぎること で支えるもの、柱を組み合わせて巨大な なく、全体が比較的均質な存在として支 構造を作るものなど、さまざまな構造が えられている。外殻を含めた外部からの 存在する。例えば、東京都庁舎は多数の 写真を写真 2 に示す。 3 角形を組み合わせた構造の柱により、 次に都市における構造に目を向ける 軽くて巨大な 4 角形の枠組みを構成して と、宗教と政治と工学が複雑に絡み合っ おり、荷重を支えつつ広い内部空間を確 た構造をみることができる。例えばヨー 保しているという * 6 ロッパ的な教会と広場の都市設計や、パ また私が特に面白いと感じるのはドー リやウィーンのリング状の街区、アメリ ム構造である。ドームというと東京ドー 力的な高速道路を基礎とした街並みなど ムを思い浮かべる方もいるかもしれない である。また東京においても、その構造 が、あれは空気圧で屋根を支えており、 から江戸時代の政治的な土地割りまで遡 構造で屋根を支えているわけではない。 ることができる。こういった構造の多く それはしくみとしては面白いが、本稿は が、ある種の中心を持ち、そこを通過す 構造に着目し、大館樹海ドーム * 7 を取り る交通の制御に取り組んでいる。中心部 上げる。 は、いわば制御されていないクライアン 写真 1 に樹海ドームの天井の構造を示 トを多数抱えるサーバのような状態にな す。このドームは、木造としては世界最 り、電車も自動車も、ふとしたことで輻 大級である。本来巨大構造物に適さない 輳したり機能不全を起こしたりする。 集成材 ( 接着剤で張り合わせた木材 ) を またもう 1 つ本稿の文脈で挙げておく 用いて、巨大な空間を作ることができた べき都市設計の先行事例として、黒川 のは、 1 つにはその構造に工夫があるか 紀章氏らが提唱したいくつかの構造があ らである。具体的には、アーチ状の天井 る。その 1 つである図 3 は、愛知県菱野 'SPECIRL * 6 石井勉 ( 監修 ) 、図解よくわか る建築・土木ーしくみと基礎知識、 p. 98 、西東社 2006 * 7 伊東豊雄 ( 設計 ) 、大館樹海ドー ム、 1997 http://www.jukaidome ℃ om/ 58 UNIX magazine 2006 Autumn

XCAST6 XCAST のイベントとは 今回、 XCAST を利用して参加したイベントは、 2006 年 8 月 5 日に行なわれた「 XCAST MATSURI 2006 ~ 和田先生と語 る Happy Hacking Keyboard のタベ on XCAST6—」だ。この イベントを開催した XCAST fan club Japan/WIDE Project XCAST WG では、 XCAST のプロモーション、また実験フィー ルト。としてデータ蓄積、直を積むことを目的として、 XCAST 上でのミーティングや講演などを行なっている。さらに昨年か らは、 XCAST MATSURI ( 祭 ) として大規模なミーティング を開催している。今回のイベントも、 10 月 21 日に開催予定の XCAST MATSURI 2006 のプレイベントとして企画されたも のだ。 ( イベントウエプサイト http://www.xcast.jp/hhk/) イベ ントについては後ほど改めて報告するが、まずは参加するために 行なった環境構築、設定方法を説明しよう。 ど・れ・に・し・よ・う・か・な 現在、 XCAST6 を使うには以下の方法がある。 ・ FreeBSD 上に XCAST6 環境を構築する ・ NetBSD 上に XCAST6 環境を構築する ・ Linux 上に XCAST6 環境を構築する ・ CD-ROM プートの XCAST6 工羅竟を使う ・ VMware イメージの XCAST6 工竟を使う ・ Windows XP 上に XCAST6 環境を構築する この中でもっとも手つ取り早いのは CD-ROM プートか VMware イメージを使って XCAST6 の環境を作ることだ。なに せ、イメージを落としてきて CD ー ROM に焼いたら環境が出来上 がってしまう。これらのキットは XCAST6 の環境のみならす必 要な設定もある程度されているので、初心堵や手軽に試したい方 にはお勧めである。 なお、今回は FreeBSD 上に構築することにした。その理由は、 工竟を本するネットワークが NAT の下にあり、 IPv6 unreachable であるためだ。 XCAST6 を試すには当然 IPv6 アドレスが必要と なる。そこで IPv6 アドレスを使える状態にするための解決策とし 画面 1 バッチのあて方 # cd /usr/s 「 c て DTCP (Dynamic Tunnel Configuration ProtocoI) というト ンネリングプロトコルを使った。 DTCP は NetBSD と FreeBSD の両方で使えるが、 FreeBSD では UDP トンネルも利用できる。 UDP トンネルも試すために、今回は FreeBSD を使用 OS として 選択したのだ。 FreeBSD のほか、 NetBSD もしくは Linux のい ずれかを OS として選択した場合にも環境を構築する手間は同じ だろうと考えられる。 今回使用した XCAST6 キットはバージョン 0.2.1 である。この ノヾージョンは FreeBSD 6.1 のカーネルに対応している。そこで 本稿ではすでに IPv6 が利用可能な FreeBSD 6.1 がインストー ルされているとして話を進めていく。 XCAST6 用カーネルの構築 素の FreeBSD のカーネルでは XCAST に対応していないた め、まず最初にカーネルの再構築を行なう。現在、 FreeBSD 6.1 で吏える XCAST6 用のカーネルバッチは以下の 2 つがある。 ・ xcast6-O.2.1-1-freebsd-sys-6.1. diff. gz (http://www.sourceforge.net/projects/xcast6/) ・ cast6-O.2.1-1-freebsd-sys-6.1ーStableー20060630. diff. gz (http://www.imasy.org/-ume/FreeBSD/) 1 つ目のパッチは SourceForge. net にホスティングされている XCAST6 Project が作成したパッチ。 2 つ目は 6. l-stable 用に 梅本肇氏が作成したパッチだ。 2 つ目のパッチを 8 月 4 日の stable にあてたが、間題なく適用された。パッチは 1 に示すように あてる。その後、カーネルの設定ファイルに次の行を付け加えて カーネルの再構築を行なう。 options XCAST6 device XCSt 上記のパッチの中には GENERIC のにヨ容と XCAST6 用の言定 が書かれた GENERIC_XCAST6 という設定ファイルが含まれ ているので、カーネルの再構築時にこちらを指定してもよいだろ う。今回は FreeBSD 6.1 Release から FreeBSD 6.1 stable へのアップグレードも含めたため、以下のようにカーネルとユー # zcat /path/t0/xcast6-O.2.1-1-freebsd-sys-6.1- stab -20060630. di 幵 . gz ー patch -pl UNIX magazine 2006 Autumn 95