DE60122691T2

DE60122691T2 - Verfahren und vorrichtung zum verteilten cachen

Info

Publication number: DE60122691T2
Application number: DE60122691T
Authority: DE
Inventors: J. Reed Beaverton SLOSS; R. Rama Portland MENON; Pratyush Portland JAISWAL; J. Benjamin Portland VRVILO
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2000-03-30
Filing date: 2001-03-14
Publication date: 2007-10-04
Anticipated expiration: 2021-03-15
Also published as: JP4845321B2; DK1269714T3; WO2001076192A2; ATE338415T1; WO2001076192A3; HK1049417B; HK1049417A1; EP1269714B1; AU2001249211A1; JP2003529866A; EP1269714A2; CN1432248A; CN1309232C; TW580814B; DE60122691D1

Description

STAND DER TECHNIK
Gebiet der Erfindung
Die vorliegende Erfindung betrifft allgemein das Gebiet der Netzwerkdienste. Im Besonderen betrifft die vorliegende Erfindung eine verbesserte Architektur für die Verteilung von Netzwerkdaten.
Beschreibung des Stands der Technik
Ein traditionelles Netzwerk-Caching-System gemäß der Veranschaulichung aus 1 weist eine Mehrzahl von Clients 130-133 auf, die über ein lokales Netzwerk 140 und/oder ein größeres Netz bzw. Netzwerk 110 (z.B. das Internet) kommunizieren. Die Clients 130-133 können eine Browser-Anwendung wie etwa Netscape Navigator oder Microsoft Internet Explorer^TM ausführen, die einen Zugang bzw. Zugriff auf Informationen im World Wide Web („das Web") über das HyperText Transport Protocol („HTTP") oder über andere Netzwerkprotokolle (z.B. das File Transfer Protocol, Gopher, ..., etc.) bereitstellen.
Der Browser auf jedem Client 130-133 kann so konfiguriert werden, dass alle Anforderungen von Informationen (z.B. Webseiten) über einen lokalen Cache-Server 115 übertragen werden, der für gewöhnlich als „Proxy-Cache" bezeichnet wird. Wenn ein Client 130 Informationen von einem entfernten Internet-Server 120 anfordert, überprüft der lokale Proxy-Cache 115 die Anforderung und bestimmt anfänglich, ob der angeforderte Inhalt „Cache-fähig" ist (ein erheblicher Teil der Internet-Inhalte ist „nicht Cache-fähig"). Wenn der lokale Proxy-Cache 115 eine nicht Cache-fähige Anforderung detektiert, leitet er die Anforderung direkt zu der Inhaltsquelle weiter (z.B. dem Internet-Server 120). Der angeforderte Inhalt wird danach direkt von der Quelle 120 zu dem Client 130 übermittelt und nicht lokal in dem Proxy-Cache 115 gespeichert.
Wenn der Proxy-Cache 115 im Gegensatz dazu bestimmt, dass die Anforderung von Inhalten eines Clients 130 Cache-fähig ist, so sucht der Cache nach einer lokalen Kopie des Inhalts (z.B. auf einem lokalen Festplattenlaufwerk). Wenn keine lokale Kopie existiert, so bestimmt der Proxy-Cache 115, ob der Inhalt in einem „übergeordneten" Cache 117 (weiter oben in dem Netzwerk in Bezug auf den Internet-Server 120 angeordnet) oder in einem „untergeordneten" Cache 116 (im Wesentlichen an der gleichen hierarchischen Position angeordnet wie der Proxy-Cache im Verhältnis zu dem Internet-Server 120, von dem der Inhalt angefordert worden ist) gespeichert wird.
Wenn in einem der benachbarten Caches 116, 117 ein „Treffer" detektiert wird, wird der angeforderte Inhalt aus dem Cache abgerufen, zu dem Client 130 übertragen und lokal in dem Proxy-Cache 115 gespeichert, so dass er für zukünftige Anforderungen durch andere lokale Clients 131-133 zur Verfügung steht. Wenn der Cache „verfehlt" wird (englisch: „Cache-Miss"), wird der Inhalt von dem Quellen-Internet-Server 120 abgerufen, zu dem Client 130 übertragen und eine Kopie wird lokal in dem Proxy-Cache 115 und möglicher Weise auch in dem übergeordneten Cache 117 gespeichert, so dass er für zukünftige Client-Anforderungen zur Verfügung steht.
Das U.S. Patent US-A-6.016.512 offenbart ein Domänen-Namensystem, das die am häufigsten verwendeten Domänennamen und zugeordneten Domänenadressen vorab erfasst (prefetch), in der Erwartung der Notwendigkeit, eine IP-Adresse bereitzustellen, welche einem der vorab erfassten Domänennamen entspricht. Dieser Betriebsmodus wurde aufgrund der drastischen Größenzunahme des Internet und der zugeordneten Latenz bezüglich der Auflösung von Domänennamen-Anforderungen eingesetzt.
„Improving the WWW: caching or multicast" von P. Rodriguez, et al., Computer Networks and ISDN Systems, North Holland Publishing, Amsterdam, Niederlande, Band 30, Nummer 22-23, 25. November 1998, Seiten 2223-2243, offenbart ein System zur Reduzierung der Web-Latenz unter Verwendung eines hierarchischen Caching-Systems, bei dem Daten den Caches zugeführt werden können.
Die vorliegende Erfindung betrifft ein Datenzentrum gemäß dem gegenständlichen Anspruch 1, ein Verfahren gemäß dem gegenständlichen Anspruch 7, ein Computerprogramm gemäß dem gegenständlichen Anspruch 9 und einen Computerspeicher gemäß dem gegenständlichen Anspruch 10. Bevorzugte Ausführungsbeispiele sind in den Unteransprüchen ausgeführt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird aus der folgenden genauen Beschreibung in Bezug auf die beigefügten Zeichnungen besser verständlich. In den Zeichnungen zeigen:
1 ein dem Stand der Technik entsprechendes Caching-System in einem Datennetzwerk;
2 ein Beispiel für eine Netzwerkarchitektur mit Elementen gemäß der vorliegenden Erfindung;
3 ein Beispiel für eine Computerarchitektur mit Elementen gemäß der vorliegenden Erfindung;
4 ein weiteres Ausführungsbeispiel für eine Netzwerkarchitektur mit Elementen gemäß der vorliegenden Erfindung;
5 ein Ausführungsbeispiel des Systems und Verfahrens zum Verteilen von Netzwerkinhalten;
6 eine Datei Anforderungsnachricht gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
7 weitere Ausführungsbeispiele der Erfindung, wobei Netzwerkinhalte an Flanken-POPs Cache-gespeichert werden;
8 ein Ausführungsbeispiel eines Verfahrens zum Caching von Netzwerkinhalten;
9 ein Ausführungsbeispiel der vorliegenden Erfindung, das Fehlertoleranzmerkmale aufweist;
die 10 und 11 Ausführungsbeispiele der Erfindung, die Fehlererkennungs- und Fehlerbehebungsmerkmale aufweisen;
12 eine dynamische Serverzuordnung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
13 ein Ausführungsbeispiel der vorliegenden Erfindung, wobei eine Streaming-Mediendatei an einem Flanken-POP in einem Cache gespeichert wird;
14 ein Ausführungsbeispiel der Erfindung mit einer Konfiguration zur Verarbeitung von live ausgestrahlten und/oder On-Demand-Audio-/Videosignalen;
15 ein Ausführungsbeispiel, in dem Audio/Video über ein Netzwerk an Endnutzer gestreamed werden; und
16 ein Ausführungsbeispiel, in dem Audio-/Video-Streaming-Inhalt an einer oder mehreren POP-Sites gecached wird.
GENAUE BESCHREIBUNG
EIN BEISPIEL FÜR EINE NETZWERKARCHITEKTUR
Elemente der vorliegenden Erfindung können in einer Multitier-Netzwerkarchitektur 200 vorhanden sein, wie etwa der in der Abbildung aus 2 dargestellten Architektur, welche ein oder mehrere Datenzentren 220-222 aufweist, eine Mehrzahl „intermediärer" Points-of-Presence („POP") Knoten 230-234 (hierin auch bezeichnet als „Private Network Access Points" oder „P-NAPs") und eine Mehrzahl von „Flanken"-POP-Knoten 240-245 (hierin auch bezeichnet als „Internet Service Provider Co-Location" Stellen oder „ISP Co-Lo" Stellen bzw. Positionen).
Gemäß dem in der Abbildung aus 2 dargestellten Ausführungsbeispiel umfasst jedes der Datenzentren 220-222, die intermediären POPs 230-234 und/oder die Flanken-POPs 240-245 Gruppen von Netzwerk-Servern, auf denen verschiedenartige Netzwerkinhalte gespeichert und zu Endnutzern 250 übertragen werden können, wie zum Beispiel an Webseiten, Netzwerknachrichtendaten-, E-Mail-Daten- und FTP- Dateien (FTP als Abkürzung von File Transfer Protocol) und live übermittelte und On-Demand-Multimedia-Streaming-Dateien. Hiermit wird jedoch festgestellt, dass die zugrunde liegenden Grundsätze der vorliegenden Erfindung unter Verwendung einer Vielzahl verschiedenartiger Netzwerkinhalte ausgeführt werden können.
Die an den Datenzentren 220-222 und POPs 230-234; 240-245 angeordneten Server können miteinander und mit Endnutzern 150 unter Verwendung einer Vielzahl von Übertragungs- bzw. Kommunikationskanälen kommunizieren. Dazu zählen unter anderem DS-Kanäle (DS als englische Abkürzung von Digital Signal) (z.B. DS-3/T-3, DS-1/T1), SONET-Kanäle (Synchronous Optical Network-Kanäle) (z.B. OC-3/STS-3), ISDN-Kanäle (Integrated Services Digital Network-Kanäle), DSL-Kanäle (Digital Subscriber Line-Kanäle), Kabelmodemkanäle und eine Vielzahl kabelloser Übertragungskanäle, einschließlich Satellitenübertragungen und Mobilfunk.
Darüber hinaus können verschiedene Netzwerkprotokolle zur Implementierung der Aspekte des Systems eingesetzt werden. Dazu zählen unter anderem zum Beispiel Asynchronous Transfer Mode („ATM"), Ethernet und Token Ring (auf der Datenübermittlungsabschnittebene); sowie Transmission Control Protocol/Internet Protocol („TCP/IP"), Internetwork Packet Exchange („IPX"), AppleTalk und DECnet (auf Netzwerk-/Transportebene). Hiermit wird jedoch festgestellt, dass die Grundsätze der Erfindung nicht auf einen bestimmten Übertragungskanal oder ein bestimmtes Übertragungsprotokoll beschränkt sind.
In einem Ausführungsbeispiel wird eine Datenbank zum Speichern von Informationen in Bezug auf verteilten Netzwerkinhalt auf Servern in Datenzentren 220-222 (und möglichst auch an den POP-Knoten 230-234; 240-245) verwaltet. In einem Ausführungsbeispiel handelt es sich bei der Datenbank um eine verteilte Datenbank (d.h. über mehrere Server verteilt), und wobei diese eine Instanz eines Relational Database Management System (RDBMS) ausführen kann, wie etwa Microsoft^TM SQL-Server, Oracle^TM oder dergleichen.
EIN BEISPIEL FÜR EINE COMPUTERARCHITEKTUR
Nach der kurzen Beschreibung eines Beispiels für eine Netzwerkarchitektur, welche die verschiedenen Elemente der vorliegenden Erfindung einsetzt, wird nachstehend in Bezug auf die Abbildung aus 3 ein Computersystem 300 beschrieben, das beispielhafte Clients und Server zur Implementierung der Elemente gemäß der vorliegenden Erfindung darstellt.
Ein Ausführungsbeispiel des Computersystems 300 umfasst einen Systembus 320 zur Übertragung von Daten bzw. Informationen, und mit einem Prozessor 310, der zur Informationsverarbeitung mit dem Bus 320 gekoppelt ist. Das Computersystem 300 umfasst ferner einen Direktzugriffsspeicher (RAM) oder eine andere dynamische Speichervorrichtung 325 (hierin als „Hauptspeicher" bezeichnet), die mit dem Bus 320 gekoppelt ist, um Informationen und Anweisungen zu speichern, die von dem Prozessor 310 auszuführen sind. Der Hauptspeicher 325 kann ferner zum Speichern temporärer Variablen oder intermediärer Informationen während der Ausführung von Befehlen durch den Prozessor 310 eingesetzt werden. Das Computersystem 300 kann auch einen Nur-Lesespeicher („ROM") und/oder eine andere statische Speichervorrichtung 326 aufweisen, die mit dem Bus 320 gekoppelt ist, um statische Informationen und Anweisungen zu speichern, die von dem Prozessor 310 verwendet werden.
Eine Datenspeichervorrichtung 327, wie etwa eine Magnetplatte oder eine optische Platte und das zugehörige Laufwerk können auch zum Speichern von Informationen und Anweisungen mit dem Computersystem 300 gekoppelt werden. Das Computersystem 300 kann auch über eine E/A-Schnittstelle 330 mit einem E/A-Bus 350 gekoppelt werden. Eine Mehrzahl von E/A-Vorrichtungen kann mit dem E/A-Bus 350 gekoppelt werden, darunter eine Anzeigevorrichtung 343 und/oder eine Eingabevorrichtung (z.B. eine alphanumerische Eingabevorrichtung 343 und/oder eine Cursor-Steuervorrichtung (341).
Die Kommunikationsvorrichtung 340 wird für den Zugriff auf andere Computer (Server oder Clients) über ein Netzwerk 210 eingesetzt. Die Kommunikationsvorrichtung 390 kann ein Modem, eine Netzwerkschnittstellenkarte oder eine andere allgemein bekannte Schnittstellenvorrichtung umfassen, wie diese etwa für die Kopplung mit Ethernet-, Token Ring- oder andersartigen Computernetzwerken verwendet werden.
AUSFÜHRUNGSBEISPIELE DER ERFINDUNG
In erneutem Bezug auf die Abbildung aus 2 betrifft der hierin verwendete Begriff „Inhalteanbieter" 260 eine Einzelperson oder ein Unternehmen bzw. eine Organisation mit zu verteilenden Inhalten an Endnutzer 250 über das hierin beschriebene Systeme und Verfahren. Der Begriff „Inhaltsverteilungsdienst" betrifft einen Dienst, der Innalteanbietern 260 von einem Einzelnen oder einer Organisation angeboten wird, wobei Ausführungsbeispiele des hierin beschriebenen Systems und Verfahrens zur Verteilung von Netzwerkinhalten implementiert werden.
In einem Ausführungsbeispiel des Systems dienen die Datenzentren 220-222 als primäre anfängliche Speicher für den Netzwerkinhalt. Wenn ein Inhalteanbieter (englisch: Content Provider) 260 somit eine an Endnutzer 250 zu verteilende Datei erzeugt, wie z.B. eine neue Streaming-Medienpräsentation, so lädt der Inhalteanbieter 260 zuerst den Inhalt in einen Streaming-Server hoch, der sich in einem Datenzentrum 220-222 befindet. Alternativ kann der Inhalt von einem Mitglied des Betriebspersonals des Datenzentrums 220-222 geladen werden. Die Datei wird danach automatisch von dem Datenzentrum 220-222 an einen oder mehrere intermediäre POPs 230-234 und/oder Flanken-POPs 240-245 auf der Basis einer automatisierten Verteilungsrichtlinie für Inhalte und/oder der Endnutzernachfrage nach der Datei (wie dies nachstehend im Text näher beschrieben ist) verteilt.
Da die Datenzentren 220-222 in der Lage sein müssen, sehr große Datenmengen des Inhalteanbieters 260 zu speichern und zu übertragen, können diese Einrichtungen mit Disk-Arrays ausgerüstet sein, die hunderte von Terabyte an Daten (auf der Basis aktueller Kapazitäten; die Datenzentren 220-222 können auf der Basis von Verbesserungen der Speichertechnologie zukünftig wohl noch deutlich größere Speicherkapazitäten aufweisen) speichern. Darüber hinaus sind die Datenzentren mit hoher Bandbreiten-Konnektivität zu den andren Datenzentren 220-222, den intermediären POPs 230-234 und in bestimmten Maße den Flanken-POPs 240-245 versehen. In einem Ausführungsbeispiel sind die Datenzentren 220-222 zu jedem Zeitpunkt mit entsprechendem Betriebspersonal besetzt (d.h. 24 Stunden am Tag an sieben Tagen in der Woche).
In einem Ausführungsbeispiel des Systems werden mehr intermediäre POPs 230-234 als Datenzentren 220-222 implementiert. Einzeln jedoch können die intermediären POPs 230-234 mit einer im Verhältnis geringeren Online-Speicherkapazität (mehrere hundert Gigabyte bis zu einem oder zwei Terabyte an Speicherkapazität) konfiguriert werden als die Datenzentren 230-234. Die intermediären POPs 230-234 sind in einem Ausführungsbeispiel geografisch über die Welt verteilt, um ein effizienteres Verteilungsmuster für Inhalte bereitzustellen. Diese Standorte können auch aus der Ferne verwaltet werden, mit einer starken Netzwerk- und Systemmanagement-Unterstützung durch die Datenzentren 220-222 (wobei dies nachstehend im Text näher beschrieben ist).
Die Flanken-POPs 240-245 sind Einrichtungen, die in einem Ausführungsbeispiel kleiner sind als die intermediären POPs 230-234. Jedoch werden im Wesentlichen geografischer verteilte Flanken-POPs 240-245 im Verhältnis zu der Anzahl der intermediären POPs 230-234 und Datenzentren 220-222 eingesetzt. Die Flanken-POPs können mehrere Server-Racks bzw. Server-Gestelle und andere Netzwerkvorrichtungen umfassen, die sich an dem gleichen Standort wie der Eigentümer bzw. der Betreiber der Einrichtung befinden (z.B. ein Internet Service Provider bzw. Internet Serviceprovider). Einige der Flanken-POPs 240-245 sind mit direkter hoher Bandbreiten-Konnektivität (z.B. über einen T1-Kanal oder höher) zu dem Netzwerk 210 vorgesehen, während andere Flanken-POPs 240-245 nur mit einer niedrigen Bandbreiten-„Steuerungs"-"Konnektivität (z.B. für gewöhnlich mindestens eine Einwahl-Datenverbindung; wobei sie aber auch einen Teil einer T1-Verbindung aufweisen kann) bereitgestellt werden. Obgleich bestimmte Flanken-POP-Sites 230-234 mit dem Rest des Systems über das Internet verbunden sind, kann die Verbindung so implementiert werden, dass die Flanken-POPs 240-245 Teil eines Virtual Private Networks bzw. eines virtuellen privaten Netzwerks („VPN") sind, das über die Datenzentren 220-222 administriert wird. Wie die intermediären POPs 230-234 können die Flanken-POPs 240-245 unter Verwendung von Netzwerk- und Systemmanagement-Unterstützung von einem oder mehreren der Datenzentren 220-222 aus der Ferne verwaltet werden.
Systemressourcen (z.B. Server, Konnektivität) können als modulare Einheiten eingesetzt werden, die auf der Basis der Nachfrage nach der jeweiligen Art von Inhalt an den Datenzentren 220-222, den intermediären POPs 230-234 und den Flanken-POPs 240-245 hinzugefügt werden können. Diese Modularität stellt Skalierbarkeit auf „lokaler" Ebene bereit, wobei Skalierbarkeit im „globalen" Rahmen (systemweit) unterstützt wird durch das Hinzufügen von intermediären POPs 230-234 und Flanken-POPs 240-245 gemäß dem Bedarf durch das Wachstum des Bestands des Inhalteanbieters 260 und Hinzufügungen/Veränderungen des Inhaltsverteilungsdienstes. „Lokale" Ebene bedeutet in diesem Zusammenhang innerhalb eines Datenzentrums, eines intermediären POP oder eines Flanken-POP. Wenn ein bestimmter Flanken-POP zum Beispiel mit 5 Streaming-Servern konfiguriert worden ist, die z.B. 5.000 Streams als Gesamtkapazität an dieser „Flanke" bereitstellen, so kann die Kapazität des Flanken-POP skaliert werden (gemäß einem Ausführungsbeispiel der vorliegenden Erfindung) auf höhere/niedrigere Werte (z.B. auf 3.000 Streams oder 10.000 Streams), abhängig von dem jeweils prognostizierten Bedarf, indem Streaming-Server entfernt/hinzugefügt werden. Im „globalen" oder systemweiten Rahmen kann Skalierbarkeit erreicht werden durch das Hinzufügen neuer POPs, Datenzentren und den Anschluss an/die Zuweisung von einer höheren Bandbreite für Netzwerkverbindungen.
Die dreistufige Architektur aus der Abbildung aus 2 sorgt für eine optimale Nutzung der Bandbreite und der Ressourcen des Netzwerks 210. Durch die Datenübermittlung an Endnutzer 250 primär von den Flanken-POPs 240-245 reduziert sich die Fernkonnektivität (z.B. direkte Versorgung von Benutzern 250 von der Inhaltsquelle), wodurch Netzwerkbandbreite eingespart wird. Dieses Merkmal ist besonders nützlich für Anwendungen wie das Multimedia-Streaming in Echtzeit, welche eine signifikante Bandbreite und Speicherkapazität voraussetzen. Folglich erfahren Endnutzer eine erheblich verbesserte Dienstgüte, da die Zustellung von Inhalten von den Flanken-POPs 240-245 die großen Engpässe in den heutigen Netzwerken verhindert.
In einem besonderen Ausführungsbeispiel des Systems gemäß der Abbildung aus 4 sind private Hochgeschwindigkeits-Übertragungskanäle 422, 424 und 426 zwischen den Datenzentren 420 und den intermediären POPs 430, 432 und 434 bereitgestellt, die alle der gleichen Organisation gehören können. Im Gegensatz dazu sind die Flanken-POPs 440-448 in dem vorliegenden Ausführungsbeispiel über das Internet (d.h. öffentliche Übertragungskanäle) mit den intermediären POPs 430, 432 und 434 und den Datenzentren 420 verbunden.
Nachstehend wird in Bezug auf die Abbildungen der 14 bis 16 ein bestimmtes Ausführungsbeispiel des Systems beschrieben, das so konfiguriert ist, dass es live ausgestrahlte und On-Demand-Audio-/Videoinhalte streamed. Wie dies in der Abbildung aus 14 dargestellt ist, können in dem vorliegenden Ausführungsbeispiel eingehende Audio-/Videoinhalte von einer Vielzahl von Quellen empfangen werden, wie zum Beispiel, ohne darauf beschränkt zu sein, live übermittelte oder aufgezeichnete Signale 1401, die über Satellitenstrecken 1410 ausgestrahlt werden; live ausgestrahlte Signale 1402, die durch Videokonferenzsysteme 1411 bereitgestellt werden; und/oder live ausgestrahlte oder aufgezeichnete Signale 1403, die über dedizierte IP-Übermittlungsabschnitte (IP als englische Abkürzung von Internet Protocol) 1412 übermittelt werden. Hiermit wird festgestellt, dass eine unbegrenzte Vielzahl von anderen Netzwerkprotokollen als IP eingesetzt werden kann, unter weiterer Einhaltung der zugrunde liegenden Grundsätze der vorliegenden Erfindung. In einem Ausführungsbeispiel befindet sich jedes der in der Abbildung aus 14 veranschaulichten Module an einem Datenzentrum 220.
Eines oder mehrere Systemerfassungs- und Managementmodule („SAMs") 1420 öffnen und schließen Kommunikationssitzungen zwischen verschiedenen Quellen 1401-1403, wie dies erforderlich ist. Wenn zum Beispiel ein Inhalteanbieter eine neue Live-Streaming-Sitzung erzeugen möchte, öffnet das SAM 1420 eine neue Verbindung, um die eingehenden Audio-/Videodaten zu behandeln (nachdem bestimmt worden ist, dass der Inhalteanbieter zur Herstellung der Verbindung berechtigt ist).
Das SAM-Modul 1420 behandelt eingehende Signale unterschiedlich auf der Basis davon, wie die Signale bereits codiert sind (z.B. durch die Inhalteanbieter) und/oder abhängig davon, ob die Signale „live" oder „On-Demand" Inhalte umfassen. Wenn ein Signal zum Beispiel noch nicht von einem Inhalteanbieter codiert worden ist (z.B. das Signal kann an dem Datenzentrum 220 in einem analogen Format oder in einem Non-Streaming Digitalformat empfangen werden), richtet das SAM-Modul das Signal an ein oder mehrere Streaming-Codierer-Module 1430, die den Stream in einem spezifizierten digitalen Streaming-Format codieren (z.B. Windows Media^TM, Real G2^TM, ..., etc.)
Wenn das eingehende Signal live ist, übermitteln die Streaming-Codierer 1430 das resultierende codierte Signal direkt an einen oder mehrere Streaming-Ursprungs-Server 1510 (welche das Signal gemäß der nachstehenden Beschreibung an verschiedene POP-Knoten übertragen) und/oder an eine oder mehrere Inhaltsspeichervorrichtungen 531 an dem Datenzentrum 220. Wenn es sich bei dem eingehenden Signal jedoch um ein On-Demand-Signal handelt, so übermitteln die Streaming-Codierer 1430 das codierte Signal direkt zu den Inhaltespeichervorrichtungen 531. Wenn das eingehende Signal in ähnlicher Weise bereits in einem Streaming-Format codiert ist, kann es direkt zu der Inhaltespeichervorrichtung 531 übertragen werden, von wo es in der Folge zu dem Streaming-Ursprungs-Server 1510 übertragen werden kann. Wenn neue Audio-/Video-Streaming-Inhalte den Inhaltespeichervorrichtungen 531 hinzugefügt werden, bewirkt das SAM-Modul 1420 eine entsprechende Aktualisierung der Speicherdatenbank 530 (z.B. über das nachstehend beschriebene Teilsystem für die Zustellung von Inhalten).
Wie dies in der Abbildung aus 15 dargestellt ist, wird das codierte Signal von den Streaming-Ursprungs-Servern 1510 zu Streaming-Splittern 1520-1522, 1530-1532 übertragen, die an einer Vielzahl von I-POP-Knoten 230-232 und E-POP-Knoten 240-242 angeordnet sind. Der Einsatz von Streaming-Splittern gemäß der Darstellung hält einen Großteil der Netzwerkbandbreite aufrecht. In dem veranschaulichten Ausführungsbeispiel empfängt zum Beispiel jeder Streaming-Splitter nur einen einzelnen Strom von live Audio-/Videoinhalten von einem Upstream-Server, der danach in mehrere verschiedene unabhängige Streams aufgeteilt wird. Der Netzwerkpfad zwischen einem Upstream-Server und einem Streaming-Splitter wird somit nur mit einem einzigen Audio-/Video-Stream geladen.
Darüber hinaus reduziert der Einsatz von Streaming-Splittern in einer mehrstufigen (Multi-Tier) Hierarchie gemäß der Darstellung die Bandbreite auf jeder Hierarchieebene. Zum Beispiel kann ein einzelner Stream von einem live Streaming-Ereignis von einem Streaming-Ursprungs-Server 1510 zu einem I-POP-Streaming-Splitter 1521 übertragen werden. Der Streaming-Splitter 1521 kann danach einen einzelnen Stream zu jedem der E-POP-Streaming-Splitter 1530-1532 übertragen, welche danach das Live-Ereignis zu einer Mehrzahl von Endnutzern 1540-1548 übertragen können. Folglich wird der Netzwerkpfad zwischen dem Datenzentrum 220 und dem I-POP 231 mit nur einem einzelnen Stream bzw. Strom geladen, und jeder der drei Netzwerkpfade zwischen dem I-POP 231 und den E-POPs 240-242 wird mit nur einem einzelnen Stream geladen. Die eingehenden Streams werden danach an jedem der E-POPs 240-242 aufgeteilt, um da Live-Ereignis an eine Mehrzahl von Endnutzern 1540-1548 bereitzustellen.
Automatisierte Zustellung von Inhalten
Wie dies in der Abbildung aus 5 veranschaulicht ist, kann Inhalt an dem Datenzentrum 505 in das System eingeführt werden, und zwar über ein direktes Hochladen durch einen Inhalteanbieter 260 (z.B. unter Verwendung von FTP), durch Mitarbeiter des Datenzentrums 515 (z.B. über Bänder und CDs) oder über ein live ausgestrahltes Echtzeit-Mulimedia-Signal. Unabhängig davon, wie neuer Inhalt eingeführt wird, aktualisiert in einem Ausführungsbeispiel ein Verzeichis/Datei-Überwachungsmodul („DF Mon") 510 einen Inhaltedatenbank 530, um die neuen Dateien zu identifizieren, die an dem Datenzentrum 505 angekommen sind. Ein Datenbankfeld oder ein Tag können festgelegt werden, um anzuzeigen, dass die Daten neu sind und noch nicht zu den intermediären POPs 506 übertragen wurden. In einem Ausführungsbeispiel handelt es sich bei dem DF Mon 510 um einen im Hintergrund auf einem Server in dem Datenzentrum ausgeführten Dienst (z.B. einen Windows NT^® Diensts), der Dienstelemente eines Betriebssystems (z.B. Win32) für die Überwachung der codierten Dateiverzeichnisse verwendet. Das Betriebssystem benachrichtigt das DF Mon 510, wenn Dateien diesen Verzeichnissen hinzugefügt oder aus diesen entfernt werden.
Ein automatisches Teilsystem für die Verteilung von Inhalten verteilt danach automatisch (d.h. „repliziert" oder „spiegelt") den neu eingeführten Inhalt durch das System. In einem Ausführungsbeispiel umfasst das automatische Teilsystem zur Verteilung von Inhalten ein Inhaltsverteilungsmanager-Modul („CDM") 520 und ein Dateiübertragungsdienst-Modul („FTS") 525. Das CDM 520 implementiert eine Richtlinie zur Verteilung und Verwaltung von Inhalten, und das FTS 525 behandelt die physikalische Übertragung von Dateien. Hiermit wird festgestellt, dass die Abbildung aus 5 zwar zeigt, dass da FTS 525 und das CDM 520 sich vollständig in dem Datenzentrum 505 befinden, können Vorkommen dieser Module an anderen Knoten in dem Netzwerk implementiert werden (z.B. den intermediären POPs 541-544).
In einem Ausführungsbeispiel wird eine zentrale Datenbank 530, die in einem der Datenzentren 220-221 verwaltet wird, dazu verwendet, Inhalte zu verfolgen, wenn diese über das Netzwerk 210 verteilt/repliziert werden. Das CDM 520 fragt die Datenbank 530 periodisch ab, um zu bestimmen, ob etwaige Dateien (die in der Inhaltsspeichervorrichtung 531 gespeichert sind) an intermediären POPs 506 repliziert werden sollen. Alternativ oder zusätzlich kann das CDM 520 benachrichtigt werden (z.B. asynchron durch eine Datenbank-Anwendungsprogrammierschnittstelle, durch das DF Mon 510 oder ein anderes Ereignis gesteuertes Modul), wenn eine Datei einer Gruppe von Dateien repliziert werden muss.
Nachdem das CDM 520 bestimmt hat, dass die Dateien repliziert werden müssen, sendet es einen Befehl an das FTS 525, wobei der Befehl hierein als „File Request Message" („FRM") bezeichnet wird, der die Dateien und die Ziel-POPs 506, 507 für die Dateiübertragung identifiziert. Das FTS 525 führt danach den zugrunde liegenden Dateiübertragungsvorgang aus (z.B. durch Aufruf von Win32 oder FTP-Befehlen; wobei letztere Übertragungen über das Internet betreffen), und wobei es Datenbankaktualisierungen bereitstellt, die anzeigen, ob die Übertragung erfolgreich gewesen ist und ob die Datei kopiert worden ist.
Der Dateientfernungsprozess läuft ähnlich ab. Das CDM 520 ruft die Datenbank 530 in Bezug auf Dateien ab, die mit „zu löschen" („TBD" für „to be deleted") gekennzeichnet sind. Alternativ oder zusätzlich kann das CDM 520 benachrichtigt werden (wie bei der Dateiübertragung), wenn Dateien mit TBD gekennzeichnet sind. Eine Datei kann auf unterschiedliche Art und Weise als TBD gekennzeichnet werden. Wenn ein Inhalteanbieter 260 zum Beispiel die Datei hochlädt, kann der Anbieter bzw. Provider 260 anzeigen, dass er wünscht, dass die Datei nur für einen spezifizierten Zeitraum (z.B. 10 Tage) zur Verfügung steht. Alternativ kann der Inhalteanbieter 260 auch auf die Angabe eines Löschdatums verzichten und stattdessen die Datei jederzeit mit TBD kennzeichnen (oder die Kennzeichnung durch die Mitarbeiter des Datenzentrums 515 vornehmen lassen). In einem anderen Ausführungsbeispiel gibt der Inhalteanbieter 260 an, dass die Datei mit TBD gekennzeichnet werden sollte, und zwar auf der Basis, wie häufig (oder selten) Benutzer 250 die Datei anfordern.
Nachdem eine Datei in einen POP-Knoten 506, 507 kopiert oder aus einem POP-Knoten 506, 507 gelöscht worden ist, erzeugt oder entfernt das Teilsystem für die Verteilung von Inhalten einen Datenbank-Datensatz „Dateiposition" in der zentralen Inhaltsdatenbank 530. Dieser Datensatz stellt eine Zuordnung zwischen einer Datenzentrumsdatei und deren Kopien auf Speicher-Servern an intermediären und/oder Flankenpositionen bereit.
Die Abbildung aus 6 veranschaulicht ein Ausführungsbeispiel einer FRM-Datenstruktur 600. Die Struktur 600 weist einen Operationscode bzw. Opcode 610 auf, der dem FTS die Operation anzeigt, die an der bzw. den Datei(en) ausgeführt werden muss, einschließlich einer Identifikation, ob „Datei löschen" oder „Datei übertragen" erforderlich ist, und wobei die bestimmte Art der Dateilöschung/-übertragung angezeigt wird. Abhängig von den Bedingungen, kann zum Beispiel eine FTP-Löschung/Übertragung oder eine Win32-Löschung/Übertragung (oder eine andere Art der Löschung/Übertragung) angemessen sein (z.B. ist FTP besser geeignet, wenn das Löschen/die Übertragung über das Internet erfolgt, während eine Win32-Löschung/Übertragung über einen privaten Kanal effizienter sein kann).
Darüber hinaus kann das Feld Opcode 610 eine normale Löschung/Übertragung oder eine „verzögerte" Löschung/Übertragung spezifizieren. Allgemein können „verzögerte" FTS-Befehle zur Behandlung von Übertragungen/Löschungen mit niedriger Priorität eingesetzt werden. In einem Ausführungsbeispiel verarbeitet ein „verzögerter" Befehl die Lösch- und Übertragungsanforderungen unter Verwendung eines einzigen Threads (d.h. einer einzelnen Transaktion oder Nachricht in einem Multithread-System), während „normale" Operationen unter Verwendung mehrerer Threads ausgeführt werden können. „Verzögerte" Operationen mit einem Thread können für bestimmte Arten von FTP-Befehlen implementiert werden (z.B. Befehle auf der Basis der WS FTP API).
Ein Feld Quellen-Server 620 identifiziert den Server in dem Datenzentrum, von dem die Datei stammt; ein Feld „Anzahl der Ziel-Server" 630 zeigt die Anzahl der POPs an, zu denen die Datei übertragen bzw. aus denen sie gelöscht wird; ein Feld „Anzahl der Felder" 640 zeit an, wie viele Dateien die Transaktion aufweist; ein Feld „tatsächliche Datei-ID" 650 identifiziert jede der an der Transaktion beteiligte Datei, und eines oder mehrere Felder „IDs der tatsächlichen Ziel-Server" 660 spezifizieren die tatsächlichen Ziel-Server, zu denen die Datei(en) kopiert oder gelöscht werden. In dem vorliegenden Ausführungsbeispiel können das Feld „Anzahl der Dateien" 640 und das Feld „Anzahl der Ziel-Server" 630 von dem System verwendet werden, um die Paketlänge für eine Anforderungsnachricht zu bestimmen (d.h. diese Felder identifizieren, wie groß die Feder für die tatsächliche Datei-ID und die Ziel-Server-ID 650, 660 sein müssen).
Hiermit wird festgestellt, dass die vorstehende Beschreibung des Formats Anforderungsnachricht (Request Message) 600 zur Veranschaulichung dient. Verschiedene andere Formate von Informations-/Datenformaten können zwischen dem CDM 520 und dem FTS 525 gemäß den zugrunde liegenden Grundsätzen eingesetzt werden.
In einem Ausführungsbeispiel kann das CDM 520 Inhalt an spezifizierten intermediären POPs 541-544 (und in manchen Fällen an Flanken-POPs 551-553) unterschiedlich repliziert werden, abhängig von Variablen wie dem Netzwerkverkehr („Belastung"), dem Bedarf für bestimmte Dateien an bestimmten Stellen und/oder dem beanspruchten Service-Level von Inhalteanbietern 260. Während Zeiten eines hohen Netzwerkaufkommens kann das CDM 520 zum Beispiel Anforderungsnachrichten in einer Warteschlange in der Datenbank 530 speichern. Sobald das Netzwerkaufkommen unter einen vorbestimmten Schwellenwert zurückgeht, werden die Anforderungsnachrichten aus der Warteschlange zu dem FTS 525 übertragen, das den Vorgang der Dateiübertragung/Dateilöschung ausführt.
Wenn es vorab bekannt ist, dass eine bestimmte Datei zu einem bestimmten Zeitpunkt besonders stark nachgefragt wird (z.B. der „Starr-Bericht") und/oder anderweitig eine erhebliche Netzwerkbandbreite erforderlich ist (z.B. Streaming-Videodateien in hoher Qualität), so kann das CDM 520 so programmiert werden, dass es die Datei(en) an bestimmte intermediäre POPs 541-544 (und/oder Flanken-POPs 551-553; siehe unten) vorab übermittelt, um größere Probleme in Bezug auf die Dienstqualität zu vermeiden (z.B. Netzwerkausfälle).
Das CDM 520 kann ferner Dateien zu POPs 541-544 drücken, und zwar auf der Basis der von jedem Inhalteanbieter 260 in Anspruch genommenen Dienstklasse. Zum Beispiel können bestimmte Inhalteanbieter 260 bereit sein, mehr dafür zu bezahlen, dass eine bestimmte Datei jederzeit an allen POPs 541-544; 551-553 in dem Netzwerk direkt zur Verfügung steht. Ferner kann es sein, dass Inhalteanbieter 260 bestimmte Arten von Inhalten nur an bestimmten POPs 541-544 zur Verfügung haben möchten. Ein internationaler Inhalteanbieter 260 kann zum Beispiel wünschen, die gleiche zugrunde liegende Webseite in verschiedenen Sprachen auf verschiedenen intermediären Seien von POPs 541-544 zur Verfügung zu stellen, abhängig von dem jeweiligen Land, in dem die intermediären POPs 541-544 verwaltet werden (und welche somit Benutzer in diesem Land mit Inhalten versorgen. Somit kann ein Automobilhersteller wünschen, dass eine französische Version seiner Webseite zu POPs in Frankreich übertragen wird, und eine deutsche Version an POPs in Deutschland. Das CDM 520 kann in dem vorliegenden Ausführungsbeispiel so konfiguriert werden, dass es den Inhalt so überträgt, wie dies erforderlich ist, um die spezifischen Anforderungen jedes Inhalteanbieters 260 zu erfüllen. In einem Ausführungsbeispiel bestimmt das CDM 520, ob spezifizierte Dateien kopiert werden müssen, und zwar auf der Basis der markierten bzw. gekennzeichneten Dateien in der Datenbank 530 (z.B. können die Dateien eine gültige Gruppe von POPs anzeigen, bei denen sie repliziert werden sollen).
Datei-Caching
In einem Ausführungsbeispiel werden die Flanken-POPs 551-553 als Cache-Dateiserver behandelt, zum Speichern des am häufigsten angeforderten Medieninhalts. Das CDM nimmt in einem Ausführungsbeispiel eine Cache-Speicherung des Inhalts an den Flanken-POPs 551-553 unter Verwendung des erzwungenen Cachings und des auf Nachfrage basierenden Cachings vor.
Bei einem erzwungenen Caching-Protokoll identifiziert das CDM Dateien, die an einer speziellen Flanken-POP-Site 551-553 eine hohe Nachfrage aufweisen (z.B. durch Abfrage der Datenbank 530), und verschiebt die Dateien als Reaktion an diese Stellen. Alternativ oder zusätzlich kann ein Inhalteanbieter Flanken-POP-Sites 551-553 spezifizieren, wobei das CDM eine bestimmte Gruppe von Dateien im Cache speichern sollte. Die Fähigkeit eines Inhalteanbieters, Flanken-POP-Sites 551-553 für das Caching von Dateien zu spezifizieren, kann auf der Dienstklasse basieren (Service Level), welche der Inhalteanbieter in Anspruch nimmt (wie dies vorstehend in Bezug auf intermediäre POP-Sites beschrieben worden ist).
In Bezug auf die Abbildung aus 7 werden nachstehend Ausführungsbeispiele des Systems beschrieben, welche ein Caching auf der Basis der Nachfrage einsetzen. Wenn ein Benutzer 705 in einem Ausführungsbeispiel Inhalt anfordert, der auf einer bestimmten Internetseite gespeichert ist (z.B. eine Webseite, eine Streaming-Multimedia-Datei, ..., etc.), so wird die Anforderung von einem Lastverteilungsmodul („LBM") 710 empfangen, welches die Flanken-POP-Site 507 mit der besten Übereinstimmung für die Behandlung der Anforderung identifiziert. Das LBM 710 ist in einem Ausführungsbeispiel ein Modul, das sich in einem Datenzentrum befindet (z.B. auf einem Webserver ausgeführt wird). Was das LBM 710 als „beste Übereinstimmung" identifiziert, ist von der speziellen Lastverteilungsrichtlinie 770 abhängig, die in Bezug auf das LBM 710 angewandt wird. Die Richtlinie 770 kann Caching-/Netzwerkvariablen berücksichtigen, wie zum Beispiel die Netzwerkbelastung, die Serverbelastung des Flanken-POP 507, die Position des Benutzers, der den Inhalt anfordert, und/oder die Position des Servers des Flanken-POP 507, um nur einige zu nennen.
In einem Ausführungsbeispiel ermittelt das LBM 710 den am besten geeigneten Flanken-POP 507 und bestimmt, ob der Inhalt an dem Flanken-POP 507 zur Verfügung steht, indem die zentrale Datenbank 530 abgefragt wird (d.h. die Datenbank 530 verfolgt in einem Ausführungsbeispiel genau, wo Inhalte in dem System verteilt worden sind). Wenn der angeforderte Inhalt an dem Flanken-POP 507 zur Verfügung steht, wird er zu dem Benutzer 705 übertragen. wenn der Inhalt an dem Flanken-POP 507 hingegen nicht zur Verfügung steht, so leitet das LBM 710 die Anforderung an den am zweitbesten geeigneten POP um (z.B. den intermediären POP 506 in dem veranschaulichten Ausführungsbeispiel), welcher danach den Inhalt zu dem Benutzer 705 übermittelt.
Das LBM 710 benachrichtigt das CDM 520, dass der angeforderte Inhalt nicht an der Position des Flanken-POP 507 zur Verfügung gestanden hat (d.h. es ist ein „Cache-Miss" aufgetreten). Das CDM 520 bestimmt, ob die bestimmte Position des Flanken-POP 507 eine Kopie des angeforderten Inhalts im Cache speichern soll, um zukünftig für Benutzeranforderungen zur Verfügung zu stehen. Wenn das CDM bestimt, dass eine Kopie an dem Flanken-POP 507 gespeichert werden soll, so endet es eine Übertragungsanforderungsnachricht an das FTS 525, welches die zugrunde liegende Dateiübertragung an den Flanken-POP 507 ausführt.
Die Entscheidung des CDM 520, ob eine Kopie im Cache gespeichert werden soll, basiert auf der jeweils eingesetzten Caching-Richtlinie 760. In einem Ausführungsbeispiels des Systems berücksichtigt die Caching-Richtlinie die Häufigkeit, mit der eine bestimmte Datei über einen Zeitraum von dem Flanken-POP 507 angefordert wird. Nachdem ein Schwellenwert erreicht worden ist (z.B. zehn Anforderungen innerhalb einer Stunde), bewirkt das CDM 520, dass das FTS 525 eine Kopie der Datei überträgt.
Andere Variablen, die bei der Caching-Richtlinie 760 berücksichtigt werden können, umfassen, ob die angeforderte Datei nicht Cache-fähig ist (z.B. Dateien, die eine Benutzerauthentifikation erfordern oder mit sich dynamisch änderndem Inhalt), die Speicherkapazität an dem Flanken-POP 507, die Größe der angeforderten Datei, die Netzwerk- und/oder Serverauslastung und die Dienstklasse bzw. der Service Level, den ein bestimmter Inhalteanbieter 260 in Anspruch nimmt, um nur einige zu nennen. Jede dieser Variablen kann alleine oder in Kombination durch das CDM 520 eingesetzt werden, um Caching-Entscheidungen darzustellen.
Nachstehend wird in Bezug auf das Flussdiagramm aus 8 ein Ausführungsbeispiel eines Verfahrens beschrieben, das ein Caching auf der Basis des Bedarfs einsetzt. Bei 810 fordert ein Benutzer Inhalt an. Als Reaktion darauf identifiziert ein LBM 710 die am besten geeignete Flanken-POP-Position, von der der angeforderte Inhalt übertragen werden soll (z.B. durch Abfrage einer zentralen Datenbank in dem Datenzentrum). Wenn der angeforderte Inhalt an dem Flanken-POP-Server zur Verfügung steht, wie dies bei 830 bestimmt wird, so leitet das LBM 710 den Benutzer zu dem Flanken-POP-Server (z.B. durch Übermittlung der URL des Servers zu dem Benutzer), und der Inhalt wird bei 835 zu dem Benutzer übermittelt.
Wenn der Inhalt hingegen nicht zur Verfügung steht, so identifiziert das LBM bei 840 den am besten geeigneten intermediären POP-Server, von dem der Inhalt übertragen werden soll (z.B. durch Abfrage der Datenbank). Der intermediäre POP-Server übermittelt den Inhalt bei 850 an den Benutzer, und bei 860 benachrichtigt das LBM 710 das CDM 520. Das CDM bestimmt bei 870, ob eine Kopie des angeforderten Inhalts lokal an der Site des Flanken-POP gespeichert werden soll auf der Basis der speziellen eingesetzten Caching-Richtlinie. Wenn es sich bei der Entscheidung um die Cache-Speicherung von Inhalt an der Site des Flanken-POP handelt, so wird der Inhalt zu der Position des Flanken-POP übertragen, und entsprechend wird die Datenbank bei 880 aktualisiert.
Wie dies in der Abbildung aus 16 veranschaulicht ist, stellt ein Ausführungsbeispiel einen Mechanismus für das Caching von häufig angefordertem Streaming-Inhalt an den I-POPs 231 und/oder den E-POPs bereit. Ob eine bestimmte Audio/Video-Streaming-Datei gecached werden soll, kann auf der antizipierten und/oder tatsächlichen Nachfrage nach der Datei basieren. Wenn zum Beispiel eine bestimmte Datei in einer bestimmten Häufigkeit an einem E-POP 241 innerhalb eines vorbestimmten Zeitraums angefordert worden ist (z.B. zehnmal innerhalb einer Stunde), so kann die Datei von einem Cache-Server 1610 (der eine Teilmenge von Dateien von den Inhaltsspeichervorrichtungen 531 empfängt) in dem Datenzentrum 220 zu einer lokalen Cache-Vorrichtung 1640 an dem E-POP 241 übermittelt werden. Wenn in einem Ausführungsbeispiel Dateien in einem Cache gespeichert oder von einer oder mehreren POP-Sites gelöscht werden, wird die Datenbank 530 aktualisiert, um diese Änderungen zu reflektieren.
In Bezug auf die Abbildung aus 13 wird nachstehend ein bestimmtes Ausführungsbeispiel des Systems und des Verfahrens zur Verteilung und Streaming von Multimedia-Dateien beschrieben. Ein Betrachter 1310, der in dem vorliegenden Beispiel über einen Flanken-POP 507 mit dem Internet verbunden ist, fordert das Streaming einer On-Demand-Datei an. Die Datei wird in der IES-Datenbank 1320 durch einen Datensatz „Dateiinfo" („FileInfo") referenziert, wobei die ID für den Datensatz als Parameter in der URL integriert ist, welche der Betrachter angeklickt hat, um auf einen Webserver 1325 in dem Datenzentrum 505 zuzugreifen. Der Webserver 1325 begründet in dem vorliegenden Ausführungsbeispiel ein Streaming-Modul (z.B. eine Website; „stream.asp" für Windows 98^TM) 1335 zur Verarbeitung der Anforderung. Das Streaming-Modul 1335 bildet eine Metadatei (z.B. eine Real G2 RAM oder WMT ASX Metadatei), welche den Streaming-Serverpfad zu der gewünschten Datei aufweist. Das Streaming-Modul 1335 ruft den Stream Redirector 1340 auf, um diesen Pfad zu bestimmen. Es verläuft in der Dateiinfo-ID von der URL und der IP-Adresse des Betrachters.
Bei dem Stream Redirector 1340 handelt es sich in einem Ausführungsbeispiel um einen Out-of-Proc COM-Server, der auf dem Webserver 1325 ausgeführt wird. Wenn der Redirector 1340 durch das Streaming-Modul 1335 aufgerufen wird, um den Streaming-Serverpfad zu der On-Demand-Datei zu erzeugen, prüft er zuerst die IP-Adresse des Betrachters 1310 im Vergleich zu einer Liste der Seiten-IP-Masken, die vorher aus der Datenbank 1320 erzeugt worden war. In dem veranschaulichten Ausführungsbeispiel ermittelt der Redirector 1340 eine Übereinstimmung und identifiziert die Flanken-POP-Site 507 richtig, von welcher der Betrachter 1310 eine Verbindung herstellt. Er prüft die Datenbank 1320 (z.B. unter Verwendung von Datenbank-APIs), um zu bestimmen, ob die gewünschte Datei an der Flanken-POP-Site 507 des Betrachters existiert. Wenn ein Datensatz Dateiort (FileLocation) unter Verwendung der Dateiinfo-ID von der URL gefunden wird, der mit diesem Ort 507 übereinstimmt, wird ein Streaming-Pfad zurückgegeben, der den Betrachter zu einem Medien-Server 1345 umleitet, der ebenfalls an der Site des Flanken-POP 507 angeordnet ist. Wenn die Datei dort nicht gefunden wird (d.h. was zu einem „Cache-Miss" führt), wird stattdessen ein Pfad erzeugt, der den Benutzer zu einem der intermediären POPs 506 umleitet, an dem die Datei bekannter Weise angeordnet sein kann.
Der Redirector 1340 fordert an, dass das Teilsystem für die Inhaltsverteilung 1355 übermittelt eine Kopie der Datei zu der Site des Flanken-POP 507 nach der Rückkehr zu dem Pfad des intermediären POP 506 zu dem Streaming-Modul 1335. In einem Ausführungsbeispiel benachrichtigt der Redirector 1340 einfach das Teilsystem zur Inhaltsverteilung 1355, dass der angeforderte Inhalt nicht an der Site des Flanken-POP 507 vorhanden ist, und er ermöglicht dem Teilsystem 1355 zur Inhaltsverteilung die Vornahme der abschließenden Entscheidung darüber, ob eine Kopie an dem Flankenort 507 gespeichert werden soll (z.B. auf der Basis der Richtlinie zur Inhaltsverteilung). Das CDM leitet danach die Anforderung an das FTS weiter, ob der Auftrag für eine spätere Verarbeitung in eine Warteschlange eingestellt wird.
Der Redirector 1340 führt den intermediären POP-Umleitungspfad zu dem Streaming-Modul 1335 zurück, wo er in die Metadatei eingefügt und zu dem Browser des Betrachters 1310 zurückgeführt wird. Der Browser des Betrachters 1310 empfängt die Metadatei und übergibt sie an den Streaming-Player (z.B. RealPlayer^®, Windows MediaPlayer^®, ..., etc.). Der Player analysiert die Metadatei für den Umleitungspfad, stellt eine Verbindung mit einem Medien-Server an dem designierten intermediären POP 506 her und beginnt mit dem Streaming der On-Demand-Datei.
Das FTS verarbeitet den Auftrag für die Übertragung der Datei zu der Site des Flanken-POP 507 (z.B. über eine Win32 Dateikopie, wenn eine private Verbindung zu dem Ort bzw. der Seite existiert, oder alternativ über FTP über das Internet, wenn dies den einzigen Pfad zu dem Ort von dem Datenzentrum darstellt). Das FTS kann in einem Ausführungsbeispiel auf jedem Server in dem Netzwerk ausgeführt werden. Somit können sich Instanzen des FTS an den intermediären POPs 506 befinden und Kopien von intermediären POPs 506 an Flanken-POPs 507 einleiten, wodurch Bandbreite an den privaten Verbindungen eingespart wird, die das Datenzentrum 505 verlassen. Wenn die Speicherung der Dateikopie an den Flanken-POP 507 erfolgreich abgeschlossen ist, erzeugt das FTS einen Datensatz „Dateiort" („FileLocation") in der Datenbank, der die Datensätze Dateiinfo und Flanken-POP-Site 507 zuordnet.
Wenn der Betrachter 1310 oder ein anderer Betrachter, der über diesen Flanken-POP 507 eine Verbindung herstellt, das nächste Mal versucht, die gleiche Datei zu Streamen, so wird diese direkt von einem Medien-Server 1345 (z.B. an dem LAN eines ISP angebunden) an der Site des Flanken-POP 507 gestreamed. Der erzeugte Datenbank-Datensatz Dateiort (FileLocation) ermöglicht dem Redirector 1340 die Auswahl der optimaleren ISP-Site für den Benutzer 1310. Hiermit wird festgestellt, dass die Zeitsteuerungen für die verschiedenen Komponenten abhängig von dem Bedarf des Systems variieren können, wobei die allgemeinen Konzepte jedoch weiterhin Gültigkeit besitzen.
Verwaltung des Speicherplatzes
In erneutem Bezug auf die Abbildung aus 5 implementiert das CDM 520 eine Richtlinie für die Verwaltung des Cache-Raums an allen Flanken-Dateiservern unter Verwendung von Dateizugriffsdaten, die in der zentralen Datenbank 530 gespeichert sind (z.B. Daten, die anzeigen, wann und wie häufig eine bestimmte Datei an einem Flanken-POP angefordert wird). Verhältnismäßig selten angeforderte Dateien und/oder Dateien, die über einen längeren Zeitraum nicht angefordert worden sind, im Vergleich zu anderen Dateien, können von dem Flanken-POP mit TBD gekennzeichnet werden (d.h. über entsprechende Algorithmen „der seltensten Verwendung" und der „letzten Zugriffszeit"). Die Datenbank kann auch Daten zum Ablauf einer Datei enthalten (z.B. „Datei X wird ab dem 15.1.2000 ungültig"), und wobei diese von dem CDM 520 verwendet werden können, um Cache-Managementfunktionen auszuführen.
In einem Ausführungsbeispiel sind jedem Flanken-POP 551-553 hohe und niedrige, in der Datenbank 530 gespeicherte Schwellenwerte zugeordnet. Der hohe Schwellenwert entspricht einem prozentualen Anteil, der anzeigt, wie voll eine Flanken-Server-Speichervorrichtung sein muss, damit das CDM 520 Dateientfernungsoperationen aufruft. Der niedrige Schwellenwert ist ein prozentualer Anteil, der anzeigt, wie voll die Flanken-Server-Speichervorrichtung ist, wenn das CDM seine Dateientfernungsfunktionen abgeschlossen hat.
Wenn der hohe Schwellenwert für einen bestimmten Flanken-POP 551 zum Beispiel 80% entspricht, wird eine Flagge für den hohen Schwellenwert in der Datenbank 530 festgelegt, wenn der Speicher an dem Standort 80% seiner Kapazität erreicht. Als Reaktion darauf weist das CDM 520, das die Datenbank 530 periodisch in Bezug auf Schwellenwertdaten abruft, das FTS 525 an, Dateien von dem Ort bzw. der Site zu entfernen, unter Verwendung einer oder mehrerer der vorstehend beschriebenen Cache-Managementrichtlinien. Wenn der niedrige Schwellenwert auf 60% für diesen Ort gesetzt wird, so weist das CDM 520 das FTS 525 an, Dateien zu löschen, bis der Standortspeicher 60% seiner Kapazität erreicht hat. Das Festlegen des niedrigen Schwellenwertes auf diese Weise verhindert die andauernde Ausführung der Dateientfernungsoperation, wenn ein Dateiserver dessen hohen Schwellenwert erreicht.
Fehlertoleranz
In Bezug auf die Abbildung aus 9 wird nachstehend ein Ausführungsbeispiel des Systems beschrieben, das Fehlertoleranzeigenschaften einsetzt. Wenn bislang mehr als ein Dateiserver an einem POP vorhanden gewesen ist, wurde der Inhalt von der Inhaltsquelle zu jedem einzelnen Dateiserver an dem POP-Ort übertragen. Die Übertragung mehrerer Kopien der gleichen Datei auf diese Weise ist tendenziell ineffizient und teuer, im Besonderen in Bezug auf Multimedia-Dateien (die allgemein ziemlich groß sind). Die Verwaltung eines einzigen Dateiservers an jedem Standort löst das Problem des erhöhten Netzwerk- und Serververkehrs, erzeugt jedoch ein Problem in Bezug auf die Zuverlässigkeit (d.h., wenn der Dateiserver ausfällt, ist der ganze Standort nicht mehr verfügbar).
Ein Ausführungsbeispiel der vorliegenden Erfindung löst alle der vorstehenden Probleme durch die Bereitstellung von Backup-Dateiservern 911-913, 921-922 und 931, die beim Fehlen der primären Server 910, 920 und 930 entsprechend aktiviert werden. Ein als „Dateiübertragungsagent" („File Transfer Agent" bzw. „FTA") bezeichnetes Modul wird auf allen Dateiservern 910-913, 920-922 und 930-931 an verschiedenen Orten ausgeführt und kann entweder als ein Master-FTA oder ein Slave-FTA konfiguriert werden. Die Master-FTA-Dateiserver 910, 920 und 930 übermitteln und empfangen Dateien von dem Rest des Systems (z.B. von dem Datenzentrum 221 über das Netzwerk 210), während die Slave-FTA-Dateiserver 911-913, 921-922 und 931 nur Dateien von den entsprechenden Master-FTA-Dateiservern 910, 920 und 930 empfangen.
Die Master-/Slave-FTA-Zuordnungen in jedem Dateiserver-Cluster werden manuell konfiguriert und/oder über ein Protokoll verhandelt. Informationen, die jeden Master- und Slave-FTA an jedem der POPs 900, 901 und Datenzentrum 221 identifizieren, werden in der Datenbank 530 gespeichert. Wenn eine Datei an eine bestimmte Stelle 900 übertragen werden soll (z.B. über einen FTS-Dateiübertragungsbefehl), verweist ein Master-FTA 930 an dem Datenzentrum 221 auf den Master-FTA-Dateiserver 910 an diesem Ort (z.B. über eine Abfrage der Datenbank 530). Der Quellen-Master-FTA-Dateiserver 930 an dem Datenzentrum 221 überträgt die Datei zu dem Ziel-Master-FTA-Dateiserver 910 an dem POP-Standort 900. Der Ziel-Master-FTA 910 ist danach verantwortlich für die Übertragung des Inhalts zu den verbleibenden Dateiservern 911-913 in dem Cluster. In einem Ausführungsbeispiel umfasst der FTA einen Teil des hierin beschriebenen Teilsystems zum Zustellen von Inhalten (d.h. CDM/FTS).
Wenn in ähnlicher Weise Dateien von dem Master-FTA-Dateiserver 910 gelöscht werden, ist der Mastre-FTA zuständig für das Löschen von Dateien von den Slave-Dateiservern 911-913. Auf diese Weise werden alle Änderungen des Master-FTA-Dateiservers 910 zu anderen sekundären Dateiservern 911-912 in dem Cluster reflektiert. In einem Ausführungsbeispiel wird diese Synchronisierung unter Verwendung eines Dämons erreicht, der alle Änderungen des Master-FTA-Dateiservers detektiert und automatisch die anderen Dateiserver aktualisiert.
Wenn der Master-FTA-Dateiserver 910 ausfällt, wird einer der Slave-FTA-Dateiserver (z.B. 911) in dem Dateiserver-Cluster zu dem Master-FTA durch Protokollaushandlung. In einem Ausführungsbeispiel wird ein Keep-Alive-Protokoll implementiert, wobei ein oder mehrere der Slave-FTA-Dateiserver 911-913 periodisch Statusanforderungen an den Master-FTA-Dateiserver 910 senden, um sicherzustellen, dass der Master aktiv ist. Wenn nach einer vorbestimmten Anzahl von Anforderungen keine Antwort von dem Master-FTA empfangen wird (was anzeigt, dass der Master ausgefallen ist), so wird einer der Slave-FTA-Dateiserver 911-912 zu dem neuen Master-FTA. In einem Ausführungsbeispiel werden automatische Master-/Slave-Zuordnungen wahlfrei erreicht; wobei jeder FTA eine Zufallszahl erzeugt, und wobei der FTA mit der größten Zufallszahl als neuer Master zugeordnet wird.
Fehlerbehandlung und -behebung
Potenziell werden tausende von Dateien pro Tag durch das CDM 520 verarbeitet. Diesbezüglich wäre eine robuste, automatisierte Fehlerbehandlung und -behebung von Vorteil, um eine hohe Dienstgüte für Endnutzer 250 zu gewährleisten. Ein Netzwerkfehler kann eine Reihe potenzieller Ursachen haben, darunter unter anderem die fehlende Verfügbarkeit der Quell- oder Zielseite (z.B. da die Server ausgefallen sind), extreme Netzwerkauslastung, fehlende Verfügbarkeit der Netzwerkübertragungskanäle und verschiedenartige Softwarefehler. In einem Ausführungsbeispiel des Systems, das nachstehend in Bezug auf die Abbildungen der 10 und 11 beschrieben wird, detektiert und analysiert das CDM automatisch Netzwerkfehler und versucht diese zu berichtigen.
Bei 1000 (10) versucht das FTS 525 als Reaktion auf eine Anforderungsnachricht des CDM 520 eine Dateioperation auszuführen (z.B. eine Dateiübertragung und/oder einen Dateilöschvorgang). Wenn die Operation erfolgreich ist (bestimmt bei 1010), so aktualisiert das FTS 525 die Datenbank 530, um die Änderungen zu reflektieren, und es wechselt zu der nächsten auszuführenden Dateioperation. Wenn das FTS 525 jedoch nicht in der Lage ist, die angeforderte Operation auszuführen, so protokolliert es den Fehler in einer Fehlerwarteschlange 1100 in der Datenbank 530 (bei 1020). Jeder Eintrag in der Fehlerwarteschlange 1100 weist die Anforderungsnachrichtoperation auf, die zu dem Fehler geführt hat (z.B. Dateiübertragungen 1108-1111, 1176-1177, 1190; und die Fehlerlöschung 1125 aus 11), in Verbindung mit einem Fehlercode, der den Grund für den Fehler anzeigt (z.B. Fehlercodes 7, 10 und 3 aus 11).
Ein Fehleranalyseabschnitt des CDM 1120 fragt die Datenbank 530 periodisch nach Fehlern ab (bei 1030) und bestimmt eine entsprechend geeignete Fehlerbehebungsprozedur, die auf der Behebungsrichtlinie 1110 basiert. Die Behebungsrichtlinie 1110 kann sowohl netzwerkspezifische als auch allgemeine Prozeduren aufweisen, die durch die Mitarbeiter des Datenzentrums 515 bereitgestellt werden (siehe 5). Wenn ein Ziel-POP zum Beispiel über einen bekannten Zeitraum (z.B. von 20.00 bis 23.00 Uhr) ausgefallen gewesen ist, können die Mitarbeiter 515 diese netzwerkspezifischen Informationen in die Behebungsrichtlinie 1110 aufnehmen. Wenn das CDM 520 Dateioperationsfehler während dem spezifizierten Zeitraum empfängt, die an diesen POP gerichtet sind, so erkennt es bei 1040, dass diese Fehler behebbar sind (d.h. es wird angenommen, dass der Ziel-POP nicht mehr länger ausgefallen ist), und wobei es einen Fehlerbehebungsprozess 1050 einleitet (z.B. kann das FTS 525 angewiesen werden, die Dateiübertragungsoperation erneut zu versuchen).
Die Behebungsrichtlinie 1110 kann auch allgemeine Behebungsprozeduren aufweisen. Wenn die fehlgeschlagene Dateioperation zum Beispiel nur einmal durch das FTS 525 versucht worden ist, kann das CDM 520 automatisch das FTS 525 anweisen, es erneut zu versuchen (d.h. in der Annahme, dass der Fehler das Ergebnis einer temporären Netzwerkstörung gewesen ist). Wenn der Fehler auch nach einer vorbestimmten Anzahl von Versuchen noch gegeben ist, kann das CDM 520 bestimmen, dass die Behebung nicht möglich ist, und es erzeugt einen Bericht (bei 1060), der von den Mitarbeitern 515 geprüft wird.
In einem Ausführungsbeispiel bestimmt das CDM 520, ob eine Behebung 1050 versucht werden soll, und zwar auf der Basis der jeweiligen Art des Fehlers, der aufgetreten ist, und/oder der Anzahl der vorherigen Versuche. Wenn der Fehler zum Beispiel darauf zurückzuführen ist, dass die Date an dem Datenzentrum 221 nicht zur Verfügung gestanden hat, so kann das CDM 520 sofort erkennen, dass die Behebung nicht möglich ist, und es wird ein Bericht erzeugt 1060, der dies anzeigt. Wenn der Fehler jedoch auf einen Netzwerkstau zurückgeht, so kann das CDM 520 verschiedene Versuche zur Berichtigung des Fehlers vornehmen (d.h. es kann das FTS 525 anweisen, verschiedene Versuche hinsichtlich der Dateioperation vorzunehmen), bevor bestimmt wird, dass die Behebung nicht möglich ist, und wobei ein Bericht 1060 erzeugt wird.
Das CDM 520 kann auch behebbare Fehler auf der Basis der aufeinander folgenden Anzahl eines bestimmten Typs von Fehler erkennen, gerichtet an den gleichen POP über einen Zeitraum. Wenn zum Beispiel aufeinander folgende Dateiübertragungsoperationen, die an einen bestimmten POP gerichtet sind (z.B. Dateiübertragung 1108-1111), während einem Zeitraum von fünf Minuten fehlgeschlagen sind, so kann das CDM 520 dies automatisch so interpretieren, dass es bedeutet, dass der POP während diesem Zeitraum ausgefallen gewesen ist (im Gegensatz zu dem vorstehenden Ausführungsbeispiel, in dem die Mitarbeiter 515 diese Informationen manuell in die Behebungsrichtlinie einfügen). Wenn somit der POP jetzt online ist und Dateiübertragungen akzeptiert, so kann das CDM 520 das FTS 525 anweisen, die Dateiübertragungen und/oder Löschungen erneut versuchen. Zusätzliche Fehlerdetektions- und Korrekturmechanismen können im Einklang mit den zugrunde liegenden Grundsätzen der Erfindung implementiert werden.
Lastausgleich mit virtuellen Internetprotokoll-Adressen
Ein einzelner Server ist für gewöhnlich nicht ausreichend, um Anwendungsdienste bereitzustellen, im Besonderen in Bezug auf Anwendungen mit hoher Bandbreite, wie etwa Live- oder On-Demand-Streaming von Multimedia-Inhalten. In Bezug auf die Abbildung aus 12 wird der Bedarf für diesen Anwendungsdienst in diesen Situationen dadurch erfüllt, dass ein Pool von Ressourcen zur Verfügung gestellt wird, z.B. die Server 1221-1223 und 1231-1232, welche den gegebenen Anwendungsdienst 1220 und 1230 entsprechend unterstützen. In dem veranschaulichten Ausführungsbeispiel wird der Lastausgleich so ausgeführt, dass kein einzelner Server überlastet wird, und wobei die Anwendungsdienste 1220, 1230 ohne Unterbrechungen wiedergegeben werden.
Ein Layer-4-Switch (Transportschicht-Switch) 1200 unterstützt diese Anforderungen, durch die Identifikation des speziellen Typs des Dienstes, der von den Clients 1250-1252 angefordert wird, und zwar auf der Basis einer virtuellen IP-Adresse („VIP"), die dem Dienst zugeordnet ist, und wobei die Anforderungen an einen bestimmten Server (z.B. 1221) in dem dem Dienst zugeordneten Server-Pool gerichtet werden. Wenn der Anwendungsdienst 1220 zum Beispiel so konfiguriert ist, dass alle eingehenden Anforderungen von Webseiten (d.h. HyperText Transport Protocol) behandelt werden, wobei Clients danach eine Verbindung mit der VIP 1202 herstellen, um Webseiten herunterzuladen, wobei diese durch den Layer-4-Switch 1200 zu einem bestimmten Server hinter der VIP 1202 umgeleitet werden.
In einer kennzeichnenden Lastausgleichskonfiguration werden statische Gruppen von Servern den Anwendungsdienst-Pools zugeordnet. In einem Ausführungsbeispiel des vorliegenden Systems werden mehrere Anwendungsdienste eingesetzt unter Verwendung dynamisch konfigurierbarer Server-Pools 1221-1223; 1231-1232, für optimale Ressourcenzuweisung und Fehlertoleranz. Im Besonderen ermöglicht das vorliegende Ausführungsbeispiel Servern (z.B. 1221), die einem Anwendungsdienst 1220 zugeordnet sind, die dynamische neue Zuordnung an einen zweiten Anwendungsdienst 1230 auf der Basis des Bedarfs für diesen Dienst, und oder der aktuellen Belastung an diesem Dienst gemäß der Anzeige in der Abbildung aus 12.
Wenn zum Beispiel antizipiert wird, dass zu einem bestimmten Zeitpunkt ein Live- oder On-Demand-Streaming-Ereignis eine signifikante Menge von Server-Ressourcen erfordert, so kann ein Server 1221 aus einem Pool von Nicht-Streaming-Servern in einen Pool von Streaming-Servern 1231-1232 entfernt werden, in Erwartung dieses Bedarfs. Dies kann automatisch oder manuell durch die Mitarbeiter 515 erreicht werden und abhängig von der Konfiguration einen Neustart der neu zugeordneten Server voraussetzen.
In einem Ausführungsbeispiel spricht der Server-Neuzuweisungsmechanismus dynamisch auf Veränderungen der Netzwerkbelastung an (an Stelle der Antizipation derartiger Veränderungen). Wenn folglich ein Pool von Servern (z.B. 1231, 1232), der für einen bestimmten Anwendungsdienst 1230 reserviert ist, plötzlich einen signifikanten Anstieg der Dienstanforderungen erfährt, kann ein Server 1221, der einem zweiten Anwendungsdienst (z.B. 1220) zugeordnet ist, dynamisch dem ersten Anwendungsdienst 1230 neu zugewiesen werden, um einen Teil der Last zu bearbeiten (in der Annahme, dass der zweite Dienst 1220 keine starke Netzwerkbelastung erfährt). In einem Ausführungsbeispiel überwacht ein im Hintergrund ausgeführtes Überwachungsmodul die Serverbelastung an den verschiedenen Anwendungsdiensten. Wenn die einen Dienst unterstützenden Server überlastet werden, versucht das Überwachungsmodul, einen oder mehrere Server von einem weniger aktiven Anwendungsdienst neu zuzuweisen.
In einem Anwendungsdienst wird die Belastung an jedem der weniger aktiven Anwendungsdienste verglichen, und es wird ein Server von dem Anwendungsdienst mit der geringsten durchschnittlichen Serverbelastung ausgewählt. In einem anderen Ausführungsbeispiel wird die antizipierte Serverbelastung ebenfalls bei der Entscheidung über die neue Zuordnung berücksichtigt. Auch wenn ein bestimmter Anwendungsdienst eine niedrige Serverbelastung erfährt, wird ein Server somit nicht von diesem Anwendungsdienst entfernt, wenn antizipiert wird, dass der Anwendungsdienst in der Zukunft stark belastet ist (z.B. wenn der Anwendungsdienst zur Unterstützung eines stark publizierten, terminierten Streaming-Ereignisses eingesetzt wird).
In einem Ausführungsbeispiel wird die dynamische neue Serverzuweisung über eine Lastdetektierungs- und Steuerlogik 1250 erreicht (z.B. an dem Layer-4-Switch 1200 konfiguriert oder alternativ in einer anderen Netzwerkvorrichtung), welche jeden der Server in den verschiedenen Anwendungsdienstgruppen 1230, 1220 überwacht. In einem Ausführungsbeispiel können hohe und niedrige Belastungsschwellenwerte für die Server und/oder die Anwendungsdienstgruppen 1230, 1220 festgelegt werden. Wenn in einem Ausführungsbeispiel die Belastung der Server in einer Gruppe den hohen Schwellenwert erreicht, versucht die Lastdetektierungs- und Steuerlogik 1250 einen Server (z.B. den Server 1221) aus einer anderen Anwendungsgruppe (z.B. der Anwendungsgruppe 1220) nur dann zu zuzuweisen, wenn die aktuelle Belastung an dem Server (oder dessen Anwendungsdienstgruppe) unterhalb des unteren Schwellenwertes liegt.
Ausführungsbeispiele der vorliegenden Erfindung weisen verschiedene Schritte auf, die vorstehend beschrieben worden sind. Die Schritte können in maschinenlesbaren Anweisungen ausgeführt werden. Die Anweisungen können eingesetzt werden, um es zu bewirken, dass ein Universalprozessor oder ein Prozessor für einen bestimmten Zweck bestimmte Schritte ausführt. Alternativ können diese Schritte durch spezielle Hardwarekomponenten ausgeführt werden, welche eine fest verdrahtete Logik zur Ausführung der Schritte aufweisen, oder durch eine Kombination von programmierten Computerkomponenten und individuelle Hardwarekomponenten.
Elemente der Erfindung können als ein maschinenlesbares Medium zum Speichern der maschinenlesbaren Anweisungen bereitgestellt werden. Das maschinenlesbare Medium kann unter anderem, ohne darauf beschränkt zu sein, folgendes aufweisen: Floppy-Disketten, optische Platten, CD-ROMs und magnetooptische Platten, ROMs, RAMs, EPROMs, Magnet- oder optische Karten, Ausbreitungsmedien oder andersartige Medien/ein maschinenlesbares Medium, das sich zum Speichern elektronischer Anweisungen eignet. Die vorliegende Erfindung kann zum Beispiel als ein Computerprogramm heruntergeladen werden, das von einem entfernten Computer (z.B. einem Server) zu einem anfordernden Computer (z.B. einem Client) durch Datensignale übertragen werden kann, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über einen Datenübermittlungsabschnitt (z.B. ein Modem oder eine Netzwerkverbindung) enthalten bzw. ausgeführt sind.
Zu Erläuterungszwecken sind in der vorstehenden Beschreibung zahlreiche spezifische Einzelheiten ausgeführt, um ein umfassendes Verständnis der vorliegenden Erfindung zu vermitteln. Für den Fachmann auf dem Gebiet ist es jedoch ersichtlich, dass die vorliegende Erfindung auch ohne einige dieser spezifischen Einzelheiten ausgeführt werden kann. Folglich ist der Umfang der vorliegenden Erfindung durch die folgenden Ansprüche zu bestimmen.

Claims

Datenzentrum (220-222), das eine Mehrzahl von Servern zum Speichern von digitalem Multimedia-Streaming-Inhalten und zum automatischen Verteilen von digitalem Multimedia-Streaming-Inhalten auf der Basis einer Verteilungsrichtlinie umfasst, für eine Replizierung an einer Mehrzahl von intermediären und Flanken-Points-of-Presence, wobei das Datenzentrum ferner eine Datenbank (530) umfasst, mit einer Mehrzahl von Inhaltsdatensätzen; wobei jeder der Datenkban-Inhaltsdatensätze eine Zuordnung zwischen dem digitalen Multimedia-Streaming-Inhalt und einem oder mehreren intermediären Points-of-Presence bereitstellt.
Verteilte Flankennetzwerkarchitektur (200), die folgendes umfasst: ein Datenzentrum (220-222) nach Anspruch 1; eine Mehrzahl von intermediären Points-of-Presence, POP, Sites (230-234), die mit dem genannten Datenzentrum kommunizieren, wobei jede der genannten POP-Sites einen oder mehrere Server aufweist, auf denen Teile des genannten digitalen Multimedia-Streaming-Inhalts repliziert werden, die in dem genannten Datenzentrum gespeichert werden; und eine Mehrzahl von Flanken-POP-Sites (240-245) zur Kommunikation mit Endnutzern und mit einem oder mehreren der genannten intermediären POP-Sites, und wobei jede Flanken-POP-Site einen oder mehrere Server zum Caching von Teilen des genannten digitalen Multimedia-Streaming-Inhalts aufweist, der von den genannten Endnutzern angefordert wird; wobei der Inhalt an den genannten intermediären POPs und den genannten Flanken-POPs repliziert wird.
Inhaltverteilungsarchitektur (200) nach Anspruch 2, wobei diese ferner ein oder mehrere zusätzliche Datenzentren (220-222) zum Speichern von digitalem Multimedia-Streaming-Inhalt und zum Kommunizieren mit der genannten Mehrzahl von intermediären POP-Sites (230-234) umfasst.
Inhaltverteilungsarchitektur (200) nach Anspruch 2, wobei diese eine größere Anzahl von Flanken-POPs (240-245) als intermediäre POPs (230-234) umfasst sowie eine größere Anzahl intermediärer POPs (230-234) als Datenzentren (220-222).
Architektur (200) nach Anspruch 2, wobei die genannten Flanken-POPs (230-245) gemeinsam bei einem oder mehreren Internet Service Providern angeordnet sind.
Architektur (200) nach Anspruch 2, wobei die genannten intermediären POPs (230-234) über einen privaten, dedizierten Kommunikationskanal kommunikativ mit dem genannten Datenzentrum (220-222) gekoppelt sind.
Verfahren zum Verteilen von Multimedia-Streaming-Inhalt in einem Computernetzwerk (200), wobei das Verfahren folgendes umfasst: das Empfangen des genannten Multimedia-Streaming-Inhalts an einem Datenzentrum (220-222); das Kopieren, automatisch gemäß einer Verteilungsrichtlinie, des Multimedia-Streaming-Inhalts von dem genannten Datenzentrum an eine oder mehrere intermediäre POP-Sites (230-234); und das Kopieren des Multimedia-Streaming-Inhalts von einer der intermediären POP-Sites (230-234) an eine oder mehrere Flanken-POP-Sites (240-245); und das Aktualisieren einer Inhalts-Datenbank (530) an dem genannten Datenzentrum, wenn der genannte Multimedia-Streaming-Inhalt an dem genannten Datenzentrum (220-222) empfangen wird, und wenn der genannte Multimedia-Streaming-Inhalt in die genannten intermediären POP-Sites (230-239) und die genannten Flanken-POP-Sites (240-245) kopiert wird, wobei die genannte Datenbank (530) den genannten intermediären POP-Sites (230-234) und den Flanken-POP-Sites (240-245) anzeigt, in welche Sites der genannte Multimedia-Streaming-Inhalt kopiert wird.
Verfahren nach Anspruch 7, wobei der genannte an dem genannten Datenzentrum (220-222) empfangene Multimedia-Streaming-Inhalt von einem Inhalteanbieter übermittelt wird.
Computerprogramm, das einen Code umfasst, um ein Verfahren oder ein System gemäß einem der vorstehenden Ansprüche zu implementieren.
Computerspeicher, der ein Computerprogramm gemäß Anspruch 9 speichert.