JP2004517412A - コンテンツ配信網のストリーミング・メディア配信機構 - Google Patents

Abstract

ＣＤＮ入口点に公開されたライブ・ストリームを要求エンドユーザーに配信することを可能とするためコンテンツ配信網内でリフレクタ網が使用される。リフレクタは一般化されたパケット・ルータ・プログラムである。リフレクタ網は、ＣＤＮへの各種入口点と、ライブ・ストリームを得るためにＣＤＮにより要求ユーザーに向けられた各エッジ・ノードと、入口点とエッジ・ノードとの間の少なくとも１つの中間層（階層中で）内に配置された各種の「リフレクタ」ノードと、に配置されたリフレクタの階層を含むことが望ましい。エッジ・ノードと各リフレクタ・ノードも供給用に手配するマネージャ・プログラムを含む。所要のストリームを未だ受信していないエッジ・ノードへエンドユーザーが向けられた時、エッジ・ノードのマネージャはリフレクタ・ノードの組に配信要求を発行する。リフレクタ・ノードが所要ストリームを既に受信している場合、そのリフレクタはこれを要求エッジ・ノードへ送信し始める。しかしながら、リフレクタ・ノードが未だ所要ストリームを受信していない場合、そのマネージャ・プログラムは入口点へ配信要求を発行して供給を開始する。

Description

【０００１】
（関連出願）
本願は、本願の譲渡人に譲渡された、２０００年１月６日提出の、インターネットを介したフォールト・トレラント（故障認容）なメディア・ストリーミングの方法とシステムという名称の共願の出願一連番号第０９／４７８、５７１号と関係している。
【０００２】
（技術分野）
本発明は、一般に、コンテンツ・配信網（ＣＤＮ，Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）での高速な、フォールト・トレラントなストリーミング・メディア配信に関する。
【０００３】
（関連技術の説明）
ストリーミング・メディアは、まだダウンロードしている過程で再生が可能であるという重要な特性を有しているインターネット・コンテンツの１型式である。クライアントは、第３パケットを受信しつつ、ストリームの第１パケットを再生し、第２パケットを解凍することが可能である。従って、エンドユーザーは送信の終了を待つことなくマルチメディアを楽しむことが可能である。メディア・ファイルは、プログラムの継続時間が増加すると特に大きくなる傾向があるため、ストリーミングはメディア配信に非常に有用である。実際、ライブ・イベントでは、ファイル・サイズは事実上無限である。ストリームされていないメディア・ファイルを見るためには、ユーザーは最初にこのファイルをローカルのハードディスクにダウンロードしなければならず、これには数分かかるかもしれず数時間かかるかもしれない。次いでファイル形式に適合するプレーヤ・ソフトウェアによりファイルをオープンしなければならない。ストリーミング・メディアを見るためには、ユーザーのブラウザがプレーヤ・ソフトウェアをオープンし、このソフトウェアがファイルを数秒間バッファし、これをダウンロードしつつファイルをプレイする。ソフトウェア・ダウンロードと異なり、ストリーミング・メディア・ファイルはユーザーのハードディスクのローカルには記憶されない。コンテンツを表現するビットがひとたび使用されると、プレーヤは通常これを廃棄する。
【０００４】
ストリーミング・メディア品質は、配信されるメディアの型式、ユーザーのインターネット接続の速度、ネットワーク条件、コンテンツをコード化するビットレート、使用するフォーマットに従って広範囲に変動する。一般に、ストリーミング・オーディオはＦＭ品質であるが、通常の帯域制限を与えると、ストリーミング・ビデオはＴＶ標準より劣っており、画面は小さく、解像度は低く、秒当たりのフレーム数は少ない。ストリーミング・メディアのソースは、ＶＨＳまたはベータ形式のテープ、音声カセット、ＤＡＴ、ＭＰＥＧビデオ、ＭＰ３音声、ＡＶＩ等を含む、任意の形式のメディアが可能である。ストリーミングの前に、コンテンツは最初にコード化されなければならないが、この過程は：必要に応じて、アナログからディジタル形式へのコンテンツの変換、ストリーミング・メディア・サーバーとプレーヤにより認識される形式のファイルの作成、実時間で与えら得た限定帯域で配信可能なコンテンツの豊富度を最大化するためのファイルの圧縮、メディアを配信するビットレートの確立の４段階を実行する。高速接続のユーザーが可能な限り良好な体験を得られるように、かつ低速接続のユーザーもコンテンツをアクセス可能なように、コンテンツ所有者は通常複数レートでメディアをコード化する。
【０００５】
非ストリーミング・コンテンツは、アパッチ・サーバー、マイクロソフト・インターネット・エクスプローラ、ネットスケープ・コミュニケータ等のような、異なるベンダにより開発されたサーバーとクライアント・ソフトウェアが一般的に互いにうまく動作すると言う意味で、規格に基づいている。しかしながら、ストリーミング・メディアは、独自のサーバーとクライアント・ソフトウェアに通常依存している。ストリーミング・ソフトウェア・ベンダにより開発されたサーバー、クライアント、製品、コード化ツールは一括してフォーマットと呼ばれる。特定のフォーマットによりコード化されたストリーミング・メディアはその形式のメディア・サーバーによりサービスされ、その形式のクライアントにより再生されなければならない。ストリーミング・メディア・クライアントはしばしばプレーヤと呼ばれ、通常のウェブブラウザへのプラグインとして存在する。ストリーミング・メディア・クライアントは、ＷＡＶまたはＡＶＩのような、規格に基づいた非ストリーミング・メディアをしばしば再生可能である。
【０００６】
現在使用されている３つの主要なストリーミング・メディア・フォーマットは：リアルネットワークのリアルシステムＧ２（ＲｅａｌＮｅｔｗｏｒｋｓ ＲｅａｌＳｙｓｔｅｍ Ｇ２（登録商標））、マイクロソフトのウィンドウズ・メディア（登録商標）・テクノロジ（「ＷＭＴ」）、及びアップルのクイックタイムである。リアルシステムＧ２は、音声、ビデオ、アニメーション、さらに静止画とテキストを含む全てのメディアを処理する。リアルシステムＧ２とクイックタイム（登録商標）は、コンテンツ・プロバイダがプレーヤのウィンドウ内でメディアを調時し位置決めすることを可能とするＸＭＬベースの言語のＳＭＩＬをサポートする。メディアを実時間で配信するため、リアルとクイックタイムはＲＴＳＰを使用する。ＷＭＴのアドバンスト・ストリーミング・フォーマットをストリームするためには、コンテンツ・プロバイダは通常マイクロソフトＮＴ４サーバーをインストールしなければならない。ＷＭＴはＳＭＩＬまたはＲＴＳＰをサポートしないが、ＨＴＭＬ＋Ｔｉｍｅと呼ぶ独自のプロトコルを有する。アップルのクイックタイムは最近ストリーミング・メディアをサービスする機能を追加した。クイックタイムはＶＲ、３Ｄ、Ｆｌａｓｈ、ＭＰ３を含む多数のフォーマットをサポート可能である。
【０００７】
コンテンツ配信網（ＣＤＮ）を使用してストリーミング・メディアを配信することは公知である。ＣＤＮは、第３者のコンテンツ・プロバイダに代わってディジタル・コンテンツ（例えば、ウェブ・コンテンツ、ストリーミング・メディア及びアプリケーション）の効率的な配信用に配置された地理的に分散されたコンテンツ配信ノードの自己編成網である。ある特定のコンテンツへの要求エンドユーザーからの要求は、「最良の」複製に向けられ、ここで「最良」とは、コンテンツ・プロバイダの元のサーバーから持ってくるのにかかる時間と比較して、クライアントに迅速にアイテムをサービス出来ることを通常意味する。
【０００８】
通常、ＣＤＮは、コンテンツ配信基礎構造（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）、要求ルーティング機構、及び配信基礎構造の組み合わせとして実装される。コンテンツ配信基礎構造は、要求エンドユーザーにコンテンツの複製を配信するため戦略的な位置（例えば、インターネット網アクセスポイント、インターネット・ポップ等）に配置した一組の「代理の（ｓｕｍｇａｔｅ）」配信元サーバーを通常含む。要求ルーティング機構は、ウェブ・コンテンツ配信に対しては特定のクライアントの応答時間を最小とするように、ストリーミング・メディア配信に対しては最高品質を提供するように、要求クライアントにコンテンツ配信基礎構造中のサーバーを割当てる。配信基礎構造は、配信元サーバーから代理の配信元サーバーへコンテンツを移動するオンデマンドまたはプッシュ式機構から構成される。効率的なＣＤＮは、特定の要求クライアントに最適な代理から頻繁にアクセスされるコンテンツをサービスする。通常のＣＤＮでは、単一のサービスプロバイダが要求ルータ、代理、及びコンテンツ・ディストリビュータを操作する。さらに、このサービスプロバイダはコンテンツ出版者とビジネス関係を設立し、その配信元サーバーサイトの代わりに動作して分散配信システムを提供する。ウェブ・コンテンツとメディア・ストリーミングを提供する公知の商用ＣＤＮサービスは、マサチューセッツ州ケンブリッジのアカマイ・テクノロジ社により提供される。
【０００９】
ＣＤＮは、コンテンツ・プロバイダのコンテンツを配信用にタグ付けするためコンテンツ変更を使用する。コンテンツ変更は、要求クライアントと配信元サーバーとの間に特別のスイッチング装置またはディレクトリ・サービスを必要とすることなく要求ルーティングに対してコンテンツ・プロバイダが直接制御することを可能とする。通常、コンテンツ・オブジェクトは、別の、埋め込みコンテンツ・オブジェクトへの参照を含む基本構造から構成される。例えば、大部分のウェブページは、単純なテキストと共に．ｇｉｆまたは．ｊｐｇ画像のようないくつかの埋め込みオブジェクトを含むＨＴＭＬ文書から構成される。埋め込みオブジェクトは埋め込みＨＴＭＬ指示を使用して参照される。例えば、ＳＭＩＬ文書内に埋め込まれるであろういくつかの型式のストリーミング・コンテンツに対しても同様の方式が使用される。埋め込みＨＴＭＬまたはＳＭＩＬ指示がクライアントに指示して配信元サーバーから埋め込みオブジェクトをフェッチさせる。ＣＤＮコンテンツ変更方式を使用して、コンテンツ・プロバイダは、最良の代理から（配信元サーバーの代わりに）埋め込みオブジェクトをフェッチするようクライアントに指示するよう埋め込みオブジェクトへの参照を変更可能である。
【００１０】
動作時に、ＣＤＮからサービスされているオブジェクトに対してクライアントが要求を出す時、最適のまたは「最良の」エッジ・ベースのコンテンツ・サーバーが認識される。クライアントのブラウザはそのサーバーからコンテンツに対する要求を出す。要求されたオブジェクトがその識別サーバーから利用可能でない時は、オブジェクトは他のＣＤＮコンテンツ・サーバーから、これに失敗した時は、配信元サーバーから検索される。
【００１１】
（発明の要約）
コンテンツ配信網（ＣＤＮ）と関連してリフレクタ網を使用して、ＣＤＮ入口点へ公開されたライブ・ストリームを要求エンドユーザーに配信可能である。リフレクタは一般化されたパケット・ルータ・プログラムである。リフレクタ網はリフレクタの階層、すなわち、ＣＤＮへの各入口点に配置した少なくとも１つのリフレクタと、ライブ・ストリームを得るためにＣＤＮにより要求をしているユーザーに向けられた各エッジ・ノードと、入口点とエッジ・ノードとの間の（階層中で）少なくとも１つの中間層内に配置された各種の「リフレクタ」ノードと、を含むことが望ましい。中間層は、高度な要求があるときにストリームの配信を容易にするために有用である。エッジ・ノードと各リフレクタ・ノードはまた供給（ｆｅｅｄ）用に配置されたマネージャ・プログラムを含む。エンドユーザーが未だ所要のストリームを受信していないエッジ・ノードに向けられた時、エッジ・ノードのマネージャはリフレクタ・ノードの組に配信要求を発行する。リフレクタ・ノードが既に所要ストリームを受信している場合、リフレクタはこれを要求エッジ・ノードに送信し始める。しかしながら、リフレクタ・ノードが未だ所要ストリームを受信していない場合、そのマネージャ・プログラムは配信要求を階層上位に、最終的に入口点に到達するまで発行して供給を開始する。
【００１２】
以上に本発明の重要な機能のいくつかを概観した。これらの特徴は単に例示的なものであることを認識すべきである。開示発明を異なる方法で適用することによりまたは以下で説明するように本発明を変更することにより、多数のその他の利点が達成可能である。従って、本発明のその他の特徴と完全な理解は、以下の望ましい実施例の詳細な説明を参照することにより得られる。
【００１３】
（望ましい実施例の詳細な説明）
図１は、本発明を実装する例示コンテンツ配信サービスを示す線図である。本発明はその他の既知の、または以後設計されたまたは構築されたコンテンツ配信サービスまたはシステムで同様に実装される。図示実施例では、コンテンツ配信サービスは、コンテンツ配信サービス領域１０２ａ−ｎの望ましくはグローバル・コンテンツ配信網（ＣＤＮ）１００、ドメインネーム・サービス（ＤＮＳ）システム１０４、網上での包含用にコンテンツをタグを付することを可能とするコンテンツ修正すなわち「イニシエータ」ツール１０６を含む。ＤＮＳシステム１０４はマップメーカ１０７から網マッピングデータを受取り、このマップメーカはインターネットを通して分散されている監視エージェント１０９から入力信号を受取る。エージェントは通常各種のテストを実施し、トラヒック状態を監視してインターネット輻輳の問題を識別する。マップメーカ１０７はエージェントから発生されたデータを取ってインターネット・トラヒック状態の詳細を示す１つ以上のマップを発生する。一般に、コンテンツ配信サービスはコンテンツ配信サーバー領域１０２ａ−ｎの網が多数のクライアントを効率的にサービスすることを可能とする。各領域は１つ以上のコンテンツ・サーバーを含み、複数コンテンツ・サーバーは通常ローカルエリア・ネットワーク（ＬＡＮ）バックボーンを共有する。限定する意味ではないが、通常のサーバーは、大量のＲＡＭとディスク記憶を有するＬｉｎｕｘオペレーティングシステムを実行するインテルのペンティアム（登録商標）・ベースのキャッシング・アプライアンスである。これも図１に示すように、コンテンツ配信サービスは、重要なプロセスが動作していること、システムが容量を超えていないこと、コンテンツ・サーバーのサブセット（いわゆるＣＤＮ領域１０２）が正しく相互作用していることを保証するため網を監視する網動作制御センター（ＮＯＣＣ）１１２を含んでもよい。コンテンツ・プロバイダは、要求をしているエンドユーザーがインターネットを経由してそこからコンテンツ・プロバイダのウェブサイトを通常アクセスする配信元サーバー（またはサーバー・ファーム）１１５を操作する。ＣＤＮの使用は、以下で説明するように選択されたコンテンツのインターネットを介した転送を避ける。コンテンツ・プロバイダは、顧客データの実時間及び履歴解析用のツールを含む監視スート１１４へのアクセスも有してよい。あるツールは、網と顧客固有のトラヒック情報への迅速なアクセスを可能とする複数監視ビューを提供するトラヒック・アナライザである。リポータは履歴データの閲覧を可能とする。課金ツールを使用して、ＣＤＮにより配信されたコンテンツの量の関数としてサービスに通常支払う、コンテンツ・プロバイダへの適切な課金情報を生成する。
【００１４】
高性能コンテンツ配信は、ウェブ・オブジェクト（例えば、グラフィック、画像、ストリーミング・メディア、ＨＴＭＬ等）への要求をコンテンツ配信サービス網へ向けることにより提供される。アカマイ・フリーフロー（Ａｋａｍａｉ ＦｒｅｅＦｌｏｗ）コンテンツ配信として知られる、ある既知の技術では、コンテンツは最初に、コンテンツ・プロバイダのウェブ・サイト１１５でコンテンツ・プロバイダにより例えば実行されても良いツール１０６により配信用にタグ付けされる。ストリーミング・コンテンツに対しては、イニシエータ・ツール１０６がストリーミング・コンテンツを参照するＵＲＬを、都合上ＡＲＬと呼ばれる変更リソース・ロケータに変換するため、前記メディアへの要求は配信元サーバーの代わりにＣＤＮから優先的にサービスされる。例えば、ツールは、各ストリーミングＵＲＬの前にＣＤＮドメインを含む文字列を、そしてオプションとして追加制御情報を付加する。例えば、ＵＲＬ ｒｔｓｐ：／／ｗｗｗ．ｆｏｏ．ｃｏｍ／ｍｏｖｉｅ／ｍｏｖに対しては、対応するＡＲＬは以下の通りとなる：
ライブまたはブロードキャスト：

オンデマンドのビデオまたは音声：

【００１５】
もちろん、上記フォーマットは単なる例示である。インターネット・ユーザーがＣＤＮ顧客サイト（例えば、配信元サーバー１１５）を訪れてリンクを選択してストリーミング・メディアを見たり聞いたりする時、ユーザーのシステムがＡＲＬのドメインをＩＰアドレスに変換する。特に、コンテンツはＣＤＮにより配信用にタグ付けされているため、ユーザーに対して透過的なＵＲＬ変更はインターネットの標準であるドメインネーム・サービス（ＤＮＳ）をキューに入れ、ＣＤＮネームサーバー（またはネームサーバーの階層）１０４に問い合わせして、ストリームを入手する適切なメディア・サーバーを識別する。ＣＤＮは要求ルーティング機構（例えば、監視エージェント１０９とマップメーカ１０７から発生されたマップの制御下で）を通常実装して、特定の時間に各ユーザーに最適のサーバーを識別する。各ユーザーは、望ましくは実時間のインターネット条件を基にして最適ストリーミング・サーバーからサービスされているため、ストリーミング・メディア・コンテンツは確実に、かつ最小の可能パケット損失で、従って最高の可能品質でサービスされる。望ましいＤＮＳベースの要求ルーティング機構のこれ以上の詳細は米国特許第６、１０８、７０３号に記載され、これは引用により本明細書に含まれる。
【００１６】
これも引用により本明細書に含まれるが、共願の出願一連番号第０９／４７８、５７１号に記載されているように、ライブ・ストリーミングは、ＣＤＮ入口点からインターネットのエッジの最適ストリーミング・サーバーへ異なるルートを介して同一ストリームの複数コピーをＣＤＮに送信させることによりさらに拡張可能である。これらのコピーは次いで組み合わされて１つの完全な元の品質ストリームを形成し、これがストリーミング・サーバーからエンドユーザーに送信される。図２はこの過程をより詳細に図示している。ブロードキャスト・ストリーム２００がＣＤＮ入口点２０２へ送信される。例えば、入口点は２台のサーバー（冗長性用）を含み、各サーバーは複数コンテンツ・プロバイダからの多数のストリームを処理可能である。入口点が一旦ストリームを受信すると、これはストリームのコピーをセット・リフレクタ２０４ａ−ｎへ再ブロードキャストする。ストリームは望ましくはＵＤＰ（例えば、ＩＰ上でＵＤＰにカプセル化されたＲＴＳＰにカプセル化されたＷＭＴ）を介してセット・リフレクタへ多重化され配信される。これらのセット・リフレクタはフォールトトレラントを保証するために網と地理的観点から分散されることが望ましい（例えば、分散されたインターネット・バックボーンのデータセンターに）。各セット・リフレクタは、次いで、そのストリームのコピーを領域２０６ａ−ｎの組の配信領域、例えば２０６ｄへ再ブロードキャストする。配信領域２０６ｄは、ＣＤＮ要求ルーティング機構によりユーザーがルートされた１つ以上のストリーミング・エッジ・ノード２０８ａ−ｎを含むＣＤＮ領域である。言い換えると、セット・リフレクタはそのストリームを必要とされる各エッジ領域へ送信する。この例では、ＣＤＮ領域は、共通のバックボーン２０９、例えばローカルエリア・ネットワーク（ＬＡＮ）により接続されたエッジ・ノードの組を含む。通常、エッジ・ノード、例えばノード２０８ｄはストリーミング・サーバー２１２を含み、またキャッシュ２１０を含んでもよい。代表的なサーバーはインテルのプロセッサ、リナックスのオペレーティングシステム及びリアルメディアまたはクイックタイム・サーバーを実行する。ウィンドウズ・ベースのプラットフォームでは、代表的なサーバーはインテルのプロセッサ、ウィンドウズＮＴ（登録商標）またはウィンドウズ２０００（登録商標）、及びウィンドウズ・メディア・サーバーを実行する。以下で説明するように、エッジ・ノードはまた制御プログラム２１４も実行して本発明の配信機構を容易にする。
【００１７】
次いで、各配信領域はストリームされたコンテンツの複数コピーを同時に受信する。これらのコピーはインターネット上の別々のルートを介して送信され、従って欠落パケットを発生する輻輳はストリームの各コピーに一様に影響を与えることは考えられない。共願の一連番号第０９／４７８、５７１号に記載されているように、各領域は入口点へ送信されたストリームの元のヴァージョンを実時間で再作成する機構を有することが望ましい。この方法で、本技術が本質的に不完全なインターネットと本質的に損失のあるＵＤＰトランスポート・プロトコルとを補償する。各領域内の再組み立て機構が領域内の全ストリーミング・メディア・サーバーに利用可能な元の全く同一なストリームを作成する。ユーザーがＣＤＮタグのストリームをクリックすると、ＣＤＮの要求ルーティング機構により識別された最適エッジ・ノード（及び、特にそのノードのストリーミング・メディア・サーバー）から配信される。ＣＤＮが、そのブロードキャストされたストリームが配信されていない領域のノードにユーザーをマップした場合（例えば、その領域からサービスされる最初の接続の場合は正である）、その領域は、以下で説明するように、セット・リフレクタに自動的に通知して、本発明を使用してそのストリームを配信する。
【００１８】
本発明の配信機構は、相対的に保守と配置が容易な、一般化されたモジュラー・プログラムの組を含むことが望ましい。これは「ライブ」ストリーミングに使用することが望ましい。これは、多かれ少なかれ実時間で操作されることを意図しているデータを担持しているデータ・ストリームを意味する。ビデオ・オンデマンド（ＶＯＤ）は任意の点で操作可能なデータである。例えば、ＴＶ局はライブで、ビデオテープはＶＯＤである。ビデオテープまたはＶＯＤはそれがライブであるかのようにブロードキャストまたはストリーム可能であるため、何らかのオーバーラップはある。ここで使用するように、「ライブ」はこれら両方の使用を包含する。
【００１９】
ここで図３を参照すると、リフレクタと呼ばれる主プログラムは、基本的にはＵＤＰパケットのアプリケーション・レベル・ルータである、汎用パケット移動エンジンである。リフレクタはユニキャスト、マルチキャスト、またはブロードキャストを使用してパケットを移動する。また、リフレクタ・プログラムは特定のストリームを特定の場所へ条件的に送信する。リフレクタは、静的な設定ファイルを介して、または本発明によると、網上の配信メッセージを経由して設定を学習することによりこれを実行するよう設定可能である。図３から分かるように、入口点３００はリフレクタ・プログラム３０２ａを含み、各セット・リフレクタ・マシン３０４はリフレクタ・プログラム３０２ｂを含み、各エッジ・ノード３０６はリフレクタ・プログラム３０２ｃを含む。エッジ・ノード３０６はまた以前に説明したようにストリーミング・メディア・サーバー３０５も含む。入口点３００もまたストリーミング・メディア・サーバーを実行する。
【００２０】
このように、望ましい実施例では、リフレクタ・プログラムは、最上層の入口点、中間層のセット・リフレクタ、及び下層レベルの１つ以上のエッジ・ノードの領域を含むストリーミング網階層の３つの異なる層で実行する。追加のセット・リフレクタ層もまたスケーラビリティのために実装可能である。一般に、リフレクタ・プログラムは以下のように「リスナ（ｌｉｓｔｅｎｅｒ）」方法と「目的地（ｄｅｓｔｉｎａｔｉｏｎ）」方法とを使用して動作する。リスナはこれらの型式の１つである：
リスナ型式
ＲＴＰ−実時間プロトコル
ＲＦＣ１８８９による実時間プロトコル。リフレクタに関しては、パケット一連番号を使用して統計を保持すること以外、これはデータの任意のチャンク（ＮＯＯＰと同様）として処理される。このリスナ型式は、規格準拠であるアップルのクイックタイムで使用される。
ＮＯＯＰ−演算なし
パケットを移動するだけで、内部の任意の情報に作用しない。これは統計を除いてはＲＴＰと基本的に同じである。ＮＯＯＰは一連番号が無いため、消失、順序異常、または複製パケットの統計を取る手段がない。これはパケット内部でアプリケーションがそれ自身の一連番号を提供することを妨げない。このリスナ型式はＷＭＳで使用される。
ＭＵＭ−マルチプレックス
これはＭＵＸ目的地（以下を参照）により発生されるパケット型式である。これはＲＴＰまたはＮＯＯＰ型式のどちらかのパケットを含む。
代表的な実施例では、リスニング・ポート当り１つのＲＴＰと１つのＮＯＯＰリスナとがある。このポート範囲は設定ファイルで指定される。ＭＵＸリスナは常に専用ポート、例えばポート１４５５で待ち受けている。待ち受けている特定のアドレスは、ユニキャスト、マルチキャスト、またはブロードキャストである。一般に、階層の入口点はＲＴＰ及び／またはＮＯＯＰリスナを有し、一方セット・リフレクタはＭＵＸリスナを有する。
目的地は以下の型式の１つである：
目的地型式
ＮＯＯＰ−演算なし
以前と同様に、パケットを移動するだけで、内部の情報には作用しない。
ＭＵＸ−マルチプレックス
任意の型式のデータを取り、これをマルチプレックス化した「メガストリーム」で送信する。
ＤＥＭＵＸ−デマルチプレックス
マルチプレックス化パケットを取り（ＭＵＸ目的地により発生）、配信元のＲＴＰまたはＮＯＯＰパケットをこれから再構成する。
ＳＭＡＲＴＤＥＭＵＸ−（更に）インテリジェントにデマルチプレックス
これは、ローカル・サーバーからの配信リスト（ポート情報ライブラリ）を参照して現在配信している供給の一部分である場合にパケットのみを送信する点を除いては、ＤＥＭＵＸと同じである。これはエッジ・ノードでの高性能を可能とする。
【００２１】
一般に、複数入力ストリーム（リスナを通して受信）は特定の目的地への送信用に単一のメガストリームに組合される。例えば、２つの別々なＲＴＰポートに２つのＲＴＰリスナがいる場合、これらは単一の目的地への転送用に単一のマルチプレックス化メガストリームに組合わせてもよい。ＲＴＰ目的地型式がないことに注意されたい。代わりに、ＮＯＯＰを使用して、パケットに処理をしてはならないことを指示する。便宜上、リフレクタはＲＴＰを目的地として受け入れ、代わりに、ＮＯＯＰを内部的に使用する。
【００２２】
リフレクタが、動的に作動し、かつ（設定ファイルからではなく）網から設定を学習可能とするため、本発明は配信（ｓｕｂｓｃｒｉｐｔｉｏｎ）機能を実装する。望ましい実施例では、配信はデータの意図したレシーバからセンダへ流れ、従ってレシーバはセンダの「目的地」設定を制御する。配信を使用するため、メッセージがリフレクタに送信され、このリストは受信者が望むポートのリストを含む。リフレクタが既にその特定の目的地へ供給を開始している場合、これは配信メッセージに対応するよう変更される。しかしながら、リフレクタがその特定の目的地へ供給を開始していない場合、新たな目的地が追加される。リフレクタは、オプションとして、配信のソース・アドレスを新たな目的地アドレスとして使用するか、またはこれが不可能な状況（マルチキャストまたはブロードキャスト・アドレス、または単に加入者にとってローカルでないアドレス）では、リフレクタは目的地としてどのアドレスを使用すべきかを告げることが可能である。リフレクタを「チェーン」するため、リフレクタ・プログラムは自己サーバー・モードで動作可能である。これはリフレクタをそれ自身のサーバーとして動作させ、リフレクタが供給用の配信を得た時に、それが、今度は、それ自身用に配信する。この機能はセット・リフレクタで使用されて、以下で説明するように配信を入口点までチェーンする。図示実施例では、配信メッセージは、例えば、適切な認証キーを組み込んだシステムからのみ配信メッセージを受入れることを保証する暗号署名システムを使用して認証される。
【００２３】
各セット・リフレクタ３０４と各エッジ・サーバー３０６はサブマネージャ・プログラム３０８も含むことが望ましい。従って、例えば、セット・リフレクタ３０４はサブマネージャ・プログラム３０８ａを含み、一方エッジ・サーバー３０６はサブマネージャ・プログラム３０８ｂを含む。サブマネージャは供給を手配するツールである。一般に、サブマネージャは同一マシン上で実行するサーバーを聞いていて、これは要求を使用して配信メッセージをリフレクタへ（階層上のより高位へ）送信して供給を開始する。サブマネージャは高利用度を保証するよう動作する。サブマネージャ単独でまたはクラスタで使用してもよく、クラスタは通常複数エッジ・サーバーを有するＣＤＮ領域内の設定である。クラスタで使用する時、サブマネージャは以下の「リーダー」アルゴリズムを実装する：
リーダー・アルゴリズム
１．全ての他のサブマネージャにローカル配信リストをアナウンスし、領域中の他のサブマネージャからのリストを聞き取る。
２．領域中の他のサブマネージャから受信したリストを共にマージする。
３．以下に従って何人か（例えば３人）のリーダーを選出する：
ＩＰアドレスにより応答のリストをソートする
特定期間（例えば、２０秒）聞かれなかったマシンを除去する
先頭の３人を取る
４．全てのリーダーは領域の供給をオンとするため配信メッセージを送信する。
結果として、各領域に入来する３つの供給がある。
単独で使用する時、このリーダー・アルゴリズムは使用されない。代わりに、ローカル・サーバーにより要求された各ポートに単純な配信が行われる。クラスタで使用する時、リーダー選出アルゴリズムを使用して故障マシンを除去する。マシンが故障した場合、これはマシンのリストから消え去る。リーダーが故障した場合、リスト上のその後から来る全てのマシンが１段階昇進する。これは領域中の全てのサーバーへの良好なサービスを保証する助けとなる。
【００２４】
限定する意味ではないが、サブマネージャが特定のポートへの配信に何をなすべきか決定する場合２つの方法があることが望ましい。
ＤＮＳ
ＤＮＳシステムを使用する時、サブマネージャは形式：ｎリーダー番号．ｒ領域番号．ｒｅｆ．ａｋａｍａｉ．ｃｏｍのアドレスを検索しようとする。（例えば、領域５のリーダー２はｎ２．ｒ５．ｒｅｆ．ａｋａｍａｉ．ｃｏｍを検索する。）全ての配信はこのアドレスに送信される。これはサブマネージャが最良のセット・リフレクタに動的にマップされることを可能とするため、エッジ・リフレクタとセット・リフレクタとの間で使用されることが望ましい方法である。
ポートテーブル
ポートテーブル構造はメモリに（そして例えばポートリッスンにより分布されて）組み込まれる。このテーブルはポート当りのＩＰアドレスを含み、従って各供給は単一ポート粒状性（ｇｒａｎｕｌａｒｉｔｙ）により異なるソースから来ることが可能である。これはセット・リフレクタと入口点との間で使用される方法である。
【００２５】
ここで図３に戻ると、各入口点３００は、リフレクタの入力を監視し、セット・リフレクタ上で実行する対応するポートリッスン機能３１２へこのリフレクタを通して利用可能な全てのポートをアナウンスするポートアナウンス機能３１０（これはリフレクタ・プロセス内の別なプログラムまたはスレッドでよい）も含むことが望ましい。ポートリッスン機能３１２は各種のポートアナウンス機能３１０（入口点）からのメッセージを待ち受けし、配信プロセスで使用するためサブマネージャ・プログラムにポートテーブルを構築する。ポート情報ライブラリ３１４は、エッジ・サーバー・プラットフォーム上で実行する任意のストリーミング・メディア・サーバー・プログラムにリンク可能なライブラリである。これは、サブマネージャが配信を設定可能なように、サーバーが望むポートのリストをサブマネージャ（エッジ・サーバー・プラットフォーム上で実行）に提供するために使用される。ルートマスタ・プログラム３１６はリフレクタと通信し、どのストリームがどこで必要とされるかを学習する。必要に応じて、ストリームの品質、特定のルートのコスト等を元にシステムを最良に最適化するためいかにストリームをルートするかについて実時間決定を行う。
【００２６】
従って、図示実施例では、入口点はリフレクタとポートアナウンスを実行し、各セット・リフレクタはリフレクタ、ポートリッスン及びサブマネージャを実行し、各エッジ・サーバー・プラットフォームはリフレクタ、サブマネージャ、及びポート情報ライブラリを使用するストリーミング・サーバーを実行する。多数のリフレクタをインターネット内の戦略的な場所に配置して入口点を作成することが望ましい。ゴールはコンテンツ・プロバイダの近傍に入口点を有することである。コンテンツ・プロバイダはそのライブ・ストリームを入口点へ送信し、この入口点はポートアナウンスを使用してセット・リフレクタに新たなストリームの利用可能性をアナウンスする。入口点は、リフレクタを実行する単なるマシンであり、特別なハードウェアを含まないため、迅速な配置は容易である。入口点は共有バックエンドを有する２台のコンピュータを含むことが望ましいが、これは必要条件ではない。入口点は利用可能性を保証するためフェイルオーバー機構を実行することが望ましい。セット・リフレクタも同様に配置され、世界中の、戦略的位置が望ましい。各セット・リフレクタはそのサブマネージャを使用して、必要に応じて供給、すなわちエッジ・ノードにより要求された供給を入口点へ配信する。各セット・リフレクタのリフレクタは自己サーバー・モードで動作し、一方その中のサブマネージャはポートテーブル・モードで実行し、ポートテーブルはポートリッスンにより分布されることが望ましい。エッジ・ノードは実際のユーザーにサービスするものである。上記したように、エッジ・ノードはリフレクタとサブマネージャと共に、メディア・サーバー（例えば、ＱＴＳＳ、ＷＭＳ、またはリアル・メディア）を実行する。エッジ・ノードは領域に配置されることが望ましいが、これは必要条件ではない。特定の領域は、共通のバックボーンを共有する約１０台のエッジ・マシンを含む。
【００２７】
これも図３に図示するように、特定の領域３２０は、リフレクタ３０２ｄとサブマネージャ３０８ｃを実行する衛星アップリンク・ノード３１５を実行する衛星領域を含んでもよい。一般に、衛星アップリンク・ノードはサーバーを実行せず、ルートマスタ・プログラムにより制御されて、ルートマスタが、ノードに接続された特定の衛星に与えることを決定した供給を配信するよう言い渡される。アップリンク領域でリフレクタにより受信したデータは衛星へ送信される。
【００２８】
限定する意味ではないが、特定のセット・リフレクタ・ノードはペンティアムＩＩＩ（登録商標）クラスのプロセッサ、リナックス・オペレーティングシステム・カーネルを実行し、及び上記したアプリケーション・プログラムをサポートする適切なシステムメモリとディスク記憶を含むマシンである。特定の入口点は、ライブ・ストリームをＣＤＮへ公開するのに必要な追加プログラム（例えば、エンコーダ、コンテンツ・イニシエータ・ツール、等）と共に、同様な構成を有する。セット・リフレクタはセット・リフレクタ・ノードから構成される。
【００２９】
図４は望ましい実施例におけるエッジ・ノードでの配信機構の動作を図示する流れ図である。例えば、ＣＤＮ要求ルーティング機構を使用してユーザーがエッジ・ノードに接続してきた時に、ルーティングが段階４００で開始する。特に、この流れ図は、ストリーミング・メディアがストリーミングＣＤＮを通して配信準備が出来ていて、要求をするユーザーがストリームを識別するリンクをクリックして、かつそのユーザーがＣＤＮにより最適サーバーへルートされたことを仮定している。これらの条件を達成する特定の方法は本発明の範囲外であり、任意の都合のよい既知のまたは以後開発されるＣＤＮ技術及びサービスをこの目的のために使用してもよい。段階４０２で、ユーザーがルートされた特定のエッジ・ノードのストリーミング・メディア・サーバーが要求を受取り、ユーザーがどのライブ・ストリームを必要としているかを決定する。段階４０４で、エッジ・ノードのストリーミング・メディア・サーバーはポート情報ライブラリを使用してストリームを要求する。段階４０６で、エッジ・ノードのストリーミング・メディア・サーバーがストリームを既に受信しているかどうか（例えば、他のユーザーがそのサーバー、または同一領域のサーバーからストリームを再生しているかどうか）を決定する検査を実行する。特定のストリームへの複数配信が単一の配信要求として処理される場合はこの段階は削除してもよい。検査の結果が肯定である場合、ルーティングは終了する。しかしながら、段階４０６の検査が否定である場合、ルーティングは段階４０８を続行する。
【００３０】
この段階で、エッジ・ノードで実行するサブマネージャは、上記したように、領域中の他のエッジ・ノード上で実行するサブマネージャと接触してリーダーの組を決定することを含む、そのリーダー・アルゴリズムを実行する。次いでルーティングは段階４１０を続行し、ＤＮＳ配信方法を使用して配信をセット・リフレクタに送信する。この配信方法によると、サブマネージャが特定のドメイン名、例えばｎ＜リーダー（ｌｅａｄｅｒ）＞．ｒ＜物理領域＞．ｒｅｆ．ａｋａｍａｉ．ｃｏｍを検索する時、ＤＮＳサーバーは要求されたメガストリームを最良に提供可能なセット・リフレクタを返し、ドメイン名のｎ１、ｎ２またはｎ３ホスト名を基にした３つのＩＰアドレスのうちの１つを返す。流れ図に戻ると、次いでルーティングは段階４１２を続行し、セット・リフレクタは３人のリーダー用にその配信リストを変更し、新たな要求ストリームの送信を開始する。
【００３１】
処理は次いで階層を上方へ移動する。特に、図５は特定のセット・リフレクタでの配信機構の動作を図示した流れ図である。セット・リフレクタが既にストリームを受信しているかどうか（例えば、このセット・リフレクタを使用しているどこかの領域が既にこれを受信しているかどうか）を決定する検査により、ルーティングは段階５００で開始する。特定のストリームへの複数配信を単一の配信要求として処理する場合この段階はオプションである。検査の結果が肯定である場合、ルーティングは終了する。しかしながら、段階５００の検査の結果が否定である場合、ルーティングは５０２を続行し、自己サービス機能を使用して、セット・リフレクタはローカル・サブマネージャ（すなわち、セット・リフレクタ・マシンで実行するサブマネージャ）にその配信リストを通知する。段階５０４で、サブマネージャ（ポートリッスンにより分布されたポートテーブルを使用して）はどの入口点がストリームを有するかを検索する。段階６０６で、サブマネージャは配信メッセージを選択した入口点へ送信して、要求セット・リフレクタへの供給を開始する。これで各セット・リフレクタでの処理は完了する。
【００３２】
図６は特定の入口点での配信機構の動作を図示する流れ図である。ルーティングは段階６００から開始し、コンテンツ・プロバイダまたは他の第３者がライブ・コンテンツを含む信号を得る。信号は公衆インターネット、ＩＳＤＮ、衛星またはその他の都合のよい手段で送信可能である。段階６０２で、プロバイダはＣＤＮと接触し、リフレクタ・ポートと最良の入口点アドレスを得る。通常、ＣＤＮはインターネット上に入口点を配置し、ＣＤＮはプロバイダのエンコーダに最良の入口点を識別可能で、段階６０２により、そのＩＰアドレスを提供する。特定の顧客に一意のユーザー名とパスワードを割り当てて、入口点でそのストリームを確認する。さらに、入口点は、インターネット上のどのＣＩＤＲブロックがデータを入口点へストリームするかに関して指令される。段階６０４で、ストリームされるコンテンツがコード化される。もちろん、コード化機能は使用するストリーミング・フォーマットに依存する。ウィンドウズ・ベースのメディアでは、プロバイダはウィンドウズ・メディア・エンコーダを実行して、コンテンツを所要のビットレートとフォーマットにコード化する。リアル・コンテンツでは、プロバイダはリアルプロデューサー（ＲｅａｌＰｒｏｄｕｃｅｒ）エンコーダを使用可能である。アップルのクイックタイムでは、プロバイダはクイックタイム・ストリーミング・サーバー上でソレンセン・ブロードキャスタ（Ｓｏｒｅｎｓｅｎ Ｂｒｏａｄｃａｓｔｅｒ）を実行可能である。段階６０６で、コンテンツ初期化ツールが実行されてストリーミング・メディア・オブジェクトを参照するＵＲＬを変更する。この過程により発生された代表的なＡＲＬは上記に図示されている。段階６０８で、ＡＲＬが公開される。このように、例えば、ウィンドウズ・メディアでは、ＡＲＬはＡＳＸファイルとウェブページを介して公開される。リアル・コンテンツでは、ＡＲＬはＲＡＭファイル、ＳＭＩＬファイルまたはウェブページに埋め込まれる。アップルのクイックタイムでは、ＡＲＬはウェブページに、または参照された映画または有線映画に埋め込まれる。
【００３３】
段階６１０で、入口点リフレクタ・プログラムが初期化されセット・リフレクタからの配信要求を受信するよう待機する。段階６０６と６０８を段階６１０と並列に実行してもよい。ポートアナウンス機能により要求を受信したかどうか段階６１２で検査を実行する。否定の場合、ルーティンは再開する。段階６１２の検査の結果が肯定の時、ポートアナウンスはセット・リフレクタの対応するポートリッスンから配信要求を受信している。段階６１４で、リフレクタは配信セット・リフレクタへの供給を開始する。
【００３４】
本発明の配信機構はいくつかの変形を有してもよい。もちろん、改善されたフォールト・トレランスを提供するため中間層内に任意の数のセット・リフレクタを使用してもよい。さらに、静的設定を使用する代わりに、この機構がセット・リフレクタを動的に選択してもよい（ＤＮＳを使用してプールから一定数のセット・リフレクタを選択する）。さらに、単なるハード的な設定の代わりに、すなわち、ＩＰアドレスをコンテンツ・プロバイダ顧客に提供することにより、入口点も動的に選択してもよい。さらに、多数のライブ供給を配信している領域がこれ以上のストリームを受信不能となった時に、インテリジェントな領域オーバーフローを設けることも望ましい。繁忙な領域はライブ・トラヒックを他の領域へオーバーフローしてもよい。さらに、一定数の入力ストリームを要求するため特定エッジ・ノードでサブマネージャを有することは、特に良好に接続される区域では、不要かもしれない。従って、入力ストリームの現在の数が不足している場合にのみストリームを要求するようサブマネージャをプログラムしてもよい。
【００３５】
衛星動作
公知のように、インターネット・プロトコル（ＩＰ）データの衛星トランスポートは陸上トランスポートとは非常に異なるセマンティックスを有する。データの１回のアップリンクは追加作業なしに無限の場所へダウンリンク可能である。この「１対多数」セマンティックは衛星トランスポートをライブ・ストリームの配信に理想的なものとする。さらに、衛星は一般に公衆インターネットほど損失がない、従って、きれいなストリームをアップリンク可能である場合、これは公衆インターネットを通過してきたものよりダウンリンク上で一般的にはよりきれいである。しかしながら、不運にも、衛星はいくつかの欠点があり、第１に、陸上線路と比較したその高コストである。全てのトランスポート機構と同様に、ヘッドエンドの任意の損失がテールエンドに忠実に配信される。従って、多数の可能なダウンリンクを与えると、この損失は負担するには非常に高価である。
【００３６】
衛星トランスポートの低損失特性は共願の出願一連番号第０９／４７８、５７１号に記載した技術を使用することにより活用可能である。上述したように、特定のＣＤＮ領域は、リフレクタとサブマネージャを実行する衛星アップリンク・ノードを実行する衛星領域を含んでもよい。リフレクタ・ベースの衛星システムは衛星トランジットの特定部分の有用性を最大化する。（リフレクタは衛星のコストに関しては何も出来ないが、高価な帯域を最高に使用するよう配置可能である。）図７に図示するように、アップリンク・センター７００は標準のＣＤＮ領域構成を含み、ここでマシン７０２ａ−ｎはプライベートなバックエンド網７０４を共有する。これらのマシンは上述したようにリフレクタとサブマネージャを実行する。一般に、これらのマシンはストリーミング・サーバーを実行せず、ユーザーはこれらにはマップされない。ダウンリンクでは、すなわちいくつかのその他のＣＤＮエッジ領域７０６、衛星アンテナ７０８及びその関連ハードウェア７１０が、領域のバックエンド網へ、望ましくはマルチキャストでそのデータを提供するよう接続される。マシン７１４ａ−ｎはエッジ・ノードであり、各々が前述したようにストリーミング・サーバーと共にリフレクタとサブマネージャを実行する。
【００３７】
セット・リフレクタはシステムの状態に関する大量の情報を有する。特に、これらは各領域がどのストリームを要求しているかを知っている。この知識をどの領域が衛星ダウンリンク能力を有しているか（そしてどの衛星ベンダから）のリストと、さらに特定時間に各衛星ベンダを使用するコストと組合わせて、あるストリームをアップリンクするのがもっともかどうか計算可能となる。そうである場合、アップリンク・メッセージがアップリンク領域８００に送信され、これはあたかも通常の領域のように、上述した配信方法を使用してストリームを配信することにより、応答する。これはきれいなストリームをアップリンクすることを保証する。次いでデータはマルチキャストに変換されて衛星アップリンクに注入される。データがダウンリンク側に見え始めると、公衆インターネットを通して到着するデータと混合されたきれいなストリームを見て、リフレクタとサブマネージャは、ストリームの陸上線路ヴァージョンからの配信を止めて衛星のみを使用することが望ましい。システムは陸上線路と衛星使用（そして損失がある場合は２者の任意の混合）を非常に迅速に（秒単位）切り換え可能である。このように、例えば天候またはハードウェア故障による衛星故障は直ちにかつ自動的に修復される。以下は、特定のストリームをアップリンクするかどうか、またどこからアップリンクするかを決定する１つの技術を説明する。上記したように、計算はルートマスタにより実施され、異なる衛星会社のコスト（ＣＤＮへの）、ストリームをアップリンク・センターへ持ち込むコスト（これは通常陸上線路を介して生じる必要がある）、ストリームを見る領域数、衛星アンテナを有する領域数、アンテナがどの衛星に向けられているか、のような各種の情報部分を使用してもよい。具体的な例として、１００領域がストリームを見ていて、これらの領域のうちの５０が衛星アンテナを有し、これらのアンテナの内の２０が第１衛星（例えばローラル（Ｌｏｒａｌ））に向けられ、他の３０は第２衛星（例えばヒューズ）に向けられていて、ＣＤＮは第１衛星に一定の第１料金（例えば、メガバイト当り＄．５０）を、第２衛星に一定の第２料金（例えば、メガバイト当り＄．８０）を支払うものとする。また、陸上線路を経由してストリームを配信するコストは一定料（例えば、＄．１０）であるものと仮定する。従って、ストリームを陸上線路を経由して１００領域に配信するためにはＣＤＮは１００＊（．１０）＝＄１０をメガバイト当り支払う。ＣＤＮが第１衛星に切り換えた場合、衛星アンテナを有しない領域にはメガバイト当り８０＊（．１０）＝＄８、加えることの、単一のローラル・アップリンクにはメガバイト当り１＊（．５０）＝＄．５０、全体で＄８．５０を支払う。第２衛星を見ると、ＣＤＮはアンテナのない領域に７０＊（．１０）＝＄７、加えることの、単一のヒューズ・アップリンクには１＊（．８０）＝＄．８０を、全体でメガバイト当り＄７．８０を支払う。従って、ヒューズ・リンクはローラル・リンクより安価である。この種の計算は、どれかの衛星にアップリンクされているストリームのコストを連続的に再評価するため定常的に実行されてもよい。ＣＤＮをさらに節約する他のストリームがある場合には、ＣＤＮはそのストリームをアップリンクすることも可能である。上例ではコストが重要な基準であるが、何時アップリンクするかを評価するために他の要因もルートマスタ・アルゴリズムにより考慮されてもよい。従って、例えば、（入来側のインターネット問題のため）多数の領域が高品質ストリームを得ることが不可能な場合、ルートマスタはこの輻輳をバイパスするため衛星にアップリンク可能である。または、多数の海外領域がある場合、米国線路よりしばしば損失が多く、遅い大洋横断線路を避けるために衛星アップリンクを使用してもよい。もちろん、以上は単なる例示である。
【００３８】
衛星帯域が固定料金（ｃａｐ）を有している場合、衛星帯域を充填することも望ましい。ＣＤＮが衛星帯域に固定コストを支払っている場合、ＣＤＮは出来る限りその帯域を使用したい。上記技術を使用することにより、異なるビットレートの各種ストリームを選択してＣＤＮが出来る限り帯域を充填させることも可能である。ＣＤＮが前記帯域に対して可変のコストを支払っているかどうかも考慮に入れてもよい。衛星会社はその衛星で「使用または未使用」決定を行う有効な手段を有しておらず、特定のストリームをアップリンする過程はしばしば手動で実行されるため、上記技術は非常に有用である。この技術は自動化され、衛星をその最大利点まで使用するよう常に探している。
【００３９】
上述した多数の機能は、個別のプログラムとして説明し図示してきた。当業者には、その代わりに特定の機能が他のプログラムの一部を含んでもよいことが認められる。従って、本明細書でのあるプログラムへの引用は、プログラム、プロセス、実行スレッド、またはその他の上記プログラミング構成概念への参照と広範囲に認めるべきである。具体的な例として、サブマネージャ及びリフレクタとして上述したプログラムは、大きなプログラムの別々なスレッドとして実行してもよい。一般化すると、上述した各機能は、コンピュータ・コード、すなわち、従来の装置、例えば、プロセッサ、マシン、接続マシンの組、システム、等を使用したそのコードの実行を介して記載した機能性を実行するコンピュータ命令の組として、実装されてもよい。
【００４０】
要約すると、図示実施例では、リフレクタ網配置は３層、すなわち入口点、セット・リフレクタ及びエッジ・ノードを含むことが望ましい。各入口点はセット・リフレクタに複数のユニキャストを送信し、各セット・リフレクタは複数の入口点からストリームを受信し、次いでマルチプレックス化されたストリームをエッジ・ノードのサブセットへ送信し、各エッジ・ノードはストリーミング・サーバーをホストするＣＤＮ領域内にあり、セット・リフレクタのあるサブセットからマルチプレックス化ストリームの複数コピーを受信し、次いで領域中の全てのサーバーが全てのストリームを見れるようにそのバックエンド網を通してこれをブロードキャストする。もちろん、特定の領域は１台のストリーミング・サーバーのみ（すなわち、単一のエッジ・ノード）を含んでもよく、これは、リーダー・アルゴリズムの実行を不要とする程度以外は、上述した配信機構に影響を与えない。さらに、需要が少ないストリームへの配信要求に関しては中間層の使用は不要でもよいことが当業者には理解できる。
【００４１】
さらに、本明細書で記載したリフレクタ網とその関連配信機構は任意の型式のデータの一般化配信に使用してもよい。従って、例えば、コンテンツ・プロバイダのメタデータをＣＤＮエッジ・ノードへ公開するためリフレクタがネットワークする。他の例として、ＣＤＮからサービスされるコンテンツによりエッジ・ノード・キャッシュを分布させるツールとして網と配信機構を使用してもよい。
【図面の簡単な説明】
【図１】
本発明を実装する既知のコンテンツ配信網のブロック線図を示す。
【図２】
ＣＤＮ入口点からインターネットのエッジの最適ストリーミング・サーバーへの異なるルートを通して同一ストリームの複数コピーをＣＤＮに送信させることによりライブ・ストリーミングがいかにさらに強化されるかを図示する簡略化ブロック線図を示す。
【図３】
本発明によるリフレクタ配信機構を図示する簡略化線図を示す。
【図４】
ＣＤＮにより要求をしているエンドユーザーが向けられたエッジ・ノードの発明の配信機構の動作を図示する流れ図を示す。
【図５】
本発明によるセット・リフレクタ・ノードの配信機構の動作を図示する流れ図を示す。
【図６】
本発明による入口点の配信機構の動作を図示する流れ図を示す。
【図７】
衛星領域がいかに本発明のリフレクタ配信機構を利用するかを図示する簡略化ブロック線図を示す。

Claims (9)

1. コンテンツ配信網（ＣＤＮ）で使用する配信機構において、一組のコンテンツ・プロバイダ入口点と、セット・リフレクタの中間層と、一組のＣＤＮに公開されたライブ・データ・ストリームを得るために要求しているエンドユーザーが選択的に向けられるエッジ・ノードと、を有し、エッジ・ノードは前記ライブ・データ・ストリームを前記要求しているエンドユーザーに配信するサーバーを含み、前記機構は、
   前記エッジ・ノードで動作して、（ａ）エンドユーザーにより要求されているライブ・データ・ストリームを前記サーバーが既に受信しているかどうかを決定し、（ｂ）前記サーバーが前記ライブ・データ・ストリームを既に受信していない場合には少なくとも１つのセット・リフレクタに前記ライブ・データ・ストリームへの配信を発行する、コードと、
   前記セット・リフレクタで動作して、（ａ）前記エッジ・ノードにより要求されている前記ライブ・データ・ストリームを前記セット・リフレクタが既に受信しているかどうかを決定し、（ｂ）前記セット・リフレクタが前記ライブ・データ・ストリームを既に受信していない場合に特定の入口点に前記ライブ・データ・ストリームへの配信を発行する、コードと、
   を含む前記コンテンツ配信網（ＣＤＮ）で使用する配信機構。
2. 請求項１記載の配信機構において、前記エッジ・ノードも少なくとも１つのセット・リフレクタから前記サーバーへ受信した前記ライブ・データ・ストリームをルーティングするコードも含む前記配信機構。
3. 請求項１記載の配信機構において、前記セット・リフレクタもノードである前記配信機構。
4. 請求項１記載の配信機構において、配信の受信に応答して、前記ライブデータ・ストリームを前記セット・リフレクタにルーティングするため前記特定の入口点で動作するコードを更に含む前記配信機構。
5. 請求項１記載の配信機構において、エッジ・ノードで動作するコードは、望ましい一組の配信を発行すべきセット・リフレクタを決定するコードを含む前記配信機構。
6. コンテンツ配信網（ＣＤＮ）で使用する配信機構において、一組のコンテンツ・プロバイダ入口点と、セット・リフレクタの中間層と、一組のＣＤＮに公開されたライブ・データ・ストリームを得るために要求しているエンドユーザーが選択的に向けられるエッジ・ノードと、を有し、エッジ・ノードは前記ライブ・データ・ストリームを前記要求しているエンドユーザーに配信するサーバーを含み、前記機構は、
   前記エッジ・ノードで動作して、（ａ）エンドユーザーにより要求されているライブ・データ・ストリームをサーバーが既に受信しているかどうかを決定し、（ｂ）前記サーバーが前記ライブ・データ・ストリームを既に受信していない場合に少なくとも１つのセット・リフレクタに前記ライブ・データ・ストリームへの配信を発行し、（ｃ）前記セット・リフレクタからの前記ライブ・データ・ストリームの受信時に前記ライブ・データ・ストリームを前記サーバーへルーティングする、コードと、
   前記セット・リフレクタで動作して、（ａ）前記エッジ・ノードにより要求されている前記ライブ・データ・ストリームを前記セット・リフレクタが既に受信しているかどうかを決定し、（ｂ）前記セット・リフレクタが前記ライブ・データ・ストリームを既に受信していない場合には特定の入口点に前記ライブ・データ・ストリームへの配信を発行し、（ｃ）特定の入口点からのライブ・データ・ストリームの受信時にライブ・データ・ストリームをエッジ・ノードへルーティングする、コードと、
   前記特定の入口点で動作して、配信の受信に応答して前記セット・リフレクタへ前記ライブ・データ・ストリームをルーティングするコードと、
   を含む前記コンテンツ配信網（ＣＤＮ）で使用する配信機構。
7. 請求項６記載の配信機構において、前記エッジ・ノードでのルーティング・コードと、前記セット・リフレクタと、前記特定の入口点と、はＵＤＰパケット・ルータである前記配信機構。
8. 請求項６記載の配信機構において、前記サーバーは、ストリーミング・メディアを特定フォーマットで配信するストリーミング・メディア・サーバーであり、前記特定のフォーマットは一組のウィンドウズ・メディアと、リアルシステムと、クイックタイムと、から構成されるフォーマットから選択される配信機構。
9. 請求項６記載の配信機構において、前記エッジ・ノードで動作するコードは、望ましい一組の前記配信を発行すべきセット・リフレクタを決定するコードを含む前記配信機構。

Images