DE69727438T2

DE69727438T2 - Zwischenspeicher-Protokoll für verbesserte Webleistung

Info

Publication number: DE69727438T2
Application number: DE69727438T
Authority: DE
Inventors: Antonio Ocean DeSimone; Sandeep Matawan Sibal; David Hilton Middletown Shur
Original assignee: AT&T Corp
Current assignee: AT&T Corp
Priority date: 1996-10-18
Filing date: 1997-10-13
Publication date: 2004-12-02
Anticipated expiration: 2017-10-14
Also published as: EP0837584A1; CA2216346C; DE69727438D1; EP0837584B1; US5787470A; JP3968119B2; JPH10254753A; CA2216346A1

Description

TECHNISCHES GEBIET
Diese Erfindung betrifft Datenkommunikationen und die Computer-Vernetzung und insbesondere den Transfer von digitaler Information auf Paketdatennetzen wie dem Internet, zwischen Caches.
HINTERGRUND DER ERFINDUNG
Bei einer Transaktion auf dem World Wide Web zwischen einem Client-Terminal und einem Web Server, bei der das Client-Terminal ein Web Objekt von einem Server zurückgewinnt, der auf dem Internet verbunden ist, greift das Client-Terminal normalerweise auf das Internet über einen Internet Access Service Provider (IASP) zu. Ein derartiges Objekt können ein oder mehrere Seiten von Textinformation, ein Bild, ein Tonclip, ein Videoclip, ein JAVA Applet oder eine andere Software, irgendeine Kombination der vorangehenden oder irgendetwas, was digital über das Internet an ein Client-Terminal übertragen werden kann, sein. Der Ausdruck „Objekt" wird nachstehend verwendet, um sämtliche voransehenden einzuschließen. Ein Cache (Zwischenspeicher), der in dem IASP Netz angeordnet ist, arbeitet als eine Zwischeneinheit bei Transaktionen, die die Zurückgewinnung von derartigen Webobjekten von Servern durch ein Client-Terminal beinhalten. Insbesondere speichert ein Cache innerhalb des IASP in seiner einfachsten Form eine Kopie des zurückgewonnenen Objekts für sich selbst, wenn das Objekt von dem Server an das anfordernde Client-Terminal bewegt wird. Diese Caching-Operation ist für den Benutzer transparent und verursacht unter normalen Umständen keine signifikante Verzögerung als Folge des Kopiervorgangs, der gleichzeitig ausgeführt wird, wenn das Objekt von dem Server zurückgewonnen und an das Client-Terminal geliefert wird.
In vorteilhafter Weise kann der Cache innerhalb des IASP Netzes nachfolgende Anforderungen für diese Objekte, die darin gespeichert sind, erfüllen, wodurch die Notwendigkeit zum Zurückgewinnen des Objekts aus dem ursprünglichen Server auf dem Internet vermieden wird. Dies verringert die Verzögerung, wie von dem Benutzer wahrgenommen, zum Zugreifen auf das Objekt und spart ferner Bandbreite auf Strecken ein, die das IASP Netz mit dem Internet verbinden. 1 ist ein Blockdiagramm eines herkömmlichen Netzes, bei dem mehrere Client-Terminals, wie 101 und 102, mit einem Cache 103 innerhalb eines IASP 104 verbunden sind. Der Cache 103 ist wiederum mit einem Server 105 verbunden, der mit dem Internet 106 verbunden ist. Durch Speichern eines Objekts von dem Server 105 in dem Cache 103, wenn es zuerst von dem Client 101 zurückgewonnen wird, können nachfolgende Anforderungen für das gleiche Objekt durch den Client 101 oder irgendeinen anderen Client, der mit dem Cache 103 innerhalb des IASP 104 verbunden ist, beispielsweise dem Client 102, direkt von dem Cache 103 erfüllt werden. Der IASP 104 umfasst wahrscheinlich auch einen zweiten oder weitere Caches, wie den Cache 107, der andere Clients bedient, die mit dem gleichen IASP verbunden sind, wie 108 und 109. Die Objekte, die in dem zweiten Cache 107 oder anderen Caches innerhalb des IASP 104 gespeichert sind, aber nicht gezeigt sind, könnten verwendet werden, um die Clients zu bedienen, die mit dem ersten Cache 103 verbunden sind, wenn die Caches untereinander kommunizieren.
Im Allgemeinen wird in dem Stand der Technik dann, wenn eine Anforderung für ein Objekt empfangen wird, eine Entdeckung von Objekten auf anderen als dem Cache, mit dem der anfordernde Client angebracht ist, durch eine explizite Befragung zu der Zeit, wenn die Anforderung für ein bestimmtes Objekt durchgeführt wird, ausgeführt. Das heißt, immer dann, wenn eine Anforderung von einem Client durch den Cache, mit dem der Client verbunden ist, nicht erfüllt werden kann, werden eine Vielzahl von Anforderungen an benachbarte Caches herausgesendet, die diese fragen, ob sie eine Kopie des gewünschten Objekts in ihrem Speicher gespeichert haben.
Die Schritte zum Befragen einer Vielzahl von Caches, das Warten auf eine Antwort, und das Herunterladen einer Kopie des Objekts von dem Cache, welches das Objekt aufweist, oder das Zurückgewinnen einer Kopie des Objekts von dem ursprünglichen Server des Objekts, wenn das Objekt in einem benachbarten Cache nicht gefunden werden kann, kann eine Verzögerung für den Zurückgewinnungsprozess mit sich bringen, der für den anfordernden Benutzer nicht akzeptabel ist. Ferner kann die Überschwemmung von Anforderungen an alle benachbarten Caches im Ansprechen auf jede Anforderung für ein Objekt eine verschwenderische Verwendung der Netzbandbreite sowie die Belegung von Berechnungsressourcen der Caches sein. Noch weiter, die Kopie eines Objekts, wenn es auf einem benachbarten Cache existiert, kann sich von dem Objekt unterscheiden, sowie es den Server verlässt, von dem es ursprünglich kommt. Dies wird sich ergeben, wenn das Objekt in dem Server modifiziert wird, nachdem die anfängliche Anforderung für das Objekt durchgeführt wurde und eine Kopie des Objekts in dem benachbarten Cache gespeichert wurde. Somit kann das Objekt, das an einem anfordernden Cache von einem antwortenden Cache verfügbar ist, nicht aktuell sein und kann eine abgestandene oder nicht aktuelle Version des Objekts sein, so wie es gegenwärtig in dem Server existiert, und es ist somit nicht geeignet, um an einen Client geliefert zu werden, der dieses Objekt anfordert.
„The Harvest Object Cache in New Zealand", von D. Neal, in "Computer Networks und ISDN Systems" Vol. 28, No. 11, pp. 1415–1430 (1996) offenbart ein System, welches zusammenarbeitende Web-Caches umfasst. Ein Server, der eine Anforderung für ein Objekt empfängt, wird eine Anfrage an sämtliche verfügbaren Caches senden, um zu bestimmen, welches Caches eine Kopie des gewünschten Objekts in ihrem Speicher gespeichert haben, und zwar in der herkömmlichen Weise, die voranstehend beschrieben wurde. Dieses System des Standes der Technik weist deshalb die spezifischen Probleme auf, die voranstehend identifiziert wurden.
„The Harvest information discovery and access system", von C. Mic Bowman at al., in "Computer Networks und ISDN Systems", Vol. 28, No. 1 pp119–125 (1995), stellt eine allgemeine Übersicht über das "Harvest" System bereit, spricht aber ein System mit zwei oder mehreren zusammenarbeitenden Web-Caches nicht an.
Die vorliegende Erfindung stellt ein Verfahren zur Verwendung in einem System mit zwei untereinander verbundenen Webcaches bereit, wie im Anspruch 1 definiert. Bevorzugte Merkmale der vorliegenden Erfindung sind in den anhängigen Ansprüchen 2–10 aufgeführt.
In Übereinstimmung mit der vorliegenden Erfindung wird ein fache mit Information darüber versehen, welche Objekte sein benachbarter fache führt, und mit anderer Information über diese Objekte in dem benachbarten fache, beispielsweise den Zeiten, zu denen diese Objekte in dem benachbarten fache modifiziert wurden, dem Typ des Inhalts von diesen Objekten, und den Größen von diesen Objekten. Die letztere Information kann zum Planen einer Plattenplatz-Verwendung nützlich sein. Dieser Informations-Sammelprozess unterscheidet sich von der tatsächlichen Zurückgewinnung eines Objekts von einem benachbarten Cache oder in der Alternative von dem aktuellen Server, der die jüngste Version des Objekts führt, und wird asynchron zu der Anforderung von irgendeinem Client für das Objekt ausgeführt.
Webcaches aktualisieren einander mit Webobjekten in ihrem Cache über verschiedene Mechanismen. In einem ersten Mechanismus befragt ein anfragender Cache einen antwortenden Cache nach Information über sämtliche Objekte oder einen Untersatz von Objekten in dem antwortenden Cache, die seit einem gegebenen Datum und einer gegebenen Zeit modifiziert worden sind. „Modifiziert" wie hier verwendet umfasst Objekte, die in diesem Cache seit der gegebenen Zeit aktualisiert oder erzeugt worden sind. In einem zweiten Mechanismus informiert ein antwortender Cache den anfordernden bzw. anfragenden Cache periodisch über Modifikationen an Objekten, an denen der anfordernde Cache früher ein Interesse ausgedrückt hatte. In dritten und vierten intelligenteren Mechanismen halten benachbarte Caches Zustands-Information darüber, auf welche Objekte die anderen Caches die Nachrichten gestützt haben, die vorher an ihn gesendet wurden. Insbesondere führt in dem dritten Mechanismus jeder Cache Zustands-Information für Objekte in jedem benachbarten Cache, mit dem er kommuniziert. Der vierte Mechanismus ist auf den Fall anwendbar, bei dem zahlreiche Peer-Caches existieren und jeder von diesen an jedem anderen Cache-Inhalt interessiert ist. Information, die ein Cache über den Inhalt von anderen Caches gesammelt hat, wird dann zusammen mit dem Inhalt von seinem eigenen Cache verwendet, um die Nachrichten zusammenzustellen, die an irgendeinen gegebenen Cache gesendet werden.
KURZBESCHREIBUNG DER ZEICHNUNGEN
In den Zeichnungen zeigen:
1 ein Blockdiagramm eines herkömmlichen Netzes, das zwei Caches, die innerhalb eines Internet Access Service Providers verbunden sind, untereinander verbundene Client-Terminals und einen Server innerhalb des Internets zeigt;
2 die Interaktionen zwischen einem anfordernden Cache und einem antwortenden Cache entlang einer Zeitlinie in Übereinstimmung mit einem vom anfordernden Cache initiierten Benachrichtigungs-Mechanismus der vorliegenden Erfindung;
3 die Interaktionen zwischen einem anfordernden Cache und einem antwortenden Cache entlang einer Zeitlinie in Übereinstimmung mit einem vom antwortenden Cache initiierten Benachrichtigungs-Mechanismus der vorliegenden Erfindung;
4 die Interaktion zwischen zwei Caches, bei der jeder Cache getrennte Zustands-Information für jeden der anderen Nachbar-Caches, mit denen er kommuniziert, führt;
5 die Interaktion zwischen zwei Caches, bei der jeder Cache eine Einzelzustands-Information für das gesamte Caching-System führt; und
6 die Nachrichten-Interaktion zwischen einem anfordernden Cache und einem antwortenden Cache für eine spezifische Implementierung eines vom anfordernden Cache initiierten Mechanismus in Übereinstimmung mit der vorliegenden Erfindung.
AUSFÜHRLICHE BESCHREIBUNG
Wie angegeben ist die vorliegende Erfindung ein Mechanismus, mit dem Webcaches einander darüber aktualisieren, welche Webobjekte in ihrem Cache sind. Eine Aktualisierungs-Benachrichtigung ist anders als ein tatsächliches Senden der modifizierten Webobjekte. Die Benachrichtigung beinhaltet typischerweise Information, aus der der empfangende Cache bestimmen kann, welche Webobjekte in dem benachbarten Cache gespeichert sind, aber auch Information wie beispielsweise die Zeit, zu der das Objekt in dem benachbarten Cache zuletzt modifiziert wurde. Optional kann die Benachrichtigung andere Information enthalten, die für den anfordernden Cache nützlich sein könnte, beispielsweise die Größe, in Bytes, des Objekts, um den anfordernden Cache in die Lage zu versetzen, seine Plattenplatz-Verwendung zu planen, und der Typ von Inhalten des Objekts.
Um zwischen zwei Caches zu unterscheiden, die bei dem Transfer von Information hinsichtlich der Objekte, die in jedem gespeichert sind, beteiligt sind, wird der Cache, der Information über die Inhalte von seinem Nachbar-Cache wünscht, nachstehend als der anfordernde Cache (Requesting Cache, RQC) bezeichnet, und der Nachbar-Cache, der Information darüber herausfindet, was er speichert, wird als der antwortende Cache (Responding Cache, RSC) bezeichnet. Der Mechanismus der vorliegenden Erfindung ist in einer Umgebung funktionsfähig, bei der einige Caches nur als RQCs arbeiten und andere nur als RSCs. Insbesondere kann in einer hierarchischen Topologie eine Situation ins Auge gefasst werden, bei der Caches, die in der Hierarchie weiter unten sind, nur Information anfordern, und diejenigen, die in der Hierarchie weiter oben sind, nur antworten. „Höher" wird in dem Sinne verwendet, dass die Strecke zu dem Internet auf der höchsten Ebene ist, und die Webclients oder Browser auf dem niedrigsten Pegel. Bei den meisten gebräuchlichen kommerziellen Browsern sind Caches gemeinsam angeordnet. Ein derartiger Client-Cache würde typischerweise immer ein RQC sein. Er kann auch als ein RSC arbeiten, wenn benachbarte Browser die Erlaubnis haben an den privaten Caches von anderen Browsern „nachzusehen".
2 zeigt den Mechanismus für eine RQC-initiierte Benachrichtigung. In diesem Mechanismus initiiert der RQC 201 eine Anforderung 202 an den RSC 203, um ihn über sämtliche oder einen Untersatz von Objekten, die in dem RSC 203 gespeichert sind und innerhalb des RSC 203 seit einem gegebenen Datum und einer gegebenen Zeit aktualisiert worden sind oder für den RSC 203 neu sind, zu informieren. Wie voranstehend angegeben soll der Ausdruck „seit einem gegebenen Datum und einer gegebenen Zeit modifiziert", wie auf Objekte angewendet, diejenigen Objekte bedeuten, die für den RSC seit dieser Zeit und diesem Datum neu sind, sowie diejenigen Objekte, die seit dieser Zeit und diesem Datum aktualisiert worden sind. Die Adressenliste von URLs in der Anforderung können Objekte mit individuellen URLs oder eine Vielzahl von Objekten innerhalb eines Bereichs von URLs unter Verwendung eines Wildcard Symbols, um all diejenigen Objekte darzustellen, deren URLs eine Adressen-Übereinstimmung teilen, einschließen. Wie angegeben kann diese Anforderung eine Anforderung nach Information über sowohl Aktualisierungen an existierenden Objekten, die vorher in dem RSC 203 gespeichert wurden, als auch Objekte, die in dem RSC 203 neu hinzugefügt worden sind, einschließen. Die Anforderung 202 umfasst ein „wenn modifiziert seit" (IMS) Datum, wodurch dem RSC angezeigt wird, dass Information für Objekte nur angefordert wird, wenn das Objekt in dem Cache modifiziert oder zu dem Cache seit diesem IMS Datum neu hinzugefügt worden ist.
Als Antwort auf die Anforderung 202 überprüft der RSC 203 diese aufgelisteten URLs, um zu bestimmen, ob das Objekt in der Tat in dem Cache seit dem IMS Datum modifiziert worden ist. Die Antwort 204 darauf ist eine Liste von denjenigen URLs, die in der Tat in dem RSC seit dem IMS Datum modifiziert worden sind, zusammen mit den Zeiten, zu denen diese URLs modifiziert wurden. Diese Information kann auch die Größe des angeforderten URL Objekts, sowie andere Information über das Objekt, beispielsweise den Typ des Inhalts des Objekts, einschließen. Der RQC 201 sieht dann die Antwort durch und entscheidet unter Verwendung der zurückgewonnenen Information über diese angeforderten URLs, insbesondere welche URLs er wünscht an sich selbst herunterzuladen. Diese Herunterladung kann in der Tat selbstständig, auf Grundlage seines eigenen Satzes von Regeln, durchgeführt werden, oder kann zu einer späteren Zeit im Ansprechen auf eine tatsächliche Anforderung für die das Objekt durch einen Benutzer, der mit dem RQC 201 verbunden ist, durchgeführt werden. Wenn der RQC entweder selbstständig oder im Ansprechen auf eine Anforderung von einem Benutzer entscheidet das Objekt mit der URL url zurückzugewinnen, bildet er eine Anforderung 205, um das Objekt mit der URL url unter Verwendung des Hyper Text Transfer Protocols (HTTP), welches das vorherrschende Protokoll des World Wide Web Internets ist, zu holen (GET). Der RSC 203 sendet als Antwort auf diese GET Anforderung eine Antwort 206 zurück an den RQC 201, der eine Kopie des Körpers des Objekts mit der URL url, das er gespeichert hat, einschließt.
3 zeigt einen Mechanismus für ein RSC initiiertes Verfahren, bei dem der RSC dem RQC manchmal Änderungen an Objekten, an denen der RSC vorher ein Interesse ausgedrückt hat, mitteilt. In einem ersten Modus wird Information über Objekte, die modifiziert worden sind, an den RSC auf einer periodischen Basis übertragen. In einem zweiten Modus wird Information immer dann gesendet, wenn ein angefordertes Objekt tatsächlich aktualisiert oder in dem RQC erzeugt wird. Beide Moden können gleichzeitig existieren. In dem zweiten Modus registriert der RQC 301 zunächst eine Anforderung 302 mit dem RSC 303 für Aktualisierungs-Ereignisse für einen Bereich von URLs. Der RSC 303 registriert dann diese Anforderungen und überträgt eine Bestätigung 304 zurück an den RQC 301. Nach der Registrierung überträgt der RSC 303 eine Aktualisierungsnachricht zurück an den RQC 301 immer dann, wenn eine von diesen registrierten URLs modifiziert wird. Wenn eine URL url1 modifiziert wird, wird somit eine Nachricht 305, die Information über das Objekt enthält, an den RQC 301 übertragen. Als Antwort darauf kann der RQC 301 entscheiden eine Anforderung 306 durchzuführen, um unter Verwendung des HTTP/1.0 Protokolls url1 zu holen (GET). Alternativ, im Ansprechen auf eine Informationsnachricht, dass eine bestimmte URL modifiziert worden ist, kann der RQC 301 entscheiden, sie nicht herunterzuladen. Wie in 3 angegeben, wenn die URL url1 modifiziert wird und eine Aktualisierungsnachricht 307 über die URL url2 an den RQC 301 übertragen wird, entscheidet der RQC somit nicht eine Anforderung zum Herunterladen der modifizierten url2 zu bilden. In einer ähnlichen Weise, wenn die URL url3 modifiziert wird und eine Nachricht an den RQC 301 übertragen wird, dann bildet der RQC eine Aufforderung zum Herunterladen des modifizierten Objekts.
Die Motivation der vorliegenden Erfindung zum einfachen Senden von Benachrichtigungs-Nachrichten anstelle der Webobjekte selbst ist zweifach. Erstens ermöglicht sie eine Art von Cache-Kohärenz sogar dann, wenn der RQC auf seinem System keinen Platz mehr hat, um das Webobjekt selbst zu kopieren. Da dies asynchron zu Benutzer-Anforderungen durchgeführt wird, und nicht als Folge einer Anforderung, wissen Caches vorzeitig, was andere Caches führen, und können deshalb eine Verzögerung, so wie sie von dem Benutzer wahrgenommen wird (durch Verhinderung von fruchtlosen Anfragen an Nachbar-Caches), sowie Netz- und Cache-Ressourcen einsparen. Zweitens erlaubt die Erfindung eine logische Trennung zwischen Information bezüglich der Modifikationszeit eines Objekts und dem Inhalt des Objekts selbst. Ein Cache kann deshalb wählen, welche Objekte er wieder auffrischen oder eincachen möchte, bevor er sie herunterlädt. Da die Information, die geführt wird, andere Aspekte des Objekts einschließen kann, beispielsweise die Größe in Bytes, ist der Cache besser vorbereitet, bevor das Objekt heruntergeladen wird. Zum Beispiel kann die Größe eines bestimmten Objekts sehr groß sein und der Cache kann wählen es als Folge einer unzureichenden Speicherkapazität nicht herunterzuladen.
Nach dem Austausch von Information über die Webobjekte, die in benachbarten Caches gespeichert sind, können die neuen oder modifizierten Webobjekte entweder individuell oder als ein Stapel unter Verwendung von Multipart-Nachrichten, Keep-Alive Verbindungen, oder einer Kompression oder irgendeinem anderen Schema zurückgewonnen werden.
Wie voransehenden angegebenen sind Dokumente, die an einem Cache seit einem gegebenen Datum und einer gegebenen Zeit aktualisiert worden sind, in Bezug auf Aktivitäten an dem Cache und nicht an dem Server, von dem das Objekt stammte. Somit kann ein Dokument, das an einem Cache nach der Zeit t1 modifiziert worden ist, unter Umständen an dem Server zu einer Zeit t2 < t1 modifiziert worden sein.
In dem vorher beschriebenen RSC-initiierten Mechanismus der 3 sendet der RSC manchmal an den RQC Information über alle Objekte, die er in seinem Cache hat und die in dem Cache seit der letzten Nachricht, die er an den RQC in der vorangehenden Epoche gesendet hat, modifiziert oder erzeugt worden sind. Dieser Mechanismus wird erweitert, so dass der RQC automatisch antwortet, indem er an den RSC eine andere Nachricht zurücksendet, die eine Liste von allen Objekten aufweist, die er in seinem Cache hat und die seit der letzten Interaktion, die er mit dem RSC in der vorangehenden Epoche hatte, modifiziert worden sind. Dieser kombinierte Mechanismus ist ähnlich zu dem Mechanismus der 3, ist aber einer, bei dem beide Nachbar-Caches sowohl anfordernde als auch antwortende Caches werden. In diesem Mechanismus wird die Anforderung in jeder Antwort implizit. Da die Differenz zwischen einer „Anforderung" und einer „Antwort" nun verschmiert wird, wird anstelle davon der Ausdruck „Nachricht" verwendet werden.
Ein intelligenteres Szenarium kann betrachtet werden. Hierbei führen Caches Zustandsinformationen darüber, was andere Caches haben, teilweise auf Grundlage der Nachrichten, die an ihn gesendet werden. Sobald diese Zustandsinformation verfügbar ist, können Nachrichten, die hin und her gesendet werden, weiter stromlinienförmig gemacht werden. Es ist insbesondere nutzlos Nachrichten über aktualisierte Objekte an den Cache von jemanden an einen Nachbarn zu senden, von dem bekannt ist, aus der früheren Nachricht des Nachbars, dass er eine jüngere oder gleich alte Version des Objekts hat. Dieser dritte Mechanismus, der in 4 gezeigt ist, ist nur zwischen Caches möglich, die sowohl als RQCs als auch RSCs arbeiten können. Dieser Mechanismus ist insbesondere zur Verwendung für den Fall ausgelegt, wenn Peer-Caches innerhalb eines IASP sich dafür interessieren alles über die modifizierten Objekte an allen Caches zu wissen. Während dieser Mechanismus fordert, dass jeder Cache eine gewisse Zustandsinformation darüber führt, was auf den Caches von seinen Nachbarn ist, reduziert es signifikant den Kommunikations-Zusatz, insbesondere dann, wenn die Anzahl von Objekten in jedem Cache groß ist.
In dem Mechanismus der 4 sendet ein Cache 401 an den Nachbar-Cache 402 eine Nachricht 403, die Information über einen Satz von URLs enthält. Wenn der Cache 402 diese Nachricht empfängt aktualisiert er die Zustandsinformation, die er über seinen Nachbar-Cache 401 akkumuliert hat. Der Cache 402 sendet dann, auf Grundlage der Zustandsinformation, die der Cache 402 auf seinem Cache 401 hat, eine Nachricht 404, die Information über einen Satz von modifizierten URLs enthält, die neuer als das ist, was der Cache 401 hat. Wenn die Nachricht 404 von dem Cache 401 empfangen wird, dann wird die Zustandsinformation, die der Cache 401 auf seinem Cache 402 hat, aktualisiert und auf Grundlage dieser Zustandsinformation wird Information über URLs, die neuer als das ist, was der Cache 402 aufweist, an den Cache 402 in der Nachricht 405 gesendet. Dieser Algorithmus wird an die Caches 401 und 402 im Ansprechen auf jede empfangene Nachricht voneinander wiederholt.
In diesem Mechanismus führt jeder Cache Zustandsinformation (als eine Tabelle) auf jedem Nachbar-Cache, mit dem er kommuniziert. Jede Tabelle ist im Wesentlichen eine Liste von URLs mit deren Modifikationszeiten an dem Cache. Jeder Posten in der Liste ist somit ein 2-Tupel der Form: (url_i, t_i) wobei t_i die modifizierte Zeit des Objekts ist, das durch die URL url_i identifiziert wird. Es sei darauf hingewiesen, dass an den unsprünglichem Server/der unsprünglichen Site ein Dokument existiert, welches neuer ist, als das, was der Cache hat, mit einer Modifikationszeit später als t_i. Jedoch listet die Tabelle einfach das jüngste Dokument, das der Nachbar-Cache hat, auf Grundlage der Kenntnis auf, die aus Nachrichten aufgebaut wird, die der Nachbar-Cache herausgegeben hat.
Die Tabelle wird wie folgt aktualisiert. Jede Nachricht von dem Nachbar-Cache umfasst eine Liste von URLs mit zugehörigen Modifikationszeiten. Für jeden Posten (url, t) wird die folgende Operation verwendet. Es sei (url_i, t_i) ein Eintrag in der Tabelle. Wenn url = url_i: ersetze (url_i, t_i) durch (url, t) in der Tabelle. Wenn es eine URL ist, die der Nachbar von dem Cache gelöscht hat, dann wird diese URL ebenfalls gesendet, mit t auf einen negativen Wert gesetzt (was anzeigt, dass er gelöscht worden ist). Es sei angenommen, dass die Liste von neuen URLs (seit der letzten Antwort von jemandem an den Nachbar-Cache), die in seinem eigenen fache gespeichert ist, aus einem Satz von 2-Tupeln in Form (url_x, t_x) besteht. Jeder von diesen wird in der Antwort der Nachricht gesendet, außer wenn url_x = url_i und t_x <= t_i ist. Mit anderen Worten, dies bedeutet, sende (url_x, t_x), außer wenn die Tabelle für den fache i, dargestellt mit (url_i, t_i) vorschlägt, dass der fache i eine gleichermaßen alte oder jüngere Version des Dokuments hat.
Der voranstehend beschriebene Mechanismus der 4 kann für den Fall eines IASP, bei dem zahlreiche Peer-Caches existieren, wobei jeder von diesen an dem Inhalt von jedem anderen fache interessiert ist, stromlinienförmig gemacht werden. In diesem Mechanismus, der in 5 dargestellt ist, wird Information, die ein fache über den Inhalt von anderen Caches gesammelt hat, zusätzlich zu dem Inhalt auf seinem eigenen fache beim Zusammenstellen von Nachrichten an irgendeinen gegebenen fache ebenfalls verwendet. Dieser Mechanismus verringert weiter einen Zusatz, weil jeder fache nicht direkt Nachrichten mit sämtlichen anderen Caches austauschen muss. Er muss auch nur einen einzelnen Zustand für das gesamte Caching-System aufrechterhalten, anstelle separat den Zustand von jedem Peer-Cache aufrecht zu erhalten; wobei die Summe der Zustandsinformation auf sämtlichen Caches viel größer als der Zustand des gesamte Caching-Systems ist. Solange wie der Satz von Caches direkte oder indirekte Verbindungen aufweisen, wird dieser Mechanismus theoretisch in der Lage sein Information auf sämtlichen Caches richtig zu verteilen. In graphen-theoretischer Hinsicht würde dieser Mechanismus funktionieren, solange wie die Zwischen-Cache-Kommunikationskanäle die Caches in einem „Baum" verknüpfen. Um irgendeinen Ausfall von Caches und Kommunikations-Kanälen zu verhindern und Ende-zu-Ende Kommunikationsverzögerungen zu reduzieren könnte ein „zwei-verbundener" oder „drei-verbundener" Baum besser geeignet sein, wobei ein „k-verbundener" Baum einer ist, bei dem der Satz von Knoten noch verbunden bleibt, wenn irgendwelche (k-1) von seinen Verknüpfungen zerstört werden.
Da dieser Mechanismus Information auf anderen Caches in seinen Nachrichten verteilt, müssen die Nachrichten, die zwischen Caches übertragen werden, von den 2-Tupeln des voranstehend beschriebenen Mechanismus auf einen 3-Tupel der Form (url_i, t_i, c_i) erweitert werden, wobei t_i der Cache ist, der tatsächlich das Objekt gespeichert hat, welches mit url_i bezeichnet wird, und wobei, wie zuvor, t_i die modifizierte Zeit des Objekts url_i ist. In denjenigen Fällen, bei denen mehrere Caches gleich alte Objekte aufweisen, ist der letzte Posten in dem 3-Tupel selbst ein Satz von Caches. In 5 gilt: Jedesmal, wenn eine Nachricht (503 oder 504) von einem Cache 501 oder 502 an dem anderen ankommt, bestehend aus einer Liste von Posten der Form (url, t, c), wenn url = url_i und t > t_i, ersetze (url_i, t_i, c_i) durch (url, t, c) in der Zustandstabelle. Wenn jedoch url = url_i und t = t_i ist, anhängen von c an den Satz c_i, wenn c nicht bereits in dem Satz c_i vorhanden ist. Es sei angenommen, dass die Liste von neuen URLs (seit der letzten Antwort von jemanden an die Nachbar-Cache), die jemand kennt, aus einem Satz von 3-Tupeln der Form (url_x, t_x, c_x) besteht. Jede von diesen wird in der Antwort der Nachricht gesendet, außer wenn c_x ∈ c_i ist. Somit ist, wie in 5 angegeben, die Nachricht, die an den Nachbar-Cache im Ansprechen auf einen Empfang eines Satzes von modifizierten URLs von diesem Nachbar-Cache gesendet wird, eine Liste von URLs, die derart neu auf dem Caching-System sind, außer wenn der Nachbar, an den die Antwort gerichtet ist, die jüngste Version der URL aufweist.
Der voranstehend beschriebene Mechanismus kann in vielerlei Vorgehensweisen implementiert werden. Eine mögliche Implementierung des RQC-initiierten Mechanismus wird nachstehend beschrieben. Dieser Mechanismus wird durch Definieren eines neuen Verfahrens realisiert, welches CONTENTS an dem Hyper Text Transfer Protocol (HTTP) bezeichnet wird. Alternative Auslegungen sind möglich, die einen getrennten Protokollstapel verwenden können, außerhalb von HTTP.
6 zeigt den Protokollmechanismus für einen RQC-initiierten Benachrichtigungsmodus zwischen RQC 601 und RSC 602. In der Anforderung (Request), die an den RSC für Information über spezifische URLs gerichtet wird, ist die HTTP/1.0 und HTTP/1.1 Syntax für die Anforderungs-Zeile (Request-Line) folgendermaßen:
Request-Line = Method SP (space) Request-URL SP HTTP-Version
CRLF (Carriage Return Line Feed)
und die Syntax für die Anforderungs-URL (Request-URL) ist folgendermaßen:
Request-URL = "*" |absolute URL |abs-path
Dies erlaubt nicht den kompletten Satz von URLs auszudrücken. "*" wird deshalb als die Anforderungs-URL gewählt, was zwangsläufig bedeutet, dass sich die Anforderung per Voreinstellung auf sämtliche Inhalte des bedienenden Caches oder des RSC bezieht. Die Anforderungs-Zeile (Request-Line) ist somit:
Request-Line = "CONTENTS" SP "*" SP HTTP-Version CRLF
Das wenn-modifiziert-seit (If-Modified-Since) Feld in dem Anforderungs-Header wird verwendet, um zu spezifizieren, dass nur diejenigen Inhaltsänderungen, die nach dem Datum stattgefunden haben, das von dem wenn-modifiziert-seit Feld spezifiziert wird, von Interesse sind. Dieses Feld ist eine Abweichung von der Vorgehensweise, in der dieses Feld normalerweise in dem HOLEN (GET) Verfahren verwendet wird. In dem letzteren spezifiziert das IMS Feld, dass das Dokument nur von Interesse ist, wenn die tatsächliche Modifikationszeit jünger als das IMS Feld ist. Hier wird das IMS Feld verwendet, um ein Interesse an dem Dokument nur dann anzuzeigen, wenn das Dokument an dem Cache seit der IMS Zeit modifiziert worden ist. Das Bereichs-Feld (Range-Field) wird verwendet, um die URLs zu spezifizieren, die von Interesse sind. Dies ist ein Feld, dessen Syntax in HTTP/1.1 spezifiziert werden muss und es würde wünschenswert sein, wenn sämtliche regulären Ausdrücke von diesem Feld ausgedrückt werden könnten. Wenn dies unzureichend sein sollte, muss unter Umständen ein neues Feld für diesen Zweck erzeugt werden. Was hier benötigt wird ist, dass dann, wenn ein RQC nur Interesse an einigen gewählten HTML Seiten hat, zum Beispiel allen HTML Seiten der New York Times mit Ausnahme von denjenigen des Sportteils, und den JPEG Bildern des Louvres, er in der Lage sein sollte diese Gemeinsamkeit unter Verwendung des Bereichs-Felds (Range-Field) zu spezifizieren. Schließlich wird das Außer-Feld (Unless-Field) verwendet, um irgendeine andere Einschränkung zu spezifizieren, die der Cache auf die URLs anwenden möchte, für die er sich interessiert. Der neue Anwendungs-Typ, der als Anwendung/www-Inhalte (application/www-contents) bezeichnet wird, wird ebenfalls definiert, um die Antwort zu unterstützen, die der antwortende Cache zurückgibt.
In 6 ist in der Anforderung 603 die Anforderungs-Zeile (Request-Line) folgendermaßen:
CONTENTS * HTTP/1.0
wobei CONTENTS (INHALTE) das Verfahren ist, das eine Liste von URLs anfordert, das "*" bedeutet, dass das Verfahren durch ein Protokoll gesteuert wird, und das HTTP/1.0 dieses Protokoll ist. Dieser Zeile folgt ein CRLF (Carriage Return Line Feed). Die nächste Zeile ist:
Accept: application/www-contents
was bedeutet, dass dann, wenn der RSC dem RQC eine Antwort in Übereinstimmung mit dieser definierten Anwendung sendet, der RQC in der Lage sein wird sie zu verstehen. Die nächste Zeile ist:
If-Modified-Since: Sat, 29 Oct 1996 19:43:31 GTM
was bedeutet, dass nur URLs, die sich seit Samstag, 29. Oktober 1996 um 19:43:31 GMT geändert haben, von Interesse sind. Die letzte Zeile ist:
Range: http://www.nytimes.com/*
Dies definiert den Bereich von URLs, die von Interesse sind, wobei "*" anzeigt, dass sämtliche „www.nytimes.com" Objekte von Interesse sind.
Die Antwort zu dem RQC muss einem spezifischen Format folgen. Anstelle dies innerhalb des Protokolls zu definieren wird es den RSC überlassen das Format zu spezifizieren, obwohl die Format-Definition selbst eine spezifische Syntax aufweisen muss. Das Format der Contents-Datei (Inhalts-Datei) enthält eine Sequenz von Zeilen, die ASCII Zeichen abgeschlossen mit entweder der Sequenz LF (Zeilenvorschub; Line Feed) oder CRLF enthalten. Inhalts-Datei-Generatoren sollten der Zeilen-Abschluss-Konvention für die Plattform, auf der sie ausgeführt werden, folgen. Jede Zeile kann entweder eine Anweisung (Direktive) oder einen (Teil von einem) Eintrag enthalten. Einträge bestehen aus einer Sequenz von Feldern, die sich auf ein einzelnes HTTP Objekt beziehen. Wenn ein Feld in einem bestimmten Eintrag nicht verwendet wird markiert "–" das weggelassene Feld. Anweisungen (Direktiven) stellen Information über die Version, sowie Header-Felder der Objekte, die folgen, bereit. Zeilen, die mit dem # Zeichen beginnen, enthalten Anweisungen. Die folgenden Anweisungen werden definiert:

– Version: <integer>.<integer>

Die Version des erweiterten Log-Datei-Formats, das verwendet wird.

– Syntax: [<specifier>...]

Spezifiziert die Felder, die in dem Log aufgezeichnet sind. Die Ketten SP und CRLF weisen eine spezielle Bedeutung auf.

– Bemerkung: <text>

Kommentar-Information. Daten, die in diesem Feld aufgezeichnet sind, sollten durch Analyse-Werkzeuge ignoriert werden.
Die Anweisungen (Direktiven) Version und Syntax werden benötigt. Die Syntax Direktive kann mehrere Male erscheinen, mit dem Verständnis, dass sämtliche Einträge die Syntax Direktive, die darüber und zu ihnen am nächsten ist, beachten. Die Syntax Direktive spezifiziert die Daten, die in den Feldern jedes Eintrags aufgezeichnet sind.
In der Antwort-Nachricht 604 zeigt die Zeile „201 O. K." an, dass die Anforderung verstanden wurde und dass eine gültig Antwort folgt. Der Content-Type (Inhalts-Typ) auf der nächsten Zeile zeigt an, dass ein spezielles Dokument mit einer bestimmten Syntax folgt, die nicht lediglich der Art nach textartig ist. Die Anweisung #Version definiert den Typ der Syntax, spezifisch die Version 1.0. Die Anweisung #Syntax: Last-Modified CRLF URL SP Content-Length zeigt an, dass das, was folgt, das Format des zuletzt modifizierten Datums aufweisen wird, auf eine nächste Zeile, die URL, die an dem RSC 602 modifiziert worden ist, gefolgt von einem Leerzeichen und der Größe des Objekts in Bytes. Somit zeigt die Antwort 604 an, dass die zwei Objekte mit der Anforderung 603 übereinstimmten. Das erste Objekt weist die URL http:://www.nytimes.com/index.html auf, die zuletzt in dem RSC 602 am Samstag, 29. Oktober 1996 um 10:54:02 GMT modifiziert worden ist, und eine Länge von 575 Bytes aufweist. Das zweite Objekt weist eine URL von http://www.nytimes.com/info/textpath.html auf, die zuletzt in dem RSC 602 am Samstag, dem 29. Oktober 1996 um 19:56:34 GMT modifiziert worden ist und eine Länge von 4096 Bytes aufweist.
Der RQC 601 empfängt die Antwort 604 und wählt, welche Objekte von dem RSC 602 zu HOLEN (GET) sind. Somit, wie in 6 angegeben, gibt der RQC 401 eine Anforderung 605 zum HOLEN (GET) von http://www.nytimes.com/info/textpath.html HTTP/1.0 von dem RSC 602 aus. Der RSC 602 füllt danach diese Anforderung aus, indem er den Körper dieses Objekts zurück an den RQC 601 sendet.
Obwohl in Verbindung mit benachbarten Caches innerhalb eines IASP beschrieben könnte die vorliegende Erfindung zum Austauschen von Information über Objekte, die in Caches auf Web Browsern gespeichert sind, oder zwischen Caches auf Web Browsern und Caches innerhalb eines IASP oder zwischen Caches, die miteinander innerhalb von irgendwelchen Orten oder zwischen irgendwelchen Orten kommunizieren können, verwendet werden.
Die voranstehend beschriebenen Ausführungsformen illustrieren die Prinzipien der vorliegenden Erfindung. Andere Ausführungsformen können von Durchschnittsfachleuten ohne Abweichen von dem Umfang der vorliegenden Erfindung erdacht werden.

Claims

Verfahren zur Verwendung in einem System, umfassend wenigstens einen ersten (201; 301; 401; 501; 601) und einen zweiten (203; 303; 402; 502; 602) untereinander verbundenen Web Cache auf einem Paketdatennetz umfasst, wobei die ersten und zweiten Web Caches jeweilige erste und zweite Vielzahlen von Web Objekten speichern, die von einer Vielzahl von Client-Terminals, die mit jedem Web Cache verbunden sind, zurückgewonnen werden können, wobei die Web Objekte, die in den ersten und zweiten Web Caches gespeichert sind, Kopien von Web Objekten sind, die von Web Servern empfangen werden, die auf dem Paketdatennetz verbunden sind, wobei das Verfahren durch die folgenden Schritte gekennzeichnet ist: Empfangen eines ersten Signals (202; 302; 403, 405; 503, 505; 603) an dem zweiten Web Cache (203; 303; 402; 502; 602) von dem ersten Web Cache (201; 301; 401; 501; 601), der eine Anforderung für die Identität einer Vielzahl von Web Objekten, die in dem zweiten Web Cache gespeichert sind, einschließt; Übertragen eines zweiten Signals (204; 305, 307, 309; 404; 504; 604) von dem zweiten Web Cache an den ersten Web Cache (201; 301; 401; 501; 601), wobei dieses zweite Signal die angeforderte Information, die sich auf die Identität einer Vielzahl von Web Objekten bezieht, die in dem zweiten Web Cache gespeichert sind, bereitstellt; und Empfangen an dem zweiten Web Cache (203; 303; 402; 502; 602) einer Anforderung, von dem ersten Web Cache, für eine Kopie eines bestimmten Web Objekts, wenn das zweite Signal anzeigt, dass das bestimmte Web Objekt in der Vielzahl von Web Objekten, die in dem zweiten Web Cache gespeichert sind, eingeschlossen ist; und Bereitstellen einer Kopie des bestimmten Web Objekts an dem ersten Web Cache (201; 301; 401; 501; 601) im Ansprechen auf die Anforderung für eine Kopie des bestimmten Web Objekts, das in dem zweiten Web Cache (203; 303; 402; 502; 602) gespeichert ist.
Verfahren nach Anspruch 1, wobei das erste Signal (202; 302; 403, 405; 503, 505; 603) asynchron in Bezug auf eine Anforderung für eine Kopie eines bestimmten Web Objekts durch ein Client-Terminal, das mit entweder dem ersten (201; 301; 401; 501; 601) oder zweiten (203, 303; 402; 502; 602) Web Cache verbunden ist, empfangen wird.
Verfahren nach Anspruch 1, wobei die angeforderte Information, die sich auf Web Objekte bezieht, die in dem zweiten Web Cache (203; 303; 402; 502; 602) gespeichert ist, ferner Information in Bezug auf die Zeit, zu der jedes Web Objekt in dem zweiten Web Cache modifiziert wurde, umfasst.
Verfahren nach Anspruch 3, wobei die angeforderte Information in Bezug auf Web Objekte, die in dem zweiten Web Cache (203; 303; 402; 502; 602) gespeichert sind, ferner Information in Bezug auf die Größe eines Web Objekts in dem zweiten Web Cache umfasst.
Verfahren nach Anspruch 1, wobei das erste Signal (202; 302; 403, 405; 503, 505; 603) ferner eine Registrierungsaufforderung für Information bezüglich darüber, wann Web Objekte in dem zweiten Web Cache (203; 303; 402; 502; 602) modifiziert werden, umfasst.
Verfahren nach Anspruch 5, wobei das zweite Signal (204; 305, 307, 309; 404; 504; 604) übertragen wird, wenn ein Web Objekt in dem zweiten Web Cache (203; 303; 402; 502; 602) modifiziert wird.
Verfahren nach Anspruch 5, wobei das zweite Signal auf einer periodischen Basis übertragen wird.
Verfahren nach Anspruch 1, wobei das erste Signal (202; 302; 403, 405; 503, 505; 603) Information in Bezug auf einen Satz von Web Objekten, die in dem ersten Web Cache (201; 301; 401; 501; 601) modifiziert worden sind, umfasst und das zweite Signal (204; 305, 307, 309; 404; 504; 604) Information in Bezug auf einen Satz von Web Objekten, die in dem zweiten Web Cache (203; 303; 402; 502; 602) modifiziert worden sind, umfasst.
Verfahren nach Anspruch 8, ferner umfassend: Aktualisieren von Zustandsinformation, die an dem zweiten Web Cache gespeichert wird und sich auf Web Objekte bezieht, die in dem ersten Web Cache (201; 301; 401; 501; 601) gespeichert sind, im Ansprechen auf Information in dem ersten Signal (204; 305, 307, 309; 404; 504; 604) in Bezug auf Web Objekte, die in dem ersten Web Cache modifiziert worden sind; wobei Information in dem zweiten Signal Information in Bezug auf diejenigen Web Objekte in dem zweiten Web Cache (203; 303; 402; 502; 602), die in dem zweiten Web Cache modifiziert worden sind, nachdem derartige Web Objekte in dem ersten Web Cache (201; 301; 401; 501; 601) in Übereinstimmung mit der aktualisierten Zustandsinformation bezüglich Web Objekte, die in dem ersten Web Cache gespeichert sind, modifiziert worden sind, umfasst.
Verfahren nach Anspruch 1, wobei das Paketdatennetz wenigstens einen anderen Web Cache, der mit dem ersten (201; 301; 401; 501; 601) und zweiten Web Cache (203; 303; 402; 502; 602) untereinander verbunden ist, umfasst, wobei das Verfahren ferner die folgenden Schritte umfasst: Empfangen, an dem zweiten Web Cache (203; 303; 402; 502; 602) von dem ersten Web Cache (201; 301; 401; 501; 601), von dritten Signalen, umfassend Information in Bezug auf Web Objekte, die in dem ersten Web Cache modifiziert worden sind, und Information, die an dem ersten Web Cache verfügbar ist und sich auf Web Objekte bezieht, die in wenigstens einem anderen Web Cache in dem System als den ersten und zweiten Web Cache modifziert worden ist; Aktualisieren von Zustandsinformation, die an dem zweiten Web Cache gespeichert wird und sich auf Web Objekte bezieht, die in dem ersten Web Cache und wenigstens einem anderen Web Cache in dem System gespeichert sind, im Ansprechen auf die dritten Signale; und Übertragen von vierten Signalen an den ersten Web Cache von dem zweiten Web Cache, wobei die vierten Signale Information in Bezug auf diejenigen Web Objekte in dem zweiten Web Cache, die in dem zweiten Web Cache modifiziert worden sind, und Information, die in dem zweiten Web Cache verfügbar ist und sich auf Web Objekte bezieht, die in wenigstens einem anderen Web Cache als den ersten und zweiten Web Caches modifiziert worden sind, in Übereinstimmung mit der aktualisierten Zustandsinformation, die an dem zweiten Web Cache gespeichert wird, umfasst.