信木に参加することになります。各ノー ら 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

ど、多額の費用がかかりました。そこ に 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

いわれています。ポットを多数の家庭用 割合は増加傾向にあります。 PC などに潜ませてポットネットを構築 spam について言及するとき、注意を し、それらのポットを遠隔操作して 払わなければならないのが、 spam とし spam を送信するという手法です。ポッ て分類されるメールの定義です。一般に は、「受信者の承諾なく、不特定多数の トを利用した spam 送信の出現は、 spam の絶対量を急激に増加させました。プ 受信者に対して無差別に送信されるメー ロードバンド回線でインターネットに常 ル」と考えられています。別の見方をす 時接続された多数の高性能 PC を利用す ると、受信者の承諾があり、特定の受信 ることで、大量の spam を短時間に送信 者宛てに送信されるメールは spam では することができるようになったのです。 ない、ということになります。 spam 対策製品の正確性をテストする 一方、 spam として送信されるメールの コンテンツについても、巧妙化が進んで ために、出会い系サイトに e-mail アドレ スを登録し、送信されてくるメールをテ います。その中でも特に増加傾向が著し ストの対象とする。こういったテストプ いのが、イメージ spam と呼ばれるもの です。名前から想像できるように、画像 ランを何度となく見かけたことがありま ( イメージ ) を貼り付けた spam です。コン す。これは、 spam として配信されるメー テンツに含める文章や URL を画像として ルと、出会い系サイトが利用者に送信 送信することで、 spam 検知工ンジンをか するメールが類似しているという理由か いくぐることを目的としています。 spam ら、検体として使用するのです。しかし 全体に占めるイメージ spam の割合は、過 これは、明らかに間違っています。出会 去 1 年間で 10 倍以上に増えたと米国では い系サイトが登録者、つまりサイトから いわれています のメールの受信を承諾した利用者に対し また、特定の組織だけを狙うスピア型 て送信するメールは、 spam にはあたり フィッシングの被害も報告されています ません。実は、技術的検知からみた場合、 従来のフィッシングメールは、 spam と これが spam 対策の難易度を高めていま して不特定多数の受信者に配信されるの す。仮にコンテンツが完全に同じであっ が一般的でした。スピア型フィッシング ても、そのメールが spam の場合もあれ は、送信先を特定の組織 ( 企業、ドメイ ば、そうでない場合もあります ンなど ) に限定し、組織のメンバーのみ なお、企業などの e ー mail システムにお いて、出会い系サイトからのメールを排 が知りうるコンテンツを偽装します。組 織内のメールを装うことで受信者の警戒 除したいというニーズがあるのは事実で 心を解き、フィッシングサイトへ誘導す す。しかし、それは spam 対策とは異な るのが狙いです。スピア型フィッシング るカテゴリとなるのです は、通常のフィッシングメールに比べて 送信量が極めて少なく、べンダー側での 対応が取りにくいのも特徴です 最新ロ spam 事情 最近の spam 事情 数年前まで、 spam を送信する方法は、 利用者確認が甘い無料 ISP などを利用し た直接送信や、オープンリレーのメール spam 対策を実施する場合、もっとも重 サーバやオープンプロキシを踏み台とし 要とされるのが検知の精確さです。検知 た送信がほとんどでした。現在、こうし の精度は、 spam を ham ( spam ではない正 た従来方式での spam 送信は激減し、 spam 規のメール ) と判定してしまう検知漏れ の過半数はポットから送信されていると 検知漏れと誤検知 1 18 UNIX magazine 2006 Autumn

宛先を 担当するノード ルーティング 結果の経路 ! 配信元 配信木 同一 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

JANOG REPORT す。これによりマルチキャストの運用負 荷は減り、さらには「責任分界点」にお ける複雑性を改善できる可能性がありま す。事業者間接続の責任分界点において は、 MBGP 、 MSDP などの手法はある ものの、商用サービスでの採用には課題 が多く、ランテブーポイントの運用とい う難点を解決できていません。また、運 用のためのツール類の充実化、および品 質の確保も大きな課題となってきます。 この点について、現時点で答はなく、運 用事業者は各自さまざまな独自工夫でし のいでいるのが実情です。 JANOG18 で行なった議論の中でも、アプリケー ション面でカノヾーするケースが多いので はないかというコメントもありました。 このプログラムはほかのものとは異な り、情報共有的なニュアンスを強めに作 図 2 PIM-SM ネットワークの動作概略 りこんだものでした。しかし、マルチキャ クリアしたという前提で、運用面につい ストの現状と必要性、そしてネットワー て考えます。冒頭で P Ⅳ - SM がもっとも クオペレーターとして意識する必要のあ 普及していると述べましたが、 PIM-SM る技術であることは十分に伝えられた を使う場合には、ユニキャストで想定で と感じています。今後 JAN 〇 G という場 きなかった運用上の難点が出てきます。 が最適であるかどうかは吟味が必要です 1 つは、ランデブーポイントです。 PIM- が、情報の共有やドキュメントの充実化、 SM のネットワークでは、すべての Join コア技術の最適化に向けて、さまざまな 要求、 Register 要求は一旦ランテブー 団体や開発者と意見交換を行なう必要が ポイントへ集まり、その後、最適化さ あると感じています。ある日突然「マル れた最短経路木へと切り替わります ( 図 チキャストの配信ネットワークを設計し 2 ) 。このランデブーポイントの運用が、 てください」と言われたときに困った筆 マルチキャストを複雑化しています。詳 者の経験を、無駄にしたくないという気 細は JANOG の Web サイト * 9 を参照して 持ちを込めて。 ( 以上、川村聖ー ) ください。もしこの複雑性を取り払お ほっといた引 Pv4 運用に うとすれば、まったく新しいプロトコル 影響する旧 v6 の話 の採用が必要となります。その注目株 が曰 M ー SSM * というプロトコルです。 PIM-SSM は、マルチキャストの送信元 lPv4 のネットワークやサーバなどを アドレスを特定して Join することによ 運用されている方は、 lPv6 を利用した り、ランテプーポイントを省略していま サービスの登場や lPv6 対応 OS の登場に 時間の流れ 端末からの受信要求 サーバが配信を開始 最適化経路への切り替え テータセンタ データセンタ テータセンタ 6 WAN WAN WAN 0 3 PIM domain ※ FHR : Fi 「 st Hop Router ※ RP : Rendezvou Point ※ PE : P 「 ovide 「 Edge ※ SPT: Shortest PathTree ① FHR 宛てにバケットを送出 ② RP へ送信元アドレスと グルーフアドレスを登録する ③端末からの受信要求 (IGMP 0 「 MLD) ④ RP への受信要求 : ( ・ (G) join メッセージ この時点で送信元アドレスがわからないため ひとます RP へ要求 ⑤ SPT への受信要求 : (S,G) join メッセ ーシ ⑥ SPT 上でのデータ転送 * 9 * 10 http://www.janog.g 「 jp/meeting/janog 18/program-abstract. html Protocollndependent Multicast-Source Specific Mode 128 UNIX magazine 2006 Autumn

コミュニケーション、静的なデジタルコ こで問題となるのが、あまり行き渡って いないデータ片の入手性です。一片でも ンテンツのオンデマンド配信機能を選択 入手できないと、元のファイルを復元で 的に追加して利用できます。 このライプ配信には、映画や楽曲と きません。そこで Avalanche では、デー タ片そのものの代わりにデータ片の線形 いった静的コンテンツとは異なるメディ 結合を流通させ、充分な数の任意のデー アとしての特性があります。 その 1 つは、多人数で同一の視聴体験 タ片を集めることで復元を可能として います。 Avalanche では、データ片の符 を共有できるという同時性です。ビデオ 号化を配布元のサーバで行なう場合と、 ゲームの多人数プレイや遊園地のアトラ ノード上で行なう場合の双方が検討され クションのように、自分以外の誰かと 同一の体験を共有することに、人は喜び ています。後者を指して network coding と呼んでいます。 を見出します。さらに、そこにコミュニ ケーションが加わることで、喜びは一層 ALM の例 : Ocean Grid 増します。この現象の一端を、大規模掲 ライプ配信システム 示板 2 ちゃんねるのテレビ番組実況板の 盛況ぶりにみることができます。 Ocean ALM システムの例として Ocean Grid Grid は配信にかかる設備・費用が安く、 を紹介します。 Ocean Grid はウタゴ工 株式会社で開発しているコンテンツ配 これまで広く共有することが難しかった プライベートな体験を、距離を越えて共 信技術・ソフトウェア・サービスの名称 有できます。 です。これは ALM として実装されてい るライプ配信機能 ( 図 9 ) を核とした技 もう 1 点、ライプ配信には視聴態度が 術パッケージです。利用者間の ( ビデオ ) 受動的であるという特徴があります。イ ンターネット上のサービスの多くは、 WebA2 ージのプラウズにせよコンテン ツの検索にせよ、利用者が能動的にかか わることでサービスを享受できるという しくみです。逆にいえば、積極的にかか わらない限り、サービスを享受できませ ん。ライプ配信はその点が異なり、それ 自体には、利用者が能動的にかかわるし かけがありません。もちろん、利用者の 性向に応じたある程度のパーソナライズ や、文脈を考慮したコンテンツ提示が活 きる余地は多いにあります。しかし基本 的には、積極的に働きかけずともその恩 恵を享受し得るメディアです。 これまで大規模なライプ配信には、 サーノヾ側設備・ネットワークの使用料な SPECIRL 0 ! 物 1 巳 ) グチ「ンネル コミュニケ - ツ当ン 第 - チャンネル ー・第一チャンネル ー・第ープロ、アマ問わず、見ごたえたっをは ) ライラ第れ 5 合を ノンストッづでお・れします ! ! 双 0 : デ行トリビューシンジをこ 広告工リア をま複チャンスル 視難可チャンネル情報 をトーをまチャンネル サッ - チやンネル 験画チャンネル 響はャンル 第・人戔みチャンネル ドうマ 図 9 Ocean Grid ライプ配信システムの画面例 42 UNIX magazine 2006 Autumn

流 = 危険」というイメージが一般化して いるため、利用の前提となるオペレー ションの安全性についても議論が行なわ れました。 電気は安全のため、実際は交流 / 直流 に関係なく、ともに適正に扱わなくては なりません。しかし直流では、コンセン トの規格化などの直流用ツールが普及し ないと、安全に扱うことは難しいとの指 摘がありました。これが交流と比較した 場合の直流の課題です。 最終的には「直流に関する情報を業界 各社で共有するとともに、実現のために は安全なツールの規格化を進める必要が ある」ということで、課題がみえてきま アメリカを始め日本でも直流の利点に 着目し、検証実験や普及に向けた検討 が、学会を中心に進められています。本 プログラムでは学会での議論をベース として、現場の運用者同士の意見交換を 行なうことができました。それに対し、 有意義であったと評価をいただき、プ ロデューサ PC として大変光栄なことと 思っています。 ( 以上、吉本慶 ) 現在のインターネットにおける IP マ ルチキャスト ( 以下、マルチキャスト ) の活用シーンを考えてみると、あまり 表立ったサービスがないのが現状です。 もっとも有名な事例として N 幵東日本 のフレツツ・ドットネット、 BB ケープ ル株式会社の BBTV のサービスなどがあ ります。ただし、これらは厳密にはイン ターネットを使ったサービスではなく、 独自網での運用形態をとっていますに マルチキャスト 運用の実話を語ろう ! * 4 ProtocoIIndependent MuIticast-Spa 「 se MOde * 5 初版は RFC21 1 7 。その後 RFC2362 が普及する。 こはユーザーからはあまり見えません ) 。 しかし近年、映像配信分野においてマル チキャストへの期待が高まっています。 もし設計者がマルチキャストという技術 を選択した場合、どのような技術要件 を検討し、また Tips やツール類の情報 はどの文献を参考にすればよいのでしょ うか ? 今のところ、頑張って RFC を読 み、体当たりで覚えるしかないというの が実情です。今回、 JANOG18 のプロ グラムでは、まずマルチキャストを身近 に感じてもらうためにサービスの紹介を させていただきました。そしてオペレー ターや設計者が困るポイントについての Tips を紹介し、情報共有の議論を行な いました。 マルチキャストがもっとも注目を浴び ている分野は、前述のような放送形態の 映像配信サービスですが、従来はもっと 別の分野で利用されていました。マルチ キャストを語るにあたってはずせないプ ロトコルは曰 M - SM * 4 です。これは現在 もっとも普及しているマルチキャストの ルーティングプロトコルで、今回のプロ グラムの中心点としました。 このプロトコルが標準化 * 5 されたのは 1997 年ですが、それ以前にも別の方式 による株価肩報のブッシュ配信、業務用 オークション、監視カメラなどが存在し ました。また欧米では ISP サービスも盛 んに提供されていた時代がありました。 現在マルチキャストが映像配信用途で注 目されている要因には、足回りの広帯域 化と受信者数増加によるスケールの問 題、クライアントの性能向上があります。 しかし映像配信サービスは、既存のネ ットワークの上にマルチキャスト対応の サーバを設置し、ルータのライセンスを 購入するだけでは提供できません。その 原因で代表的な例は RPF * 6 チェックで す。今でこそ uRPF * 7 がネットワークオ ペレーターの間で話題になり、その考え 方が普及していますが、実際のところ送 信元 IP アドレスのフィールドを参照して ルーティングテープルを構築する考え方 は、なかなか馴染めない手法です。よく あるトラブル例に、ユニキャストは通っ ているのにマルチキャストだけ破棄され ている症状があり、このような場合は RPF チェックに引っかかっているケー スが多いです。また、さらにトラブルシ ュートを困難にするのが、イーサネット レベルの問題や、 NAT がある場合です。 まずマルチキャストとプロードキャスト の関連性は、意外に知られていません。 ルータにおいては扱いが異なるが、レイ ヤ 2 以下の世界ではマルチキャストとプ ロードキャストは同等扱いの MAC アド レスにマッピングされるのです。これを 無視すると、問題が発生する場合があり ます。詳細はシスコシステムズ株式会社 の web サイトをご覧ください * 8 。また NAT はさらに問題を複雑化させる要因 の 1 つです。ユニキャストべースルーテ イングでは、経路の途中に NAT が入っ ている場合でも、その NAT が適切に設 計されていれば、端末は意識しなくても 到達性は確保できます。しかしマルチキ ャストネットワークでは、 NAT を回避 する手段を End ー to ー End の観点で設計し なければ、到達性がまったくなくなりま す。またネットワークの冗長性という意 味でも、ユニキャストネットワークの切 り替え時間を 30 秒と設計しても、マル チキャストは 30 秒で切り替わりません。 それ以上の時間がかかることも重要なポ イントです。 ではここまでに述べてきた設計要件を [RFC2117 ] , [ RFC2362 ] , Protocollndependent MuIticast-Sparse Mode (PIM-SM) : P 「 0t0C6 Specification * 6 * 7 Reverse Path Forwarding unicast Reverse Path FO 「 warding * 8 http://www.cisco.com/jp/p 「 oduct/hs/ios/multicast/tech/ mcst_ovr. shtml UNIX magazine 2006 Autumn 127

報告 RSS を登録することで、最新のコンテ 2005 年度には 6 回 ( うち 1 回は前年 ンツが自動でダウンロードできるため、 度 4 月と 6 月の合イ鰤幵究会 ) の研究会を行 利用者はブッシュ型のコンテンツのよう ないました。 2005 年度の開催概要は以 に扱うことができます。 下の通りでした。 次に実際にポッドキャストを視聴する 方法について、画面操作を交えた説明を していただきました。ポッドキャストを 視聴するには、配信しているサイトを直 2005 年 5 月 29 日 ( 日 ) 接訪問する以外に iTunes Music Store 場所 の検索機能を使うことでも、視聴可能な クレオ大阪東 配信を探すことができます。見つけた配 演題と発表者 信はすぐに iTunes に登録でき、そのまま 事務所無人化計画 -- jus の事例 -- ・齊藤明 ネ則恵できます。また、 iPod 以外のプレイ 紀 ( 鳥取環境大学 ) ャーでも、配信されているコンテンツの レンタルサーバの借り方、使い方 . 竹内 形式に対応していれば、コンテンツを手 友張 (taketomo.org/ 動で転送して視聴することができます。 大学の計算機システムと学生自己負担に ポッドキャストを配信する方法につい ついて : 西野美香 ( 神戸女学院大学 ) ても説明していただきました。ポッド キャストに対応したプログサービスなど を利用することで、簡単に配信すること ができます。また、プログッールの中に 2005 年 8 月 20 日 ( 土 ) は MovabIe Type のように、プラグイ 場所 ン機能でポッドキャストの配信に対応で 大阪府立青少年会館本館第 5 会議室 演を一発表者 きるものもあります。 最後に、コンテンツを作成する方法に 大学てのコンピュータリテラシー教育と ついて説明していただきました。実際に その諸問題 . 齊藤明紀 ( 鳥取環境大学 ) 音声の録音と編集をその場で実演してい 高度技術者養成を目指す専門職大学 ただき、講演は締めくくられました。 院、神戸情報大学院大学について : 小島 今回はポッドキャストを実際に利用す 三弘 ( 神戸情報大学院大学助教授 ( 実務 るということに重点を置いた勉強会で、 家専任 ) ) 講演のあとにはポッドキャストを使って ネットワーク技術者初級養成ギブス : 高 みたくなるような内容となりました。 木宏 ( ィーサホート ) 日程 jus では毎偶数月に「 jus 関西 UNIX 研 2005 年 10 月 28 日 ( 金 ) 究会」を行なっています。 1984 年開始 場所 以来、 20 年以上も続いているロングラ 大阪産業創造館 17F 交流プラサ ンの研究会です。 ( 関西オープンソース 2005 の一環として 1 21 回 122 回 jus 関西 UNIX 研究会 報告 : 齊藤明紀 123 回 134 UNIX magazine 2006 Autumn

の符号化は、 ALM と深い関連がありま す。例えば、元のデータストリームを符 号化してから ALM に流すことで、バケッ トロスなどでデータ片が揃わない場合で も、ある程度の品質で再生することが可 能となります。 erasure coding とは、 n 個のデータ片 を符号化し、そのうちの k 個を揃えるだ けで元のデータを復号できるというよう な符号化を指します。例えば 64 個のデー タ片に符号化し、そのうちの 16 個を揃 えることで元のデータを復元できます。 これは特に映像・音声に特化しているわ けではありません。 layered coding は、元の映像・音声ス トリームを、複数本のデータストリーム に符号化します。受信側は、 base layer のストリームだけ受信できれば最低限 の品質で再生が可能であり、そのほかの ストリームも受信すればさらに高い品 質での再生が可能となります。例えば 256kbps のデータストリーム 4 本に符号 化するとしましよう。この場合、 1 本分 (256kbps) を受信するだけで最低限の 再生が可能であり、すべて (IMbps) を 受信することで最高品質での再生が可 能となります。つまり layered coding に より、広帯域幅かつ高品質のデータスト リームに、狭帯域幅かっ低品質のデータ を兼ねさせることが可能となるのです。 ツリーベースの ALM で、広帯域幅でつ ながったノードの先に狭帯域幅のノード がつながっている場合を想定してみま しよう。この場合は通常、狭帯域幅のノー ドに合わせて両ノードに低品質のデータ を送るか、それぞれのノードに異なる品 質のデータを送るかのどちらかとなりま す。しかしここで layered coding を用い ることで、両ノードに個別のデータを送 ることなく、帯域幅に応じたデータを受 信して再生することができます。広帯域 幅のノードは高品質で、狭帯域幅のノー ドはそれなりの品質で再生することが可 能となるのです。 multiple description coding (MDC) も、映像・音声のための符号化手法です。 元のデータストリームを複数本に符号化 します。再生に base layer が必要となる layered coding とは異なり、任意のデー タストリームを最低 1 本受信すれば再生 できるという、再生可能性の高さが特徴 です。データストリームの本数が増える ほど、歪みの少ない高品質な再生が可能 となります。 MDC を応用した ALM に、 CoopNet があります。 network coding は、ビット列を伝送す る通信ネットワークを前提として、その 中継ノードにおいて中継だけでなく符号 化を許します。そうして、中継だけが可 能な場合よりも高い伝送レートを達成し ます。中継ノードで行なわれる符号化 とは、多くの場合、異なる枝からやって きたデータ同士の線形結合 ( もっとも簡 単には x xor y) です。 network coding は 2000 年にその可能性が示されました。 それ以降、 ALM に限定してもすでに多 数の応用提案がされています。もっとも 話題を呼んだのは、 ALM ではありませ んが、 2005 年 6 月に Microsoft Research から発表された P2P コンテンツ配信方 式 Avalanche ではないでしようか。これ は BitTorrent の代替技術といった触れ 込みで報道されました。 BitTorrent で は、ファイルをデータ片に分割し、各 ノード ( 利用者の PC ) は全データ片を集 めることで元のデータを復元します。 UNIX magazine 2006 Autumn

に対し強制的にデータを送りつけます。 構造を前提としながらもメッシュべース つまりプッシュ型の方式です。データを の手法をとっています。最初は配信木に 受信したノードは、そのデータの受信が 従ってデータを流しますが、各ノードは 初めてであれば、データが来た方向を除 すべての子に全データを流すわけではあ いて、自分の隣接ノードに対してデータ りません。各ノードは木構造に関係なく、 を転送します。受信済であれば転送しま 足りないデータをほかのノードから入手 せん。 します。この点がメッシュべースである 単純な flooding には、データ転送の総 所以です。どのノードがどのデータを保 量、それも無駄なデータ転送が多いとい 持しているかという情報は、木構造を活 う問題があります。例えば図 6 中のある 用して流通させます。この手法によりッ ノードは、同一のデータを 4 回以上受信 リーベースよりも高帯域幅のデータを流 しています。各ノードの上り帯域幅が貴 すことができる、というのが提案者の主 重な ALM において、これは大きな問題 張です。 です。そこで、 ALM に flooding を適用す データ駆動のデータ転送 る場合には、無駄なデータ転送を低減す る工夫がとり入れられています。 これまで紹介してきたツリーベース、 flooding の良い点、つまり高いデータ浸 メッシュべースの方法は、基本的にブッ 透率を維持しつつ、なおかっデータ転送 シュ (push) 型のプロトコルでした。木 の総量を抑える手法として、 1980 年代に 構造では、データは単一の親からしか gossip と呼ばれる手法が考え出されまし やってこないため、プル (pull) 型のプロ た。 gossip は rumor mongering 、 epidemic トコル、つまり親に対するデータの要求 dissemination とも呼ばれます。文字どお は無駄なものでしかありません。しかし り、噂が人づてに伝わっていくような動 メッシュべースでは状況が異なります。 作をします。 gossip プロトコルには、多く ブッシュ型プロトコルである flooding や のノヾリエーションがあります。基本的には gossip では、同一のデータが複数の隣接 転送処理として、隣接ノードの中から転 ノードからやってきます。この無駄を省 送先をランダムに選び転送する、という くためには、プル型のプロトコルが有効 動作を繰り返します。そして、例えば受 です。つまり、強制的にデータを送りつ 信済ノードへの転送を一定回数繰り返し けること (push) はやめ、明示的な要求 てしまった時点で、転送を止めます。 (pull) があって初めて転送するのです。 この種のプロトコルの ALM への応用 かといって、隣接ノードに対してや としては、構造化オーバーレイ CAN の みくもにデータを要求しても、その隣 上で % oding を行なうものがあります。 接ノードが当該データを持っていなけれ flooding は ALM 自体よりも、イベント ば、要求自体が無駄なものとしかなりま 通知 ( 例 :lpbcast) やオーノヾーレイのメ せん。そこで、自らが保持しているデー ンノヾ管理 ( 例 : CoolStreaming/DONet) タの一覧を、隣接ノードに知らせておく という方法がとられます。具体的には、 によく用いられています。 Bullet という ALM は、ノード間の木 データストリームを時間方向に分割した SPECIRL C 38 UNIX magazine 2006 Autumn