JP4845321B2 - 分散エッジ・ネットワーク・アーキテクチャ - Google Patents
分散エッジ・ネットワーク・アーキテクチャ Download PDFInfo
- Publication number
- JP4845321B2 JP4845321B2 JP2001573743A JP2001573743A JP4845321B2 JP 4845321 B2 JP4845321 B2 JP 4845321B2 JP 2001573743 A JP2001573743 A JP 2001573743A JP 2001573743 A JP2001573743 A JP 2001573743A JP 4845321 B2 JP4845321 B2 JP 4845321B2
- Authority
- JP
- Japan
- Prior art keywords
- content
- pop
- multimedia streaming
- streaming content
- edge
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2854—Wide area networks, e.g. public data networks
- H04L12/2856—Access arrangements, e.g. Internet access
- H04L12/2869—Operational details of access network equipments
- H04L12/287—Remote access server, e.g. BRAS
- H04L12/2876—Handling of subscriber policies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Bakery Products And Manufacturing Methods Therefor (AREA)
- Confectionery (AREA)
- Medicines That Contain Protein Lipid Enzymes And Other Medicines (AREA)
- Computer And Data Communications (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
【０００１】
（発明の分野）
本発明は、一般に、ネットワーク・サービスの分野に関する。より詳細には、本発明は、ネットワーク・データ配信に関する改良されたアーキテクチャに関する。
【０００２】
（関連技術の説明）
図１に示す従来のネットワーク・キャッシング・システムは、ローカル・エリア・ネットワーク１４０および／またはより大きいネットワーク１１０（例えばインターネット）を介して通信する複数のクライアント１３０〜１３３を含む。クライアント１３０〜１３３は、ハイパーテキスト・トランスポート・プロトコル（「ＨＴＴＰ」）を介して、またはその他のネットワーク・プロトコル（例えば、ファイル・トランスファ・プロトコル、Ｇｏｐｈｅｒ．．．等）を介してＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（「Ｗｅｂ」）上の情報にアクセスするＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（商標）またはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（商標）などのブラウザ・アプリケーションを実行することが可能である。
【０００３】
各クライアント１３０〜１３３のブラウザは、情報（例えば、Ｗｅｂページ）のすべての要求が、「プロキシ・キャッシュ」と一般に呼ばれるローカル・キャッシュ・サーバ１１５を介して伝送されるように構成されている。クライアント１３０が、遠隔のインターネット・サーバ１２０へ情報を要求したとき、ローカル・プロキシ・キャッシュ１１５は、その要求を検査し、要求されたコンテンツが「キャッシュ可能」であるかどうかを最初に判定する（相当な量のインターネット・コンテンツは、「キャッシュ不可能」である）。ローカル・プロキシ・キャッシュ１１５は、キャッシュ不可能な要求を検出した場合、その要求をコンテンツ・ソース（例えば、インターネット・サーバ１２０）に直接に転送する。その要求されたコンテンツが、そのソース１２０からクライアント１３０に直接に伝送され、プロキシ・キャッシュ１１５上にはローカル的に記憶されない。
【０００４】
反対に、プロキシ・キャッシュ１１５は、クライアント１３０のコンテンツ要求がキャッシュ可能であると判定したとき、ローカルに（例えば、ローカル・ハードディスクで）そのコンテンツのコピーを探索する。ローカルのコピーが存在しない場合には、プロキシ・キャッシュ１１５は、そのコンテンツが、「親」キャッシュ１１７（インターネット・サーバ１２０との関係でネットワークのさらに上流に位置する）に記憶されているか、あるいは「兄弟」キャッシュ１１６（コンテンツの要求を受けたインターネット・サーバ１２０との関係でプロキシ・キャッシュと実質的に同じ階層上の位置にある）上に記憶されているかを判定する。
【０００５】
近隣のキャッシュ１１６、１１７のどちらかでキャッシュ「ヒット」が検出された場合、要求されたコンテンツがそのキャッシュから取り出され、クライアント１３０に伝送され、またその他のローカル・クライアント１３１〜１３３による将来の要求に対して利用可能であるようにプロキシ・キャッシュ１１５上にローカルの記憶させる。しかし、キャッシュ「ミス」が生じた場合、コンテンツは、ソースのインターネット・サーバ１２０から取り出され、クライアント１３０に伝送される一方、将来のクライアント要求に対して利用可能であるように、コピーがプロキシ・キャッシュ１１５にローカルで記憶され、また、場合により、親キャッシュ１１７上に記憶される。
【０００６】
本発明のよりよい理解は、添付の図面と併せた以下の詳細な説明から得ることができる。
【０００７】
（詳細な説明）
例としてのネットワーク・アーキテクチャ
本発明の要素は、図２に示すような多層ネットワーキング・アーキテクチャ２００に含まれる。このアーキテクチャは、１つまたは複数のデータ・センタ２２０〜２２２と、複数の「中間」Ｐｏｉｎｔ ｏｆ Ｐｒｅｓｅｎｃｅ（「ＰＯＰ」）ノード２３０〜２３４（本明細書で、「プライベート・ネットワーク・アクセス・ポイント(Private Network Access Point)」又は「Ｐ−ＮＡＰ」とも呼ぶ）と、複数の「エッジ」ＰＯＰノード２４０〜２４５（本明細書で、「インターネット・サービス・プロバイダ・コロケーション（Internet Service Provider Co-Location）」サイトまたは「ＩＳＰ Ｃｏ−Ｌｏ」サイトとも呼ぶ）とを含む。
【０００８】
図２の実施形態によれば、データ・センタ２２０〜２２２、中間ＰＯＰ２３０〜２３４、および／またはエッジＰＯＰ２４０〜２４５のそれぞれが、ネットワーク・サーバのグループから構成される。サーバは、Ｗｅｂページ、ネットワーク・ニュース・データ、電子メール・データ、ファイル・トランスファ・プロトコル（「ＦＴＰ」）ファイル、およびライブ＆オンデマンドのマルチメディア・ストリーミング・ファイルを含む様々なタイプのネットワーク・コンテンツを記憶し、それらをエンド・ユーザ２５０に伝送ることが可能である。ただし、本発明の基礎となる原理は、様々な異なるタイプのネットワーク・コンテンツを使用して実施するのが可能であることに留意されたい。
【０００９】
データ・センタ２２０〜２２２およびＰＯＰ２３０〜２３４、２４０〜２４５に配置されたサーバは、例えば、Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ（「ＤＳ」）チャネル（例えば、ＤＳ−３／Ｔ−３、ＤＳ−１／Ｔ１）、Ｓｙｎｃｈｒｏｎｏｕｓ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ（「ＳＯＮＥＴ」）チャネル（例えば、ＯＣ−３／ＳＴＳ−３）、サービス総合デジタル網（「ＩＳＤＮ」）チャネル、デジタル加入者回線（「ＤＳＬ」）、ケーブル・モデム、チャネル、およびサテライト・ブロードキャストおよびセルラーを含む様々な無線通信チャネルを含む様々な通信チャネルを使用して互いに通信することができ、またエンド・ユーザ１５０と通信することができる。
【００１０】
さらに、様々なネットワーク・プロトコルを使用して、例えば、非同期転送モード（「ＡＴＭ」）、イーサネット、およびトークン・リング（データ・リンク・レベルで）、ならびに伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）、Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｔ Ｅｘｃｈａｎｇｅ（「ＩＰＸ」）、ＡｐｐｌｅＴａｌｋ、およびＤＥＣｎｅｔ（ネットワーク／トランスポート・レベルで）を含むシステムの態様を実施することができる。ただし、本発明の原理は、どの特定の通信チャネルまたは通信プロトコルにも限定されないことに留意されたい。
【００１１】
一実施形態では、分散ネットワーク・コンテンツに関する情報を記憶するためのデータベースが、データ・センタ２２０〜２２２における（また、場合により、ＰＯＰノード２３０〜２３４、２４０〜２４５における）サーバ上に維持される。一実施形態におけるデータベースは、分散データベース（すなわち、複数のサーバにわたって分散された）であり、Ｍｉｃｒｏｓｏｆｔ（商標）のＳＱＬ−Ｓｅｒｖｅｒ、Ｏｒａｃｌｅ（商標）などのリレーショナル・データベース管理システム（ＲＤＢＭＳ）のインスタンスを実行することが可能である。
【００１２】
例としてのコンピュータ・アーキテクチャ
本発明の様々な要素を使用する例としてのネットワーク・アーキテクチャを簡単に説明したので、次に、図３を参照して本発明の要素を実装する例としてのクライアントおよびサーバを示すコンピュータ・システム３００を説明する。
【００１３】
コンピュータ・システム３００の一実施形態は、情報を通信するためのシステム・バス３２０と、情報を処理するためにバス３２０に結合されたプロセッサ３１０とを含む。コンピュータ・システム３００は、情報、およびプロセッサ３１０によって実行される命令を記憶するためバス３２０に結合されたランダム・アクセス・メモリ（ＲＡＭ）、またはその他の動的記憶デバイス３２５（本明細書で、「メイン・メモリ」と呼ぶ）をさらに含む。また、メイン・メモリ３２５は、プロセッサ３１０による命令の実行中、一時的変数またはその他の中間情報を記憶するために使用されている。また、コンピュータ・システム３００は、静的情報、およびプロセッサ３１０によって使用される命令を記憶するためバス３２０に結合された、読取り専用メモリ（「ＲＯＭ」）および／またはその他の静的記憶デバイス３２６も含むことが可能である。
【００１４】
また、磁気ディスクまたは光ディスクなどのデータ記憶デバイス３２７、およびそれに対応するドライブも、情報および命令を記憶するためにコンピュータ・システム３００に結合することができる。また、コンピュータ・システム３００は、Ｉ／Ｏインターフェース３３０を介して第２のＩ／Ｏバス３５０に結合することもできる。表示デバイス３４３および／または入力デバイス（例えば、英数字入力デバイス３４２および／またはカーソル制御デバイス３４１）を含め、複数のＩ／ＯデバイスをＩ／Ｏバス３５０に結合することが可能である。
【００１５】
ネットワーク２１０を介してその他のコンピュータ（サーバまたはクライアント）にアクセスするため、通信デバイス３４０が使用される。通信デバイス３４０は、モデム、ネットワーク・インターフェース・カード、またはイーサネット、トークン・リング、またはその他のタイプのコンピュータ・ネットワークに結合するために使用されるもののようなその他の周知のインターフェース・デバイスを含むことが可能である。
【００１６】
（発明の実施形態）
図２を再び参照すると、本明細書で使用する「コンテンツ・プロバイダ」２６０は、本明細書で説明するシステムおよび方法を介してエンド・ユーザ２５０に配信されるコンテンツを有する個人または団体を指す。「コンテンツ配信サービス」は、本明細書で説明するネットワーク・コンテンツ配信のシステムおよび方法の実施形態を実装している個人または団体によってコンテンツ・プロバイダ２６０に提供されるサービスを指す。
【００１７】
システムの一実施形態では、データ・センタ２２０〜２２２が、ネットワーク・コンテンツのための１次の初期リポジトリとして作用する。したがって、コンテンツ・プロバイダ２６０は、例えば、新しいストリーミング・メディア・プレゼンテーションなどのエンド・ユーザ２５０に配信されるファイルを生成したとき、最初にそのコンテンツをデータ・センタ２２０〜２２２に配置されたストリーミング・サーバにアップロードする。別法では、コンテンツは、データ・センタ２２０〜２２２のオペレーションズ・スタッフのメンバによってロードされることが可能である。次に、そのファイルが、自動化されたコンテンツ配信ポリシーおよび／またはそのファイルに対するエンド・ユーザ要求に基づき（以下により詳細に説明するとおり）、データ・センタ２２０〜２２２から中間ＰＯＰ２３０〜２３４および／またはエッジＰＯＰ２４０〜２４５の１つまたは複数に自動的に配信される。
【００１８】
データ・センタ２２０〜２２２は、膨大な量のコンテンツ・プロバイダ２６０のデータを記憶し、伝送することができなければなければならないため、これらの施設は、数百テラバイトのデータを記憶することができるディスク・アレイを備えている（現行の能力に基づく；最終的には、データ・センタ２２０〜２２２は、ストーレッジ技術の向上に基づき、相当により大きな記憶容量を備えることが可能である）。さらに、データ・センタは、その他のデータ・センタ２２０〜２２２に対する、中間ＰＯＰ２３０〜２３４に対する、またある程度、エッジＰＯＰ２４０〜２４５に対する高帯域幅接続性を備えている。さらに、一実施形態では、データ・センタ２２０〜２２２には、常時、オペレーションズ・スタッフが配備されている（すなわち、１日２４時間、週７日）
【００１９】
本システムの一実施形態では、データ・センタ２２０〜２２２より多くの中間ＰＯＰ２３０〜２３４が実装される。ただし、個々には、中間ＰＯＰ２３０〜２３４は、データ・センタ２３０〜２３４より比較的小さいオンライン記憶容量（数百ギガバイトないし１テラバイトまたは２テラバイトのストーレッジ）で構成することができる。一実施形態における中間ＰＯＰ２３０〜２３４は、世界中に地理的に分散されてより効率的なコンテンツ配信スキームを提供する。また、これらのサイトは、相当な量のネットワークとシステムの管理サポートがデータ・センタ２２０〜２２２から提供されて（以下により詳細に説明する）遠隔式に管理されることも可能である。
【００２０】
エッジＰＯＰ２４０〜２４５は、一実施形態では、中間ＰＯＰ２３０〜２３４と比べてより規模の小さい設備である。ただし、（数が）中間ＰＯＰ２３０〜２３４およびデータ・センタ２２０〜２２２との関係で、相当により地理的に分散したエッジＰＯＰ２４０〜２４５が使用される。エッジＰＯＰは、設備所有者（例えば、インターネット・サービス・プロバイダ）と同じ場所に配置されたいくつかのラックのサーバおよびその他のネットワーキング・デバイスでよい。エッジＰＯＰ２４０〜２４５のいくつかは、ネットワーク２１０に対する直接の高帯域幅接続性を（例えば、Ｔ１チャネルまたはより高いチャネルを介して）備え、他方、その他のＰＯＰ２４０〜２４５は、低帯域幅「制御」接続性（例えば、通常、最低限、ダイヤルアップ・データ接続（モデム）、ただし、部分Ｔ−１接続が含まれることも可能である）だけを備える。いくつかのエッジＰＯＰサイト２３０〜２３４は、インターネットを介してシステムの残りの部分に接続されているものの、接続は、エッジＰＯＰ２４０〜２４５が、データ・センタ２２０〜２２２から管理される仮想プライベート・ネットワーク（「ＶＰＮ」）の一部とすることができる。中間ＰＯＰ２３０〜２３４と同様に、エッジＰＯＰ２４０〜２４５は、データ・センタ２２０〜２２２の１つまたは複数からのネットワークとシステムの管理サポートで遠隔式に管理されることができる。
【００２１】
特定タイプのコンテンツに対するデマンドに基づき、データ・センタ２２０〜２２２、中間ＰＯＰ２３０〜２３４、およびエッジＰＯＰ２４０〜２４５において追加することが可能なモジュラー・ユニットとしてシステム・リソース（例えば、サーバ、接続性）を配備することができる。このモジュール性により、「ローカル」レベルでスケーラビリティが提供され、「グローバル」範囲（システム全体）におけるスケーラビリティが、コンテンツ・プロバイダ２６０ベースにおける成長によって必要とされるにつれての中間ＰＯＰ２３０〜２３４およびエッジＰＯＰ２４０〜２４５の追加、ならびにコンテンツ配信サービスに対する追加／変更を介してサポートされる。このコンテキストにおける「ローカル」レベルとは、データ・センタ内部、中間ＰＯＰ内部、またはエッジＰＯＰ内部を意味する。例として、特定のエッジＰＯＰが、例えば、その「エッジ」において総容量として５０００のストリームを提供する５つのストリーミング・サーバで構成された場合、エッジＰＯＰの容量は、ストリーミング・サーバを除去／追加することにより、予測されるデマンドに応じてより高い／より低い値に（例えば、３０００のストリームまたは１００００のストリームに）（本発明の一実施形態に従って）スケール変更することができる。「グローバル」範囲、つまりシステム全体の範囲では、新しいＰＯＰ、新しいデータ・センタを追加することにより、またさらには、より高い帯域幅をネットワーク接続に加入する／割り振ることによってスケーラビリティを得ることができる。
【００２２】
図２に示す３層アーキテクチャは、ネットワーク２１０の帯域幅およびリソースの最適な使用を提供する。主にエッジＰＯＰ２４０〜２４５からエンド・ユーザ２５０にデータを伝送することにより、長距離接続性（例えば、コンテンツ・ソースから直接にユーザ２５０にサービス提供を行い）が少なくなり、これにより、ネットワーク帯域幅が節約される。この特徴は、相当な帯域幅および記憶容量を必要とするリアルタイム・マルチメディア・ストリーミングなどの用途で特に役に立つ。この結果、エッジＰＯＰ２４０〜２４５からのコンテンツ配信が今日のネットワークにおける主なボトルネックを回避するため、エンド・ユーザは、相当に向上したサービス品質を体験する。
【００２３】
図４に示した本システムの１つの特定の実施形態では、データ・センタ４２０と中間ＰＯＰ４３０、４３２、４３４の間でプライベート高速通信チャネル４２２、４２４、４２６が用意される。このチャネルのすべてが、同じ団体によって所有されていることが可能である。対照的に、この実施形態におけるエッジＰＯＰ４４０〜４４８は、インターネット（すなわち、公共通信チャネルを介して）中間ＰＯＰ４３０、４３２、４３４、およびデータ・センタ４２０に接続されている。
【００２４】
次に、図１４ないし１６に関連して、ライブかつオンデマンドのオーディオ／ビデオ・コンテンツをストリーミングするように構成された本システムの１つの特定の実施形態を説明する。図１４に示すとおり、この実施形態は、サテライト・リンク１４１０を介してブロードキャストされるライブの信号、または記録された信号１４０１、ビデオ会議システム１４１１を介して提供されるライブの信号１４０２、および／または専用インターネット・プロトコル（「ＩＰ」）リンク１４１２を介して伝送されるライブの信号、または記録された信号１４０３を含むが、以上には限定されない様々なソースから、着信するオーディオ／ビデオ・コンテンツを受信することができる。ただし、本発明の基礎となる原理に適合しながらも、ＩＰ以外の限りなく様々なネットワーク・プロトコルを使用できることに留意されたい。一実施形態では、図１４に示したモジュールのそれぞれが、データ・センタ２２０に存在する。
【００２５】
１つまたは複数のシステム獲得−管理モジュール（「ＳＡＭ」）１４２０が、必要に応じて、様々なソース１４０１〜１４０３の間で通信セッションを開くこと、および閉じることを行う。例えば、コンテンツ・プロバイダが、新しいライブのストリーミング・セッションを確立することを望む場合、ＳＡＭ１４２０が、着信するオーディオ／ビデオ・データを扱う新しい接続を開く（コンテンツ・プロバイダが接続を確立する権利を有すると判定した後）。
【００２６】
ＳＡＭモジュール１４２０は、信号が（例えば、コンテンツ・プロバイダにより）既に符号化されているかどうかに基づき、かつ／または信号が「ライブ」のコンテンツから成るか、または「オンデマンド」のコンテンツから成るかに基づき、異なった仕方で着信信号を扱う。例えば、信号がコンテンツ・プロバイダによって既に符号化されていない場合（例えば、信号がアナログ形式で、またはストリーミングではないデジタル形式でデータ・センタ２２０において受信されることが可能である）、ＳＡＭモジュールは、その信号を１つまたは複数のストリーミング・エンコーダ・モジュール１４３０に向け、モジュール１４３０が、そのストリームを指定されたデジタル・ストリーミング形式（例えば、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ（商標）、Ｒｅａｌ Ｇ２（商標）．．．等）で符号化する。
【００２７】
着信信号がライブである場合、ストリーミング・エンコーダ１４３０は、データ・センタ２２０における１つまたは複数のストリーミング起点サーバ１５１０（以下に説明するとおり、様々なＰＯＰノードにその信号を配信する）、および／または１つまたは複数のコンテンツ記憶デバイス５３１に結果の符号化された信号を直接に伝送する。しかし、着信信号がオンデマンドの信号である場合には、ストリーミング・エンコーダ１４３０は、符号化された信号をコンテンツ記憶デバイス５３１に直接に伝送する。同様に、着信信号がストリーミング形式で既に符号化されている場合、この信号は、コンテンツ記憶デバイス５３１に直接に伝送することが可能であり、次に、信号は、記憶デバイス５３１からストリーミング起点サーバ１５１０に伝送することが可能である。新しいオーディオ・ビデオ・ストリーミング・コンテンツがコンテンツ記憶デバイス５３１に追加されるにつれ、ＳＡＭモジュール１４２０は、記憶データベース５３０がそれに応じて更新されるようにする（例えば、以下に説明するコンテンツ配信サブシステムを介して）。
【００２８】
図１５に示すとおり、符号化された信号は、ストリーミング起点サーバ１５１０から、様々なＩ−ＰＯＰノード２３０〜２３２およびＥ−ＰＯＰノード２４０〜２４２に配置されているストリーミング・スプリッタ１５２０〜１５２２、１５３０〜１５３２に伝送される。図示するストリーミング・スプリッタを使用することにより、相当な量のネットワーク帯域幅が節約される。例えば、図示する実施形態では、各ストリーミング・スプリッタが、上流のサーバから単一ストリームのライブのオーディオ／ビデオ・コンテンツだけを受信し、次にこのストリームをいくつかの独立したストリームに分割する。したがって、上流のサーバとストリーミング・スプリッタの間のネットワーク・パスには、単一のオーディオ／ビデオ・ストリームだけがロードされる。
【００２９】
さらに、図示するとおり、多層階層の中でストリーミング・スプリッタを使用することにより、階層の各レベルにおける帯域幅が減少する。例えば、ライブのストリーミング・イベントからの単一ストリームをストリーミング起点サーバ１５１０からＩ−ＰＯＰストリーミング・スプリッタ１５２１に伝送することが可能である。次にストリーミング・スプリッタ１５２１は、Ｅ−ＰＯＰストリーミング・スプリッタ１５３０〜１５３２のそれぞれに単一ストリームを伝送することができ、次にスプリッタ１５３０〜１５３２が、そのライブのイベントを複数のエンド・ユーザ１５４０〜１５４８に伝送する。したがって、データ・センタ２２０とＩ−ＰＯＰ２３１の間のネットワーク・パスに、単一のストリームだけがロードされ、またＩ−ＰＯＰ２３１とＥ−ＰＯＰ２４０〜２４２の間における３つのネットワーク・パスのそれぞれに、単一のストリームがロードされる。次に、着信するストリームがＥ−ＰＯＰ２４０〜２４２のそれぞれにおいて分割されて、複数のエンド・ユーザ１５４０〜１５４８にライブのイベントが提供される。
【００３０】
自動化されたコンテンツ配信
図５に示すとおり、コンテンツ・プロバイダ２６０による（例えば、ＦＴＰを使用する）直接のアップロードを介して、データ・センタのオペレーションズ・スタッフ５１５による（例えば、テープおよびＣＤを介する）直接のアップロードを介して、またはライブのリアルタイム・マルチメディア信号を介して、コンテンツをデータ・センタ５０５におけるシステムに導入することができる。新しいコンテンツがどのように導入されるかに関わらず、一実施形態では、ディレクトリ／ファイル・モニタ・モジュール（「ＤＦ Ｍｏｎ」）５１０が、コンテンツ・データベース５３０を更新して、データ・センタ５０５に着信した新しいファイルを識別する。ファイルが新規であり、まだ中間ＰＯＰ５０６に伝送されていないことを示すようにデータベース・フィールドまたはタグを設定することができる。一実施形態では、ＤＦ Ｍｏｎ５１０は、オペレーティング・システム・プリミティブ（例えば、Ｗｉｎ３２）を使用して符号化されたファイルのディレクトリを監視するデータ・センタにおけるサーバ上のバックグラウンドで実行されるサービス（例えば、Ｗｉｎｄｏｗｓ ＮＴ（登録商標）サービス）である。オペレーティング・システムは、これらのディレクトリにおいていつファイルが追加されたか、または削除されたかをＤＦ Ｍｏｎ５１０に通知する。
【００３１】
次に、自動コンテンツ配信サブシステムが、新たに導入されたコンテンツをシステムを介して自動的に配信する（すなわち、「複製する」または「ミラーリングする」）。一実施形態では、自動コンテンツ配信サブシステムは、コンテンツ配信マネージャ（「ＣＤＭ」）モジュール５２０、およびファイル転送サービス（「ＦＴＳ」）モジュール５２５から成る。ＣＤＭ５２０はコンテンツ配信−管理ポリシーを実施し、ＦＴＳ５２５はファイルの物理的転送を扱う。図５は、データ・センタ５０５に完全に置かれているＦＴＳ５２５およびＣＤＭ５２０を示しているが、これらのモジュールのインスタンスをネットワーク内のその他のノード（例えば、中間ＰＯＰ５４１〜５４４）に実装することも可能であることに留意されたい。
【００３２】
一実施形態では、ネットワーク２１０にわたってコンテンツが配信／複製されるなかでそのコンテンツを追跡するため、データ・センタ２２０〜２２１のどれかにおいて維持される中央データベース５３０が使用される。ＣＤＭ５２０が定期的にデータベース５３０をクエリし、中間ＰＯＰ５０６において何らかのファイル（コンテンツ記憶デバイス５３１上に記憶される）が複製されなければならないかどうかを判定する。あるいは、またはさらには、一群のファイルのあるファイルが複製される必要があるとき、ＣＤＭ５２０に通知が行われることが可能である（例えば、データベース・アプリケーション・プログラミング・インターフェース、ＤＦ Ｍｏｎ５１０、または何らかの他のイベント駆動モジュールによって非同期式に）。
【００３３】
ＣＤＭ５２０は、ファイルが複製される必要があると判定した後、本明細書で「ファイル要求メッセージ」（「ＦＲＭ」）と呼ぶＦＴＳに対するコマンドをＦＴＳ５２５に送信し、ファイル転送のためにファイルおよび宛先ＰＯＰ５０６、５０７を特定する。次に、ＦＴＳ５２５は、基礎のファイル・トランスファ・プロセスを実行し（例えば、Ｗｉｎ３２コマンドまたはＦＴＰコマンドを呼び出すことにより；ＦＴＰコマンドは、インターネットを介する転送の場合）、転送が成功したかどうか、またどこにファイルがコピーされたかを示すデータベース更新を提供する。
【００３４】
ファイル除去プロセスも同様の仕方で行われる。ＣＤＭ５２０が、「削除される」（「ＴＢＤ」）とマークを付けられたファイルに関してデータベース５３０にクエリする。あるいは、またはさらには、ファイルにＴＢＤとマークが付けられたとき、ＣＤＭ５２０に通知が行われる（ファイル転送の場合と同様に）ことが可能である。ファイルには、様々な仕方でＴＢＤのマークを付けることが可能である。例えば、コンテンツ・プロバイダ２６０がファイルをアップロードしたとき、そのプロバイダ２６０が、指定した期間（例えば、１０日間）だけそのファイルが利用可能であることを望むのを示すことができる。あるいは、コンテンツ・プロバイダ２６０は、削除のための日付を指定しないが、代わりに、任意の時点に手動でファイルにＴＢＤのマークを付けること（またはデータ・センタのオペレーションズ・スタッフ５１５にファイルのマーク付けを行わせること）が可能である。別の実施形態では、コンテンツ・プロバイダ２６０は、どれだけ多い頻度で（または少ない頻度で）ユーザ２５０がファイルを要求したかに基づいてファイルにＴＢＤのマークが付けられるべきことを示す。
【００３５】
ファイルがＰＯＰノード５０６、５０７にコピーされた、またはそこから削除された後、コンテンツ配信サブシステムは、中央コンテンツ・データベース５３０の中で「ＦｉｌｅＬｏｃａｔｉｏｎ」データベース・レコードの作成または除去を行う。このレコードは、データ・センタ・ファイルと、中間サイトおよび／またはエッジ・サイトにおける記憶サーバ上のそのファイルのコピーとの関連を提供する。
【００３６】
ＦＲＭデータ構造６００の一実施形態を図６に示している。構造６００は、「ファイル削除」または「ファイル転送」のどちらが必要とされているかの特定、およびファイル削除／転送の特定タイプに関する指示を含め、ファイルに対して行われる必要があるオペレーションをＦＴＳに対して特定するオプコード６１０を含む。例えば、状況に応じては、ＦＴＰ削除／転送、またはＷｉｎ３２削除／転送（または代替のタイプの削除／転送）が適切であろう（例えば、ＦＴＰは、削除／転送がインターネットを介して行われる場合、より適切であり、他方、Ｗｉｎ３２削除／転送は、プライベート・チャネルを介してより効率的である）。
【００３７】
さらに、オプコード・フィールド６１０は、通常の削除／転送、あるいは「怠惰な」削除／転送を指定することができる。基本的に、「怠惰な」ＦＴＳコマンドを使用して優先順位の低い転送／削除を扱うことが可能である。一実施形態では、「怠惰な」コマンドは、単一のスレッド（すなわち、マルチスレッド・システムにおける単一のトランザクションまたは単一のメッセージ）だけを使用して削除要求および転送要求を処理し、他方、「通常の」オペレーションは、複数のスレッドを使用して行うことができる。単一スレッドの「怠惰な」オペレーションは、あるタイプのＦＴＰコマンド（例えば、ＷＳ＿ＦＴＰ ＡＰＩに基づくＦＴＰコマンド）に関して行うことができる。
【００３８】
送信元サーバ・フィールド６２０が、ファイルの起点であるデータ・センタにおけるサーバを特定し、「宛先サーバ数」フィールド６３０が、ファイルが転送／削除されるＰＯＰの数を示し、「ファイル数」フィールド６４０が、トランザクションにおいていくつのファイルが呼び出されるかを示し、「実際のファイルＩＤ」フィールド６５０が、トランザクションにおいて呼び出されるファイルのそれぞれを特定し、また１つまたは複数の「実際の宛先サーバＩＤ」が、ファイルがコピー／削除される実際の宛先サーバを特定する。この実施形態では、「ファイル数」フィールド６４０、および「宛先サーバ数」フィールド６３０がシステムによって使用されて、要求メッセージ・パケット長が判定される（すなわち、これらのフィールドは、実際のファイルＩＤフィールド６５０および実際の宛先サーバＩＤフィールド６６０がどれだけの大きさである必要があるかを特定する）。
【００３９】
要求メッセージ形式６００の以上の説明は、例示だけを目的としていることに留意されたい。本発明の基礎となる原理と適合して、ＣＤＭ５２０とＦＴＳ５２５の間でその他の様々なタイプの情報／データ形式を伝送することができる。
【００４０】
一実施形態では、ＣＤＭ５２０は、ネットワーク輻輳（別名、「ロード」）、ある場所におけるあるファイルに対するデマンド、および／またはコンテンツ・プロバイダ２６０によって加入されたサービスのレベルなどの変数に応じて異なる仕方で、指定された中間ＰＯＰ５４１〜５４４において（また、いくつかのケースでは、エッジＰＯＰ５５１〜５５３において）コンテンツを複製することが可能である。例えば、高いネットワーク輻輳の期間中、ＣＤＭ５２０は、データベース５３０上の待ち行列の中にファイル要求メッセージを記憶することができる。ネットワーク輻輳が所定のしきい値を下回って低下した後、その待ち行列からの要求メッセージがＦＴＳ５２５に伝送され、ＦＴＳ５２５がファイル転送／ファイル削除プロセスを行う。
【００４１】
同様に、特定の時刻において特定のファイルに対するデマンドが極めて高いことが事前に知られており（例えば、「Ｓｔａｒｒ Ｒｅｐｏｒｔ」）、かつ／またはそのファイルが、別の形で相当な量のネットワーク帯域幅を必要とする（例えば、高品質のストリーミング・ビデオ・ファイル）場合には、ＣＤＭ５２０は、ある中間ＰＯＰ５４１〜５４４（および／またはエッジＰＯＰ５５１〜５５３；以下を参照）に事前にそのファイルを伝送して重大なサービス品質の問題（例えば、ネットワーク・クラッシュ）を回避するようにプログラミングすることができる。
【００４２】
また、ＣＤＭ５２０は、各コンテンツ・プロバイダ２６０によって加入されるサービスのレベルに基づいてファイルをＰＯＰ５４１〜５４４にプッシュすることができる。例えば、あるコンテンツ・プロバイダ２６０は、常時、ネットワーク上のすべてのＰＯＰ５４１〜５４４、５５１〜５５３において特定のファイルがすぐに利用可能であるようにするため、追加の支払いをする用意がある可能性がある。さらに、コンテンツ・プロバイダ２６０は、特定タイプのコンテンツがいくつかのＰＯＰ５４１〜５４４上で利用可能であるが、別のＰＯＰ５４１〜５４４上ではそうではないことを望むことがある。国際コンテンツ・プロバイダ２６０が、例えば、中間ＰＯＰ５４１〜５４４が維持されている国（したがって、中間ＰＯＰ５４１〜５４４は、その国内のユーザにコンテンツを供給する）に応じて、異なる中間ＰＯＰ５４１〜５４４サイトにおいて異なる言語で同一の基礎のＷｅｂページが利用可能であることを望む可能性がある。したがって、自動車製造業者が、フランス国内のＰＯＰに自らのＷｅｂページのフランス語バージョンがプッシュされることを望み、またドイツ国内のＰＯＰにドイツ語バージョンがプッシュされることを望むであろう。この実施形態におけるＣＤＭ５２０は、各コンテンツ・プロバイダ２６０の特定のニーズを満たす必要に応じてコンテンツを伝送するように構成することができる。一実施形態では、ＣＤＭ５２０は、データベース５３０の中でファイルにマークが付けられている仕方に基づき（例えば、ファイルは、そのファイルが複製されるべき有効な１組のＰＯＰを示すことが可能である）、どこに指定されたファイルがコピーされる必要があるかを判定する。
【００４３】
ファイル・キャッシング
一実施形態では、エッジＰＯＰ５５１〜５５３は、最も頻繁に要求されるメディア・コンテンツを記憶するためのキャッシュ・ファイル・サーバとして扱われる。一実施形態におけるＣＤＭは、強制キャッシングとデマンド・ベースのキャッシングの両方を使用して、エッジＰＯＰ５５１〜５５３にコンテンツをキャッシュする。
【００４４】
強制キャッシング・プロトコルの下で、ＣＤＭは、特定のエッジＰＯＰサイト５５１〜５５３に高いデマンドが生じるファイルを特定し（例えば、データベース５３０にクエリすることにより）、これに応答して、そのファイルをそれらのサイトにプッシュする。あるいは、またはさらには、コンテンツ・プロバイダは、ＣＤＭが特定の一群のファイルをキャッシングすべきＰＯＰサイト５５１〜５５３を指定することができる。コンテンツ・プロバイダがファイルのキャッシングを行うためにエッジＰＯＰサイト５５１〜５５３を指定する能力は、そのコンテンツ・プロバイダによって加入されたサービスのレベルに基づくことが可能である（中間ＰＯＰサイトに関連して説明したとおり）。
【００４５】
次に、図７に関連して、デマンド・ベースのキャッシングを使用するシステムを説明する。一実施形態では、特定のインターネット・サイト上に記憶されたコンテンツ（例えば、Ｗｅｂページ、ストリーミング・マルチメディア・ファイル．．．等）をユーザ７０５が要求したとき、その要求がロード・バランサ・モジュール（「ＬＢＭ」）７１０によって受信され、ＬＢＭ７１０が、その要求を扱うのに最も適したエッジＰＯＰサイト５０７を特定する。一実施形態におけるＬＢＭ７１０は、データ・センタにおいて存在するモジュールである（例えば、Ｗｅｂサーバ上で実行される）。ＬＢＭ７１０が「最も適している」として特定するものは、ＬＢＭ７１０に適用されている特定のロード・バランサ・ポリシー７７０に依存する。ポリシー７７０は、いくつかを挙げると、ネットワーク・ロード、エッジＰＯＰ５０７サーバ・ロード、コンテンツを要求したユーザの場所、および／またはエッジＰＯＰ５０７サーバの場所などのキャッシング／ネットワーク変数を考慮に入れることが可能である。
【００４６】
一実施形態では、ＬＢＭ７１０は、最も適切なエッジＰＯＰ５０７を探し出し、中央データベース５３０にクエリすることにより（すなわち、一実施形態におけるデータベース５３０は、システム全体のどこに正確にコンテンツが配信されているかを記録に留める）、エッジＰＯＰ５０７においてそのコンテンツが利用可能であるかどうかを判定する。要求されたコンテンツは、エッジＰＯＰ５０７で利用可能である場合、ユーザ７０５に伝送される。しかし、エッジＰＯＰ５０７でそのコンテンツが利用可能ではない場合には、ＬＢＭ７１０は、第２の最も適切なＰＯＰ（例えば、図示する実施形態における中間ＰＯＰ５０６）にその要求を転送し、この第２の最も適切なＰＯＰが、そのコンテンツをユーザ７０５に伝送する。
【００４７】
ＬＭＢ７１０は、要求されたコンテンツがエッジＰＯＰ５０７で利用可能でなかったこと（すなわち、キャッシュ「ミス」が生じたこと）をＣＤＭ５２０に通知する。ＣＤＭ５２０は、特定のエッジＰＯＰサイト５０７が、将来のユーザ要求に対して利用可能であるように要求されたコンテンツのコピーをキャッシュすべきかどうかを判定する。ＣＤＭは、エッジＰＯＰ５０７上でコピーが維持されるべきであると判定した場合、エッジＰＯＰ５０７に対する基礎のファイル転送を実行するＦＴＳ５２５に転送要求メッセージを送信する。
【００４８】
コピーがキャッシュされるべきかどうかに関するＣＤＭ２５０による判定は、適用されている特定のキャッシング・ポリシー７６０に基づく。本システムの一実施形態では、キャッシング・ポリシーは、ある期間にわたってエッジＰＯＰ５０７から特定のファイルが要求された回数を考慮に入れる。しきい値が達せられると（例えば、１時間以内に１０の要求）、ＣＤＭ５２０は、ＦＴＳ５２５にそのファイルのコピーを転送させる。
【００４９】
キャッシング・ポリシー７６０において考慮に入れることができるその他の変数には、いくつかを挙げると、要求されたファイルがキャッシュ不可能であるかどうか（例えば、ユーザ認証を必要とするファイル、または動的に変化するコンテンツ）、エッジＰＯＰ５０７における記憶容量、要求されたファイルのサイズ、ネットワーク輻輳および／またはサーバ輻輳、および特定のコンテンツ・プロバイダ２６０によって加入されたサービスのレベルが含まれる。以上の変数のいずれかが単独で、または組み合わせでＣＤＭ５２０によって使用して、キャッシュ判定を下すことが可能である。
【００５０】
次に、図８の流れ図に関連して、デマンド・ベースのキャッシングを使用する方法の一実施形態を説明する。８１０で、ユーザがコンテンツの要求を行う。これに応答して、ＬＢＭ７１０が、要求されたコンテンツの伝送元として最も適切なエッジＰＯＰサイトを特定する（例えば、データ・センタにおける中央データベースにクエリすることにより）。要求されたコンテンツが８３０で判定されたエッジＰＯＰサーバで利用可能である場合には、ＬＢＭ７１０は、ユーザをそのエッジＰＯＰサーバに誘導し（例えば、そのサーバのＵＲＬをユーザに伝送することにより）、８３５で、そのコンテンツがユーザに伝送される。
【００５１】
しかし、そのコンテンツが利用可能でなかった場合には、８４０で、ＬＢＭが、そのコンテンツの伝送元として最も適切な中間ＰＯＰサーバを特定する（例えば、データベースにクエリすることにより）。８５０で、その中間ＰＯＰサーバがコンテンツをユーザに伝送し、８６０で、ＬＢＭ７１０がＣＤＭ５２０に通知を行う。８７０で、実施されている特定のキャッシング・ポリシーに基づき、要求されたコンテンツのコピーがそのエッジＰＯＰサイトにおいてローカルで記憶されるべきかどうかをＣＤＭが判定する。その判定が、エッジＰＯＰサイトにおいてコンテンツをキャッシュすることである場合には、８８０で、そのコンテンツがそのエッジＰＯＰサイトに転送され、これに応じてデータベースが更新される。
【００５２】
図１６に示すとおり、一実施形態は、頻繁に要求されるストリーミング・コンテンツをＩ−ＰＯＰ２３１および／またはＥ−ＰＯＰにおいてキャッシュするための機構を設けている。特定のオーディオ／ビデオ・ストリーミング・ファイルをキャッシュするかどうかは、そのファイルに対する予期される、かつ／または実際のデマンドに基づく。例えば、所定の期間内にあるＥ−ＰＯＰ２４１においてある回数（例えば、１時間以内に１０回）、特定のファイルが要求された場合には、データ・センタ２２０におけるキャッシュ・サーバ１６１０（コンテンツ記憶デバイス５３１からファイルのサブセットを受け取る）から、Ｅ−ＰＯＰ２４１におけるローカル・キャッシュ・デバイス１６４０にそのファイルを伝送することが可能である。一実施形態では、ＰＯＰサイトの１つまたは複数においてファイルがキャッシュに入れられた、または削除されたとき、その変更を反映するようにデータベース５３０が更新される。
【００５３】
次に、図１３に関連して、マルチメディア・ファイルを配信し、ストリーミングするための本システムおよび本方法の１つの特定の実施形態を説明する。この例においてエッジＰＯＰ５０７を介してインターネットに接続されたビューア１３１０が、オンデマンド・ファイルをストリーミングする要求を行う。このファイルは、ＩＥＳデータベース１３２０の中で「ＦｉｌｅＩｎｆｏ」レコードによってリファレンスが行われ、そのレコードに対するＩＤが、データ・センタ５０５におけるＷｅｂサーバ１３２５にアクセスするためにビューアがクリックするＵＲＬの中にパラメータとして含まれている。この実施形態におけるＷｅｂサーバ１３２５は、ストリーミング・モジュール（例えば、Ｗｅｂページ；Ｗｉｎｄｏｗｓ ９８（商標）の場合、「ｓｔｒｅａｍ．ａｓｐ」）１３３５を起動してその要求を処理する。ストリーミング・モジュール１３３５は、所望のファイルに至るストリーミング・サーバ・パスを含むメタファイル（例えば、Ｒｅａｌ Ｇ２ ＲＡＭメタファイル、またはＷＭＴ ＡＳＸメタファイル）を構築する。ストリーミング・モジュール１３３５は、ストリーム・リダイレクタ１３４０を呼び出してこのパスを決定する。このパスは、ＵＲＬからのＦｉｌｅＩｎｆｏ ＩＤおよびビューアのＩＰアドレスを通る。
【００５４】
一実施形態におけるストリーム・リダイレクタ１３４０は、Ｗｅｂサーバ１３２５上で実行されるｏｕｔ−ｏｆ−ｐｒｏｃ ＣＯＭサーバである。オンデマンド・ファイルに至るストリーミング・サーバ・パスを作成するようにストリーミング・モジュール１３３５によって呼び出されたとき、リダイレクタ１３４０は、まず、データベース１３２０から以前に収集したサイトＩＰマスクのリストに照らしてビューア１３１０のＩＰアドレスを調べる。図示する実施形態では、リダイレクタ１３４０は、マッチを探し出し、ビューア１３１０の接続元であるエッジＰＯＰサイト５０７を正しく識別する。リダイレクタ１３４０は、データベース１３２０を調べて（例えば、データベースＡＰＩを使用して）、ビューアのエッジＰＯＰサイト５０７に所望のファイルが存在するかどうかを判定する。リダイレクタ１３４０は、ＵＲＬからのＦｉｌｅＩｎｆｏ ＩＤを使用してそのサイト５０７にマッチするＦｉｌｅＬｏｃａｔｉｏｎレコードを見つけた場合、エッジＰＯＰサイト５０７と同じ場所に配置されたメディア・サーバ１３４５にビューアを転送するストリーミング・パスを戻す。リダイレクタ１３４０は、エッジＰＯＰサイト５０７にそのファイルがなかった（すなわち、キャッシュ「ミス」となった）場合、代わりに、そのファイルがあることが分かっている中間ＰＯＰサイト５０６のどれかにビューアを転送するパスを生成する。
【００５５】
リダイレクタ１３４０は、中間ＰＯＰ５０６パスをストリーミング・モジュール１３３５に戻した後、コンテンツ配信サブシステム１３５５がファイルのコピーをエッジＰＯＰサイト５０７に伝送することを要求する。あるいは、一実施形態では、リダイレクタ１３４０は、要求されたコンテンツがエッジＰＯＰサイト５０７に存在しなかったことを単にコンテンツ配信サブシステム１３５５に通知し、コンテンツ配信サブシステム１３５５がコピーがエッジ・サイト５０７に記憶されるべきかどうかについて判断できるようにする（例えば、コンテンツ配信ポリシーに基づき）。次に、ＣＤＭが、後の処理のためにジョブが待ち行列に入れられるＦＴＳにその要求を転送する。
【００５６】
リダイレクタ１３４０が中間ＰＯＰ転送パスをストリーミング・モジュール１３３５に戻し、モジュール１３３５はその転送パスをメタファイルに挿入して、ビューア１３１０のブラウザに戻する。ビューア１３１０のブラウザは、このメタファイルを受け取り、それをストリーミング・プレーヤ（例えば、ＲｅａｌＰｌａｙｅｒ（登録商標）、Ｗｉｎｄｏｗｓ ＭｅｄｉａＰｌａｙｅｒ（登録商標）．．．等）に渡す。プレーヤは転送パスに関してメタファイルを構文解析し、指定された中間ＰＯＰ５０６におけるメディア・サーバに対する接続を確立し、オンデマンド・ファイルのストリーミングを開始する。
【００５７】
ＦＴＳは、ファイルをエッジＰＯＰサイト５０７に転送するために（例えば、そのサイトに対するプライベート接続が存在する場合、Ｗｉｎ３２ファイルを介して、あるいは、インターネットがデータ・センタからそのサイトに至る唯一のパスである場合、インターネットを介するＦＴＰを介して）ジョブを処理する。一実施形態におけるＦＴＳは、ネットワーク内のどのサーバ上で実行されてもよい。したがって、ＦＴＳのインスタンスは中間ＰＯＰ５０６に存在し、中間ＰＯＰ５０６からエッジＰＯＰ５０７へのコピーを開始することで、データ・センタ５０５から延びるプライベート接続の帯域幅を節約することが可能である。エッジＰＯＰ５０７のストーレッジに対するファイル・コピーが正常に完了したとき、ＦｉｌｅＩｎｆｏレコードとエッジＰＯＰサイト５０７レコードを関連付ける「ＦｉｌｅＬｏｃａｔｉｏｎ」データベース・レコードをＦＴＳが作成する。
【００５８】
次回に、このエッジＰＯＰ５０７を介して接続するこのビューア１３１０または別のビューアが、同じファイルをストリーミングしようとしたとき、そのファイルは、エッジＰＯＰサイト５０７におけるメディア・サーバ１３４５（例えば、ＩＳＰのＬＡＮに接続された）から直接にストリーミングされる。作成されたＦｉｌｅＬｏｃａｔｉｏｎデータベース・レコードにより、リダイレクタ１３４０が、ビューア１３１０にサービスを提供するより最適なＩＳＰサイトを選択することができるようになる。様々な構成要素の間のタイミングは、システムの要求に応じて異なるが、それでも一般的概念は当てはまることに留意されたい。
【００５９】
記憶スペース管理
図５を再び参照すると、一実施形態では、ＣＤＭ５２０が、中央データベース５３０の中に記憶されたファイル・アクセス・データ（例えば、いつ、またどれだけ頻繁に特定のファイルがエッジＰＯＰにおいて要求されたかを示すデータ）を使用して、すべてのエッジ・ファイル・サーバ上のキャッシュ・スペースを管理するポリシーを実施する。比較的低い頻度で要求されたファイル、および／または他のファイルと比べて比較的長い期間にわたって要求されていないファイルに、エッジＰＯＰからＴＢＤのマークを付けることができる（すなわち、「最低使用頻度」アルゴリズム、および「最終アクセス時刻」アルゴリズムをそれぞれ使用して）。また、ファイル失効日をデータベースに含め（例えば、「ファイルＸは、１／１５／００後、失効する」）、これがＣＤＭ５２０によって使用されてキャッシュ管理機能が行われることが可能である。
【００６０】
一実施形態では、各エッジＰＯＰ５５１〜５５３は、データベース５３０の中に記憶された高いしきい値および低いしきい値に関連している。高いしきい値は、ＣＤＭ５２０がファイル除去オペレーションを起動するには、エッジ・サーバ記憶デバイスがどれだけ満たされていなければならないかを示すパーセンテージである。低いしきい値は、ＣＤＭがそのファイル除去機能を完了したとき、エッジ・サーバ記憶デバイスがどれだけ満たされているかを示すパーセンテージである。
【００６１】
例えば、特定のエッジＰＯＰ５５１に関する高いしきい値が８０％である場合、そのサイトにおけるストーレッジが８０％に達したとき、高いしきい値フラグがデータベース５３０上で設定される。これに応答して、しきい値データに関して定期的にデータベース５３０にクエリするＣＤＭ５２０が、前述したキャッシュ管理ポリシーの１つまたは複数を使用してサイトからファイルを除去するようにＦＴＳ５２５に命令する。そのサイトに関して低いしきい値が６０％に設定されている場合には、ＣＤＭ５２０は、サイトのストーレッジがその容量の６０％に達するまでファイルを削除するようにＦＴＳ５２５に命令する。この仕方で低いしきい値を設定することにより、ファイル・サーバが高いしきい値に達した後も絶え間なくファイル除去オペレーションが実行されることが防止される。
【００６２】
フォールト・トレランス
次に、図９に関連して、フォールト・トレラント機能を使用する本システムの一実施形態を説明する。以前は、複数のファイルサーバが所与のＰＯＰに存在している場合、コンテンツは、コンテンツ・ソースからＰＯＰサイトにおけるそれぞれの個々のファイルサーバに転送されていた。このやり方で同一のファイルの複数のコピーを転送することは、特にマルチメディア・ファイル（一般に極めて大きい）に関して非効率的で、費用が高くつく傾向がある。各サイトにおいて単一のファイルサーバを維持することにより、ネットワーク・トラフィックおよびサーバ・トラフィックの増大の問題が解決されるが、信頼性の問題が生じる（すなわち、そのファイルサーバに障害が起きた場合、サイト全体が利用不可能になる）。
【００６３】
本発明の一実施形態は、１次サーバ９１０、９２０、および９３０がそれぞれ不在である場合にアクティブにされるバックアップ・ファイルサーバ９１１〜９１３、９２１〜９２２、および９３１を設けることにより、以上の問題のすべてを解決する。ファイル転送エージェント（以降、「ＦＴＡ」）と呼ばれるモジュールが、様々なサイトにおいてすべてのファイルサーバ９１０〜９１３、９２０〜９２２、および９３０〜９３１上で実行され、マスタＦＴＡ、またはスレーブＦＴＡとして構成されていることが可能である。マスタＦＴＡファイルサーバ９１０、９２０、９３０は、システムの残りの部分と（例えば、ネットワーク２１０を介してデータ・センタ２２１と）ファイルの送受信を行い、他方、スレーブＦＴＡファイルサーバ９１１〜９１３、９２１〜９２２、および９３１は、それぞれマスタＦＴＡファイルサーバ９１０、９２０、および９３０からファイルを受信するだけである。
【００６４】
各ファイルサーバ・クラスタの中のマスタ／スレーブＦＴＡ指定が、手動で構成され、かつ／またはプロトコルを介して交渉される。ＰＯＰ９００、９０１のそれぞれ、およびデータ・センタ２２１における各マスタＦＴＡおよびスレーブＦＴＡを識別する情報がデータベース５３０の中に記憶される。特定のサイト９００にファイルが転送されたとき（例えば、ＦＴＳファイル転送コマンドを介して）、データ・センタ２２１におけるマスタＦＴＡ９３０が、そのサイトにおけるマスタＦＴＡファイルサーバ９１０をルックアップする（例えば、データベース５３０のクエリを介して）。データ・センタ２２１における送信元マスタＦＴＡファイルサーバ９３０が、ＰＯＰサイト９００における宛先マスタＦＴＡファイルサーバ９１０にファイルを転送する。次に、宛先マスタＦＴＡ９１０が、そのコンテンツをクラスタ内の残りのファイルサーバ９１１〜９１３に転送することを担う。一実施形態では、ＦＴＡは、本明細書で説明するコンテンツ配信サブシステム（すなわち、ＣＤＭ／ＦＴＳ）の一部分を含む。
【００６５】
同様に、マスタＦＴＡファイルサーバ９１０からファイルが削除されたとき、そのマスタＦＴＡは、スレーブ・ファイルサーバ９１１〜９１３からファイルを削除することを担う。このようにして、マスタＦＴＡファイルサーバ９１０に対するあらゆる変更が、クラスタの中のその他の２次ファイルサーバ９１１〜９１２に反映される。一実施形態では、この同期は、マスタＦＴＡファイルサーバ上のあらゆる変更を検出し、次にその他のファイルサーバを自動的に更新するデーモンを使用して実行される。
【００６６】
マスタＦＴＡファイルサーバ９１０がダウンした場合、ファイルサーバ・クラスタの中のスレーブＦＴＡファイルサーバ（例えば、９１１）のどれかがプロトコル交渉を介してマスタＦＴＡになる。一実施形態では、スレーブＦＴＡファイルサーバ９１１〜９１３の１つまたは複数がマスタＦＴＡファイルサーバ９１０にステータス要求を定期的に送信してマスタがアクティブであることを確実にするキープ・アライブ・プロトコルが実施される。所定回数の要求の後、マスタＦＴＡから応答が受信されなかった（マスタがダウンしていることを示し）場合には、スレーブＦＴＡファイルサーバ９１１〜９１２のどれかが、新しいマスタＦＴＡになる。一実施形態では、自動マスタ／スレッド指定が、ランダムに実行され、各ＦＴＡが、乱数を発生させ、最大の乱数を有するＦＴＡが新しいマスタになるように指定される。
【００６７】
誤り処理および回復
１日ヒット数千のファイルがＣＤＭ５２０によって処理される可能性がある。このため、堅固な自動化された誤り処理−回復設計が、エンド・ユーザ２５０に対するサービスの高品質を確実にするのに有益である。ネットワーク障害は、例えば、宛先サイトが利用不可能であること（例えば、サーバがダウンしているため）、極度のネットワーク輻輳、ネットワーク通信チャネルが利用不可能であること、および様々なタイプのソフトウェアの誤りを含め、いくつかの可能な原因を有する可能性がある。次に図１０および１１に関連して説明する本システムの一実施形態では、ＣＤＭが、ネットワーク障害を自動的に検出し、分析し、訂正しようとする。
【００６８】
１０００で（図１０）、ＦＴＳ５２５が、ＣＤＭ５２０要求メッセージに応答して、ファイル・オペレーション（例えば、ファイル転送および／またはファイル削除）を行おうと試みる。そのオペレーションが正常に行われた場合（１０１０で判定される）には、ＦＴＳ５２５が、その変更を反映するようにデータベース５３０を更新し、行われるべき次のファイル・オペレーションに進む。しかし、ＦＴＳ５２５は、要求されたオペレーションを実行できなかった場合には、その誤りをデータベース５３０上の誤り待ち行列１１００の中にログ記録する（１０２０で）。誤り待ち行列１１００の中の各エントリは、障害をもたらした要求メッセージ・オペレーション（例えば、図１１のファイル転送１１０８〜１１１１、１１７６〜１１７７、１１９０、およびファイル削除１１２５）、ならびにその障害の理由を示す誤りコード（例えば、図１１の誤りコード７、１０、および３）を含む。
【００６９】
ＣＤＭ１１２０の誤り分析部分が、定期的に誤りに関してデータベース５３０にクエリを行い（１０３０で）、回復ポリシー１１１０に基づく適切な誤り回復手続きを決定する。回復ポリシー１１１０は、データ・センタ・オペレーションズ・スタッフ５１５（図５参照）によって提供されるネットワーク特有の手続きと汎用の手続きの両方を含むことが可能である。例えば、宛先ＰＯＰが、既知の期間（例えば、午後８：００から午後１１：００まで）、ダウンしていた場合、オペレーションズ・スタッフ５１５は、このネットワーク特有の情報を回復ポリシー１１１０に含めることができる。ＣＤＭ５２０は、指定された期間中、このＰＯＰに向けられたファイル・オペレーション誤りを受信した場合、１０４０で、こられの誤りが回復可能な誤りであることを認識し（すなわち、宛先ＰＯＰがもはやダウンしていないと想定すると）、誤り回復プロセス１０５０を開始する（例えば、ＣＤＭ５２０は、ファイル転送オペレーションを再試行するようにＦＴＳ５２５に指示する）。
【００７０】
また、回復ポリシー１１１０は、汎用回復手続きを含むことも可能である。例えば、失敗したファイル・オペレーションがＦＴＳによって一回試みられている場合、ＣＤＭ５２０は、再び試みるようにＦＴＳ５２５に指示する（すなわち、その障害が、一時的なネットワーク不具合の結果であったと想定すると）。所定回数の試行の後、障害が続く場合、ＣＤＭ５２０は、回復が可能ではないと判定し、オペレーションズ・スタッフ５１５によって点検される報告書を生成する（１０６０で）ことが可能である。
【００７１】
一実施形態では、ＣＤＭ５２０は、生じた誤りの特定のタイプおよび／または前の試行の回数に基づき、回復を試みる１０５０かどうかを判定する。例えば、誤りが、ファイルがデータ・センタ２２１において利用可能でなかったことに起因していた場合には、ＣＤＭ５２０は、回復が可能でないことを即時に認識することができ、それを示す報告書を生成する１０６０。しかし、誤りがネットワーク輻輳に起因していた場合には、ＣＤＭ５２０は、その誤りを訂正する試行を数回行ってから（すなわち、ＣＤＭ５２０は、ファイル・オペレーションを数回試みるようにＦＴＳ５２５に指示することが可能である）、回復が可能でないと判定し、報告書を生成する１０６０。
【００７２】
また、ＣＤＭ５２０は、ある期間にわたって同一のＰＯＰに向けられた特定タイプの誤りの連続回数に基づいて回復可能な誤りを認識することも可能である。例えば、特定のＰＯＰに向けられた連続するファイル転送オペレーション（例えば、ファイル転送１１０８〜１１１１）が、５分間にわたって失敗した場合、ＣＤＭ５２０は、これが、この期間中、ＰＯＰがダウンしていたことを意味するものと自動的に解釈することができる（オペレーションズ・スタッフ５１５が、この情報を回復ポリシーに手動で含める前述した実施形態とは対照的に）。したがって、ＰＯＰが、現時点でオンライン状態にあり、ファイル転送を受け入れている場合、ＣＤＭ５２０は、ファイル転送および／またはファイル削除を再試行するようにＦＴＳ５２５に指示することができる。本発明の基礎となる原理に適合する追加の誤り検出機構および誤り訂正機構を実行することも可能である。
【００７３】
仮想インターネット・プロトコル・アドレスを使用するロード平衡化
特に、マルチメディア・コンテンツのライブまたはオンデマンドのストリーミングなどの高帯域幅の用途に関して、アプリケーション・サービスを提供するのに単一のサーバでは十分でない。図１２を参照すると、そのような状況では、アプリケーション・サービス・デマンドは、リソースのプール、例えば、所与のアプリケーション・サービス１２２０および１２３０をそれぞれサポートするサーバ１２２１〜１２２３および１２３１〜１２３２を利用できるようにすることによって満たされる。図示する実施形態では、どの単一のサーバも、過ロードにならず、アプリケーション・サービス１２２０、１２３０が中断なしに行われるようにロード平衡化が行われる。
【００７４】
レイヤ４スイッチ１２００が、サービスに関連する仮想ＩＰアドレス（「ＶＩＰ」）に基づいてクライアント１２５０〜１２５２によって要求されているサービスの特定のタイプを識別し、その要求をそのサービスに割り当てられたサーバ・プール内の特定のサーバ（例えば、１２２１）に向けることにより、前述の用件をサポートする。例えば、アプリケーション・サービス１２２０が、すべての着信するＷｅｂページ（すなわち、ハイパーテキスト・トランスポート・プロトコル）要求を扱うように構成されている場合には、ＷｅｂページをダウンロードするようにＶＩＰ１２０２に接続しているクライアントが、レイヤ４スイッチ１２００によってＶＩＰ１２０２背後の特定のサーバに転送される。
【００７５】
通常のロード平衡化の構成では、静的なグループのサーバが、アプリケーション・サービス・プールに割り当てられる。本システムの一実施形態では、最適なリソース割振りおよびフォールト・トレランスのために動的に構成可能なサーバ・プール１２２１〜１２２３、１２３１〜１２３２を使用して、複数のアプリケーション・サービスが実施される。より具体的には、この実施形態により、図１２に示すとおり、あるアプリケーション・サービス１２３０に割り当てられたサーバ（例えば、１２２１）が、そのサービスに対するデマンド、および／またはそのサービスに関する現在のロードに基づいて動的に割当て変更されることが可能になる。
【００７６】
例えば、所与の時点で、ライブまたはオンデマンドのストリーミング・イベントが、相当な量のサーバ・リソースを必要とする場合には、そのデマンドを予期して、ストリーミングではないサーバのプールからサーバ１２２１をストリーミング・サーバ１２３１〜１２３２のプールに移動させることができる。これは、自動的に行われること、またはオペレーションズ・スタッフ５１５によって手動で行われることが可能であり、また構成に応じて、割振り変更が行われたサーバをリブートする必要がある可能性がある。
【００７７】
一実施形態では、サーバ割振り変更機構は、ネットワークにおける変更に動的に応答する（そのような変更を予期してではなく）。したがって、特定のアプリケーション・サービス１２３０のために予約されたサーバのプール（例えば、１２３１、１２３２）が、サービス要求の相当な増大を突然に経験した場合、第２のアプリケーション・サービス（例えば、１２２０）に割り当てられたサーバ１２２１が、第１のアプリケーション・サービス１２３０に動的に割当て変更されて、（第２のサービス１２２０もまた、重いネットワーク・ロードを経験しているのではないと想定すると）そのロードのいくらかを扱うことが可能である。一実施形態では、バックグラウンドで実行されるモニタ・モジュールが、異なるアプリケーション・サービスにわたるサーバ・ロードを把握している。あるサービスをサポートしているサーバが過ロードになったとき、モニタ・モジュールは、それほどアクティブでないアプリケーション・サービスから１つまたは複数のサーバの割当て変更を行おうと試みる。
【００７８】
一実施形態では、それほどアクティブでないアプリケーション・サービスのそれぞれのロードが比較され、最低の平均サーバ・ロードを有するアプリケーション・サービスからサーバが選択される。別の実施形態では、予期されるサーバ・ロードも割当て変更の判定の考慮に入れられる。したがって、特定のアプリケーション・サービスが低いサーバ・ロードを経験していても、将来にそのアプリケーション・サービスに重いロードがかかることが予期される場合（例えば、そのアプリケーション・サービスが、盛んに宣伝され、スケジュール設定されたストリーミング・イベントをサポートするのに使用される場合）、そのアプリケーション・サービスからサーバが除去されることはない。
【００７９】
一実施形態では、様々なアプリケーション・サービス・グループ１２３０、１２２０内の各サーバを監視するロード検出−制御論理１２５０（例えば、レイヤ４スイッチ１２００上に、あるいは別のネットワーク・デバイス内部に構成された）を介して動的なサーバ割当て変更が実行される。一実施形態では、サーバおよび／またはアプリケーション・サービス・グループ１２３０、１２２０に関して、高いロードしきい値および低いロードしきい値を設定することができる。一実施形態では、あるグループ内のサーバ上のロードが高いしきい値に達したとき、ロード検出−制御論理１２５０は、別のアプリケーション・グループ（例えば、アプリケーション・グループ１２２０）からのサーバ（例えば、１２２１）を、そのサーバ（またはそのサーバのアプリケーション・サービス・グループ）の現在のロードが低いしきい値より低い場合にだけ、割当て変更しようと試みる。
【００８０】
本発明の実施形態は、前述した様々なステップを含む。このステップは、マシン実行可能命令で実現することが可能である。この命令を使用して、汎用プロセッサまたは専用プロセッサがあるステップを行うようにさせることができる。あるいは、これらのステップは、そのステップを行うためのハードワイヤド論理を含む特定のハードウェア構成要素によって、またはプログラミングされたコンピュータ構成要素とカスタム・ハードウェア構成要素の任意の組み合わせによって実行できる。
【００８１】
本発明の要素は、マシン実行可能命令を記憶するためのマシン可読媒体として提供することが可能である。マシン可読媒体には、フロッピー（登録商標）・ディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、伝播媒体、または電子命令を記憶するのに適したその他のタイプの媒体／マシン可読媒体を含むことが可能であるが、以上には限定されない。例えば、本発明は、通信リンク（例えば、モデム接続またはネットワーク接続）を介する搬送波またはその他の伝播媒体で実現されたデータ信号を介して、遠隔コンピュータ（例えば、サーバ）から要求を行うコンピュータ（例えば、クライアント）に転送することが可能なコンピュータ・プログラムとしてダウンロードすることが可能である。
【００８２】
説明のため、以上の説明全体にわたり、本発明の完全な理解を提供するために多数の特定の詳細を提示した。ただし、これらの特定の詳細のいくつかをなしに本発明を実行できることが、当分野の技術者には明白であろう。したがって、本発明の範囲および趣旨は、頭記の特許請求の範囲で判断されるべきものである。
【図面の簡単な説明】
【図１】 データ・ネットワーク上の従来技術のキャッシング・システムを示す図である。
【図２】 本発明の要素を含む例としてのネットワーク・アーキテクチャを示す図である。
【図３】 本発明の要素を含む例としてのコンピュータ・アーキテクチャを示す図である。
【図４】 本発明の要素を含むネットワーク・アーキテクチャの別の実施形態を示す図である。
【図５】 ネットワーク・コンテンツを配信するためのシステムおよび方法の一実施形態を示す図である。
【図６】 本発明の一実施形態によるファイル要求メッセージを示す図である。
【図７】 ネットワーク・コンテンツがエッジＰＯＰにおいてキャッシュされる本発明の実施形態を示す図である。
【図８】 ネットワーク・コンテンツをキャッシュするための方法の一実施形態を示す図である。
【図９】 フォールト・トレラント機能を含む本発明の一実施形態を示す図である。
【図１０】 誤り検出機能および誤り回復機能を含む本発明の実施形態を示す図である。
【図１１】 誤り検出機能および誤り回復機能を含む本発明の実施形態を示す図である。
【図１２】 本発明の一実施形態による動的なサーバ割振りを示す図である。
【図１３】 ストリーミング・メディアがエッジＰＯＰにおいてキャッシュされる本発明の実施形態を示す図である。
【図１４】 ライブかつ／またはオンデマンドのオーディオ／ビデオ信号を処理するように構成された本発明の一実施形態を示す図である。
【図１５】 オーディオ／ビデオがネットワークを介してエンド・ユーザにストリーミングされる一実施形態を示す図である。
【図１６】 オーディオ／ビデオ・ストリーミング・コンテンツが、１つまたは複数のＰＯＰサイトにおいてキャッシュされる一実施形態を示す図である。
（発明の分野）
本発明は、一般に、ネットワーク・サービスの分野に関する。より詳細には、本発明は、ネットワーク・データ配信に関する改良されたアーキテクチャに関する。
【０００２】
（関連技術の説明）
図１に示す従来のネットワーク・キャッシング・システムは、ローカル・エリア・ネットワーク１４０および／またはより大きいネットワーク１１０（例えばインターネット）を介して通信する複数のクライアント１３０〜１３３を含む。クライアント１３０〜１３３は、ハイパーテキスト・トランスポート・プロトコル（「ＨＴＴＰ」）を介して、またはその他のネットワーク・プロトコル（例えば、ファイル・トランスファ・プロトコル、Ｇｏｐｈｅｒ．．．等）を介してＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（「Ｗｅｂ」）上の情報にアクセスするＮｅｔｓｃａｐｅ Ｎａｖｉｇａｔｏｒ（商標）またはＭｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（商標）などのブラウザ・アプリケーションを実行することが可能である。
【０００３】
各クライアント１３０〜１３３のブラウザは、情報（例えば、Ｗｅｂページ）のすべての要求が、「プロキシ・キャッシュ」と一般に呼ばれるローカル・キャッシュ・サーバ１１５を介して伝送されるように構成されている。クライアント１３０が、遠隔のインターネット・サーバ１２０へ情報を要求したとき、ローカル・プロキシ・キャッシュ１１５は、その要求を検査し、要求されたコンテンツが「キャッシュ可能」であるかどうかを最初に判定する（相当な量のインターネット・コンテンツは、「キャッシュ不可能」である）。ローカル・プロキシ・キャッシュ１１５は、キャッシュ不可能な要求を検出した場合、その要求をコンテンツ・ソース（例えば、インターネット・サーバ１２０）に直接に転送する。その要求されたコンテンツが、そのソース１２０からクライアント１３０に直接に伝送され、プロキシ・キャッシュ１１５上にはローカル的に記憶されない。
【０００４】
反対に、プロキシ・キャッシュ１１５は、クライアント１３０のコンテンツ要求がキャッシュ可能であると判定したとき、ローカルに（例えば、ローカル・ハードディスクで）そのコンテンツのコピーを探索する。ローカルのコピーが存在しない場合には、プロキシ・キャッシュ１１５は、そのコンテンツが、「親」キャッシュ１１７（インターネット・サーバ１２０との関係でネットワークのさらに上流に位置する）に記憶されているか、あるいは「兄弟」キャッシュ１１６（コンテンツの要求を受けたインターネット・サーバ１２０との関係でプロキシ・キャッシュと実質的に同じ階層上の位置にある）上に記憶されているかを判定する。
【０００５】
近隣のキャッシュ１１６、１１７のどちらかでキャッシュ「ヒット」が検出された場合、要求されたコンテンツがそのキャッシュから取り出され、クライアント１３０に伝送され、またその他のローカル・クライアント１３１〜１３３による将来の要求に対して利用可能であるようにプロキシ・キャッシュ１１５上にローカルの記憶させる。しかし、キャッシュ「ミス」が生じた場合、コンテンツは、ソースのインターネット・サーバ１２０から取り出され、クライアント１３０に伝送される一方、将来のクライアント要求に対して利用可能であるように、コピーがプロキシ・キャッシュ１１５にローカルで記憶され、また、場合により、親キャッシュ１１７上に記憶される。
【０００６】
本発明のよりよい理解は、添付の図面と併せた以下の詳細な説明から得ることができる。
【０００７】
（詳細な説明）
例としてのネットワーク・アーキテクチャ
本発明の要素は、図２に示すような多層ネットワーキング・アーキテクチャ２００に含まれる。このアーキテクチャは、１つまたは複数のデータ・センタ２２０〜２２２と、複数の「中間」Ｐｏｉｎｔ ｏｆ Ｐｒｅｓｅｎｃｅ（「ＰＯＰ」）ノード２３０〜２３４（本明細書で、「プライベート・ネットワーク・アクセス・ポイント(Private Network Access Point)」又は「Ｐ−ＮＡＰ」とも呼ぶ）と、複数の「エッジ」ＰＯＰノード２４０〜２４５（本明細書で、「インターネット・サービス・プロバイダ・コロケーション（Internet Service Provider Co-Location）」サイトまたは「ＩＳＰ Ｃｏ−Ｌｏ」サイトとも呼ぶ）とを含む。
【０００８】
図２の実施形態によれば、データ・センタ２２０〜２２２、中間ＰＯＰ２３０〜２３４、および／またはエッジＰＯＰ２４０〜２４５のそれぞれが、ネットワーク・サーバのグループから構成される。サーバは、Ｗｅｂページ、ネットワーク・ニュース・データ、電子メール・データ、ファイル・トランスファ・プロトコル（「ＦＴＰ」）ファイル、およびライブ＆オンデマンドのマルチメディア・ストリーミング・ファイルを含む様々なタイプのネットワーク・コンテンツを記憶し、それらをエンド・ユーザ２５０に伝送ることが可能である。ただし、本発明の基礎となる原理は、様々な異なるタイプのネットワーク・コンテンツを使用して実施するのが可能であることに留意されたい。
【０００９】
データ・センタ２２０〜２２２およびＰＯＰ２３０〜２３４、２４０〜２４５に配置されたサーバは、例えば、Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ（「ＤＳ」）チャネル（例えば、ＤＳ−３／Ｔ−３、ＤＳ−１／Ｔ１）、Ｓｙｎｃｈｒｏｎｏｕｓ Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ（「ＳＯＮＥＴ」）チャネル（例えば、ＯＣ−３／ＳＴＳ−３）、サービス総合デジタル網（「ＩＳＤＮ」）チャネル、デジタル加入者回線（「ＤＳＬ」）、ケーブル・モデム、チャネル、およびサテライト・ブロードキャストおよびセルラーを含む様々な無線通信チャネルを含む様々な通信チャネルを使用して互いに通信することができ、またエンド・ユーザ１５０と通信することができる。
【００１０】
さらに、様々なネットワーク・プロトコルを使用して、例えば、非同期転送モード（「ＡＴＭ」）、イーサネット、およびトークン・リング（データ・リンク・レベルで）、ならびに伝送制御プロトコル／インターネット・プロトコル（「ＴＣＰ／ＩＰ」）、Ｉｎｔｅｒｎｅｔｗｏｒｋ Ｐａｃｋｔ Ｅｘｃｈａｎｇｅ（「ＩＰＸ」）、ＡｐｐｌｅＴａｌｋ、およびＤＥＣｎｅｔ（ネットワーク／トランスポート・レベルで）を含むシステムの態様を実施することができる。ただし、本発明の原理は、どの特定の通信チャネルまたは通信プロトコルにも限定されないことに留意されたい。
【００１１】
一実施形態では、分散ネットワーク・コンテンツに関する情報を記憶するためのデータベースが、データ・センタ２２０〜２２２における（また、場合により、ＰＯＰノード２３０〜２３４、２４０〜２４５における）サーバ上に維持される。一実施形態におけるデータベースは、分散データベース（すなわち、複数のサーバにわたって分散された）であり、Ｍｉｃｒｏｓｏｆｔ（商標）のＳＱＬ−Ｓｅｒｖｅｒ、Ｏｒａｃｌｅ（商標）などのリレーショナル・データベース管理システム（ＲＤＢＭＳ）のインスタンスを実行することが可能である。
【００１２】
例としてのコンピュータ・アーキテクチャ
本発明の様々な要素を使用する例としてのネットワーク・アーキテクチャを簡単に説明したので、次に、図３を参照して本発明の要素を実装する例としてのクライアントおよびサーバを示すコンピュータ・システム３００を説明する。
【００１３】
コンピュータ・システム３００の一実施形態は、情報を通信するためのシステム・バス３２０と、情報を処理するためにバス３２０に結合されたプロセッサ３１０とを含む。コンピュータ・システム３００は、情報、およびプロセッサ３１０によって実行される命令を記憶するためバス３２０に結合されたランダム・アクセス・メモリ（ＲＡＭ）、またはその他の動的記憶デバイス３２５（本明細書で、「メイン・メモリ」と呼ぶ）をさらに含む。また、メイン・メモリ３２５は、プロセッサ３１０による命令の実行中、一時的変数またはその他の中間情報を記憶するために使用されている。また、コンピュータ・システム３００は、静的情報、およびプロセッサ３１０によって使用される命令を記憶するためバス３２０に結合された、読取り専用メモリ（「ＲＯＭ」）および／またはその他の静的記憶デバイス３２６も含むことが可能である。
【００１４】
また、磁気ディスクまたは光ディスクなどのデータ記憶デバイス３２７、およびそれに対応するドライブも、情報および命令を記憶するためにコンピュータ・システム３００に結合することができる。また、コンピュータ・システム３００は、Ｉ／Ｏインターフェース３３０を介して第２のＩ／Ｏバス３５０に結合することもできる。表示デバイス３４３および／または入力デバイス（例えば、英数字入力デバイス３４２および／またはカーソル制御デバイス３４１）を含め、複数のＩ／ＯデバイスをＩ／Ｏバス３５０に結合することが可能である。
【００１５】
ネットワーク２１０を介してその他のコンピュータ（サーバまたはクライアント）にアクセスするため、通信デバイス３４０が使用される。通信デバイス３４０は、モデム、ネットワーク・インターフェース・カード、またはイーサネット、トークン・リング、またはその他のタイプのコンピュータ・ネットワークに結合するために使用されるもののようなその他の周知のインターフェース・デバイスを含むことが可能である。
【００１６】
（発明の実施形態）
図２を再び参照すると、本明細書で使用する「コンテンツ・プロバイダ」２６０は、本明細書で説明するシステムおよび方法を介してエンド・ユーザ２５０に配信されるコンテンツを有する個人または団体を指す。「コンテンツ配信サービス」は、本明細書で説明するネットワーク・コンテンツ配信のシステムおよび方法の実施形態を実装している個人または団体によってコンテンツ・プロバイダ２６０に提供されるサービスを指す。
【００１７】
システムの一実施形態では、データ・センタ２２０〜２２２が、ネットワーク・コンテンツのための１次の初期リポジトリとして作用する。したがって、コンテンツ・プロバイダ２６０は、例えば、新しいストリーミング・メディア・プレゼンテーションなどのエンド・ユーザ２５０に配信されるファイルを生成したとき、最初にそのコンテンツをデータ・センタ２２０〜２２２に配置されたストリーミング・サーバにアップロードする。別法では、コンテンツは、データ・センタ２２０〜２２２のオペレーションズ・スタッフのメンバによってロードされることが可能である。次に、そのファイルが、自動化されたコンテンツ配信ポリシーおよび／またはそのファイルに対するエンド・ユーザ要求に基づき（以下により詳細に説明するとおり）、データ・センタ２２０〜２２２から中間ＰＯＰ２３０〜２３４および／またはエッジＰＯＰ２４０〜２４５の１つまたは複数に自動的に配信される。
【００１８】
データ・センタ２２０〜２２２は、膨大な量のコンテンツ・プロバイダ２６０のデータを記憶し、伝送することができなければなければならないため、これらの施設は、数百テラバイトのデータを記憶することができるディスク・アレイを備えている（現行の能力に基づく；最終的には、データ・センタ２２０〜２２２は、ストーレッジ技術の向上に基づき、相当により大きな記憶容量を備えることが可能である）。さらに、データ・センタは、その他のデータ・センタ２２０〜２２２に対する、中間ＰＯＰ２３０〜２３４に対する、またある程度、エッジＰＯＰ２４０〜２４５に対する高帯域幅接続性を備えている。さらに、一実施形態では、データ・センタ２２０〜２２２には、常時、オペレーションズ・スタッフが配備されている（すなわち、１日２４時間、週７日）
【００１９】
本システムの一実施形態では、データ・センタ２２０〜２２２より多くの中間ＰＯＰ２３０〜２３４が実装される。ただし、個々には、中間ＰＯＰ２３０〜２３４は、データ・センタ２３０〜２３４より比較的小さいオンライン記憶容量（数百ギガバイトないし１テラバイトまたは２テラバイトのストーレッジ）で構成することができる。一実施形態における中間ＰＯＰ２３０〜２３４は、世界中に地理的に分散されてより効率的なコンテンツ配信スキームを提供する。また、これらのサイトは、相当な量のネットワークとシステムの管理サポートがデータ・センタ２２０〜２２２から提供されて（以下により詳細に説明する）遠隔式に管理されることも可能である。
【００２０】
エッジＰＯＰ２４０〜２４５は、一実施形態では、中間ＰＯＰ２３０〜２３４と比べてより規模の小さい設備である。ただし、（数が）中間ＰＯＰ２３０〜２３４およびデータ・センタ２２０〜２２２との関係で、相当により地理的に分散したエッジＰＯＰ２４０〜２４５が使用される。エッジＰＯＰは、設備所有者（例えば、インターネット・サービス・プロバイダ）と同じ場所に配置されたいくつかのラックのサーバおよびその他のネットワーキング・デバイスでよい。エッジＰＯＰ２４０〜２４５のいくつかは、ネットワーク２１０に対する直接の高帯域幅接続性を（例えば、Ｔ１チャネルまたはより高いチャネルを介して）備え、他方、その他のＰＯＰ２４０〜２４５は、低帯域幅「制御」接続性（例えば、通常、最低限、ダイヤルアップ・データ接続（モデム）、ただし、部分Ｔ−１接続が含まれることも可能である）だけを備える。いくつかのエッジＰＯＰサイト２３０〜２３４は、インターネットを介してシステムの残りの部分に接続されているものの、接続は、エッジＰＯＰ２４０〜２４５が、データ・センタ２２０〜２２２から管理される仮想プライベート・ネットワーク（「ＶＰＮ」）の一部とすることができる。中間ＰＯＰ２３０〜２３４と同様に、エッジＰＯＰ２４０〜２４５は、データ・センタ２２０〜２２２の１つまたは複数からのネットワークとシステムの管理サポートで遠隔式に管理されることができる。
【００２１】
特定タイプのコンテンツに対するデマンドに基づき、データ・センタ２２０〜２２２、中間ＰＯＰ２３０〜２３４、およびエッジＰＯＰ２４０〜２４５において追加することが可能なモジュラー・ユニットとしてシステム・リソース（例えば、サーバ、接続性）を配備することができる。このモジュール性により、「ローカル」レベルでスケーラビリティが提供され、「グローバル」範囲（システム全体）におけるスケーラビリティが、コンテンツ・プロバイダ２６０ベースにおける成長によって必要とされるにつれての中間ＰＯＰ２３０〜２３４およびエッジＰＯＰ２４０〜２４５の追加、ならびにコンテンツ配信サービスに対する追加／変更を介してサポートされる。このコンテキストにおける「ローカル」レベルとは、データ・センタ内部、中間ＰＯＰ内部、またはエッジＰＯＰ内部を意味する。例として、特定のエッジＰＯＰが、例えば、その「エッジ」において総容量として５０００のストリームを提供する５つのストリーミング・サーバで構成された場合、エッジＰＯＰの容量は、ストリーミング・サーバを除去／追加することにより、予測されるデマンドに応じてより高い／より低い値に（例えば、３０００のストリームまたは１００００のストリームに）（本発明の一実施形態に従って）スケール変更することができる。「グローバル」範囲、つまりシステム全体の範囲では、新しいＰＯＰ、新しいデータ・センタを追加することにより、またさらには、より高い帯域幅をネットワーク接続に加入する／割り振ることによってスケーラビリティを得ることができる。
【００２２】
図２に示す３層アーキテクチャは、ネットワーク２１０の帯域幅およびリソースの最適な使用を提供する。主にエッジＰＯＰ２４０〜２４５からエンド・ユーザ２５０にデータを伝送することにより、長距離接続性（例えば、コンテンツ・ソースから直接にユーザ２５０にサービス提供を行い）が少なくなり、これにより、ネットワーク帯域幅が節約される。この特徴は、相当な帯域幅および記憶容量を必要とするリアルタイム・マルチメディア・ストリーミングなどの用途で特に役に立つ。この結果、エッジＰＯＰ２４０〜２４５からのコンテンツ配信が今日のネットワークにおける主なボトルネックを回避するため、エンド・ユーザは、相当に向上したサービス品質を体験する。
【００２３】
図４に示した本システムの１つの特定の実施形態では、データ・センタ４２０と中間ＰＯＰ４３０、４３２、４３４の間でプライベート高速通信チャネル４２２、４２４、４２６が用意される。このチャネルのすべてが、同じ団体によって所有されていることが可能である。対照的に、この実施形態におけるエッジＰＯＰ４４０〜４４８は、インターネット（すなわち、公共通信チャネルを介して）中間ＰＯＰ４３０、４３２、４３４、およびデータ・センタ４２０に接続されている。
【００２４】
次に、図１４ないし１６に関連して、ライブかつオンデマンドのオーディオ／ビデオ・コンテンツをストリーミングするように構成された本システムの１つの特定の実施形態を説明する。図１４に示すとおり、この実施形態は、サテライト・リンク１４１０を介してブロードキャストされるライブの信号、または記録された信号１４０１、ビデオ会議システム１４１１を介して提供されるライブの信号１４０２、および／または専用インターネット・プロトコル（「ＩＰ」）リンク１４１２を介して伝送されるライブの信号、または記録された信号１４０３を含むが、以上には限定されない様々なソースから、着信するオーディオ／ビデオ・コンテンツを受信することができる。ただし、本発明の基礎となる原理に適合しながらも、ＩＰ以外の限りなく様々なネットワーク・プロトコルを使用できることに留意されたい。一実施形態では、図１４に示したモジュールのそれぞれが、データ・センタ２２０に存在する。
【００２５】
１つまたは複数のシステム獲得−管理モジュール（「ＳＡＭ」）１４２０が、必要に応じて、様々なソース１４０１〜１４０３の間で通信セッションを開くこと、および閉じることを行う。例えば、コンテンツ・プロバイダが、新しいライブのストリーミング・セッションを確立することを望む場合、ＳＡＭ１４２０が、着信するオーディオ／ビデオ・データを扱う新しい接続を開く（コンテンツ・プロバイダが接続を確立する権利を有すると判定した後）。
【００２６】
ＳＡＭモジュール１４２０は、信号が（例えば、コンテンツ・プロバイダにより）既に符号化されているかどうかに基づき、かつ／または信号が「ライブ」のコンテンツから成るか、または「オンデマンド」のコンテンツから成るかに基づき、異なった仕方で着信信号を扱う。例えば、信号がコンテンツ・プロバイダによって既に符号化されていない場合（例えば、信号がアナログ形式で、またはストリーミングではないデジタル形式でデータ・センタ２２０において受信されることが可能である）、ＳＡＭモジュールは、その信号を１つまたは複数のストリーミング・エンコーダ・モジュール１４３０に向け、モジュール１４３０が、そのストリームを指定されたデジタル・ストリーミング形式（例えば、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ（商標）、Ｒｅａｌ Ｇ２（商標）．．．等）で符号化する。
【００２７】
着信信号がライブである場合、ストリーミング・エンコーダ１４３０は、データ・センタ２２０における１つまたは複数のストリーミング起点サーバ１５１０（以下に説明するとおり、様々なＰＯＰノードにその信号を配信する）、および／または１つまたは複数のコンテンツ記憶デバイス５３１に結果の符号化された信号を直接に伝送する。しかし、着信信号がオンデマンドの信号である場合には、ストリーミング・エンコーダ１４３０は、符号化された信号をコンテンツ記憶デバイス５３１に直接に伝送する。同様に、着信信号がストリーミング形式で既に符号化されている場合、この信号は、コンテンツ記憶デバイス５３１に直接に伝送することが可能であり、次に、信号は、記憶デバイス５３１からストリーミング起点サーバ１５１０に伝送することが可能である。新しいオーディオ・ビデオ・ストリーミング・コンテンツがコンテンツ記憶デバイス５３１に追加されるにつれ、ＳＡＭモジュール１４２０は、記憶データベース５３０がそれに応じて更新されるようにする（例えば、以下に説明するコンテンツ配信サブシステムを介して）。
【００２８】
図１５に示すとおり、符号化された信号は、ストリーミング起点サーバ１５１０から、様々なＩ−ＰＯＰノード２３０〜２３２およびＥ−ＰＯＰノード２４０〜２４２に配置されているストリーミング・スプリッタ１５２０〜１５２２、１５３０〜１５３２に伝送される。図示するストリーミング・スプリッタを使用することにより、相当な量のネットワーク帯域幅が節約される。例えば、図示する実施形態では、各ストリーミング・スプリッタが、上流のサーバから単一ストリームのライブのオーディオ／ビデオ・コンテンツだけを受信し、次にこのストリームをいくつかの独立したストリームに分割する。したがって、上流のサーバとストリーミング・スプリッタの間のネットワーク・パスには、単一のオーディオ／ビデオ・ストリームだけがロードされる。
【００２９】
さらに、図示するとおり、多層階層の中でストリーミング・スプリッタを使用することにより、階層の各レベルにおける帯域幅が減少する。例えば、ライブのストリーミング・イベントからの単一ストリームをストリーミング起点サーバ１５１０からＩ−ＰＯＰストリーミング・スプリッタ１５２１に伝送することが可能である。次にストリーミング・スプリッタ１５２１は、Ｅ−ＰＯＰストリーミング・スプリッタ１５３０〜１５３２のそれぞれに単一ストリームを伝送することができ、次にスプリッタ１５３０〜１５３２が、そのライブのイベントを複数のエンド・ユーザ１５４０〜１５４８に伝送する。したがって、データ・センタ２２０とＩ−ＰＯＰ２３１の間のネットワーク・パスに、単一のストリームだけがロードされ、またＩ−ＰＯＰ２３１とＥ−ＰＯＰ２４０〜２４２の間における３つのネットワーク・パスのそれぞれに、単一のストリームがロードされる。次に、着信するストリームがＥ−ＰＯＰ２４０〜２４２のそれぞれにおいて分割されて、複数のエンド・ユーザ１５４０〜１５４８にライブのイベントが提供される。
【００３０】
自動化されたコンテンツ配信
図５に示すとおり、コンテンツ・プロバイダ２６０による（例えば、ＦＴＰを使用する）直接のアップロードを介して、データ・センタのオペレーションズ・スタッフ５１５による（例えば、テープおよびＣＤを介する）直接のアップロードを介して、またはライブのリアルタイム・マルチメディア信号を介して、コンテンツをデータ・センタ５０５におけるシステムに導入することができる。新しいコンテンツがどのように導入されるかに関わらず、一実施形態では、ディレクトリ／ファイル・モニタ・モジュール（「ＤＦ Ｍｏｎ」）５１０が、コンテンツ・データベース５３０を更新して、データ・センタ５０５に着信した新しいファイルを識別する。ファイルが新規であり、まだ中間ＰＯＰ５０６に伝送されていないことを示すようにデータベース・フィールドまたはタグを設定することができる。一実施形態では、ＤＦ Ｍｏｎ５１０は、オペレーティング・システム・プリミティブ（例えば、Ｗｉｎ３２）を使用して符号化されたファイルのディレクトリを監視するデータ・センタにおけるサーバ上のバックグラウンドで実行されるサービス（例えば、Ｗｉｎｄｏｗｓ ＮＴ（登録商標）サービス）である。オペレーティング・システムは、これらのディレクトリにおいていつファイルが追加されたか、または削除されたかをＤＦ Ｍｏｎ５１０に通知する。
【００３１】
次に、自動コンテンツ配信サブシステムが、新たに導入されたコンテンツをシステムを介して自動的に配信する（すなわち、「複製する」または「ミラーリングする」）。一実施形態では、自動コンテンツ配信サブシステムは、コンテンツ配信マネージャ（「ＣＤＭ」）モジュール５２０、およびファイル転送サービス（「ＦＴＳ」）モジュール５２５から成る。ＣＤＭ５２０はコンテンツ配信−管理ポリシーを実施し、ＦＴＳ５２５はファイルの物理的転送を扱う。図５は、データ・センタ５０５に完全に置かれているＦＴＳ５２５およびＣＤＭ５２０を示しているが、これらのモジュールのインスタンスをネットワーク内のその他のノード（例えば、中間ＰＯＰ５４１〜５４４）に実装することも可能であることに留意されたい。
【００３２】
一実施形態では、ネットワーク２１０にわたってコンテンツが配信／複製されるなかでそのコンテンツを追跡するため、データ・センタ２２０〜２２１のどれかにおいて維持される中央データベース５３０が使用される。ＣＤＭ５２０が定期的にデータベース５３０をクエリし、中間ＰＯＰ５０６において何らかのファイル（コンテンツ記憶デバイス５３１上に記憶される）が複製されなければならないかどうかを判定する。あるいは、またはさらには、一群のファイルのあるファイルが複製される必要があるとき、ＣＤＭ５２０に通知が行われることが可能である（例えば、データベース・アプリケーション・プログラミング・インターフェース、ＤＦ Ｍｏｎ５１０、または何らかの他のイベント駆動モジュールによって非同期式に）。
【００３３】
ＣＤＭ５２０は、ファイルが複製される必要があると判定した後、本明細書で「ファイル要求メッセージ」（「ＦＲＭ」）と呼ぶＦＴＳに対するコマンドをＦＴＳ５２５に送信し、ファイル転送のためにファイルおよび宛先ＰＯＰ５０６、５０７を特定する。次に、ＦＴＳ５２５は、基礎のファイル・トランスファ・プロセスを実行し（例えば、Ｗｉｎ３２コマンドまたはＦＴＰコマンドを呼び出すことにより；ＦＴＰコマンドは、インターネットを介する転送の場合）、転送が成功したかどうか、またどこにファイルがコピーされたかを示すデータベース更新を提供する。
【００３４】
ファイル除去プロセスも同様の仕方で行われる。ＣＤＭ５２０が、「削除される」（「ＴＢＤ」）とマークを付けられたファイルに関してデータベース５３０にクエリする。あるいは、またはさらには、ファイルにＴＢＤとマークが付けられたとき、ＣＤＭ５２０に通知が行われる（ファイル転送の場合と同様に）ことが可能である。ファイルには、様々な仕方でＴＢＤのマークを付けることが可能である。例えば、コンテンツ・プロバイダ２６０がファイルをアップロードしたとき、そのプロバイダ２６０が、指定した期間（例えば、１０日間）だけそのファイルが利用可能であることを望むのを示すことができる。あるいは、コンテンツ・プロバイダ２６０は、削除のための日付を指定しないが、代わりに、任意の時点に手動でファイルにＴＢＤのマークを付けること（またはデータ・センタのオペレーションズ・スタッフ５１５にファイルのマーク付けを行わせること）が可能である。別の実施形態では、コンテンツ・プロバイダ２６０は、どれだけ多い頻度で（または少ない頻度で）ユーザ２５０がファイルを要求したかに基づいてファイルにＴＢＤのマークが付けられるべきことを示す。
【００３５】
ファイルがＰＯＰノード５０６、５０７にコピーされた、またはそこから削除された後、コンテンツ配信サブシステムは、中央コンテンツ・データベース５３０の中で「ＦｉｌｅＬｏｃａｔｉｏｎ」データベース・レコードの作成または除去を行う。このレコードは、データ・センタ・ファイルと、中間サイトおよび／またはエッジ・サイトにおける記憶サーバ上のそのファイルのコピーとの関連を提供する。
【００３６】
ＦＲＭデータ構造６００の一実施形態を図６に示している。構造６００は、「ファイル削除」または「ファイル転送」のどちらが必要とされているかの特定、およびファイル削除／転送の特定タイプに関する指示を含め、ファイルに対して行われる必要があるオペレーションをＦＴＳに対して特定するオプコード６１０を含む。例えば、状況に応じては、ＦＴＰ削除／転送、またはＷｉｎ３２削除／転送（または代替のタイプの削除／転送）が適切であろう（例えば、ＦＴＰは、削除／転送がインターネットを介して行われる場合、より適切であり、他方、Ｗｉｎ３２削除／転送は、プライベート・チャネルを介してより効率的である）。
【００３７】
さらに、オプコード・フィールド６１０は、通常の削除／転送、あるいは「怠惰な」削除／転送を指定することができる。基本的に、「怠惰な」ＦＴＳコマンドを使用して優先順位の低い転送／削除を扱うことが可能である。一実施形態では、「怠惰な」コマンドは、単一のスレッド（すなわち、マルチスレッド・システムにおける単一のトランザクションまたは単一のメッセージ）だけを使用して削除要求および転送要求を処理し、他方、「通常の」オペレーションは、複数のスレッドを使用して行うことができる。単一スレッドの「怠惰な」オペレーションは、あるタイプのＦＴＰコマンド（例えば、ＷＳ＿ＦＴＰ ＡＰＩに基づくＦＴＰコマンド）に関して行うことができる。
【００３８】
送信元サーバ・フィールド６２０が、ファイルの起点であるデータ・センタにおけるサーバを特定し、「宛先サーバ数」フィールド６３０が、ファイルが転送／削除されるＰＯＰの数を示し、「ファイル数」フィールド６４０が、トランザクションにおいていくつのファイルが呼び出されるかを示し、「実際のファイルＩＤ」フィールド６５０が、トランザクションにおいて呼び出されるファイルのそれぞれを特定し、また１つまたは複数の「実際の宛先サーバＩＤ」が、ファイルがコピー／削除される実際の宛先サーバを特定する。この実施形態では、「ファイル数」フィールド６４０、および「宛先サーバ数」フィールド６３０がシステムによって使用されて、要求メッセージ・パケット長が判定される（すなわち、これらのフィールドは、実際のファイルＩＤフィールド６５０および実際の宛先サーバＩＤフィールド６６０がどれだけの大きさである必要があるかを特定する）。
【００３９】
要求メッセージ形式６００の以上の説明は、例示だけを目的としていることに留意されたい。本発明の基礎となる原理と適合して、ＣＤＭ５２０とＦＴＳ５２５の間でその他の様々なタイプの情報／データ形式を伝送することができる。
【００４０】
一実施形態では、ＣＤＭ５２０は、ネットワーク輻輳（別名、「ロード」）、ある場所におけるあるファイルに対するデマンド、および／またはコンテンツ・プロバイダ２６０によって加入されたサービスのレベルなどの変数に応じて異なる仕方で、指定された中間ＰＯＰ５４１〜５４４において（また、いくつかのケースでは、エッジＰＯＰ５５１〜５５３において）コンテンツを複製することが可能である。例えば、高いネットワーク輻輳の期間中、ＣＤＭ５２０は、データベース５３０上の待ち行列の中にファイル要求メッセージを記憶することができる。ネットワーク輻輳が所定のしきい値を下回って低下した後、その待ち行列からの要求メッセージがＦＴＳ５２５に伝送され、ＦＴＳ５２５がファイル転送／ファイル削除プロセスを行う。
【００４１】
同様に、特定の時刻において特定のファイルに対するデマンドが極めて高いことが事前に知られており（例えば、「Ｓｔａｒｒ Ｒｅｐｏｒｔ」）、かつ／またはそのファイルが、別の形で相当な量のネットワーク帯域幅を必要とする（例えば、高品質のストリーミング・ビデオ・ファイル）場合には、ＣＤＭ５２０は、ある中間ＰＯＰ５４１〜５４４（および／またはエッジＰＯＰ５５１〜５５３；以下を参照）に事前にそのファイルを伝送して重大なサービス品質の問題（例えば、ネットワーク・クラッシュ）を回避するようにプログラミングすることができる。
【００４２】
また、ＣＤＭ５２０は、各コンテンツ・プロバイダ２６０によって加入されるサービスのレベルに基づいてファイルをＰＯＰ５４１〜５４４にプッシュすることができる。例えば、あるコンテンツ・プロバイダ２６０は、常時、ネットワーク上のすべてのＰＯＰ５４１〜５４４、５５１〜５５３において特定のファイルがすぐに利用可能であるようにするため、追加の支払いをする用意がある可能性がある。さらに、コンテンツ・プロバイダ２６０は、特定タイプのコンテンツがいくつかのＰＯＰ５４１〜５４４上で利用可能であるが、別のＰＯＰ５４１〜５４４上ではそうではないことを望むことがある。国際コンテンツ・プロバイダ２６０が、例えば、中間ＰＯＰ５４１〜５４４が維持されている国（したがって、中間ＰＯＰ５４１〜５４４は、その国内のユーザにコンテンツを供給する）に応じて、異なる中間ＰＯＰ５４１〜５４４サイトにおいて異なる言語で同一の基礎のＷｅｂページが利用可能であることを望む可能性がある。したがって、自動車製造業者が、フランス国内のＰＯＰに自らのＷｅｂページのフランス語バージョンがプッシュされることを望み、またドイツ国内のＰＯＰにドイツ語バージョンがプッシュされることを望むであろう。この実施形態におけるＣＤＭ５２０は、各コンテンツ・プロバイダ２６０の特定のニーズを満たす必要に応じてコンテンツを伝送するように構成することができる。一実施形態では、ＣＤＭ５２０は、データベース５３０の中でファイルにマークが付けられている仕方に基づき（例えば、ファイルは、そのファイルが複製されるべき有効な１組のＰＯＰを示すことが可能である）、どこに指定されたファイルがコピーされる必要があるかを判定する。
【００４３】
ファイル・キャッシング
一実施形態では、エッジＰＯＰ５５１〜５５３は、最も頻繁に要求されるメディア・コンテンツを記憶するためのキャッシュ・ファイル・サーバとして扱われる。一実施形態におけるＣＤＭは、強制キャッシングとデマンド・ベースのキャッシングの両方を使用して、エッジＰＯＰ５５１〜５５３にコンテンツをキャッシュする。
【００４４】
強制キャッシング・プロトコルの下で、ＣＤＭは、特定のエッジＰＯＰサイト５５１〜５５３に高いデマンドが生じるファイルを特定し（例えば、データベース５３０にクエリすることにより）、これに応答して、そのファイルをそれらのサイトにプッシュする。あるいは、またはさらには、コンテンツ・プロバイダは、ＣＤＭが特定の一群のファイルをキャッシングすべきＰＯＰサイト５５１〜５５３を指定することができる。コンテンツ・プロバイダがファイルのキャッシングを行うためにエッジＰＯＰサイト５５１〜５５３を指定する能力は、そのコンテンツ・プロバイダによって加入されたサービスのレベルに基づくことが可能である（中間ＰＯＰサイトに関連して説明したとおり）。
【００４５】
次に、図７に関連して、デマンド・ベースのキャッシングを使用するシステムを説明する。一実施形態では、特定のインターネット・サイト上に記憶されたコンテンツ（例えば、Ｗｅｂページ、ストリーミング・マルチメディア・ファイル．．．等）をユーザ７０５が要求したとき、その要求がロード・バランサ・モジュール（「ＬＢＭ」）７１０によって受信され、ＬＢＭ７１０が、その要求を扱うのに最も適したエッジＰＯＰサイト５０７を特定する。一実施形態におけるＬＢＭ７１０は、データ・センタにおいて存在するモジュールである（例えば、Ｗｅｂサーバ上で実行される）。ＬＢＭ７１０が「最も適している」として特定するものは、ＬＢＭ７１０に適用されている特定のロード・バランサ・ポリシー７７０に依存する。ポリシー７７０は、いくつかを挙げると、ネットワーク・ロード、エッジＰＯＰ５０７サーバ・ロード、コンテンツを要求したユーザの場所、および／またはエッジＰＯＰ５０７サーバの場所などのキャッシング／ネットワーク変数を考慮に入れることが可能である。
【００４６】
一実施形態では、ＬＢＭ７１０は、最も適切なエッジＰＯＰ５０７を探し出し、中央データベース５３０にクエリすることにより（すなわち、一実施形態におけるデータベース５３０は、システム全体のどこに正確にコンテンツが配信されているかを記録に留める）、エッジＰＯＰ５０７においてそのコンテンツが利用可能であるかどうかを判定する。要求されたコンテンツは、エッジＰＯＰ５０７で利用可能である場合、ユーザ７０５に伝送される。しかし、エッジＰＯＰ５０７でそのコンテンツが利用可能ではない場合には、ＬＢＭ７１０は、第２の最も適切なＰＯＰ（例えば、図示する実施形態における中間ＰＯＰ５０６）にその要求を転送し、この第２の最も適切なＰＯＰが、そのコンテンツをユーザ７０５に伝送する。
【００４７】
ＬＭＢ７１０は、要求されたコンテンツがエッジＰＯＰ５０７で利用可能でなかったこと（すなわち、キャッシュ「ミス」が生じたこと）をＣＤＭ５２０に通知する。ＣＤＭ５２０は、特定のエッジＰＯＰサイト５０７が、将来のユーザ要求に対して利用可能であるように要求されたコンテンツのコピーをキャッシュすべきかどうかを判定する。ＣＤＭは、エッジＰＯＰ５０７上でコピーが維持されるべきであると判定した場合、エッジＰＯＰ５０７に対する基礎のファイル転送を実行するＦＴＳ５２５に転送要求メッセージを送信する。
【００４８】
コピーがキャッシュされるべきかどうかに関するＣＤＭ２５０による判定は、適用されている特定のキャッシング・ポリシー７６０に基づく。本システムの一実施形態では、キャッシング・ポリシーは、ある期間にわたってエッジＰＯＰ５０７から特定のファイルが要求された回数を考慮に入れる。しきい値が達せられると（例えば、１時間以内に１０の要求）、ＣＤＭ５２０は、ＦＴＳ５２５にそのファイルのコピーを転送させる。
【００４９】
キャッシング・ポリシー７６０において考慮に入れることができるその他の変数には、いくつかを挙げると、要求されたファイルがキャッシュ不可能であるかどうか（例えば、ユーザ認証を必要とするファイル、または動的に変化するコンテンツ）、エッジＰＯＰ５０７における記憶容量、要求されたファイルのサイズ、ネットワーク輻輳および／またはサーバ輻輳、および特定のコンテンツ・プロバイダ２６０によって加入されたサービスのレベルが含まれる。以上の変数のいずれかが単独で、または組み合わせでＣＤＭ５２０によって使用して、キャッシュ判定を下すことが可能である。
【００５０】
次に、図８の流れ図に関連して、デマンド・ベースのキャッシングを使用する方法の一実施形態を説明する。８１０で、ユーザがコンテンツの要求を行う。これに応答して、ＬＢＭ７１０が、要求されたコンテンツの伝送元として最も適切なエッジＰＯＰサイトを特定する（例えば、データ・センタにおける中央データベースにクエリすることにより）。要求されたコンテンツが８３０で判定されたエッジＰＯＰサーバで利用可能である場合には、ＬＢＭ７１０は、ユーザをそのエッジＰＯＰサーバに誘導し（例えば、そのサーバのＵＲＬをユーザに伝送することにより）、８３５で、そのコンテンツがユーザに伝送される。
【００５１】
しかし、そのコンテンツが利用可能でなかった場合には、８４０で、ＬＢＭが、そのコンテンツの伝送元として最も適切な中間ＰＯＰサーバを特定する（例えば、データベースにクエリすることにより）。８５０で、その中間ＰＯＰサーバがコンテンツをユーザに伝送し、８６０で、ＬＢＭ７１０がＣＤＭ５２０に通知を行う。８７０で、実施されている特定のキャッシング・ポリシーに基づき、要求されたコンテンツのコピーがそのエッジＰＯＰサイトにおいてローカルで記憶されるべきかどうかをＣＤＭが判定する。その判定が、エッジＰＯＰサイトにおいてコンテンツをキャッシュすることである場合には、８８０で、そのコンテンツがそのエッジＰＯＰサイトに転送され、これに応じてデータベースが更新される。
【００５２】
図１６に示すとおり、一実施形態は、頻繁に要求されるストリーミング・コンテンツをＩ−ＰＯＰ２３１および／またはＥ−ＰＯＰにおいてキャッシュするための機構を設けている。特定のオーディオ／ビデオ・ストリーミング・ファイルをキャッシュするかどうかは、そのファイルに対する予期される、かつ／または実際のデマンドに基づく。例えば、所定の期間内にあるＥ−ＰＯＰ２４１においてある回数（例えば、１時間以内に１０回）、特定のファイルが要求された場合には、データ・センタ２２０におけるキャッシュ・サーバ１６１０（コンテンツ記憶デバイス５３１からファイルのサブセットを受け取る）から、Ｅ−ＰＯＰ２４１におけるローカル・キャッシュ・デバイス１６４０にそのファイルを伝送することが可能である。一実施形態では、ＰＯＰサイトの１つまたは複数においてファイルがキャッシュに入れられた、または削除されたとき、その変更を反映するようにデータベース５３０が更新される。
【００５３】
次に、図１３に関連して、マルチメディア・ファイルを配信し、ストリーミングするための本システムおよび本方法の１つの特定の実施形態を説明する。この例においてエッジＰＯＰ５０７を介してインターネットに接続されたビューア１３１０が、オンデマンド・ファイルをストリーミングする要求を行う。このファイルは、ＩＥＳデータベース１３２０の中で「ＦｉｌｅＩｎｆｏ」レコードによってリファレンスが行われ、そのレコードに対するＩＤが、データ・センタ５０５におけるＷｅｂサーバ１３２５にアクセスするためにビューアがクリックするＵＲＬの中にパラメータとして含まれている。この実施形態におけるＷｅｂサーバ１３２５は、ストリーミング・モジュール（例えば、Ｗｅｂページ；Ｗｉｎｄｏｗｓ ９８（商標）の場合、「ｓｔｒｅａｍ．ａｓｐ」）１３３５を起動してその要求を処理する。ストリーミング・モジュール１３３５は、所望のファイルに至るストリーミング・サーバ・パスを含むメタファイル（例えば、Ｒｅａｌ Ｇ２ ＲＡＭメタファイル、またはＷＭＴ ＡＳＸメタファイル）を構築する。ストリーミング・モジュール１３３５は、ストリーム・リダイレクタ１３４０を呼び出してこのパスを決定する。このパスは、ＵＲＬからのＦｉｌｅＩｎｆｏ ＩＤおよびビューアのＩＰアドレスを通る。
【００５４】
一実施形態におけるストリーム・リダイレクタ１３４０は、Ｗｅｂサーバ１３２５上で実行されるｏｕｔ−ｏｆ−ｐｒｏｃ ＣＯＭサーバである。オンデマンド・ファイルに至るストリーミング・サーバ・パスを作成するようにストリーミング・モジュール１３３５によって呼び出されたとき、リダイレクタ１３４０は、まず、データベース１３２０から以前に収集したサイトＩＰマスクのリストに照らしてビューア１３１０のＩＰアドレスを調べる。図示する実施形態では、リダイレクタ１３４０は、マッチを探し出し、ビューア１３１０の接続元であるエッジＰＯＰサイト５０７を正しく識別する。リダイレクタ１３４０は、データベース１３２０を調べて（例えば、データベースＡＰＩを使用して）、ビューアのエッジＰＯＰサイト５０７に所望のファイルが存在するかどうかを判定する。リダイレクタ１３４０は、ＵＲＬからのＦｉｌｅＩｎｆｏ ＩＤを使用してそのサイト５０７にマッチするＦｉｌｅＬｏｃａｔｉｏｎレコードを見つけた場合、エッジＰＯＰサイト５０７と同じ場所に配置されたメディア・サーバ１３４５にビューアを転送するストリーミング・パスを戻す。リダイレクタ１３４０は、エッジＰＯＰサイト５０７にそのファイルがなかった（すなわち、キャッシュ「ミス」となった）場合、代わりに、そのファイルがあることが分かっている中間ＰＯＰサイト５０６のどれかにビューアを転送するパスを生成する。
【００５５】
リダイレクタ１３４０は、中間ＰＯＰ５０６パスをストリーミング・モジュール１３３５に戻した後、コンテンツ配信サブシステム１３５５がファイルのコピーをエッジＰＯＰサイト５０７に伝送することを要求する。あるいは、一実施形態では、リダイレクタ１３４０は、要求されたコンテンツがエッジＰＯＰサイト５０７に存在しなかったことを単にコンテンツ配信サブシステム１３５５に通知し、コンテンツ配信サブシステム１３５５がコピーがエッジ・サイト５０７に記憶されるべきかどうかについて判断できるようにする（例えば、コンテンツ配信ポリシーに基づき）。次に、ＣＤＭが、後の処理のためにジョブが待ち行列に入れられるＦＴＳにその要求を転送する。
【００５６】
リダイレクタ１３４０が中間ＰＯＰ転送パスをストリーミング・モジュール１３３５に戻し、モジュール１３３５はその転送パスをメタファイルに挿入して、ビューア１３１０のブラウザに戻する。ビューア１３１０のブラウザは、このメタファイルを受け取り、それをストリーミング・プレーヤ（例えば、ＲｅａｌＰｌａｙｅｒ（登録商標）、Ｗｉｎｄｏｗｓ ＭｅｄｉａＰｌａｙｅｒ（登録商標）．．．等）に渡す。プレーヤは転送パスに関してメタファイルを構文解析し、指定された中間ＰＯＰ５０６におけるメディア・サーバに対する接続を確立し、オンデマンド・ファイルのストリーミングを開始する。
【００５７】
ＦＴＳは、ファイルをエッジＰＯＰサイト５０７に転送するために（例えば、そのサイトに対するプライベート接続が存在する場合、Ｗｉｎ３２ファイルを介して、あるいは、インターネットがデータ・センタからそのサイトに至る唯一のパスである場合、インターネットを介するＦＴＰを介して）ジョブを処理する。一実施形態におけるＦＴＳは、ネットワーク内のどのサーバ上で実行されてもよい。したがって、ＦＴＳのインスタンスは中間ＰＯＰ５０６に存在し、中間ＰＯＰ５０６からエッジＰＯＰ５０７へのコピーを開始することで、データ・センタ５０５から延びるプライベート接続の帯域幅を節約することが可能である。エッジＰＯＰ５０７のストーレッジに対するファイル・コピーが正常に完了したとき、ＦｉｌｅＩｎｆｏレコードとエッジＰＯＰサイト５０７レコードを関連付ける「ＦｉｌｅＬｏｃａｔｉｏｎ」データベース・レコードをＦＴＳが作成する。
【００５８】
次回に、このエッジＰＯＰ５０７を介して接続するこのビューア１３１０または別のビューアが、同じファイルをストリーミングしようとしたとき、そのファイルは、エッジＰＯＰサイト５０７におけるメディア・サーバ１３４５（例えば、ＩＳＰのＬＡＮに接続された）から直接にストリーミングされる。作成されたＦｉｌｅＬｏｃａｔｉｏｎデータベース・レコードにより、リダイレクタ１３４０が、ビューア１３１０にサービスを提供するより最適なＩＳＰサイトを選択することができるようになる。様々な構成要素の間のタイミングは、システムの要求に応じて異なるが、それでも一般的概念は当てはまることに留意されたい。
【００５９】
記憶スペース管理
図５を再び参照すると、一実施形態では、ＣＤＭ５２０が、中央データベース５３０の中に記憶されたファイル・アクセス・データ（例えば、いつ、またどれだけ頻繁に特定のファイルがエッジＰＯＰにおいて要求されたかを示すデータ）を使用して、すべてのエッジ・ファイル・サーバ上のキャッシュ・スペースを管理するポリシーを実施する。比較的低い頻度で要求されたファイル、および／または他のファイルと比べて比較的長い期間にわたって要求されていないファイルに、エッジＰＯＰからＴＢＤのマークを付けることができる（すなわち、「最低使用頻度」アルゴリズム、および「最終アクセス時刻」アルゴリズムをそれぞれ使用して）。また、ファイル失効日をデータベースに含め（例えば、「ファイルＸは、１／１５／００後、失効する」）、これがＣＤＭ５２０によって使用されてキャッシュ管理機能が行われることが可能である。
【００６０】
一実施形態では、各エッジＰＯＰ５５１〜５５３は、データベース５３０の中に記憶された高いしきい値および低いしきい値に関連している。高いしきい値は、ＣＤＭ５２０がファイル除去オペレーションを起動するには、エッジ・サーバ記憶デバイスがどれだけ満たされていなければならないかを示すパーセンテージである。低いしきい値は、ＣＤＭがそのファイル除去機能を完了したとき、エッジ・サーバ記憶デバイスがどれだけ満たされているかを示すパーセンテージである。
【００６１】
例えば、特定のエッジＰＯＰ５５１に関する高いしきい値が８０％である場合、そのサイトにおけるストーレッジが８０％に達したとき、高いしきい値フラグがデータベース５３０上で設定される。これに応答して、しきい値データに関して定期的にデータベース５３０にクエリするＣＤＭ５２０が、前述したキャッシュ管理ポリシーの１つまたは複数を使用してサイトからファイルを除去するようにＦＴＳ５２５に命令する。そのサイトに関して低いしきい値が６０％に設定されている場合には、ＣＤＭ５２０は、サイトのストーレッジがその容量の６０％に達するまでファイルを削除するようにＦＴＳ５２５に命令する。この仕方で低いしきい値を設定することにより、ファイル・サーバが高いしきい値に達した後も絶え間なくファイル除去オペレーションが実行されることが防止される。
【００６２】
フォールト・トレランス
次に、図９に関連して、フォールト・トレラント機能を使用する本システムの一実施形態を説明する。以前は、複数のファイルサーバが所与のＰＯＰに存在している場合、コンテンツは、コンテンツ・ソースからＰＯＰサイトにおけるそれぞれの個々のファイルサーバに転送されていた。このやり方で同一のファイルの複数のコピーを転送することは、特にマルチメディア・ファイル（一般に極めて大きい）に関して非効率的で、費用が高くつく傾向がある。各サイトにおいて単一のファイルサーバを維持することにより、ネットワーク・トラフィックおよびサーバ・トラフィックの増大の問題が解決されるが、信頼性の問題が生じる（すなわち、そのファイルサーバに障害が起きた場合、サイト全体が利用不可能になる）。
【００６３】
本発明の一実施形態は、１次サーバ９１０、９２０、および９３０がそれぞれ不在である場合にアクティブにされるバックアップ・ファイルサーバ９１１〜９１３、９２１〜９２２、および９３１を設けることにより、以上の問題のすべてを解決する。ファイル転送エージェント（以降、「ＦＴＡ」）と呼ばれるモジュールが、様々なサイトにおいてすべてのファイルサーバ９１０〜９１３、９２０〜９２２、および９３０〜９３１上で実行され、マスタＦＴＡ、またはスレーブＦＴＡとして構成されていることが可能である。マスタＦＴＡファイルサーバ９１０、９２０、９３０は、システムの残りの部分と（例えば、ネットワーク２１０を介してデータ・センタ２２１と）ファイルの送受信を行い、他方、スレーブＦＴＡファイルサーバ９１１〜９１３、９２１〜９２２、および９３１は、それぞれマスタＦＴＡファイルサーバ９１０、９２０、および９３０からファイルを受信するだけである。
【００６４】
各ファイルサーバ・クラスタの中のマスタ／スレーブＦＴＡ指定が、手動で構成され、かつ／またはプロトコルを介して交渉される。ＰＯＰ９００、９０１のそれぞれ、およびデータ・センタ２２１における各マスタＦＴＡおよびスレーブＦＴＡを識別する情報がデータベース５３０の中に記憶される。特定のサイト９００にファイルが転送されたとき（例えば、ＦＴＳファイル転送コマンドを介して）、データ・センタ２２１におけるマスタＦＴＡ９３０が、そのサイトにおけるマスタＦＴＡファイルサーバ９１０をルックアップする（例えば、データベース５３０のクエリを介して）。データ・センタ２２１における送信元マスタＦＴＡファイルサーバ９３０が、ＰＯＰサイト９００における宛先マスタＦＴＡファイルサーバ９１０にファイルを転送する。次に、宛先マスタＦＴＡ９１０が、そのコンテンツをクラスタ内の残りのファイルサーバ９１１〜９１３に転送することを担う。一実施形態では、ＦＴＡは、本明細書で説明するコンテンツ配信サブシステム（すなわち、ＣＤＭ／ＦＴＳ）の一部分を含む。
【００６５】
同様に、マスタＦＴＡファイルサーバ９１０からファイルが削除されたとき、そのマスタＦＴＡは、スレーブ・ファイルサーバ９１１〜９１３からファイルを削除することを担う。このようにして、マスタＦＴＡファイルサーバ９１０に対するあらゆる変更が、クラスタの中のその他の２次ファイルサーバ９１１〜９１２に反映される。一実施形態では、この同期は、マスタＦＴＡファイルサーバ上のあらゆる変更を検出し、次にその他のファイルサーバを自動的に更新するデーモンを使用して実行される。
【００６６】
マスタＦＴＡファイルサーバ９１０がダウンした場合、ファイルサーバ・クラスタの中のスレーブＦＴＡファイルサーバ（例えば、９１１）のどれかがプロトコル交渉を介してマスタＦＴＡになる。一実施形態では、スレーブＦＴＡファイルサーバ９１１〜９１３の１つまたは複数がマスタＦＴＡファイルサーバ９１０にステータス要求を定期的に送信してマスタがアクティブであることを確実にするキープ・アライブ・プロトコルが実施される。所定回数の要求の後、マスタＦＴＡから応答が受信されなかった（マスタがダウンしていることを示し）場合には、スレーブＦＴＡファイルサーバ９１１〜９１２のどれかが、新しいマスタＦＴＡになる。一実施形態では、自動マスタ／スレッド指定が、ランダムに実行され、各ＦＴＡが、乱数を発生させ、最大の乱数を有するＦＴＡが新しいマスタになるように指定される。
【００６７】
誤り処理および回復
１日ヒット数千のファイルがＣＤＭ５２０によって処理される可能性がある。このため、堅固な自動化された誤り処理−回復設計が、エンド・ユーザ２５０に対するサービスの高品質を確実にするのに有益である。ネットワーク障害は、例えば、宛先サイトが利用不可能であること（例えば、サーバがダウンしているため）、極度のネットワーク輻輳、ネットワーク通信チャネルが利用不可能であること、および様々なタイプのソフトウェアの誤りを含め、いくつかの可能な原因を有する可能性がある。次に図１０および１１に関連して説明する本システムの一実施形態では、ＣＤＭが、ネットワーク障害を自動的に検出し、分析し、訂正しようとする。
【００６８】
１０００で（図１０）、ＦＴＳ５２５が、ＣＤＭ５２０要求メッセージに応答して、ファイル・オペレーション（例えば、ファイル転送および／またはファイル削除）を行おうと試みる。そのオペレーションが正常に行われた場合（１０１０で判定される）には、ＦＴＳ５２５が、その変更を反映するようにデータベース５３０を更新し、行われるべき次のファイル・オペレーションに進む。しかし、ＦＴＳ５２５は、要求されたオペレーションを実行できなかった場合には、その誤りをデータベース５３０上の誤り待ち行列１１００の中にログ記録する（１０２０で）。誤り待ち行列１１００の中の各エントリは、障害をもたらした要求メッセージ・オペレーション（例えば、図１１のファイル転送１１０８〜１１１１、１１７６〜１１７７、１１９０、およびファイル削除１１２５）、ならびにその障害の理由を示す誤りコード（例えば、図１１の誤りコード７、１０、および３）を含む。
【００６９】
ＣＤＭ１１２０の誤り分析部分が、定期的に誤りに関してデータベース５３０にクエリを行い（１０３０で）、回復ポリシー１１１０に基づく適切な誤り回復手続きを決定する。回復ポリシー１１１０は、データ・センタ・オペレーションズ・スタッフ５１５（図５参照）によって提供されるネットワーク特有の手続きと汎用の手続きの両方を含むことが可能である。例えば、宛先ＰＯＰが、既知の期間（例えば、午後８：００から午後１１：００まで）、ダウンしていた場合、オペレーションズ・スタッフ５１５は、このネットワーク特有の情報を回復ポリシー１１１０に含めることができる。ＣＤＭ５２０は、指定された期間中、このＰＯＰに向けられたファイル・オペレーション誤りを受信した場合、１０４０で、こられの誤りが回復可能な誤りであることを認識し（すなわち、宛先ＰＯＰがもはやダウンしていないと想定すると）、誤り回復プロセス１０５０を開始する（例えば、ＣＤＭ５２０は、ファイル転送オペレーションを再試行するようにＦＴＳ５２５に指示する）。
【００７０】
また、回復ポリシー１１１０は、汎用回復手続きを含むことも可能である。例えば、失敗したファイル・オペレーションがＦＴＳによって一回試みられている場合、ＣＤＭ５２０は、再び試みるようにＦＴＳ５２５に指示する（すなわち、その障害が、一時的なネットワーク不具合の結果であったと想定すると）。所定回数の試行の後、障害が続く場合、ＣＤＭ５２０は、回復が可能ではないと判定し、オペレーションズ・スタッフ５１５によって点検される報告書を生成する（１０６０で）ことが可能である。
【００７１】
一実施形態では、ＣＤＭ５２０は、生じた誤りの特定のタイプおよび／または前の試行の回数に基づき、回復を試みる１０５０かどうかを判定する。例えば、誤りが、ファイルがデータ・センタ２２１において利用可能でなかったことに起因していた場合には、ＣＤＭ５２０は、回復が可能でないことを即時に認識することができ、それを示す報告書を生成する１０６０。しかし、誤りがネットワーク輻輳に起因していた場合には、ＣＤＭ５２０は、その誤りを訂正する試行を数回行ってから（すなわち、ＣＤＭ５２０は、ファイル・オペレーションを数回試みるようにＦＴＳ５２５に指示することが可能である）、回復が可能でないと判定し、報告書を生成する１０６０。
【００７２】
また、ＣＤＭ５２０は、ある期間にわたって同一のＰＯＰに向けられた特定タイプの誤りの連続回数に基づいて回復可能な誤りを認識することも可能である。例えば、特定のＰＯＰに向けられた連続するファイル転送オペレーション（例えば、ファイル転送１１０８〜１１１１）が、５分間にわたって失敗した場合、ＣＤＭ５２０は、これが、この期間中、ＰＯＰがダウンしていたことを意味するものと自動的に解釈することができる（オペレーションズ・スタッフ５１５が、この情報を回復ポリシーに手動で含める前述した実施形態とは対照的に）。したがって、ＰＯＰが、現時点でオンライン状態にあり、ファイル転送を受け入れている場合、ＣＤＭ５２０は、ファイル転送および／またはファイル削除を再試行するようにＦＴＳ５２５に指示することができる。本発明の基礎となる原理に適合する追加の誤り検出機構および誤り訂正機構を実行することも可能である。
【００７３】
仮想インターネット・プロトコル・アドレスを使用するロード平衡化
特に、マルチメディア・コンテンツのライブまたはオンデマンドのストリーミングなどの高帯域幅の用途に関して、アプリケーション・サービスを提供するのに単一のサーバでは十分でない。図１２を参照すると、そのような状況では、アプリケーション・サービス・デマンドは、リソースのプール、例えば、所与のアプリケーション・サービス１２２０および１２３０をそれぞれサポートするサーバ１２２１〜１２２３および１２３１〜１２３２を利用できるようにすることによって満たされる。図示する実施形態では、どの単一のサーバも、過ロードにならず、アプリケーション・サービス１２２０、１２３０が中断なしに行われるようにロード平衡化が行われる。
【００７４】
レイヤ４スイッチ１２００が、サービスに関連する仮想ＩＰアドレス（「ＶＩＰ」）に基づいてクライアント１２５０〜１２５２によって要求されているサービスの特定のタイプを識別し、その要求をそのサービスに割り当てられたサーバ・プール内の特定のサーバ（例えば、１２２１）に向けることにより、前述の用件をサポートする。例えば、アプリケーション・サービス１２２０が、すべての着信するＷｅｂページ（すなわち、ハイパーテキスト・トランスポート・プロトコル）要求を扱うように構成されている場合には、ＷｅｂページをダウンロードするようにＶＩＰ１２０２に接続しているクライアントが、レイヤ４スイッチ１２００によってＶＩＰ１２０２背後の特定のサーバに転送される。
【００７５】
通常のロード平衡化の構成では、静的なグループのサーバが、アプリケーション・サービス・プールに割り当てられる。本システムの一実施形態では、最適なリソース割振りおよびフォールト・トレランスのために動的に構成可能なサーバ・プール１２２１〜１２２３、１２３１〜１２３２を使用して、複数のアプリケーション・サービスが実施される。より具体的には、この実施形態により、図１２に示すとおり、あるアプリケーション・サービス１２３０に割り当てられたサーバ（例えば、１２２１）が、そのサービスに対するデマンド、および／またはそのサービスに関する現在のロードに基づいて動的に割当て変更されることが可能になる。
【００７６】
例えば、所与の時点で、ライブまたはオンデマンドのストリーミング・イベントが、相当な量のサーバ・リソースを必要とする場合には、そのデマンドを予期して、ストリーミングではないサーバのプールからサーバ１２２１をストリーミング・サーバ１２３１〜１２３２のプールに移動させることができる。これは、自動的に行われること、またはオペレーションズ・スタッフ５１５によって手動で行われることが可能であり、また構成に応じて、割振り変更が行われたサーバをリブートする必要がある可能性がある。
【００７７】
一実施形態では、サーバ割振り変更機構は、ネットワークにおける変更に動的に応答する（そのような変更を予期してではなく）。したがって、特定のアプリケーション・サービス１２３０のために予約されたサーバのプール（例えば、１２３１、１２３２）が、サービス要求の相当な増大を突然に経験した場合、第２のアプリケーション・サービス（例えば、１２２０）に割り当てられたサーバ１２２１が、第１のアプリケーション・サービス１２３０に動的に割当て変更されて、（第２のサービス１２２０もまた、重いネットワーク・ロードを経験しているのではないと想定すると）そのロードのいくらかを扱うことが可能である。一実施形態では、バックグラウンドで実行されるモニタ・モジュールが、異なるアプリケーション・サービスにわたるサーバ・ロードを把握している。あるサービスをサポートしているサーバが過ロードになったとき、モニタ・モジュールは、それほどアクティブでないアプリケーション・サービスから１つまたは複数のサーバの割当て変更を行おうと試みる。
【００７８】
一実施形態では、それほどアクティブでないアプリケーション・サービスのそれぞれのロードが比較され、最低の平均サーバ・ロードを有するアプリケーション・サービスからサーバが選択される。別の実施形態では、予期されるサーバ・ロードも割当て変更の判定の考慮に入れられる。したがって、特定のアプリケーション・サービスが低いサーバ・ロードを経験していても、将来にそのアプリケーション・サービスに重いロードがかかることが予期される場合（例えば、そのアプリケーション・サービスが、盛んに宣伝され、スケジュール設定されたストリーミング・イベントをサポートするのに使用される場合）、そのアプリケーション・サービスからサーバが除去されることはない。
【００７９】
一実施形態では、様々なアプリケーション・サービス・グループ１２３０、１２２０内の各サーバを監視するロード検出−制御論理１２５０（例えば、レイヤ４スイッチ１２００上に、あるいは別のネットワーク・デバイス内部に構成された）を介して動的なサーバ割当て変更が実行される。一実施形態では、サーバおよび／またはアプリケーション・サービス・グループ１２３０、１２２０に関して、高いロードしきい値および低いロードしきい値を設定することができる。一実施形態では、あるグループ内のサーバ上のロードが高いしきい値に達したとき、ロード検出−制御論理１２５０は、別のアプリケーション・グループ（例えば、アプリケーション・グループ１２２０）からのサーバ（例えば、１２２１）を、そのサーバ（またはそのサーバのアプリケーション・サービス・グループ）の現在のロードが低いしきい値より低い場合にだけ、割当て変更しようと試みる。
【００８０】
本発明の実施形態は、前述した様々なステップを含む。このステップは、マシン実行可能命令で実現することが可能である。この命令を使用して、汎用プロセッサまたは専用プロセッサがあるステップを行うようにさせることができる。あるいは、これらのステップは、そのステップを行うためのハードワイヤド論理を含む特定のハードウェア構成要素によって、またはプログラミングされたコンピュータ構成要素とカスタム・ハードウェア構成要素の任意の組み合わせによって実行できる。
【００８１】
本発明の要素は、マシン実行可能命令を記憶するためのマシン可読媒体として提供することが可能である。マシン可読媒体には、フロッピー（登録商標）・ディスク、光ディスク、ＣＤ−ＲＯＭ、および光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、伝播媒体、または電子命令を記憶するのに適したその他のタイプの媒体／マシン可読媒体を含むことが可能であるが、以上には限定されない。例えば、本発明は、通信リンク（例えば、モデム接続またはネットワーク接続）を介する搬送波またはその他の伝播媒体で実現されたデータ信号を介して、遠隔コンピュータ（例えば、サーバ）から要求を行うコンピュータ（例えば、クライアント）に転送することが可能なコンピュータ・プログラムとしてダウンロードすることが可能である。
【００８２】
説明のため、以上の説明全体にわたり、本発明の完全な理解を提供するために多数の特定の詳細を提示した。ただし、これらの特定の詳細のいくつかをなしに本発明を実行できることが、当分野の技術者には明白であろう。したがって、本発明の範囲および趣旨は、頭記の特許請求の範囲で判断されるべきものである。
【図面の簡単な説明】
【図１】 データ・ネットワーク上の従来技術のキャッシング・システムを示す図である。
【図２】 本発明の要素を含む例としてのネットワーク・アーキテクチャを示す図である。
【図３】 本発明の要素を含む例としてのコンピュータ・アーキテクチャを示す図である。
【図４】 本発明の要素を含むネットワーク・アーキテクチャの別の実施形態を示す図である。
【図５】 ネットワーク・コンテンツを配信するためのシステムおよび方法の一実施形態を示す図である。
【図６】 本発明の一実施形態によるファイル要求メッセージを示す図である。
【図７】 ネットワーク・コンテンツがエッジＰＯＰにおいてキャッシュされる本発明の実施形態を示す図である。
【図８】 ネットワーク・コンテンツをキャッシュするための方法の一実施形態を示す図である。
【図９】 フォールト・トレラント機能を含む本発明の一実施形態を示す図である。
【図１０】 誤り検出機能および誤り回復機能を含む本発明の実施形態を示す図である。
【図１１】 誤り検出機能および誤り回復機能を含む本発明の実施形態を示す図である。
【図１２】 本発明の一実施形態による動的なサーバ割振りを示す図である。
【図１３】 ストリーミング・メディアがエッジＰＯＰにおいてキャッシュされる本発明の実施形態を示す図である。
【図１４】 ライブかつ／またはオンデマンドのオーディオ／ビデオ信号を処理するように構成された本発明の一実施形態を示す図である。
【図１５】 オーディオ／ビデオがネットワークを介してエンド・ユーザにストリーミングされる一実施形態を示す図である。
【図１６】 オーディオ／ビデオ・ストリーミング・コンテンツが、１つまたは複数のＰＯＰサイトにおいてキャッシュされる一実施形態を示す図である。
Claims (19)
- デジタル・マルチメディア・ストリーミング・コンテンツを記憶し、かつ配信ポリシーに基づいて自動的にデジタル・マルチメディア・ストリーミング・コンテンツを配信するための複数のサーバから構成され、複数のコンテンツ・レコードを有するデータベースとコンテンツ配信マネジャとをさらに備えるデータ・センタであって、前記コンテンツ配信マネージャは、前記データベースに問い合わせを行い、そして前記問い合わせが前記デジタル・マルチメディア・ストリーミング・コンテンツが複製される必要があることを指示する場合に、前記デジタル・マルチメディア・ストリーミング・コンテンツを自動的に配信する、データ・センタと、
前記データ・センタと通信を行う複数の中間ポイント・オブ・プレゼンス（「ＰＯＰ」）サイトであって、前記複数の中間ＰＯＰサイトの各々は前記データ・センタにて記憶された前記デジタル・マルチメディア・ストリーミング・コンテンツの部分が複製される１つまたは複数のサーバを有する、複数の中間ＰＯＰサイトと、そして
エンド・ユーザおよび前記複数の中間ＰＯＰサイトと通信するための複数のエッジＰＯＰサイトであって、前記複数のエッジＰＯＰサイトの各々は前記エンド・ユーザにより要求された前記デジタル・マルチメディア・ストリーミング・コンテンツの部分をキャッシュするための１つまたは複数のサーバーを有する、複数のエッジＰＯＰサイトと
から構成され、
前記複数のコンテンツ・レコードの各々はデジタル・マルチメディア・ストリーミング・コンテンツと前記複数の中間ＰＯＰの各々とを関連付け、関連付けられた前記デジタル・マルチメディア・ストリーミング・コンテンツは前記複数のエッジＰＯＰサイトにて複製される、
ことを特徴とする配信エッジ・ネットワーク・アーキテクチャ。 - デジタル・マルチメディア・ストリーミング・コンテンツを記憶し、かつ前記複数の中間ＰＯＰサイトと通信するための１つまたは複数の追加のデータ・センタをさらに備えることを特徴とする請求項１に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 中間ＰＯＰの数より多い数のエッジＰＯＰと、データ・センタの数より多い数の中間ＰＯＰを有することを特徴とする請求項１に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 前記複数の中間ＰＯＰと前記データ・センタとの間の通信をサポートする専用プライベート通信チャネルをさらに備えることを特徴とする請求項１に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 前記複数のエッジＰＯＰは、公共ネットワークを介して前記複数の中間ＰＯＰと通信することを特徴とする請求項４に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 前記専用プライベート通信チャネルは、Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ（「ＤＳ」）チャネルであることを特徴とする請求項４に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 前記専用プライベート通信チャネルは、ＤＳ−３チャネルであることを特徴とする請求項６に記載の配信エッジ・ネットワーク・アーキテクチャ。
- 前記データ・センタにはデータ・センタ・オペレーションズ・スタッフが配備されていることを特徴とする請求項１に記載の配信エッジ・ネットワーク・アーキテクチャ。
- １つまたは複数のコンテンツ・プロバイダからマルチメディア・ストリーミング・コンテンツを受信するための１次記憶設備と、
前記１次記憶設備において記憶された前記マルチメディア・ストリーミング・コンテンツの部分がミラーリングされる１つまたは複数のサーバをそれぞれが有する、前記１次記憶設備と通信するように結合された複数の２次記憶設備と、
前記２次記憶設備と通信するように結合され、エンド・ユーザによって要求された前記マルチメディア・ストリーミング・コンテンツの部分をキャッシュするための１つまたは複数のサーバを有する複数の３次記憶設備と、
から構成され、
前記一次記憶設備は複数のコンテンツ・レコードとコンテンツ配信マネジャを備え、前記配信マネジャによりデータベースに問い合わせを行い、前記問い合わせが前記デジタル・マルチメディア・ストリーミング・コンテンツの複製を示す場合、自動的に前記デジタル・マルチメディア・ストリーミング・コンテンツを配信し、
それぞれの前記データベース・コンテンツ・レコードはデジタル・マルチメディア・ストリーミング・コンテンツと前記２次、３次記憶設備のそれぞれの関連を提供し、各記憶設備においてコンテンツが複製される、
ことを特徴とするシステム。 - 前記３次記憶設備は、１つまたは複数のインターネット・サービス・プロバイダと同じ場所に配置されていることを特徴とする請求項９に記載のシステム。
- 前記２次記憶設備は、プライベート専用通信チャネルを介して前記１次記憶設備と通信するように結合されていることを特徴とする請求項９記載のシステム。
- 前記２次記憶設備は、前記インターネットを介して前記３次記憶設備と通信するように結合されていることを特徴とする請求項１１に記載のシステム。
- １つまたは複数のコンテンツ・プロバイダからマルチメディア・ストリーミング・コンテンツを受信するための１次記憶手段と、
前記１次記憶手段と通信するように結合され、前記１次記憶手段において記憶された前記マルチメディア・ストリーミング・コンテンツの部分がミラーリングされる１つまたは複数のサーバを有する２次記憶手段と、
前記２次記憶手段と通信するように結合され、エンド・ユーザによって要求された前記マルチメディア・ストリーミング・コンテンツの部分をキャッシュするための１つまたは複数のサーバを有する３次記憶手段と、
から構成され、
前記一次記憶設備は、複数のコンテンツ・レコードとコンテンツ配信マネジャを備え、前記配信マネジャによりデータベースに問い合わせを行い、前記問い合せが前記デジタル・マルチメディア・ストリーミング・コンテンツの複製を指示する場合、自動的に前記デジタル・マルチメディア・ストリーミング・コンテンツを配信し、
それぞれの前記データベース・コンテンツ・レコードはデジタル・マルチメディア・ストリーミング・コンテンツと前記２次、３次記憶設備のそれぞれの関連を提供し、各前記記憶設備においてコンテンツが複製される、
ことを特徴とするシステム。 - 前記３次記憶手段は、１つまたは複数のインターネット・サービス・プロバイダと同じ場所に配置されていることを特徴とする請求項１３に記載のシステム。
- 前記２次記憶手段は、プライベート専用通信チャネルを介して前記１次記憶手段と通信するように結合されていることを特徴とする請求項９に記載のシステム。
- 前記２次記憶手段は、インターネットを介して前記３次記憶手段と通信するように結合されていることを特徴とする請求項１３に記載のシステム。
- コンピュータ・ネットワーク上でマルチメディア・ストリーミング・コンテンツを配信するための方法であって、
データ・センタにおいて前記マルチメディア・コンテンツを受信するステップと、
前記マルチメディア・ストリーミング・コンテンツを複製するかどうか決定するためにコンテンツ・データベースに問い合わせを行うステップと、
前記問い合わせにより前記デジタル・マルチメディア・ストリーミング・コンテンツを複製するよう指示がある場合、前記データセンタから１つ又は複数の中間ＰＯＰサイトに自動的に前記マルチメディア・ストリーミング・コンテンツを複製するステップと、
前記中間ＰＯＰサイトの１つから１つまたは複数のエッジＰＯＰサイトに、前記マルチメディア・ストリーミング・コンテンツをコピーするステップと、
前記データ・センタに前記マルチメディア・ストリーミング・コンテンツが受信され、前記中間ＰＯＰサイトおよび前記エッジＰＯＰサイトに前記コンテンツがコピーされたときに、前記データ・センタにおけるコンテンツ・データベースを更新するステップと、
から構成され、
前記データベースが前記マルチメディア・ストリーミング・コンテンツがコピーされる前記中間ＰＯＰサイトおよび前記エッジＰＯＰサイトを示す、
ことを特徴とする方法。 - 前記データ・センタで受信された前記マルチメディア・ストリーミング・コンテンツは、コンテンツ・プロバイダから伝送されることを特徴とする請求項１７に記載の方法。
- 前記データ・センタから前記１つまたは複数の中間ＰＯＰへのコピーが、コンテンツ・プロバイダからの入力に応答して行われることを特徴とする請求項１７に記載の方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US53946600A | 2000-03-30 | 2000-03-30 | |
| US09/539,466 | 2000-03-30 | ||
| PCT/US2001/008326 WO2001076192A2 (en) | 2000-03-30 | 2001-03-14 | Method and device for distributed caching |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003529866A JP2003529866A (ja) | 2003-10-07 |
| JP2003529866A5 JP2003529866A5 (ja) | 2008-05-08 |
| JP4845321B2 true JP4845321B2 (ja) | 2011-12-28 |
Family
ID=24151327
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001573743A Expired - Fee Related JP4845321B2 (ja) | 2000-03-30 | 2001-03-14 | 分散エッジ・ネットワーク・アーキテクチャ |
Country Status (10)
| Country | Link |
|---|---|
| EP (1) | EP1269714B1 (ja) |
| JP (1) | JP4845321B2 (ja) |
| CN (1) | CN1309232C (ja) |
| AT (1) | ATE338415T1 (ja) |
| AU (1) | AU2001249211A1 (ja) |
| DE (1) | DE60122691T2 (ja) |
| DK (1) | DK1269714T3 (ja) |
| HK (1) | HK1049417B (ja) |
| TW (1) | TW580814B (ja) |
| WO (1) | WO2001076192A2 (ja) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003288309A (ja) * | 2002-03-27 | 2003-10-10 | Toshiba Corp | メッセージ処理装置、メッセージ処理システム及びメッセージ処理方法 |
| JP2003288291A (ja) * | 2002-03-28 | 2003-10-10 | Ntt Comware Corp | コンテンツ配信システム、コンテンツ配信方法、及びコンテンツ配信プログラム |
| JP2004265397A (ja) * | 2003-02-14 | 2004-09-24 | Masuo Yoshimoto | デジタルコンテンツ配送システム、デジタルコンテンツ配送方法、及びエッジサーバ |
| US20050210121A1 (en) * | 2004-03-22 | 2005-09-22 | Qualcomm Incorporated | Satellite anticipatory bandwith acceleration |
| US7603131B2 (en) * | 2005-08-12 | 2009-10-13 | Sellerbid, Inc. | System and method for providing locally applicable internet content with secure action requests and item condition alerts |
| US20070061282A1 (en) * | 2005-09-14 | 2007-03-15 | Nec Laboratories America, Inc. | Data network information distribution |
| CN101064729B (zh) * | 2006-04-27 | 2010-06-09 | 中国电信股份有限公司 | 通过cdn网络实现ftp下载服务的系统和方法 |
| CN101202749B (zh) * | 2007-11-16 | 2011-12-07 | 华为技术有限公司 | 一种sip网络中处理媒体流请求的方法、系统及装置 |
| US8160063B2 (en) * | 2008-06-09 | 2012-04-17 | Microsoft Corporation | Data center interconnect and traffic engineering |
| US8443370B2 (en) | 2008-08-26 | 2013-05-14 | Microsoft Corporation | Method of assigning resources to fulfill a service request by a programming model abstraction layer at a data center based at least in part on a reference of the requested resource class indicative of an abstract amount of resources |
| CN101499095B (zh) * | 2009-03-11 | 2011-04-27 | 南京联创科技集团股份有限公司 | 用于数据共享平台的构建缓冲的方法 |
| US8874744B2 (en) * | 2010-02-03 | 2014-10-28 | Vmware, Inc. | System and method for automatically optimizing capacity between server clusters |
| US8380931B2 (en) * | 2010-03-12 | 2013-02-19 | Microsoft Corporation | Memory cache data center |
| CN101924785A (zh) * | 2010-04-28 | 2010-12-22 | 华为技术有限公司 | 数据的上传方法、下载方法和系统 |
| CN101841571B (zh) * | 2010-05-24 | 2013-03-20 | 尤建兴 | 数据离散存储方法、数据离散存储装置及数据恢复方法 |
| US8463788B2 (en) * | 2010-09-03 | 2013-06-11 | Marvell World Trade Ltd. | Balancing caching load in a peer-to-peer based network file system |
| US8505057B2 (en) | 2010-10-05 | 2013-08-06 | Concurrent Computers | Demand-based edge caching video content system and method |
| US20120089700A1 (en) * | 2010-10-10 | 2012-04-12 | Contendo, Inc. | Proxy server configured for hierarchical caching and dynamic site acceleration and custom object and associated method |
| KR101175505B1 (ko) * | 2011-10-06 | 2012-08-20 | 한화에스앤씨주식회사 | Ｎ?스크린 환경에서 네트워크 기반 파일 시스템을 이용한 사용자 데이터 저장환경 제공 시스템 |
| US8966643B2 (en) | 2011-10-08 | 2015-02-24 | Broadcom Corporation | Content security in a social network |
| US20130091207A1 (en) * | 2011-10-08 | 2013-04-11 | Broadcom Corporation | Advanced content hosting |
| WO2013082595A1 (en) | 2011-12-01 | 2013-06-06 | Huawei Technologies Co., Ltd. | Systems and methods for connection pooling for video streaming in content delivery networks |
| CN102521405B (zh) * | 2011-12-26 | 2014-06-25 | 中国科学院计算技术研究所 | 支持高速加载的海量结构化数据存储、查询方法和系统 |
| CN102521406B (zh) * | 2011-12-26 | 2014-06-25 | 中国科学院计算技术研究所 | 海量结构化数据复杂查询任务的分布式查询方法和系统 |
| JP2013171337A (ja) | 2012-02-17 | 2013-09-02 | Toshiba Corp | メモリシステムとその試験方法 |
| CN102882977B (zh) * | 2012-10-16 | 2015-09-23 | 北京奇虎科技有限公司 | 网络应用集成系统和方法 |
| CN103179037B (zh) * | 2012-12-13 | 2015-12-09 | 清华大学 | 基于内容的数据中心网络的数据传输方法 |
| JP5642817B2 (ja) * | 2013-02-12 | 2014-12-17 | 日本電信電話株式会社 | 差分更新装置、差分更新システム、差分更新方法、差分更新プログラム及び差分更新サーバ |
| US9635580B2 (en) | 2013-10-08 | 2017-04-25 | Alef Mobitech Inc. | Systems and methods for providing mobility aspects to applications in the cloud |
| US9037646B2 (en) | 2013-10-08 | 2015-05-19 | Alef Mobitech Inc. | System and method of delivering data that provides service differentiation and monetization in mobile data networks |
| CN104869139B (zh) * | 2014-02-25 | 2019-04-16 | 上海帝联信息科技股份有限公司 | 缓存文件更新方法、装置及系统 |
| EP2963871B1 (de) | 2014-06-30 | 2018-10-10 | Deutsche Telekom AG | Effiziente Transportnetz Architektur für Content Delivery Network |
| CN109347925B (zh) * | 2014-12-31 | 2021-07-09 | 华为技术有限公司 | 缓存方法、缓存边缘服务器、缓存核心服务器和缓存系统 |
| CN106230817B (zh) * | 2016-07-29 | 2019-04-02 | 中国电子科技集团公司第二十八研究所 | 分布式海量数据传输方法及系统 |
| CN109815049B (zh) | 2017-11-21 | 2021-03-26 | 北京金山云网络技术有限公司 | 节点宕机恢复方法、装置、电子设备及存储介质 |
| CN109889599B (zh) * | 2019-03-07 | 2020-08-28 | 北京邮电大学 | 一种数据处理方法及系统 |
| FR3099598B1 (fr) | 2019-07-31 | 2021-08-27 | Amadeus | Apprentissage automatique distribué pour la validité des données antémé- morisées |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH086834A (ja) * | 1994-06-17 | 1996-01-12 | Canon Inc | ファイル資源管理システムおよびその方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6119151A (en) * | 1994-03-07 | 2000-09-12 | International Business Machines Corp. | System and method for efficient cache management in a distributed file system |
| ATE252801T1 (de) * | 1997-06-20 | 2003-11-15 | Swisscom Fixnet Ag | System und verfahren zur kodierung und zur aussendung von sprachdaten |
| US6016512A (en) * | 1997-11-20 | 2000-01-18 | Telcordia Technologies, Inc. | Enhanced domain name service using a most frequently used domain names table and a validity code table |
-
2001
- 2001-03-14 DK DK01922404T patent/DK1269714T3/da active
- 2001-03-14 EP EP01922404A patent/EP1269714B1/en not_active Expired - Lifetime
- 2001-03-14 CN CNB01810391XA patent/CN1309232C/zh not_active Expired - Fee Related
- 2001-03-14 JP JP2001573743A patent/JP4845321B2/ja not_active Expired - Fee Related
- 2001-03-14 DE DE60122691T patent/DE60122691T2/de not_active Expired - Fee Related
- 2001-03-14 AU AU2001249211A patent/AU2001249211A1/en not_active Abandoned
- 2001-03-14 AT AT01922404T patent/ATE338415T1/de not_active IP Right Cessation
- 2001-03-14 WO PCT/US2001/008326 patent/WO2001076192A2/en active IP Right Grant
- 2001-03-20 TW TW090106502A patent/TW580814B/zh not_active IP Right Cessation
-
2003
- 2003-02-28 HK HK03101510.6A patent/HK1049417B/zh not_active IP Right Cessation
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH086834A (ja) * | 1994-06-17 | 1996-01-12 | Canon Inc | ファイル資源管理システムおよびその方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| TW580814B (en) | 2004-03-21 |
| WO2001076192A2 (en) | 2001-10-11 |
| CN1432248A (zh) | 2003-07-23 |
| WO2001076192A3 (en) | 2002-02-21 |
| JP2003529866A (ja) | 2003-10-07 |
| ATE338415T1 (de) | 2006-09-15 |
| DE60122691T2 (de) | 2007-10-04 |
| AU2001249211A1 (en) | 2001-10-15 |
| DK1269714T3 (da) | 2007-01-08 |
| EP1269714B1 (en) | 2006-08-30 |
| HK1049417B (zh) | 2007-04-13 |
| HK1049417A1 (en) | 2003-05-09 |
| CN1309232C (zh) | 2007-04-04 |
| DE60122691D1 (de) | 2006-10-12 |
| EP1269714A2 (en) | 2003-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4845321B2 (ja) | 分散エッジ・ネットワーク・アーキテクチャ | |
| US6687846B1 (en) | System and method for error handling and recovery | |
| US7203731B1 (en) | Dynamic replication of files in a network storage system | |
| US7181523B2 (en) | Method and apparatus for managing a plurality of servers in a content delivery network | |
| JP4695759B2 (ja) | 組込型コンテンツ分散ゴースト・サーバを用いたグローバル文書ホスティング・システム | |
| EP1364510B1 (en) | Method and system for managing distributed content and related metadata | |
| US7266555B1 (en) | Methods and apparatus for accessing remote storage through use of a local device | |
| US6952737B1 (en) | Method and apparatus for accessing remote storage in a distributed storage cluster architecture | |
| US7506034B2 (en) | Methods and apparatus for off loading content servers through direct file transfer from a storage center to an end-user | |
| US5956489A (en) | Transaction replication system and method for supporting replicated transaction-based services | |
| US7219153B1 (en) | Methods and apparatus for distributing content | |
| US8914429B2 (en) | Method for creating global distributed namespace | |
| US7428540B1 (en) | Network storage system | |
| US7266556B1 (en) | Failover architecture for a distributed storage system | |
| US7281168B1 (en) | Failover architecture for local devices that access remote storage | |
| JP2004500660A5 (ja) | ||
| EP1368948A2 (en) | Method and apparatus for large payload distribution in a network | |
| US20030055910A1 (en) | Method and apparatus to manage data on a satellite data server | |
| US20060168145A1 (en) | Method for creating a secure and reliable content distribution framework | |
| WO2002003704A1 (en) | System and method for fault tolerant stream splitting | |
| Yeung et al. | Probability based replacement algorithm for www server arrays |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080314 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080314 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20101027 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101124 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110131 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110913 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20111011 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141021 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |