DE60036021T2 - System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt - Google Patents

System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt Download PDF

Info

Publication number
DE60036021T2
DE60036021T2 DE60036021T DE60036021T DE60036021T2 DE 60036021 T2 DE60036021 T2 DE 60036021T2 DE 60036021 T DE60036021 T DE 60036021T DE 60036021 T DE60036021 T DE 60036021T DE 60036021 T2 DE60036021 T2 DE 60036021T2
Authority
DE
Germany
Prior art keywords
content
server
network
client
request
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 - Lifetime
Application number
DE60036021T
Other languages
English (en)
Other versions
DE60036021D1 (de
Inventor
Steven Berkeley McCANNE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Yahoo Inc
Original Assignee
Yahoo Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Yahoo Inc filed Critical Yahoo Inc
Application granted granted Critical
Publication of DE60036021D1 publication Critical patent/DE60036021D1/de
Publication of DE60036021T2 publication Critical patent/DE60036021T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1014—Server selection for load balancing based on the content of a request
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/563—Data redirection of data network streams
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • 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

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft die effiziente Übertragung von Daten in einem Netzwerk wie etwa dem als das "Internet" bekannten globalen Netzwerk. Insbesondere betrifft die vorliegende Erfindung das Verschieben von Live- oder gespeicherten "Broadcast"-Datenströmen von Herstellern von Inhalten zu großen Zahlen von Empfängern dieser Datenströme.
  • "Broadcast" bezieht sich auf die Übertragung eines Datenstroms von einem Inhaltehersteller an eine große Anzahl von Empfängern. Bei dem Datenstrom kann es sich um Text, Grafik, Video, Audio, oder jeglichen anderen digitalen Datenstrom handeln. Daten werden häufig als ein Stream oder als eine Datei zur Verfügung gestellt, die sich dadurch unterscheiden, dass das Ende des Streams offen ist, während die Datei ein definiertes Ende besitzt. Beispielsweise könnte man sich Echtzeit-Börsennotierungen als einen Strom von Daten, eine 30-minütige audiovisuelle Präsentation hingegen als eine Datei mit Daten vorstellen. Gemäß der vorliegenden Bezugnahme ist keine scharfe Unterscheidung zwischen einem Stream und einer Datei erforderlich, da der typische Broadcast-Betrieb sehr ähnlich ist, ob nun ein Stream übertragen wird oder eine Datei übertragen wird. Es ist daher anzumerken, dass bei einer Beschreibung eines Streams ebenso gut eine Datei an dessen Stelle stehen könnte, falls nicht anders angegeben.
  • Broadcast braucht relativ zur Erzeugung des Inhalts nicht in Echtzeit zu erfolgen. Echtzeit-Broadcast bezieht sich auf die Übertragung der Daten so, wie sie in einer digitalen Form erzeugt wurden. Beispielsweise könnte ein Football-Spiel von einer Kamera aufgezeichnet, digitalisiert und in einem Broadcast an viele Einzelpersonen, welche die Übertragung über das Internet empfangen möchten, gesendet werden. Das Football-Spiel könnte auch nach der Digitalisierung gespeichert und zu einem späteren Zeitpunkt in einem Broadcast gesendet werden. Außerdem könnte das Football-Spiel sowohl live übertragen als auch zu einem späteren Zeitpunkt übertragen werden ("verzögertes Broadcast"). Allgemein gesprochen könnten einige der Komponenten eines Broadcast-Netzes unabhängig davon, ob das Broadcast live oder verzögert ist, auf genau die gleiche Weise arbeiten, wie dies bei einer gegenwärtigen Fernsehausstrahlung der Fall ist. Beispielsweise arbeiten die Antennen zum Ausstrahlen des Signals und die Empfänger zum Empfangen des Signals auf identische Weise, um Live-Sendungen oder verzögerte Sendungen zu empfangen.
  • Ein technischer Unterschied zwischen Live-Broadcast und verzögertem Broadcast ist, dass das Live-Broadcast zum Zeitpunkt des Broadcast eine höhere Publikumszahl hat, da es nur einen Zeitpunkt gibt, um sich in ein Live-Broadcast einzuschalten, aber viele Zeitpunkte für ein verzögertes Broadcast verfügbar sein könnten. Einige Inhalte werden von Empfängern wahrscheinlich als Live-Broadcast einem verzögerten Broadcast vorgezogen. Beispiele umfassen Sportereignisse, zeitproblematische Geschäftsinformationen wie etwa Börsennotierungen, Analysteninterviews und Schlagzeilen, und dergleichen.
  • Die Trennlinie zwischen Live- und verzögertem Broadcast ist nicht fest. Eine der Herausforderung des Live-Broadcast ist es, den Datenstrom in Echtzeit zu verarbeiten, um ihn für eine Übertragung geeignet zu machen (z.B. Komprimierung, Formatierung), wohingegen mehr Zeit für solche Verarbeitungsschritte verfügbar ist, falls der Datenstrom eine verzögertes Broadcast ist. Auch wenn diese Herausforderung eine Unterscheidung zwischen Live- und verzögertem Broadcast akzentuiert, falls die verzögerten Broadcasts nur zu festgelegten Zeiten verfügbar sind – was bei Wiederholungen im Fernsehen der Fall ist – unterscheiden sich Live- und verzögertes Broadcast nicht sonderlich. Weil die Trennlinie nicht immer klar ist, ist anzumerken, dass sich "Broadcast", falls nicht anders angegeben, auf Live- und/oder verzögertes Broadcast bezieht.
  • Im Vergleich mit den derzeitigen Forderungen von Internet-Anwendern sind Fernsehausstrahlungen derzeit einfach: die Erzeuger von Inhalten liefern ihre Inhalte an die Sendestationen, die den Datenstrom in einen Kanal aussenden, der exklusiv für dessen Inhalte reserviert ist und die Bandbreite besitzt, um diese Inhalte in der zugewiesenen Zeit zu übertragen, und das Übertragungsmedium (fest verdrahtet oder drahtlos) und die Empfänger alle mit dem Medium mit einer Bandbreite verbunden sind, die ausreichend ist, um den gesamten Datenstrom mit minimaler Verarbeitung von einem speziell für diese Inhalte reservierten Kanal zu empfangen. Das Broadcast von Inhalten über das Internet (oder jegliches andere verwendete Netzwerk oder Netz) ist jedoch nicht einfach durchführbar, da das Internet oder Netz im Wesentlichen ein Punkt-zu-Punkt-Übertragungsmedium ist, bei dem einige Vorkehrungen für Punkt-zu-Mehrpunkt- oder Mehrpunkt-zu-Mehrpunkt-Übertragung getroffen sind.
  • Als Beispiel befasst sich Broadcast-Fernsehen mit einem Schlagzeilenereignis, indem Information gesammelt, ein Script geschrieben, und ein Reporter auf Sendung gebracht wird. Die Empfänger der Schlagzeilen (die Fernsehzuschauer) müssen darauf warten, dass der Fernsehsender die Informationen ausstrahlt, und erhalten nur den Datenstrom, der von diesem Inhalteprovider zur Präsentation ausgewählt wird. Im Falle von Schlagzeilen auf dem Internet versucht eine große Anzahl von Anwendern, die Nachrichteninformationen abzurufen (im Wesentlichen als eine große Anzahl von Punkt-zu-Punkt-Übertragungen des gleichen Datenstroms), wodurch häufig die Server und die Recheninfrastruktur der Inhalteprovider lahm gelegt werden. Dieser "Flash-Effekt" ist nicht auf Schlagzeilen beschränkt, sondern ist auch häufig anzutreffen, wenn Live-Events stattfinden, wenn neue Versionen einer beliebten Software herausgegeben werden, oder wenn eine populäre Website angetroffen wird. Hierbei bezieht sich eine "Website" im Allgemeinen auf eine Ansammlung von Seiten, die als Einheit präsentiert und üblicherweise von einem oder mehreren koordinierten Servern mit einer bestimmten Netzwerkadresse dargeboten werden, und kann sich auch auf die Computer und die Infrastruktur beziehen, welche die Seiten der Ansammlung darbieten.
  • Die Probleme der gegenwärtigen Broadcast-Lösungsansätze werden im Nachfolgenden beschrieben, jedoch ist zuerst eine gewisse Hintergrundinformation zur Client-Server-Architektur angebracht. Bei vielen Vernetzungs- und anderen Rechensystemen ist die Verarbeitung und Funktionalität des Systems ingesamt in "Clients" und "Server" aufgeteilt, wobei es sich bei den Clients um Computer, Programme oder Hardware handelt, die Anfragen initiieren, und wobei es sich bei den Servern um Computer, Programme oder Hardware handelt, die auf Anfragen von Clients antworten. Es gibt Ausnahmen, bei denen Vorrichtungen oder Programme, die im Allgemeinen als Server betrachtet werden, Anfragen an Vorrichtungen oder Programme stellen, die im Allgemeinen als Clients betrachtet werden, jedoch warten im Client-Server-Modell überwiegend die Server auf Anfragen, bedienen die Anfragen, und warten dann auf weitere Anfragen. Clients werden für gewöhnlich insofern als unabhängigere Akteure angesehen, als sie Anfragen initiieren. Es ist jedoch anzumerken, dass einige Vorrichtungen oder Hardware zu bestimmten Zeiten oder für bestimmte Zwecke Clients sein könnten und zu anderen Zeiten oder für andere Zwecke Server sein könnten.
  • Im Kontext einer extrem grundlegenden Broadcast-Infrastruktur wartet ein Content Server auf eine Anfrage von einem Content Client und sendet bei Empfang einer Anfrage die angeforderten Inhalte an den Content Client. Diese grundlegende Infrastruktur ist kein Problem, wenn ein Client eine Anfrage an einen Server stellt und die Inhalte in die ungenutzte Bandbreite eines den Client und den Server verbindenden Kanals passen; da aber die meisten Netze mehr als einen Client oder mehr als einen Server umfassen und sich eine begrenzte Bandbreite teilen, muss die Bandbreite auf intelligente Weise zugewiesen werden.
  • Aus einer Perspektive der Infrastruktur ist der Flash-Effekt nicht sehr bandbreiteneffizient, da viele, viele identische Kopien des Datenstroms über das Netz zu den vielen Empfängern transportiert werden, die den Datenstrom anfordern. Dieser Effekt ist möglicherweise kein Problem, falls es sich bei dem Datenstrom um einige wenig Datenbits handelt, aber Datenströme mit Full-Motion-Video und CD-Qualität-Audio werden immer üblicher.
  • In der Vergangenheit wurden mehrere verschiedene Lösungsansätze unternommen, um Broadcast über das Internet zur Verfügung zu stellen, jedoch weisen die meisten von diesen Nachteile auf, die ihre verbreitete Anwendung verhindern. Zwei Schlüsselmechanismen wurden für das Internet vorgeschlagen und sind in eingeschränktem Gebrauch, um die durch den Flash-Effekt hervorgerufenen Probleme zu überwinden, nämlich 1) Cachen und 2) Serverreplikation bzw. Serverabgleich. Cachen bezieht sich auf einen Vorgang unter Verwendung eines Cache-Speichers, der sich an strategischen Stellen innerhalb der Netzinfrastruktur befindet, um Inhaltsanfragen von Clients abzufangen, so dass die Inhaltsquelle nicht jede Kopie der Inhalte zur Verfügung zu stellen braucht. Wenn ein Client Inhalte von einem Content Server anfordert und der Client die Inhalte vom Content Server empfangt, speichert ein Cache-Speicher in dem Netz, das die Inhalte durchlaufen, eine Kopie der Inhalte. Wenn ein anderer Client (oder der gleiche Client) eine Anfrage für diese gleichen Inhalte stellt, konsultiert die Netzinfrastruktur den Cache-Speicher, um festzustellen, ob eine Kopie der angeforderten Inhalte in dem Cache-Speicher vorhanden ist. Falls die Inhalte in dem Cache-Speicher vorhanden sind, wird die Anfrage abgefangen, bevor sie den Content Server erreicht, und der Cache-Speicher bedient stattdessen die Anfrage. Im anderen Fall, in dem die Inhalte nicht im Cache-Speicher vorhanden sind, wird die Anfrage an den Content Server weiter geleitet, und die Antwort wird zurück an den Client geleitet.
  • Cachen ist von Nutzen, wenn eine hohe Wahrscheinlichkeit besteht, dass die angeforderten Inhalte im Cache-Speicher vorliegen könnten. Da der Cache-Speicher eine begrenzte Speicherkapazität besitzt, die für das Speichern gecacheter Inhalte zugewiesen ist, muss der Cache-Speicher letztendlich einige seiner gespeicherten Inhalte entfernen, um Platz für neuere oder populärere Inhalte zu schaffen. Viele Strategien wurden vorgeschlagen und sind in Verwendung, um den lokalen Speicher des Cache-Speichers zu verwalten, z.B. Entscheiden, wann ein Objekt aus dem Cache-Speicher entfernt werden soll, warm Inhalte "aufgefrischt" (eine frische, möglicherweise aktualisierte Kopie der Inhalte vom Content Server besorgt) werden sollen, und so weiter.
  • Cachen kann entweder transparent oder nicht-transparent sein. Bei transparentem Cachen stellt der Client eine Anfrage an den Content Server, und die Netz-Infrastruktur fängt die Anfrage ab, falls der Cache-Speicher die Anfrage bedienen kann. Bei nicht-transparentem Cachen stellt der Client die Anfrage an den Cache-Speicher (oder genauer gesagt an einen Netzknoten, an den der Cache-Speicher angeschlossen ist), und der Cache-Speicher bedient die Anfrage, wenn er kann, oder er leitet die Anfrage an den Content Server weiter, woraufhin der Client die von dem Content Server zurückgesendeten Inhalte liefert.
  • Der Serverreplikationsmechanismus beinhaltet replizierte Server, von denen jeder Kopien der gleichen gelieferten Inhalte führt. Bevorzugt sind die replizierten Server über einen weiten Bereich des Netz installiert, und Client-Anfragen an einen Content Server werden an einen dieser verteilten, replizierten Server umgeleitet, um die Belastung auszugleichen und Netzbandbreite zu sparen. Beispielsweise falls die Anfragen stellenden Clients sämtlich an einem Netzzugangspunkt mit einem Netz verbunden sind und sich der Content Server am entgegengesetzten Ende des Netzes befindet, könnten die replizierten Server nahe dem Client-Netzzugangspunkt angeordnet sein, so dass die Inhalte nicht das gesamte Netz zu durchlaufen brauchen. Diese replizierten Server können einige oder alle der Inhalte aufweisen, die im Ursprungs-Content Server enthalten sind, und viele Variationen existieren für die Anordnung bestimmter Server in einer replizierten Server-Installation für die Verteilung von Inhalten an die replizierten Server vom Ursprungs-Content Server, sowie für eine Bestimmung, wie Clients zu dem geeigneten replizierten Server umgeleitet werden.
  • Ein ähnliches Problem mit der Verteilung von Inhalten beinhaltet das Liefern von Live Streaming Media an viele Anwender über das Internet. Bei Live Streaming Media erzeugt ein Server eine Live-Broadcast-Einspeisung, und Clients stellen unter Verwendung von Streaming Media-Transportprotokollen eine Verbindung mit dem Server her, um die Sendung zu empfangen, während sie erzeugt wird. Während sich immer mehr Clients in die Sendung einschalten, werden der Server und das Netz in der Nähe des Servers von der Aufgabe, eine große Anzahl von Paketströmen an eine große Anzahl von Clients zu liefern, überwältigt. Diese Aufgabe beinhaltet eine unnötige Duplizierung, weil der Server mehrere Streams mit den gleichen Daten (einen Stream pro Client) aussendet.
  • Die Duplizierung existiert aus dem Grunde, dass jede Verbindung von einem Client zum Server eine "Unicast"-Verbindung, d.h. eine Einpunkt-zu-Einpunkt-Verbindung ist. Die grundlegende Verbindung zwischen zwei Punkten in einem Netz wie etwa dem Internet ist eine Unicast-Verbindung. Obgleich Unicast-Daten über viele verschiedene Pfade (Routen) fließen können, können sie als Daten von einem Quellknoten an einer Quelladresse an einen Zielknoten an einer Zieladresse identifiziert werden. Aus diesem Grund benötigt jeder Client seine eigene Verbindung mit dem Server, und der Datenstrom wird in dem Netz so oft dupliziert, wie diesen Datenstrom anfordernde Clients vorhanden sind.
  • Network-Multicasting löst das Problem einer unnötigen Duplizierung von Datenströmen. Multicasting an der Netzschicht kann über das Internet unter Verwendung von IP-Multicast-Protokollen durchgeführt werden, die in der Internet-Architektur definiert sind. Bei Multicast überträgt ein Content Server den Datenstrom als einen einzelnen Strom von Paketen, der an eine "Multicast-Gruppe" adressiert ist, anstatt individuelle Kopien des Stroms an individuelle Unicast-Adressen zu senden. Während ein Client normalerweise nur Pakete empfängt, die an die Unicast-Adresse dieses Clients adressiert sind, kann sich ein Client, der sich für den Multicast-Strom interessiert, in die Sendung "einschalten", indem er der Multicast-Gruppe beitritt. Bei IGMP (dem Internet Group Management Protocol) nimmt der Client an einer "IP-Multicast"-Gruppe teil, indem er dem nächsten Router Teilnahmeinformationen signalisiert. Das Netz liefert das Broadcast auf effiziente Weise zu jedem empfangenden Client, indem es nur eine Kopie des Datenstroms trägt und zusätzliche Kopien nur an Ausfächerpunkten im Verteilungspfad von der Quelle (dem Content Server) zu den Empfängern ausfächert. Somit erscheint auf jeder physischen Verbindung nur eine Kopie von jedem Paket.
  • Unglücklicherweise haben eine breite Vielfalt von Installations- und Skalierbarkeitsproblemen die Akzeptanz und Verbreitung von IP-Multicast im globalen Internet untergraben. Viele dieser Probleme ergeben sich im Grunde aus der Tatsache, dass das Berechnen eines Multicast-Verteilungsbaums es erforderlich macht, dass alle Router in dem Netz eine gleichförmig übereinstimmende Sicht vom Aussehen dieses Baumes haben müssen. Um IP-Multicasting effektiv zu verwenden, muss jeder Router die korrekte lokale Sicht von einem einzelnen, global übereinstimmenden Multicast-Weiterleitungsbaum haben. Falls Router unterschiedliche Sichten von einem gegebenen Multicast-Baum in verschiedenen Teilen des Netzes haben, sind Weiterleitungsschleifen und schwarze Löcher unvermeidlich. Eine Anzahl von anderen Problemen – z.B. Multicast-Adressenzuweisung, Multicast-Stausteuerung, zuverlässige Lieferung für Multicast usw. – haben ebenfalls die Installation und Akzeptanz von IP-Multicast beeinträchtigt. Trotz wesentlicher neuerer Schritte in Richtung auf eine kommerzielle Installation von IP-Multicast ist die resultierende Infrastruktur noch vergleichsweise schwach, und ihre Reichweite ist äußerst beschränkt.
  • Es gab nicht nur wesentliche technische Barrieren gegen die Installation eines allgegenwärtigen Internet Multicast-Dienstes, sondern es gibt außerdem auch geschäftliche und wirtschaftliche Barrieren. Internet-Serviceprovider waren nicht sehr erfolgreich beim Anbieten von Weitbereichs-Multicast-Diensten, weil die Verwaltung, Überwachung und Bereitstellung für den Multicast-Verkehr ziemlich schwierig ist. Darüber hinaus ist es schwierig zu steuern, wer in einer Multicast-Sitzung einen Verkehr erzeugen kann, und welche Teile des Netzes dieser Verkehr erreichen darf. Diese Probleme werden sogar noch größer, wenn Serviceprovider versuchen, sich zusammenzuschließen ("peering"), um einen weiter reichenden Multicast-Dienst anzubieten, was sie für den traditionellen Unicast-Dienst mit überwältigendem Erfolg geschafft haben. Wegen dieser Barrieren ist das Zustandekommen eines Multicast-Dienstes, der den Großteil des Internet erreicht, unwahrscheinlich, und ein solches Zustandekommen in der nahen Zukunft ist sehr unwahrscheinlich.
  • Andere haben Ausweichlösungen wie etwa Splitter-Netze vorgeschlagen, um die Schwierigkeiten des Multicast zu umgehen. Ein Splitter-Netz ist eine Anwendungsschicht-Lösung zum Transportieren von Streaming Media-Broadcasts, wobei eine Gruppe von Server über ein Netz an strategischen Stellen über das Internet verteilt ist. Beispielsweise könnte ein Datenlieferant eine Kollokation von Splittern am Ort eines ISP (Internet Service Provider) vornehmen oder mit dem ISP eine Abmachung für eine großflächige Installation innerhalb des Netzes des ISP treffen. Beispielsweise stellt RealNetworks in Seattle, Washington, die Lieferung von Streaming Media zur Verfügung. Die Verteilung findet insofern auf Anwendungsniveau statt, als ein RealNetworksTM G2-Server G2 Datenströme an G2-Clients senden könnte.
  • Diese verteilten Server sind mit einer "Splitting"-Fähigkeit konfiguriert, die es ihnen ermöglicht, einen gegebenen Strom an eine Anzahl von dahinter befindlichen Servern zu replizieren. Mit dieser Fähigkeit können Server in einer baumartigen Hierarchie angeordnet werden, in der der Root-Server einen Strom an eine Anzahl von dahinter befindlichen Servern sourct, die den Strom wiederum in eine Anzahl von Kopien aufteilen, die dann zu einer weiteren Reihe von dahinter befindlichen Servern weiter geleitet werden.
  • Unglücklicherweise leidet ein Splitter-Netz von Servern an einer Anzahl von Problemen. Erstens ist der Baum von Splittern statisch konfiguriert, was bedeutet dass, falls ein einzelner Splitter ausfällt, der gesamte Unterbaum unterhalb des Ausfallpunktes an Dienst verliert. Zweitens muss das Splitter-Netz auf eine einzelne Broadcast-Zentrale ausgerichtet sein, was separate Splitter-Netze erforderlich macht, die aus separaten physischen Server zusammengesetzt sind und für jedes Broadcast-Netz aufrecht erhalten werden müssen. Drittens sind Splitter typischerweise für ein Datenstromformat spezifisch, was den Splitter plattformabhängig macht. Beispielsweise kann ein Splitter, der eingerichtet ist, um RealNetworkTM-Datenströme zu tragen, keine MicrosoftTM NetshowTM-Datenströme tragen. Viertens sind Splitter-Netze stark bandbreitenineffizient, da sie kein Empfängerinteresse verfolgen und Verkehr aus Unterbäumen des Splitter-Netzes, die keine dahinter liegenden Empfänger aufweisen, ausgliedern. Schließlich stellen Splitter-Netze schwache Richtlinienkontrollen zur Verfügung – die zusammengesetzte Bitrate, die entlang eines Pfades zwischen zwei Splitter-Knoten verbraucht wird, kann nicht gesteuert und verschiedenen Klassen von Flüssen auf eine strombewusste Weise zugewiesen werden.
  • Wieder ein anderer Lösungsansatz, um die Probleme von Multicast zu vermeiden, ist es, die Inhalte an mehrere Stellen um ein Netz zu senden und den Client einen Test durchführen zu lassen, um den am wenigsten ausgelasteten Pfad zu einem Server zu bestimmen, der die betreffenden Inhalte aufweist. Der Client verbindet sich dann mit dem Server, der den am wenigsten überlasteten Pfad zum Client zeigt. Obgleich dies im Vergleich mit stromzentrierten Anwendungen gut für dateizentrierte Anwendungen ist, weist dieser Lösungsansatz Nachteile auf. Beispielsweise, obgleich der Client möglicherweise einen Server mit geringer Auslastung findet, wird wenig oder gar nichts unternommen, um sicher zu stellen, dass der zu bestimmten Clients am nächsten befindliche Server diejenigen Daten aufweist, die diese Clients am meisten anfordern. Ein weiteres Problem ist, dass viele Anwendungen Live-Broadcasts sind und die Lieferung der Daten daher zeitproblematisch ist, und die Daten schnell zu den Edge Servern verschoben werden müssen, welche die an dem Live-Broadcast interessierten Clients bedienen, während sie den Betrag an Netzstau beschränken, der in dem Netz auftritt, der nicht für Anwender mit einem Interesse an den Broadcasts bestimmt ist.
  • Die EP-A2-0817444 beschreibt ein Domainnamen-Auflösungssystem, bei dem der Server innerhalb des Netzes des Serviceproviders, von dem aus der anfragende Anwender weiter geleitet wird, um Informationen zu erhalten, basierend auf Eigenschaften des anfragenden Anwenders bestimmt wird, wobei sich der Server und/oder die Informationen auf die Anfrage oder die angeforderten Inhalte beziehen.
  • Die WO-A1-99/06913 beschreibt einen Switch, der unmittelbar mit einer Mehrzahl von Content Servern verbunden ist. Der Switch führt einen Lastausgleich zwischen den Servern basierend auf ihrer Verfügbarkeit und auf Eigenschaften der angeforderten Inhalte und der Dienstgüteerfordernisse des anfragenden Clients durch.
  • Die WO-A2-98/57275 beschreibt eine Anordnung zum Teilen von Netzverkehr zwischen replizierten Servern basierend auf der geografischen Lage der Server und der Ressourcenverfügbarkeit.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Eine Ausführungsform der vorliegenden Erfindung stellt eine verbesserte Datenstrom-Broadcast-Verteilung unter Anwendung eines gemeinsamen Anbietens von Inhalten (Content Peering) zur Verfügung. Ein Aspekt der Erfindung ist in dem nebengeordneten Anspruch dargelegt, und bevorzugte Merkmale sind in den Unteransprüchen dargelegt.
  • Gemäß einem Aspekt wird ein Verfahren zum Liefern von Inhalten an einen Client in einem Netzwerk, welches eine Vielzahl von Content Servern mit einer Vielzahl von Clients verbindet, wobei die Clients nach einer Inhalte bereitstellenden Verbindung über Internet-Serviceprovider suchen, zur Verfügung gestellt, wobei die Inhalte sich zu Beginn auf einem Content Server befinden und in das Netzwerk an einem Einspeisungspunkt eingespeist werden, wobei mindestens zwei Internet-Serviceprovider eine Verknüpfung für ein gemeinsames Anbieten von Inhalten (Content Peering Relationship) haben, wobei der erste Internet-Serviceprovider Inhalte an Clients überträgt und liefert, welche mit dem zweiten Internet-Serviceprovider verbunden sind, und der zweite Internet-Serviceprovider Inhalte an Clients überträgt und liefert, welche mit dem ersten Internet-Serviceprovider verbunden sind, wobei eingespeiste Inhalte von dem Einspeisungspunkt unter den gemeinsam Inhalte anbietenden Internet-Serviceprovidern aufgeteilt werden, wobei das Verfahren aufweist: Empfangen einer Anfrage nach Inhalten von dem Client; und Leiten der Anfrage an einen Content Server, auf der Grundlage von Verknüpfungen zwischen den Internet-Serviceprovidern für ein gemeinsames Anbieten von Inhalten, unter Verwendung von Anycast-Routing.
  • Bevorzugt wird die Anfrage an eine Anycast-Adresse gerichtet, welche zu Vorrichtungen in einem ersten autonomen System zugeordnet ist, wobei das Verfahren ferner ein Leiten der Anfrage an die nächste der Vorrichtungen einschließt, denen die Anycast-Adresse zugeordnet ist.
  • Bevorzugt wird die Anfrage an eine Anycast-Adresse gerichtet, welche zu Vorrichtungen in einem ersten autonomen System zugeordnet ist, wobei das Verfahren ferner ein Leiten der Anfrage an eine Vorrichtung innerhalb eines zweiten, an das erste autonome System angegliederten, autonomen Systems einschließt.
  • Bevorzugt wird eine Umleitungsstruktur für ein Weiterleiten der Anfrage an den Content Server auf der Grundlage von Verknüpfungen für ein gemeinsames Anbieten von Inhalten bereitgestellt, wobei die Umleitungsstruktur dafür eingerichtet ist, den Client an einen Edge Server auf der Grundlage von einer Client-Umgebung, von Netzwerkpfadcharakteristika, von Server-Auslastung und -Ausnutzung und auf der Grundlage von der Verknüpfung für ein gemeinsames Anbieten von Inhalten anzuschließen.
  • Die Umleitungsstruktur kann dafür eingerichtet sein, die Anfrage an den Content Server auf der Grundlage von im Hintergrund erfassten Auslastungs- und Netzwerkmesswerten weiterzuleiten.
  • Bevorzugt ist ein Verteilernetzwerk zum Verteilen der Inhalte vom Einspeisungspunkt an eine Server-Anordnung eingerichtet.
  • Bevorzugt umfasst das Verfahren ferner einen Schritt aufweisend: Verteilen an Umleitungsvorrichtungen, welche Anwendungsschicht-Multicast-Routing verwenden, von mindestens einem aus: Richtlinien für ein Weiterleiten von Inhalten, Server-Auslastungsinformation, Ressourcenverfügbarkeit und Abgleichinformation.
  • Die Anfrage kann eine explizite Serviceanfrage an eine Anycast-Adresse aufweisen, um eine topologische Lage über Anycast-Routing einzuschließen.
  • Die Anfrage kann auf der Grundlage des topologischen Lage-Zusammenhangs geleitet werden.
  • Bevorzugt umfasst das Verfahren ferner die Verwendung von einer Umleitung in entfernten autonomen Systemen, um einen Lastausgleich bei einer Vielzahl von Servern in nahegelegenen autonomen Systemen durchzuführen.
  • Ein weiter reichendes Verständnis der Beschaffenheit und der Vorteile der vorliegenden Erfindungen ist durch Bezugnahme auf die übrige Beschreibung und die beigefügte Zeichnung erhältlich.
  • Einzelheiten von Systemen und Verfahren, die in Verbindung mit der Erfindung implementiert werden können, sind auch in den folgenden, verwandten Patentanmeldungen zu finden: US-Patent Nr. US6785704 mit der Bezeichnung "A Content Distribution System for Operation Over An Internetwork Including Content Peering Arrangements"; US-Patent Nr. US6415323 mit der Bezeichnung "A Proximity-Based Redirection System For Robust and Scalable Service-Node Location In An Internetwork" (im Nachfolgenden: McCanne et al. I"); US-Patent Nr. US6415323 mit der Bezeichnung "A Proximity-Based Redirection System For Robust and Scalable Service-Node Location In An Internetwork" (im Nachfolgenden: McCanne et al. II"); US-Patent Nr. US6611872 mit der Bezeichnung "Performing Multicast Communica tion In Computer Networks By Using Overlay Routing" (im Nachfolgenden: McCanne I").
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • 1 ist ein Blockdiagramm eines verallgemeinerten Client-Server-Netzsystems.
  • 2 ist ein Blockdiagramm, welches das in 1 gezeigte Netz in mehr Detail zeigt.
  • 3 ist ein Blockdiagramm eines Netzes mit einer Leitungsstruktur.
  • 4 ist ein Blockdiagramm, das einen Abschnitt des Netzes von 3 zeigt, das Server umfasst, die mit Routern in dem Netz gekoppelt sind.
  • 5 ist ein Blockdiagramm zur Veranschaulichung der Netzpfade, die für eine Client-Anforderung von Inhalten und eine darauf folgende Server-Antwort mit den Inhaltsanfragen verwendet werden.
  • 6 ist ein Blockdiagramm zur Veranschaulichung der Verwendung eines Verteilernetzwerks und einer Umleitungsstruktur gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 7 ist ein Blockdiagramm zur Veranschaulichung eines in einem Backbone-ISP verankerten Inhalte-Backbones.
  • 8 ist ein Netzdiagramm zur Veranschaulichung eines stark belasteten Inhalte-Backbone.
  • 9 ist ein Netzdiagramm zur Veranschaulichung von Peering mit APAR-Anycast-Umleitungsvorrichtungsknoten.
  • 10 ist ein Netzdiagramm zur Veranschaulichung des Systems von 9 mit einer zusätzlichen Peering-Anordnung.
  • 11 ist ein Netzdiagramm zur Veranschaulichung von einander angegliederten Inhalte-Backbones.
  • 12 ist ein Netzdiagramm zur Veranschaulichung einer APAR-DNS-Umleitungsarchitektur.
  • 13 ist ein Netzdiagramm zur Veranschaulichung der inkrementellen Installation einer APAR-DNS Umleitungsarchitektur.
  • 14 ist ein Netzdiagramm zur Veranschaulichung der inkrementellen Installation einer APAR-DNS-Umleitungsarchitektur, in der autonome Systeme keine gemeinsam angeordneten Server aufweisen.
  • 15 ist ein Netzdiagramm zur Veranschaulichung einer expliziten Umleitung.
  • 16 ist ein Netzdiagramm eines Netzes, bei dem explizite Umleitungsvorrichtungen über die Kanten von autonomen Systemen hinaus installiert sind.
  • 17 veranschaulicht eine herkömmliche DNS-Architektur.
  • 18 veranschaulicht eine CDSR (Client-Driven Service Rendezvous)-Architektur als Erweiterungen zu einer existierenden End-Host-Architektur und TCP/IP-Internet-Architektur.
  • 19 ist ein Netzdiagramm zur Veranschaulichung eines End-Hosts, der das CDSR-System in der Internet-Infrastruktur aufruft.
  • 20 ist ein Netzdiagramm zur Veranschaulichung einer Weitbereichsinstallation von CDSR.
  • 21 veranschaulicht eine Kombination aus CDSR und traditionellen Webservern mit Lastausgleich.
  • BESCHREIBUNG DER KONKRETEN AUSFÜHRUNGSFORMEN
  • Es werden nun einige Beispiele für konkrete Ausführungsformen von Architekturen zum gemeinsamen Anbieten von Inhalten (Content Peering) gemäß der vorliegenden Erfindung beschrieben. Andere können sich beim Lesen dieser Beschreibung ergeben, und es ist anzumerken, dass die Erfindung nicht auf diese konkreten Beispiele beschränkt, sondern nur durch die beigefügten Ansprüche begrenzt ist. Während außerdem konkrete Verfahren und Vorrichtungen gezeigt sind, sollte es beim Lesen dieser Beschreibung deutlich sein, dass einige der Verfahren unter Verwendung verschiedener Vorrichtungen ausgeführt werden können, und dass die gezeigten Vorrichtungen verwendet werden könnten, um andere als die gezeigten Verfahren durchzuführen.
  • Die vorliegende Beschreibung zeigt, wie mehrere Ausführungsformen eines Systems gemäß der vorliegenden Erfindung erstellt und verwendet werden können, verzichtet aber zu Zwecken der Überschaulichkeit auf Beschreibungen von vielen allgemein bekannten Komponenten solcher Systeme. Beispielsweise sind der Betrieb und der Entwurf von einem standardmäßigen TCP/IP-Netz, standardmäßigen TCP/IP-Clients und dergleichen vorliegend nicht explizit beschrieben, das sie in zahllosen, bereits verfügbaren Quellen gut beschrieben sind.
  • In der nachfolgenden Beschreibung sind gleiche Elemente der Figuren mit gleichen Nummern bezeichnet. Unterschiedliche Fälle solcher Elemente können mit gleichen Nummern bezeichnet sein, gefolgt von unterschiedlichen Fallnummern in Klammern. Die vorliegende Beschreibung ist gemäß der folgenden Übersicht aufgebaut:
    • 1. Existierende Inhalteverteilungsmodelle und eine Allgemeine Netzarchitektur 1.1. Existierende Inhalteverteilungsmodelle 1.2. Edge Server 1.3. Inhalteverteilungs-Serviceprovider (CSPs)
    • 2. Allgemeine Architekturen für Inhalteverteilung und Peering
    • 3. Erstellung eines Netzes mit Content Peering 3.1. Föderierte Umleitung 3.1.1. Administratively Provisioned Interdomain Anycast Routing ("APAR") 3.1.2. Inhalte-Backbone 3.1.3. Anycast Peering-Konfiguration 3.1.4. DNS-basiertes Content Peering 3.1.5. Explizite Umleitung 3.2. Inhalteverteilung-Benennungssystem 3.3. Inhalteverteilung mittels Anwendungsschicht-Routing 3.4. Verbesserte Serverfähigkeiten
    • 4. Client-driven Service Rendezvous (CDSR) 4.1. Allgemeine CDSR-Architekturen 4.2. Weitbereichsinstallation 4.3. Gestufte Installation 4.4. Webserver-gestufte Installation
  • 1. Existierende Inhalteverteilungsmodelle und eine Allgemeine Netzarchitektur
  • 1 ist eine Darstellung eines Systems 10, in dem Clients 12 mit Servern 14 über eine Infrastruktur 16 verbunden sind. In den hierbei verwendeten Beispielen wird das globale Internet als ein Beispiel für eine Infrastruktur 16 verwendet, jedoch ist anzumerken, dass die Infrastruktur 16 nicht auf diese Weise beschränkt ist. Beispielsweise könnte die Infrastruktur 16 als eine Untergruppe des globalen Internet, ein Intranet, Extranet, local area Netz, Internet II-Netz oder dergleichen, oder als eine Überlagerung über eine existierende Netz Architektur implementiert sein. Ferner werden zwar die TCP/IP-Protokolle als Beispiel für Vernetzung verwendet, und es werden beispielsweise Daten gezeigt, die sich als Pakete bewegen, jedoch könnte die Infrastruktur 16 unter Verwendung verschiedener Protokolle implementiert werden, ohne den Schutzbereich der Erfindung zu verlassen.
  • 2 zeigt die Infrastruktur 16 in mehr Detail als ein Netz mit Clients, die an das Netz an Zugangspunkten wie etwa Internet Service Provider (ISP) Points-of Presence (PoPs) angebunden sind, und Inhalten, die an Einspeisungspunkten zur Verfügung gestellt werden.
  • 3 veranschaulicht eine Netzverbindung, wobei Clients an Edge Router 38 an das Netz angebunden sind, und Daten sich in "Sprüngen" durch das Netz bewegen, wobei ein Sprung ein Datentransfer von einem Router (von einem Edge Router 38 oder einem internen Router 39) zu einem anderen auf dem Weg von einer Datenquelle zu einem Datenziel ist.
  • 4 veranschaulicht das Netz 36 in mehr Detail, wobei Server 40 gezeigt sind, die sich innerhalb des Netzes 36 befinden, um auf Anfragen zu antworten. Es ist anzumerken, dass jeder Server 40 mit dem Netz über einen Router gekoppelt ist, so dass zwischen den Router fließende Daten von Servern 40 empfangen und übertragen werden können. Die Server 40 brauchen nicht grundlegend von den in 1 gezeigten Content Servern 14 verschieden zu sein, auch wenn sie üblicherweise unterschiedlichen Zwecken dienen.
  • 1.1. Existierende Inhalteverteilungsmodelle
  • Die Datenstromverteilung wird nachfolgend erläutert, jedoch werden zuerst einige Hintergrundinformationen über existierende Inhalte dargelegt, um den Kontext der Verteilung in dem neuartigen System zu erläutern. Es ist anzumerken, dass sich viele Beispiele zwar auf die Verteilung eines Datenstroms beziehen, dass das System aber auch verwendet werden kann, um Daten zu tragen, die keine Streaming-Daten sind, wie etwa Dateien oder Datenblöcke einer definierten Länge.
  • Bei einem derzeit in Verwendung befindlichen, üblichen Verteilungsmodell werden Internet-Inhalte erzeugt und ausgeführt, indem Webseiten verfasst und auf einem Abstufungs-Webserver platziert werden, oder mittels Digitalisierung von Audio/Video-Signalen. Dies ist allgemein in 1 veranschaulicht. Inhalte werden an Einspeisungspunkten, die in 2 mit "I" bezeichnet sind, in das Internet veröffentlicht. Die Einspeisungspunkte könnten einen Produktionsserver umfassen, der den Datenstrom (oder Datei oder Datenblock, je nach Fall) fertig für das Broadcast an viele Clients enthält, wobei der Produktionsserver mit der Quelle der Inhalte (einem Webpage-Produzenten, einer Digitalkamera oder einer anderen Quelle) über eine einfache LAN-Verbindung oder dergleichen gekoppelt ist. Bei komplizierteren Konfigurationen könnte ein Datenstrom von einem entfernten Ereignisort wie einem Konzertort oder Sportereignis über eine dedizierte Verbindung (z.B. eine Wähl-ISDN-Leitung, eine geleaste T1-Leitung, oder eine Frame Relay-Verbindung) an eine Produktionsserverstelle transportiert werden, wo der Datenstrom auf dem Produktionsserver platziert wird. Sobald die Inhalte auf dem Produktionsserver veröffentlicht wurden, kann jeder Client auf dem Internet mit einer Web- oder Streaming Media-Verbindung zwischen dem Produktionsserver und dem Client auf diese Inhalte zugreifen.
  • Das einzelne Produktionsservermodell funktioniert nur bis zu einem bestimmten Maßstab. Da jeder Client seine eigene Verbindung mit dem Server erzeugt, kann der Server leicht überwältigt werden, wenn er populäre Inhalte liefert. Dies trifft besonders dann zu, wenn der Zugang synchronisiert ist, z.B. bei einem Live-Event, so dass der Server gleichzeitig viele separate Kopien der Inhalte an jeden anfordernden Client senden muss. Dies überwältigt nicht nur den Durchsatz des Servers, sondern belastet auch das Netz nahe des Serverortes, das die gleichen Inhalte viele redundante Male über die gleiche Netzverbindung zu tragen hat, außerordentlich.
  • 1.2. Edge Server
  • Ein üblicher Lösungsansatz zum Überwinden dieses Problems ist es, Servervorrichtungen wie etwa Webcaches oder Streaming Media-Splitter an oder nahe der "Kante" des Netzes anzuordnen. Beispielsweise besitzt der ISP in einem typischen ISP-Netz viele untereinander verbundene Knoten, und einige der Knoten sind PoP (Point of Presence)-Knoten. Ein PoP-Knoten ist ein Knoten, an dem sich ein Kunde des ISP anhängen kann, um sich mit dem Internet zu verbinden. Ein üblicher PoP-Knoten umfasst eine Bank von Einwahlmodems, bei denen sich Kunden einwählen und verbinden können. Andere Knoten könnten völlig intern für den ISP und für den Kunden unzugänglich sein. Typischerweise werden Knoten, die PoP-Knoten sind, oder Knoten, die einen Router-"Sprung" von einem PoP (ein Sprung "in" das ISP-Netz) entfernt sind, als "Edge"-Knoten angesehen. ISP-Kollokationssysteme ("colos") werden ebenfalls als Edgeknoten angesehen, obgleich sich einige von ihnen relativ tief im Netz befinden. Unter diesen Umständen können programmierbare Server in einem Edge-PoP platziert werden, um nahegelegene Clients auf effiziente Weise zu bedienen. In Edge-PoPs oder nahe bei Edge-PoPs platzierte Server werden häufig als "Edge Server" bezeichnet.
  • Bei diesem Modell erfasst der Edge Server die Anforderung des Anwenders von Inhalten und liefert die Inhalte lokal, wodurch er die Antwortzeit verbessert, den Weitbereich-Bandbreitenverbrauch verringert, und die Belastung des Produktionsservers senkt. Falls der Produktionsserver verteilt ist, so dass mehrere Server alle Clients bedienen, die Inhalte anfordern, wird die anfängliche Quelle der Inhalte hierbei häufig als der "Ursprungsserver" bezeichnet, der die anfängliche, offizielle Kopie des Datenstroms liefert. Falls die Kante als PoP-Knoten und um einen Sprung von einem PoP-Knoten entfernte Knoten definiert ist, liegt ein Edge Server höchstens einen Sprung von dem Knoten entfernt, wo die Inhalte geliefert werden sollen. Falls die Kante insofern als "dicker" definiert ist, als Knoten, die um mehr als einen Sprung, aber weniger als N (N > 1) Sprünge entfernt sind, in der "Kante" liegen, dann könnten Edge Server natürlich bis zu N Sprünge von einem Kunden entfernt sein.
  • Falls die Kante universell auf diese Weise mit Server ausgebaut wird, dann leisten und skalieren Internetdienste insgesamt besser. Unglücklicherweise gibt es keine einzelne "Kante" des Internet, die einfach auf diese Weise ausgebaut werden kann. Die Kante ist im Besitz einer breiten Menge von unabhängigen Serviceorganisationen mit verschiedenen Geschäftsmodellen, die nur sehr lose zusammenarbeiten, um eine globale Internet-Verbindungsfähigkeit zur Verfügung zu stellen. Bei gegenwärtigen Geschäftsmodellen werden Webinhalte im Allgemeinen durch eine Hosting-Einrichtung in das Internet veröffentlicht, die häufig über den Weitbereich verteilt, aber nicht über die Kante hinweg vorhanden ist. Wie beispielsweise in 2 gezeigt ist, besitzt ein ISP A ein Stück der Kante, während der ISP B ein anderes Stück der Kante besitzt, so dass sie die gesamte Kante nur dadurch abdecken können, dass sie zusammenarbeiten.
  • Somit hängt das Web-Hosting-Geschäft davon ab, dass Edge-Caching-Infrastruktur durch die gesamte Infrastruktur hindurch installiert ist, um die Belastung von Hosting-Zentralen zu verringern und Anwendern Qualität zur Verfügung zu stellen, indem sie Inhalte aus den nahe gelegenen Netzzugangspunkten liefern. Gegenwärtige Geschäftsmodelle im Internet tendieren jedoch nicht dazu, jede Dienstinstanz zu ermutigen, ihre Kante mit qualitätsverbessernder Technologie wie Cache-Speichern und Splittern auszubauen. Dies wird nur dann gemacht, wenn es für den Serviceprovider wirtschaftlich sinnvoll ist, auszubauen, z.B. weil der Nutzen des Caching (Reduzierung von Bandbreitekosten und Liefern besserer Qualität für den Kunden) stär ker wiegen als die Investition in die Installation und Verwaltung der neuen Infrastruktur. Bestimmte ISPs beispielsweise sind nicht der Ansicht, dass dies der Fall sei.
  • Inhalteprovider sehen einen enormen Wert darin, Zugang zu einer Versorgungsvorrichtung in der Kante zu haben. Dies trifft zu, ob der Inhalteprovider nun ein kostenloser (z.B. durch Werbung finanzierter) Dienst oder ein bezahlter Dienst ist (wobei die Bezahlung durch herkömmliche Finanzkanäle oder unter Verwendung eines Mikrozahlungssystems abgewickelt wird), da es für den Inhalteprovider immer rentabler ist, wenn seine Inhalte auf effiziente Weise und richtig die Clients erreichen.
  • Wenn der Inhalteprovider es so einrichten könnte, dass seine Inhalte stets von der Kante des Netzes geliefert würden, dann würden die Verbraucher seiner Inhalte stets bestmögliche Leistung aus dem Internet erhalten. Dann wäre der Inhalteprovider wahrscheinlich gewillt, für einen solchen Dienst zu bezahlen, da dieser seine Inhalte von denjenigen seiner Konkurrenten durch eine verbesserte Lieferleistung abhebt und den Empfängern, an die der Provider seine Broadcasts sendet, besser dient. Die existierenden Internet-Cachemodelle stellen jedoch keine koordinierte Kontrolle darüber zur Verfügung, welche Inhalte an der Kante platziert werden, und diese Kante ist im Besitz und unter Kontrolle von vielen verschiedenen ISPs.
  • 1.3. Inhalteverteilungs-Serviceprovider (CSPs)
  • Ein Inhalteverteilungs-Serviceprovider (Content Distribution Service Provider; CSP) ist eine Serviceorganisation, welche Internet-"Inhalteverteilungsservice" an Inhalteprovider verkauft und liefert. Ein CSP könnte einen Vertrag mit einem Inhalteprovider wie etwa Yahoo oder CNN abschließen, damit die Inhalte (z.B. Webseiten und Streaming Media-Verkehr) von Yahoo oder CNN auf effiziente Weise repliziert und durch das Internet geliefert werden, wodurch gute Qualitätserfahrungen an Empfänger dieser Inhalte geliefert werden. Diese CSPs bauen ihr Inhaltenetz typischerweise durch Kollokation ihrer Server in traditionellen ISP-Netzen und Umleiten von Client-Anfragen auf nahe gelegene Server auf der Grundlage von verschiedenen Metriken auf, die hinsichtlich des Zustandes des Netzes und der Server-Infrastruktur gesammelt werden. Für die Durchführung des Umleitungssystems "verweisen" URLs häufig eher auf die Dienstinfrastruktur des CSP statt auf die Internet-Site des ursprünglichen Inhalteproviders. In der Tat kann der CSP nun kontrollieren, welche Inhalte auf seinen Edge Servern platziert werden, und seine Infrastruktur so bestücken, dass er in der Lage ist, die Inhalte aller seiner Kunden mit hohen Leistungsniveaus an beliebige Internet-Anwender liefern kann.
  • Damit das CSP-Modell funktionieren kann, muss eine zentralisierte Instanz, die die gesamte verteilte Infrastruktur besitzt und kontrolliert, Vorrichtungen installieren und verwalten, welche die gesamte Kante des Internet durchdringen, durch Installieren solcher Vorrichtungen entlang der Kante jedes unabhängigen ISP, um allen Empfängern Vorteile unabhängig davon zur Verfügung zu stellen, wo die Clients dieser Empfänger mit dem Internet verbunden sind. Dies ist jedoch so gut wie unmöglich, da das Internet weiterhin wächst und sich entwickelt. Selbst wenn eine solche Instanz in der Lage wäre, einen bestimmten Grad von Erfolg mit dieser Art von globaler Installation zu erzielen, wäre das resultierende Geschäftsmodell instabil und schwach, weil die ISPs selbst, die die physische Netzinfrastruktur besitzen, die neue Geschäftsgelegenheit bemerken und zumindest einige von ihnen wünschen werden, selbst in den Inhalteverteilungsmarkt einzusteigen. Das Resultat ist ein Szenario, bei dem genau die Instanzen, auf die der CSP angewiesen ist, damit sie ihr Serviceangebot aufbauen, im Endeffekt seine Konkurrenten werden.
  • Als Alternative kann der CSP anbieten, es dem ISP zu erlauben, die Dienstleistung des CSP unter der eigenen Marke des ISP weiter zu verkaufen, wodurch er im Endeffekt Partnerschaften durch die ISPs aufbaut, um ein globales Inhalteverteilungssystem auszubauen. Dieser monolithische Lösungsansatz ist jedoch bei jedem ISP eng mit der Inhalteverteilungstechnologie des CSP verbunden. Da der CSP kontrolliert, wie Inhalte verteilt und repliziert werden und wie Clients zu Content Servern geleitet werden, hat der ISP keine Möglichkeit, seine eigenen Beziehungen mit anderen CSPs und/oder ISPs zu stärken. Es ist daher wahrscheinlich, dass auch dieses Geschäftsmodell schwach und instabil sein wird.
  • 2. Allgemeine Architekturen für Inhalteverteilung und Peering
  • Um die Zerbrechlichkeit der Geschäftsmodelle zu überwinden, bei denen ein allwissender CSP die Infrastruktur von unabhängigen ISPs koordiniert, um die Inhalteverteilung durchzuführen, ist ein bei weitem stabileres und skalierbareres Geschäftsmodell das vorliegend beschriebene "Content Peering"-Modell. Content Peering beseitigt oder verringert die Rolle des CSP und ermöglicht es ISPs, selbst die Träger der Inhalte zu werden. Bei diesem Modell besitzt der ISP die Beziehung mit dem Inhalteprovider und investiert in seine eigene Edge Server-Infrastruktur, um effektiv eine hochleistungsfähige Belieferung von Empfängern mit Inhalten der Inhalteprovider zur Verfügung zu stellen. Weil aber jeder ISP nur ein Stück der Internetkante insgesamt besitzt, müssen sie alle durch "Content Service-Level Agreements" (CSLAs) kooperieren, um jegliche anderen Inhalte von der Kante ihres eigenen Netzes zu liefern und ausreichende Ressourcen auf ihrer Kante bereit zu halten, um die CSLAs einzuhalten, die sie mit ihren Inhaltepartnern eingehen. D.h., zwei ISPs, A und B, treten in eine Beziehung ein, in der ISP A sich verpflichtet, die Inhaltekunden von ISP B zu tragen und zu "beliefern", und umgekehrt. Mit anderen Worten, die ISPs treten in bilaterale "Content Peering"-Beziehungen ein. Ebenso, wie bilaterales Peering auf der IP-Netzschicht Internet-Routing ermöglicht, werden bilaterale "Content Peering"-Beziehungen eine neue Form von Internet und Webinhalte-Routing und Broadcast-Streaming ermöglichen.
  • Mit Content Peering wird kein CSP mehr benötigt, um die existierende Inhalteverteilungsinfrastruktur von ISPs zu überbrücken. Stattdessen wäre die Rolle des CSP zu einer solchen vereinfacht, in der er Inhalte akquiriert und ansammelt. Im Gegenzug würde der CSP dem Inhalteverteilernetzwerk des ISP "Inhalteeinspeisungen" durch Content Peering-Beziehungen zur Verfügung stellen.
  • Gemäß der vorliegenden Beschreibung kann eine Gruppe von ISPs durch Peering auf dem "Inhalteniveau" und nicht dem Netzniveau einfacher als vorher ihren eigenen Inhalteverteilungsdienst entwickeln. Auf dem Netzniveau routen einzelne Datenpakete (deren Inhalte für das Netz völlig transparent sind) von Router zu Router, von Quelle zu Zielort. In einigen Fällen ist die Quelle in einem Netz, und der Zielort ist in einem anderen Netz. Ein Beispiel wäre, falls (unter Bezugnahme auf 2) ein mit dem ISP A am Client 12 (1) verbundener Anwender einen Satz von Paketen (z.B. eine eMail-Nachricht) an einen Anwender sendet, der mit ISP B am Client 12 (4) verbunden ist. Peering auf dem Netzniveau findet über eine Verbindung 29 statt, die zwischen den ISPs A und B, vermutlich gemäß einer Peering-Vereinbarung auf Netzniveau zwischen A und B, vorgesehen ist. Somit würden die Pakete im ISP A zu einem Edge Router (nicht gezeigt) routen, der mit der Verbindung 29 gekoppelt ist, und dann zu einem Edge Router (ebenfalls nicht gezeigt) am ISP B fließen, wo sie zum Client 12 (4) geleitet werden. Jeder Router, der die Pakete behandelt, hat eine Vorstellung davon, in welche Richtung die Pakete gesendet werden sollen, so dass sie auf ihren Weg gebracht werden, aber die Router wissen im Allgemeinen nicht, was die Daten in den Paketen bedeuten. Da die Router eine Netzmasche bilden, könnten die Router ein Paket um eine Überlastung oder einen Routerausfall herum leiten.
  • 5 ist ein grundlegendes Blockdiagramm zur Veranschaulichung der Elemente des Netzes, die in einer einfachen Client-Server-Anfrage und -Antwort eine Rolle spielen. Wie dort gezeigt ist, stellt der Client 12 eine Anfrage an den Server 14 durch das Netz 36, und die Anfrage fließt durch einen Edge Router 38, einen internen Router 39 und einen weiteren Edge Router. Die Antwort fließt durch eine ähnliche Gruppe von Router. Für Content Peering wird dem Ganzen noch ein weiterer Rahmen hinzugefügt, der in 6 als Umleitungsstruktur 50 bezeichnet ist. Die Umleitungsstruktur 50 arbeitet mit einem Verteilernetzwerk 52 und einer Server-Anordnung 54, um Anfragen zu empfangen und Broadcast-Inhalte an einzelne Clients geliefert zu bekommen. Die Umleitungsstruktur 50, das Verteilernetzwerk 52 und die Server-Anordnung 54 arbeiten nicht auf einem Netzniveau, sondern auf einem Inhalteniveau, und bilden somit ein Netz auf der Anwendungsschicht. Um die verschiedenen Niveaus wiederzugeben, zeigt 6 nicht unbedingt alle Netzniveau-Details. Beispielsweise könnte die Umleitungsstruktur 50 Router umfassen, um auf die Netzschicht zu routen. Die Umleitungsstruktur 50 und/oder die Server-Anordnung 54 könnten auch dezentralisiert und über das gesamte Netz verbreitet sein.
  • In diesem Rahme werden die Inhalte als Inhalte an die Clients "geleitet". Die Inhalte beginnen an einem Content Server 14 und werden an einem Einspeisungspunkt 26 in das Netz 36 eingespeist. Vom Einspeisungspunkt erreichen die Inhalte die Server-Anordnung 54 über das Verteilernetzwerk 52. Da das Verteilernetzwerk 52 als ein Netz angeordnet ist, können die Inhalte skalierbar auf viele Server in der Server-Anordnung 54 verteilt werden, wobei um einen Stau oder einen ausgefallenen Verteilerknoten herumgeleitet wird.
  • Ein Modell für ein Verteilernetzwerk ist der in McCanne I beschriebene "Overlay Routing"-Lösungsansatz. In einem Overlay-Netz können Inhalte an jeglichem Anschlusspunkt in ein Overlay-Netz von "Service Hubs" eingespeist werden. Dieses Overlay-Netz trägt Inhalte von jedem Einspeisungspunkt, der sich irgendwo entlang einer "Kante" befinden könnte, zu Server, die innerhalb der Netzinfrastruktur gemeinsam angeordnet und über alle wichtigen ISPs verteilt sind, wodurch jeder ISP seine eigene Untergruppe dieses Verteilernetzwerkes verwalten und Service Hubs durch virtuelle Content Peering-Verbindungen verbinden kann.
  • Diese Service Hubs können anfänglich im Kern des Netzes angeordnet sein, und über die Zeit, wenn die Inhalteverteilungsinfrastruktur mehr und mehr Verkehr trägt, können die Server inkrementell nach außen auf die Kante des IP-Netzes geschoben werden, was viele Aspekte des Netzes und der vom Anwender wahrgenommenen Leistungsfähigkeit verbessert. Somit können Inhalte effizient über das Netz zu Servern in der Nähe des Endanwenders getragen werden, was sowohl die Qualität der Erfahrung des Anwenders (weil Inhalte schnell mit weniger Verlust geliefert werden) als auch die Netzeffizienz (weil Inhalte effizient durch die gesamte Netzinfrastruktur repliziert werden, was die Anzahl von Kopien verringert, die über überlastete Netz-Peering-Punkte und -Backbone-Netze übertragen werden) verbessert.
  • Eine andere bevorzugte Komponente eines umfassenden Inhalteverteilungsmodells ist ein effizienter Mechanismus zum Anschluss eines Client an den am besten geeigneten Server. Wie in 6 dargestellt ist, "klebt" eine Umleitungsstruktur Clients an Edge Server, um den bestmöglichen Inhalteverteilungspfad zur Verfügung zu stellen. Die Umleitungsstruktur zieht Client-Nähe, Netzpfadcharakteristiken, Serverlast und -ausnutzung, und vielleicht am wichtigsten, Richtlinien auf der Grundlage von Content Peering Service-Level Agreements in Betracht, um zu entscheiden, wie der Client am besten an die Dienstinfrastruktur angeschlossen werden kann. Beispielsweise wenn ein Client auf einen Weblink klickt, leitet das Umleitungssystem die Anfrage dieses Clients nahtlos an den besten Server, unabhängig von jeglicher Konfiguration oder Wissen eines Clients.
  • Um dieses Umleitungsmodell zu verwirklichen, beziehen sich von dem Inhalteprovider erzeugte URLs nicht auf die Ursprungs-Site der Inhalte, sondern verweisen stattdessen abstrakt in die Umleitungsstruktur (nicht-transparente Umleitung). Dies wird durch "Verankern" jedes Inhalteverteilemetzwerks in einem oder mehreren ISP-Netzen bewerkstelligt, die ein virtuelles "Inhalte-Backbone" aufweisen, wie in 7 gezeigt ist. D.h., das Inhalte-Backbone verankert den URL-Namespace des hier verwurzelten Inhalteverteilernetzwerks unter Verwendung der nachstehend beschriebenen APAR-Routingmechanismen. Das Verteilernetzwerk ist über das Inhalte-Backbone aufgebaut durch Installieren von Anwendungsschicht-Multicast-Routingvorrichtungen in den Service Hubs in ISP-Datenzentralen und Bilden eines Overlay-Netzes durch Peering dieser Inhalte-Router über Datenzentralen unter Verwendung von "virtuellen Verbindungen". In Kollokation mit jedem Inhalte-Router befinden sich ein oder mehrere Content Server, die live oder auf Anfrage Streaming Media sowie Web-Inhalte liefern. Im Grunde bilden die Inhalte-Router ein intelligentes Netz, das Inhalte-Einspeisungspunkte mit allen Edge Servern in dem Inhalte-Backbone verbindet.
  • Entlang jedes Inhalte-Router befindet sich ein Umleitungsknoten, der sein Vorhandensein dem Netz veröffentlicht und im Effekt die URL-Namespaces angibt, die er verwaltet. Wenn also eine Anwenderanwendung versucht, über das Netz mit dem betreffenden URL zu kommunizieren, fängt ein nahe gelegener Umleitungsvorrichtungsknoten in dem Inhalteverteilernetzwerk die Anfrage ab. Dieser Umleitungsvorrichtungsknoten wiederum leitet den Client an den am besten geeigneten Server auf der Grundlage von Last- und Netzmessungen, welche die Umleitungsvorrichtungsknoten im Hintergrund beständig sammeln. Normalerweise liegt der beste Server nahe dem Umleitungsvorrichtungsknoten, aber falls die lokalen Server voll ausgelastet sind, kann das System einen Client anderswohin umleiten. Diese Umleitung kann explizit durch eine direkte Kommunikation zwischen dem Client und dem Umleitungssystem stattfinden, kann aber auch in einigen Fällen als eine implizite Umleitung unter Verwendung des DNS (Domain Name Service)-Nachschlagevorgangs zum Umleiten von Clients implementiert werden.
  • 8 ist eine Darstellung davon, was geschieht, wenn immer mehr Anwender auf das Inhalte-Backbone zugreifen. Wie dort gezeigt ist, bedient ein Inhalte-Backbone 91 viele Clients 92 über individuelle Client-Verbindungen 94 zwischen dem Inhalte-Backbone und Clients über ISPs. Ebenfalls gezeigt sind die Unicast-Peering-Links 96. Die Peering-Kosten zwischen dem-Backbone Netz und benachbarten ISPs nehmen dann zu, und die Lieferqualität wird sich letztlich verschlechtern. Um dies zu verhindern, kann ein Peer-ISP sein eigenes Inhalteverteilernetzwerk unter Verwendung der vorliegenden Erfindung aufbauen, um sich mit dem Inhalte-Backbone zusammenzuschließen ("peer"), um das Inhaltenetz inkrementell auszubauen. Die Inhalte-Router in dieser neuen Installation wären dann dazu konfiguriert, die URL-Anfragen zu erfassen, die in das kooperierende Inhalte-Backbone weisen.
  • Diese ISP-Installation der Inhalteverteilungstechnologie reduziert nicht nur Bandbreitekosten und stellt dem Anwender eine bessere Netzqualität zur Verfügung, sondern erzeugt eine neue Einnahmegelegenheit, indem sie es diesem ISP ermöglicht, in den Inhalteverteilungsservice einzutreten. D.h., der zweite ISP würde seinen eigenen URL-Namespace erzeugen und besitzen, der in seinem eigenen Inhalte-Backbone verankert ist. Daraufhin konfigurieren seine angegliederten ISPs ihre Inhalte-Umleitungsvorrichtungen, um die neuen URLs zu erfassen, vorausgesetzt, es existiert eine Geschäftsbeziehung, um dieses Niveau von "Content Peering" zu unterstützen. Tatsächlich ermöglicht es die vorliegend beschriebene Inhalteverteilungsarchitektur jedem ISP, sein eigenes Inhalte-Backbone und sein eigenes Inhalteverteilungs-Serviceangebot aufzubauen, sich dann gegenseitig zusammenschließen – nicht auf dem IP-Niveau, sondern auf dem Inhalte-Niveau – um beliebig breite und weitreichende Inhalteverteilungsnetze zu erstellen.
  • 3. Erstellung eines Netzes mit Content Peering
  • In dieser Sektion wird eine Ausführungsform der vorausgehend umrissenen Content Peering-Architektur beschrieben. Die Systemkomponenten umfassen:
    • 1) ein "föderiertes" Umleitungssystem, das es ermöglicht, dass Inhaltsanfragen auf der Grundlage von Content Peering-Beziehungen zwischen ISPs (die teilweise auf den Lehren von McCanne et al. I und II basieren) an Server geleitet werden;
    • 2) ein Benennungssystem, bei dem URLs in die Umleitungsstruktur verweisen und genügend Informationen enthalten, um es zu ermöglichen, dass das Dienstanschlusspunkt-System die Inhalte aus dem Inhalteverteilungssystem abruft;
    • 3) ein Inhalteverteilernetzwerk mit Anwendungsschicht-Inhalte-Routern, die ein "Weitbereichs-Multicasting" von Daten (gemäß der Beschreibung in McCanne et al. I und II) unterstützen; und
    • 4) Servertechnologien, die so verbessert oder erweitert sind, dass sie mit dem beschriebenen Inhalte-Benennungssystem zusammenwirken.
  • Es werden nun die Systemkomponenten in mehr Detail beschrieben.
  • 3.1. Föderierte Umleitung
  • Content Peering verwendet bevorzugt ein Umleitungssystem, das auf die existierenden Peering-Beziehungen zwischen ISPs mappt. Ein Lösungsansatz verwendet Anycasting als Teil des Umleitungsvorgangs. Anycast-Routing verwendet die existierende Unicast-Routing-Infrastruktur. Jedem Inhalte-Backbone ist seine eigene Anycast-Adresse zugeordnet (als Haken zum Erfassen von Inhaltsanfragen). Somit kann jeder ISP seine Gesamtheit von Umleitungsvorrichtungsknoten mit dieser neuen Anycast-Adresse konfigurieren, um Inhaltsanfragen dieses Inhalte-Backbone zu erfassen. Das Inhalte-Backbone dient als das standardmäßige autonome System ("AS") für alle Anfragen, die nicht von einem für die Inhalteverteilung befähigten ISP stammen oder diesen durchlaufen. Administrativ vorgesehenes Interdomain-Anycast-Routing kann verwendet werden, damit das Inhalte-Backbone mehrere autonome Systeme übergreift.
  • Gemäß der vorliegenden Beschreibung gibt es mehrere Lösungsansätze für das Umleiten. Ein solcher Lösungsansatz verwendet DNS (Domain Name Service)-Server zum Durchführen des Umleitens. Unter Verwendung dieses Lösungsansatzes kann den DNS-Servern eine Anycast-Adresse zugeordnet werden, so dass sie in das Content Peering-Modell passen. Unter Verwendung von N* Konfiguration kann der DNS-Server eines ISP entscheiden, bestimmte Anfragen an die Kante des ISP und andere Anfragen an eine Main Hub, und wieder andere Anfragen an seine Inhalte-Peers (je nach den vorgesehenen Richtlinien) zu leiten.
  • Ein Aspekt einer skalierbaren und effizienten Content Peering-Implementierung könnte ein nahtloses Umleitungsmodell sein, das die administrativen Richtlinien und Grenzen der das Inhalteverteilungssystem umfassenden Infrastruktur berücksichtigt. Bei diesem Modell wird ein Inhalteverteilernetzwerk (CDN) als virtuelles Netz aufgebaut, das mehrere, möglicherweise unabhängig verwaltete Unter-CDNs übergreift. In der Tat bildet dieses Netz aus CDN-Netzen ein "Inhalte-Internet", da die Unter-CDNs in ein massives CDN vernetzt sind.
  • 3.1.1. Administratively Provisioned Interdomain Anycast Routing ("APAR")
  • Administratively Provisioned Interdomain Anycast Routing ("APAR") bezieht sich auf eine Unicast-Routingmethode, die in dem Umleitungssystem verwendet wird. Eine Variation von APAR ist in McCanne et al. II beschrieben. Wenn APAR verwendet wird, ist jedes CDN einer geringen Anzahl von Anycast-Adressen zugeordnet. Eine Anycast-Adresse ist eine einzelne Unicast-IP-Adresse, die über mehrere unterschiedliche physischen Instanzen geteilt wird. Diese unterschiedlichen physischen Instanzen sind dazu konfiguriert, an den Unicast-Routing-Protokollen teilzunehmen, und der Nettoeffekt ist, dass an diese Anycast-Adresse gesendete Pakete an die nächste Vorrichtung geleitet werden, die dieser Adresse zugeordnet ist.
  • Um diesen Lösungsansatz über den Weitbereich auszuweiten, sind ein oder mehrere BGP autonome Systeme (AS) dazu konfiguriert, diese besonderen Anycast-Adressen anzukündigen. Somit wird Anycast-Routing auch auf dem Interdomain-Niveau durchgeführt, da BGP den kürzesten Weg (eingeschränkt durch BGP Richtlinien) zu der vielfach angekündigten Adresse berechnet.
  • Um die Installation dieses Lösungsansatzes zu erleichtern, könnte ein Block von Unicast-Adressen exklusiv für APAR zugewiesen werden, um es ISPs so zu ermöglichen, Richtlinien für diese speziellen Anycast-Adressen leicht zu definieren. Beispielsweise könnte IANA anfänglich einen/20-Adressen-Block (d.h. einen Block von 4096 IP-Adressaten) zur Verwendung für APAR zuweisen. Somit kann ein ISP sicher sein, dass der Anycast-Routing-Zustand niemals 4096 Einträge übersteigt (weil es in der Praxis wahrscheinlich viel weniger sind, da nicht alle Adressaten verwendet werden, und Unterbereiche sehr wahrscheinlich zusammengelegt werden). Dies überwindet das Problem, dass einige ISPs BGP Richtlinien verwenden, um Routen mit Präfixen, die länger als 20 Bits sind, zu blockieren und dadurch einen Fall zu vermeiden, in dem ein ISP im Internet die BGP Routing-Tabellen mit vielen eindeutigen Adressaten mit langen Präfixen überflutet. Stattdessen können diese ISPs ihre Richtlinie dahingehend ändern, solche Präfixe immer noch zu blockieren, während sie nur Routen mit langen Präfixen durchlassen, die innerhalb des reservierten, allgemein bekannten APAR Anycast-Adressenbereichs fallen.
  • 3.1.2. Inhalte-Backbone
  • Jede CDN besitzt ein zugeordnetes "Inhalte-Backbone", bei dem es sich um die Gruppe von AS's handelt, welche die diesem CDN zugeordnete(n) Anycast-Adresse(n) ankündigen. Innerhalb des Inhalte-Backbone sind Vorrichtungen installiert, die der/den Anycast-Adresse(n) zugeordnet sind. Solche Vorrichtungen könnten Webserver, Streaming Media-Server, anwendungsspezifische Umleitungsvorrichtungen, DNS-Server, die virtuelle Adresse einer Schicht 4-Switch-Lastausgleichvorrichtung usw. sein. Somit wird jedes Paket, das an eine solche Adresse gesendet wird (ob dies nun eine "zustandsbehaftete" TCP-Dienstverbindung oder eine "zustandslose" UDP-Transaktion wie DNS ist) an die nächstliegende Instanz einer Anycastadressierten Vorrichtung geleitet wird.
  • Beispielsweise zeigt 9 eine Konfiguration, bei der das Inhalte-Backbone 1 unter Verwendung der Anycast-Adresse A* im AS 100 installiert ist, während das Inhalte-Backbone 2 über die AS's 200 und 300 unter Verwendung der Anycast-Adresse B* installiert ist. Wie in 9 gezeigt ist, kündigt B* BGP-Routen an. Die Vorrichtun gen A1* und A2* sind der Anycast-Adresse A* zugeordnet, und die Vorrichtungen B1*, B2*, B3* and B4* sind der Anycast-Adresse B* zugeordnet. (Anycast-adressierte Vorrichtungen besitzen auch eine normale, eindeutige IP-Adresse, die ihnen für einen Netzverwaltungszugriff usw. zugewiesen ist. Wir bezeichnen diese Adresse als die Verwaltungsadresse.) Ein an die Adresse A* gesendetes Paket wird an die nächste Vorrichtung in AS 100 geleitet, wohingegen ein an B* gesendetes Paket an entweder AS 200 oder 300 geleitet wird (je nach der BGP-Routenpräferenz). Beispielsweise falls der Host C1 ein an A* adressiertes Paket sendet, wird es entlang des Pfades 101 an die Vorrichtung A1* geleitet. Desgleichen, falls der Host C1 ein Paket an B* sendet, wird es entlang des Pfades 102 an die Vorrichtung B1* geleitet. Wenn der Host C2 hingegen ein Paket an B* sendet, wird es entlang des Pfades 103 an die Vorrichtung B3* geleitet.
  • 3.1.3. Anycast Peering-Konfiguration
  • Gemäß der vorstehenden Beschreibung des CDN-Systems kann dann durch das Erzeugen von Angliederungsbeziehungen zwischen dem Inhalte-Backbone und einer anderen AS in andere AS's (gemäß der Beschreibung in McCanne et al. II) erweitert werden. Hierzu installiert die angegliederte Einrichtung Anycast-adressierte Vorrichtungen (oder konfiguriert ihre existierenden neu) bei dem Anycast-Adressenblock, der im Besitz des betreffenden Inhalte-Backbone ist. Diese Vorrichtungen wiederum kündigen die entsprechende Anycast-Route in das Internal Gateway Routing-Protokoll (IGP) des AS an, aber diese Routen dürfen nicht in die externe BGP-Route dieses AS weiterführen (ansonsten würde es unter unserer Terminologie nicht als Teil des Inhalte-Backbone betrachtet). Somit werden an den Anycast-Bestimmungsort adressierte Pakete, die von Hosts innerhalb des Netzes dieses ISP stammen, oder Pakete, die das Netz des ISP durchlaufen, an die nächstliegende Anycast-adressierte Vorrichtung geleitet.
  • Dieser Lösungsansatz ermöglicht es, dass die gleiche physische Infrastruktur und die gleichen Vorrichtungen über mehrere unabhängige CDNs erneut verwendet werden. Beispielsweise zeigt 10 eine Variation des in 9 gezeigten Layout mit Änderungen, so dass das AS 400 eine Angliederung des Inhalte Backbone 1 wird, und das AS 500 eine Angliederung sowohl des Inhalte Backbone 1 als auch des Inhalte Backbone 2 wird. Hierbei sind Anycast-adressierte Vorrichtungen im AS 400 dazu konfiguriert, den Adressenblock A* anzukündigen, während ähnliche Vorrichtungen im AS 500 dazu konfiguriert sind, beide Adressenblöcke A* und B* anzukündigen.
  • Falls nun der Client C2 ein Paket an die Adresse B* sendet, wird es entlang des Pfades 111 an die Vorrichtung B5* geleitet. Auf ähnliche Weise, falls der Client C2 ein Paket an die Adresse A* sendet, wird es entlang des Pfades 112 an die Vorrichtung A5* geleitet. Somit erfasst das AS 500 die Pakete innerhalb seiner Domain aufgrund der IGP-Route, wodurch die Notwendigkeit vermieden wird, die Anfrage den ganzen Weg bis zum Inhalte-Backbone zu leiten.
  • Darüber hinaus können die zwei Inhalte-Backbones sich zusammenschließen, wie in 11 gezeigt ist, wobei sie eine Angliederung des jeweils anderen werden. Hierbei wäre das AS 100 eine Angliederung des AS 200 und AS 300, und die AS 200/300 würden zu Angliederungen des AS 100. Dies wird durch das Installieren der Anycast-adressierten Vorrichtungen B5* im AS 100, A3* im AS 200, und A4* im AS 300 erreicht, sowie durch Modifizieren der IGP des jeweiligen AS, um den Verkehr des anderen Inhalte-Backbone zu erfassen.
  • 3.1.4. DNS-basiertes Content Peering
  • Gemäß der vorstehenden Beschreibung kann das APAR-Routing-System dazu verwendet werden, eine Art von Content Peering auf der Grundlage von spezialisierten DNS-Servern durchzuführen, die vorliegend als "APAR-DNS-Server" bezeichnet werden. Bei diesem Modell ist der APAR-DNS-Server mit einer oder mehreren APAR-Anycast-Adressen konfiguriert und erscheint daher als Nameserver auf einem oder mehreren CDNs. Mit anderen Worten, der APAR-DNS-Server ist typischerweise ein einzelner Teil der physischen Infrastruktur, der entweder im Besitz des ISP ist, bei dem sich die Vorrichtung befindet, oder im Besitz eines Dritten mit Kollokation seiner Ausrüstung im Netz des ISP, das mehrere virtuelle CDNs unterstützt, die sich im Besitz von dritten Inhalte-Serviceprovidern oder möglicherweise von anderen ISPs befinden.
  • Das CDN-Backbone konfiguriert den DNS, so dass ein Unterbaum des DNS-Namespace autoritativ von dem Nameserver mit einer APAR Anycast-Adresse verwaltet wird. Mit anderen Worten, der Namespace wird auf der Föderation von APAR-DNS-Servern verwaltet, die mit dieser Anycast-Adresse konfiguriert sind und als die autoritativen Nameserver für die DNS-Unterdomains in dem Unterbaum dienen. Dies wird dadurch erreicht, dass einfach die gewünschte Anycast-Adresse als ein Nameserver (NS) DNS-Ressourceneintrag für die gewünschte CDN-Unterdomain veröffentlicht wird (s. unten).
  • Im Stand der Technik mappen DNS-Server eine endliche Menge von konfigurierten Namen auf eine endliche Menge von Host-Adressaten. Eine extensive Forschung und Produktentwicklung hat dieses Modell verallgemeinert, so dass DNS für verschiedene Arten von Lastausgleich, Webinhalte-Replizierung usw. verwendet werden kann, aber in allen diesen Lösungsansätzen ist der Eingang ein Name, der vorausgehend bekannt und explizit in das Benennungssystem konfiguriert sein muss.
  • Anders als dieser Stand der Technik brauchen die APAR-DNS-Server nicht mit einer Menge von bekannten Namen konfiguriert zu sein, die auf eine mögliche Menge von Adressaten gemappt werden sollen. Stattdessen können APAR-DNS-Server eine unbegrenzte Menge von beliebigen Namen, ausgedrückt auf eine Weise, die Informationen über die Inhaltsanfrage codiert, auf eine Menge von Adressenzielen mappen. Die Ziele sind in die APAR-DNS-Server zusammen mit Attributen konfiguriert, die ihre Fähigkeiten, administrativen Einschränkungen usw. beschreiben. Die Konfiguration von Zielen und damit zusammenhängenden Attributen kann unter Verwendung eines externen Protokolls (eines APAR-DNS-Verwaltungsprotokolls) dynamisch modifiziert werden.
  • Außerdem sind Richtlinien in die APAR-DNS-Server programmiert, um das Mappen von benannten Serviceanfragen auf Ziele zu kontrollieren. Um einen ordnungsgemäßen Lastausgleich von Anfragen über die Dienstinfrastruktur durchzuführen und Hotspots mit Netzüberlastung zu vermeiden, können Serverlast-Informationen und Netzwegcharakteristiken zwischen den APAR-DNS-Servern an der Kante des Netzes (nahe dem Client) und der Dienstinfrastruktur in den APAR-DNS-Server aus einem externen Datensammelvorgang eingegeben werden.
  • Der APAR-DNS-Server mappt programmatisch eine Name-zu-Adresse-Übersetzungsanfrage in ein Ziel durch:
    • 1) Parsen des Namens, um die Metainformation M in Bezug auf diesen benannten Dienst zu bestimmen;
    • 2) Finden der möglichen Menge von Zielen in der konfigurierten Datenbank, die mit M abgleichen;
    • 3) Beschneiden der möglichen Menge auf der Grundlage von konfigurierter Richtlinie, Serverlastmessungen, and Netzwegmessungen;
    • 4) Auswählen eines Mitgliedes der letztlichen Menge auf der Grundlage von zusätzlicher Richtlinie;
    • 5) Zurücksenden der ausgewählten Adresse (oder Satz von Adressaten) als DNS A-Eintrag zum Erfüllen der DNS-Anfrage (typischerweise mit einem TTL von 0, so dass der Eintrag nur einmal verwendet wird).
  • Unter Verwendung des vorstehenden Vorgangs können DNS-Namen wie folgt gegliedert werden:
    <codepoint>.<provider>
    wobei <codepoint> die vorstehend erwähnte Metainformation M definiert, und <provider> die DNS-Unterdomain ist, die dem CDN-Netz entspricht. Das Feld <codepoint> vermittelt Informationen wie etwa Anwendungstyp (z.B. Web, G2 Streaming Video, Börsennotierungen), den Kunden (z.B. Yahoo oder ESPN), die Größe des Objektes, die Klasse des Objektes, usw. Dieses Codierschema kann auf viele Weisen verallgemeinert werden, die mit der vorgeschlagenen Architektur zusammen hängen. Das Feld <provider> ist einfach die DNS-Unterdomain des CDN-Netzes (z.B. cdn.acme.net). D.h., Namen mit dem Suffix cdn.acme.net werden von APAR-DNS-Servern aufgelöst, welche die am besten geeigneten Ziele auf der Grundlage von extern konfigurierten Richtlinien und dynamischen Netz- und Servermessungen wählen. Daher könnte der Name eines Web-Objektes, das sich im Besitz von "ABC" befindet und über das "ACME Networks"-CDN verteilt ist, den folgenden Aufbau besitzen:
    ad102.web.abc.cdn.acme.net
  • Um diesen Namen aufzulösen, würde der DNS-Anfragemechanismus lernen, dass cdn.acme.net von einem autoritativen Nameserver mit einer APAR Anycast-Adresse behandelt wird, wie z.B. N*. Wenn dann ein Client versuchte, ein mit diesem Namen bezeichnetes Objekt zu holen, würde die DNS-Anfrage nach ad102.web.cdn.acme.net von diesem Client an N* gesendet, was dazu führte, dass die Anfrage an den nächsten APAR-DNS-Server geleitet würde, der dazu konfiguriert war, Anfragen für cdn.acme.net zu behandeln. Beispielsweise sei in 12 angenommen, dass N1*, N2* und N3* APAR-DNS-Server sind, die mit der APAR-Anycast-Adresse N* konfiguriert sind. Es ist anzumerken, dass N3* BGP APAR-Anycast-Routen ankündigt (gezeigt durch das Etikett N*"). Die DNS-Anfrage des Clients C1 wird an N1* geleitet, während die Anfrage des Clients C3 an N3* geleitet wird. C2 wiederum kann entweder an N1* oder N2* geleitet werde, je nachdem, ob die BGP-Route für N* vom AS 200 AS 400 direkt oder AS 400 über AS 100 favorisiert, was administrativ mit BGP-Routing-Richtlinien gesteuert werden kann.
  • Innerhalb dieses Rahmens können die verschiedenen N*'s mit verschiedenen Richtlinien programmiert werden. Beispielsweise kann N1* dazu konfiguriert sein, Server S1 oder S2 für diese Anfrage zu wählen, da S1 und S2 sich nahe dem anfragenden Client befinden. Aber für andere Namensanfragen (z.B. ad102.web.nbc.cdn.acme.net) kann N1* entscheiden, zum Server S4 zurückzukehren, der weiter weg gelegen ist und daher eine potenziell geringere Dienstgüte zur Verfügung stellt. Eine solche Richtlinie wäre von Nutzen, wenn ein Kunde des CDN-Netzes (in diesem Fall NBC) einen (z.B. im Vergleich mit ABC) Dienst geringeren Grades kauft. Da die Kundeninformation explizit im Namen codiert ist, können solche Entscheidungen als Teil des DNS-Nachschlagevorgangs getroffen werden.
  • Um die Integrität der Informationen in einem Namen zu gewährleisten, können die Namen eine digitale Signatur enthalten, die in ihnen eingebettet ist, wobei der zum Erzeugen der Signatur verwendete Schlüssel nur der Namenserzeugungsinstanz (d.h. dem Kunden des CDN-Netzes) und der Infrastruktur (d.h. den APAR-DNS-Servern) bekannt ist. Somit könnte ein Anwender die Art des von ihm erhaltenen Dienstes nicht ändern, indem er die Infrastruktur überlistet, die Anfrage mit einer nicht vorgesehenen Dienstgüte zu behandeln. Um im Namen übermittelte Informationen zu verbergen (was für den CDN-Serviceprovider oder seinen Kunden wünschenswert sein kann), kann auch das Feld <codepoint> verschlüsselt werden, und zwar auch mit einem Geheimschlüssel.
  • Zusätzlich zu der Kundeninformation könnte der Name eine spezielle Art von angefordertem Dienst bezeichnen. Beispielsweise könnte
    chan4.abc.tv.cdn.acme.net
    anzeigen, dass der Name nicht einem statischen Webobjekt, sondern einem Streaming Media-Kanal entspricht. Wenn also der APAR-DNS-Server die Namensauflösung durchführt, würde er nicht einen Webserver, sondern einen Streaming Media-Server als das Ziel wählen.
  • Es ist anzumerken, dass in keinem dieser Fälle der Name ad102.web.abc.cdn.acme.net oder chan4.abc.tv.cdn.acme.net explizit in das System konfiguriert ist. Stattdessen ist die Abhängigkeit zwischen Namen und Ressourcen explizit unterbrochen, und Ziele werden auf der Grundlage von flexiblen und programmierbaren Richtlinien gewählt. D.h., ABC könnte neue Inhaltseinträge mit neuen Namen (z.B. ad103.web.abc.cdn.acme.net) erzeugen und bräuchte diesen Namen beim CDN nicht explizit registrieren. Stattdessen würde der CDN auf den neuen Namen bei seiner ersten Verwendung einfach auf angemessene Weise reagieren.
  • Als Teil dieses Vorgangs können die APAR-DNS-Server den Ort eines Stücks Inhalt verfolgen. D.h., ein externer Agent kann explizite Ortsinformationen für gegebene Objekte verteilen, um die Replikationsmenge, die stattfindet, zu optimieren. Oder die APAR-DNS-Server können sich einfach erinnern, wann sie kürzlich Clients geleitet haben, und zukünftige Anfragen weiterhin an die gleiche Stelle leiten, um die Erzeugung von unnötigen redundanten Inhaltskopien zu vermeiden (und dabei die Serverlast zu überwachen und Kopien nur dann zu erzeugen, wenn die Serverlast dies zulässt).
  • 13 veranschaulicht, wie die APAR-DNS-Umleitungsarchitektur inkrementell installiert werden kann. Anfänglich werden N1*, N2* und N3* nur innerhalb des Inhalte-Backbone installiert. In Kollokation mit jedem APAR-DNS-Server befindet sich ein Content Server (S1, S2 bzw. S3). Darüber hinaus sind sie in der Nähe der Peering-Punkte des ISP angeordnet, wodurch es dem System als Ganzes ermöglicht wird zu wissen, was der nächste Peering-Punkt für den Client ist, der den Dienst anfordert. Wenn also eine Client-Namensanfrage am Knoten N2* eintrifft, würde beispielsweise dieser Server bevorzugt die Adresse S2 für den angeforderten Namen zurücksenden. Falls jedoch S2 überlastet ist, könnte N2* davon informiert werden (entweder durch Abfragen der Last auf S2 selbst, oder durch Erhalt einer Information über diesen Überlastzustand durch einen anderen Agenten) und könnte stattdessen Clients an alternative Server (z.B. S1 oder S3) leiten.
  • Um eine inkrementelle Installation zu unterstützen, können APAR-DNS-Server in AS's installiert werden, wobei keine gemeinsam angeordneten Server vorhanden sind. Beispielsweise zeigt 14 eine Konfiguration, bei der das AS 100 und das AS 200 das Inhalte-Backbone mit den Servern S1, S2, S3 und S4 umfassen. Das AS 300 ist eine Angliederung ohne Server. N3* kann jedoch dazu konfiguriert sein, die Server S1 usw. zu verwenden, und kann die Dienstgüte, die dem Kunden auf oder hinter dem AS 300 geliefert wird, verbessern, indem er den geeigneten Server auf der Grundlage von dynamischen Server- und Netzmessungen, Replikationsbeschränkungen und konfigurierter Richtlinie wählt.
  • Eine weitere Möglichkeit für N3* ist es, Server zu verwenden, die nicht im Besitz des betreffenden CDN sind. Somit kann N3* dazu konfiguriert sein, die Server S1 usw. zu bevorzugen, außer wenn sich die Leistungsfähigkeit verschlechtert, wobei er an diesem Punkt entscheiden kann, Anfragen an die Server X1, X2 umzuleiten, die im Besitz eines anderen CDN-Netzes oder des ISP, der das AS 300 besitzt, sein können. Da all dies durch eine Richtlinie gesteuert wird, die sich aus Content Peering Service Level Agreements ergibt, kann eine Bezahlung einfach vorgenommen werden, damit sie die Ressourcen widerspiegelt, die unter Peering-CDNs geteilt werden. Letztendlich ist die Leistungsfähigkeit eines Internet aus CDN-Netzen am effektivsten, wenn diese Technologie universell installiert wird. Bei diesem Modell würde jeder ISP an den CDN-Peering-Arrangements teilnehmen und Inhalte von vielen verschiedenen Inhalteprovidern für viele verschiedene CDN-Provider liefern und befördern.
  • 3.1.5. Explizite Umleitung
  • DNS-Server cachen häufig Name-zu-Adresse-Bindungen, um die Leistungsfähigkeit des Übersetzungsvorgangs zu verbessern und die Bandbreite zu reduzieren. Cachen führt jedoch dazu, dass die Serverwahlentscheidung veraltet. Dies kann für das Web einen annehmbaren Ausgleichseffekt darstellen, da Web-Transaktionen flüchtig sind und sich das System problemlos an eine Überlast auf einer Zeitskala anpassen kann, die in einem Verhältnis zu der Rate steht, mit der der Cache-Eintrag abläuft. Eine veraltete Umleitungsentscheidung ist jedoch für andere Verkehrsarten wie Streaming Media oder langlebige Dateitransfers (z.B. große Web-Objekte oder Musik-Downloads), bei denen ein Client mit dem ausgewählten Server während einer langen Zeitdauer verbunden bleibt, definitiv nicht akzeptabel.
  • Auch wenn Cachen unter Verwendung eines TTL von 0 in der DNS-Antwortnachricht ausgeschaltet werden kann, könnte dies potenziell eine unverhältnismäßige Belastung der Leistungsfähigkeit des DNS-Systems verursachen, außer wenn die APAR-DNS-Server universell installiert sind, was beim anfänglichen Aufstellen solcher Systeme nicht zu erwarten ist. Einige ISP's konfigurieren ihre DNS-Server dazu, das TTL-Feld zu ignorieren, damit es nicht möglich ist, Cachen insgesamt zu vermeiden. Selbst wenn Cachen vermieden wird, verschlechtert die Verwendung von nicht-cachebaren DNS-Antworten die Antwortzeit von Web-Transfers insgesamt, da der DNS-Übersetzungsschritt häufig ein beträchtlicher Bruchteil der Web-Transaktion insgesamt sein kann (besonders für kleine Web-Objekte), und dies hindert den DNS-Server nahe dem anfragenden Client daran, den Übersetzungsschritt für andere Clients zu cachen. Somit ist es wichtig, DNS-Eintrag-Cachen zu verwenden, um eine gute Leistungsfähigkeit eines CDN insgesamt zu erzielen, könnte aber zu der Verwendung veralteter Daten führen.
  • Es sei angenommen, dass der APAR-DNS-Server einen Streaming Media Server S wählt, um ein bestimmtes Streaming Media einzuspeisen und es daher zurücksendet. Ferner sei angenommen, dass die Antwort für eine Minute cachebar ist. Es wird nun der Fall betrachtet, in dem es sich ereignet, dass 5000 Clients genau diese Einspeisung in der nächsten Minute anfordern. Da das Mapping für S im normalen DNS-System gecachet ist (das sich des CDN nicht bewusst ist), wird S das Ziel von 5000 Client-Verbindungen. Falls dies die Kapazität dieses Servers übersteigt, wird die Leistungsfähigkeit des Client verschlechtert, oder die Verbindungen des Client werden abgewiesen.
  • Um dieses Problem zu überwinden, könnte eine explizite Umleitung anstelle (oder in Kombination mit) einer DNS-basierten Umleitung verwendet werden. Hierbei sind Umleitungsmodule als Anycast-adressierbare Vorrichtungen installiert, ebenso wie die APAR-DNS-Server vorausgehend installiert waren. Eine anwendungsspezifische Verbindungsanfrage (z.B. über HTTP oder RTSP) wird dann vom Client an eine Anycast-Adresse gesendet, die dann den Client zu einem geeigneten Server umleitet. In diesem Fall ist immer ein expliziter Umleitungsschritt enthalten, was eine Veraltung gecacheter DNS-Bindungen vermeidet. D.h., eine Umleitungsvorrichtung kann die Server-Infrastruktur kontinuierlich überwachen und ihr Umleitungsverhalten sofort ändern, um Änderungen der Last oder der Netzwegcharakteristiken zu reflektieren. Dieser Vorgang ist in McCanne et al. II ausführlich beschrieben.
  • Eine explizite Umleitung kann mit einer APAR-DNS-Umleitung kombiniert werden, um den besten von beiden Lösungsansätzen zu erzielen. In der nachfolgenden Beschreibung wird angenommen, dass ein APAR-DNS-System bereits installiert ist. Falls ein solches System installiert ist, könnte der APAR-DNS-Server, anstatt ein DNS-Mapping an einen bestimmten Server zurückzusenden, ein Mapping an eine explizite Umleitungsvorrichtung zurücksenden, die eine feinkörnige Server-Überwachung und Lastausgleich durchführt.
  • 15 veranschaulicht diese Konfiguration. Hier wird die gleiche Streaming Media-Anfrage vom Server S2 an den Client C2 im AS 200 geliefert, aber vom Server S1 zum Client C1 im AS 100. Im ersteren Fall führt der Client C2 eine DNS-Anfrage über den Dienstnamen durch, der an den APAR-DNS-Server N2* über die Adresse N* (Pfad 21) geleitet wird. N2* parst die Serviceanfrage und entscheidet auf der Grundlage einer konfigurierten Richtlinie, dass die Umleitungsvorrichtung R2 den angeforderten Dienst zur Verfügung stellen kann, und sendet daher einen A-Eintrag für die Adresse von R2 als Antwort auf die ursprüngliche Anfrage (Pfad 22). Der Client C2 ruft dann eine anwendungsspezifische Verbindung (z.B. HTTP) zu R2 (Pfad 23) auf, der mit einer Nachricht antwortet (Pfad 24), welche den Client anweist, eine Streaming Media-Anfrage (z.B. über RTSP) an den Server S2 zu erzeugen. Es ist anzumerken, dass die Umleitungsvorrichtung R2 dann mit ihrem eigenen Satz von Richtlinien und potenziellen Zielservern zum entsprechenden Leiten von Clients konfiguriert ist. Ähnliche Schritte würden für den Client C1 unternommen, wie durch die Pfade 11-16 gezeigt ist.
  • Als Alternative könnte der APAR-DNS-Server eine APAR-Anycast-Adresse einer Gruppe von Umleitungsvorrichtungen zurücksenden. Dies würde ein Szenario ermöglichen, bei dem ein APAR-DNS-Server im Kern eines AS installiert ist, während eine Anzahl von expliziten Umleitungsvorrichtungen über die Kante installiert ist, wie in 16 dargestellt ist. Hierbei ist N1* dazu konfiguriert, eine Adresse A* (die A1*... A3* zugeordnet ist) als Antwort auf Streaming Media-Anfragen zurückzusenden. Dann würde eine Client-Anfrage, etwa von C1, an die nächste explizite Umleitungsvorrichtung, in diesem Fall A2*, geleitet. A2* würde dann entscheiden, wie der Client explizit umgeleitet werden soll, wie vorstehend beschrieben ist. Ein ähnlicher Vorgang wird für das Netz durchgeführt, das N2* enthält.
  • 3.2. Inhalteverteilung-Benennungssystem
  • Normale URLs, die auf die Content Server (die Ursprungsserver) weisen, können nicht immer von einer Umleitungsvorrichtung "erfasst" werden. Falls beispielsweise ein Client eine Anfrage unter Verwendung einer URL stellt, die in die Umleitungsstruktur weist, weiß die Umleitungsstruktur nicht sofort den Ursprung der Anfrage (weil die Ursprungsadresse durch eine Anycast-Adresse ersetzt ist). Somit ist es ein besserer Lösungsansatz, zusätzliche Informationen im URL zu führen, die verwendet werden können, um zu identifizieren, wie die Inhalte lokalisiert werden können, wer der Kunde ist, usw.
  • In der Web-Architektur wird der Name eines Web-Objektes in einen Server-Namen und einen Pfad auf diesem Server zerlegt, der üblicherweise als URL ausgedrückt ist. Das Umleitungssystem gemäß der vorstehenden Beschreibung ist jedoch auf das Mappen des Server-Namens des Web-Objektes (oder der Inhaltsanfrage allgemein) auf einen beliebigen Dienstknoten innerhalb der Netzinfrastruktur angewiesen. Somit könnte es sein, dass der Server-Name die betreffenden Inhalte nicht mehr eindeutig identifiziert.
  • Um dieses Problem zu überwinden, gewinnen die typischen, von anderen verwendeten Umleitungssysteme, welche die Server-Adresse auf diese Weise entstellen, die ursprüngliche Absicht des Web-Benennungssystems durch die Einbettung zusätzlicher Inhalte-Benennungsinformationen in die Pfadkomponente des URL. Beispielsweise könnte ein herkömmlicherweise als
    http://www.foo.com/index.html
    bezeichnetes Web-Objekt hinsichtlich des CDN wie folgt bezeichnet werden:
    http://foo.cdn.acme.net/www.foo.com/index.html
  • Diese Darstellung ermöglicht es dann dem CDN-Umleitungssystem des ACME-Netzes, Client-Anfragen für dieses Objekt an einen beliebigen Server im CDN zu leiten. Bei Empfang der Anfrage wäre dieser Server in der Lage, die Inhalte aus dem Ursprungs-Server bei www.foo.com zu ziehen. Dieser Lösungsansatz kann natürlich so verallgemeinert werden, dass er beliebige Inhalteleitungs- und Richtlinieninformationen in der betreffenden URL einbettet.
  • Ein besserer Lösungsansatz, der ein höheres Maß an Flexibilität zur Verfügung stellt, ist die Hinzufügung eines Niveaus der Ungerichtetheit, wobei der URL den Namen oder die Adresse eines Servers enthält, der beliebige Informationen darüber zur Verfügung stellt, wie die Inhaltsanfrage behandelt werden soll. Beispielsweise könnte eine Serviceanfrage für ein Live-Broadcast mit dem folgenden URL dargestellt werden:
    http://foo.cdn.acme.net/cdn.foo.com/Channel12
  • Hierbei weist cdn.foo.com auf einen Server hin, der die Informationsbank darüber, wie Inhaltsanfragen behandelt werden sollen, verwaltet. Der Dienstknoten, der diese Anfrage empfängt, könnte cdn.foo.com kontaktieren, um abzufragen, wie die "Channel12"-Inhalteanfrage bedient werden soll. Dieser Server könnte dann mit einer Nachricht antworten, die dem Dienstknoten mitteilt, sich an einen bestimmten Anwendungsschicht-Multicastkanal anzuschließen, um den Broadcast zu empfangen (s. unten), oder alternativ eine kaskadierte Einspeisung aus einem Streaming Media-Server anderswo im Netz zu ziehen. Durch Hinzufügen dieser Ungerichtetheit könnte eine beliebige Menge an Inhalte-Metainformation einem URL zugeordnet werden, ohne diese Informationen spezifisch in den URLs des Inhalteproviders platzieren zu müssen. Ferner kann diese Metainformation dynamisch geändert werden, z.B. um die Weise zu ändern, auf die ein Broadcast auf der Grundlage einer Überlastung oder von Netzausfällen verteilt wird. Schließlich könnte die Leistungsfähigkeit dieses Directory-Systems optimiert werden durch Cachen von Ergebnissen und/oder Verteilen der Informationen über das Anwendungsschicht-Multicast-Netz, das einen integralen Teil der zuerst anbietenden CDN bilden könnte.
  • 3.3. Inhalteverteilung mittels Anwendungsschicht-Routing
  • Anwendungsschicht-Multicast-Routing kann dazu verwendet werden, Live-Inhalte zu liefern und eine Cache-Hierarchie für eine auf Anfrage angesteuerte Inhaltereplikation zu veranlassen. Anwendungsschicht-Multicast-Routing kann auch dazu verwendet werden, Inhalte-Routingrichtlinien, Serverlast-Informationen, Replikationsinformationen usw. an die Umleitungsvorrichtungen zu verteilen (d.h. die Umleitungsvorrichtungen treten einer Anwendungsschicht-Multicast-Gruppe bei, um herauszufinden, wie sie ihre Umleitung vornehmen sollen).
  • Die vorstehenden Methoden für eine Client-Umleitung betreffen Server allgemein, aber bei einem CDN handeln die Server typischerweise in Übereinstimmung mit anderen Elementen im Netz, um Inhalte von den Veröffentlichung-Sites über das Netz an die CDN-Server zu überbrücken. Insofern ist es ein leistungsfähigeres Modell, die Server als Zugangspunkte zu einem Anwendungsschicht-Inhaltenetz zu casten, wie in McCanne et al. I beschrieben ist. Bei diesem Modell werden die Client-Anfragen auf der Grundlage von Serverlastmessungen, Netzwegcharakteristiken, administrativem Ort, Kundenrichtlinien usw. zu Dienstknotenanschlusspunkten geleitet. Inhalte werden über ein Anwendungsschicht-Netz von Inhalte-Routern geleitet. Zusätzliche Schichten für Benennung und Adressierung können implementiert werden, um dieses Inhaltenetz über das zugrunde liegende Internet zu legen.
  • Wenn beispielsweise ein Client einen Dienst anfordert, enthält die Anfrage (ausgedrückt als ein Web-URL) genügend Informationen, um die Inhalte ordnungsgemäß von den Anwendungsschicht-Inhalte-Routern anzufordern, wie vorstehend beschrieben ist. Für ein Live Streaming Media-Broadcast beispielsweise muss der Dienstanschlusspunkt den Broadcast von dem Verteilernetzwerk auf eine Weise gewinnen, die es dem System ermöglicht, mit der Anzahl von Zugangspunkten zu skalieren. Hierzu wird ein Verteilernetzwerk zwischen die Broadcast-Einspeisungspunkte an den Dienstanschlusspunkten geschaltet. Anstatt sich auf einen global installierten "Multicast"-Netzdienst zu verlassen, verwendet das vorliegend beschriebene System stattdessen die Dienstinfrastruktur erneut, um Service-Hubs über den Weitbereich zu einem "Overlay-Netz" zu verbrücken. Dieser Overlay berechnet Multicast-Routen an der Anwendungsschicht, was auf effiziente Weise Live-Ströme über den Weitbereich von jedem Einspeisungspunkt zu jedem Dienstanschlusspunkt auf der Grundlage eines Teilnehmermodells aufteilt und repliziert. Ein Netzschicht (native) Multicast – falls verfügbar – kann von dem Anwendungsschicht-Inhalteverteilungssystem rekursiv als Optimierung verwendet werden.
  • Ein Anwendungsschicht-Multicast Netz ist nicht nur zum Leiten von Live-Inhalten über den Weitbereich von Nutzen, sondern kann auch dazu verwendet werden, On-Demand Web- und Streaming Media-Verkehr asynchron zu leiten. Bei diesem Modell induziert eine Multicast-Route von einem Einspeisungspunkt an alle Kantenorte eine Cache-Hierarchie, wobei ein Cache-Miss den Baum hoch zu seinem Veröffentlichungsort geleitet wird. D.h., wenn ein Cache-Speicher (E) an der Kante des Netzes einen Inhalt holen muss, etwa von einer Quelle (S), konsultiert diese Kantenvorrichtung die Anwendungsschicht-Multicast-Route für den bei S verwurzelten Spanning-Tree. Diese Route gibt den Stammknoten (P) im Baum auf dem Weg zurück zu S an, und die Kantenvorrichtung sendet wiederum die Inhaltsanfrage an P. Daraufhin konsultiert P seinen Cache-Speicher, um zu sehen, ob die Inhalte vorhanden sind, und – falls ja – liefert die Inhalte entlang des Baumes zurück zu E, wo jeder Knoten entlang des umgekehrten Weges eine Kopie der angeforderten Inhalte speichert. Falls die Inhalte in P nicht vorhanden waren, propagiert P die Anfrage den Baum hoch gemäß der Multicast-Route, und so weiter. Dieses Verteilungsmodell skaliert gut, weil jeder Knoten in dem Baum einen gegebenen Inhaltsartikel höchstens einmal anfordert, jedoch wird im Verlauf der Zeit die gesamte Kante des Netzes mit den Inhalten besetzt.
  • Als Alternative kann der Multicast-Mechanismus verwendet werden, um Cache-Speicher an der Kante des Netzes unter Verwendung von Sprung um Sprung verlässlichem Multicast "vorzufüllen". (Im Gegensatz zu einem Netzschicht-Multicast ermöglicht eine Anwendungsschicht-Dienstinfrastruktur die Implementierung von ausführlicheren Verlässlichkeitsformen auf einer Sprung-um-Sprung-Basis.) Hierbei gehören bestimmte Cache-Speicher an der Kante des Netzes zu einer oder mehreren Anwendungsschicht-Multicast-Gruppen. Am Organisationsort der Inhalte werden neue Inhaltsaktualisierungen auf eine Gruppe veröffentlicht, die auf zuverlässige Weise an alle Cache-Speicher verteilt wird, die Mitglieder dieser Gruppe sind. Außerdem wird das Umleitungssystem über die Cache-Aktualisierungen informiert, so dass Clients zu Cache-Speichern umgeleitet werden, welche die angeforderten Inhalte aufweisen. Somit werden Änderungen oder Zusätze von Inhalten auf effiziente Weise an große Abschnitte der Kanten-Caches unter Verwendung von Anwendungsschicht-Multicast verteilt.
  • Eines der Elemente eines effektiven Beitragssystems ist der effiziente Austausch von Informationen über die verschiedenen Komponenten, aus denen das Gesamtsystem besteht, z.B. Verteilen von Serverlastinformationen an Umleitungsvorrichtungen, Inhaltereplikationsentscheidungen über das System, Netzwegmessungen, usw. Hierzu könnten die Anwendungsschicht-Multicast-Inhalteverteilungsmechanismen erneut verwendet werden, um die Metainformation über die Systemkomponenten zu verteilen. Beispielsweise könnten alle Umleitungsvorrichtungen in einer "Domain" an einer gemeinsamen Multicast-Gruppe teilnehmen und Lastinformationen über diese Gruppe austauschen. Ebenso könnte, wenn eine Systemelement entscheidet, einen "aktiven" Inhalt an einen anderen Server zu replizieren, dieses Replikationsereignis allen Umleitungsvorrichtungen durch Veröffentlichen des Ereignisses über die Multicast-Infrastruktur bekannt gemacht werden. Die Umleitungsvorrichtungen wiederum könnten dann Clients zu der neuen Kopie der Inhalte leiten.
  • 3.4. Verbesserte Serverfähigkeiten
  • Wie in den 4 etc. gezeigt ist, sind die Server 40 in die Infrastruktur 16 eingebettet, und diese Server 40 werden von dem Verteilernetzwerk 52 (in 6 gezeigt) versorgt, und die Umleitungsstruktur 50 leitet Clients an Edge Server um. Falls die vorstehend beschriebenen URL-Konventionen verwendet werden, wie etwa das Erstellen eines Bezugs auf eine solche Weise, dass die Umleitungsstruktur den Ursprung ableiten kann, dann könnte ein herkömmlicher Webcache oder Streaming Media-Server nicht in der Lage sein, die ursprünglichen Inhalte herunterzuziehen. Somit werden diese Server mit einfachen Regeln zum Auflösen der Inhaltsanfrage über die Konventionen im URL erweitert. Beispielsweise würde ein umleitungsbewusstes Webcache den URL-Pfad parsen und bestimmen, dass es zu einem bestimmten Webserver in dem Netz gehen sollte, um die Inhalte herunterzuziehen. Als Alternative kann der Cache-Speicher eine Datenbank (durch ein anderes Directory-System vom Anycast-Typ) konsultieren, das ihm mitteilt, von wo er die Inhalte holen soll, oder der Cache-Speicher kann dazu konfiguriert sein, die Inhalte aus dem Inhaltenetz zu ziehen, z.B. indem er dem Inhalte-Router das aussehen seines übergeordneten Webcaches gibt und die Anfrage bedient, indem er die Inhalte über das Anwendungsschicht-Inhaltenetz zieht.
  • Ein anderes Beispiel sind Live-Inhalte wie Streaming Media. Hier könnte der Edge Server den URL parsen, um die Streaming Media-"Kanalinformation" zu finden, die eine Anwendungsschicht-Multicast-Gruppe sein könnte. Um den Live-Broadcast zu empfangen, würde der Edge Server an der Anwendungsschicht-Multicast-Gruppe unter Verwendung der in McCanne et al. I beschriebenen Methoden teilnehmen.
  • Eine der Herausforderungen, die von der vorliegend beschriebenen CDN-Architektur auferlegt werden, ist, dass das DNS-System wieder verwendet wird, um eine Client-Umleitung durchzuführen, was dazu führt, dass der ursprüngliche Ort der Inhalte verloren geht. Um dies zu überwinden, können zusätzliche Inhalt-Identifikationsinformationen anderswohin übertragen werden, z.B. wie vorstehend beschrieben durch Einbetten des URL. Die Kehrseite dieses Lösungsansatzes ist, dass Vorrichtungen, die sich auf die herkömmliche URL-Semantik verlassen, nicht funktionieren können, z.B. kann ein Webcache die ursprünglichen Inhalte nicht aus der im URL angegebenen Host-Adresse holen.
  • Um damit umgehen zu können, müssen Legacy-Vorrichtungen entweder so konfiguriert sein, dass sie dieses Problem auf eine "CDN-bewußte" Komponente offloaden können, oder sie müssen so geändert werden, dass sie mit der neuen Architektur zusammenpassen. Bei dem ersteren Lösungsansatz könnte beispielsweise eine Webcache dazu konfiguriert sein, einen CDN-bewußten Inhalte-Router unter Verwendung des Internet Caching Protocol (ICP) als übergeordnete Instanz zu verwenden, ein Schema, das so gut wie alle im Handel verfügbaren Cache-Speicher unterstützen. Wenn ein solcher Cache-Speicher eine Inhaltsanfrage für Inhalte empfängt, die nicht bereits im Cache-Speicher vorhanden sind, leitet er die Anfrage an den übergeordneten ICP weiter, der dann mit den betreffenden Daten antwortet, indem er die modifizierte URL interpretiert, die Inhalte über das CDN-Netz zieht, und die geholten Daten an den anfragenden Cache-Speicher zurücksendet.
  • Als Alternative kann eine existierende Servertechnologie mit Regeln bezüglich der Auflösung der Inhaltsanfrage über die Konventionen im URL erweitert werden. D.h., ein neues URL-Format könnte derart definiert werden, dass Webcaches das spezielle Format erkennen und die Anfrage gemäß der neuen Semantik behandeln könnten, z.B. bei einem Fehlversuch holt der Cache-Speicher die Inhalte aus der im URL eingebetteten Serverstelle. Oder der Cache-Speicher könnte mit Protokollen erweitert werden, die mit dem CDN-Netz übereinstimmen, und könnte die Inhalte direkt über den CDN holen. Auf ähnliche Weise könnte für Live-Inhalte ein modifizierter Streaming Media-Server an einem Broadcast teilnehmen, indem er einer Anwendungsschicht-Multicast-Gruppe beitritt, die entweder im URL eingebettet oder aus einem Directory unter Verwendung von Metainformation gewonnen werden, die in den URL codiert sind.
  • 4. Client-Driven Service Rendezvous (CDSR)
  • 4.1. Allgemeine CDSR-Architekturen
  • Während die DNS-basierte Umleitung und die expliziten Umleitungsmethoden gemäß der vorstehenden Beschreibung gangbare Lösungsansatze für Content Peering auf der Grundlage von APAR-Routing zur Verfügung stellen, weisen sie auch einige Beschränkungen auf. Bei dem DNS-Lösungsansatz konfigurieren Anwender beispielsweise häufig ihre Hosts unrichtig, um DNS-Server zu verwenden, die sich in anderen Serviceprovider-Netzen befinden, und zwar entweder aus Versehen (z.B. weil sie Provider wechseln, ohne ihre DNS-Serveradresse zu aktualisieren) oder absichtlich (z.B. weil das DNS-System ihres Providers eine geringe Leistungsfähigkeit besitzt). Selbst wenn ein Host ordnungsgemäß mit dem topologisch nächsten DNS-Server konfiguriert ist, ist die Genauigkeit der DNS-basierten Umleitung nur so gut wie die Granularität der Abdeckung von DNS-Servern. Beispielsweise kann ein ISP nur einen DNS-Server für sein gesamtes autonomes System installieren. In diesem Fall werden alle Umleitungsentscheidungen für alle Kunden dieses ISP bezogen auf diesen einen DNS-Server durchgeführt. Darüber hinaus cachen DNS-Server häufig Namensübersetzungsergebnisse selbst dann, wenn das DNS-Antwortpaket einen Lebenszeitwert von 0 angibt. Bei der Beantwortung einer Serviceanfrage kann ein APAR-DNS-Server somit nicht sicher stellen, dass sich nur ein Client für eine gegebene Umleitungstransaktion an den gewählten Server anschließt. Aus diesem Grund ist die Anzahl von Clients, die eine Kommunikation mit diesem Server versuchen, nicht einfach zu kontrollieren. Schließlich cachen Clients häufig Name-zu-Adresse-Übersetzungen in der Anwendung selbst, weil sie annehmen, dass der DNS ein stabiles, (nahezu) statisches Mapping von Namen auf Adressaten zur Verfügung stellt. Wenn in diesem Fall ein Server ausfällt und der Client versucht, den ausgefallenen Server zu kontaktieren, hat das Umleitungssystem keine Gelegenheit, zu einer alternativen Adresse für den ausgefallenen Server zurückzukehren.
  • Der explizite Umleitungsvorgang ist (verglichen mit einer Transaktionsumleitung wie dem APAR-DNS-Lösungsansatz) rechen- und speicherintensiv, weil er die Herstellung einer TCP-Verbindung, das Assemblieren der Anfragenachricht aus beliebigen TCP-Paketen, das Parsen der Anwendungsschicht-Protokolle, welche die Anfragenachricht umfassen, das Antworten mit einer ordnungsgemäß gebildeten Umleitungsnachricht, und das Herunterfahren der Verbindung beinhalten. Im Vergleich dazu beinhaltet ein Transaktionsumleitungssystem lediglich das Empfangen eines einzelnen Anfragepakets, das Parsen seines Inhaltes, und das Antworten mit einem einzelnen Antwortpaket. Es gibt keine einschlägige Verbindungszustand- oder Protokollverarbeitung, die über eine Paketsequenz stattfinden muss. Darüber hinaus beruht die explizite Umleitung auf etwas komplexen anwendungsspezifischen Protokollen, die hinsichtlich ihres Anwendungsbereiches unflexibel sind. Beispielsweise wenn die Umleitungsvorrichtung einen Client zu einem bestimmten Server geleitet hat, ist diese Client-Server-Beziehung festgelegt. Falls also der Server ausfällt oder der Netzpfad zwischen dem Client und dem Server Probleme mit der Leistungsfähigkeit aufweist oder ausfällt, kann der Client sich nicht erneut mit einem alternativen Ort verbinden, weil das Umleitungssystem nicht mehr an der Server-Client-Kommunikation mitwirkt.
  • Um diese Probleme zu überwinden, kann die Umleitung als ein zentraler und grundlegender Teil der Internet-Infrastruktur neu ausgelegt werden, ebenso wie das DNS-System ein zentraler und allgegenwärtiger Teil des Internet ist. Bei DNS umfasst jeder Host im Internet einen Logik- und Konfigurationszustand, der es jedem Internet-Host ermöglicht, dynamisch mit der Infrastruktur zu interagieren, um Name-zu-Adresse-Übersetzungen durchzuführen. D.h., ein Host wird mit der IP-Adresse eines DNS-Servers konfiguriert, der Namensübersetzungen für diesen Client durchführt – der Client interagiert mit intelligenten Agenten (d.h. Namen-Servern) in der Infrastruktur, um diesen Dienst zu erhalten.
  • 17 veranschaulicht diese Architektur. Hier rufen Anwendungen einen Stub Resolver am End-Host auf, der wiederum mit DNS-Serveragenten in der Netzinfrastruktur interagiert. Alle diese Agenten verwenden den zugrundeliegenden IP-Paket-Weiterleitungsdienst für die Kommunikation untereinander.
  • Ein allgegenwärtiges Umleitungssystem kann gemäß der gleichen Denkweise aufgebaut werden, wie in 18 dargestellt ist. Bei diesem Modell interagieren Anwendungen direkt mit einem Umleitungs-Stub, der naiv auf dem End-Host läuft. Dieser Umleitungs-Stub kommuniziert wiederum mit intelligenten Agenten in der Netzinfrastruktur, um explizite Umleitungsfunktionen für den Client auszuführen. Weil eine neue Schnittstelle mit dem Umleitungssystem erzeugt wird, und Anwendungen spezifisch dazu ausgelegt sind, mit diesem Untersystem zu interagieren, sind die Probleme im Zusammenhang mit transparenten Formen des Umleitens beseitigt. Beispielsweise können Anwendungen eine spezifische Logik zum Wiederherstellen von Dienstverbindungen mit ausgefallenen oder fehlerhaften Servern umfassen. Dieser Lösungsansatz für das Umleiten wird als "Client-driven Service Rendezvous" (CDSR) bezeichnet, da der End-Client aktiv an dem Umleitungsvorgang teilnimmt.
  • Wenn CDSR auf dem vorausgehend beschriebenen APAR-Routing-System aufbaut, stellt es einen skalierbaren und inkrementell installierbaren Rahmen für Content Peering im großen Maßstab zur Verfügung, wobei verschiedene Serviceprovider verschiedene Teile der physischen Infrastruktur besitzen und betreiben, um in Peering-Arrangements auf dem Inhalteniveau einzutreten. Bei diesem Modell kann das vorausgehend beschriebene APAR-Routing-System verwendet werden, um Content Peering unter Verwendung eines Client-getriebenen Umleitungsagenten durchzuführen, der vorliegend als eine CDSR-Umleitungsvorrichtung bezeichnet wird. Hierbei ist eine CDSR-Umleitungsvorrichtung mit einer oder mehreren APAR-Anycast-Adressen konfiguriert. Wie bei APAR-DNS ist die CDSR-Umleitungsvorrichtung ein einzelner Teil der physischen Infrastruktur, der entweder im Besitz des ISP ist, bei dem sich die Vorrichtung befindet, oder eines Dritten, der die Gerätschaft in Kollokation im Netz des ISP anordnet, der mehrere virtuelle CDNs unterstützt, die im Besitz von dritten Inhalte-Serviceproviders oder vielleicht von anderen ISPs sind.
  • Um eine CDSR-Umleitung zu unterstützen, sind Client-Anwendungen so modifiziert, dass sie direkt mit dem Umleitungssystem interagieren, indem sie einen Umleitungs-Stub auf dem lokalen Host aufrufen. Dieser Stub kommuniziert wiederum über APAR-Anycast-Routing mit CDSR-Umleitungsvorrichtungen in der Netzinfrastruktur. Dieser Dialog findet als eine einfache Einzelpaket-Anfrage/Antwort-Interaktion statt, so dass die Transaktion zustandslos ist und dadurch Probleme im Zusammenhang mit Route-Flaps vermeidet (d.h. wenn ein Route-Flap dazu führt, dass eine Sequenz von Anycast-Paketen an unterschiedliche physische Hosts geleitet wird, was ansonsten eine zustandsbehaftete Transaktion abbrechen würde).
  • Es gibt viele mögliche Wege, wie ein Client diese Service Rendezvous-Aufgabe durchführen könnte, aber ein solcher Mechanismus könnte auf dem weithin akzeptierten Verfahren des Verweisens auf Inhaltsressourcen und Dienste mit URLs beruhen. Im gegenwärtigen Stand der Technik parst eine Anwendung wie ein Webbrowser oder ein Streaming Media-Player einen URL in eine Serverkomponente und relative Pfadkomponente. Die Serverkomponente wird typischerweise mit dem DNS-System zur IP-Adresse des Servers aufgelöst. Die Anwendung leitet dann eine TCP-Verbindung mit diesem Server ein und gibt eine Anfrage nach dem Objekt aus, das von der relativen Pfadkomponente unter Verwendung eines Anwendungsschicht-Protokolls wie HTTP oder RTSP angegeben ist. Das Objekt wird dann empfangen oder über die Verbindung an den Client gestreamt oder über eine verknüpfte Verbindung, die als ein Nebeneffekt der ursprünglichen Transaktion erzeugt wird.
  • Unter CDSR verwendet der Client einen alternativen Lösungsansatz. Anstatt den URL in Server- und Pfadkomponenten zu parsen und eine Verbindung mit dem Server einzuleiten, präsentiert der Client den gesamten URL dem CDSR-Stub, der wiederum ein Serviceanfragepaket an die nächste CDSR-Umleitungsvorrichtung in der Netzinfrastruktur sendet. Die nächste Umleitungsvorrichtung wird implizit durch die Verwendung von APAR-Anycast-Routing lokalisiert. D.h., das Paket wird an eine Anycast-Adresse wie etwa A* gesendet, die dem CDN-Backbone zugeordnet ist, das die Inhalte hostet, auf welche die betreffende URL verweist. Es gibt viele mögliche Verfahren zum Erhalten der Adresse A*, aber ein solches Verfahren wäre es, die Adresse im URL gemäß allgemein bekannter Konventionen einzubetten, z.B. als Teil des Pfades oder als die Server-Adresse.
  • Beispielsweise könnte ein URL, der auf eine Nachrichteneinspeisung ("news.rm" genannt) verweist, die auf dem "any"-Knoten auf dem ACME Networks-CDN verfügbar ist, die folgende Form haben:
    rtsp://any.cdn.acme.net/news.rm
  • Hier würde der Client die Host-Komponente des URL "any.cdn.acme.net" inspizieren und durch irgendeinen Mechanismus bestimmen, dass dieser URL auf ein CDN-Backbone und nicht auf einen spezifischen Server verweist. Es gibt viele Möglichkeiten für die Durchführung dieser Bestimmung, aber ein solcher Mechanismus wäre es, eine allgemein bekannte Menge von IP-Adressen zu definieren, damit sie als APAR-Anycast-Adressen dienen. Beispielsweise kann IANA einen besonderen Bereich von Unicast-Adressen aus dem IP-Adressenraum reservieren, der spezifisch für APAR-Anycast-Routing vorgesehen ist. Oder eine statische Gruppe von Adressaten kann von verschiedenen Serviceprovidern zugewiesen werden und entweder durch statische Kompilierung oder durch dynamische Download-Aktualisierungen über das Internet in die End-Host Anwendungen konfiguriert werden. Mit diesen Konventionen könnte der Client durch Inspizieren der Adresse direkt ableiten, dass er statt der herkömmlichen Verfahren das CDSR-System für Service Rendezvous verwenden soll. Als Alternative könnte der DNS ein besonderes Attribut besitzen, das anzeigt, dass eine bestimmte DNS-Subdomain von dem CDSR-System verwaltet wird.
  • In Weiterführung des Beispiels sei angenommen, dass any.cdn.acme.net zu der IP-Adresse A* auflöst. Dann sendet der Client ein CDSR-Anfragepaket über UDP mit der IP-Adresse A* wie im Zieladressfeld des IP-Headers. Im Ergebnis wird das Anfragepaket an die topologisch nächste CDSR-Umieitungsvorrichtung geleitet, welche das Paket empfängt und den URL aus der Nutzlast dieses Paketes ausliest. Die CDSR-Umleitungsvorrichtung wiederum konsultiert ihre einkonfigurierten Richtlinien und Informationsbank von Lastmessungen, um einen geeigneten Ort zum Abschließen des anfragenden Clients zu bestimmen.
  • Ein Beispiel für diesen Vorgang ist in 19 ausführlicher dargestellt. Hier präsentiert ein Anwender eine URL einem Player (Pfad 300) über einen Mechanismus (z.B. durch Eintippen der URL in die Anwenderschnittstelle oder durch Klicken auf einen Hypertext-Link). Der Player parst dann den URL und löst den Domainnamen any.cdn.acme.net auf, indem er eine DNS-Anfrage entlang des Pfades 401 über den DNS-Resolver auf dem lokalen Host an einen nahe gelegenen DNS-Server 400 sendet. Der Server ruft das DNS-System auf normale Weise auf, um den Name in der Anycast-Adresse A* aufzulösen (die in den DNS durch einen Netzoperator konfiguriert ist, der auf geeignete Weise den autoritativen Nameserver für die acme.net DNS-Subdomain konfiguriert). Der DNS-Server wiederum antwortet mit der Adresse A* über den Pfad 402.
  • Zu diesem Zeitpunkt bestimmt der Client, dass die Adresse A* eine APAR-Anycast-Adresse ist, und sendet daher eine den URL enthaltene Serviceanfragenachricht an den CDSR-Stub 102 über den Pfad 301, alle innerhalb des lokalen Host. Der CDSR-Stub sendet dann ein Serviceanfragepaket in UDP verkapselt an A* adressiert in das Netz, welches das Paket an die topologisch nächste CDSR-Umleitungsvorrichtung 200 leitet. Die CDSR-Umleitungsvorrichtung bestimmt dann die Adresse eines Servers, mit dem sich der anfragende Client verbinden kann, wobei sie ihre Entscheidung auf einem beliebigen Satz von konfigurierten Richtlinien und Messungen basiert, die dynamisch aus dem laufenden System gesammelt werden, sowie die IP-Adresse des anfragenden Clients. Diese Richtlinien- und Konfigurationsinformationen werden der CDSR-Umleitungsvorrichtung dynamisch über einige externe Netzverwaltungsprotokolle zugeordnet, die möglicherweise von der CDN-Operationszentrale stammen, z.B. über den Netzpfad 207. Auf diese Weise, während sich Richtlinien im Lauf der Zeit entwickeln (z.B. auf der Grundlage von externen Geschäftsbeziehungen zwischen Netzprovidern und dem CDN-Serviceprovider), können die CDSR-Richtlinien aktualisiert werden, um bestimmte gewünschte Service Level-Vereinbarungen zu erfüllen.
  • Für einen ordnungsgemäßen Lastausgleich von Server- und Rechenressourcen überwacht die CDSR-Umleitungsvorrichtung die lokalen Server 201 und 202 über Kommunikationspfade 205 bzw. 206, oder die CDSR kann Lastaktualisierungen gemäß der vorstehenden Beschreibung über eine Anwendungsschicht-Multicast-Gruppe empfangen. Somit kann die CDSR-Umleitungsvorrichtung informierte Entscheidungen darüber treffen, wohin Clients auf der Grundlage der Serverlast umgeleitet werden sollen. Falls die gesamte lokale Diensteinrichtung voll ausgelastet ist, kann die CDSR-Umleitungsvorrichtung entscheiden, den Client tiefer in das Netz zu Servern umzuleiten, die in dem Diagramm nicht gezeigt sind. Diese Entscheidung kann auf Informationen beruhen, die von den alternativen Servern (z.B. ihrer Verfügbarkeit und Auslastung) zur Verfügung gestellt werden, die über den Weitbereich, z.B. über den Pfad 208, mitgeteilt werden können.
  • Angesichts all dieser Informationen ist die CDSR-Umleitungsvorrichtung dann in einer Position, das ursprüngliche Anfragepaket zu beantworten. Nimmt man beispielsweise an, dass bestimmt wird, dass der Server 201 der am besten geeignete Anschlusspunkt für den Client ist, überträgt die CDSR-Umleitungsvorrichtung ein Antwortpaket zurück zum CDSR-Stub auf dem End-Host über den Pfad 302, der die Adresse des Servers enthält, der die im ursprünglichen URL angegebenen Inhalte erfüllen kann. Der CDSR-Stub wiederum sendet dieses Ergebnis an die anfragende Anwendung zurück, die dann eine normale Inhaltetransaktion aufruft (z.B. einen Web-Transfer oder eine Instantiierung eines Streaming Media-Flusses) unter Verwendung traditioneller Client-Server-Protokolle, die an dem gewählten Server abschließen.
  • Falls schließlich die angeforderten Inhalte noch nicht am Server 201 vorhanden sind (d.h. weil sie nicht vorausgehend an diese Stelle verschoben oder über das Inhalte-Broadcast-Netz geleitet wurden), dann fordert der Server 201 die Inhalte über das Inhaltenetz durch einen nahegelegenen Inhalte-Router an, d.h. durch die Vorrichtung 203 oder die Vorrichtung 204. Ein Mechanismus zum Holen von Inhalten auf diese Weise gemäß einem Anwendungsschicht-Inhalte-Routingnetz ist in McCanne et al. I beschrieben.
  • 4.2. Weitbereichsinstallation
  • Der vorstehend beschriebene CDSR-Umleitungsmechanismus kann über eine Ansammlung von autonomen Systemen auf eine Weise ähnlich dem vorstehend beschriebenen, DNS-basierten Umleitungssystem installiert sein. Es wäre für einen Fachmann offensichtlich, dass die Variationen des vorstehend beschriebenen, DNS-basierten Umleitungssystems auf die in dieser Sektion beschriebenen CDSR-Umleitungsmechanismen angewendet werden könnten.
  • Um eine solche Konfiguration zu veranschaulichen, zeigt 20, wie das CDSR über den Weitbereich zwischen zwei kooperierenden Inhalte-Backbones und zwei Inhalte-Angliederungen installiert ist. Das Diagramm zeigt vier ASs (100, 200, 300 und 400), die an der IP-Schicht mit herkömmlichem Schicht 3-Peering über Links 1.2, 1.3, 2.3, 2.4 und 3.4 miteinander verbunden sind. Das AS 100 enthält zwei CDSR-Umleitungsvorrichtungen (101 und 103), die jeweils der Anycast-Adresse A* (die aus einem dem AS 100 zugeordneten CIDR-Block entnommen ist) und den Servern 102 und 104 zugeordnet sind. Das AS 200 enthält zwei CDSR-Umleitungsvor richtungen (201 und 203), die jeweils der Anycast-Adresse B* (die aus einem dem AS 200 zugeordneten CIDR-Block entnommen ist) und den Servern 202 und 204 zugeordnet sind. Bei dieser Konfiguration ist das AS 100 das A* Inhalte-Backbone, und AS 200 ist das B* Inhalte-Backbone.
  • Das AS 400 stellt eine Inhalteangliederung des B* Inhalte-Backbone dar, da es eine CDSR-Umleitungsvorrichtung 401 installiert hat, die mit der B* APAR-Anycast-Adresse adressiert ist. Der Server 402 stellt den Dienstanschlusspunkt für Clients auf dem B* Netz zur Verfügung. Auf ähnliche Weise stellt das AS 300 eine Inhalteangliederung von sowohl dem A*- als auch B*-Inhalte-Backbone dar, da es eine CDSR-Umleitungsvorrichtung 301 installiert hat, die sowohl mit der A* als auch B* APAR-Anycast-Adresse adressiert ist. Der Server 302 stellt den Dienstanschlusspunkt für Clients auf dem B* Netz zur Verfügung.
  • Es wird das Vorhandensein eines Inhalte-Broadcastnetzes angenommen, das die Serveranlage verbinden, um Anwendungsschicht-Multicast, Verkehrsverwaltung usw. durchzuführen (gemäß der Beschreibung in McCanne et al. I) und ist aus diesem Diagramm weggelassen, um die vorliegende Erörterung zu erleichtern. D.h., Anwendungsschicht-Verbindungen sind zwischen den verschiedenen Servern (102, 104, 202, 204, 302 und 402) und Inhaltsquellen 10, 11 und 12 (und möglicherweise anderen, nicht gezeigten Inhalte-Routingvorrichtungen) vorhanden, um Inhalte (d.h. Live Streams, On-Demand Clips, Dateien usw.) von den Einspeisungspunkten an den Quellen an jeden Server zu leiten, der die Inhalte benötigt, um die Client-Anfragen zu erfüllen.
  • Mit dieser Gesamtarchitektur können die Clients 303 und 403 gemäß der Reichweite des jeweiligen Netzes unter Verwendung von CDSR auf effiziente Weise gegenseitig auf die Inhalte ihrer Inhaltenetze zugreifen. Das System funktioniert folgendermaßen. Im Falle von Client 403 sei angenommen, dass der Anwender Inhalte durch einen URL anfordert, der sich auf Inhalte von der Quelle 11 beziehen. Der Client decodiert den URL (möglicherweise mithilfe eines externen Directory-Systems wie DNS), um zu bestimmen, dass der URL auf Inhalte auf dem B*-Backbone verweist. Folglich überträgt der Client diese URL in einem Serviceanfragepaket, das an B* adressiert ist. APAR-Anycast-Routing liefert dieses Anfragepaket an die CDSR-Umleitungsvorrichtung 401, welche den URL inspiziert, einen geeigneten Server (wie z.B. Server 402) wählt, und eine Antwort zurücksendet, die anzeigt, dass der Client sich an das Inhaltenetz am Server 402 anschließen soll. Der Client 403 leitet dann eine Anwendungsverbindung (z.B. unter Verwendung von RTSP, HTTP usw.) an den Server 402 ein, um die Inhalte anzufordern, die über das CDN gemäß der vorstehenden Beschreibung geholt werden.
  • Nun sei angenommen, dass der Client 402 Inhalte anfordert, die durch einen URL angegeben sind, der auf Inhalte von der Quelle 10 verweist. Der Client decodiert den URL (möglicherweise mithilfe eines externen Directory-Systems wie DNS), um zu bestimmen, dass der URL auf Inhalte auf dem A*-Backbone verweist. Folglich überträgt der Client diesen URL in einem Serviceanfragepaket, das an A* adressiert ist. Dieses Mal liefert APAR-Anycast-Routing diese Anfrage im AS 400, aber weil in diesem AS keine A*-adressierten CDSR-Umleitungsvorrichtungen vorhanden sind, leiten die IP-Router das Anfragepaket zum AS 100 hin weiter (d.h. das extern den CIDR-Block ankündigt, der Adresse A* enthält). Es sei angenommen, dass die Route den Pfad 3.4 auf seinem Weg zum AS 100 überkreuzt. Somit tritt das Paket in das AS 300 ein, da aber die CDSR-Umleitungsvorrichtung 301 nun der A*-Adresse zugeordnet ist, wird das Anfragepaket zu dieser Vorrichtung geleitet, anstatt weiter zum AS 100 geleitet zu werden. Die Umleitungsvorrichtung 401 wiederum inspiziert den URL, wählt einen geeigneten Server (wie z.B. Server 302), und sendet eine Antwort zurück, die angibt, dass der Client sich an das Inhaltenetz am Server 302 anschließen soll. Der Client 403 leitet dann eine Anwendungsverbindung (z.B. unter Verwendung von RTSP, HTTP usw.) an den Server 302 ein, um die Inhalte anzufordern, die über das CDN gemäß der vorstehenden Beschreibung geholt werden. Es ist anzumerken, dass sich der Client an den nächsten Knoten in dem A*-verwurzelten CDN anschließt; selbst wenn der Client im AS 400 residiert und Dienstelemente in diesem AS vorhanden sind, wird stattdessen der Server 302 im AS 300 verwendet, weil er das nächstliegende Element auf dem A*-Netz ist.
  • 4.3. Gestufte Installation
  • Eine der Herausforderungen, auf welche die Installation von Client-driven Service Rendezvous trifft, sind die Änderungen, die an der bereits existierenden Basis von Anwendungen (d.h. Webbrowsern und Streaming Media-Clients) vorgenommen werden müssen, und die Propagierung dieser Änderungen in die aktive Anwendergemeinschaft. Dieser Übergang kann definitiv nicht auf ein Mal vonstatten gehen und muss stattdessen allmählich im Verlauf der Zeit ablaufen, während Verkäufer eine solche Fähigkeit in ihre Anwendungen integrieren und Anwender ihre Software er weitern. Somit muss das System in der Lage sein, eine Mischung aus Legacy-Anwendungen zusammen mit den neuen, CDSR-fähigen Anwendungen zu unterstützen.
  • Glücklicherweise ist eine gestufte Installation von CDSR-Fähigkeiten durch eine neuartige Kombination aus CDSR-Umleitung und expliziter Umleitung möglich. Bei dieser Methode werden CDSR-Umleitungsvorrichtungen parallel zu expliziten Umleitungsvorrichtungen installiert, und URLs werden so gegliedert, dass sie unter jedem dieser Szenarien effektiv arbeiten. Es gibt eine Anzahl von möglichen Weisen, um diese Koexistenz zu gliedern, und für einen Fachmann auf diesem Gebiet wäre es offensichtlich, wie die vorstehend beschriebenen Verfahren kombiniert werden könnten, um diese Art einer gestuften Installation durchzuführen.
  • Ein solcher Lösungsansatz ist es, mehrere Umleitungsvorgänge oder Agents zu betreiben, die verschiedene Arten von Umleitung auf jeder CDSR-Umleitungsvorrichtung durchführen. Beispielsweise könnte ein Vorgang eine RTSP-basierte Umleitung durchführen, während ein anderer eine native CDSR-Umleitung durchführt. Der erstere Vorgang würde z.B. an den TCP-Port 554 (d.h. den Standard-RTSP-Port) anbinden, während der letztere an irgendeinen allgemein bekannten UDP-Port wie etwa 2554 anbinden würde. Daraufhin würde das Inhaltenetz mit der Konvention konfiguriert werden, dass der Serverabschnitt eines jeden URL, der auf Inhalte auf diesem Netz verweist, zu der APAR-Anycast-Adresse dieses Netzes auflöst. Beispielsweise in der URL
    rtsp://any.cdn.acme.net//news.rm
    könnte der DNS-Name any.cdn.acme.net zu der Anycast-IP-Adresse A* auflösen. Wenn also ein Legacy-Client diese URL verarbeitet, leitet er eine RTSP-Verbindung an den IP-Host ein, der der Adresse A* am TCP-Port 554 zugeordnet ist. Das Netz wiederum leitet die Pakete, welche diese Verbindung umfassen, an die nächste CDSR-Umleitungsvorrichtung (mittels APAR-Anycast-Routing), und der auf dieser Vorrichtung ablaufende RTSP-Umleitungsvorrichtung stellt die Verbindung her. Für die Ausführung des Umleitungsschritts wählt die RTSP-Umleitungsvorrichtung einen möglichen Server (wie vorstehend erwähnt) und leitet den Client explizit zu diesem Server mittels einer RTSP Umleitungsnachricht um, bei der es sich um eine eingebaute Fähigkeit des RTSP-Protokolls handelt. Somit wird der Client ordnungsgemäß an einen geeigneten, nahe gelegenen Server umgeleitet.
  • Unter Verwendung der gleichen Infrastruktur inspiziert ein CDSR-bewusster Client die Adresse A*, die von dem DNS für den Namen any.cdn.acme.net zurückgesendet wird, und bestimmt, dass A* eine APAR Anycast-Adresse ist. Folglich ruft der Client das CDSR-Umleitungssystem durch Übertragung eines Serviceanfrage-UDP-Paketes auf, das den URL an die Adresse A* am UDP-Port 2554 enthält. Das Netz wiederum leitet die Pakete, welche diese Verbindung enthalten, zur nächsten CDSR-Umleitungsvorrichtung (mittels APAR-Anycast-Routing) weiter, und dieses Mal empfängt der CDSR-Umleitungsvorrichtungsvorgang, der auf dieser Vorrichtung abläuft, die Anfrage. Für die Ausführung des Umleitungsschritts wählt die CDSR-Umleitungsvorrichtung einen möglichen Server (wie bereits erwähnt) und sendet ein Antwortpaket zurück, das die Adresse diese Servers enthält, der für die Diensttransaktion (z.B. Web-Anfrage oder Streaming Media-Fluss) verwendet werden soll. Das Antwortpaket kann auch andere Hinweise enthalten, die für den Client nützlich sein könnten, z.B. eine Angabe, dass der Client die zurückgesendete Serveradresse für alle zukünftigen Inhaltsanfragen mit dem gleichen Serverkomponentennamen (z.B. any.cdn.acme.net) verwenden kann, oder dass der Client die Adresse auf diese Weise während einer bestimmten Zeitspanne (z.B. 5 Minuten) verwenden kann. Das Antwortpaket kann auch prädiktive Hinweise enthalten, die es Clients ermöglichen, mehr Informationen darüber abzuleiten, welche URLs von dem CDSR-Umleitungssystem behandelt werden.
  • 4.4. Webserver-gestufte Installation
  • Eine ähnliche Strategie kann für andere Typen von Protokollen und Anwendungen wie Webbrowser übernommen werden. In diesem Fall läuft ein HTTP-Umleitungsagent parallel zu einer CDSR-Umleitungsvorrichtung, die auf der APAR Anycastadressierten Vorrichtung läuft. Beispielsweise würde ein Legacy-Webbrowser, der den URL
    http://any.cdn.acme.net/index.html
    aufruft, versuchen, sich mit any.cdn.acme.net zu verbinden, von der wiederum angenommen wird, dass sie zu der APAR Anycast-Adresse A* auflöst.
  • D.h., ein Vorgang führt eine HTTP-basierte Umleitung durch, während ein anderer eine native CDSR-Umleitung durchführt. Der erstere Vorgang bindet z.B. an den TCP-Port 80 (d.h. den voreingestellten HTTP-Port) an, während der letztere an einen allgemein bekannten UDP-Port wie etwa 2554 anbindet. Daraufhin wird das Inhaltenetz mit der Konvention konfiguriert, dass der Serverabschnitt eines jeden URL, der zu Inhalten auf diesem Netz auflöst, auf die APAR Anycast-Adresse dieses Netzes hinweist. Beispielsweise in dem URL
    http://any.cdn.acme.net/index.html
    löst der DNS-Namen any.cdn.acme.net zu der Anycast IP-Adresse A* auf. Wenn also ein Legacy-Client diese URL verarbeitet, leitet er eine HTTP-Verbindung an den IP-Host ein, der der Adresse A* am TCP-Port 80 zugeordnet ist. Das Netz wiederum leitet die Pakete, die diese Verbindung enthalten, an die nächste CDSR-Umleitungsvorrichtung (mittels APAR-Anycast-Routing), und der HTTP-Umleitungsvorrichtungsvorgang, der auf dieser Vorrichtung läuft, stellt die Verbindung her. Um den Umleitungsschritt durchzuführen, wählt die HTTP-Umleitungsvorrichtung einen möglichen Server (wie bereits erwähnt) und leitet den Client mittels einer HTTP Umleitungsnachricht, die eine eingebaute Fähigkeit des HTTP-Protokolls ist, explizit zu diesem Server um. Somit wird der Client ordnungsgemäß an einen geeigneten, nahe gelegenen Server umgeleitet.
  • Unter Verwendung der gleichen Infrastruktur inspiziert ein CDSR-bewusster Client die Adresse A*, die vom DNS für den Namen any.cdn.acme.net zurückgesendet wird, und bestimmt, dass A* eine APAR-Anycast-Adresse ist. Folglich ruft der Client das CDSR-Umleitungssystem auf, indem er ein Serviceanfrage-UDP-Paket überträgt, das den URL zum Adressieren an A* am UDP-Port 2554 enthält. Das Netz wiederum leitet die Pakete, welche diese Verbindung aufweisen, an die nächste CDSR-Umleitungsvorrichtung (mittels APAR-Anycast-Routing), und dieses Mal empfängt der CDSR-Umleitungsvorrichtungsvorgang, der auf dieser Vorrichtung läuft, die Anfrage. Um den Umleitungsschritt durchzuführen, wählt die CDSR-Umleitungsvorrichtung einen möglichen Server (wie bereits erwähnt) und sendet ein Antwortpaket zurück, das die Adresse dieses Servers enthält, der für den Web-Transfer verwendet werden soll. Das Antwortpaket kann auch andere Hinweise enthalten, die für den Client nützlich sein könnten, z.B. die Angabe, dass der Client die zurückgesendete Serveradresse für alle zukünftigen Inhaltsanfragen mit dem gleichen Serverkomponentennamen (d.h. any.cdn.acme.net) verwenden kann, oder dass der Client die Adresse auf diese Weise während einer bestimmten Zeitspanne (z.B. 5 Minuten) verwenden kann. Das Antwortpaket kann auch prädiktive Hinweise enthalten, die es Clients ermöglichen, mehr Informationen darüber abzuleiten, welche URLs von dem CDSR-Umleitungssystem gehandhabt werden.
  • Bei einer anderen Konfiguration ist der HTTP-Umleitungsagent durch einen tatsächlichen Webserver ersetzt. Um diese Konfiguration zu skalieren, kann der Webserver optional mit einem Schicht 4-Switch lastausgeglichen sein. 21 veranschaulicht dieses Schema. Hierbei ist der Schicht 4-Switch 11 der virtuellen IP-Adresse A* zugeordnet und dazu konfiguriert, die A*/32 Host-Route in das Netz-Routingprotokoll anzukündigen, um ein APAR-Anycast-Routing zu bewirken. Der Switch 11 ist dazu konfiguriert, Verkehr vom UDP-Port 2554 an die CDSR-Umleitungsvorrichtung 12, zu leiten und jeglichen Webverkehr (am TCP-Port 80) an die Webserver 13 und 14 zu leiten (die auf eine größere Größe geclustert sein können). Der Switch 21 ist ähnlich gegenüber der CDSR-Umleitungsvorrichtung 22 und den Webservern 23 und 24 konfiguriert.
  • Zunächst sei angenommen, dass die Webbrowser-Clients 10 und 20 Legacy-Anwendungen sind, denen die CDSR-Umleitung nicht bewusst ist. Wenn der Client in diesem Fall 10 den URL
    http://any.cdn.acme.net/index.html
    aufruft, holt er die Inhalte direkt von dem Server über dem Switch 11, wohingegen der Client 20 die Inhalte von dem Server über dem Switch 21 holt.
  • Nun sei angenommen, dass die Clients 10 und 20 CDSR-bewusst sind. Wenn der Client 10 den URL parst, bestimmt er, dass die Serverkomponentenadresse eine APAR-Anycast-Adresse ist, und überträgt ein Serviceanfragepaket an die A* Anycast-Adresse, welche den URL enthält. Der Schicht 4-Switch leitet dieses Paket an die CDSR-Umleitungsvorrichtung 12, die einen nahe gelegenen Server wählt oder irgendeinen anderen Server, falls der lokale Cluster überlastet ist (wie vorstehend beschrieben), und sendet eine Antwortnachricht zurück, die diesen Server angibt, wie etwa den Server 14. Der Client holt dann die Inhalte unter Verwendung von HTTP vom Server 14. Eine ähnliche Transaktion findet zwischen dem Client 20 und dem Schicht 4-Switch 21 statt, wenn der Client 20 den betreffenden URL aufruft.
  • Unter Verwendung der vorstehend genannten Vorgehensweisen können Server leicht lastausgeglichen werden. Ein APAR-DNS-Routingschema kann auch verwendet werden, um Anfragen von unbefugten Clients zu beschränken. Beispielsweise könnte die Anfrage nach einer Domain-Namensauflösung Metadaten angeben, die einen befugten Client validieren. Der APAR-DNS-Server überprüft die Metadaten, und falls es scheint, dass der Client befugt ist, antwortet der APAR-DNS-Server auf die Anfrage mit einer Auflösung des Domainnamens in eine IP-Adresse und eine Port-Nummer, die durch eine Vorvereinbarung zwischen dem Content Server und dem APAR-DNS-Server oder dergleichen ein Port ist, über den der Content Server verbindet. Falls der Client nicht für den APAR-DNS-Server ersichtlich befugt ist, sendet der APAR-DNS-Server eine IP-Adresse und Port-Zahl von einem Port, den der Content Server ignoriert, zurück.
  • Eine Weise, auf die Content Peering gemäß der vorstehenden Beschreibung verwendet werden kann, ist innerhalb von Inhalteverteilernetzwerken, die von Netzserviceprovidern betrieben werden, die sich mit anderen solchen Inhalteverteilernetzwerken durch "Inhaltebörsen" (content exchange)-Providern zusammenschließen. Eine Inhaltebörse bei einer solchen Architektur ist eine Dienstinstanz, die Beziehungen zwischen den Inhalteprovidern und den Verteilernetzen vermittelt. Auf diese Weise können Inhaltebörsen Beziehungen mit Inhalteprovidern als ihren Kunden eingehen, aber die tatsächliche Übertragung des Verkehrs den Inhalteverteilernetzwerken überlassen. Dies führt zu einer Landschaft, in der eine Anzahl von Inhaltebörsen auftreten und als Makler zwischen Inhalteprovidern und Inhalteverteilernetzwerken wirken, die im Besitz der Netzserviceprovider sind und von diesen betrieben werden, und die Anzahl von Inhaltebörsen für einen effizienten Betrieb klein genug ist.
  • Es wurde somit eine neuartige Datenstrom-Broadcast-Verteilungsmethode unter Verwendung von Content Peering und anderen neuartigen Elementen beschrieben.

Claims (10)

  1. Verfahren zum Liefern von Inhalten an einen Client (12) in einem Netzwerk (36), welches eine Vielzahl von Content Servern (14) mit einer Vielzahl von Clients verbindet, wobei die Clients nach einer Inhalte bereitstellenden Verbindung über Internet-Serviceprovider suchen, wobei die Inhalte sich zu Beginn auf einem Content Server (14) befinden und in das Netzwerk an einem Einspeisungspunkt (26) eingespeist werden, wobei mindestens zwei Internet-Serviceprovider eine Verknüpfung für ein gemeinsames Anbieten von Inhalten (content peering relationship) haben, wobei der erste Internet-Serviceprovider Inhalte an Clients überträgt und liefert, welche mit dem zweiten Internet-Serviceprovider verbunden sind, und der zweite Internet-Serviceprovider Inhalte an Clients überträgt und liefert, welche mit dem ersten Internet-Serviceprovider verbunden sind, wobei eingespeiste Inhalte von dem Einspeisungspunkt unter den gemeinsam Inhalte anbietenden Internet-Serviceprovidern aufgeteilt werden, wobei das Verfahren aufweist: Empfangen einer Anfrage nach Inhalten von dem Client; und Leiten der Anfrage an einen Content Server, auf der Grundlage von Verknüpfungen zwischen den Internet-Serviceprovidern für ein gemeinsames Anbieten von Inhalten, unter Verwendung von Anycast-Routing.
  2. Verfahren gemäß Anspruch 1, wobei die Anfrage an eine Anycast-Adresse (A*, B*) gerichtet ist, welche zu Vorrichtungen (A1*, A2*, A3*, A4*, B1*, B2*, B3*, B4*) in einem ersten autonomen System (AS100, AS200, AS300) zugeordnet ist, wobei das Verfahren ferner ein Leiten der Anfrage an die nächste der Vorrichtungen (A1*, A2*, A3*, A4*, B1*, B2*, B3*, B4*) einschließt, denen die Anycast-Adresse (A*, B*) zugeordnet ist.
  3. Verfahren gemäß Anspruch 1 oder 2, wobei die Anfrage an eine Anycast-Adresse (A*, B*) gerichtet ist, welche zu Vorrichtungen (A1*, A2*, A3*, A4*, B1*, B2*, B3*, B4*) in einem ersten autonomen System (AS100, AS200, AS300) zugeordnet ist, wobei das Verfahren ferner ein Leiten der Anfrage an eine Vorrichtung innerhalb eines zweiten, an das erste autonome System (AS100, AS200, AS300) angegliederten, autonomen Systems (AS500) einschließt.
  4. Verfahren gemäß einem der vorhergehenden Ansprüche, wobei eine Umleitungsstruktur (50) für ein Weiterleiten der Anfrage an den Content Server auf der Grundlage von Verknüpfungen für ein gemeinsames Anbieten von Inhalten bereitgestellt wird und wobei die Umleitungsstruktur dafür eingerichtet ist, den Client an einen Edge Server auf der Grundlage von einer Client-Umgebung, von Netzwerkpfadcharakteristika, von Server-Auslastung und -Ausnutzung und auf der Grundlage von der Verknüpfung für ein gemeinsames Anbieten von Inhalten anzuschließen.
  5. Verfahren gemäß Anspruch 4, wobei die Umleitungsstruktur (50) dafür eingerichtet ist, die Anfrage an den Content Server auf der Grundlage von im Hintergrund erfassten Auslastungs- und Netzwerkmesswerten weiterzuleiten.
  6. Verfahren gemäß einer der vorhergehenden Ansprüche, wobei ein Verteilernetzwerk (52) zum Verteilen der Inhalte vom Einspeisungspunkt (26) an eine Server-Anordnung (54) eingerichtet ist.
  7. Verfahren gemäß Anspruch 1, ferner den Schritt aufweisend: Verteilen an Umleitungsvorrichtungen, welche Anwendungsschicht-Multicast-Routing verwenden, von mindestens einem aus: Richtlinien für ein Weiterleiten von Inhalten, Server-Auslastungsinformation, Ressourcenverfügbarkeit und Abgleichinformation.
  8. Verfahren gemäß Anspruch 1, wobei die Anfrage eine explizite Serviceanfrage an eine Anycast-Adresse aufweist, um eine topologische Lage über Anycast-Routing einzuschließen.
  9. Verfahren gemäß Anspruch 8, wobei die Anfrage auf der Grundlage des topologischen Lage-Zusammenhangs geleitet wird.
  10. Verfahren gemäß Anspruch 1, ferner einschließend: Verwenden einer Umleitung in entfernten autonomen Systemen, um einen Lastausgleich bei einer Vielzahl von Servern in nahegelegenen autonomen Systemen durchzuführen.
DE60036021T 1999-12-20 2000-12-19 System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt Expired - Lifetime DE60036021T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US17274699P 1999-12-20 1999-12-20
US172746P 1999-12-20
US09/609,442 US6785704B1 (en) 1999-12-20 2000-07-03 Content distribution system for operation over an internetwork including content peering arrangements
US609442 2000-07-03
PCT/US2000/034675 WO2001052497A2 (en) 1999-12-20 2000-12-19 A content distribution system for operation over an internetwork including content peering arrangements

Publications (2)

Publication Number Publication Date
DE60036021D1 DE60036021D1 (de) 2007-09-27
DE60036021T2 true DE60036021T2 (de) 2008-05-08

Family

ID=26868415

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60036021T Expired - Lifetime DE60036021T2 (de) 1999-12-20 2000-12-19 System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt

Country Status (5)

Country Link
US (2) US6785704B1 (de)
EP (4) EP1865684B1 (de)
AU (1) AU2282701A (de)
DE (1) DE60036021T2 (de)
WO (1) WO2001052497A2 (de)

Families Citing this family (658)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185598B1 (en) * 1998-02-10 2001-02-06 Digital Island, Inc. Optimized network resource location
US8060613B2 (en) 1998-02-10 2011-11-15 Level 3 Communications, Llc Resource invalidation in a content delivery network
US20020126135A1 (en) * 1998-10-19 2002-09-12 Keith Ball Image sharing for instant messaging
US7339595B2 (en) 1998-10-19 2008-03-04 Lightsurf Technologies, Inc. Method and system for improved internet color
US7664864B2 (en) * 1998-11-13 2010-02-16 Verisign, Inc. Meta content distribution network
US8266266B2 (en) 1998-12-08 2012-09-11 Nomadix, Inc. Systems and methods for providing dynamic network authorization, authentication and accounting
US7194554B1 (en) 1998-12-08 2007-03-20 Nomadix, Inc. Systems and methods for providing dynamic network authorization authentication and accounting
US8713641B1 (en) 1998-12-08 2014-04-29 Nomadix, Inc. Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device
US7299294B1 (en) * 1999-11-10 2007-11-20 Emc Corporation Distributed traffic controller for network data
US6415323B1 (en) * 1999-09-03 2002-07-02 Fastforward Networks Proximity-based redirection system for robust and scalable service-node location in an internetwork
US7120694B2 (en) * 1999-10-22 2006-10-10 Verizon Laboratories Inc. Service level agreements and management thereof
AU1224101A (en) 1999-10-22 2001-05-08 Nomadix, Inc. Gateway device having an xml interface and associated method
US6405252B1 (en) 1999-11-22 2002-06-11 Speedera Networks, Inc. Integrated point of presence server network
US6694358B1 (en) * 1999-11-22 2004-02-17 Speedera Networks, Inc. Performance computer network method
WO2001050331A2 (en) * 2000-01-06 2001-07-12 L90, Inc. Method and apparatus for selecting and delivering internet based advertising
US6647420B2 (en) * 2001-01-18 2003-11-11 Reynolds And Reynolds Holdings, Inc. Enterlink for providing a federated business to business system that interconnects applications of multiple companies
US20020031131A1 (en) * 2000-02-02 2002-03-14 Yechiam Yemini Method and apparatus for the exchange of data between a dynamically addressed network and a foreign network
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US6519773B1 (en) 2000-02-08 2003-02-11 Sherjil Ahmed Method and apparatus for a digitized CATV network for bundled services
US7552233B2 (en) * 2000-03-16 2009-06-23 Adara Networks, Inc. System and method for information object routing in computer networks
US6981180B1 (en) * 2000-03-16 2005-12-27 Akamai Technologies, Inc. Method and apparatus for testing request-response service using live connection traffic
US7565450B2 (en) * 2000-03-16 2009-07-21 Adara Networks Inc. System and method for using a mapping between client addresses and addresses of caches to support content delivery
US7162539B2 (en) * 2000-03-16 2007-01-09 Adara Networks, Inc. System and method for discovering information objects and information object repositories in computer networks
JP3617406B2 (ja) * 2000-03-30 2005-02-02 日本電気株式会社 マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法並びにサービス仲介装置
US20020073033A1 (en) * 2000-04-07 2002-06-13 Sherr Scott Jeffrey Online digital video signal transfer apparatus and method
US7024466B2 (en) * 2000-04-07 2006-04-04 Movielink, Llc Network configured for delivery of content for download to a recipient
US6937814B1 (en) * 2000-04-14 2005-08-30 Realnetworks, Inc. System and method for play while recording processing
WO2001080515A2 (en) * 2000-04-17 2001-10-25 Circadence Corporation System and method for data prioritization
US7908337B2 (en) * 2000-04-28 2011-03-15 Adara Networks, Inc. System and method for using network layer uniform resource locator routing to locate the closest server carrying specific content
US7725596B2 (en) * 2000-04-28 2010-05-25 Adara Networks, Inc. System and method for resolving network layer anycast addresses to network layer unicast addresses
US7343422B2 (en) * 2000-04-28 2008-03-11 Adara Networks, Inc. System and method for using uniform resource locators to map application layer content names to network layer anycast addresses
US7577754B2 (en) * 2000-04-28 2009-08-18 Adara Networks, Inc. System and method for controlling access to content carried in a caching architecture
US20010039547A1 (en) * 2000-05-08 2001-11-08 Black Jonathan K. Internet web-based technology for storing, archiving, and updating key personal identity items
US7020698B2 (en) * 2000-05-31 2006-03-28 Lucent Technologies Inc. System and method for locating a closest server in response to a client domain name request
WO2002003614A2 (en) * 2000-06-29 2002-01-10 Cachestream Corporation Virtual multicasting
US8341297B2 (en) 2000-07-19 2012-12-25 Akamai Technologies, Inc. Latencies and weightings in a domain name service (DNS) system
US7912978B2 (en) * 2000-07-19 2011-03-22 Akamai Technologies, Inc. Method for determining metrics of a content delivery and global traffic management network
CN1404670A (zh) * 2000-07-24 2003-03-19 成津C&C株式会社 广播多频道网络电视的中继系统和组网方法
US7257581B1 (en) * 2000-08-04 2007-08-14 Guardian Networks, Llc Storage, management and distribution of consumer information
US8566248B1 (en) * 2000-08-04 2013-10-22 Grdn. Net Solutions, Llc Initiation of an information transaction over a network via a wireless device
US9928508B2 (en) * 2000-08-04 2018-03-27 Intellectual Ventures I Llc Single sign-on for access to a central data repository
US20060122917A1 (en) * 2000-08-14 2006-06-08 Urbanpixel Inc Real-time collaborative commerce in a multiple browser environment
JP2002074123A (ja) * 2000-08-31 2002-03-15 Sony Corp サーバの使用予約方法、予約管理装置およびプログラム格納媒体
US20030061294A1 (en) * 2000-09-19 2003-03-27 Stennicke Michael B. Method and apparatus for digital media exchange
US7657629B1 (en) 2000-09-26 2010-02-02 Foundry Networks, Inc. Global server load balancing
US7454500B1 (en) 2000-09-26 2008-11-18 Foundry Networks, Inc. Global server load balancing
US9130954B2 (en) 2000-09-26 2015-09-08 Brocade Communications Systems, Inc. Distributed health check for global server load balancing
JP2002108840A (ja) * 2000-09-28 2002-04-12 Toshiba Corp 分散型注文受付システム、受付サーバ、コンテンツサーバ、分散型注文受付方法及びコンピュータプログラム製品
US7197566B1 (en) * 2000-09-29 2007-03-27 Intel Corporation Method and apparatus for selecting server to distribute multimedia data via a network
US6970943B1 (en) * 2000-10-11 2005-11-29 Nortel Networks Limited Routing architecture including a compute plane configured for high-speed processing of packets to provide application layer support
US7349994B2 (en) * 2000-10-17 2008-03-25 Avaya Technology Corp. Method and apparatus for coordinating routing parameters via a back-channel communication medium
US7720959B2 (en) 2000-10-17 2010-05-18 Avaya Inc. Method and apparatus for characterizing the quality of a network path
US8023421B2 (en) 2002-07-25 2011-09-20 Avaya Inc. Method and apparatus for the assessment and optimization of network traffic
DE60141417D1 (de) 2000-10-17 2010-04-08 Avaya Technology Corp Verfahren und vorrichtung zur optimierung der leistung und des kosten in einem internetzwerk
US20010013052A1 (en) * 2000-10-25 2001-08-09 Yobie Benjamin Universal method and apparatus for disparate systems to communicate
US6970939B2 (en) * 2000-10-26 2005-11-29 Intel Corporation Method and apparatus for large payload distribution in a network
AU2002236435A1 (en) * 2000-10-26 2002-05-21 Prismedia Networks, Inc. Method and apparatus for real-time parallel delivery of segments of a large payload file
EP1364510B1 (de) * 2000-10-26 2007-12-12 Prismedia Networks, Inc. Verfahren und system zur verwaltung von verteilten inhalten und entsprechenden metadaten
AUPR129300A0 (en) * 2000-11-07 2000-11-30 Devsecure Pty Ltd Encoding of universal resource locators in a security gateway to enable manipulation by active content
US7047273B2 (en) * 2000-11-28 2006-05-16 Navic Systems, Inc. Load balancing in set top cable box environment
US7155487B2 (en) * 2000-11-30 2006-12-26 Intel Corporation Method, system and article of manufacture for data distribution over a network
US7039014B1 (en) * 2000-12-26 2006-05-02 Cisco Technology, Inc. Network-wide connection-based debug mechanism
US7035911B2 (en) 2001-01-12 2006-04-25 Epicrealm, Licensing Llc Method and system for community data caching
US7188145B2 (en) 2001-01-12 2007-03-06 Epicrealm Licensing Llc Method and system for dynamic distributed data caching
US20020138561A1 (en) * 2001-02-16 2002-09-26 Gemini Networks, Inc. System, method, and computer program product for an end-user of an open access network to select a new service provider following a discontinuance of a business relationship between their current service provider and the operator of the open access network
JP2002259259A (ja) * 2001-02-27 2002-09-13 Canon Inc 画像データ通信システム、画像データ通信方法および記憶媒体
EP1388073B1 (de) * 2001-03-01 2018-01-10 Akamai Technologies, Inc. Optimale routenauswahl in einem inhaltsablieferungsnetzwerk
JP4311899B2 (ja) * 2001-03-02 2009-08-12 パナソニック株式会社 コンテンツの配信および保護を行なう方法および装置
US7130908B1 (en) 2001-03-13 2006-10-31 Intelsat Ltd. Forward cache management between edge nodes in a satellite based content delivery system
US7174373B1 (en) 2001-03-13 2007-02-06 Panamsat Corporation Self-contained demonstration node in a satellite based content delivery system
US7154898B1 (en) 2001-03-13 2006-12-26 Intelsat, Ltd. Scalable edge node
US7237017B1 (en) 2001-03-13 2007-06-26 Panamsat Corporation Micronode in a satellite based content delivery system
US7555561B2 (en) * 2001-03-19 2009-06-30 The Aerospace Corporation Cooperative adaptive web caching routing and forwarding web content data broadcasting method
EP1244262B1 (de) * 2001-03-23 2005-05-11 Sun Microsystems, Inc. Client- Abfragenumlenkung
US7085825B1 (en) * 2001-03-26 2006-08-01 Freewebs Corp. Apparatus, method and system for improving application performance across a communications network
US7720996B2 (en) * 2001-03-27 2010-05-18 Microsoft Corporation Internet protocol (IP) address proximity and application to peer provider location
US7149797B1 (en) * 2001-04-02 2006-12-12 Akamai Technologies, Inc. Content delivery network service provider (CDNSP)-managed content delivery network (CDN) for network service provider (NSP)
US7340505B2 (en) * 2001-04-02 2008-03-04 Akamai Technologies, Inc. Content storage and replication in a managed internet content storage environment
US20020198995A1 (en) * 2001-04-10 2002-12-26 International Business Machines Corporation Apparatus and methods for maximizing service-level-agreement profits
JP3884920B2 (ja) * 2001-04-16 2007-02-21 株式会社日立製作所 データ配送方法
US7237033B2 (en) 2001-04-30 2007-06-26 Aol Llc Duplicating switch for streaming data units to a terminal
US8572278B2 (en) 2001-04-30 2013-10-29 Facebook, Inc. Generating multiple data streams from a single data source
US7292571B2 (en) * 2001-04-30 2007-11-06 Aol Llc, A Delaware Limited Liability Company Load balancing with direct terminal response
US7124166B2 (en) 2001-04-30 2006-10-17 Aol Llc Duplicating digital streams for digital conferencing using switching technologies
US7266609B2 (en) * 2001-04-30 2007-09-04 Aol Llc Generating multiple data streams from a single data source
WO2003105006A1 (en) * 2001-04-30 2003-12-18 America Online, Inc. Load balancing with direct terminal response
US7185052B2 (en) * 2001-05-16 2007-02-27 Akamai Technologies, Inc. Meta content delivery network system
US20020184507A1 (en) * 2001-05-31 2002-12-05 Proact Technologies Corp. Centralized single sign-on method and system for a client-server environment
US8135834B1 (en) * 2001-06-18 2012-03-13 Packet Design, Inc. Method and system for causing intra-AS network traffic to be more evenly balanced
US20030005138A1 (en) * 2001-06-25 2003-01-02 Giffin Michael Shawn Wireless streaming audio system
EP1415446A1 (de) * 2001-07-05 2004-05-06 Koninklijke Philips Electronics N.V. Url-ersetzung für einen anhang beim weiterleiten elektronischer inhalte
US7761497B1 (en) * 2001-07-13 2010-07-20 Vignette Software, LLC Storage medium having a manageable file directory structure
US6981029B1 (en) * 2001-07-17 2005-12-27 Cisco Technology, Inc. System and method for processing a request for information in a network
US6981032B2 (en) * 2001-07-27 2005-12-27 International Business Machines Corporation Enhanced multicast-based web server
JP2003051837A (ja) * 2001-08-07 2003-02-21 Sony Corp アドレス管理システム、エニーキャスト・アドレス設定処理装置、通信端末装置、情報格納装置、およびアドレス管理方法、並びにコンピュータ・プログラム
FI20011651A (fi) * 2001-08-15 2003-02-16 Nokia Corp Palveluklusterin kuormituksen tasapainoittaminen
US20030055971A1 (en) * 2001-09-19 2003-03-20 Menon Rama R. Providing load balancing in delivering rich media
EP2403219B1 (de) 2001-09-28 2014-10-22 Level 3 CDN International, Inc. Verfahren zur Domänennamenauflösung
US7769823B2 (en) * 2001-09-28 2010-08-03 F5 Networks, Inc. Method and system for distributing requests for content
US7860964B2 (en) 2001-09-28 2010-12-28 Level 3 Communications, Llc Policy-based content delivery network selection
US7761594B1 (en) * 2001-10-15 2010-07-20 Netapp, Inc. Method and apparatus for forwarding requests in a cache hierarchy based on user-defined forwarding rules
US8914480B1 (en) * 2001-10-15 2014-12-16 6020356 Canada Inc. Method and device for transparent interception of socket connections
US7003575B2 (en) * 2001-10-15 2006-02-21 First Hop Oy Method for assisting load balancing in a server cluster by rerouting IP traffic, and a server cluster and a client, operating according to same
US20030079027A1 (en) * 2001-10-18 2003-04-24 Michael Slocombe Content request routing and load balancing for content distribution networks
US20080279222A1 (en) * 2001-10-18 2008-11-13 Level 3 Communications Llc Distribution of traffic across a computer network
NZ532773A (en) * 2001-11-01 2005-11-25 Verisign Inc Transactional memory manager
US20040072810A1 (en) * 2001-11-07 2004-04-15 Besins International Belgique Pharmaceutical composition in the form of a gel or a solution based on dihydrotestosterone, process for preparing it and uses thereof
US20030120680A1 (en) * 2001-11-16 2003-06-26 Rakesh Agrawal Method for directly providing content and services via a computer network
US8429221B2 (en) * 2001-12-13 2013-04-23 Rockstar Consortium Us Lp Content request routing method
US6954456B2 (en) * 2001-12-14 2005-10-11 At & T Corp. Method for content-aware redirection and content renaming
US8635305B1 (en) * 2001-12-19 2014-01-21 Cisco Technology, Inc. Mechanisms for providing differentiated services within a web cache
CA2471855C (en) * 2002-01-11 2013-03-19 Akamai Technologies, Inc. Java application framework for use in a content delivery network (cdn)
JP2003223378A (ja) * 2002-01-29 2003-08-08 Fujitsu Ltd コンテンツデリバリネットワークサービス方法及びシステム
US9167036B2 (en) * 2002-02-14 2015-10-20 Level 3 Communications, Llc Managed object replication and delivery
US8224986B1 (en) * 2002-03-07 2012-07-17 Cisco Technology, Inc. Methods and apparatus for redirecting requests for content
US7088718B1 (en) * 2002-03-19 2006-08-08 Cisco Technology, Inc. Server load balancing using IP option field approach to identify route to selected server
US6856991B1 (en) * 2002-03-19 2005-02-15 Cisco Technology, Inc. Method and apparatus for routing data to a load balanced server using MPLS packet labels
US7099936B2 (en) * 2002-03-29 2006-08-29 International Business Machines Corporation Multi-tier service level agreement method and system
US7315541B1 (en) * 2002-04-03 2008-01-01 Cisco Technology, Inc. Methods and apparatus for routing a content request
US7133905B2 (en) * 2002-04-09 2006-11-07 Akamai Technologies, Inc. Method and system for tiered distribution in a content delivery network
US9137324B2 (en) * 2002-04-10 2015-09-15 International Business Machines Corporation Capacity on-demand in distributed computing environments
ITTO20020341A1 (it) * 2002-04-19 2003-10-20 Telecom Italia Lab Spa Procedimento per realizzare l'interlavoro fra reti del tipo content delivery network -cdn-,relativo insieme di reti e componente di interfac
US20030204573A1 (en) * 2002-04-30 2003-10-30 Andre Beck Method of providing a web user with additional context-specific information
US7289519B1 (en) * 2002-05-01 2007-10-30 Cisco Technology, Inc. Methods and apparatus for processing content requests using domain name service
US7260598B1 (en) * 2002-05-03 2007-08-21 Cisco Technology, Inc. Methods and apparatus for processing client requests in a content distribution network using client lists
SE524989C2 (sv) * 2002-05-08 2004-11-09 Marratech Ab Anordning och förfarande för distribution av flödande realtidsinformation mellan klienter
US7945636B2 (en) * 2002-05-15 2011-05-17 In-Store Broadcasting Network, Llc Providing a multi-tier enterprise level application
US7657917B2 (en) * 2002-05-23 2010-02-02 Microsoft Corporation Interactivity emulator for broadcast communication
JP4221646B2 (ja) * 2002-06-26 2009-02-12 日本電気株式会社 共有キャッシュサーバ
US8028092B2 (en) 2002-06-28 2011-09-27 Aol Inc. Inserting advertising content
US20040015976A1 (en) * 2002-06-28 2004-01-22 Sun Microsystems, Inc., A Delaware Corporation Optimized distributed resource management system with digital signature
US7219120B2 (en) * 2002-07-09 2007-05-15 Savvis Communications Corporation Systems, methods and protocols for securing data in transit over networks
US7328237B1 (en) * 2002-07-25 2008-02-05 Cisco Technology, Inc. Technique for improving load balancing of traffic in a data network using source-side related information
US6947940B2 (en) * 2002-07-30 2005-09-20 International Business Machines Corporation Uniform name space referrals with location independence
US7086061B1 (en) 2002-08-01 2006-08-01 Foundry Networks, Inc. Statistical tracking of global server load balancing for selecting the best network address from ordered list of network addresses based on a set of performance metrics
US7565413B1 (en) * 2002-08-05 2009-07-21 Cisco Technology, Inc. Content request redirection from a wed protocol to a file protocol
US7574508B1 (en) 2002-08-07 2009-08-11 Foundry Networks, Inc. Canonical name (CNAME) handling for global server load balancing
US20040034705A1 (en) * 2002-08-13 2004-02-19 Mihai Focsaneanu Connecting devices in a data network
US7461147B1 (en) * 2002-08-26 2008-12-02 Netapp. Inc. Node selection within a network based on policy
JP2004086562A (ja) * 2002-08-27 2004-03-18 Fujitsu Ltd コンテンツ中継装置及びコンテンツ中継方法及びコンテンツ中継プログラム
ITTO20020762A1 (it) * 2002-09-02 2004-03-03 Telecom Italia Lab Spa Procedimento e sistema per realizzare stime di connettivita'
JP4019880B2 (ja) * 2002-09-26 2007-12-12 株式会社日立製作所 サーバ装置
US10051092B2 (en) * 2002-10-15 2018-08-14 Rockwell Collins, Inc. Method and device for transparent interception of socket connections
EP1552659B1 (de) * 2002-10-16 2015-01-14 Aepona Limited A service access gateway
US7310686B2 (en) * 2002-10-27 2007-12-18 Paxfire, Inc. Apparatus and method for transparent selection of an Internet server based on geographic location of a user
KR20040075460A (ko) * 2003-02-21 2004-08-30 엘지전자 주식회사 데이터 방송 시스템 및 그 운용 방법
US8145699B2 (en) 2003-05-30 2012-03-27 Microsoft Corporation Generalized proximity service
US7577939B2 (en) * 2003-06-27 2009-08-18 International Business Machines Corporation Method, system and program product for sharing source code over a network
US20040267875A1 (en) * 2003-06-30 2004-12-30 Hennessey Wade L. Method and apparatus for establishing peering rules for distributed content delivery
US7373394B1 (en) 2003-06-30 2008-05-13 Cisco Technology, Inc. Method and apparatus for multicast cloud with integrated multicast and unicast channel routing in a content distribution network
US9525566B2 (en) * 2003-07-31 2016-12-20 Cloudsoft Corporation Limited Self-managed mediated information flow
US20050125290A1 (en) * 2003-08-01 2005-06-09 Gil Beyda Audience targeting system with profile synchronization
US9928522B2 (en) 2003-08-01 2018-03-27 Oath (Americas) Inc. Audience matching network with performance factoring and revenue allocation
US7805332B2 (en) 2003-08-01 2010-09-28 AOL, Inc. System and method for segmenting and targeting audience members
US9118812B2 (en) 2003-08-01 2015-08-25 Advertising.Com Llc Audience server
US8150732B2 (en) * 2003-08-01 2012-04-03 Tacoda Llc Audience targeting system with segment management
US8464290B2 (en) 2003-08-01 2013-06-11 Tacoda, Inc. Network for matching an audience with deliverable content
US9117217B2 (en) 2003-08-01 2015-08-25 Advertising.Com Llc Audience targeting with universal profile synchronization
US8291062B2 (en) 2003-08-20 2012-10-16 Aol Inc. Managing access to digital content sources
US8909726B1 (en) 2003-08-27 2014-12-09 Cisco Technology, Inc. Priority based anycast routing
US7574528B2 (en) * 2003-08-27 2009-08-11 Cisco Technology, Inc. Methods and apparatus for accessing presence information
JP4303541B2 (ja) * 2003-09-02 2009-07-29 株式会社日立製作所 検索方法及び検索ブローカ
WO2005048019A2 (en) 2003-09-04 2005-05-26 Emc Corporation Data message mirroring and redirection
CN1902902A (zh) 2003-09-04 2007-01-24 Emc公司 数据消息镜像和重定向
US9584360B2 (en) 2003-09-29 2017-02-28 Foundry Networks, Llc Global server load balancing support for private VIP addresses
US20050076099A1 (en) * 2003-10-03 2005-04-07 Nortel Networks Limited Method and apparatus for live streaming media replication in a communication network
GB0324878D0 (en) * 2003-10-24 2003-11-26 Nokia Corp Communication system
US7945648B2 (en) * 2003-10-27 2011-05-17 Hewlett-Packard Development Company, L.P. Methods and systems for dynamically configuring a network component to reroute media streams
US7610387B1 (en) * 2003-11-12 2009-10-27 Cisco Technology, Inc. Method and apparatus for providing sticky bindings using version vectors
US7546355B2 (en) * 2004-01-16 2009-06-09 Bloomberg Finance L.P. Network architecture for data transmission
US20050198269A1 (en) * 2004-02-13 2005-09-08 Champagne Andrew F. Method and system for monitoring border gateway protocol (BGP) data in a distributed computer network
JP4291174B2 (ja) * 2004-02-16 2009-07-08 株式会社日立製作所 Ｗｅｂサービス委譲処理方法及び実施装置並びに処理プログラム
US8037203B2 (en) * 2004-02-19 2011-10-11 International Business Machines Corporation User defined preferred DNS reference
US7546286B2 (en) * 2004-02-19 2009-06-09 Microsoft Corporation Offline multi-table data editing and storage
US7716168B2 (en) 2005-06-29 2010-05-11 Microsoft Corporation Modifying table definitions within a database application
US7546291B2 (en) * 2004-02-19 2009-06-09 Microsoft Corporation Data source task pane
US8135755B2 (en) 2005-06-29 2012-03-13 Microsoft Corporation Templates in a schema editor
US7451185B2 (en) * 2004-02-27 2008-11-11 Fotomedia Technologies, Llc Method and system for providing links to resources related to a specified resource
US7639682B2 (en) * 2004-03-05 2009-12-29 Nec Corporation Communication quality management and apparatus
US8782654B2 (en) 2004-03-13 2014-07-15 Adaptive Computing Enterprises, Inc. Co-allocating a reservation spanning different compute resources types
JP2005267167A (ja) * 2004-03-18 2005-09-29 Hitachi Ltd 負荷分散方法およびシステム
US8089972B2 (en) 2004-05-03 2012-01-03 Level 3 Communications, Llc Registration redirect server
US20060064478A1 (en) * 2004-05-03 2006-03-23 Level 3 Communications, Inc. Geo-locating load balancing
US7496651B1 (en) 2004-05-06 2009-02-24 Foundry Networks, Inc. Configurable geographic prefixes for global server load balancing
US7584301B1 (en) 2004-05-06 2009-09-01 Foundry Networks, Inc. Host-level policies for global server load balancing
US8214447B2 (en) * 2004-06-08 2012-07-03 Bose Corporation Managing an audio network
US8527752B2 (en) 2004-06-16 2013-09-03 Dormarke Assets Limited Liability Graduated authentication in an identity management system
US9245266B2 (en) * 2004-06-16 2016-01-26 Callahan Cellular L.L.C. Auditable privacy policies in a distributed hierarchical identity management system
US8504704B2 (en) * 2004-06-16 2013-08-06 Dormarke Assets Limited Liability Company Distributed contact information management
US20070266388A1 (en) 2004-06-18 2007-11-15 Cluster Resources, Inc. System and method for providing advanced reservations in a compute environment
US9647952B2 (en) * 2004-08-06 2017-05-09 LiveQoS Inc. Network quality as a service
US8176490B1 (en) 2004-08-20 2012-05-08 Adaptive Computing Enterprises, Inc. System and method of interfacing a workload manager and scheduler with an identity manager
US7423977B1 (en) 2004-08-23 2008-09-09 Foundry Networks Inc. Smoothing algorithm for round trip time (RTT) measurements
US7526566B2 (en) * 2004-09-10 2009-04-28 Sony Ericsson Mobile Communications Ab Methods of operating radio communications devices including predefined streaming times and addresses and related devices
WO2006029508A1 (en) * 2004-09-13 2006-03-23 Solace Systems Inc. Highly scalable subscription matching for a content routing network
US7719971B1 (en) * 2004-09-15 2010-05-18 Qurio Holdings, Inc. Peer proxy binding
US7564869B2 (en) 2004-10-22 2009-07-21 Cisco Technology, Inc. Fibre channel over ethernet
JP4357534B2 (ja) * 2004-10-28 2009-11-04 富士通株式会社 移動無線通信端末及び通信制御方法
CA2586763C (en) 2004-11-08 2013-12-17 Cluster Resources, Inc. System and method of providing system jobs within a compute environment
US7778984B2 (en) * 2004-11-19 2010-08-17 Microsoft Corporation System and method for a distributed object store
US9843557B2 (en) 2004-12-09 2017-12-12 Level 3 Communications, Llc Systems and methods for dynamically registering endpoints in a network
US8768350B2 (en) 2004-12-09 2014-07-01 Level 3 Communications, Llc Systems and methods for locating endpoints in a communication network
US7734019B1 (en) 2004-12-09 2010-06-08 Level 3 Communications, Llc Systems and methods for third party emergency call termination
KR100758281B1 (ko) * 2004-12-20 2007-09-12 한국전자통신연구원 다중 서비스 타입 관리 기능을 가지는 컨텐츠 분배 관리시스템 및 그 방법
US7818401B2 (en) * 2004-12-23 2010-10-19 General Instrument Corporation Method and apparatus for providing decentralized load distribution
JP4103892B2 (ja) * 2005-01-26 2008-06-18 オンキヨー株式会社 ピアツーピアコンテンツ配信システム
US7769886B2 (en) * 2005-02-25 2010-08-03 Cisco Technology, Inc. Application based active-active data center network using route health injection and IGP
US7710865B2 (en) * 2005-02-25 2010-05-04 Cisco Technology, Inc. Disaster recovery for active-standby data center using route health and BGP
US7609619B2 (en) * 2005-02-25 2009-10-27 Cisco Technology, Inc. Active-active data center using RHI, BGP, and IGP anycast for disaster recovery and load distribution
US20060209824A1 (en) * 2005-03-01 2006-09-21 The Mitre Corporation Method, apparatus, and computer program product for transmitting and receiving broadcast packets
US7191215B2 (en) * 2005-03-09 2007-03-13 Marquee, Inc. Method and system for providing instantaneous media-on-demand services by transmitting contents in pieces from client machines
US9176955B2 (en) * 2005-03-09 2015-11-03 Vvond, Inc. Method and apparatus for sharing media files among network nodes
US20090025046A1 (en) * 2005-03-09 2009-01-22 Wond, Llc Hybrid architecture for media services
US7937379B2 (en) * 2005-03-09 2011-05-03 Vudu, Inc. Fragmentation of a file for instant access
US20080022343A1 (en) * 2006-07-24 2008-01-24 Vvond, Inc. Multiple audio streams
US20090019468A1 (en) * 2005-03-09 2009-01-15 Vvond, Llc Access control of media services over an open network
US7698451B2 (en) 2005-03-09 2010-04-13 Vudu, Inc. Method and apparatus for instant playback of a movie title
US8904463B2 (en) * 2005-03-09 2014-12-02 Vudu, Inc. Live video broadcasting on distributed networks
US8219635B2 (en) 2005-03-09 2012-07-10 Vudu, Inc. Continuous data feeding in a distributed environment
US8863143B2 (en) 2006-03-16 2014-10-14 Adaptive Computing Enterprises, Inc. System and method for managing a hybrid compute environment
EP2348409B1 (de) 2005-03-16 2017-10-04 III Holdings 12, LLC Automatische Arbeitslastübertragung auf ein On-Demand-Center
US9015324B2 (en) 2005-03-16 2015-04-21 Adaptive Computing Enterprises, Inc. System and method of brokering cloud computing resources
US9231886B2 (en) 2005-03-16 2016-01-05 Adaptive Computing Enterprises, Inc. Simple integration of an on-demand compute environment
EP3203374B1 (de) 2005-04-07 2021-11-24 III Holdings 12, LLC Zugang auf anfrage zu computerressourcen
US8782120B2 (en) 2005-04-07 2014-07-15 Adaptive Computing Enterprises, Inc. Elastic management of compute resources between a web server and an on-demand compute environment
AU2010201379B2 (en) * 2010-04-07 2012-02-23 Limelight Networks, Inc. System and method for delivery of content objects
US7710983B2 (en) * 2005-04-21 2010-05-04 Cisco Technology, Inc. Method and apparatus for determining information associated with a particular multicast channel in a multicast network
US20060245358A1 (en) * 2005-04-29 2006-11-02 Beverly Harlan T Acceleration of data packet transmission
US7630392B2 (en) * 2005-05-31 2009-12-08 Cisco Technology, Inc. Multi-homing using controlled route leakage at a backup service provider
US8099511B1 (en) 2005-06-11 2012-01-17 Vudu, Inc. Instantaneous media-on-demand
US8082348B1 (en) * 2005-06-17 2011-12-20 AOL, Inc. Selecting an instance of a resource using network routability information
US7940921B2 (en) * 2005-06-23 2011-05-10 Agere Systems Inc. Continuous power transfer scheme for two-wire serial link
US8831194B2 (en) * 2005-06-30 2014-09-09 Emc Corporation Telephonic communication redirection and compliance processing
US8605878B2 (en) * 2005-06-30 2013-12-10 Emc Corporation Redirecting and mirroring of telephonic communications
US8059805B2 (en) * 2005-06-30 2011-11-15 Emc Corporation Enhanced services provided using communication redirection and processing
KR100648926B1 (ko) * 2005-07-11 2006-11-27 삼성전자주식회사 사용자 식별 정보 부가기능을 갖는 복합기 및 그 방법
US7623515B2 (en) * 2005-07-14 2009-11-24 Yahoo! Inc. Content router notification
US20070014307A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router forwarding
US7631045B2 (en) * 2005-07-14 2009-12-08 Yahoo! Inc. Content router asynchronous exchange
US20070038703A1 (en) * 2005-07-14 2007-02-15 Yahoo! Inc. Content router gateway
US20070014277A1 (en) * 2005-07-14 2007-01-18 Yahoo! Inc. Content router repository
US7849199B2 (en) * 2005-07-14 2010-12-07 Yahoo ! Inc. Content router
US7961625B2 (en) * 2005-08-01 2011-06-14 Limelight Networks, Inc. Routing under heavy loading
US7706280B2 (en) * 2005-08-01 2010-04-27 Limelight Networks, Inc. Heavy load packet-switched routing
US20070037574A1 (en) * 2005-08-09 2007-02-15 Jonathan Libov Method and apparatus of a location-based network service for mutual social notification
US8171238B1 (en) 2007-07-05 2012-05-01 Silver Peak Systems, Inc. Identification of data stored in memory
US8095774B1 (en) 2007-07-05 2012-01-10 Silver Peak Systems, Inc. Pre-fetching data into a memory
US8392684B2 (en) 2005-08-12 2013-03-05 Silver Peak Systems, Inc. Data encryption in a network memory architecture for providing data based on local accessibility
US8370583B2 (en) * 2005-08-12 2013-02-05 Silver Peak Systems, Inc. Network memory architecture for providing data based on local accessibility
US20070055629A1 (en) * 2005-09-08 2007-03-08 Qualcomm Incorporated Methods and apparatus for distributing content to support multiple customer service entities and content packagers
US7565506B2 (en) * 2005-09-08 2009-07-21 Qualcomm Incorporated Method and apparatus for delivering content based on receivers characteristics
US8893179B2 (en) 2005-09-12 2014-11-18 Qualcomm Incorporated Apparatus and methods for providing and presenting customized channel information
US20070078944A1 (en) * 2005-09-12 2007-04-05 Mark Charlebois Apparatus and methods for delivering and presenting auxiliary services for customizing a channel
US8528029B2 (en) * 2005-09-12 2013-09-03 Qualcomm Incorporated Apparatus and methods of open and closed package subscription
US20070061445A1 (en) * 2005-09-13 2007-03-15 Deganaro Louis R Cooperative routing between traffic control device and multi-server application
US8082334B1 (en) 2005-09-15 2011-12-20 Emc Corporation Providing direct access to managed content
US8447827B2 (en) * 2005-09-15 2013-05-21 Emc Corporation Providing local access to managed content
US8396938B2 (en) * 2005-09-15 2013-03-12 Emc Corporation Providing direct access to distributed managed content
US8489562B1 (en) 2007-11-30 2013-07-16 Silver Peak Systems, Inc. Deferred data storage
US8811431B2 (en) 2008-11-20 2014-08-19 Silver Peak Systems, Inc. Systems and methods for compressing packet data
US8929402B1 (en) 2005-09-29 2015-01-06 Silver Peak Systems, Inc. Systems and methods for compressing packet data by predicting subsequent data
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7961621B2 (en) 2005-10-11 2011-06-14 Cisco Technology, Inc. Methods and devices for backward congestion notification
US8166197B2 (en) * 2005-10-25 2012-04-24 Oracle International Corporation Multipath routing process
US20070115929A1 (en) * 2005-11-08 2007-05-24 Bruce Collins Flexible system for distributing content to a device
US8600836B2 (en) * 2005-11-08 2013-12-03 Qualcomm Incorporated System for distributing packages and channels to a device
US8533358B2 (en) * 2005-11-08 2013-09-10 Qualcomm Incorporated Methods and apparatus for fragmenting system information messages in wireless networks
US8571570B2 (en) * 2005-11-08 2013-10-29 Qualcomm Incorporated Methods and apparatus for delivering regional parameters
WO2007053957A1 (en) * 2005-11-14 2007-05-18 Cyberdiffusion Inc. Transcoder for live streams and on demand media
US8412840B2 (en) * 2005-11-14 2013-04-02 Ando Media, Llc Live media serving system and method
US8065680B2 (en) * 2005-11-15 2011-11-22 Yahoo! Inc. Data gateway for jobs management based on a persistent job table and a server table
US8291117B1 (en) 2012-02-15 2012-10-16 Limelight Networks, Inc. Scaled domain name service
US8194701B2 (en) 2005-12-06 2012-06-05 Lippershy Celestial Llc System and/or method for downstream bidding
US9686183B2 (en) 2005-12-06 2017-06-20 Zarbaña Digital Fund Llc Digital object routing based on a service request
US7894447B2 (en) 2005-12-06 2011-02-22 Lippershy Celestial Llc Digital object routing
US8014389B2 (en) 2005-12-06 2011-09-06 Lippershy Celestial Llc Bidding network
US8055897B2 (en) * 2005-12-06 2011-11-08 Lippershy Celestial Llc Digital object title and transmission information
EP1958080A4 (de) * 2005-12-08 2014-05-07 Nortel Networks Ltd Multicast-verwaltungsverfahren mit sitzungseinleitungsprotokoll (sip)
US20070192798A1 (en) * 2005-12-30 2007-08-16 Barrett Morgan Digital content delivery via virtual private network (VPN) incorporating secured set-top devices
WO2007133294A2 (en) * 2005-12-30 2007-11-22 Bmo Llc Ubiquitous navbar user interface across multiple heterogeneous digital media devices
US8447837B2 (en) * 2005-12-30 2013-05-21 Akamai Technologies, Inc. Site acceleration with content prefetching enabled through customer-specific configurations
US7743026B2 (en) * 2006-01-31 2010-06-22 Microsoft Corporation Redirection to local copies of server-based files
KR100782836B1 (ko) * 2006-02-08 2007-12-06 삼성전자주식회사 컨텐츠 관리 방법, 장치 및 저장매체와 이를 이용한 적응적컨텐츠 재생 방법
US7818402B1 (en) * 2006-02-08 2010-10-19 Roxbeam Media Network Corporation Method and system for expediting peer-to-peer content delivery with improved network utilization
US7764701B1 (en) 2006-02-22 2010-07-27 Qurio Holdings, Inc. Methods, systems, and products for classifying peer systems
US7779004B1 (en) 2006-02-22 2010-08-17 Qurio Holdings, Inc. Methods, systems, and products for characterizing target systems
US9026677B2 (en) * 2006-03-17 2015-05-05 Cisco Technology, Inc. Method and apparatus for providing video on demand
CN101473605B (zh) * 2006-04-28 2012-01-11 意大利电信股份公司 用于确定因特网服务供应商的预期对等合作者的方法
US9386327B2 (en) * 2006-05-24 2016-07-05 Time Warner Cable Enterprises Llc Secondary content insertion apparatus and methods
US8280982B2 (en) 2006-05-24 2012-10-02 Time Warner Cable Inc. Personal content server apparatus and methods
US9047234B1 (en) * 2006-06-05 2015-06-02 Thomson Reuters (Markets) Llc Data context passing between non-interfaced application programs in a common framework
US8024762B2 (en) 2006-06-13 2011-09-20 Time Warner Cable Inc. Methods and apparatus for providing virtual content over a network
US8606926B2 (en) 2006-06-14 2013-12-10 Opendns, Inc. Recursive DNS nameserver
US8713188B2 (en) 2007-12-13 2014-04-29 Opendns, Inc. Per-request control of DNS behavior
US20070294721A1 (en) * 2006-06-20 2007-12-20 Sbc Knowledge Ventures, Lp System and method of providing supplemental video content related to targeted advertisements in a video stream
US8885632B2 (en) 2006-08-02 2014-11-11 Silver Peak Systems, Inc. Communications scheduler
US8755381B2 (en) 2006-08-02 2014-06-17 Silver Peak Systems, Inc. Data matching using flow based packet data storage
US8848711B1 (en) * 2006-08-04 2014-09-30 Brixham Solutions Ltd. Global IP-based service-oriented network architecture
JP4950295B2 (ja) * 2006-08-21 2012-06-13 テレフオンアクチーボラゲット エル エム エリクソン（パブル） エンドユーザにトリプルプレイサービスを提供するための分散型サーバネットワーク
US7647590B2 (en) * 2006-08-31 2010-01-12 International Business Machines Corporation Parallel computing system using coordinator and master nodes for load balancing and distributing work
US8806045B2 (en) * 2006-09-01 2014-08-12 Microsoft Corporation Predictive popular content replication
US8296812B1 (en) 2006-09-01 2012-10-23 Vudu, Inc. Streaming video using erasure encoding
WO2008030494A2 (en) * 2006-09-05 2008-03-13 Donnelli Robert M Managing client-to-server or peer-to-peer relationships in a private or virtual network
US9326138B2 (en) * 2006-09-06 2016-04-26 Devicescape Software, Inc. Systems and methods for determining location over a network
US8667596B2 (en) 2006-09-06 2014-03-04 Devicescape Software, Inc. Systems and methods for network curation
US7873988B1 (en) 2006-09-06 2011-01-18 Qurio Holdings, Inc. System and method for rights propagation and license management in conjunction with distribution of digital content in a social network
US7801971B1 (en) 2006-09-26 2010-09-21 Qurio Holdings, Inc. Systems and methods for discovering, creating, using, and managing social network circuits
US7925592B1 (en) 2006-09-27 2011-04-12 Qurio Holdings, Inc. System and method of using a proxy server to manage lazy content distribution in a social network
US7782866B1 (en) 2006-09-29 2010-08-24 Qurio Holdings, Inc. Virtual peer in a peer-to-peer network
US8965783B2 (en) * 2006-09-29 2015-02-24 Yahoo! Inc. Content-embedding code generation in digital media benefit attachment mechanism
US8943401B2 (en) * 2006-09-29 2015-01-27 Yahoo! Inc. Script-based content-embedding code generation in digital media benefit attachment mechanism
US8554827B2 (en) 2006-09-29 2013-10-08 Qurio Holdings, Inc. Virtual peer for a content sharing system
US8737261B2 (en) * 2006-11-27 2014-05-27 Telefonaktiebolaget L M Ericsson (Publ) Node registering method
US7886334B1 (en) 2006-12-11 2011-02-08 Qurio Holdings, Inc. System and method for social network trust assessment
US7730216B1 (en) 2006-12-14 2010-06-01 Qurio Holdings, Inc. System and method of sharing content among multiple social network nodes using an aggregation node
US8239573B2 (en) * 2006-12-15 2012-08-07 Starz Entertainment, Llc Off-peak background delivery
US8301775B2 (en) * 2006-12-15 2012-10-30 Starz Entertainment, Llc Affiliate bandwidth management
US9582804B2 (en) * 2006-12-22 2017-02-28 Excalibur Ip, Llc Link retrofitting of digital media objects
WO2008085979A1 (en) * 2007-01-08 2008-07-17 Bmo Llc Household network incorporating secure set- top devices
JP2008172517A (ja) 2007-01-11 2008-07-24 Nec Corp 輻輳制御システム、輻輳制御方法、輻輳制御プログラム、及び、プログラム記録媒体
US7924456B1 (en) 2007-01-12 2011-04-12 Broadbus Technologies, Inc. Data distribution and buffering
US20080177894A1 (en) * 2007-01-22 2008-07-24 Jennings Raymond B Methods and Apparatus For Improving Interactions Between Multi-Server Web Environments and Web Browsers
US8259720B2 (en) * 2007-02-02 2012-09-04 Cisco Technology, Inc. Triple-tier anycast addressing
US7694016B2 (en) * 2007-02-07 2010-04-06 Nominum, Inc. Composite DNS zones
US20080212584A1 (en) * 2007-03-02 2008-09-04 At&T Knowledge Ventures, L.P. Method and system for presentation of multicast trees
US8385190B2 (en) * 2007-03-14 2013-02-26 At&T Intellectual Property I, Lp Controlling multicast source selection in an anycast source audio/video network
US9996627B2 (en) * 2007-03-30 2018-06-12 Excalibur Ip, Llc Point of presence distribution mechanism for digital content objects
US9019830B2 (en) * 2007-05-15 2015-04-28 Imagine Communications Corp. Content-based routing of information content
US7756130B1 (en) 2007-05-22 2010-07-13 At&T Mobility Ii Llc Content engine for mobile communications systems
US8996723B2 (en) * 2007-06-04 2015-03-31 Microsoft Technology Licensing, Llc ISP-aware peer-to-peer content exchange
US20080313350A1 (en) * 2007-06-18 2008-12-18 Verizon Services Organization Inc. Method and system of cache discovery in a peer-to-peer environment
US8543700B1 (en) 2007-06-28 2013-09-24 Emc Corporation Asynchronous content transfer
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US8028090B2 (en) * 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US10223858B2 (en) 2007-07-05 2019-03-05 Mediaport Entertainment, Inc. Systems and methods monitoring devices, systems, users and user activity at remote locations
US8121038B2 (en) 2007-08-21 2012-02-21 Cisco Technology, Inc. Backward congestion notification
US10063392B2 (en) * 2007-08-21 2018-08-28 At&T Intellectual Property I, L.P. Methods and apparatus to select a voice over internet protocol (VOIP) border element
US9124603B2 (en) * 2007-08-27 2015-09-01 At&T Intellectual Property I., L.P. Methods and apparatus to select a peered voice over internet protocol (VoIP) border element
US9258268B2 (en) 2007-08-27 2016-02-09 At&T Intellectual Property, I., L.P. Methods and apparatus to dynamically select a peered voice over internet protocol (VoIP) border element
WO2009029105A1 (en) * 2007-08-31 2009-03-05 Vulano Group, Inc. Virtual aggregation processor for incorporating reverse path feedback into content delivered on a forward path
US8509748B2 (en) * 2007-08-31 2013-08-13 Lava Two, Llc Transaction management system in a multicast or broadcast wireless communication network
WO2009029112A1 (en) * 2007-08-31 2009-03-05 Vulano Group, Inc. Forward path multi-media management system with end user feedback to central content sources
WO2009029107A1 (en) 2007-08-31 2009-03-05 Vulano Group, Inc. Gaming device for multi-player games
WO2009029108A1 (en) * 2007-08-31 2009-03-05 Vulano Group, Inc. Gaming system with end user feedback for a communication network having a multi-media management
WO2009029109A1 (en) * 2007-08-31 2009-03-05 Vulano Group, Inc. Communication network for a multi-media management system with end user feedback
US8572176B2 (en) * 2007-08-31 2013-10-29 Lava Two, Llc Forward path multi-media management system with end user feedback to distributed content sources
US8041773B2 (en) 2007-09-24 2011-10-18 The Research Foundation Of State University Of New York Automatic clustering for self-organizing grids
US7958485B2 (en) * 2007-11-21 2011-06-07 General Electric Company Methods and systems for managing content dependency deployment
US8307115B1 (en) * 2007-11-30 2012-11-06 Silver Peak Systems, Inc. Network memory mirroring
US8756340B2 (en) 2007-12-20 2014-06-17 Yahoo! Inc. DNS wildcard beaconing to determine client location and resolver load for global traffic load balancing
US8214524B2 (en) * 2007-12-21 2012-07-03 Hostway Corporation System and method for selecting an optimal authoritative name server
US7962631B2 (en) * 2007-12-21 2011-06-14 Yahoo! Inc. Method for determining network proximity for global traffic load balancing using passive TCP performance instrumentation
US8386629B2 (en) * 2007-12-27 2013-02-26 At&T Intellectual Property I, L.P. Network optimized content delivery for high demand non-live contents
US20090172192A1 (en) * 2007-12-28 2009-07-02 Christian Michael F Mapless Global Traffic Load Balancing Via Anycast
US8549402B2 (en) * 2007-12-29 2013-10-01 Joseph Harold Moore System and method for providing internet radio service
US9538141B2 (en) 2007-12-31 2017-01-03 Alcatel Lucent Method and apparatus for controlling presentation of content at a user terminal
US20090168752A1 (en) * 2007-12-31 2009-07-02 Jonathan Segel Method and apparatus for distributing content
WO2009088513A1 (en) * 2008-01-10 2009-07-16 Hewlett-Packard Development Company, L.P. Multiway peer-to-peer media streaming
US8543667B2 (en) 2008-01-14 2013-09-24 Akamai Technologies, Inc. Policy-based content insertion
US20090187978A1 (en) * 2008-01-18 2009-07-23 Yahoo! Inc. Security and authentications in peer-to-peer networks
US8442052B1 (en) 2008-02-20 2013-05-14 Silver Peak Systems, Inc. Forward packet recovery
US7594035B2 (en) 2008-02-22 2009-09-22 Tactara, Llc Methods of providing published content
US8015144B2 (en) 2008-02-26 2011-09-06 Microsoft Corporation Learning transportation modes from raw GPS data
US8520663B2 (en) 2008-02-26 2013-08-27 At&T Intellectual Property I, L. P. Systems and methods to select peered border elements for an IP multimedia session based on quality-of-service
US8972177B2 (en) 2008-02-26 2015-03-03 Microsoft Technology Licensing, Llc System for logging life experiences using geographic cues
US11323510B2 (en) 2008-02-28 2022-05-03 Level 3 Communications, Llc Load-balancing cluster
US8489750B2 (en) 2008-02-28 2013-07-16 Level 3 Communications, Llc Load-balancing cluster
US8966121B2 (en) * 2008-03-03 2015-02-24 Microsoft Corporation Client-side management of domain name information
US7930427B2 (en) * 2008-03-03 2011-04-19 Microsoft Corporation Client-side load balancing
US7991879B2 (en) 2008-03-03 2011-08-02 Microsoft Corporation Internet location coordinate enhanced domain name system
US8458298B2 (en) * 2008-03-03 2013-06-04 Microsoft Corporation Failover in an internet location coordinate enhanced domain name system
US8601090B1 (en) 2008-03-31 2013-12-03 Amazon Technologies, Inc. Network resource identification
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US8533293B1 (en) 2008-03-31 2013-09-10 Amazon Technologies, Inc. Client side cache management
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US8156243B2 (en) 2008-03-31 2012-04-10 Amazon Technologies, Inc. Request routing
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US20090245114A1 (en) * 2008-04-01 2009-10-01 Jayanth Vijayaraghavan Methods for collecting and analyzing network performance data
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
EP2274684A4 (de) 2008-04-04 2012-12-05 Level 3 Communications Llc Umgang mit long-tail-inhalt in einem inhaltsablieferungsnetzwerk (cdn)
US9762692B2 (en) * 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US7797426B1 (en) * 2008-06-27 2010-09-14 BitGravity, Inc. Managing TCP anycast requests
US7860973B2 (en) * 2008-06-27 2010-12-28 Microsoft Corporation Data center scheduler
US9912740B2 (en) 2008-06-30 2018-03-06 Amazon Technologies, Inc. Latency measurement in resource requests
US7925782B2 (en) * 2008-06-30 2011-04-12 Amazon Technologies, Inc. Request routing using network computing components
US9407681B1 (en) 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
US10805840B2 (en) 2008-07-03 2020-10-13 Silver Peak Systems, Inc. Data transmission via a virtual wide area network overlay
US10164861B2 (en) 2015-12-28 2018-12-25 Silver Peak Systems, Inc. Dynamic monitoring and visualization for network health characteristics
US8743683B1 (en) 2008-07-03 2014-06-03 Silver Peak Systems, Inc. Quality of service using multiple flows
US9717021B2 (en) 2008-07-03 2017-07-25 Silver Peak Systems, Inc. Virtual network overlay
US8619775B2 (en) * 2008-07-21 2013-12-31 Ltn Global Communications, Inc. Scalable flow transport and delivery network and associated methods and systems
US10007668B2 (en) * 2008-08-01 2018-06-26 Vantrix Corporation Method and system for triggering ingestion of remote content by a streaming server using uniform resource locator folder mapping
US8171111B1 (en) 2008-08-07 2012-05-01 United Services Automobile Association (Usaa) Systems and methods for non-specific address routing
US8706878B1 (en) 2008-08-21 2014-04-22 United Services Automobile Association Preferential loading in data centers
US9203921B2 (en) * 2008-08-26 2015-12-01 British Telecommunications Public Limited Company Operation of a content distribution network
EP2159983A1 (de) * 2008-08-26 2010-03-03 BRITISH TELECOMMUNICATIONS public limited company Inhaltsverteilungsnetzwerk
US8516082B2 (en) 2009-03-25 2013-08-20 Limelight Networks, Inc. Publishing-point management for content delivery network
AU2010202034B1 (en) 2010-04-07 2010-12-23 Limelight Networks, Inc. Partial object distribution in content delivery network
AU2010276462B1 (en) 2010-12-27 2012-01-12 Limelight Networks, Inc. Partial object caching
WO2010033938A2 (en) * 2008-09-19 2010-03-25 Limelight Networks, Inc. Content delivery network stream server vignette distribution
US8775456B2 (en) * 2008-11-03 2014-07-08 Bmc Software, Inc. System and method for scheduled and collaborative distribution of software and data to many thousands of clients over a network using dynamic virtual proxies
US9426213B2 (en) 2008-11-11 2016-08-23 At&T Intellectual Property Ii, L.P. Hybrid unicast/anycast content distribution network system
US8732309B1 (en) 2008-11-17 2014-05-20 Amazon Technologies, Inc. Request routing utilizing cost information
US8521880B1 (en) 2008-11-17 2013-08-27 Amazon Technologies, Inc. Managing content delivery network service providers
US8065417B1 (en) 2008-11-17 2011-11-22 Amazon Technologies, Inc. Service provider registration by a content broker
US8060616B1 (en) 2008-11-17 2011-11-15 Amazon Technologies, Inc. Managing CDN registration by a storage provider
US8073940B1 (en) 2008-11-17 2011-12-06 Amazon Technologies, Inc. Managing content delivery network service providers
US8122098B1 (en) 2008-11-17 2012-02-21 Amazon Technologies, Inc. Managing content delivery network service providers by a content broker
US8316106B2 (en) 2008-12-05 2012-11-20 At&T Intellectual Property Ii, Lp System and method for assigning requests in a content distribution network
US20100153802A1 (en) * 2008-12-15 2010-06-17 At&T Corp. System and Method for Anycast Transport Optimization
GB2478687B (en) 2008-12-22 2014-05-21 Ltn Global Communications Inc A system and method for recovery of packets in overlay networks
US9063226B2 (en) * 2009-01-14 2015-06-23 Microsoft Technology Licensing, Llc Detecting spatial outliers in a location entity dataset
US9485299B2 (en) * 2009-03-09 2016-11-01 Arris Canada, Inc. Progressive download gateway
US20100235469A1 (en) * 2009-03-11 2010-09-16 Morris Robert P Method And System For Providing Access To Resources Related To A Locatable Resource
US9391825B1 (en) 2009-03-24 2016-07-12 Amazon Technologies, Inc. System and method for tracking service results
US8521851B1 (en) 2009-03-27 2013-08-27 Amazon Technologies, Inc. DNS query processing using resource identifiers specifying an application broker
US8412823B1 (en) 2009-03-27 2013-04-02 Amazon Technologies, Inc. Managing tracking information entries in resource cache components
US8756341B1 (en) 2009-03-27 2014-06-17 Amazon Technologies, Inc. Request routing utilizing popularity information
US8688837B1 (en) 2009-03-27 2014-04-01 Amazon Technologies, Inc. Dynamically translating resource identifiers for request routing using popularity information
US8599851B2 (en) 2009-04-03 2013-12-03 Ltn Global Communications, Inc. System and method that routes flows via multicast flow transport for groups
US9106569B2 (en) 2009-03-29 2015-08-11 Ltn Global Communications, Inc. System and method that routes flows via multicast flow transport for groups
GB2469528B (en) * 2009-04-18 2011-10-05 Saffron Digital Ltd Transcoding video data
US8676989B2 (en) 2009-04-23 2014-03-18 Opendns, Inc. Robust domain name resolution
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
US20130103556A1 (en) 2009-06-25 2013-04-25 3Crowd Technologies, Inc. Crowd based content delivery
US20130103785A1 (en) * 2009-06-25 2013-04-25 3Crowd Technologies, Inc. Redirecting content requests
CN101938505B (zh) * 2009-07-01 2013-01-30 华为技术有限公司 一种P2P流媒体数据分发的方法、系统和proxy节点
US8560597B2 (en) * 2009-07-30 2013-10-15 At&T Intellectual Property I, L.P. Anycast transport protocol for content distribution networks
US8566393B2 (en) * 2009-08-10 2013-10-22 Seawell Networks Inc. Methods and systems for scalable video chunking
KR101135087B1 (ko) * 2009-08-12 2012-04-16 삼성에스디에스 주식회사 콘텐츠 제공 시스템 및 방법
US20110040788A1 (en) * 2009-08-14 2011-02-17 Ic Manage, Inc. Coherent File State System Distributed Among Workspace Clients
US20140222758A1 (en) * 2009-08-14 2014-08-07 Ic Manage, Inc. Coherent File State Maintained Among Confederated Repositories By Distributed Workspace Apparatuses Backed Up By a File State Ledgerdemain Store
US8966033B2 (en) * 2009-08-17 2015-02-24 At&T Intellectual Property I, L.P. Integrated proximity routing for content distribution
US8296458B2 (en) * 2009-08-24 2012-10-23 At&T Intellectual Property I, Lp Adaptive routing of content requests using multiple anycast addresses
US20110055731A1 (en) * 2009-09-02 2011-03-03 Andrew Echenberg Content distribution over a network
US9450804B2 (en) * 2009-09-03 2016-09-20 At&T Intellectual Property I, L.P. Anycast aware transport for content distribution networks
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US9009177B2 (en) 2009-09-25 2015-04-14 Microsoft Corporation Recommending points of interests in a region
US9124513B2 (en) * 2009-09-30 2015-09-01 At&T Intellectual Property I, L.P. Load balancing multicast network traffic using virtual channels
US8433771B1 (en) 2009-10-02 2013-04-30 Amazon Technologies, Inc. Distribution network with forward resource propagation
US8219645B2 (en) * 2009-10-02 2012-07-10 Limelight Networks, Inc. Content delivery network cache grouping
US8612622B2 (en) 2009-10-02 2013-12-17 Limelight Networks, Inc. Real-time message queuing for a processing ring
US11720290B2 (en) 2009-10-30 2023-08-08 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US10877695B2 (en) 2009-10-30 2020-12-29 Iii Holdings 2, Llc Memcached server functionality in a cluster of data processing nodes
US8560598B2 (en) 2009-12-22 2013-10-15 At&T Intellectual Property I, L.P. Integrated adaptive anycast for content distribution
US8607014B2 (en) * 2009-12-22 2013-12-10 At&T Intellectual Property I, L.P. Multi-autonomous system anycast content delivery network
US20110173337A1 (en) * 2010-01-13 2011-07-14 Oto Technologies, Llc Proactive pre-provisioning for a content sharing session
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US8612134B2 (en) * 2010-02-23 2013-12-17 Microsoft Corporation Mining correlation between locations using location history
US9261376B2 (en) * 2010-02-24 2016-02-16 Microsoft Technology Licensing, Llc Route computation based on route-oriented vehicle trajectories
US10288433B2 (en) 2010-02-25 2019-05-14 Microsoft Technology Licensing, Llc Map-matching for low-sampling-rate GPS trajectories
US8819208B2 (en) 2010-03-05 2014-08-26 Solidfire, Inc. Data deletion in a distributed data storage system
US8341099B2 (en) * 2010-03-12 2012-12-25 Microsoft Corporation Semantics update and adaptive interfaces in connection with information as a service
US8856281B2 (en) * 2010-03-22 2014-10-07 At&T Intellectual Property I, L.P. Internet protocol version 6 content routing
US20110264530A1 (en) 2010-04-23 2011-10-27 Bryan Santangelo Apparatus and methods for dynamic secondary content and data insertion and delivery
US9373106B1 (en) * 2010-04-26 2016-06-21 Sprint Communications Company L.P. Tracking the download and purchase of digital content
US8719198B2 (en) 2010-05-04 2014-05-06 Microsoft Corporation Collaborative location and activity recommendations
EP2387177A1 (de) * 2010-05-11 2011-11-16 Thomson Licensing Verteilung von Inhalten an Peers mittels Multicast-Verbindungen innerhalb einer P2P-Infrastruktur
US9593957B2 (en) 2010-06-04 2017-03-14 Microsoft Technology Licensing, Llc Searching similar trajectories by locations
CN103069776B (zh) 2010-06-18 2016-10-05 阿卡麦科技公司 将内容分发网络(cdn)扩展到移动或有线网络
US8751638B2 (en) 2010-07-02 2014-06-10 Futurewei Technologies, Inc. System and method to implement joint server selection and path selection
US8190677B2 (en) 2010-07-23 2012-05-29 Seawell Networks Inc. Methods and systems for scalable video delivery
EP2421200A1 (de) * 2010-08-16 2012-02-22 Numerex Corporation IP-Netzwerkdienstumleitervorrichtung und -verfahren
US8410994B1 (en) * 2010-08-23 2013-04-02 Matrox Graphics Inc. System and method for remote graphics display
US8756272B1 (en) 2010-08-26 2014-06-17 Amazon Technologies, Inc. Processing encoded content
US8924528B1 (en) 2010-09-28 2014-12-30 Amazon Technologies, Inc. Latency measurement in resource requests
US10097398B1 (en) 2010-09-28 2018-10-09 Amazon Technologies, Inc. Point of presence management in request routing
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
US8930513B1 (en) 2010-09-28 2015-01-06 Amazon Technologies, Inc. Latency measurement in resource requests
US8819283B2 (en) 2010-09-28 2014-08-26 Amazon Technologies, Inc. Request routing in a networked environment
US8938526B1 (en) 2010-09-28 2015-01-20 Amazon Technologies, Inc. Request routing management based on network components
US8577992B1 (en) 2010-09-28 2013-11-05 Amazon Technologies, Inc. Request routing management based on network components
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US9148466B2 (en) * 2010-10-05 2015-09-29 Yahoo! Inc. Presenting modules in a browser
US8549148B2 (en) 2010-10-15 2013-10-01 Brocade Communications Systems, Inc. Domain name system security extensions (DNSSEC) for global server load balancing
US8452874B2 (en) 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US8626950B1 (en) 2010-12-03 2014-01-07 Amazon Technologies, Inc. Request routing processing
US9391949B1 (en) 2010-12-03 2016-07-12 Amazon Technologies, Inc. Request routing processing
US8825813B2 (en) 2010-12-28 2014-09-02 Microsoft Corporation Distributed network coordinate system based on network performance
TW201238291A (en) * 2011-03-14 2012-09-16 Wistron Corp Communication system and peer to peer transmission method
FR2973978A1 (fr) * 2011-04-08 2012-10-12 France Telecom Procede de communication entre des reseaux de distribution de contenus numeriques
ES2650595T3 (es) * 2011-04-15 2018-01-19 Deutsche Telekom Ag Ingeniería de tráfico de red
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
US20120311076A1 (en) * 2011-05-31 2012-12-06 Cisco Technology, Inc. System and method to support different uniform resource locator formats for content on different network elements
US20120327931A1 (en) * 2011-06-21 2012-12-27 Alcatel-Lucent Usa Inc. Gateways integrating name-based networks with host-based networks
US9037680B2 (en) 2011-06-29 2015-05-19 Instart Logic, Inc. Application acceleration
FR2977420A1 (fr) 2011-06-30 2013-01-04 France Telecom Technique d'obtention par un terminal d'une information relative a un acces a un service
JP6039915B2 (ja) * 2011-07-08 2016-12-07 株式会社ドワンゴ ステージ演出システム、演出制御サブシステム、ステージ演出システムの動作方法、演出制御サブシステムの動作方法、およびプログラム
US8943170B2 (en) * 2011-07-08 2015-01-27 Ming Li Content delivery network aggregation with selected content delivery
US8831110B2 (en) 2011-07-20 2014-09-09 James D. Ocon Electronic news gathering method and system for the prioritized transmission of data
US9680791B2 (en) 2011-07-29 2017-06-13 Fortinet, Inc. Facilitating content accessibility via different communication formats
US20130103853A1 (en) 2011-07-29 2013-04-25 3Crowd Technologies, Inc. Directing clients based on communication format
US8510807B1 (en) 2011-08-16 2013-08-13 Edgecast Networks, Inc. Real-time granular statistical reporting for distributed platforms
US8689280B2 (en) 2011-09-09 2014-04-01 Microsoft Corporation DNS-based content routing
US9521214B2 (en) * 2011-09-20 2016-12-13 Instart Logic, Inc. Application acceleration with partial file caching
US8849976B2 (en) * 2011-09-26 2014-09-30 Limelight Networks, Inc. Dynamic route requests for multiple clouds
WO2013056058A1 (en) * 2011-10-13 2013-04-18 Interdigital Patent Holdings Inc. Method and apparatus for providing interfacing between content delivery networks
US9130991B2 (en) 2011-10-14 2015-09-08 Silver Peak Systems, Inc. Processing data packets in performance enhancing proxy (PEP) environment
KR20130048032A (ko) * 2011-11-01 2013-05-09 한국전자통신연구원 컨텐츠 중심 네트워크에서 라우팅 방법
US9626224B2 (en) 2011-11-03 2017-04-18 Silver Peak Systems, Inc. Optimizing available computing resources within a virtual environment
US9754226B2 (en) 2011-12-13 2017-09-05 Microsoft Technology Licensing, Llc Urban computing of route-oriented vehicles
EP2791819B1 (de) 2011-12-14 2017-11-01 Level 3 Communications, LLC Inhaltsausgabenetzwerk
CN103179145B (zh) * 2011-12-20 2016-04-06 中国电信股份有限公司 基于云计算的数据传输方法、系统及隐式内容服务器
US20130166188A1 (en) 2011-12-21 2013-06-27 Microsoft Corporation Determine Spatiotemporal Causal Interactions In Data
US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
US9054992B2 (en) 2011-12-27 2015-06-09 Solidfire, Inc. Quality of service policy sets
US9032092B1 (en) * 2011-12-28 2015-05-12 Amazon Technologies, Inc. Client traffic redirection service
US9231903B2 (en) * 2011-12-30 2016-01-05 Time Warner Cable Enterprises Llc System and method for resolving a DNS request using metadata
US20130173806A1 (en) 2011-12-31 2013-07-04 Level 3 Communications, Llc Load-balancing cluster
US10218756B2 (en) 2012-01-06 2019-02-26 Comcast Cable Communications, Llc Streamlined delivery of video content
US9137111B2 (en) 2012-01-30 2015-09-15 Microsoft Technology Licensing, Llc Discovering, validating, and configuring hardware-inventory components
US9641394B2 (en) * 2012-01-30 2017-05-02 Microsoft Technology Licensing, Llc Automated build-out of a cloud-computing stamp
US9367360B2 (en) 2012-01-30 2016-06-14 Microsoft Technology Licensing, Llc Deploying a hardware inventory as a cloud-computing stamp
US9917736B2 (en) 2012-01-30 2018-03-13 Microsoft Technology Licensing, Llc Automated standalone bootstrapping of hardware inventory
US8904009B1 (en) 2012-02-10 2014-12-02 Amazon Technologies, Inc. Dynamic content delivery
US10021179B1 (en) 2012-02-21 2018-07-10 Amazon Technologies, Inc. Local resource delivery network
US8825811B2 (en) * 2012-03-15 2014-09-02 International Business Machines Corporation Connection management and optimization for services delivered over networks
US8904014B2 (en) 2012-03-15 2014-12-02 International Business Machines Corporation Content delivery mechanisms for multicast communication
US9083743B1 (en) 2012-03-21 2015-07-14 Amazon Technologies, Inc. Managing request routing information utilizing performance information
FR2988544A1 (fr) * 2012-03-23 2013-09-27 France Telecom Selection d'une entite de reseau pour la fourniture d'un contenu numerique
US9307044B2 (en) * 2012-03-28 2016-04-05 At&T Intellectual Property I, L.P. System and method for routing content based on real-time feedback
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US9712887B2 (en) 2012-04-12 2017-07-18 Arris Canada, Inc. Methods and systems for real-time transmuxing of streaming media content
US9532080B2 (en) 2012-05-31 2016-12-27 Sonic Ip, Inc. Systems and methods for the reuse of encoding information in encoding alternative streams of video data
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
US10120725B2 (en) 2012-06-22 2018-11-06 Microsoft Technology Licensing, Llc Establishing an initial configuration of a hardware inventory
US10057377B2 (en) * 2012-06-29 2018-08-21 Vmware, Inc. Dynamic resolution of servers in a distributed environment
US8909736B1 (en) * 2012-07-12 2014-12-09 Juniper Networks, Inc. Content delivery network referral
US9525659B1 (en) 2012-09-04 2016-12-20 Amazon Technologies, Inc. Request routing utilizing point of presence load information
US9323577B2 (en) 2012-09-20 2016-04-26 Amazon Technologies, Inc. Automated profiling of resource usage
US9135048B2 (en) 2012-09-20 2015-09-15 Amazon Technologies, Inc. Automated profiling of resource usage
US8606938B1 (en) * 2012-09-27 2013-12-10 Ringcentral, Inc. High availability for cloud-based services
CN103731404B (zh) * 2012-10-12 2016-12-28 北京百度网讯科技有限公司 基于cdn网络的数据访问方法、系统及装置
US9634918B2 (en) 2012-12-13 2017-04-25 Level 3 Communications, Llc Invalidation sequencing in a content delivery framework
US10652087B2 (en) 2012-12-13 2020-05-12 Level 3 Communications, Llc Content delivery framework having fill services
US10701148B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having storage services
US10701149B2 (en) 2012-12-13 2020-06-30 Level 3 Communications, Llc Content delivery framework having origin services
US10791050B2 (en) 2012-12-13 2020-09-29 Level 3 Communications, Llc Geographic location determination in a content delivery framework
US20140337472A1 (en) 2012-12-13 2014-11-13 Level 3 Communications, Llc Beacon Services in a Content Delivery Framework
US9847917B2 (en) 2012-12-13 2017-12-19 Level 3 Communications, Llc Devices and methods supporting content delivery with adaptation services with feedback
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
KR101978173B1 (ko) * 2013-01-18 2019-05-14 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠 제공자가 데이터 패킷을 전송하는 방법 및 그 컨텐츠 제공자
US9292279B2 (en) * 2013-01-22 2016-03-22 Maluuba Inc. Method and system for creating and managing a dynamic route topography for service oriented software environments
JP6088853B2 (ja) * 2013-02-27 2017-03-01 株式会社東芝 通信装置、通信方法および通信プログラム
US9357210B2 (en) 2013-02-28 2016-05-31 Sonic Ip, Inc. Systems and methods of encoding multiple video streams for adaptive bitrate streaming
US9560126B2 (en) 2013-05-06 2017-01-31 Alcatel Lucent Stateless load balancing of connections
CA2851709A1 (en) 2013-05-16 2014-11-16 Peter S. Warrick Dns-based captive portal with integrated transparent proxy to protect against user device caching incorrect ip address
US9800634B2 (en) 2013-05-28 2017-10-24 Cisco Technology, Inc. Pull-based media system
US9294391B1 (en) 2013-06-04 2016-03-22 Amazon Technologies, Inc. Managing network computing components utilizing request routing
US9369518B2 (en) 2013-06-26 2016-06-14 Amazon Technologies, Inc. Producer system partitioning among leasing agent systems
US9843631B2 (en) 2013-06-26 2017-12-12 Amazon Technologies, Inc. Producer system selection
US9350801B2 (en) 2013-06-26 2016-05-24 Amazon Technologies, Inc. Managing client access to a plurality of computing systems
US9780993B2 (en) * 2013-06-26 2017-10-03 Amazon Technologies, Inc. Producer computing system leasing on behalf of consumer computing system
US9392079B2 (en) 2013-07-19 2016-07-12 International Business Machines Corporation Directory service discovery and/or learning
US9819436B2 (en) 2013-08-26 2017-11-14 Coriant Operations, Inc. Intranodal ROADM fiber management apparatuses, systems, and methods
US9276991B2 (en) * 2013-09-18 2016-03-01 Xerox Corporation Method and apparatus for providing a dynamic tool menu based upon a document
US8745221B1 (en) * 2013-09-18 2014-06-03 Limelight Networks, Inc. Dynamic request rerouting
US9113182B2 (en) * 2013-12-04 2015-08-18 Wowza Media Systems, LLC Selecting a media content source based on monetary cost
US9253545B2 (en) * 2013-12-04 2016-02-02 Wowza Media Systems, LLC Routing media content based on monetary cost
US8775564B1 (en) 2013-12-31 2014-07-08 Limelight Networks, Inc. Time based CDN traffic allocation
US9929939B2 (en) 2013-12-26 2018-03-27 Coriant Operations, Inc. Systems, apparatuses, and methods for rerouting network traffic
US10044609B2 (en) * 2014-02-04 2018-08-07 Fastly, Inc. Communication path selection for content delivery
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
US10142342B2 (en) 2014-03-23 2018-11-27 Extreme Networks, Inc. Authentication of client devices in networks
US20150271016A1 (en) * 2014-03-23 2015-09-24 Avaya Inc. Configuration of networks with server cluster device
US9531591B2 (en) 2014-03-23 2016-12-27 Avaya Inc. Configuration of networks using switch device access of remote server
US9549385B2 (en) 2014-03-23 2017-01-17 Avaya Inc. Configuration of networks using client device access of remote server
FR3019427A1 (fr) 2014-03-28 2015-10-02 Orange Procede de mise en cache d'un contenu dans un reseau de distribution de contenus
KR20150133437A (ko) * 2014-05-20 2015-11-30 한국전자통신연구원 가입자 망으로 전진된 캐쉬를 적응적으로 배치하는 방법 및 이를 위한 시스템
US9655027B1 (en) 2014-07-11 2017-05-16 ProSports Technologies, LLC Event data transmission to eventgoer devices
US9760572B1 (en) 2014-07-11 2017-09-12 ProSports Technologies, LLC Event-based content collection for network-based distribution
WO2016007965A1 (en) 2014-07-11 2016-01-14 ProSports Technologies, LLC Ball tracker camera
WO2016007962A1 (en) 2014-07-11 2016-01-14 ProSports Technologies, LLC Camera feed distribution from event venue virtual seat cameras
US9571903B2 (en) 2014-07-11 2017-02-14 ProSports Technologies, LLC Ball tracker snippets
US9729644B1 (en) 2014-07-28 2017-08-08 ProSports Technologies, LLC Event and fantasy league data transmission to eventgoer devices
US9948496B1 (en) 2014-07-30 2018-04-17 Silver Peak Systems, Inc. Determining a transit appliance for data traffic to a software service
US9875344B1 (en) 2014-09-05 2018-01-23 Silver Peak Systems, Inc. Dynamic monitoring and authorization of an optimization device
US9699523B1 (en) 2014-09-08 2017-07-04 ProSports Technologies, LLC Automated clip creation
US9871716B2 (en) * 2014-10-16 2018-01-16 Kollective Technology, Inc. Broadcast readiness testing in distributed content delivery networks
US10530880B2 (en) 2014-10-31 2020-01-07 Netapp, Inc. Scalable multiple VLAN multi-tenant networking
US10091096B1 (en) 2014-12-18 2018-10-02 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10033627B1 (en) 2014-12-18 2018-07-24 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9887932B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9819567B1 (en) 2015-03-30 2017-11-14 Amazon Technologies, Inc. Traffic surge management for points of presence
US9887931B1 (en) 2015-03-30 2018-02-06 Amazon Technologies, Inc. Traffic surge management for points of presence
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US10015077B2 (en) 2015-05-22 2018-07-03 Microsoft Technology Licensing, Llc Forwarding current request based on, at least in part, previous request(s)
US9946976B2 (en) * 2015-06-04 2018-04-17 Corey Francis Stedman System for enabling channel designation differentiation for hierarchically organizing and accessing address registers with address signifiers and elements
US10616179B1 (en) 2015-06-25 2020-04-07 Amazon Technologies, Inc. Selective routing of domain name system (DNS) requests
US10097566B1 (en) 2015-07-31 2018-10-09 Amazon Technologies, Inc. Identifying targets of network attacks
US9774619B1 (en) 2015-09-24 2017-09-26 Amazon Technologies, Inc. Mitigating network attacks
US9794281B1 (en) 2015-09-24 2017-10-17 Amazon Technologies, Inc. Identifying sources of network attacks
US9742795B1 (en) 2015-09-24 2017-08-22 Amazon Technologies, Inc. Mitigating network attacks
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US10257307B1 (en) 2015-12-11 2019-04-09 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10049051B1 (en) 2015-12-11 2018-08-14 Amazon Technologies, Inc. Reserved cache space in content delivery networks
US10348639B2 (en) 2015-12-18 2019-07-09 Amazon Technologies, Inc. Use of virtual endpoints to improve data transmission rates
US9591047B1 (en) 2016-04-11 2017-03-07 Level 3 Communications, Llc Invalidation in a content delivery network (CDN)
US10586023B2 (en) 2016-04-21 2020-03-10 Time Warner Cable Enterprises Llc Methods and apparatus for secondary content management and fraud prevention
US10929022B2 (en) 2016-04-25 2021-02-23 Netapp. Inc. Space savings reporting for storage system supporting snapshot and clones
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10432484B2 (en) 2016-06-13 2019-10-01 Silver Peak Systems, Inc. Aggregating select network traffic statistics
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US9967056B1 (en) 2016-08-19 2018-05-08 Silver Peak Systems, Inc. Forward packet recovery with constrained overhead
US9992086B1 (en) 2016-08-23 2018-06-05 Amazon Technologies, Inc. External health checking of virtual private cloud network environments
US10033691B1 (en) 2016-08-24 2018-07-24 Amazon Technologies, Inc. Adaptive resolution of domain name requests in virtual private cloud network environments
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
US10505961B2 (en) 2016-10-05 2019-12-10 Amazon Technologies, Inc. Digitally signed network address
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US10372499B1 (en) 2016-12-27 2019-08-06 Amazon Technologies, Inc. Efficient region selection system for executing request-driven code
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US10771394B2 (en) 2017-02-06 2020-09-08 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows on a first packet from DNS data
US11044202B2 (en) 2017-02-06 2021-06-22 Silver Peak Systems, Inc. Multi-level learning for predicting and classifying traffic flows from first packet data
US10257082B2 (en) 2017-02-06 2019-04-09 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows
US10892978B2 (en) 2017-02-06 2021-01-12 Silver Peak Systems, Inc. Multi-level learning for classifying traffic flows from first packet data
US10503613B1 (en) 2017-04-21 2019-12-10 Amazon Technologies, Inc. Efficient serving of resources during server unavailability
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
US10447648B2 (en) 2017-06-19 2019-10-15 Amazon Technologies, Inc. Assignment of a POP to a DNS resolver based on volume of communications over a link between client devices and the POP
US11212210B2 (en) 2017-09-21 2021-12-28 Silver Peak Systems, Inc. Selective route exporting using source type
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
US10567333B2 (en) 2017-11-01 2020-02-18 Verizon Digital Media Services Inc. Deterministic traffic management in an anycast network
US10685493B2 (en) 2017-12-24 2020-06-16 Facebook, Inc. Systems and methods for delivering augmented reality content
US10462233B2 (en) * 2018-01-23 2019-10-29 Charter Communications Operating, Llc Protocol for anycast based discovery of local resources
US11070603B2 (en) 2018-02-26 2021-07-20 Charter Communicatons Operating, LLC Apparatus and methods for packetized content routing and delivery
US10771582B2 (en) 2018-03-04 2020-09-08 Netskrt Systems, Inc. System and apparatus for intelligently caching data based on predictable schedules of mobile transportation environments
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
US10637721B2 (en) 2018-03-12 2020-04-28 Silver Peak Systems, Inc. Detecting path break conditions while minimizing network overhead
US11140583B2 (en) * 2018-03-22 2021-10-05 Netskrt Systems, Inc. Transforming video manifests to enable efficient media distribution
US11388252B2 (en) 2018-03-22 2022-07-12 Netskrt Systems, Inc. Micro-cache method and apparatus for a mobile environment with variable connectivity
US11323536B2 (en) 2018-03-22 2022-05-03 Netskrt Systems, Inc. Apparatus and method for trans-border movement of streaming media content
US11399058B2 (en) 2018-03-22 2022-07-26 Netskrt Systems, Inc. Immutable ledger method and apparatus for managing the distribution of content
US11375036B2 (en) 2018-03-22 2022-06-28 Netskrt Systems, Inc. Method and apparatus to prioritize and schedule the distribution of learned content
US11128728B2 (en) 2018-03-22 2021-09-21 Netskrt Systems, Inc. Method and apparatus for walled garden with a mobile content distribution network
US11252253B2 (en) 2018-03-22 2022-02-15 Netskrt Systems, Inc. Caching aggregate content based on limited cache interaction
US11356530B2 (en) 2018-03-22 2022-06-07 Netskrt Systems, Inc. Leveraging mobile environment to distribute cache data
US10554701B1 (en) 2018-04-09 2020-02-04 Amazon Technologies, Inc. Real-time call tracing in a service-oriented system
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US10645008B1 (en) 2018-12-06 2020-05-05 Verizon Digital Media Services Inc. Predictive Anycast traffic shaping
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
EP3668052B1 (de) * 2018-12-13 2021-05-26 Telefonica, S.A. Verfahren, system und vorrichtungen zur verbesserten multimedia -inhaltsbereitstellung
US10999370B1 (en) * 2018-12-28 2021-05-04 BridgeLabs, Inc. Syncing and sharing data across systems
CN110417861B (zh) * 2019-06-25 2023-05-26 腾讯科技（北京）有限公司 一种信息推送方法以及相关装置
US11403849B2 (en) 2019-09-25 2022-08-02 Charter Communications Operating, Llc Methods and apparatus for characterization of digital content
US11438393B1 (en) * 2019-09-26 2022-09-06 Amazon Technologies, Inc. Origin server address rotation
US11153165B2 (en) 2019-11-06 2021-10-19 Dell Products L.P. System and method for providing an intelligent ephemeral distributed service model for server group provisioning
CN112866424A (zh) * 2019-11-28 2021-05-28 华为技术有限公司 域名查询方法以及相关设备
CN111191156B (zh) * 2019-12-20 2023-09-05 中移（杭州）信息技术有限公司 网络请求资源调度方法、装置及计算机可读存储介质
CN114124802B (zh) * 2021-11-10 2023-08-25 中盈优创资讯科技有限公司 一种跨域黑洞路由集中管控方法及装置
CN114071173A (zh) * 2021-11-15 2022-02-18 北京百度网讯科技有限公司 直播调度方法及装置、系统、电子设备和介质
US11792289B2 (en) * 2021-11-22 2023-10-17 International Business Machines Corporation Live socket redirection
US11831707B2 (en) * 2022-03-08 2023-11-28 Charter Communications Operating, Llc Redirect processing for content delivery networks
US11706292B1 (en) * 2022-03-15 2023-07-18 Disney Enterprises, Inc. Local preference in anycast CDN routing

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5611049A (en) 1992-06-03 1997-03-11 Pitts; William M. System for accessing distributed data cache channel at each network node to pass requests and data
US6085234A (en) 1994-11-28 2000-07-04 Inca Technology, Inc. Remote file services network-infrastructure cache
US5751338A (en) * 1994-12-30 1998-05-12 Visionary Corporate Technologies Methods and systems for multimedia communications via public telephone networks
US6003030A (en) 1995-06-07 1999-12-14 Intervu, Inc. System and method for optimized storage and retrieval of data on a distributed computer network
US6181867B1 (en) 1995-06-07 2001-01-30 Intervu, Inc. Video storage and retrieval system
JP2728064B2 (ja) * 1995-11-20 1998-03-18 日本電気株式会社 アドレス解決方法
US6038664A (en) * 1996-06-10 2000-03-14 Cubix Corporation Method for selecting communication access method for local area networks
US6154777A (en) * 1996-07-01 2000-11-28 Sun Microsystems, Inc. System for context-dependent name resolution
US6101180A (en) * 1996-11-12 2000-08-08 Starguide Digital Networks, Inc. High bandwidth broadcast system having localized multicast access to broadcast content
US6046980A (en) * 1996-12-09 2000-04-04 Packeteer, Inc. System for managing flow bandwidth utilization at network, transport and application layers in store and forward network
US6052718A (en) 1997-01-07 2000-04-18 Sightpath, Inc Replica routing
US6256675B1 (en) * 1997-05-06 2001-07-03 At&T Corp. System and method for allocating requests for objects and managing replicas of objects on a network
US6047322A (en) * 1997-05-27 2000-04-04 Ukiah Software, Inc. Method and apparatus for quality of service management
SE9702239L (sv) * 1997-06-12 1998-07-06 Telia Ab Arrangemang för lastbalansering i datornät
US6112239A (en) 1997-06-18 2000-08-29 Intervu, Inc System and method for server-side optimization of data delivery on a distributed computer network
US6006264A (en) * 1997-08-01 1999-12-21 Arrowpoint Communications, Inc. Method and system for directing a flow between a client and a server
CA2217277A1 (en) * 1997-10-03 1999-04-03 Newbridge Networks Corporation Automatic link establishment for distributed servers in atm networks
US5974453A (en) * 1997-10-08 1999-10-26 Intel Corporation Method and apparatus for translating a static identifier including a telephone number into a dynamically assigned network address
US6148005A (en) * 1997-10-09 2000-11-14 Lucent Technologies Inc Layered video multicast transmission system with retransmission-based error recovery
US6212570B1 (en) * 1998-04-29 2001-04-03 Nippon Telegraph & Telephone Corporation Information distribution device selection system
US6115752A (en) * 1998-05-21 2000-09-05 Sun Microsystems, Inc. System and method for server selection for mirrored sites
US6108703A (en) * 1998-07-14 2000-08-22 Massachusetts Institute Of Technology Global hosting system
US6078586A (en) * 1998-08-03 2000-06-20 Mci Communications Corporation ATM virtual private networks
US6092178A (en) * 1998-09-03 2000-07-18 Sun Microsystems, Inc. System for responding to a resource request
US6578066B1 (en) * 1999-09-17 2003-06-10 Alteon Websystems Distributed load-balancing internet servers
US6286052B1 (en) * 1998-12-04 2001-09-04 Cisco Technology, Inc. Method and apparatus for identifying network data traffic flows and for applying quality of service treatments to the flows
BR9908762A (pt) * 1998-11-02 2004-02-25 Integrated Data Communications Endereçamento de protocolo de internet geo-espacial
KR100285122B1 (ko) * 1999-01-13 2001-03-15 이수복 인터넷 전자우편 부가 서비스 시스템
US7188138B1 (en) * 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
US6735633B1 (en) * 1999-06-01 2004-05-11 Fast Forward Networks System for bandwidth allocation in a computer network
US6542964B1 (en) * 1999-06-02 2003-04-01 Blue Coat Systems Cost-based optimization for content distribution using dynamic protocol selection and query resolution for cache server
US6442602B1 (en) * 1999-06-14 2002-08-27 Web And Net Computing System and method for dynamic creation and management of virtual subdomain addresses
US7441045B2 (en) * 1999-12-13 2008-10-21 F5 Networks, Inc. Method and system for balancing load distribution on a wide area network
US20030177274A1 (en) * 2002-03-12 2003-09-18 Chen Sun Virtual subdomain address file suffix
US20030050920A1 (en) * 2001-02-12 2003-03-13 Chen Sun Contacts management using virtual subdomains
US6741585B1 (en) * 2000-05-05 2004-05-25 Lucent Technologies Inc. Interworking of addressing in an internetwork
US20030193958A1 (en) * 2002-04-11 2003-10-16 Vidya Narayanan Methods for providing rendezvous point router redundancy in sparse mode multicast networks
US7010565B2 (en) * 2002-09-30 2006-03-07 Sampson Scott E Communication management using a token action log

Also Published As

Publication number Publication date
EP1865684B1 (de) 2011-09-28
EP1250785B1 (de) 2007-08-15
WO2001052497A9 (en) 2002-05-16
US20050010653A1 (en) 2005-01-13
WO2001052497A2 (en) 2001-07-19
US6785704B1 (en) 2004-08-31
EP1250785A2 (de) 2002-10-23
EP2838240A1 (de) 2015-02-18
EP1865684A1 (de) 2007-12-12
EP2838240B1 (de) 2020-08-12
US7734730B2 (en) 2010-06-08
EP2320619B1 (de) 2014-10-01
EP2320619A1 (de) 2011-05-11
DE60036021D1 (de) 2007-09-27
WO2001052497A3 (en) 2002-01-24
AU2282701A (en) 2001-07-24

Similar Documents

Publication Publication Date Title
DE60036021T2 (de) System zur Verteilung von Daten innerhalb eines Internetzwerkes mit zweitseitiger Vereinbarung über Inhalt
DE69909839T3 (de) Optimierte Lokalisierung von Netzwerkbetriebsmittel
DE60301611T2 (de) Wegoptimierer für gleichrangige netzwerke
DE60217666T2 (de) System und verfahren zum beantworten von ressourcenanforderungen in verteilten rechnernetzen
DE60132718T2 (de) System und methode zum auffinden von informationsobjekten und informationsobjektspeichern in rechnernetzen
DE60208659T2 (de) Skalierbare ressourcenermittlung und rekonfiguration für verteilte rechnernetze
DE60121176T2 (de) Verfahren und System zur anforderungsorientierten Wiedererkennung von verbindungsorientierten Transaktionen
DE69730056T2 (de) Routen von duplikaten
DE69834731T2 (de) Arrangement zum gemeinsamen laden in computernetzwerken
US9252963B2 (en) Performing multicast communication in computer networks by using overlay routing
US6944676B1 (en) Information dissemination system and method with central and distributed caches
DE60204528T2 (de) Auflösen von virtuellen Netzwerknamen
DE60108166T2 (de) Untergruppen-multicasting in einem kommunikationsnetz
DE60125954T2 (de) Adressierung und routen von datenpaketen in einem computer-netzwerk mit hilfe von inhaltsbeschreibenden labeln
DE112019005826T5 (de) Lastverteilter Zugang zu verteilten Endpunkten unter Verwendung globaler Netzwerkadressen
EP3507969A1 (de) Anycast-manifestabruf, unicast-inhaltsabruf
DE60205393T2 (de) Verfahren und vorrichtung zum empfang von rundsendedaten
Molina et al. A closer look at a content delivery network implementation
Trossen et al. If Multicast is the Answer--What was the Question?
Vogels et al. A collaborative infrastructure for scalable and robust news delivery
Rodriguez et al. Automated delivery of web documents through a caching infrastructure
Gupta Scalable distribution of data across autonomous systems
DE10113552A1 (de) Verfahren, Anordnung von Computersystemen, Computersystem und Computerprogrammprodukt zum effizienten Verteilen von Daten in einem Netzwerk
DE102008028591A1 (de) Verfahren zur unterbrechungsfreien Datenübertragung
Davidson et al. Language constructs for timed atomic commitment

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8328 Change in the person/name/address of the agent

Representative=s name: BOSCH JEHLE PATENTANWALTSGESELLSCHAFT MBH, 80639 M