-
VERWANDTE ANMELDUNGEN
-
Die
vorliegende Erfindung bezieht sich auf und beansprucht hierdurch
den Prioritätsvorteil
der folgenden vorläufigen
US-Patentanmeldungen:
Anmeldung Nr. 60/190,331 mit dem Titel „SYSTEM
AND METHOD FOR DISCOVERING INFORMATION OBJECTS AND INFORMATION OBJECT
REPOSITORIES IN COMPUTER NETWORKS", eingereicht am 16. März 2000
von J. J. Garcia-Luna-Aceves; und
Anmeldung Nr. 60/200,401
mit dem Titel „SYSTEM
AND METHOD FOR DISCOVERING OPTIMUM INFORMATION OBJECT REPOSITORIES
IN COMPUTER NETWORKS (WILD PROTOCOL)", eingereicht am 28. April 2000 von
J. J. Garcia-Luna-Aceves und Bradley R. Smith.
-
GEBIET DER ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein System und ein Verfahren für das Auffinden
von Informationsobjekten und von Informationsobjektespeichernden
Servern, die über
Computernetzwerke verteilt sind, sowie Server, die beim Zugriff
gemäß Typen
von Service-Parametern besonders effizient sind. Insbesondere betrifft die
vorliegende Erfindung das Auffinden des Orts von Cache- und Hosting-Sites
im World Wide Web, die beim Zugriff von einem Objekt-anfordernden
Standpunkt und darin, die angeforderten Informationsobjekte und -dienste
nach Wunsch zu diesen Cache- und Hosting-Sites zu bringen, höchst effizient
sind.
-
HINTERGRUND
-
Ein
Internetzwerk ist eine Sammlung von Computernetzwerken, die durch
Knoten miteinander verbunden sind, wobei jeder solcher Knoten ein
Mehrzweckcomputer oder eine spezialisierte Vorrichtung wie etwa ein
Router sein kann. Insofern wird ein Internetzwerk häufig Netzwerk
von Netzwerken genannt. Der Zweck des Aufbaus eines Internetzwerks
ist es, Informationsdienste zu Endknoten zu liefern, wobei jeder
Endknoten ein Netzwerkcomputer oder eine spezialisierte Vorrichtung
wie etwa eine Kamera oder ein Display sein kann. Das Internet ist
ein Internetzwerk, in dem Information als Paket organisiert ist,
die von einer Quelle zu Bestimmungsendknoten nach Art von Speicherung
und Lieferung verteilt werden, und worin Router und Endknoten das
Internetprotokoll (IP) verwenden, um diese Pakete zu kommunizieren.
-
Das
World Wide Web (auch als WWW oder Web bekannt) ist im Internet zum
wesentlichen Informationsdienst geworden. Das Web stellt ein System
dar, um über
das gesamte Internet hinweg auf gelinkte Informationsobjekte zuzugreifen,
die in Endknoten (Host-Computern) gespeichert sind. Berners-Lee schrieb den ursprünglichen
Vorschlag für
ein Web aus verlinkten Informationsobjekten (T. Berners-Lee, „Information
Management: A Proposal",
CERN Document, März
1989). Das Web besteht aus einer wilden Sammlung von Informationsobjekten,
die als Seiten (Pages) organisiert sind, und jede Seite kann Links
zu anderen Seiten oder allgemein Informationsobjekte enthalten,
deren Inhalt als Audio, Video, Bilder, Text oder Daten dargestellt
ist. Seiten werden vom Endbenutzer mit einem Programm betrachtet,
das Browser genannt wird (zum Beispiel Netscape NavigatorTM). Der Webbrowser läuft in einem Endsystem nach
Vorgaben des Benutzers. Der Client (Webbrowser) erhält die angeforderten
Informationsobjekte von einem Server (Webserver) mittels eines Anfrage-Antwort-Dialogs als
Teil des Hypertext Transfer Protokolls (HTTP). Informationsobjekte
werden mittels Namen identifiziert, die über das gesamte Internet eindeutig
sind; diese Namen werden Uniform Resource Locators oder URLs genannt.
Ein URL besteht aus drei Komponenten:
- (1) dem
Protokoll oder Schema, das zum Zugriff auf das Objekt verwendet
werden soll (zum Beispiel HTTP);
- (2) den Namen (einen DNS-Namen) des Hosts, an dem das Objekt
lokalisiert ist; und
- (3) einem lokalen Identifizierer, der in dem spezifizierten
Host eindeutig ist.
-
Wie
jedes groß bemessene
System erfordert das Web die Verwendung von Mechanismen für Skalierung
und Zuverlässigkeit.
Insbesondere weil die Anzahl von Informationsobjekten, die durch
das Web erhalten werden können,
zunimmt, finden es die Menschen immer schwieriger, die spezifischen
Informationsobjekte zu lokalisieren, die sie benötigen. Da ferner die Anzahl
von Web-Benutzern und Servern zunimmt, können Sites oder Server, die
die angeforderten Informationsobjekte speichern, von den die Objekte
anfordernden Verwendern sehr weit entfernt sein, was zu langen Latenzen
im Zugriff und der Lieferung der Information führt, oder die die Informationsobjekte
speichernden Server können
mit der Anzahl der Anfragen für
populäre
Informationsobjekte überfordert
sein.
-
Um
das Web in die Lage zu versetzen, große und rasch zunehmende Anzahlen
von Benutzern und eine wilde und wachsende Sammlung von Informationsobjekten
zu skalieren, müssen
die Informationsobjekte in dem Web auf mehrere Server verteilt gespeichert
werden, derart, dass Benutzer die Informationsobjekte, die sie benötigen, rasch
abfragen können,
und ohne einen der die Objekte speichernden Server zu überfordern.
-
Dementsprechend
ist es für
das Web zur Skalierung und Zuverlässigkeit erforderlich, Informationsobjekte
zwischen mehreren Seiten zu verteilen. Die zu diesem Ziel verwendeten
Schemata werden Web-Caching Schemata genannt. In einem Web-Caching
Schema wird ein oder werden mehrere Web-Caches oder Proxy-Webserver
in Computernetzwerken und im Internet verwendet, um zu erlauben,
das mehrere Host-Computer (Clients) auf einen Satz von Informationsobjekten
von anderen Seiten als den Seiten zu greifen, von denen der Inhalt
(die Objekte) ursprünglich
bereitgestellt werden. Web-Caching
Schemata unterstützen
das Auffinden der Seiten, wo die Informationsobjekte gespeichert
sind, das Verteilen von Informationsobjekten zwischen den Web-Caches
und das Abfragen von Informationsobjekten von einem gegebenen Web-Cache.
Viele bisherige Vorschläge
und Implementationen unterscheiden sich in den verschiedenen Mechanismen,
die zum Unterstützen
jedes dieser Dienste verwendet werden.
-
Im
Stand der Technik gibt es viele Verfahren zur Bestimmung des Servers,
Cache, Spiegelserver oder Proxy, aus denen Informationsobjekte abgefragt
werden sollten. Der Stand der Technik bezieht sich auf die Entwicklung
des ARPANET in den 1970ern und die Untersuchung und Implementierung
von Methoden zur Lösung
des Datei-Allokation-Problems (FAP) für Datenbanken, die über das
ARPANET verteilt sind, und Computernetzwerke im Allgemeinen.
-
Datei-Allokations-Methoden
für verteilte
Datenbanken (zum Beispiel W. W. Chu, „Optimal File Allocation in
a Multiple Computer System",
IEEE Transactions an Computers, Oktober 1969; S. Mahmoud and J.
S. Riordon, „Optimal
Allocation of Resources in Distributed Information Networks", ACM Transactions
an Data Base Systems, Band 1, Nr. 1, März 1976; H. L. Morgan und K.
D. Levin, „Optimal
Program and Data Locations in Computer Networks", Communications of the ACM, Band. 20,
Nr. 5, Mai 1977) und Directory-Systeme (zum Beispiel W. W. Chu, „Performance
of File Directory Systems for Data Bases in Star and Dirstributed
Networks", Proc.
National Computer Conference, 1976, S. 577–587; D. Small und W. W. Chu, „A Distributed
Data Base Architecture for Data Processing in a Dynamic Environment", Proc. COMPCON 79
Spring) stellen einige der frühesten Ausführungen
von Methoden dar, die zum Wählen
einer Ausgabeseite verwendet werden, um auf eine Datei oder ein
Informationsobjekt zuzugreifen, das auf einer Anzahl von Seiten
repliziert werden kann.
-
Ein
anderes Beispiel dieser herkömmlichen
Technik ist die Methode, die beschrieben ist von Chiu, Raghavendra
und Ng (G. Chiu, C. S. Rahgavendra und S. M. Ng, „Resource
Allocation with Load Balancing Consideration an Distributed Computing
Systems", Proc.
IEEE INFOCOM 89, Ottawa, Ontario, Kanada, April 1999, S. 758–765). Gemäß dieser
Methode werden mehrere identische Kopien derselben Quelle (zum Beispiel eine
Datei, ein Informationsobjekt) über
eine Anzahl von Verarbeitungs-Sites (zum Beispiel ein Spiegelserver, ein
Cache) eines verteilten Rechensystems verteilt. Die Methode versucht,
die Kosten zu minimieren, die beim Replizieren der Quelle an den
Verarbeitungs-Sites und beim Abfragen der Quelle durch Benutzer
des Systems von den Bearbeitungsseiten auftreten.
-
Eine
jüngere
Arbeit hat sich mit dem gleichen Resourcen-Allokation- und Auffindungsproblem
innerhalb des Kontexts von Internetdiensten befasst. Guyton und
Schwartz (J. D. Guyton und M. F. Schwartz, „Locating Nearby Copies of
Replicated Internet Servers",
Proc. ACM SIGCOMM 95 Conference, Cambridge, Massachusetts, August
1995, S. 288–298)
beschreiben und analysieren Serverlokationstechniken für replizierte
Internetdienste, wie etwa Network Time Protocol (NTP), Server und
Web-Caches. Im Stand
der Technik gibt es verschiedene unterschiedliche Ansätze für das Auffinden
von Informationsobjekten in Web-Caching Schemata.
-
Ein
Ansatz für
die Objektauffindung besteht in der hierarchischen Organisation
von Web-Caches. In einer hierarchischen Web-Cache-Architektur wird
zwischen den Caches eine Eltern-Kind-Beziehung hergestellt; jedes
Cache in der Hierarchie teilt sich eine Gruppe von Clients oder
einen Satz von Kinder-Caches. Eine Anfrage nach einem Informationsobjekt
von einem Client wird auf der niedrigsten Cache-Ebene verarbeitet, das
entweder eine Kopie des angeforderten Objekt hat oder jedes seiner
Geschwister in der Hierarchie für
das Objekt abfragt und die Anfrage zu seinem Eltern-Cache weiterleitet,
wenn kein Geschwister eine Kopie des Objekts hat. Der Prozess geht
in der Hierarchie hinauf, bis eine Kopie des Objekts von dem Cache
lokalisiert ist oder der Wurzel der Hierarchie erreicht ist, die
aus Servern mit der Originalkopie des Objekts besteht.
-
Eines
der frühesten
Beispiele vom hierarchischen Web-Caching war das Discover-System
(A. Duda und M. A. Sheldon, „Content
Routing in networks of WAIS Servers", Proc. IEEE 14th International
Conference an Distributed Computing Systems, Juni 1994; M. A. Sheldon,
A. Duda, R. Weiss, J. W. O'Toole,
Jr. Und D. K. Gifford, „A
Content Routing System for Distributed Information Servers", Proc. Fourth International
Conference an Extending Database Technology, März 1994), das einen assoziativen
Zugriff zu Servern bereitstellt; der Benutzer leitet die Verfeinerung
der Anfrage.
-
Harvest
(A. Chankhunthod, P. Danzing, C. Neerdaels, M. Schwartz und K. Worrell, „A Hierarchical
Internet Object Cache",
Proc. USENIX Technical Conference 96, San Diego, California, Januar
1996) und Squid (D. Wessels, „Squid
Internet Object Cache",
http://www.squid.org, August 1998) sind zwei der bestbekannten hierarchischen
Web-Cache-Architekturen. Harvest und Squid konfigurieren Web-Caches
zu einer statischen hierarchischen Struktur, worin ein Web-Cache
ein statischer Satz von Siblings und einem Parent ist. Das Internet-Caching-Protocol
oder ICP (D. Wessels und K. Claffy, „Internet Cache Protocol (OCP),
Version 2'', RFC 2186, September
1997) wird unter Web-Caches verwendet, um Informationsobjekte anzufordern.
-
In
den Harvest-Hierarchien werden Geschwister und Eltern manuell in
Web-Caches oder
Proxys konfiguriert; dies ist sehr einschränkend und fehlerbehaftet, weil
die Rekonfiguration stattfinden muss, wenn ein Cache in das System
eintritt oder dieses verlässt.
Eine noch allgemeinere Beschränkung
des hierarchischen Web-Caching basierend auf statischen Hierarchien
ist, dass die Verzögerungen,
die beim Routen von Anfragen nach Informationsobjekten auftreten,
in einem groß bemessenen
System zu stark werden können,
und die Latenz darin, das Informationsobjekt von dem Cache mit einer
Kopie des Objekts abzufragen, kann lang sein, weil es keine Korrelation
zwischen dem Routing der Anforderung zu einem gegebenen Cache in
der Hierarchie und der Netzwerkverzögerung von diesem Cache zu
dem anfordernden Client gibt. Ferner können einige Web-Caches mit
Anfragen überlastet
sein, während
andere zu wenig genutzt werden können,
selbst wenn sie dieselben Objekte speichern.
-
In
dem WebWave-Protokoll (A. Heddaya und S. Mirdad, „WebWave:
Globally Load Balanced Fully Distributed Caching of Hot Published
Documents", Technical
Report BU-CS-96-024, Boston University, Computer Science Department,
Oktober 1996; A. Heddaya und S. Mirdad, „WebWave: Globally Load Balanced
Fully Distributed Caching of Hot Published Documents", Proc. IEEE 17th International Conference an Computing
Systems, Baltimore, Maryland, Mai 1997) sind Web-Caches als ein
Baum organisiert, der seine Wurzeln an dem Server hat, der die ursprüngliche
Kopie des einen Objekts oder einer Familie von Informationsobjekten
bereitstellt; die Blätter
des Baums sind die Clients, die die Informationsobjekte anfragen,
und der Rest der Knoten in dem Baum sind Web-Caches. Das Ziel des
Protokolls ist es, einen Lastausgleich zwischen den Web-Caches zu
erreichen; jedes Web-Cache in einem solchen Baum hält ein Maß der Last
an seinem Elter und Kind in dem Baum, und liefert oder leitet die
Anforderung automatisch zu seinem Elter basierend auf der Lastinformation. Dieser
Ansatz assoziiert die Möglichkeit
der Überlastung
von Web-Caches, wie beim Harvest-Ansatz für hierarchisches Web-Caching;
jedoch treten immer noch Verzögerungen
in der Fortleitung von Anfragen von stark belasteten Web-Caches
zu ihren Vorgängern
in der Web-Hierarchie
auf.
-
Hash-Routing-Protokolle
(K. W. Ross, „Hash
Routing for Collections of Shared Web Caches", IEEE Network, Band 11, Nr. 6, November
1997, S. 37–44)
stellen einen anderen Ansatz dar, um das Auffinden eines Objekts
in aufgeteilten Caches zu unterstützen. Hash-Routing-Protokolle
beruhen auf einem deterministischem Hashing-Ansatz zum Mappen eines
Informationsobjekts zu einem eindeutigen Cache (D. G. Thaler und C.
V. Ravishankar, „Using
Name-Based Mappings To Increase Hit", IEEE/ACM Trans. Networking, 1998;
V. Valloppillil und J. Cohen, „Hierarchical
HTTP Routing Protocol",
Internet Draft, http://www.nlanr.net/Cache/ICP/draft-vinod-icp-traffic-dist-00.txt),
um die Informationsobjekte zu verteilen (universeller Resourcen-Lokator
oder URL im Falle des Webs) zwischen einer Anzahl von Caches; das
Endergebnis ist die Entstehung eines einzigen logischen Caches,
das über
viele physikalische Caches hinweg verteilt wird. Eine wichtige Eigenschaft
dieses Schemas ist, dass Informationsobjekte zwischen Cache-Sites
nicht repliziert werden. Die Hash-Funktion kann an den Clients oder
an den Cache-Sites gespeichert werden. Der Hash-Raum ist unter den
N Cache-Sites unterteilt. Wenn ein Client Zugriff zu einem Informationsobjekt
o braucht, wird der Wert für die
Hash-Funktion für
o (h(o)) an dem Client oder einer Cache-Site berechnet (im letzteren
Fall wird das Cache zum Beispiel an dem Client konfiguriert). Der
Wert von h(o) ist die Adresse der Cache-Site zum Kontaktieren in
der Zugriffsreihenfolge des Informationsobjekts o.
-
Der
Cache-Resolver ist anderer jüngerer
Ansatz für
das hierarchische Web-Caching
(D. Karger, E. Lehman, T. Leighton, M. Levine, D. Lewin und R. Panigraphy, „Consistent
Hashing and Random Trees: Distributed Caching Protocols for Relieving
Hot Spots an the World Wide Web",
Proc. 29th ACM Symposium an Theory of Computing
(STOC 97), El Paso, Texas, 1997; D. Karger, Sherman, A. Berkheimer,
B. Bogstad, R. Dhannidina, K. Iwamoto, B. Kim, L. Matkins und Y.
Yerushalmi, „Web
Caching with Consistent Hashing",
Proc. 8th International World Wide Web Conference,
Toronto, Canada, Mai 1999). Dieser Ansatz kombiniert hierarchisches
Web-Caching mit Hashing und besteht aus zwei Haupttools, Zufalls-Cache-Bäumen und
konsistentem Hashing. Ein Baum von Web-Caches ist für jedes
Informationsobjekt definiert. Wenn ein Browser (ein Client) ein
Informationsobjekt anfordert, nimmt er ein Blatt des Baumes auf
und liefert eine diesen Identifizierer enthaltende Anforderung,
den Identifizierer des Objekts, die Sequenz von Caches, durch die
hindurch die Anforderung geroutet werden soll, falls erforderlich.
Wenn ein Web-Cache eine Anfrage erhält, bestimmt es, ob es eine
lokale Kopie der Seite hat und reagiert auf die Anfrage, falls sie
diese hat; andererseits leitet sie die Anfrage zum nächsten Web-Cache
in den Weg, der in der Anfrage enthalten ist, weiter.
-
Ein
Web-Cache beginnt dann damit, eine lokale Kopie eines Informationsobjekts
zu halten, wenn die Anzahl von Anfragen, die es für das Objekt
erhält,
eine vordefinierte Anzahl erreicht. Ein Client wählt ein Web-Cache mittels konsistentem Hashing,
was Anfragen zu den Blättern
der Web-Cache-Hierarchie gleichmäßig verteilt,
aber, anders als traditionelle Hashing-Techniken, keine aktualisierte
Hash-Tabelle umverteilen muss, jedes Mal, wenn in der Hashing-Hierarchie
eine Änderung
auftritt (zum Beispiel sich ein neues Web-Cache anschließt oder
ein Web-Cache ausfällt).
Weil Caching sehr schwer zu implementieren ist oder zu existierenden
Webbrowsern hinzuzufügen
ist, implementiert der Cache-Resolver-Ansatz das Hashing von DNS-Servern,
die Anpassung an diesen Zweck modifiziert sind.
-
Die
restlichen Einschränkungen
mit diesem Ansatz beruhen auf dem fortgesetzten Gebrauch einer Hierarchie
von Web-Caches und dem Bedarf, eine Hash-Funktion in entweder Web-Caches
oder DNS-Servern zu implementieren. Das Routen einer Anforderung
durch mehrere Web-Caches kann wesentliche Verzögerungen für die Clients mit sich bringen,
um Informationsobjekte abzufragen, die zwischen anderen Clients, welche
dem gleichen Web-Cache durch die Hashing-Funktion zugewiesen werden,
nicht populär
sind. Zusätzliche
Verzögerungen,
und auch kleine, entstehen an dem DNS-Server, der die Adresse des
Web-Caches, auf die der Client zugreifen sollte, bereitstellt. Ferner
müssen
die DNS-Server, die die konsistente Hashing-Funktion stützen, Information über die
Beladung aller Web-Caches in dem gesamten System erhalten, oder
zumindest einen Bereich des Systems, um genaue Lastausgleichsentscheidungen
zu treffen.
-
Dieser
DNS-basierende Ansatz wird, ohne die Verwendung der Hierarchien
von Web-Caches, angesprochen in der Akamai-CDN-Lösung (F. T. Leighton und D.
M. Lewin, „Global
Hosting System",
U.S. Patent 6,108,703 , 22.
August 2000). Das von Akamai angesprochene „Global Hosting System" stellt sicher, dass
ein Inhalts-Provider ein HTML-Dokument beginnt, worin spezielle
URLs einen für
Akamai spezifischen Domain-Namen spezifizieren. Wenn der Client
die IP-Adresse des Web-Caches benötigt, die den im speziellen URL
spezifizierten Inhalt hostet, kontaktiert der Client zuerst sein
lokales DNS. Das lokale DNS weist zu einem „Top-Level" DNS-Server, der das lokale DNS zu einem
regionalen DNS-Server verweist, die dem lokalen DNS benachbart erscheint.
Der regionale DNS-Server verwendet eine Hashing-Funktion, um den
Domain-Namen in dem speziellen URL in die Adresse eines Web-Caches
(Hosting Server) in seinem Bereich herauszufinden, das in der vorliegenden
Anmeldung als Ziel-Web-Cache bezeichnet wird, in einer derartigen
Weise, dass die Last zwischen Web-Caches in dem Bereich ausgeglichen wird.
Das lokale DNS liefert die Adresse dieses Web-Caches zu dem Client,
der wiederum seine Anfrage nach dem Informationsobjekt zu diesem
Web-Cache schickt. Wenn das Objekt in dem Ziel-Web-Cache abgelegt
wird, sendet das Cache das Objekt zu dem Client; andernfalls wird
das Objekt von der Original-Inhalts-Site wieder abgefragt.
-
Das
von Akamai angesprochene Global Hosting System sollte auf Probleme
hinweisen, die bei traditionellen lastausgeglichenen Spiegelungslösungen auftritt,
worin ein Lastausgleicher oder eine Hierarchie von Lastausgleichern
Anfragen zu einer weniger Hosting-Sites umleiten, um die Last zwischen
diesen Sites auszugleichen. Firmen, wie etwa Cisco-Systems, Santa
Clara, Ca, F5 Networks, Inc., Seattle, WA, Resonate, Inc., Sunnyvale,
CA, Nortel Networks, Brampton, Ontario und Foundry Networks, Inc.,
San Jose, CA liefern gegenseitig Beispiele von lastausgeglichenen
Lösungen.
Die Einschränkungen
des globalen Hosting Systems sind inhärent für die Tatsache, dass der Ansatz
im Wesentlichen eine DNS-basierende lastausgeglichene Spiegelungslösung ist.
Das Global Hosting System wählt
ein Ziel-Web-Cache vollständig
basierend auf dem Bereich, der für
das lokale DNS günstig
erscheint, das den Client nicht begünstigen braucht, und die Last
zwischen Web-Caches ausgleicht, ohne die Latenz zwischen den Web-Caches
und den Clients zu berücksichtigen.
Im Fall eines fehlenden Caches muss das Informationsobjekt von der
originale Inhalts-Site abgefragt werden, was bedeutet, dass die
Latenzen in der Lieferung des Inhalts sehr stark variieren können, solange
nicht der Inhalt in allen Caches aller Bereiche gespiegelt ist.
-
Ein
anderer alternativer Ansatz für
hierarchische Web-Caching- und Hash-Routing-Protokolle besteht aus der Weiterleitung
von Client-Anfragen nach URLs mittels Routing-Tabellen, die den
Routing-Tabellen sehr ähnlich
sind, die häufig
für das
Routing von IP-Paketen im Internet verwendet werden (L. Zhang, S.
Michel, S. Floyd und V. Jacobsen, „Adaptive Web Caching: Towards
a New Global Caching Architecture", Proc. Third International WWW Caching
Workshop, Manchester, England, Juni 1998, B. S. Michel, K. Nikoloudakis,
P. Reiher und L. Zhang, „URL
Forwarding and Compression in Adaptive Web Caching", Proc. IEEE Infocom
2000, Tel Aviv, Israel, April 2000). Gemäß diesem Ansatz, der hierin
als „URL-Anfrage-Weiterleitung" bezeichnet wird,
enthalten Web-Caches eine URL-Anfrage-Routing-Tabelle, und verwenden
sie zur Entscheidung, wie URL-Anfragen zu anderen Web-Caches weitergeleitet
werden sollen, wenn angeforderte Informationsobjekte örtlich nicht
gefunden werden. Die Schlüssel
der URL-Anfrage-Routing-Tabelle
sind URL-Präfixe,
die einem oder mehreren Identifizierern zu sprungnächsten Caches
oder Cache-Gruppen zugeordnet sind, sowie eine Maß, das die
durchschnittliche Verzögerung
widerspiegelt, um eine Anfrage von einem passenden URL abzufragen.
-
Bei
diesem Ansatz spezifiziert ein Eintrag in der URL-Anfrage-Routing-Tabelle ein URL-Präfix und
das sprungnächste
Web-Cache zu einem Bereich oder Nachbarschaft von Web-Caches, wo
sich das Objekt befindet. Im Idealfall braucht ein Web-Cache nur
zu wissen, wo eine Kopie eines gegebenen Objekts abgelegt ist; jedoch
erfordert, wegen der großen
Anzahl von Objekten (identifizierten URLs), die in einem System
angefordert werden können,
der URL-Anfrage-Weiterleitungs-Ansatz, dass Web-Caches zu Bereichen
oder Nachbarschaften organisiert sind. Alle Web-Caches innerhalb
des gleichen Bereichs kennen die Objekte, die in jedem anderen Web-Cache
in demselben Bereich verfügbar
sind. Zusätzlich
hält, für jene Objekte,
die sich im Bereich des Web-Caches nicht befinden, das Web-Cache auch das sprungnächste Web-Cache
zu dem Bereich hin, in dem sich ein Web-Cache mit dem Inhalt befindet.
-
Leider
hat dieser Ansatz verschiedene Einschränkungen bei der Skalierung
und Leistung. Erstens muss jedes Web-Cache alle Web-Caches kennen,
wo sich jedes Objekt in dem Bereich befindet, was zu einer starken
Belastung führt,
wie ähnlich
der Belastung, eines Rundsendeprotokolls traditioneller Topologie
für IP-Routing
mit dem zusätzlichen
Nachteil, dass die Anzahl von Objekten, die sich in einem Bereich
befinden können,
viel größer sein
kann als die Anzahl von IP-Adressbereichen, die in den Rückgrat-Routern
des Internets gehalten werden. Zweitens, weil Web-Caches nur etwa
den nächsten
Sprung zu einem URL kennen, der sich nicht in einem Bereich befindet,
könnte
eine Anfrage nach einem Objekt, das außerhalb des Bereichs eines
Web-Caches liegt, mehrere Web-Cache-Ströme überqueren, bevor ein Web-Cache
in dem Bereich erreicht, wo ein Objekt gespeichert ist. Dies liefert
weiter zusätzliche
Latenzen ähnlich
jenen, die bei Caching-Hierarchien
auftreten, die in den oben diskutierten anderen Schemata vorgeschlagen
wurden. Drittens ist es schwierig, Web-Caches in der Praxis so zu
modifizieren, dass Mechanismen implementiert werden, die zum Weiterleiten
der URL Anfragen erforderlich sind.
-
Um
die Verzögerungen
zu reduzieren, die in den hierarchischen Web-Caches auftraten, führten Tewari, Dahlin, Vin und
Kay (R. Tewari, „Architecture
und Algorithms for Scalable Wide-Area Information Systems", Ph. D. Dissertation,
Chapter 5, Computer Science Department, University of Texas at Austin,
August 1998; R. Tewari, M. Dahlin, H. M. Vin und J. S. Kay, „Design
Considerations for Distributed Caching an the Internet", Proc. IEEE 19th International Conference on Distributed
Computing Systems, May 1999) im Kontext einer hierarchischen Web-Caching-Architektur
ein. Bei diesem Schema hat ein Web-Cache Zugriff zu einem lokalen Hinweis-Cache,
das eine Karte eine Objekts zu einem Identifizierer eines anderen
Web-Caches enthält,
das eine Kopie des Objekts hat und dem lokalen Hinweis-Cache am
nächsten
ist. Die Web-Caches auf der ersten Ebene der Hierarchie enthalten
Kopien von Informationsobjekten, während Web-Caches auf höheren Ebenen nur
Hinweise zu den Objekten enthalten. Hinweise werden entlang der
hierarchischen Topologie von den in der Hierarchie niedrigeren Web-Caches zu den in
der Hierarchie höheren
Web-Caches fortgeleitet. Ferner leitet ein Web-Cache mit einer Kopie
eines Objekts einen Hinweis auf das Objekt nicht weiter. Die Beschränkung bei
diesem Ansatz ist, dass eine Web-Caching-Hierarchie noch immer etabliert
sein muss, was bei Abwesenheit einer automatisierten Methode zum
Etablieren der Hierarchie manuell gemacht werden muss, und die Web-Caching-Hierarchie
muss an die Örtlichkeit
der Referenz-Clienten angepasst sein, um eine Steuerungsüberlastung
zu reduzieren.
-
Es
gibt eine Anzahl von Vorschlägen,
um die Weiterverteilung von Informationsobjekten unter Verwendung
von dem zu begünstigen,
was „Push
Distribution" genannt
wird, zum Beispiel von Backweb, Marimba und Pointcast („BackWeb:
http://www.backweb.com/", „Marimba:
http://www.marimba.com/";
Pointcast: http://www.pointcast.com/"). Bei diesem Ansatz verschiebt ein
Webserver die jüngste
Version eines Dokuments oder Informationsobjekts zu einer Gruppe
von Subscribern. Die populären
Internetbrowser Netscape Navigator und Internet ExplorerTM verwenden einen Unicast-Ansatz, worin
der Client das angeforderte Objekt direkt von der ursprünglichen
Quelle oder Cache erhält.
Da die Anzahl von Subscribern eines Dokuments oder Informationsobjekts
zunimmt, wird der Unicast-Ansatz ineffizient wegen eines Bearbeitungsüberhangs
und Servern und Proxys und Verkehrsüberlastung in den Netzwerken.
Der naheliegende Ansatz, die Pushverteilung mit der Anzahl von Subscribern
zu skalieren, besteht aus der Verwendung von Multicast-Technologie.
Bei diesem Ansatz (P. Rodriguez und E. W. Briesack, „Continuous
Multicast Push of Web Documents over the Internet", IEEE Network Magazine,
Band 12, Nr. 2, S. 18–31,
1998), wird ein Dokument fortlaufend innerhalb einer Multicast-Gruppe fortlaufen
zuverlässig
gemulticastet. Eine Multicast-Gruppe ist für ein gegebenes Dokument definiert
und Subscriber verbinden die Multicast-Gruppe des Web-Dokuments nach Bedarf,
um den Empfang von Updates zu dem Dokument zu beginnen. Eine Multicast-Gruppe
besteht aus einem Satz von Gruppenelementen, die Information enthalten
sollten, die zu der Gruppe von einer oder mehreren Quellen der Multicast-Gruppe
geschickt werden. Der Hauptnachteil dieses besonderen Ansatzes zur
Pushverteilung sind:
- – Der Anteil des Internets,
wo Subscriber angeordnet sind, müssen
Multicast-Routing-Verteilung unterstützen.
- – Eine
Multicast-Adresse und -Gruppe muss für jedes Dokument verwendet
werden, das zu den Subscribern geschoben werden soll, was schwierig
zu handhaben wird, wenn die Anzahl von so verschiedenen Dokumenten
zunimmt.
-
Ferner
haben Rodriguez, Biersack und Ross (P. Rodriguez, E. W. Biersack
und K. W. Ross, „Improving the
WWW: Caching or Multicast?",
Institut EURECOM 2229, Route Computer Networks and ISDN Systems, S.
1–17,
30. März
1998) haben gezeigt, dass das Multicasten von Webdokumenten eine
attraktive Alternative zu hierarchischem Web-Caching nur dann ist,
wenn die zu verschiedenen Dokumente sehr populär sind, da eine Caching-Verteilung weniger
Latenz hervorruft.
-
Kenner
und Karush (B. Kenner und A. Karush, „System and Method for Optimized
Storage and Retrieval of Data an a Distributed Computer Network",
U.S. Patent Nr. 6,003,030 , 14. Dezember
1999) schlagen eine Methode vor, um die Auslieferung von Informationsobjekten
zur Endbenutzern zu begünstigen.
Bei dieser Methode wird die Endbenutzer-Site, zusätzlich zum Webbrowser, mit
spezieller Software ausgestattet. Diese Software besteht auf einer
Konfigurations-Utility und einem Client-Programm. Die Konfigurations-Utility
wird dazu benutzt, um eine Auslieferungs-Site-Datei herunterzuladen,
die eine Liste von Auslieferungs-Sites
spezifiziert (Web-Caches oder ursprüngliche Webserver), von dem
die Informationsobjekte abgefragt werden können, sowie eine Anzahl von
Tests, die laufen können,
um zu bestimmen, welche Auslieferungs-Site kontaktiert werden soll.
Die Einschränkungen
zu diesem Ansatz beruhen auf der Tatsache, dass er für die Endbenutzer-Sites
nicht transparent ist. Insbesondere muss die Endbenutzer-Site zusätzliche
Software laufen lassen; es müssen
Leistungstests von der Endbenutzer-Site her an einer oder mehreren
Auslieferungs-Sites durchgeführt
werden, um zu entscheiden, welche Site benutzt werden muss; und
wenn an den Auslieferungs-Sites Änderungen
auftreten, muss eine neue Version der Auslieferungsdatei von der
Endbenutzer-Site abgefragt werden, oder es müssen neue Leistungstests durchgeführt werden.
-
Ein
anderer Ansatz dazu, das Auswählen
von Servern in einem Computer-Netzwerk
zu unterstützen (Z.
Fei, S. Bhattacharjes, E. W. Zegura und M. H. Ammar, „A Novel
Server Selection Technique for Improving The Response Time of a
Replicated Service",
Proc. IEEE Infocom 98, März
1998, S. 783–791)
besteht aus einem Rundsender-Server, der Information lädt, nachdem
ein bestimmter Lastschwellenwert oder eine Zeitdauer überschritten
ist. Die Einschränkung
dieses Ansatzes ist, dass, wie bei den Topologie-Rundsende-Protokollen,
die zum Routen im Computernetzwerken verwendet werden, das Schema
eine wesentliche Überlastung
hervorruft, wenn die Anzahl der Server zunimmt.
-
Ein
anderer jüngerer
Ansatz, Clients zu Host-Sites mit angeforderten Informationsobjekten
oder Diensten umzuleiten, ist der Replica-Routing-Ansatz, vorgeschlagen
von Sightpath, Inc. (D. K. Gifford, „Replica Routing", U.S.-Patent, 18.
April 2000). Gemäß dem Replica-Routing-Ansatz wird ein Informationsobjekt oder
Dienst in einer Anzahl von Replica-Servern repliziert. Das Replica-Routing-System
leitet eine Clientanfrage nach dem Informationsobjekt oder Dienst
zu einer „benachbarten" Replica des Objekts
oder Dienstes um. In einem Ansatz kennen alle Replica-Router die
Replica-Hinweise von jedem der Replica-Server in dem System, die
Information über
ihren Ort und Beobachtungen über
die örtliche
Internetzwerk-Topologie und Leistungsfähigkeit zusammenfassen. Bei
Verwendung dieser Überflutung
von Hinweisen entscheidet ein Replica-Router, welcher Replica-Server irgendeinem
Client benachbart erscheint. Wenn jedoch jeder Replica-Router die
Hinweise von jedem anderen Replica-Server empfangen muss, wird dies inpraktikabel,
wenn die Anzahl der Replica-Server und der Replica-Router zunimmt.
-
Zur Überwindung
dieses Problems werden Replica-Router zu einer Hierarchie organisiert,
und Replica-Hinweise werden nur auf einem Teil des Wegs bis zu dieser
Router-Hierarchie fortgeleitet. Eine kleine Anforderung wird zur
Wurzel der Hierarchie geleitet, und von dort wird sie die Hierarchie
nach unten weitergeleitet, bis sie einen Replica-Router mit ausreichend
Kenntnis über
die Internetzwerk-Örtlichkeit
der Replica erreicht, um eine informierte Umleitentscheidung zu
treffen. Dieser Ansatz hat ähnliche
Einschränkungen
in der Leistungsfähigkeit
und Skalierung wie die oben zusammengefassten herkömmlichen
Ansätze,
basierend auf Hierarchien von Web-Caches, Überflutung von Informationen
zwischen Caches oder Servern und Weiterleitung von Anforderungen über mehrere
Sprünge.
-
Die
PCT-Anmeldung Nr.
WO 99/40514 offenbart
einen Weg für
Server in einem Computernetzwerk, um ihre Verarbeitung von Anfragen
nach gewählten
Ressourcen abzuleiten, indem ein anderer Server (ein „Wiederholer") bestimmt wird,
um diese Anforderungen zu verarbeiten. Die Auswahl des Wiederholers
kann dynamisch erfolgen, basierend auf Information über mögliche Wiederholungen.
-
Ein
Artikel mit dem Titel „Routing
Information Protocol" von
C. Hendrick, Network Working Group, Juni 1998 (1998–06) (XP002233127)
beschreibt ein existierendes Protokoll zum Austausch von Routing-Information
zwischen den Gateways und anderen Hosts in der Internetgemeinschaft.
Das Routing-Protokoll,
das in diesem Artikel offenbart ist, beruht auf dem Bellman-Ford-(oder Distanzvektor-)Algorithmus.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Gemäß der vorliegenden
Erfindung wird ein Kommunikationsprotokoll angegeben, wie es in
Anspruch 1 der beigefügten
Ansprüche
aufgeführt
wird.
-
Die
vorliegende Erfindung gibt ein Verfahren und ein System zum Bestimmen
an, welches einer Anzahl günstiger
Informationsobjekt-Depots einen Client bedienen sollte, wobei das
Informationsobjekt-Depot das vom Client angeforderte Informationsobjekt über den
Dienst hält
und das Informationsobjekt oder den Dienst zu dem Informationsobjekt-Depot
bringt, das den Client bedienen soll. Indem man das Informationsobjekt
oder den Dienst, der vom Client angefordert wird, zu dem Informationsobjekt
bringt, von dem bestimmt worden dass es die Client-Anfrage bedienen
sollte, beinhaltet die Anweisung, dass ein Informationsobjekt-Depot
das Informationsobjekt oder den Dienst, der vom Client angefordert
wurde, von dem Informationsobjekt-Depot abzufragen, das das Informationsobjekt
oder den Dienst tatsächlich
enthält.
Danach kontaktiert, bei Erhalt einer Anweisung, dies zu tun, das
Informationsobjekt-Depot, von dem bestimmt wurde, dass es die Client-Anforderung
bedienen soll, das Informationsobjekt-Depot, das das Informationsobjekt
oder den Dienst, der vom Client angefordert wurde, tatsächlich enthält, direkt,
um das Informationsobjekt oder den Dienst anzufordern.
-
In
einer Ausführung
wird eine Adresse eines Informationsobjekt-Depots, das eine Client-Anforderung nach
einem Informationsobjekt bedienen sollte, in Antwort auf eine Anfrage
danach zurückgeführt. Die
Adresse des Informationsobjekt-Depots, die rückgeführt ist, wird gemäß spezifizierten
Performanzgrößen unabhängig davon
ausgewählt,
ob das Informationsobjekt-Depot eine lokale Kopie des Informationsobjekts
enthält,
das die Client-Anforderung ist. In einigen Fällen wird die Adresse des Informationsobjekt-Depots
ferner gemäß einer
Adresse des Clients ausgewählt,
der die Client-Anfrage macht. Ferner wird die Adresse des Informationsobjekt-Depots
aus einer Anzahl von Adressen von Informationsobjekt-Depots ausgewählt.
-
Die
spezifizierten Performanzgrößen können eine
oder mehrere von durchschnittlicher Verzögerung von dem Informationsobjekt-Depot
zu dem Client, durchschnittlicher Prozessverzögerungen an dem Informationsobjekt-Depot, Zuverlässigkeit
eines Wegs von dem Informationsobjekt-Depot zum Client, verfügbarer Bandbreite
in dem Weg und Last an dem Informationsobjekt-Depot beinhalten.
In einigen Fällen
kann das Informationsobjekt-Depot angewiesen werden, um eine Kopie
des Informationsojekts zu erhalten, nachdem die Adresse des Informationsobjekt-Depots
in Antwort auf die Anfrage danach zurückgekehrt ist.
-
Zusätzlich kann
eine Adresse eines Informationsobjekt-Depots, das eine lokale Kopie
des in einer Client-Anfrage spezifizierten Objekts enthält, zu dem
Informationsobjekt-Depot zurückgeführt werden,
das zur Bedienung der Clients-Anfrage ausgewählt ist. Die Auswahl des Informationsobjekt-Depots,
das eine Kopie eines Objekts enthält, kann entsprechend einem
oder mehreren der spezifizierten Performanzgrößen durchgeführt werden.
-
In
einer weiteren Ausführung
wird ein Kommunikationsprotokoll eine oder mehrere Meldungen, die zwischen
Web-Routern über
ein zuverlässiges Übertragungsprotokoll übertragen
werden, das zur Zwischen-Web-Router-Kompensation verwendet wird. Diese Meldungen
enthalten Information, die erlaubt, dass die Web-Router Mappings
von Client-Adressen oder Adressbereichen für Informationsobjekt-Depot-Adressen basierend
auf spezifizierten Performanzgrößen dynamisch
aktualisiert, und können
auch Mappings von Informationsobjekt-Identifizierern für Informationsobjekt-Depots enthalten,
die lokale Kopien der Informationsobjekte enthalten. Diese Mappings
können
optimale Mappings von Client-Adressen oder Adressbereichen für die Informationsobjekt-Depot-Adressen
sein, und/oder optimale Mappings von Informationsobjekt-Identifizierern für Informationsobjekt-Depot-Adressen.
Die verwendeten spezifizierten Performanzgrößen können eine oder mehrere einer
durchschnittlichen Verzögerung
von einem Informationsobjekt-Depot zu einer gewählten Client-Adresse oder einem
Adressbereich sein, eine durchschnittliche Prozessverzögerung in
einem Informationsobjekt-Depot, Zuverlässigkeit eines Wegs von einem
Informationsobjekt-Depot zu einem Client, verfügbare Bandbreiten in einem
solchen Weg sowie Last an einem Informationsobjekt-Depot sein. Die
Meldungen können
aktualisierte Distanzen von den Informationsobjekt-Depot-Adressen
zu Client-Adressen oder -Adressbereichen melden, wobei diese Distanz
auf den spezifizierten Performanzgrößen beruhen; und/oder aktualisierte Distanzen
von dem Informationsobjekt-Depot-Adressen zu dem Informationsobjekt-Depot-Hosting eines Informationsobjekts
oder Dienstes, wobei diese Distanzen auf den spezifizierten Performanzgrößen beruhen.
-
Auch
können
die Meldungen ferner, für
jede aktualisierte Distanz, eine zugeordnete Client-Adresse oder
Adressbereich melden, und/oder eine zugeordnete Ankeradresse eines
Web-Routers, der gemeinsam mit einem Informationsobjekt-Depot lokalisiert
ist, der das Objekt der Meldung ist.
-
In
einer noch anderen Ausführung
wird eine Adresse eines ein Informationsobjekt suchenden Clients zu
einer oder mehreren Adressen von Informationsobjekt-Depots gemappt,
die eine erstbeste Distanz zu der Clients-Adresse haben, gemäß den spezifizierten
Performanzgrößen, unabhängig davon,
ob die Informationsobjekt-Depots eine lokale Kopie des vom Client
nachgesuchten Informationsobjekt enthalten. Dieses Mapping kann
auch ein Mapping der Adresse des Clients zu einer oder mehreren
Adressen von umleitenden Web-Routern enthalten, die eine zweitbeste
Distanz zu dem Client haben gemäß einigen
oder allen der spezifizierten Performanzgrößen.
-
Die
spezifizierten Performanzgrößen können eine
oder mehrere einer durchschnittlichen Verzögerungen von den Informationsobjekt-Depots
zu den Clients, eine durchschnittliche Prozessverzögerung an
den Informationsobjekt-Depots, Zuverlässigkeit der Wege von den Informationsobjekt-Depots
zu den Clients, verfügbare
Bandbreite in solchen Wegen und Lasten an den Informationsobjekt-Depots
beinhalten. Die Distanzinformation zwischen den Client-Adressen
und den Informationsobjekt-Depots kann gemäß einem ersten Algorithmus
des kürzesten
Wegs berechnet werden, zum Beispiel gemäß Routing-Informationen, die von Internetzwerk-Routern
bereitgestellt werden. Solche Routing-Information kann Inter-Domain-
und Intra-Domain-Routing-Information
enthalten.
-
Eine
noch andere Ausführung
enthält
das Verifizieren von Mapping-Information
zwischen Client-Adressen oder Adressbereichen und einem oder mehreren
Informationsobjekt-Depots, und/oder Mapping-Information zwischen
Informationsobjekt-Depot-Adressen, entsprechend davon, ob eine minimale Sprungdistanz
oder eine andere Art von Distanz zwischen einem Web-Router, der
die Mapping-Informationen enthält,
und einem Web-Router, von dem die Mapping-Information ursprünglich stammt,
endlich ist oder nicht.
-
Die
Mapping-Information kann dann für
zumindest eine der Client-Adressen oder Adressbereiche und/oder
für jeden
bekannten Informationsobjekt-Identifizierer
angewendet werden. Zusätzlich
kann eines der Mapping aus zwei oder mehr gültiger Mappings für zumindest
einen der Client-Adressen oder Adressbereich gemäß dem Typ der Service-Distanz,
die dem Mapping zugeordnet ist, ausgewählt werden. Der Typ der Service-Distanz
kann gemäß den durchschnittlichen
Prozessverzögerungen
an den Informationsobjekt-Depots bestimmt werden, durchschnittlichen
Verzögerungen
von den Informationsobjekt-Depots zu den Client-Adressen oder Adressbereichen,
Zuverlässigkeit
von Wegen zwischen Informationsobjekt-Depots und Client-Adressen
oder Adressbereichen, verfügbarer
Bandbreite in den Wegen und/oder Last an den Informationsobjekt-Depots.
Im Falle von zwei oder mehr gleichartigen Service-Distanzen kann
jene Mapping-Information verwendet werden, die von dem Web-Router
herrührt,
der die kleinste minimale Sprungdistanz zu dem Web-Router hat, der
die Mapping-Information enthält.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Die
vorliegende Erfindung wird als Beispiel und nicht einschränkend in
den Figuren der beigefügten Zeichnungen
veranschaulicht, worin sich gleiche Bezugszeichen auf ähnliche
Elemente beziehen, und worin:
-
1 stellt
ein herkömmliches
Internetzwerk dar, wie etwa das Internet.
-
2 stellt
ein Netzwerk dar, das eine virtuelle Topologie von Web-Routern aufweist,
die gemäß einer Ausführung der
vorliegenden Erfindung konfiguriert sind.
-
3 stellt
ein Beispiel von einer lokalen TOS-Distanz, die von Web-Routern
zu Client-Adressbereichen bekannt ist, von ihren lokalen Web-Caches
oder Inhalts-Servern gemäß einer
Ausführung
der vorliegenden Erfindung dar.
-
4 stellt
ein Beispiel der besten TOS-Distanzen dar, die Web-Routern für einen
bestimmten Client erhalten werden.
-
5a–5d stellen ein Beispiel der vorliegenden
Erfindung dar, wenn ein Web-Router ein WILD-Update von einem benachbarten
Web-Router empfängt.
-
DETAILLIERTE BESCHREIBUNG
-
Hierin
ist ein Schema offenbart, um das Auffinden der Caches und Server
zu ermöglichen,
die Informationsobjekte speichern, die über Computernetzwerke verteilt
sind, welche in Hardware und/oder Software implementiert werden
können.
Insbesondere wird nun ein Verfahren und ein System zum Auffinden
von Informationsobjekten und Servern, die Informationsobjekte speichern,
die über
Computernetzwerke verteilt sind, beschrieben. In der folgenden Beschreibung
werden zahlreiche spezifische Details aufgeführt, um ein gründliches
Verständnis
der vorliegenden Erfindung bereitzustellen. Jedoch versteht es sich
für den
normalen Fachkundigen, dass einige dieser spezifische Details nicht
benutzt werden müssen,
um die vorliegende Erfindung in die Praxis umzusetzen und/oder das Äquivalente
davon verwendet werden können.
In anderen Fällen
sind an sich bekannte Strukturen und Komponenten im Detail nicht
gezeigt worden, um eine unnötige
Verschleierung der vorliegenden Erfindung zu vermeiden. Obwohl in
Bezug auf bestimmte dargestellte Ausführungen diskutiert, wird bei
Durchsicht dieser Beschreibung der normale Fachkundige erkennen,
dass das vorliegende System und die vorliegenden Verfahren in einer
Vielzahl von Systemen Anwendung finden können, und die dargestellten
Ausführungen
daher nur als beispielhaft betrachtet werden sollten und nicht so,
dass sie den Umfang einschränken.
-
Einige
Teile der folgenden Beschreibung sind als Algorithmen und symbolische
Darstellungen von Operationen und Daten innerhalb eines Computerspeichers
(zum Beispiel in einem Pseudo-Code) dargestellt. Diese algorithmischen
Beschreibungen und Darstellungen sind die Mittel, die für den Fachkundigen
in der Computerwissenschaft verwendet werden, um die Substanz ihrer
Arbeit anderen Fachkundigen besonders effizient zu übermitteln.
Ein Algorithmus ist hier allgemein als eine in sich konsistente Sequenz
von Schritten zu verstehen, die zu einem gewünschten Ergebnis führen. Die
Schritte sind jene, die physikalische Manipulationen physikalischer
Größen erfordern.
Gewöhnlich,
obgleich nicht notwendigerweise, nehmen diese Größen die Form elektrischer oder
magnetischer Signale ein, die gespeichert, übermittelt, kombiniert, verglichen
oder anderweitig manipuliert werden können. Es hat sich derzeit als
praktisch erwiesen, grundsätzlich
aus Gründen des
allgemeinen Gebrauchs, diese Signale als Bits, Werte, Elemente,
Symbole, Schriftzeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen.
Man sollte sich jedoch daran erinnern, dass alle diese und ähnliche
Begriffe den entsprechenden physikalischen Größen zuzuordnen sind und sie
lediglich praktische Kennungen sind, die auf diese Größen angewendet
werden. Solange nicht anderweitig angegeben, versteht es sich, dass in
der gesamten Beschreibung der vorliegenden Erfindung der Gebrauch
von Begriffen wie etwa „Verarbeiten", „Berechnen", „Errechnen", „Bestimmen", „Darstellen" oder dergleichen
sich auf die Wirkung und die Prozesse eines Computersystems bezieht
oder eine ähnliche
elektronische Rechenvorrichtung, die Daten, die als physikalische
(elektronische) Größen repräsentiert
sind, innerhalb der Register des Computersystems und den Speichern,
manipuliert und in andere Daten transformiert, die ähnlich als
physikalische Größen in den
Computersystemspeichern oder -registern oder anderen solchen Informationsspeicher-Übertragungs-
oder Displayvorrichtungen repräsentiert
sind.
-
Aus
der obigen Beschreibung der herkömmlichen
Technik sollte es sich verstehen, dass keines der herkömmlichen
Schemata inkomplett skalierbarer Art und in einer Weise, die für die Clients
vollständig
transparent ist, vorsehen: (a) die beste Übereinstimmung zwischen den
Adressen eines Clients und dem Satz von Web-Caches, Hosting-Server
oder Inhalts-Servern,
die den Client mit vom Client angeforderten Objekten beliefern können; und
(b) die beste Übereinstimmung
zwischen einem Web-Cache oder Hosting-Server, der einem Client dienen
sollte und dem Web-Cache, Hosting-Server oder Inhalts-Server, der
gegenwärtig
das Informationsobjekt oder den Dienst, der vom Client angefordert
wird, wählt.
Die vorliegende Erfindung strebt danach, diese Nachteile des Stands
der Technik zu überwinden.
-
Gemäß einer
Ausführung
der vorliegenden Erfindung wird eine Sammlung von einem oder mehreren „Web-Routern" benutzt, um eine
Anfrage nach einem Objekt auf ein Web-Cache oder einen Inhalts-Server
zu beziehen, der in der Lage ist, das angeforderte Objekt zu dem
Zielclient zu übertragen,
während
ein gegebener Satz von Performanzgrößen erfüllt wird. Hierin wird der Begriff
Web-Router so benutzt, dass er sich auf eine Ausführung (die
in Hardware und/oder Software zur Ausführung durch ein Computersystem
implementiert sein kann) eines Computersystems bezieht, das gemäß den Methoden
(nachfolgend beschrieben) konfiguriert ist, die erforderlich sind,
um die Adresse eines Clients mit der Adresse eines Web-Caches zu
mappen, das die angeforderten Informationsobjekte optimal zu dem
Client liefern kann. Die Performanzgrößen, die von Web-Routern zum
Auswählen
der Sites (Web-Cache oder Inhalts-Server) verwendet wird, die die
angeforderten Objekte zu den Clients liefern sollen, können Netzwerkverzögerungen,
verfügbare
Bandbreite, Zuverlässigkeit
von Wegen von den gewählten
Sites zu den Ziel-Sites, und Belastungen an den Web-Caches und Inhalts-Servern
beinhalten. Das Verfahren, das zum Auswählen der besten Stelle verwendet
wird, von der Informationsobjekte abgefragt werden sollte, ist für die Clients
transparent, und das Computernetzwerk oder Internetzwerk, über das
das System arbeitet, braucht eine Multicast-Lieferung zu den Endbenutzer-Sites nicht
zu unterstützen.
-
Ein
System gemäß einer
Ausführung
der vorliegenden Erfindung enthält
einen oder mehrere Client-Knoten, einen Satz von einem oder mehreren
Webservern, einen oder mehrere original-Inhalts-Servern, einen Satz
von einem oder mehreren Web-Caches, Hosting-Server oder Proxy-Server,
die Replika von Informationsobjekten speichern, sowie einen Satz
von einem oder mehreren Web-Routern. Ein Web-Router kann gemeinsam
mit einem Webserver, einem Web-Cache, einem Hosting-Server oder
einem Original- Inhalt-Server
angeordnet sein. Eine Topologie von Web-Routern ist derart definiert,
dass ein gegebener Web-Router als seine benachbarten Web-Router einen Untersatz
von allen Web-Routern in dem System hat. Ein Web-Router kommuniziert direkt mit seinem
benachbarten Web-Router und bevorzugt nicht mit anderen Web-Routern.
-
In
einer Ausführung
der vorliegenden Erfindung wird ein Web-Router gemäß einem
Schema kontaktiert, um das Auffinden der Caches und Server zu ermöglichen,
die Informationsobjekte speichern, die über Computernetzwerke verteilt
sind, welche in Hardware und/oder Software implementiert werden
können,
von einem Client, einem Webserver, einem Web-Cache oder einem anderen
Servertyp mit einer Anfrage nach der Adresse eines oder mehrerer
Web-Caches, die ein Client kontaktieren sollte, um ein Informationsobjekt
zu erhalten.
-
In
einer weiteren Ausführung
der vorliegenden Erfindung implementieren Web-Router einen verteilten Algorithmus
und führen
ein Kommunikationsprotokoll aus, mit dem jeder Web-Router bestimmt:
(a) die Adresse von einem oder mehreren Web-Caches, woraus Informationsobjekte
von einem Client abgefragt werden können, während ein Satz von Type-of-Service
(TOS)-Perfomanz-Parametern erfüllt
ist, und (b) Adresse von einem oder mehreren Web-Caches, die Informationsobjekte
speichern, von denen solche Objekte von anderen Web-Caches zu Service-Client-Anfragen nach
solchen Informationsobjekten abgefragt werden können. Die verwendeten TOS-Parameter
beinhalten – sind
jedoch nicht beschränkt
auf – die
durchschnittliche Verzögerung
in einem Cache oder Inhalts-Server zu dem Client, die durchschnittlichen
Prozessverzögerungen
an der Site, an der das Objekt abgefragt werden würde, die
Zuverlässigkeit
des Wegs von dieser Site zu dem Client und die verfügbare Bandbreite
in diesem Weg. Der Wert der TOS-Parameter des Wegs von einem Server oder
Web-Cache zu einem Client wird auch TOS-Distanz eines solchen Servers
oder Web-Caches zu dem Client genannt. Dementsprechend hält ein gegebener
Web-Router für
jeden Adressbereich, der einem Satz potentieller Clients entspricht,
die Adresse von einem oder mehreren Web-Caches, Proxys oder Inhalts-Servern, die
die beste TOS-Distanz zu der Client-Adresse haben, und den Wert
einer solchen TOS-Distanz.
-
1 stellt
ein Internetzwerk 100 dar. Die hierin beschriebenen Methoden
und Systeme, die in Software und/oder Hardware implementiert werden
können,
ermöglichen
das Auffinden entweder von Informationsobjekten oder der Caches
und Server, die Informationsobjekte speichern, die über Computernetzwerke verteilt
sind, wie etwa in dieser Darstellung das Internetzwerk 100.
Ein Beispiel eines Internetzwerks 100 ist das Internet.
Andere Beispiele beinhalten Enterprise-Netzwerke, örtliche
Netzwerke, Weitbereichs-Netzwerke, städtische Netzwerke und Netzwerke
solcher Netzwerke. Für
den Fall, wo das Internetzwerk 100 Internet ist, werden
Clients 105 allgemein durch eine Serie von Netzwerken,
die von verschiedenen Providern betrieben werden, auf Inhalt zugreifen,
der an entfernten Servern 150 angeordnet ist. Zum Beispiel
können
Clients 105 Konten mit örtlichen
Internet-Service-Providern (ISPs) 110 haben, die dem Clients
einen Verbindung mit dem Internet ermöglichen, unter Verwendung konventioneller
Hochwähl-
oder einer einer Vielzahl von Hochgeschwindigkeitsverbindungen (zum
Beispiel DSL-Verbindungen, Kabelverbindungen, Hybride, die Satelliten und
Hochwählverbindungen
beinhalten, etc.). ISPs 110 können wiederum direkte Verbindungen
zum Internet vorsehen oder können,
wie gezeigt, auf anderen Service-Providern 120, 130, 140 beruhen,
um Verbindungen durch einen Satz von Hochgeschwindigkeitsverbindungen
zwischen Computer-Ressourcen vorzusehen, was als Rückgrat 150 bekannt
ist. Die Verbindung eines Hosts (zum Beispiel eines Servers 150 kann
somit eine Verbindung durch Netzwerke beinhalten, die von einer
Vielzahl von Service-Providern betrieben werden.
-
2 stellt
ein virtuelles Netzwerk von Web-Routern 201, 202, 205, 210, 220, 230, 240 und 250 dar, die
oben auf der physikalischen Topologie eines Internetzwerks wie etwa
das Internet definiert sind, bestehend aus Routern, die über Punkt-zu-Punkt-Links
oder Netzwerke miteinander verbunden sind. Das virtuelle Netzwerk
von Web-Routern enthält
Punkt-zu-Punkt-Links, die zwischen den Web-Routern konfiguriert
sind, um den Links, die zwischen einem Web-Router und einem oder
mehreren Web-Caches (zum Beispiel dem Web-Cache 310) und
Inhalts-Servern konfiguriert sind. Solche Links können mittels
Tunneln zwischen Web-Routern und zwischen Web-Caches implementiert
werden. Der hierin benutzte Begriff „Inhalts-Server" bedeutet die Angabe
eines Servers, der als der Ursprungspunkt für ein Stück Inhalt (zum Beispiel Text,
Video, Audio etc.) dient. Solcher Inhalt kann anschließend von
einem oder mehreren Web-Caches repliziert werden. Wie in der Figur gezeigt,
ist ein Client 101 nicht notwendigerweise Teil des virtuellen
Netzwerks von Web-Routern.
-
Wie
oben angegeben, ist ein Web-Router eine Ausführung der Methoden, die hierin
beschrieben sind, zum Auffinden von Informationsobjekten und Objektablagen
im Computernetzwerk. Die Funktionalität eines Web-Routers kann als
Teil eines Web-Caches implementiert sein, als Teil eines Routers
oder als separate Einheit. Um diese Beschreibung zu vereinfachen,
wird hierin der Web-Router als separate Einheit von einem Web-Cache
oder einem Router beschrieben und behandelt.
-
Ein
Web-Router kann mit einem Webserver einem Web-Cache oder einem Ursprung-Inhalts-Server gemeinsam
angeordnet sein. In einer Ausführung
der vorliegenden Erfindung kann ein Web-Router in Software implementiert
sein, die von einem Mehrzweck-(oder Sonderzweck-)Computerprozessor
auszuführen
ist, oder kann als Teil der Software eines Routers oder Web-Caches implementiert
sein. In einer anderen Ausführung
der vorliegenden Erfindung kann ein Teil oder die gesamte Funktionalität des Web-Routers
in Hardware implementiert sein.
-
In
einer Ausführung
der vorliegenden Erfindung wird eine Ansammlung von einem oder mehreren Web-Routern
in Bezug auf die Anfrage nach einem Objekt zu einem Web-Cache oder
Inhalts-Server benutzt, der in der Lage ist, das angeforderte Objekt
zu dem Ziel-Client zu überführen, während ein
gegebener Satz von TOS-Parametern erfüllt wird, wie etwa Netzwerk-Verzögerungen,
verfügbare
Bandbreite, Zuverlässigkeit von
Wegen von den gewesenen Orten zu den Ziel-Clients, und Belastungen
an den Web-Caches und Inhalts-Servern. Die Methode, die zum Auswählen der
besten Sites verwendet wird, von der Informationsobjekte durch User-Sites
(Clients) abgefragt werden werden sollten, ist für die User-Sites transparent,
und das Computernetzwerk oder Internetzwerk, über das das System hinweg arbeitet,
braucht eine Multicast-Ausgabe zu Endbenutzer-Sites nicht zu unterstützen.
-
Um
Kommunikations- und Prozessüberlastung
in Web-Routern zu reduzieren, ist eine Topologie von Web-Routern
derart definiert, dass ein gegebener Web-Router als seinem benachbarten
Web-Router einen Teilsatz aller Web-Router in dem System aufweist,
wobei sich der Begriff System auf alle oder einen teil des virtuellen
Netzwerks für
die oben diskutierten Web-Router
bezieht. Ein Web-Router kann seinem Satz von benachbarten Web-Routern konfigurieren.
Eine solche Konfiguration kann eine Tabelle von benachbarten Web-Routern
sein, die durch einen Netzwerk-Service-Provider definiert und/oder
dynamisch aktualisiert wird. In einer anderen Ausführung der
vorliegenden Erfindung wählt
ein Web-Router den Satz von benachbarten Web-Routern, mit dem, der
kommunizieren sollte, aus allen Web-Routern in dem System dynamisch
aus. Ein Web-Router kommuniziert bevorzugt nur mit seinen benachbarten
Web-Router und verwendet für
diesen Zweck das Web-Information-Locator-by-Distance (WILD)-Protokoll.
Das WILD-Protokoll ist in der mitanhängigen US-Anmeldung Nr. 60/200401
des gemeinsamen Anmelders offenbart, mit dem Titel „System
and Method for Discovering Optimal Information Objects Repositories
in Computer Networks (WILD Protocol)", eingereicht am 28. April 2000 von
J. J. Garcia-Luna-Aceves
und Bradley R. Smith, deren vollständige Offenbarung hierdurch
unter Bezugnahme aufgenommen wird.
-
In
einer Ausführung
der vorliegenden Erfindung läuft
WILD oben auf dem Transmission Control Protocol (TCP) weitgehend
genauso wie das Border Gateway Protocol (BGP); in diesem Fall existiert
eine TCP-Verbindung zwischen einem Web-Router und jedem seiner benachbarten
Web-Router. In einer anderen Ausführung der vorliegenden Erfindung
kann WILD oben auf dem TCP-Santa-Cruz-Protokoll laufen (C. Parsa und
J. J. Garcia-Luna-Aceves, „Improving
TCP Congestion Control Over Internets with Heterogeneous Transmission
Media", Proc. IEEE
ICNP 99), bestehend aus einer TCP-Option, die die verfügbare Bandbreite
zwischen Web-Routern effizienter nutzt. In einer noch anderen Ausführung der
vorliegenden Erfindung läuft
weit oben auf einem zuverlässigen Übertragungsprotokoll,
das wiederum oben auf dem User Datagram Protocol (UDP) läuft. Andere
Ausführungen
der vorliegenden Erfindung können
auf alternativen Protokollen beruhen, um für zuverlässige Übertragungen zwischen Web-Routern zu sorgen.
-
In
einem Beispiel des Betriebs eines Systems, das eine Ausführung der
vorliegenden Erfindung verwendet, kontaktiert ein Client zuerst
einen Webserver, der eine Web-Page anfordert, worin ein Satz von
Informationsobjekten unter ihren URLs referenziert sind. Der Webserver
kann wiederum einen Web-Router kontaktieren, um die Sites zu bestimmen
(zum Beispiel einen oder mehrere Web-Caches oder einen Ursprungsinhalt-Server,
von denen jeder allgemein als Informationsobjekt-Depot bezeichnet
werden kann), wovon jedes solches Informationsobjekt abgefragt werden
sollte. In Abhängigkeit
von der Implementierung kann ein Web-Router von einem Client, einem Web-Cache,
einem Inhalts-Server oder einem anderen Server-Typ kontaktiert werden
(zum Beispiel Webserver 401 oder 402), der nach
der Adresse eines Web-Caches, Satz von Web-Caches oder eines Inhalts-Servers
fragt, den ein Client kontaktieren sollte, zu dem Zweck, Informationsobjekte
abzufragen. Im vorliegenden Beispiel beliefert der Webserver den
Web-Router mit der Adresse des Clients, der den Satz von Objekten
anfordert, eine URL für
jedes Informationsobjekt, das von dem Client angefordert wird, und
einen Satz von TOS-Parametern, mit denen die Anfrage dem Client übermittelt
werden soll. Es wird angenommen, dass das Fehlen von TOS-Parametern
eine Service-Anfrage mit minimaler Verzögerung implementiert.
-
Der
Web-Router mappt jedes URL, das von dem Webserver geliefert wird,
zu der Adresse eines Web-Caches oder dem Inhalts-Server, der das
zugeordnete Informationsobjekt zu dem Client liefern kann, optimal
entsprechend den spezifizierten TOS-Parametern. Dieses Mapping von
URLs zu Adressen von Web-Caches oder Inhalts-Servern wird durch
Zusammenarbeit zwischen den Web-Routern durch WILD erreicht. Dementsprechend
kann der von dem Webserver kontaktiert Web-Router die angeforderten
Adressen unmittelbar nach Bearbeitung der Anfrage zurücksenden.
Der Webserver wiederum sendet eine Webpage zu dem anfragenden Client
zurück,
der ein URL für
jedes Informationsobjekt enthält,
das zu dem Web-Cache oder Inhalts-Server zeigt, der das Informationsobjekt
zu dem Client liefern kann, während
die TOS-Parameter erfüllt werden,
die in der Anfrage des Clients explizit oder implizit spezifiziert
sind. Der Client ist dann in der Lage, die in der Web-Site referenzierten
Informationsobjekte direkt von einem Web-Cache, Proxy- oder Inhalts-Server abzufragen,
der den besten TOS-Weg zum Client hat. In anderen Ausführungen
kann der Web-Router eine Anfrage von einem Client, einem Cache,
einem Webserver, einem anderen Web-Router, einem Namen-Server oder einem
anderen Servertyp empfangen, und die Adresse des Clients und die
TOS-Performanz-Parameter verwenden, die in der Anfrage spezifiziert
sind, um die Adresse eines Web-Caches, eines Satzes von Web-Caches, eines Inhalts-Servers
oder Web-Routers zu erhalten (das heißt ein Informationsobjekt-Depot),
das dem Client optimal entsprechend den spezifizierten TOS-Performanz-Parametern
bedienen sollte.
-
Wenn
in einer Ausführung
der Web-Router die Adresse des Clients, der den Ort der Informationsobjekte
anfragt, zu Adressen von Web-Caches mappt, die gegenwärtig diese
Objekte nicht speichern, kann der Web-Router die entsprechenden
Web-Caches anfragen, um eine Kopie der angeforderten Objekte zu
erhalten, unmittelbar nachdem er dem anfordernden Webserver Adressen
eines solchen Web-Caches oder Proxys mitteilt. In einer anderen
Ausführung
versucht ein Web-Cache oder Proxy, ein angefordertes Objekt von
einem anderen Web-Cache oder einem Inhalts-Server nur dann abzufragen,
nachdem er von einem Client kontaktiert wurde, und bestimmt, dass
eine Kopie des angeforderten Informationsobjekts örtlich nicht
zur Verfügung
steht. In beiden Fällen
beliefert der Web-Router das Web-Cache, das eine Client-Anfrage
bedient, mit der Adresse des „nächsten" Web-Caches, das das vom
Client angeforderte Informationsobjekt speichert. Daher kommuniziert
das Web-Cache, das das Informationsobjekt benötigt, direkt mit dem Web-Cache,
das angeforderte Informationsobjekt speichert, ohne durch irgendwelche
zwischenliegenden Web-Caches hindurchgehen zu müssen und ohne den Inhalt kennen
zu müssen,
der in allen anderen Web-Caches gespeichert ist, wie dies im Stand
der Technik üblich
ist.
-
Aufbauend
auf dem oben Stehenden ist der Web-Router verantwortlich für die Bestimmung,
welches einer Anzahl verfügbarer
Informationsobjekt-Depots
einen Client bedienen sollte (das heißt, einen Client oder eine
Webserver-Anfrage nach einem Informationsobjekt oder Dienst). Der
Web-Router bestimmt
auch das Informationsobjekt-Depot, das das so angeforderte Informationsobjekt
oder den Dienst aktuell hält,
und initiiert den Prozess, um das Informationsobjekt oder den Dienst
zu dem Informationsobjekt-Depot zu überbringen, das den Client
bedienen sollte. Das Überbringen
des Informationsobjekts oder Dienstes, das von dem Clients angefordert
wurde, zu dem Informationsobjekt-Depot, von dem bestimmt worden
ist, dass es die Client-Anfrage bedienen sollte, wird in einer Ausführung dadurch
erreicht, dass ein Informationsobjekt-Depot, das die Anfrage bedienen
soll, angewiesen wird, das Informationsobjekt oder den Dienst, der
von dem Client angefragt wird, von dem Informationsobjekt-Depot abzufragen,
das aktuell das Informationsobjekt oder den Dienst enthält. Danach
kontaktiert, bei Anfrage einer Anweisung, es zu tun, das Informationsobjekt-Depot,
von dem bestimmt worden ist, dass es die Clientsanfrage bedienen
soll, das Informationsobjekt-Depot, das das Informationsobjekt oder
den Dienst, der vom Client angefragt wurde, aktuell enthält, direkt
zur Anforderung des Informationsobjekts oder Dienstes.
-
In
einer weiteren Ausführung
wird oder kann einer der folgenden vier Mechanismen oder eine Kombination
einiger der folgenden vier Mechanismen dazu benutzt werden, um das
beste Web-Cache oder den Inhalts-Server oder den Satz von Web-Caches,
die eine Anfrage von einem Client bedienen sollten, zu kommunizieren:
- (1) direkte Cache-Auswahl;
- (2) Umleitungs-Cache-Auswahl;
- (3) entfernte DNS-Cache-Auswahl; und
- (4) Client-DNS-Cache-Auswahl.
-
Diese
Ansätze
sind in der mitanhängigen
US-Anmeldung Nr. 60/2004404 des gleichen Anmelders offenbart, mit
dem Titel „System
and Method for Using a Mapping Between Client Addresses and Addresses
of Caches to Support Content Delivery", eingereicht am 28. April 2000 von
J. J. Garcia-Luna-Aceves
und Bradley R. Smith, deren komplette Offenbarung hierdurch unter
Bezugnahme aufgenommen wird.
-
Jene
Web-Router, die zum Umleiten von Clients zu geeigneten Web-Caches
oder Inhalts-Servern verwendet werden, müssen in einer sehr fehlertoleranten
Weise implementiert sein und müssen über das
gesamte System gut bekannt sein. Dementsprechend werden in einer
Ausführung
der vorliegenden Erfindung nicht alle Web-Router in einem System
zur Client-Umleitung
verwendet, um die Kosten von Web-Routern und die Kommunikationsüberlastung
zu reduzieren, die mit der Kenntnis über das Vorhandensein von Web-Routern einhergeht,
die in der Lage sind, Clients zu Web-Caches und Inhalts-Servern
umzuleiten. In einem solchen System ist ein Satz umleitender Web-Router
definiert; der Satz umleitender Web-Router ist allen Web-Routern des Systems
bekannt, während
ein Web-Router,
der nicht als umleitender Web-Router dient, nicht allen Web-Routern
des Systems bekannt zu sein braucht.
-
Allgemein
führen
Web-Router WILD aus, um die Adresse eines Clients zum Mappen in
(a) eine oder mehrere Adressen von Web-Caches oder des Inhalts-Servers,
der die beste TOS-Distanz zu der Client-Adresse aufweist, und (b)
eine oder mehrere Adressen von umleitenden Web-Routern, die die
beste TOS-Distanz zu der Client-Adresse haben. Dieses Mapping erfolgt
unabhängig
davon, ob die Web-Caches oder Inhalts-Server eine lokale Kopie eines
der vom Client angeforderten Informationsobjekte enthält. Web-Router führen WILD
auch dazu aus, um den Identifizierer eines Informationsobjekts zu
Mappen in: (a) eine oder mehrere Adressen von Web-Caches oder Inhalts-Servers,
der das Informationsobjekt speichert und den Web-Routern gemäß TOS-Parametern
am nächsten
ist. Ein gegebener Web-Router hält
somit:
- • Für jede Adresse
und/oder jeden Adressbereich entsprechend einem Satz potentieller
Clients, die Adresse eines Web-Caches, Proxy, Inhalts-Servers und/oder
umleitenden Web-Routers, der die beste TOS-Distanz zu der Client-Adresse
hat, sowie den Wert einer solchen TOS-Distanz;
- • Für jedes
Informationsobjekt die Adresse eines Web-Caches, Proxys oder Inhalts-Servers,
der die beste TOS-Distanz zu dem Web-Router hat.
-
In
einer Ausführung
der vorliegenden Erfindung beliefern die Internet-Router des Systems
Web-Router mit Distanzen zu bekannten Zieladressen, die gemäß einer
Anzahl von Netzwerk-Performanz-Parametern gemessen werden. Ein Web-Router,
der gemeinsam mit einem Web-Cache oder Inhalts-Server lokalisiert
ist, verwendet die von benachbarten Routern erhaltene Information
und die Performanzgröße des Web-Caches oder
Inhalts-Servers, um die TOS-Distanz von dem ko-lokalisierten Web-Cache
oder Inhalts-Server zu jedem bekannten Zielort, der potentiellen
Client-Adressen
entspricht, herzuleiten. In einer Ausführung der vorliegenden Erfindung
verwenden Web-Router Routing-Information, die vom Border Gateway
Protocol (BGP) und einem der Intradomain-Routing-Protokolle (zum
Beispiel USPF, EIGRP) geliefert werden, die in Routern laufen, die
an den gleichen Ortsbereichsnetzwerken angeschlossen sind, wo sich
die Web-Router befinden,
um Distanzen zu Client-Adressbereichen herzuleiten.
-
Der
spezifische Algorithmus, den ein Web-Router zum Berechnen der TOS-Distanz von jedem
lokalen Web-Cache zu einem Client-Adressbereich ausführt, ist
von Routing-Information abhängig,
die der angeschlossene Router dem Web-Router zur Verfügung stellt.
Jeder Router kann mit Interdomain- und Intradomain-Routing-Information
beliefert werden, die zu allen genannten Client-Adressbereichen
gehört;
alternativ kann nur ein Teilsatz von Web-Routern Interdomain-Routing-Information
direkt von einem oder mehreren Routern empfangen, die sich in dem
gleichen Netzwerk wie der Web-Router befinden. In jedem Fall führt ein Web-Router
einen Weg-Auswahl-Algorithmus
aus, wie etwa den ersten Kürzester-Weg-Algorithmus
von Dijkstra, um die örtliche
TOS-Distanz von den angeschlossenen Web-Caches zu jedem Client-Adressbereich
zu berechnen, wenn der Web-Router vollständige Intradomain- und Interdomain-Routing-Daten
aufweist, oder zu jedem Client-Adressbereich in dem örtlichen
autonomen System, wenn der Web-Router nur Intradomain-Routing-Daten
aufweist. Ein Web-Router kann einen unterschiedlichen Weg-Auswahl-Algorithmus
ausführen,
um örtliche
TOS-Distanzen zu Adressbereichen für jedes in dem System definierte
TOS zu berechnen.
-
Unter
Verwendung der gleichen virtuellen Topologie von Web-Routern, die
in 2 eingeführt
werden, stellt 3 ein Beispiel der örtlichen
TOS-Distanz, die
Web-Routern bekannt sind, zu Client-Adressbereichen von ihren Web-Caches
oder Inhalts-Servern dar. In der Figur ist eine einzelne TOS-Distanz angegeben.
Die in Klammern gesetzten Zahlen bezeichnen die TOS-Distanz von
einem Web-Cache oder Inhalts-Server zu dem Client 101.
Die gestrichelten Linien geben an, dass die örtliche TOS-Distanz zum Client 101,
die an einem Web-Router gespeichert ist, der Belastung eines örtlichen Web-Caches
oder Inhalts-Servers und der Verstopfung im Weg von dem Web-Cache
oder Inhalts-Server zum Client 101 entspricht. Zum Beispiel
ist die örtliche TOS-Distanz
zum Client 101, die vom Web-Router 201 gespeichert
ist, 20, und entspricht der TOS-Distanz von dem Web-Cache 301 zum
Client 101.
-
Indem
nun die örtlichen
TOS-Distanzen von den angeschlossenen Web-Caches zu allen oder einem Teilsatz
von Client-Adressbereichen berechnet ist, verwendet ein Web-Router
diese Information zu Berechnen der besten Übereinstimmung zwischen einem
Client-Adressbereich und dem Satz von Web-Caches, die dem Clients-Adressbereich
bedienen sollten, weil sie die beste TOS-Distanz zu dem Client haben.
Um diesen Prozess zu erreichen, hält, für jede bekannte Zieladresse
und für
jedes in dem System definierte TOS, ein Web-Router einen Satz von
einem oder mehreren Adressen der Web-Caches oder Inhalts-Server,
die besten TOS-Distanzen zu der Ziel-Adresse haben, sowie den Wert dieser
Distanzen, sowie auch die Adresse von einem oder mehreren Web-Routern,
die dazu benutzt werden können,
Anfragen von Clients in den Adressbereich umzuleiten und dem Wert
der Distanzen von den umleitenden Web-Routern zu dem Client-Adressbereich.
-
Der
spezifische Algorithmus, den ein Web-Router ausführt, um die Distanz zu dem
nächsten
Web-Cache zu berechnen, das eine Kopie eines Informationsobjekts
speichert, ist von der Routing-Information abhängig, die die Web-Router nutzen,
um Distanzen zu anderen Web-Routern zu berechnen, die mit den Informationsobjekten
speichernden Web-Caches gemeinsam lokalisiert sind. Ein Web-Router
wird aus örtlichen Web-Caches über die
Belastung der Web-Caches und die in den Web-Caches gespeicherten
Objekte informiert. Daher weiß ein
Web-Router, dass seine Distanz zu in örtlichen Web-Caches gespeicherten
Informationsobjekten die Latenz ist, die beim Erhalt dieser Objekte
von den örtlichen
Web-Caches auftritt, was eine direkte Funktion der Belastung in
diesen Web-Caches ist. Wenn man annimmt, dass ein Web-Router einen
Routing-Algorithmus ausführt,
der es dem Web-Router ermöglicht,
seine eigene Distanz zu anderen Web-Routern zu erkennen, wählt ein
Web-Router das nächste
Web-Cache, das eine Kopie eines Informationsobjekts speichert, durch
Vergleich der örtlichen
Distanz zu dem Informationsobjekt (dies ist die Latenz, die bei
einem örtlichen
Web-Cache auftritt, wenn das Objekt lokal gespeichert ist, oder
unendlich, wenn das Objekt nicht lokal gespeichert ist) mit den
gemeldeten Übereinstimmungen
von Objekt-Identifizieren zu Web-Caches,
denen von ihren benachbarten Web-Routern berichtet wird. Die Objekt-Cache-Übereinstimmungsmeldung
für ein
gegebenes Informationsobjekt spezifiziert den Informationsobjekt-Identifzierer,
das Web-Cache, wo
das Informationsobjekt gespeichert ist, den Web-Router, der zu diesem
Web-Cache örtlich
ist, und die Distanz zu dem Web-Cache. Die in den Objekt-Cache-Übereinstimmungsbericht
spezifizierte Distanz enthält
explizit oder implizit die Distanz von dem benachbarten Web-Router
zu dem im Bericht spezifizierten Web-Cache, plus der Belastung des
in dem Bericht spezifizierten Web-Caches. Der Web-Router wählt dann
eine Passung des Informationsobjekts zu dem Web-Cache, das die minimale
Distanz zu dem das Objekt speichernden Web-Cache produziert.
-
Die
Gültigkeit
der Information, die für
Passungen zwischen Clients und Web-Caches und Informationsobjekten und
Web-Caches kommuniziert wird, kann auf verschiedene Weisen überprüft werden.
In einer bevorzugten Ausführung
der vorliegenden Erfindung wird die Gültigkeit des Mappings zwischen
einem Client-Adressbereich und den Adressen von Web-Caches und umlenkenden
Web-Routern, oder des Mappings zwischen dem Informationsobjekt-Identifizierer
und einem objektspeichernden Web-Cache unter Verwendung der Adressen
und minimalen Sprungdistanzen zu den Web-Routern, von denen die
Information herrührt,
etabliert. Ein Web-Router, der ein Mapping zwischen einem Client-Adressbereich
und den Adressen von einem oder mehreren Web-Caches und umliegenden
Web-Routern empfängt,
akzeptiert die Mapping-Information als gültig, wenn die minimale Sprungdistanz
zu dem Web-Router, von dem die Mapping-Information gestammt hat, endlich
ist. Ein Web-Router, der zwei gültige
Mappings für
den gleichen Client-Adressbereich empfängt, verwendet das Mapping,
das die besten TOS-Distanzen meldet, und im Falle von Verknüpfungen
in TOS-Distanzen,
verwendet der Web-Router das Mapping, das von jenem Web-Router stammt, zu
dem er die kleinste minimale Sprungdistanz hat. Der Web-Router,
von dem die Mapping-Information für einen gegebenen Client-Adressbereich oder
ein Informationsobjekt stammt, wird Anker des Mappings genannt,
und es soll das Mapping für
den Web-Router, das die Information enthält, verankern.
-
Der
Web-Router meldet seinen benachbarten Web-Routern Updates, die entweder
an der Adresse des oder der Web-Caches, umleitender Web-Router oder zugeordnet
zu dessen TOS-Distanz für
Vieladressbereiche von Clients gemacht wurden. Der Web-Router meldet
auch seinen benachbarten Web-Routern Updates, die entweder an Adressen
von Web-Caches oder der zugeordneten besten TOS-Distanz für Informationsobjekt-Identifizierer
gemacht wurde.
-
Für jede bekannte
Zieladresse und für
jedes im System definierte TOS hält
der Web-Router auch die Information, die jedem benachbarten Web-Router
gemeldet werden: (a) die Adresse des Web-Caches-Inhalts-Servers
oder Satzes von Web-Caches und die beste TOS-Distanz von jedem solchen
Web-Cache oder Server zu dem Client-Adressbereich, und (b) die Adresse
des umleitenden Web-Routers oder Satzes von Web-Routern und die
beste TOS-Distanz von diese, Web-Router(n) zu dem Client-Adressbereich.
-
Für jeden
bekannten Informationsobjekt-Identifizierer hält der Web-Router die folgende
Information, die jedem benachbarten Web-Router gemeldet wird: (a)
die Adresse des das Objekt speichernden Web-Caches, (b) die Adresse
des Web-Routers, von dem die Passung stammt, (c) die TOS-Distanz zu dem Web-Cache,
das das Informationsobjekt speichert.
-
Ein
Web-Router wählt
den Satz von Web-Caches und Inhalts-Servern und den Satz von umleitenden Web-Routern,
die die besten TOS-Distanzen jedem Client-Adressbereich haben, derart,
dass eine mangelnde Aktualität oder
irrtümliche
Information über
TOS-Distanzen von Web-Caches oder Web-Routern zum Bestimmungsort
rasch gelöscht
wird, um irrtümliche
Bezugnahme oder einen schlechten Lastausgleich und Reaktionszeiten
zu vermeiden.
-
In
einer Ausführung
der vorliegenden Erfindung schicken Web-Router einander die TOS-Distanz-Information
von ihren benachbarten Web-Caches und Inhalts-Servern zu allen Client-Adressbreichen.
Dieser Ansatz gestattet es den Web-Routern, die beste Passung (das
heißt,
Web-Cache und umleitender Web-Router) für jeden Adressbereich zu berechnen),
können
aber eine wesentliche Überlastung
vermeiden, weil der Web-Router dazu zwingt, das Vorhandensein aller
Web-Caches und Web-Router in dem System zu kennen. Um den Kommunikations-
und Speicherüberhang
zu reduzieren, die beim Replizieren dieser Information an jedem
Web-Router auftritt, halten, in einer bevorzugte Ausführung der
vorliegenden Erfindung, Web-Router die minimale Sprungdistanz zu
jedem Web-Router, der kontaktiert werden kann, um Clients umzuleiten,
und zu jedem Web-Router, der mit einem Web-Cache ko-lokalisiert,
der die beste TOS-Distanz zu einem Satz von Client-Zielen hat. Die
minimalen Sprung-Distanzen zu Web-Routern werden mittels eines Routing-Algorithmus als
Teil von WILD gehalten. Der Routing-Algorithmus, der zu diesem Zweck
benutzt wird, kann einer der Routing-Algorithmen sein, die im Stand
der Technik für
das traditionelle Internet und Routing auf Netzwerkebene berechnet
worden sind; das einzige Erfordernis für den in WILD verwendeten Routing-Algorithmus
ist, dass der Routing-Algorithmus permanente oder langdauernde Routing-Tabellenschleifen
vermeidet. Zum Beispiel verwendet eine bevorzugte Ausführung der
vorliegenden Erfindung einen der folgenden Mechanismen, Routing-Algorithmen
und Protokollen als Teil von WILD:
- 1. Verteilender
Aktualisierungs-Algorithmus (DUAL), der die Basis für Cisco's EIGRP ist
- 2. Schleifenfreier Wegfinder-Algorithmus (LPA)
- 3. Link-Vektor Algorithmus (LVA)
- 4. Bandbreiteneffizientes Quellenbaum (BEST)-Protokoll
- 5. Dynamisches Quellenbaum (DST)-Routing-Protokoll
- 6. Verteilender Algorithmus für kürzeste Mehrfachwege (DASM)
- 7. Mehrfachweg-Distanz-Vektor (MDVA)
- 8. Azyklisches bedarfsweises Routing-Mehrfachweg (ROAM)-Protokoll
- 9. Mehrfachweg-Disseminations-Algorithmus mit partieller Topologie
(MPDA)
- 10. Schleifenfreier Mehrfachweg-Routing-Algorithmus (MAPTH)
- 11. Adaptives Link-Zustand-Protokoll (ALP)
- 12. Topologie-Rundsende-Protokoll, wie etwa dasjenige, das in
dem Open-Shortest-Path-First-Protokoll (OSPF) implementiert ist
- 13. Weg-Vektor-Algorithmus, der als Teil des Border-Gateway-Protokoll
(BGP) verwendet wird
- 14. Statische Tabelle in einem Web-Router, die die nächsten Sprünge oder
Wege zu jedem oder anderem aktiven Web-Router in dem System spezifiziert.
-
Web-Router
tauschen WILD-Update-Meldungen aus, um ihre Abstände zu anderen Web-Routern
zu aktualisieren und um die besten TOS-Distanzen von den Web-Caches,
Inhalts-Servern und Web-Routern zu Client-Adressen zu aktualisieren.
Zurück
zur virtuellen Topologie von Web-Routern, die in 2 eingeführt wurden,
stellt 4 die besten TOS-Distanzen dar, die von Web-Routern
für den
Client 101 gehalten werden; die Figur zeigt eine einzelne
TOS-Distanz pro Web-Router für
den Client 101. Die in Klammern gesetzten Zahlen bezeichnen
die lokale TOS-Distanz, gefolgt von einem Paar in eckigen Klammern,
bestehend aus der bestbekannten TOS-Distanz und den dieser TOS-Distanz
entsprechendem Web-Cache.
-
Zum
Beispiel speichert der der Web-Router 220 eine lokale TOS-Distanz 100 zum
Client 101 und dessen beste TOS-Distanz zum Client 101 ist
10, und das Web-Cache 310 ist jenes Web-Cache, das als
der Client dienen sollte. Ähnlich
speichert der Web-Router 240 eine lokale TOS-Distanz von
50 zu dem Client 101 und dessen beste TOS-Distanz zu dem
Client ist 10 und wird von dem Web-Cache 350 bereitgestellt.
Die Web-Router 210 und 250 haben jeweils eine
lokale TOS-Distanz von 10 zum Client 101, und dies ist
auch ihre beste TOS-Distanz zum Client.
-
Web-Router
wählen,
welche TOS-Distanz verwendet werden soll, und das diese Distanz
bereitstellende Web-Cache durch Berechnung des Minimums der TOS-Distanz,
die sie von ihren Nachbarn erhalten, und ihre lokale TOS-Distanz zum selben
Client, und im Falle von Verknüpfungen
minimaler TOS-Distanzen,
die von Nachbarn erhalten werden und örtlich verfügbar sind; sie wählen das
Web-Cache, das diesen am nächsten
ist, durch die virtuelle Topologie der Web-Router. In einer anderen
Ausführung
der vorliegenden Erfindung kann ein Web-Router einfach alle Web-Caches
und alle umleitenden Web-Router enthalten, die minimale TOS-Distanz
zu einem Client-Adressbereich haben.
-
Eine
WILD-Update-Meldung besteht aus zwei Teilen. Ein Teil entspricht
der Information, die die Web-Router benötigen, um ihre minimalen Sprungdistanzen
zueinander zu aktualisieren, und der andere Teil entspricht der
Information, den die Web-Router benötigen, um das Mapping von Client-Adressbereichen zu Adressen
von Web-Caches und umleitenden Web-Routern, die als ein solcher Client-Adressbereich
dienen können,
durch die beste TOS-Distanz zu aktualisieren.
-
In
einer Ausführung
der vorliegenden Erfindung liefert eine WILD-Update-Meldung die Mappings
von Client-Adressbereichen zu Adressen von Web-Caches und umleitenden Web-Routern durch
Spezifikation der besten TOS-Distanz,
die von einem Web-Cache oder Web-Router zu einem bestimmten Clients-Adressbereich
bekannt ist. In diesem Fall besteht eine bevorzugte Ausführung der
vorliegenden Erfindung aus den folgenden drei Komponenten:
- (a) Basis-Routing-Update: Dies entspricht der
Information, der in jedem der vorgenannten Routing-Algorithmen erforderlich
ist, um minimale Sprungdistanzen zu Web-Routern zu aktualisieren,
welche Distanzen zu Web-Routern, die Distanzen und die zweitletzten
Sprünge
in Wegen zu Web-Routern, die gesamten minimalen Sprungwege zu Web-Routern,
die Identifizierer und Längen
der virtuellen Links, die zwischen Web-Routern definiert sind, die
einen Teil eines minimalen Sprungwegs zu einem Web-Router bilden,
oder die Identifizierer und Längen
der virtuellen Links, die zwischen Web-Routern definiert sind, die
Teil der virtuellen Topologie des Web-Routers bilden, enthalten
können.
- (b) Eine Liste von TOS-Distanzen von Web-Caches zu Bestimmungsorten,
welche das Folgende enthält:
- (i) Eine Client-Adresse oder einen Client-Adressbereich.
- (ii) Eine Liste von einer oder mehreren Web-Cache-Aufzeichnungen, jeweils
bestehend aus:
- (iia) Die Adresse eines Web-Caches oder Inhalts-Servers, der den
Client-Adressbereich bedienen kann.
- (iib) Die TOS-Distanz von dem Web-Cache oder Inhalts-Server
zu der Client-Adresse oder zum Client-Adressbereich.
- (iic) Die Adresse des Web-Routers, der mit dem Web-Cache oder
Inhalts-Server ko-lokalisiert ist.
- (c) Eine Liste von TOS-Distanzen von umleitenden Web-Routern
zu Bestimmungsorten, welche das Folgende enthalten:
- (i) Eine Client-Adresse oder einen Client-Adressbereich.
- (ii) Eine Liste von einer oder mehreren Web-Router-Aufzeichnungen, jeweils
bestehend aus:
- (iia) Der Adresse eines Web-Routers, der dazu benutzt werden
kann, um Clients mit den gemeldeten Adressen oder Adressbereich
umzuleiten.
- (iib) Der TOS-Distanz von dem Web-Router zu der Client-Adresse
oder dem Client-Adressbereich.
-
Die
nachfolgende Beschreibung des WILD-Protokolls nimmt an, dass die
vorgenannte Information in WILD-Update-Meldungen spezifiziert ist.
Jedoch sollte es sich für
den normalen Fachkundigen verstehen, dass auch andere Formate und
Informationstypen dazu benutzt werden können, das Mapping zwischen
einem Client-Adressbereich und den Adressen von Web-Caches, Inhalts-Servern
und umleitenden Web-Routern zu implementieren.
-
Unter
Verwendung der vorgenannten Information in WILD-Update-Meldungen führt ein
Web-Router Procedure Local_Change, Procedure WILD-Update und Procedure
Topology_change aus, die nachfolgend in Pseudo-Code spezifiziert
sind, um die Passungen zwischen Client-Adressbereichen und Adressen von Web-Caches
und umleitenden Web-Routern,
die diese bedienen sollten, zu aktualisieren. Procedure Local_Change
besteht aus dem Web-Router, an dem örtlich ein Weg-Ausführ-Algorithmus
läuft,
dessen lokale TOS-Distanzen zu Client-Adressbereichen berechnet, und aufrufen
von Procedure WILD_Update, als ob ein WILD-Update zu sich selbst
gesendet würde,
um Änderungen
zu bemerken, die an lokalen TOS-Distanzen zu Client-Adressbereichen
auftreten. Procedure WILD_Update behandelt den Empfang eines WILD-Updates durch einen
Web-Router, und Procedure Topology_Change behandelt das Auftreten
einer Topologie-Änderung,
die bewirkt, dass einer oder mehrere Web-Router unerreichbar werden.
-
In
dieser Beschreibung wird die Prozedur, die von einem Web-Router
benutzt wird, um seine minimalen Sprungdistanzen zu anderen Web-Routern zu aktualisieren,
Basic_Routing_Algorithm genannt. Die Ausgabe dieser Prozedur besteht
aus einer aktualisierten Distanz zu jedem Web-Router, der in dem System bekannt ist,
und einem Satz von Updates, die neuen Distanzen zu Web-Routern entsprechen,
die der Web-Router benötigt,
um mit seinen benachbarten Web-Routern zu kommunizieren.
-
Der
Einfachheit wegen wird angenommen, dass ein Web-Router eine Anker-Roter-Tabelle (ART)
hält, die
aus einem oder mehreren Ankereinträgen besteht, und jede solche
Eintrag spezifiziert: (a) die Adresse eines Anker-Web-Routers, (b)
die Liste von Ziel-Adress-Bereichen, für die der Web-Router als Anker
dient, für die
der Web-Router als Anker dient, für das Mapping von einem Adressbereich
zu einer Web-Cache-Adresse, und (c) die Liste von Zieladressbereichen,
für die
der Web-Router als Anker dient für
das Mapping des Adressbereichs zu sich selbst als umleitender Web-Router.
Die ART-Tabelle ermöglicht
es dem Web-Router, zu bestimmen, für welche Zieladressbereiche
er neue Mappings von Web-Caches oder umleitenden Web-Routern haben
könnte,
für den
Fall dass irgendein Web-Router unerreichbar wird.
-
Eine
aktualisierte TOS-Distanz von einem Web-Cache zu einem Client-Adresse oder einem
Adressbereich wird in einer WILD-Update-Meldung gemeldet mit einem
Aktualisierungseintrag [Client, Web-Cache, TOS-Distanz (vom Web-Cache
zum Client), Anker-Web-Router], wo der Anker-Web-Router die Adresse des Web-Routers ist,
der mit dem Web-Cache oder Inhalts-Server, der in dem Aktualisierungseintrag
spezifiziert ist, ko-lokalisiert ist.
-
Eine
aktualisierte TOS-Distanz von einem umleitenden Web-Router zu einer
Client-Adresse oder einem Adressbereich wird in einer WILD-Update-Meldung mit einem
Aktualisierungseintrag gemeldet [Client, umleitender Web-Router,
TOS-Distanz vom umleitenden Web-Router].
-
Procedures
WILD_Update und Topology_Change ruft Procedure Send_WILD_Update
auf, damit der Web-Router seinen benachbarten Web-Router seine aktualisierten
Distanzen zu anderen Web-Routern und aktualisierte TOS-Distanzen
von Web-Caches, Inhalts-Server und umleitenden Web-Routern zu Client-Adressen
kommuniziert.
-
Um
die nachfolgende Pseudo-Beschreibung zu vereinfachen, wird ein einzelnes
Web-Cache und ein umleitender Web-Router für jeden Client-Adressbereich benutzt.
Ferner wird ein einzelnes TOS bei der Berechnung von Mappings von
Client-Adressbereichen zu Adressen von Web-Caches und umleitenden Web-Routern
benutzt. Jedoch das gleiche hierin spezifizierte Gesamtverfahren
auch für
den Fall, wo ein Satz von Web-Caches
und umleitenden Web-Routern und mehrere TOSes für jeden Client-Adressbereich benutzt werden.
-
Definierte Variablen:
-
-
- c-id:
- Client-Adressbereich.
- H(WR-id):
- Minimale Sprungdistanz
zu Web-Router WR-id am Web-Router,
der Procedure WILD_Update ausführt.
- D(c-id):
- Beste TOS-Distanz
von einem Web-Cache zum c-id am Web-Router, der Procedure WILD_Update ausführt.
- C(cied):
- Adresse eines Web-Caches
oder Inhalts-Servers zur Verwendung für den Client-Adressbereich
c-id durch den Web-Router,
der Procedure WILD_Update ausführt.
- a(c-id):
- Anker des Mappings
zwischen einem Web-Cache und c-id am Web-Router, der Procedure WILD_Update
ausführt.
- DR(c-id):
- Beste TOS-Distanz
von einem umleitenden Web-Router zu c-id am Web-Router, der Procedure
WILD-Update ausführt.
- R(C-id):
- Adresse eines umleitenden
Web-Routers zur Verwendung als Client-Adressbereich c-id durch den
Web-Router, der Procedure WILD_Update ausführt.
- D_k(c-id):
- TOS-Distanz von einem
Web-Cache zum c-id, der von einem benachbarten Web-Router k gemeldet
wird und an einem Web-Router
gespeichert wird, der Procedure WILD_Update ausführt.
- C_k(c-id):
- Adresse vom Web-Cache
oder Inhalts-Server, den der benachbarte Web-Router k für den Client-Adressbereich
c-id empfiehlt und der am Web-Router gespeichert ist, der Procedure WILD_Update
ausführt.
- DR_k(c-id):
- TOS-Distanz von einem
umleitenden Web-Router zum c-id, der von einem benachbarten Web-Router
k gemeldet wird, und der am Web-Router gespeichert ist, der Procedure WILD_Update
ausführt.
- R_k(c-id):
- Adresse eines umleitenden
Web-Routers, den ein benachbarter Web-Router k für den Client-Adressbereich
c-id empflielt, und der am Web-Router gespeichert ist, der Procedure WILD_Update
ausführt.
- a_k(c-id):
- Web-Router, der D_k(c-id)
verankert.
- UWR:
- Unerreichbare-Web-Router-Liste
- UWR.w:
- Reihe in UWR, die
Web-Router w listet.
- ART:
- Verankernde Router-Tabelle.
- ART.w:
- Reihe, die dem Web-Router
w in ART entspricht.
- ART.w-c[j]:
- Ziel j, für das der
Web-Router w ein Anker für
das Mapping zu einer Web-Cache-Adresse ist.
- ART.w-r[j]:
- Ziel j, für das der
Web-Router w ein Anker für
das Mapping zu sich selbst als umleitender Web-Router ist.
-
-
-
-
-
-
-
-
Procedure
Update_Web_Routers
-
-
-
Procedure
Send_WILD_Update
-
5a–5d zeigen ein Beispiel der vorliegenden
Erfindung, wenn ein Web-Router ein WILD-Update von einem benachbarten
Web-Router empfängt.
In diesem Beispiel nimmt die Verstopfung im Netzwerk vom Web-Cache 310 zum
Client 101 zu, was die lokale TOS-Distanz vom Web-Router 210 zum
Client 101 gleich 40 macht, als Ergebnis der Ausführung vom
Procedure Local_Change, das wiederum Procedure WILD_Update aufruft.
-
Wie
in 5(a) gezeigt, schickt der Web-Router 210 ein
WILD-Update nach Ausführung
vom Procedure WILD_Update, um eine beste TOS-Distanz zum Client 101 zu
melden, die gleich 40 ist, und die Tatsache, dass das Web-Cache 310 dazu
benutzt werden sollte, als Client zu dienen. Das WILD-Update vom Web-Router 210 wird
von seinen benachbarten Web-Routern 220 und 230 empfangen.
Als Ergebnis des WILD-Updates vom Web-Router 210 berechnet
der Web-Router 220 seine neue beste TOS-Distanz zum Client 101 unter
Verwendung der TOS-Distanzen, die er von seinen Web-Routern und seiner örtlich verfügbaren TOS-Distanz
zum Client 101 empfangen hat, und der Web-Router 220 schickt
dann ein WILD-Update, das eine TOS-Distanz von 40 zum Client 101 und
zum Web-Cache 310, als dem Cache zum Bedienen des Clients 101,
angibt (siehe 5(b)).
-
Ähnlich schickt
der Web-Router 230 ein WILD-Update, das eine TOS-Distanz zu einem
Client 101 gleich 10 und ein Web-Cache 350 zu
dem als dem Client dienenden hin angibt. Wie 5(c) zeigt,
bewirkt das WILD-Update
vom Web-Router 220, dass der Web-Router 205 ein
WILD-Update schickt, das eine TOS-Distanz zum Client 101 gleich
10 angibt, und einen Web-Cache 305 als dem einen, der als
der Client dient. Das WILD-Update von dem Web-Router 230 bewirkt,
dass der Web-Router 210 sein bestes TOS für den Client 101 auf
10 ändert
und das Web-Cache 350 als das eine setzt, das als Client
dient, und der Web-Router 210 schickt dementsprechend ein
WILD-Update. Andererseits modifiziert der Web-Router 240 seine beste TOS-Distanz
für den
Client 101 nicht, nach Bearbeitung des WILD-Updates vom
Web-Router 230.
-
5(d) stellt einen Web-Router 220 dar,
der ein WILD-Update schickt, mit einer TOS-Distanz zum Client 101 von
gleich 10 und einem Web-Cache 350 als den einen, der als
der Client dient. Dieses Beispiel stellt die Tatsache dar, das WILD-Update
sich über
die Topologie von Web-Routern nur soweit fortpflanzen, wie sie gehen
müssen,
um zu ermöglichen,
dass alle Web-Router
die minimalen TOS-Distanzen zu Clients speichern.
-
Somit
ist ein Schema beschrieben worden, um das Auffinden der Caches und
Server zu ermöglichen, die
Informationsobjekte speichern, die über Computer-Netzwerke verteilt
sind, welche in Hardware und/oder Software implementiert sein können. Es
versteht sich, dass einige Ausführungen
der vorliegenden Erfindung das so genannte URL-Routing auf Netzwerkebene
(NURL) verwenden. Diese Routing-Technik beinhaltet das Mapping von
angeforderten URLs zu Unicast-Adressen, die dann als Anycast-IP-Adresse
verwendet werden (das heißt,
eine Unicast-Adresse, die von mehreren physikalisch verschiedenen
Punkten in einem Internet beworben wird). Siehe zum Beispiel Craig
Partridge, Trevor Mendez und Walter Milliken, „Host Anycasting Service RFC
1546", November
1993. Ein System und ein Verfahren zur Verwendung von Uniform Resource
Locators (URLS) auf Map-Anwendungs-Ebenen-Inhaltsnamen zu Netzwerkebenen-Anycast-Adressen, das vorgenannte
Mapping, ist in der mitanhängigen
U.S.-Anmeldung 60/200,511
des gleichen Anmelders offenbart, mit dem Titel „System and Method for Using
URLs to Map Application Layer Content Names to Network Layer Anycast
Addresses", eingereicht
am 28. April 2000 von J. J. Garcia-Luna-Aceves und Bradley R. Smith,
deren vollständige
Offenbarung hierdurch unter Bezugnahme aufgenommen wird. Ferner
ist ein System und ein Verfahre zur Verwendung von Netzwerkebenen-URL-Routing zum Lokalisieren
des nächsten
Servers, der einen bestimmten Inhalt trägt (Routing von URLs auf Netzwerkebene)
in der mitanhängigen
U.S.-Anmeldung Nr. 60/200,402 des gleichen Anmelders offenbart,
mit dem Titel „System
and Method for Using Network Layer URL Routing to Locate the Closest,
eingereicht am 28.04.2000 von J. J. Garcia-Luna-Aceves und Bradley
R. Smith, deren vollständige
Offenbarung hierdurch unter Bezugnahme aufgenommen wird.
-
Mit
der Route über
den Anycast-Cache-Server, der in der Netzwerkinfrastruktur existiert,
würde ein
Cache-Server, der ein fehlendes Cache bearbeitet, den Inhalt von
der URL-IP-Adresse übertragen
wollen. In einem Ausführungsbeispiel
löst in
einer solchen Situation die vorliegende Erfindung die Anycast-Adresse
zur realen Unicast-Adresse des Servers (die per Definition diesen
Server in dem Internet eindeutig identifiziert) auf, bevor das Download
beginnt. In einem Ausführungsbeispiel
erfolgt dies mittels eines Anycast-Adressauflösungsprotokolls (AARP), das
in der mitanhängigen
U.S.-Anmeldung Nr. 60/200,403 des gleichen Anmelders offenbart ist
mit dem Titel „System
and Method for Resolving Network Layer Anycast Addresses to Network Layer
Unicast Addresses (AARP)",
eingereicht am 28. April von J. J. Garcia-Luna-Aceves und Bradley
R. Smith, deren vollständige
Offenbarung hierdurch unter Bezugnahme aufgenommen wird.
-
Obwohl
somit die vollständige
Beschreibung und die beigefügten
Figuren spezifische Ausführungen diskutieren
und veranschaulichen, ist die vorliegende Erfindung nur in Hinblick
auf die nachfolgenden Ansprüche
und ihre Äquivalente
zu bemessen.