DE69915462T2 - Sehr leistungsstarker objektcache - Google Patents

Sehr leistungsstarker objektcache Download PDF

Info

Publication number
DE69915462T2
DE69915462T2 DE69915462T DE69915462T DE69915462T2 DE 69915462 T2 DE69915462 T2 DE 69915462T2 DE 69915462 T DE69915462 T DE 69915462T DE 69915462 T DE69915462 T DE 69915462T DE 69915462 T2 DE69915462 T2 DE 69915462T2
Authority
DE
Germany
Prior art keywords
key
cache
block
objects
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69915462T
Other languages
English (en)
Other versions
DE69915462D1 (de
Inventor
Peter Mattis
John Plevyak
Matthew Haines
Adam Beguelin
Brian Totty
David Gourley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Altaba Inc
Original Assignee
Inktomi Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inktomi Corp filed Critical Inktomi Corp
Application granted granted Critical
Publication of DE69915462D1 publication Critical patent/DE69915462D1/de
Publication of DE69915462T2 publication Critical patent/DE69915462T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/953—Organization of data
    • Y10S707/955—Object-oriented
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure

Description

  • GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung bezieht sich auf die Informationsausgabe und genauer auf einen Cache-Speicher für Informationsobjekte, die effizient und mit einer hohen Geschwindigkeit über ein Netz an einen Client auszugeben sind.
  • HINTERGRUND DER ERFINDUNG
  • Einige wichtige Computer-Technologien stützen sich in einem großen Umfang auf eine schnelle Ausgabe der Informationen von einem zentralen Speicherort an entfernte Vorrichtungen. Im Client/Server-Modell der Computer-Technik werden z. B. ein oder mehrere Server verwendet, um Informationen zu speichern. Die Client-Computer oder -Prozesse sind von den Servern getrennt und unter Verwendung eines Netzes mit den Servern verbunden. Die Clients fordern die Informationen von einem der Server an, indem sie eine Netzadresse der Informationen bereitstellen. Der Server lokalisiert die Informationen anhand der bereitgestellten Netzadresse und sendet sie über das Netz an den Client, wodurch die Transaktionen abgeschlossen werden.
  • Das World Wide Web ist eine populäre Anwendung des Client/Server-Modells der Computer-Technik. 1 ist ein vereinfachter Blockschaltplan der Beziehung zwischen den in einem Web-System verwendeten Elementen. Einer oder mehrere Web-Clients 10a, 10b, von denen jeder ein Computer oder ein Software-Prozess, wie z. B. ein Browser-Programm, ist, sind mit einem globalen Informationsnetz 20, das als das Internet bezeichnet wird, entweder direkt oder durch einen Vermittler, wie z. B. einen Internet-Diensteanbieter oder einen Online-Informationsdienst, verbunden.
  • Ein Web-Server 40 ist gleichermaßen durch eine Netzverbindung 42 mit dem Internet 20 verbunden. Der Web-Server 40 besitzt eine oder mehrere Internet-Netzadressen und Host-Namen in Klarschrift, die in einem vereinbarten Format zugeordnet sind, das in einem zentralen Bereichs-Namen-Server (DNS) indexiert ist. Der Server enthält Multimedia-Informationsquellen, wie z. B. Dokumente und Bilder, die den Clients auf Anforderung bereitzustellen sind. Der Server 40 kann außerdem oder alternativ Software enthalten, um derartige Quellen in Reaktion auf Anforderungen dynamisch zu erzeugen.
  • Die Clients 10a, 10b und der Server 40 kommunizieren unter Verwendung eines vereinbarten Protokolls oder mehrerer vereinbarter Protokolle, die das Format der Informationen spezifizieren, die übertragen werden. Ein Client 10a sucht die Netzadresse eines speziellen Servers unter Verwendung des DNS und stellt eine Verbindung zu dem Server unter Verwendung eines Kommunikationsprotokolls her, das als das Hypertext-Übertragungsprotokoll (HTTP) bezeichnet wird. Ein einheitlicher Fundstellenanzeiger (URL) identifiziert jedes auf dem Server 40 gespeicherte oder durch den Server 40 dynamisch erzeugte Informationsobjekt eindeutig. Ein URL ist eine Form einer Netzadresse, die den Ort der in einem Netz gespeicherten Informationen identifiziert.
  • Ein Schlüsselfaktor, der die Leistung des World Wide Web einschränkt, ist die Geschwindigkeit, mit der der Server 40 Informationen über das Internet 20 an einen Client liefern kann. Die Leistung ist durch die Geschwindigkeit, die Zuverlässigkeit und das Niveau der Überlastung des Netzweges durch das Internet, durch die Verzögerungen durch geographische Entfernungen und durch das Belastungsniveau des Servers eingeschränkt. Demzufolge kann die Zeit für eine Client-Transaktion verringert werden, indem Kopien von populären Informationsobjekten an vom Server geographisch verteilten Aufbewahrungsorten gespeichert werden. Jeder lokale Aufbewahrungsort für Objektkopien wird im Allgemeinen als ein Cache-Speicher bezeichnet. Ein Client kann in der Lage sein, schneller auf Kopien von einem typologisch nahe liegenden Cache-Speicher zuzugreifen, als es vom ursprünglichen Web-Server möglich ist, während gleichzeitig der Internet-Server-Verkehr verringert wird.
  • In einer Anordnung befindet sich der Cache-Server in einem Proxy-Server 30, wie in 1 gezeigt ist, der logisch zwischen den Clients 10a, 10b und dem Server 40 angeordnet ist. Der Proxy-Server stellt einen "Mittelsmann"-Gateway-Dienst bereit, wobei er für den Client als ein Server und für den Server als ein Client wirkt. Ein mit einem Cache-Speicher ausgerüsteter Proxy-Server wird als Proxy-Server mit Cache-Speicherung oder häufig als ein "Proxy-Cache-Speicher" bezeichnet.
  • Der Proxy-Cache-Speicher 30 unterbricht Anforderungen für Quellen, die von den Clients 10a, 10b an den Server 40 gerichtet sind. Wenn der Cache-Speicher im Proxy 30 eine Kopie der angeforderten Quelle besitzt, die bestimmte Neuheits-Einschränkungen erfüllt, antwortet der Proxy den Clients 10a, 10b, wobei er die Quelle direkt liefert. In dieser Anordnung sind die Anzahl und das Volumen der Datenübertragungen längs der Verbindung 42 im hohen Maße verringert. Im Ergebnis werden die Netzquellen oder -objekte viel schneller den Clients 10a, 10b bereitgestellt.
  • Ein Schlüsselproblem einer derartigen Cache-Speicherung ist die effiziente Speicherung, Lokalisierung und Wiedergewinnung der Objekte im Cache-Speicher. Dieses Dokument betrifft Technologien, die mit der Speicherung, der Lokalisierung und der Wiedergewinnung der Multimedia-Objekte innerhalb eines Cache-Speichers in Beziehung stehen. Die Objektspeichereinrichtung innerhalb eines Cache-Speichers wird als ein "Cache-Objekt-Speicher" oder "Objektspeicher" bezeichnet.
  • Um Umgebungen mit starkem Verkehr effektiv zu handhaben, wie z. B. das World Wide Web, muss ein Cache-Objekt-Speicher Zehn oder Hunderte von Millionen verschiedener Objekte handhaben können, während die Objekte gleichzeitig gespeichert, gelöscht und geholt werden. Demzufolge darf sich die Leistung des Cache-Speichers nicht signifikant mit der Objektanzahl verschlechtern. Die Leistung ist das treibende Ziel der Cache-Objekt-Speicher.
  • Das Auffinden eines Objekts im Cache-Speicher ist die häufigste Operation, wobei deshalb der Cache-Speicher beim Ausführen von Durchsuchungen äußerst schnell sein muss. Der Schlüsselfaktor, der die Leistung des Cache-Speichers einschränkt, ist die Suchzeit. Es ist erwünscht, einen Cache-Speicher zu besitzen, der so schnell wie möglich bestimmen kann, ob sich ein Objekt im Cache-Speicher befindet (ein "Treffer") oder nicht (ein "Fehltreffer"). In früheren Zugängen sind Cache-Speicher, die Millionen von Objekten speichern können, in den Speicherstrukturen eines herkömmlichen Dateisystems gespeichert worden. Herkömmliche Dateisysteme sind für Cache-Speicher für Multimedia-Objekte schlecht geeignet, weil sie für bestimmte Objektgrößen angepasst sind und mehrere Bewegungen der Plattenköpfe erfordern, um die Metadaten des Dateisystems zu untersuchen. Objektspeicher können eine höhere Suchleistung erreichen, indem sie DRAM-Speicher für die Aufgabe der Objektsuche widmen, weil es aber Zehn oder Hunderte von Millionen von Objekten gibt, müssen die Nachschlagetabellen des Speichers sehr kompakt sein.
  • Sobald ein Objekt lokalisiert ist, muss es effizient an den Client übertragen werden. Moderne Plattenlaufwerke bieten eine hohe Leistung, wenn sequentielle Daten gelesen und geschrieben werden, sie leiden aber an signifikanten Leistungsverzögerungen, wenn Bewegungen der Plattenköpfe zu anderen Teilen der Platte notwendig sind. Diese Bewegungen der Plattenköpfe werden als "Positionierungen" bezeichnet. Die Plattenleistung ist typischerweise durch die nominellen Positionierungen pro Sekunde des Laufwerks eingeschränkt. Um die Leistung eines Cache-Speichers zu optimieren, ist es erwünscht, die Plattenpositionierungen zu minimieren, indem zusammenhängende Blöcke der Daten gelesen und geschrieben werden.
  • Schließlich wird der Objektspeicher voll, wobei spezielle Objekte gelöscht werden müssen, um Raum für neue Inhalte zu schaffen. Dieser Prozess wird als "Speicherbereinigung" bezeichnet. Die Speicherbereinigung muss effizient genug sein, damit sie kontinuierlich ablaufen kann, ohne eine signifikante Verringerung der Systemleistung zu schaffen, während Objekte entfernt werden, die den kleinsten Einfluss auf die künftige Leistung des Cache-Speichers besitzen.
  • FRÜHERE ZUGÄNGE
  • In der Vergangenheit sind vier Zugänge verwendet wurden, um die Cache-Objekt-Speicher zu strukturieren: die Verwendung des natürlichen Dateisystems, die Verwendung eines "Seiten"-Cache-Speichers mit Speicherblöcken, die Verwendung einer Datenbank und die Verwendung einer kreisförmigen "Zyklon"-Speicherstruktur. Jeder dieser früheren Zugänge besitzt signifikante Nachteile.
  • Der Zugang des natürlichen Dateisystems verwendet das Dateisystem eines Betriebssystems, das auf dem Server abläuft, um einen Cache-Speicher zu erzeugen und zu managen. Die Dateisysteme sind für eine spezielle beabsichtigte Anwendung konstruiert: das Speichern und das Wiedergewinnen von Anwender- und System-Datendateien. Die Dateisysteme sind für Dateimanagementanwendungen konstruiert und optimiert. Sie sind optimiert für typische Datendateigrößen und für eine relativ kleine Anzahl von Dateien (sowohl gesamt als auch innerhalb des Ordners/Verzeichnisses). Die herkömmlichen Dateisysteme sind nicht optimiert, um die Anzahl der Positionierungen bzw. Suchvorgänge zu minimieren, um Dateien zu öffnen, zu lesen/zu schreiben und zu schließen. Viele Dateisysteme erleiden signifikante Leistungsnachteile, um Dateien zu lokalisieren und zu öffnen, wenn eine große Anzahl von Dateien vorhanden ist. Typische Dateisys teme leiden an der Fragmentierung, wobei kleine Plattenblöcke über die Plattenoberfläche verstreut sind, wobei dies die Anzahl der Plattenpositionierungen vergrößert, die erforderlich sind, um auf die Daten zuzugreifen, und Speicherraum verschwendet. Die Dateisysteme sind außerdem für das Management von Anwenderdatendateien konstruiert, sie enthalten Einrichtungen, die für Cache-Objekt-Speicher irrelevant und in der Tat für diese Anwendung kontraproduktiv sind. Beispiele enthalten: die Unterstützung für den Direktzugriff und die wahlweise Modifizierung, die Dateivorrechte, die Unterstützung für das Bewegen von Dateien, die Unterstützung für das Umbenennen von Dateien und die Unterstützung für das Anhängen an Dateien während der Zeit. Die Dateisysteme investieren außerdem auf Kosten der Leistung eine signifikante Energie, um jeden Datenverlust zu minimieren und das Dateisystem nach einem Ausfall zu rekonstruieren, beides zum Schreibzeitpunkt. Das Ergebnis ist, dass Dateisysteme relativ schlecht sind, um Millionen von Dateien zu handhaben, die in einem Cache-Speicher von Web-Objekten vorhanden sein können. Die Dateisysteme unterstützen die große Variation in der Größe von Internet-Multimediaobjekten nicht effizient – insbesondere unterstützen sie typischerweise sehr kleine Objekte oder sehr große Objekte nicht effizient. Die Dateisysteme erfordern eine große Anzahl von Plattenpositionierungen, um die Metadaten zu durchlaufen, und für die Blockverkettung, sie unterstützen die Speicherbereinigung schlecht und sie erfordern Zeit, um die Datenintegrität sicherzustellen und die Dateisysteme beim Neustart zu reparieren.
  • Der Seiten-Cache-Speicher erweitert Dateisysteme mit einer Menge von Speicherpuffern mit fester Größe. Die Daten werden vor der Übertragung über das Netz in diese Puffer eingespeichert und aus diesen Puffern ausgespeichert. Dieser Zugang verschwendet signifikanten Speicher für große Objekte, die über langsame Verbindungen gesendet werden.
  • Der Zugang des Datenbanksystems verwendet ein Datenbanksystem als einen Cache-Speicher. Im Allgemeinen sind Datenbanken strukturiert, um Ziele zu erreichen, die sie für die Verwendung als ein Objekt-Cache-Speicher ungeeignet machen. Sie sind z. B. strukturiert, um die Transaktionsverarbeitung zu optimieren. Um die Integrität jeder Transaktion zu erhalten, verwenden sie eine umfassende Sperrung. Im Ergebnis bevorzugen sie als ein Konstruktionsziel die Datenintegrität gegenüber Leistungsfaktoren, wie z. B. der Geschwindigkeit. Im Gegensatz ist es für einen Objekt-Cache-Speicher, annehmbar, gelegentlich Daten zu verlieren, vorausgesetzt, dass der Cache-Speicher keine Objekte verfälscht, weil die Daten immer von dem Server wiedergewonnen werden können, die ursprüngliche Quelle der Daten ist. Die Datenbanken sind oft für eine schnelle Schreibleistung optimiert, weil die Schreibgeschwindigkeit die Verarbeitungsgeschwindigkeit der Transaktionen einschränkt. In einem Objekt-Cache-Speicher ist die Lesegeschwindigkeit jedoch gleich wichtig. Ferner sind die Datenbanken naturgemäß beim Speichern einer riesengroßen Vielfalt von Objektgrößen nicht gut, während sie das Streaming, die Pipeline-E/A in einem virtuellen Speicher, in effizienter Weise unterstützen. Die Datenbanken sind gewöhnlich für feste Größen der Datensatzgröße optimiert. Wo die Datenbanken variable Größen der Datensätze unterstützen, enthalten sie Unterstützung zum Aufrechterhalten der Objektbeziehungen, die redundant sind, wobei sie typischerweise langsame Seitentechniken im virtuellen Speicher verwenden, um das Streaming, die Pipeline-E/A zu unterstützen.
  • In einem Zyklon-Dateisystem sind die Daten um eine kreisförmige Speicherstruktur zugewiesen. Wenn der Raum voll wird, werden die ältesten Daten einfach entfernt. Dieser Zugang erlaubt eine schnelle Zuordnung der Daten, er macht es aber schwierig, große Objekte zu unterstützen, ohne sie zuerst in den Speicher einzuspeichern, er leidet an Problemen mit der Fragmentierung der Daten und er hat typischerweise eine naive Speicherbereinigung zur Folge, die das älteste Objekt, ungeachtet seiner Popularität, hinauswirft. Für einen anspruchslosen aktiven Cache-Speicher mit einer abweichenden Arbeitsmenge kann eine derartige Speicherbereinigung nach dem Siloprinzip Objekte hinauswerfen, bevor sie wieder verwendet werden.
  • Das grundlegende Problem bei den obigen Zugängen für die Konstruktion von Cache-Objekt-Speichern ist, dass die Lösung für die Zwänge des Problems nicht optimiert ist. Diese Zugänge stellen alle die erneute Anwendung vorhandener Technologien auf eine neue Anwendung dar. Keine der obigen Anwendungen ist ideal für die eindeutigen Beschränkungen von Multimedia-, Streaming- und Objekt-Cache-Speichern geeignet. Die obigen Lösungen belasten die Objekt-Cache-Speicher nicht nur inhärent mit Ineffizienzen, die auf ihre fehlerhafte erneute Anwendung zurückzuführen sind, sondern sie sind außerdem ungeeignet, um die eindeutigen Anforderungen von Multimedia-Objekt-Cache-Speichern zu unterstützen. Diese eindeutigen Anforderungen enthalten die Fähigkeit, redundante Inhalte, die völlig gleich sind, aber verschiedenen Namen besitzen, zu erkennen und gemeinsam zu verwenden, und die entgegengesetzte Fähigkeit, mehrere Varianten von Inhalten mit dem gleichen Namen zu speichern, die auf bestimmte Clients, Sprachen, Datentypen usw. abzielen.
  • Aus EP-A-0811939 ist ein Verfahren zum Vertreten und Umcodieren von Dokumenten in einem verteilten Netz bekannt, in dem ein in Reaktion auf eine Anforderung vom Client von einem entfernten Server wiedergewonnenes Web-Dokument unter Verwendung gespeicherter Information umcodiert wird, die sich auf das angeforderte Dokument beziehen. Das Dokument wird für verschiedene Zwecke umcodiert, die das Überlisten von in dem Dokument gefundenen Programmfehlern oder Eigenarten, die Größenänderung des Dokuments für die Anzeige auf einem Fernsehgerät, die Verbesserung des Übertragungswirkungsgrades und die Verringerung der Latenzzeit enthalten.
  • Basierend auf dem Vorangehenden gibt es einen deutlichen Bedarf, einen Objekt-Cache-Speicher zu schaffen, der die Nachteile dieser früheren Zugänge überwindet und der für die eindeutigen Anforderungen von Multimedia-Objekt-Cache-Speichern ideal geeignet ist. Insbesondere gibt es:
    • 1. einen Bedarf an einem Objektspeicher, der Hunderte von Millionen von Objekten mit ungleichartiger Größe und ein Terabyte der Inhaltsgröße in einer speichereffizienten Weise speichern kann;
    • 2. einen Bedarf an einem Objektspeicher, der ohne zeitraubende Durchsuchungen der Dateiverzeichnisse schnell bestimmen kann, ob ein Dokument ein "Treffer" oder ein "Fehltreffer" ist;
    • 3. einen Bedarf an einem Cache-Speicher, der die Anzahl der Plattenpositionierungen minimiert, um Objekte zu lesen und zu schreiben;
    • 4. einen Bedarf an einem Objektspeicher, der das effiziente Streaming der Daten zu dem und von dem Cache-Speicher erlaubt;
    • 5. einen Bedarf an einem Objektspeicher, der mehrere verschiedene Versionen anvisierter Alternativen für den gleichen Namen unterstützt;
    • 6. einen Bedarf an einem Objektspeicher, der eine große Anzahl von Objekten ohne Inhaltsverdoppelung effizient speichert;
    • 7. einen Bedarf an einem Objektspeicher, in dem schnell und effizient die Speicherbereinigung ausgeführt werden kann, die Dokumente verständnisvoll auswählt, die zu ersetzen sind, um die Reaktionsgeschwindigkeit für den Anwender zu verbessern und den Verkehr zu verringern;
    • 8. einen Bedarf an einem Objektspeicher, der nach einem Software- oder Hardware-Auswahl ohne Datenverfälschungen und mit minimalem Datenverlust innerhalb von Sekunden mit der vollen Betriebskapazität neugestartet werden kann.
  • Dieses Dokument betrifft die Technologie, die vorangehenden Ziele zu erreichen. Insbesondere beschreibt dieses Dokument Verfahren und Strukturen, die mit einer zeiteffizienten und raumeffizienten Speicherung, Wiedergewinnung und Wartung von Objekten in einem großen Objektspeicher in Beziehung stehen. Die hierin beschriebene Technologie sorgt für einen Cache-Objekt-Speicher für eine Hochleistungsanwendung bei hoher Last, der die folgenden allgemeinen Eigenschaften besitzt:
    • 1. eine hohe Leistung, gemessen in einer niedrigen Latenzzeit und einem hohen Durchsatz für Objektspeicher-Operationen und einer großen Anzahl von gleichzeitigen Operationen;
    • 2. die Unterstützung eines großen Cache-Speichers, der Terabyte-Cache-Speicher und Milliarden von Objekten unterstützt, um die exponentielle Wachstumsrate des Internets handzuhaben;
    • 3. Speicherraum-Effizienz, damit teurer Halbleiterspeicher sparsam und effektiv verwendet wird;
    • 4. Plattenspeicher-Effizienz, damit große Zahlen von Kopien von Internet-Objekten innerhalb der begrenzten Plattenkapazität des Objektspeichers gespeichert werden können;
    • 5. Aliasfreiheit, sodass mehrere Objekte oder Objektvarianten mit verschiedenen Namen, aber mit den gleichen inhaltsgleichen Objektinhalten, Objektinhalte besitzen, die nur einmal im Cache-Speicher gespeichert sind und unter den verschiedenen Namen gemeinsam verwendet werden;
    • 6. Unterstützung für Multimedia-Heterogenität, die verschiedene Multimedia-Objekte aus einer großen Zahl von Typen mit Größen effizient unterstützt, die über sechs Größenordnungen von wenigen hundert Bytes zu Hunderten von Megabytes reichen;
    • 7. eine schnelle Speicherbereinigung, die sich der Verwendung bewusst ist, damit weniger nützliche Objekte effizient aus dem Objektspeicher entfernt werden können, um Raum für neue Objekte zu schaffen;
    • 8. Datenkonsistenz, damit Programmfehler und Hardware-Ausfälle nicht zu verfälschen Daten führen;
    • 9. schnelle Neustartfähigkeit, damit ein Objekt-Cache-Speicher innerhalb von Sekunden nach dem Neustart beginnen kann, Anforderungen zu bearbeiten, ohne eine zeitraubende Operation zur Überprüfung der Datenbank oder des Dateisystems zu erfordern;
    • 10. Streaming, damit große Objekte effizient im Pipelinemodus vom Objektspeicher zu langsamen Clients übertragen werden können, ohne das ganze Objekt in den Speicher einzuspeichern;
    • 11. Unterstützung für Inhaltsverhandlung, damit Proxy-Cache-Speicher Varianten von Objekten für den gleichen URL, die auf den Client-Browser, die Client-Sprache oder ein anderes Attribut der Client-Anforderung abzielen, effizient und flexibel speichern können; und
    • 12. universelle Anwendbarkeit, sodass die Objektspeicher-Schnittstelle ausreichend flexibel ist, um die Anforderungen künftiger Medientypen und Protokolle zu erfüllen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Die vorliegende Erfindung wendet sich den vorangehenden Notwendigkeiten und anderen Notwendigkeiten zu, wobei sie in einem Aspekt einen Cache-Speicher für Informationsobjekte, die durch Schlüsselwerte, die auf den Namen der Informationsobjekte basieren, identifiziert werden, schafft, wobei der Cache-Speicher eine Tag-Tabelle, die die Informationsobjekte unter Verwendung einer Menge von Unterschlüsselwerten indexiert, die auf den Schlüsselwerten basieren, eine Verzeichnistabelle, die mehrere Blöcke besitzt, die durch zweite Unterschlüsselwerte, die auf den Schlüsselwerten basieren, auf die Mengen in der Tag-Tabelle indexiert werden, und Datenspeicherbereiche auf die durch die Blöcke in der Verzeichnistabelle Bezug genommen wird, umfasst, wobei ein Verfahren zum Ausgeben eines angeforderten Informationsobjekts vom Cache-Speicher in einem Server an einen Client die folgenden Schritte umfasst: Empfangen eines Namens, der ein angefordertes Informationsobjekt identifiziert; Berechnen eines Schlüsselwertes mit fester Größe, wobei der Schlüsselwert mehrere Unterschlüssel umfasst, basierend auf dem Namen; Suchen des angeforderten Informationsobjekts in einer Verzeichnistabelle unter Verwendung der Unterschlüssel als Suchschlüssel; und Wiedergewinnen einer Kopie des angeforderten Informationsobjekts aus den Datenspeicherbereichen unter Verwendung einer Referenz, die in einem Anpassungsblock in der Verzeichnistabelle enthalten ist.
  • Ein Merkmal dieses Aspekts umfasst die Schritte des Auswählens einer Version des angeforderten Informationsobjekts aus einer Liste in dem Cache-Speicher, die mehrere Versionen der angeforderten Informationsobjekte enthält; des Identifizierens eines Speicherplatzes des angeforderten Informationsobjekts in dem Cache-Speicher auf der Grundlage eines Objektschlüssels, der in der Liste in Zuordnung zu der ersten Version gespeichert ist; des Wiedergewinnens des angeforderten Informationsobjekts aus dem Speicherplatz; und des Ausgebens des angeforderten Informationsobjekts an den Client.
  • Ein weiteres Merkmal umfasst das Speichern der Informationsobjekte zusammenhängend in einer Massenspeichervorrichtung. Ein noch weiteres Merkmal ist das Speichern jedes der Informationsobjekte in einem zusammenhängenden Pool der Massenspeichervorrichtung. Ein noch weiteres Merkmal ist das Speichern jedes der Informationsobjekte in einem von mehreren Arenen in dem Pool. Ein weiteres Merkmal ist das Speichern jedes der Informationsobjekte in einem oder mehreren Fragmenten, die von Arenen zugewiesen werden.
  • Gemäß einem weiteren Merkmal sind die Fragmente, die ein Informationsobjekt enthalten, durch den vorhergehenden Fragmentschlüssel verknüpft. Ein weiteres Merkmal umfasst Speichern der Liste zusammenhängend mit jeder der mehreren Versionen des angeforderten Informationsobjekts; in jedem der Blöcke Speichern eines Größenwertes des angeforderten Informationsobjekts in Zuordnung zu einem solchen Block, wobei der Größenwert eine Speichergröße der Liste sowie die mehreren Versionen des Informationsobjekts angibt; und wobei der Schritt (D) den Schritt des gleichzeitigen Lesens der Liste und der mehreren Versionen umfasst. Ein noch weiteres Merkmal ist das Konsolidieren der mit unterschiedlichen Geschwindigkeiten erfolgenden Datenübertragungen in einem Schreibaggregationspuffer.
  • Gemäß einem noch weiteren Merkmal umfasst der Schritt des Speicherns der Informationsobjekte den Schritt, bei dem die Informationsobjekte in einen zusammenhängenden verfügbaren Speicherraum der Massenspeichervorrichtung geschrieben werden, während gleichzeitig die Schritte (A) bis (D) in Bezug auf ein weiteres Informationsobjekt ausgeführt werden.
  • Die Erfindung umfasst außerdem eine Vorrichtung, ein Computer-System, ein Computer-Programmprodukt und ein Computerdatensignal, das in einer Trägerwelle verkörpert ist, die gemäß den vorangehenden Aspekten und anderen Aspekten konfiguriert sind.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • Die vorliegende Erfindung wird beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnung veranschaulicht, in der sich gleiche Bezugszeichen auf gleiche Elemente beziehen, und worin:
  • 1 ein Blockschaltplan einer Client/Server-Beziehung ist;
  • 2 ein Blockschaltplan eines Verkehrs-Servers ist;
  • 3A ein Blockschaltplan der Umsetzung eines Objekts in einen Schlüssel ist;
  • 3B ein Blockschaltplan der Umsetzung eines Objektnamens in einen Schlüssel ist;
  • 4A ein Blockschaltplan eines Cache-Speichers ist;
  • 4B ein Blockschaltplan eines Speichermechanismus für Vektoren von Alternativen ist;
  • 4C ein Blockschaltplan einer Mehrfachsegment-Verzeichnistabelle ist;
  • 5 ein Blockschaltplan von Zeigern ist, die sich auf Datenfragmente beziehen;
  • 6 ein Blockschaltplan einer Speichervorrichtung und ihrer Inhalte ist;
  • 7 ein Blockschaltplan ist, der die Struktur eines Pools zeigt;
  • 8A ein Ablaufplan eines Prozesses der Speicherbereinigung ist;
  • 8B ein Ablaufplan eines Prozesses zum Schreiben von Informationen in einer Speichervorrichtung ist;
  • 8C ein Ablaufplan eines Prozesses der Synchronisation ist;
  • 8D ein Ablaufplan eines "checkout_read"-Prozesses ist;
  • 8E ein Ablaufplan eines "checkout_write"-Prozesses ist;
  • 8F ein Ablaufplan eines "checkout_create"-Prozesses ist;
  • 9A ein Ablaufplan eines Durchsuchungsprozesses des Cache-Speichers ist;
  • 9B ein Ablaufplan eines "checkin"-Prozesses ist;
  • 9C ein Ablaufplan eines Durchsuchungsprozesses des Cache-Speichers ist;
  • 9D ein Ablaufplan eines Löschprozesses des Cache-Speichers ist;
  • 9E ein Ablaufplan eines Leseprozesses des Cache-Speichers ist;
  • 9F ein Ablaufplan eines Schreibprozesses des Cache-Speichers ist;
  • 9G ein Ablaufplan eines Aktualisierungsprozesses des Cache-Speichers ist;
  • 10A ein Ablaufplan eines Prozesses des Zuweisens und des Schreibens von Objekten in einer Speichervorrichtung ist;
  • 10B ein Ablaufplan eines Prozesses der Aktualisierung eines skalierten Zählers ist;
  • 11 ein Blockschaltplan eines Computer-Systems ist, das verwendet werden kann, um die vorliegende Erfindung zu implementieren; und
  • 12 ein Ablaufplan eines Prozesses der erneuten Validierung eines Objekts ist.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Es ist ein Verfahren und eine Vorrichtung für die Cache-Speicherung von Informationsobjekten beschrieben. In der folgenden Beschreibung werden für den Zweck der Erklärung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu schaffen. Es ist jedoch für einen Fachmann auf dem Gebiet offensichtlich, dass die vorliegende Erfindung ohne diese spezifische Einzelheiten praktiziert werden kann. In anderen Fällen sind wohl bekannte Strukturen und Vorrichtungen in Blockschaltplanform gezeigt, um die unnötige Unverständlichkeit der vorliegenden Erfindung zu vermeiden.
  • DER VERKEHRS-SERVER
  • 2 ist ein Blockschaltplan der allgemeinen Struktur bestimmter Elemente eines Proxys 30. In einer Ausführungsform wird der Proxy 30 als ein Verkehrs-Server bezeichnet, wobei er eines oder mehrere Computer-Programme oder einen oder mehrere Computer-Prozesse umfasst, die in einem Computer-Arbeitsplatzrechner des Typs arbeiten, der im Folgenden weiter beschrieben ist. Ein Client 10a richtet über das Internet 20 eine Anforderung 50 für ein Objekt an den Proxy 30. In diesem Kontext bedeutet der Begriff "Objekt" eine Netzquelle oder ein diskretes Informationselement, die bzw. das von einem Server ausgegeben wird. Beispiele von Objekten enthalten Web-Seiten oder -Dokumente, graphische Bilder, Dateien, Textdokumente und durch Web-Anwendungsprogramme während der Ausführung der Programme erzeugte Objekte oder andere Elemente, die in einem Server gespeichert sind, der durch das Internet 20 zugänglich ist. Alternativ ist der Client 10a durch ein anderes Netz als das Internet mit dem Proxy 30 verbunden.
  • Die ankommende Anforderung 50 kommt an einem Eingabe/Ausgabe-Kern (E/A-Kern) 60 des Proxys 30 an. Der E/A-Kern 60 arbeitet, um die Rate der vom Proxy empfangenen oder ausgegebenen Daten an die Datenübertragungsgeschwindigkeit der Verbindung zwischen den Client 10a und dem Internet 20 anzupassen. In einer bevorzugten Ausführungsform ist der E/A-Kern 60 in der Form einer kreisförmig angeordneten Menge von Originalspeicherbereichen implementiert, die zwischen den Eingabepuffern und den Ausgabepuffern angeordnet sind, die an den Proxy 30 und das Internet 20 gekoppelt sind. Die Verbindungen zwischen dem Proxy 30 und einem oder mehreren Clients 10a sind in den Originalspeicherbereichen gespeichert. Jeder Originalspeicherbereich in der Menge wird nacheinander untersucht, wobei jede Verbindung im Originalspeicherbereich abgefragt wird. Während des Abfragens wird die Menge der Informationen bestimmt, die sich in einem Puffer, der der Verbindung zugeordnet ist, seit dem letzten Abfragen angesammelt hat. Basierend auf der Menge wird ein Periodenwert, der der Verbindung zugeordnet ist, eingestellt. Die Verbindung wird dann in einem anderen Originalspeicherbereich gespeichert, der im Allgemeinen durch die Summe aus der momentanen Originalspeicherbereichsnummer und aus dem Periodenwert identifiziert wird. Das Abfragen wird mit der nächsten Verbindung und dem nächsten Originalspeicherbereich fortgesetzt. In dieser Weise stellt die verstrichene Zeit zwischen aufeinander folgenden Abfragen einer Verbindung automatisch die tatsächliche Betriebsbandbreite oder Datenübertragungsgeschwindigkeit der Verbindung ein.
  • Der E/A-Kern 60 leitet die Anforderung 50 zu einer Protokollmaschine 70, die an den E/A-Kern 60 und an einen Cache-Speicher 80 gekoppelt ist. Die Protokollmaschine 70 arbeitet, um die Anforderung 50 zu parsen und zu bestimmen, welcher Typ einer wesentlichen Handlung in der Anforderung 50 verkörpert ist. Basierend auf den Informationen in der Anforderung 50 stellt die Protokollmaschine 70 dem Cache-Speicher 80 einen Befehl bereit, um eine spezielle Operation auszuführen. In einer Ausführungsform ist der Cache-Speicher 80 in einem oder mehreren Computer-Programmen implementiert, die unter Verwendung einer Anwendungsprogrammschnittstelle (API) für die Protokollmaschine 70 zugänglich sind. In dieser Ausführungsform decodiert die Protokollmaschine die Anforderung 50 und führt einen Funktionsaufruf für die API des Cache-Speichers 80 aus. Der Funktionsaufruf enthält als Parameterwerte die aus der Anforderung 50 abgeleiteten Informationen.
  • Der Cache-Speicher 80 ist angeschlossen, um Informationen zur Protokollmaschine 70 zu schicken und von der Protokollmaschine 70 zu empfangen, und um mit einer oder mehreren nichtflüchtigen Massenspeichervorrichtungen 90a–90n in Wechselwirkung zu treten. In einer Ausführungsform sind die Speichervorrichtungen 90a–90n schnelle Plattenlaufwerke mit hoher Kapazität. Der Cache-Speicher 80 tritt außerdem mit den Datentabellen 82 in Wechselwirkung, die hierin ausführlicher beschrieben sind.
  • DIE INDEXIERUNG DES OBJEKT-CACHE-SPEICHERS
  • DIE INHALTSINDEXIERUNG
  • In der bevorzugten Ausführungsform speichert der Cache-Speicher 80 die Objekte in den Speichervorrichtungen 90a–90n. Populäre Objekte werden außerdem in einen Cache-Speicher kopiert. In der bevorzugten Ausführungsform besitzt der Cache-Speicher eine endliche Größe, wobei er im Hauptspeicher oder RAM des Proxys 30 gespeichert ist.
  • Die Objekte auf der Platte werden durch Positionsanzeiger mit festen Größen indexiert, die als Schlüssel bezeichnet werden. Die Schlüssel werden verwendet, um in die Verzeichnisse zu indexieren, die auf den Platz der Objekte auf der Platte und auf die Metadaten über die Objekte zeigen. Es gibt zwei Schlüsseltypen, die als "Namensschlüssel" und als "Objektschlüssel" bezeichnet werden. Die Namensschlüssel werden verwendet, um die Metadaten über ein benanntes Objekt zu indexieren, während die Objektschlüssel verwendet werden, um die wahren Objektinhalte zu indexieren. Die Namensschlüssel werden verwendet, um die URLs und die anderen Namen der Informationsquellen in eine Metadatenstruktur umzusetzen, die die Objektschlüssel für die Objektdaten enthält. Wie anschließend erörtert wird, unterstützt diese Indexierungsstruktur auf zwei Ebenen die Fähigkeit, mehrere alternative Objekte einem einzelnen Namen zuzuordnen, während gleichzeitig eine einzelne Kopie aller Objektinhalte auf der Platte aufrechterhalten wird, die zwischen mehreren verschiedenen Namen oder Alternativen gemeinsam verwendet wird.
  • Unähnlich anderen Cache-Speicher-Systemen, die den Namen oder den URL eines Objektes als den Schlüssel verwenden, durch den auf das Objekt Bezug genommen wird, verwenden die Ausführungsformen der Erfindung einen "Fingerabdruck" der Inhalte, die das Objekt selbst bilden, um das Objekt zu lokalisieren. Die aus den Inhalten des indexierten Objektes erzeugten Schlüssel werden hierin als die Objektschlüssel bezeichnet. Spezifisch ist der Objektschlüssel 56 ein eindeutiger Fingerabdruck oder eine komprimierte Darstellung der Inhalte des Objektes 52. Vorzugsweise ist eine Kopie des Objektes 52 als eine Eingabe in eine Hash-Funktion 54 vorgesehen, wobei ihre Ausgabe der Objektschlüssel 56 ist. Eine Datei oder eine andere Darstellung des Objektes 52 ist z. B. als eine Eingabe in die Hash-Funktion vorgesehen, die jedes Byte der Datei liest und einen Teil des Objektschlüssels 56 erzeugt, bis die ganze Datei gelesen worden ist. Auf diese Weise wird basierend auf den ganzen Inhalten des Objektes 52 anstatt auf seinem Namen ein Objektschlüssel 56 erzeugt. Weil die Schlüssel auf dem Inhalt basieren und als Indizes in die Tabellen des Cache-Speichers 80 dienen, wird der Cache-Speicher als ein inhaltsindexierter Cache-Speicher bezeichnet. Bei einem gegebenen Fingerabdruck-Schlüssel seines Inhalts können die Inhalte leicht gefunden werden.
  • In dieser Ausführungsform ermöglicht die Inhaltsindexierung dem Cache-Speicher 80, doppelte Objekte zu erfassen, die verschiedenen Namen aber die gleichen Inhalte besitzen. Derartige Duplikate werden erfasst, weil Objekte mit völlig gleichen Inhalten durch die Hash-Funktion auf den gleichen Schlüsselwert abgebildet werden, selbst wenn die Objekte verschiedene Namen besitzen.
  • Es wird z. B. angenommen, dass der Server 40 in einem Unterverzeichnis ein Software-Programm speichert, das eine ausführbare Datei mit Namen "IE4.exe" umfasst, die 10 Megabytes groß ist. Es wird ferner angenommen, dass der Server 40 in einem anderen Unterverzeichnis eine Kopie derselben Datei mit dem Namen "Internet Explorer.exe" speichert. Der Server 40 ist ein anonymer FTP-Server, der Kopien der Dateien über eine HTTP-Verbindung unter Verwendung des FTP-Protokolls ausgeben kann. In früheren Zugängen speichert, wenn einer oder mehrere Clients die zwei Dateien anfordern, speichert der Cache-Speicher eine Kopie jeder der Dateien im Cache-Speicher und indexiert jede der Dateien unter ihrem Namen im Cache-Speicher. Im Ergebnis muss der Cache-Speicher 20 Megabytes des Speichers für zwei Objekte verwenden, die mit Ausnahme des Namens völlig gleich sind.
  • In einer Ausführungsform der Erfindung erzeugt, wie hierin ausführlicher erörtert ist, der Cache-Speicher für jedes der Objekte einen Namensschlüssel und einen Objektschlüssel. Die Namensschlüssel werden erzeugt, indem eine Hash-Funktion auf den Namen des Objektes angewendet wird. Die Objektschlüssel werden erzeugt, indem eine Hash-Funktion auf die Inhalte des Objektes angewendet wird. Im Ergebniswerden für die zwei oben beschriebenen beispielhaften Objekte zwei verschiedene Namensschlüssel erzeugt, der Objektschlüssel ist jedoch der gleiche. Wenn das erste Objekt im Cache-Speicher gespeichert wird, werden sein Namensschlüssel und sein Objektschlüssel im Cache-Speicher gespeichert. Wenn danach das zweite Objekt im Cache-Speicher gespeichert wird, wird sein Namensschlüssel im Cache-Speicher gespeichert. Der Cache-Speicher erfasst jedoch den früheren völlig gleichen Objektschlüsseleintrag, wobei er keinen doppelten Objektschlüsseleintrag speichert; stattdessen speichert der Cache-Speicher eine Referenz auf den gleichen Objektschlüsseleintrag in Zuordnung zu dem Namensschlüssel, wobei er das neue redundante Objekt löscht. Im Ergebnis sind nur 10 Megabytes des Objektspeichers erforderlich. Folglich erfasst der Cache-Speicher doppelte Objekte, die verschiedenen Namen besitzen, und speichert nur eine permanente Kopie jedes derartigen Objektes.
  • 3A ist ein Blockschaltplan der verwendeten Mechanismen, um einen Objektschlüssel 56 für ein Objekt 52 zu erzeugen. Wenn der Client 10a ein Objekt 52 anfordert und das Objekt unter Verwendung der hierin beschriebenen Prozesse nicht im Cache-Speicher 80 gefunden wird, ruft der Cache-Speicher das Objekt von einem Server ab und erzeugt einen Objektschlüssel 56, um das Objekt im Cache-Speicher zu speichern.
  • Die Verzeichnisse sind die Datenstrukturen, die die Schlüssel auf die Plätze auf der Platte abbilden. Es ist ratsam, alle oder die meisten der Inhalte der Verzeichnisse im Speicher zu halten, um für schnelle Suchvorgänge zu sorgen. Dies erfordert, dass die Verzeichniseinträge klein sind und eine große Anzahl von Einträgen in einer möglichen Menge des Speichers erlauben. Weil ferner erwartet wird, dass 50% der Zugriffe nicht im Cache-Speicher gespeichert sind, sollen die Cache-Speicher-Fehltreffer schnell bestimmt werden, ohne beträchtliche Plattenpositionierungen bzw. -durchsuchungen aufzuwenden. Derartige schnelle Fehltreffer-Optimierungen eröffnen knappe Kopfbewegungen für die realen Datenübertragungen und keine erfolglosen spekulativen Suchvorgänge. Um schließlich die Suchvorvorgänge über Hash-Suchtechniken schnell zu machen, besitzen die Verzeichniseinträge eine feste Größe.
  • Die Schlüssel sind aus später beschriebenen Gründen sorgfältig strukturiert, damit sie eine feste Größe besitzen und klein sind. Außerdem sind die Schlüssel für den Zweck der Speichereffizienz und der schnellen Suchvorgänge in Unterschlüssel partitioniert. Die Fehltreffer können schnell identifiziert werden, indem die Unterschiede in nur einem kleinen Teil der Schlüssel erfasst werden. Aus diesem Grund werden die Fehltreffer schnell unter Verwendung einer Tabelle kleiner Unterschlüssel, die als eine "Tag-Tabelle" bezeichnet wird, gefiltert, anstatt die volle Verzeichnistabelle zu durchsuchen, die die vollständigen Schlüssel enthält. Außerdem können die statistischen Eigenschaften großer Bitvektoren ausgenutzt werden, um raumeffiziente Schlüssel zu erzeugen, die eine große Anzahl von Cache-Speicher-Objekten mit kleinen Raumanforderungen unterstützen.
  • Gemäß einer Ausführungsform umfasst der Objektschlüssel 56 einen Mengen-Unterschlüssel 58 und einen Tag-Unterschlüssel 59. Der Mengen-Unterschlüssel 58 und der Tag-Unterschlüssel 59 umfassen eine Teilmenge der Bits, die den vollständigen Objektschlüssel 56 bilden. Wenn z. B. der vollständige Objekt schlüssel 56 128 Bits lang ist, können die Unterschlüssel 58, 59 16 Bits, 27 Bits oder irgendein anderer Teil des vollständigen Schlüssels sein. Die Unterschlüssel 58, 59 werden in bestimmten Operationen, die im Folgenden beschrieben sind, verwendet, in denen die Unterschlüssel Ergebnisse liefern, die fast so genau sind, als ob der vollständige Schlüssel verwendet wird. In diesem Zusammenhang bedeutet "genau", dass die Verwendung der Unterschlüssel einen Treffer im Cache-Speicher auf das richtige Objekt so oft verursacht, als ob der vollständige Schlüssel verwendet wird.
  • Diese Genauigkeitseigenschaft ist als "Glätte" bekannt, wobei sie eine Eigenschaft einer bestimmten bevorzugten Teilmenge der Hash-Funktionen ist. Ein Beispiel einer Hash-Funktion, die für die Verwendung in einer Ausführungsform geeignet ist, ist die MD5-Hash-Funktion, die in B. Schneier, "Applied Cryptography" (New York: John Wiley & Sons, Inc., 2. Auflage, 1996), auf den Seiten 429–431 und 436–441 beschrieben ist. Die MD5-Hash-Funktion erzeugt aus einem Eingangsdatenstrom mit einer beliebigen Länge einen 128-Bit-Schlüssel. Im Allgemeinen werden die MD5-Hash-Funktion und andere Einweg-Hash-Funktionen im Gebiet der Kryptographie verwendet, um sichere Schlüssel für Nachrichten oder Dokumente zu erzeugen, die über sichere Kanäle zu übertragen sind. Im Allgemeinen sind die Konstruktion von Hash-Tabellen und die Suchtechniken ausführlich in D. Knuth, "The Art of Computer Programming: Vol. 3, Sorting and Searching" (Reading, MA: Addison-Wesley, 1973), auf 506–549 beschrieben.
  • DIE NAMENSINDEXIERUNG
  • Leider identifizieren die Anforderungen für Objekte typischerweise nicht die angeforderten Objekte unter Verwendung der Objektschlüssel für die Objekte. Stattdessen identifizieren die Anforderungen die angeforderten Objekte typischerweise durch den Namen. Das Format des Namens kann basierend auf der Umgebung, in der der Cache-Speicher verwendet wird, von Implementierung zu Implementierung variieren. Der Objektname kann z. B. ein Dateisystemname, eine Netzadresse oder ein URL sein.
  • Gemäß einem Aspekt der Erfindung wird der Objektschlüssel für ein angefordertes Objekt unter einem "Namensschlüssel" indexiert, der anhand des Objektnamens erzeugt wird. Folglich ist das Wiedergewinnen eines Objekts in Reaktion auf eine Anforderung ein zweiphasiger Prozess, in dem ein Namensschlüssel verwendet wird, um den Objektschlüssel zu lokalisieren, wobei der Objektschlüssel verwendet wird, um das Objekt selbst zu lokalisieren.
  • 3B ist ein Blockschaltplan der verwendeten Mechanismen, um einen Namensschlüssel 62 basierend auf einem Objektnamen 53 zu erzeugen. Gemäß einer Ausführungsform wird die gleiche Hash-Funktion 54, die verwendet wird, um die Objektschlüssel zu erzeugen, verwendet, um die Namensschlüssel zu erzeugen. Folglich werden die Namensschlüssel die gleichen Längen- und Glätteeigenschaften der Objektschlüssel besitzen.
  • Ähnlich zum Objektschlüssel 56 umfasst der Namensschlüssel 62 Mengen- und Tag-Unterschlüssel 64, 66. Die Unterschlüssel 64, 66 umfassen eine Teilmenge der Bits, die den vollständigen Namensschlüssel 62 bilden. Wenn z. B. der vollständige Namensschlüssel 62 128 Bits lang ist, können die ersten und zweiten Unterschlüssel 64, 66 16 Bits, 27 Bits oder irgendein anderer Teil des vollständigen Schlüssels sein.
  • DIE SUCHE MIT EINEM OBJEKT- ODER NAMENSSCHLÜSSEL
  • Vorzugsweise umfasst der Cache-Speicher 80 bestimmte Datenstrukturen, die im Speicher eines Computer-Systems oder in seinen nichtflüchtigen Speichervorrichtungen, wie z. B. den Platten, gespeichert sind. 4 ist ein Blockschaltplan der allgemeinen Struktur des Cache-Speichers 80. Der Cache-Speicher 80 umfasst eine Tag-Tabelle 102, eine Verzeichnis-Tabelle 110, eine Tabelle des offenen Verzeichnisses 130 und eine Menge von Pools 200a bis 200n, die unter Verwendung logischer Referenzen miteinander gekoppelt sind, wie im Folgenden weiter beschrieben ist.
  • Die Tag-Tabelle 102 und die Verzeichnistabelle 110 sind als bereichsassoziative Hash-Tabellen organisiert. Die Tag-Tabelle 102, die Verzeichnistabelle 110 und die Tabelle des offenen Verzeichnisses 130 entsprechen den in 2 gezeigten Tabellen 82. Für den Zweck der Erklärung sollte angenommen werden, dass eine Indexsuche basierend auf dem Objektschlüssel 56 ausgeführt wird. Die Tag-Tabelle 102 und die Verzeichnistabelle 110 arbeiten jedoch in der gleichen Weise, wenn sie basierend auf einem Namensschlüssel 62 durchlaufen werden.
  • Die Tag-Tabelle 102 ist eine bereichsassoziative Anordnung der Mengen 104a, 104b bis 104n. Die Tag-Tabelle ist konstruiert, damit sie klein genug ist, um in den Hauptspeicher zu passen. Es ist ihre Aufgabe, Fehltreffer schnell zu erfassen, wodurch unter Verwendung einer kleinen Teilmenge der Bits im Schlüssel eine Bestimmung ausgeführt werden kann, dass der Schlüssel nicht im Cache-Speicher gespeichert ist. Die Bezeichnung 104n wird verwendet, um anzuzeigen, dass keine spezielle Anzahl von Mengen in der Tag-Tabelle 102 erforderlich ist. Wie in dem Fall der Menge 104n gezeigt ist, umfasst jede der Mengen 104a–104n mehrere Blöcke 106.
  • In der bevorzugten Ausführungsform besitzt der Objektschlüssel 56 eine Länge von 128 Bits. Der Mengen-Unterschlüssel 58 wird verwendet, um eine der Mengen 104a–104n zu identifizieren und auszuwählen. Vorzugsweise besitzt der Mengen-Unterschlüssel 58 eine Länge von etwa 18 Bits. Der Tag-Unterschlüssel 59 wird verwendet, um auf einen der Einträge 106 innerhalb einer ausgewählten Menge Bezug zu nehmen. Vorzugsweise besitzt der Tag-Unterschlüssel 59 eine Länge von etwa 16 Bits, er kann aber in Fällen, in denen es viele Mengen gibt, so klein wie null Bits sein. In derartigen Fällen würde die Tag-Tabelle ein Bitvektor sein.
  • Der verwendete Mechanismus, um ein Element zu identifizieren oder auf ein Element Bezug zu nehmen, kann von Implementierung zu Implementierung variieren, wobei er assoziative Referenzen, Zeiger oder eine Kombination daraus enthalten kann. In diesem Zusammenhang bezeichnet der Begriff der "Referenz", dass ein Element ein anderes Element identifiziert oder auf ein anderes Element Bezug nimmt. Ein Rest-Unterschlüssel 56' umfasst die verbleibenden Bits des Schlüssels 56. Der Mengen-Unterschlüssel, der Tag-Unterschlüssel und der Rest-Unterschlüssel werden manchmal als s, t bzw. r abgekürzt.
  • Die bevorzugte Struktur der Tag-Tabelle 102, in der jeder Eintrag eine relativ kleine Menge von Informationen enthält, ermöglicht, dass die Tag-Tabelle im schnellen flüchtigen Hauptspeicher, wie z. B. dem RAM, gespeichert wird. Folglich unterstützt die Struktur der Tag-Tabelle 102 die schnelle Operation des Cache-Speichers. Andererseits enthalten die Blöcke in der Verzeichnistabelle 110 viel mehr Informationen, wie im Folgenden beschrieben ist, wobei folglich Teile der Verzeichnistabelle zu irgendeinem gegebenen Zeitpunkt im Gegensatz zum schnellen DRAM-Speicher auf Magnetplattenmedien gespeichert sein können.
  • Die Verzeichnistabelle 110 umfasst mehrere Mengen 110a–110n. Jede der Men gen 110a–110n besitzt eine feste Größe, wobei jede mehrere Blöcke 112a–112n umfasst. In der bevorzugten Ausführungsform gibt es eine vorgegebene konstante Anzahl von Mengen und eine vorgegebene konstante Anzahl von Blöcken in jeder Menge. Wie im Fall des Blocks 112n gezeigt ist, speichert jeder der Blöcke 112a–112n einen dritten Rest-Unterschlüsselwert 116, einen Plattenplatzwert 118 und einen Größenwert 120. In der bevorzugten Ausführungsform ist der Rest-Unterschlüsselwert 116 ein 27-Bit-Teil des vollständigen 128-Bit-Objektschlüssels 56, wobei er die Bits des vollständigen Objektschlüssels 56 umfasst, die von den Bits getrennt sind, die die Mengen- oder Tag-Unterschlüssel 58, 59 umfassen.
  • Bei einer Durchsuchung stimmen die im Eintrag 106 der Tag-Tabelle 102 gespeicherten Unterschlüsselwerte mit einer der Mengen 110a–110n überein oder nehmen auf diese Bezug, wie durch den Pfeil in 4 angezeigt ist, der den Eintrag 106 mit der Menge 110d verbindet. Als ein Beispiel werden der 12-Bit-Schlüssel und die ersten und zweiten Vier-Bit-Unterschlüssel betrachtet, die oben beschrieben worden sind. Es wird vorausgesetzt, dass der Mengen-Unterschlüsselwert 1111 mit der Menge 104n der Tag-Tabelle 102 übereinstimmt, und dass der Tag-Unterschlüsselwert 0000 mit dem Eintrag 106 der Menge 104n übereinstimmt. Die Übereinstimmung des Tag-Unterschlüsselwertes 0000 zeigt an, dass es einen entsprechenden Eintrag in der Menge 110d der Verzeichnistabelle 110 gibt, der dem Schlüsselpräfix 11110000 zugeordnet ist. Wenn eine der Mengen 110a–110n in dieser Weise ausgewählt wird, werden die Blöcke innerhalb der ausgewählten Menge linear durchsucht, um einen Block zu finden, wie z. B. Block 112a, der den Rest-Unterschlüsselwert 116 enthält, der mit einem entsprechenden Teil des Objektschlüssels 56 übereinstimmt. Wenn eine Übereinstimmung gefunden wird, dann gibt es fast immer einen Treffer im Cache-Speicher. Es gibt eine kleine Möglichkeit eines Fehltreffers, falls die ersten, zweiten und dritten Unterschlüssel nicht den ganzen Schlüssel umfassen. Falls es einen Treffer gibt, wird das Objekt, auf das Bezug genommen wird, dann anhand der im Block enthaltenen Informationen lokalisiert, von einer der Speichervorrichtungen 90a–90n des Cache-Speichers wiedergewonnen und dem Client 10a bereitgestellt, wie im Folgenden weiter beschrieben ist.
  • Unähnlich der Tag-Tabelle, deren Aufgabe es ist, bei der minimalen Verwendung des RAM-Speichers ausschließende Fehltreffer schnell zu bestimmen, enthält jeder Block innerhalb der Verzeichnistabelle 110 einen vollen Zeiger auf einen Plattenplatz. Das Element, auf das durch den Plattenplatzwert 118 Bezug ge nommen wird, variiert abhängig von der Quelle, von der der Schlüssel erzeugt worden ist. Wenn der Schlüssel anhand der Inhalte eines Objekts erzeugt worden ist, wie oben beschrieben worden ist, dann zeigt der Plattenplatzwert 118 den Platz eines gespeicherten Objekts 124 (oder seines ersten Fragments) an, wie in 4 im Fall des Blocks 112b gezeigt ist. Wenn der Schlüssel ein Namensschlüssel ist, dann zeigt, wie für den Block 112n gezeigt ist, der Plattenplatzwert 118 den Platz von einem oder mehreren Vektoren der Alternativen 122 an, von denen jeder einen oder mehrere Objektschlüssel für das Objekt speichert, dessen Name verwendet worden ist, um den Namensschlüssel zu erzeugen. Eine einzelne Tag-Tabelle 102 und eine einzelne Verzeichnistabelle 110 sind in 4 lediglich beispielhaft gezeigt. Zusätzliche Tabellen, die zusätzliche Ebenen der Speicherung und der Indexierung bereitstellen, können jedoch in alternativen Ausführungsformen verwendet werden.
  • In der bevorzugten Anordnung wird, wenn eine Durchsuchung des Cache-Speichers ausgeführt wird, ein Treffer oder ein Fehltreffer in der Tag-Tabelle 102 sehr schnell auftreten. Wenn es einen Treffer in der Tag-Tabelle 102 gibt, dann gibt es eine sehr hohe Wahrscheinlichkeit, dass ein entsprechender Eintrag in der Verzeichnistabelle 110 vorhanden ist. Die hohe Wahrscheinlichkeit ergibt sich aus der Tatsache, dass ein Treffer in der Tag-Tabelle 102 bedeutet, dass der Cache-Speicher ein Objekt enthält, dessen voller Schlüssel X völlig gleiche Bits mit dem empfangenen Schlüssel teilt, wobei X die Anzahl der Bits der Verkettung der Mengen- und Tag-Unterschlüssel 58 und 59 ist. Weil Fehltreffer schnell identifiziert werden können, arbeitet der Cache-Speicher 80 schnell und effizient, weil unter Verwendung der Tag-Tabelle 102 im Speicher Treffer und Fehltreffer schnell erfasst werden, ohne zu erfordern, dass die ganze Verzeichnistabelle 110 im Hauptspeicher gespeichert ist.
  • Wenn der Cache-Speicher anhand eines Objektschlüssels 56 durchsucht wird, wird der Mengen-Unterschlüssel 58 verwendet, um eine der Mengen 104a–104n in der Tag-Tabelle 102 zu indexieren. Sobald die dem Unterschlüssel 58 zugeordnete Menge identifiziert ist, wird durch die Elemente in der Menge eine lineare Suche ausgeführt, um einen Eintrag zu identifizieren, dessen Tag mit dem Tag-Unterschlüssel 59 übereinstimmt.
  • Bei einer Suche nach einem durch einen Client 10a vom Cache-Speicher 80 angeforderten Objekt 52 wird eine lineare Durchsuchung aller Elemente 106 in dieser Menge ausgeführt, wenn eine der Mengen 104a–104n unter Verwendung des Mengen-Unterschlüssels 58 ausgewählt wird. Die Durchsuchung sucht nach einer Übereinstimmung des Tag-Unterschlüssel 59 mit einem der Einträge. Wenn eine Übereinstimmung gefunden wird, dann gibt es einen Treffer in der Tag-Tabelle 102 für das angeforderte Objekt, wobei der Cache-Speicher 80 fortfährt, nach einem Treffer in der Verzeichnistabelle 110 zu suchen.
  • Als ein Beispiel wird angenommen, dass der Objektschlüssel ein 12-Bit-Schlüssel mit einem Wert von 111100001010 ist, dass der Mengen-Unterschlüssel die ersten vier Bits des Objektschlüssels umfasst, die einen Wert von 1111 besitzen, und dass der Tag-Unterschlüssel die nächsten vier Bits des Objektschlüssels umfasst, die einen Wert von 0000 besitzen. In der Produktionsverwendung würde die Anzahl der Restbits signifikant größer als die Mengen- und Tag-Bits sein, um Speicherersparnisse zu beeinflussen. Der Cache-Speicher identifiziert die Menge 15 (1111) als die Menge, um die Tag-Tabelle 102 zu untersuchen. Der Cache-Speicher sucht nach einem Eintrag innerhalb dieser Menge, der ein Tag 0000 enthält. Wenn es keinen derartigen Eintrag gibt, dann tritt in der Tag-Tabelle 102 ein Fehltreffer auf. Wenn es einen derartigen Eintrag gibt, dann fährt der Cache-Speicher fort, um die verbleibenden Bits in der Verzeichnistabelle 110 nach einer Übereinstimmung zu überprüfen.
  • DIE MEHRSTUFIGE VERZEICHNISTABELLE
  • In einer Ausführungsform enthält die Verzeichnistabelle 110 mehrere Mengen, die jede aus einer festen Anzahl von Elementen bestehen. Jedes Element enthält das Rest-Tag und einen Plattenzeiger. Große Cache-Speicher enthalten eine große Anzahl von Objekten, die eine große Anzahl von Elementen der Verzeichnistabelle erfordern. Dies kann Tabellen erzeugen, die zu groß sind, um kosteneffizient im Hauptspeicher gespeichert zu werden.
  • Falls z. B. ein Cache-Speicher mit 128 Millionen Elementen der Verzeichnistabelle konfiguriert worden ist, wobei jedes Element durch maßvolle 8 Bytes des Speichers dargestellt worden ist, würden 1 GByte des Speichers erforderlich sein, um die Verzeichnistabelle zu speichern, was mehr Speicher ist, als in modernen Arbeitsplatz-Computern üblich ist. Weil zu irgendeinem Zeitpunkt auf wenige dieser Objekte aktiv zugegriffen wird, gibt es einen Wunsch, dass die ungenügend verwendeten Einträge auf die Platte abwandern, während die höher verwendeten Einträge im Hauptspeicher gelassen werden.
  • 4C ist eine graphische Darstellung eines mehrstufigen Verzeichnismechanismus. Die Verzeichnistabelle 110 ist in die Segmente 111a, 111b, 111c partitioniert. In den bevorzugten Ausführungsformen gibt es zwei oder drei Segmente 111a–111c, obwohl eine größere Anzahl von Segmenten verwendet werden kann. Das erste Segment 111a ist das kleinste, wobei es in den Hauptspeicher passt, wie z. B. den Hauptspeicher 1106 des in 11 gezeigten Computer-Systems, das im Folgenden ausführlich erörtert ist. Die zweiten und dritten Segmente 111b, 111c sind schrittweise größer. Die zweiten und dritten Segmente 111b, 111c sind durch einen Seiten-Mechanismus mit einer Massenspeichervorrichtung 1110, wie z. B. einer Platte, gekoppelt. Die zweiten und dritten Segmente 111b, 111c lagern die Daten von der Platte seitenweise ein, falls die angeforderten Daten im Hauptspeicher 1106 nicht vorhanden sind.
  • Da auf Verzeichniselemente öfter zugegriffen wird, werden die Verzeichniselemente zu aufeinander folgenden höheren Segmenten unter den Segmenten 111a–111c des mehrstufigen Verzeichnisses bewegt. Folglich ist es wahrscheinlicher, dass Verzeichniselemente, auf die häufig zugegriffen wird, im Hauptspeicher 1106 gespeichert sind. Die populärsten Elemente erscheinen im höchsten und kleinsten Segment 111a des Verzeichnisses, wobei sie alle im Hauptspeicher 1106 vorhanden sind. Die Popularität der Einträge wird unter Verwendung eines kleinen Zählers verfolgt, der eine Länge von einigen Bits besitzt. Dieser Zähler wird aktualisiert, wie im Abschnitt DIE AKTUALISIERUNG DES SKALIERTEN ZÄHLERS beschrieben ist. Dieses mehrstufige Verzeichnis approximiert die Leistung von speicherinternen Hash-Tabellen, während es eine kosteneffektive vereinigte Speicherkapazität für Cache-Speicher mit Terabyte-Größen bereitstellt, indem inaktive Elemente auf die Platte gelegt werden.
  • DER VERZEICHNIS-SEITENAUSTAUSCH
  • Wie erörtert worden ist, ist in einer bevorzugten Ausführungsform die Verzeichnistabelle 110 als eine mehrstufige Hash-Tabelle implementiert. Teile der Verzeichnistabelle können außerhalb des Hauptspeichers auf der Platte gespeichert sein. Die Daten für die Verzeichnistabelle werden auf Abruf seitenweise auf der Platte ein- und ausgelagert. Eine bevorzugte Ausführungsform dieses Mechanismus verwendet die direkte Platten-E/A, um die zeitliche Steuerung des Seiten austauschs zu und von der Platte und die Menge der Informationen, die seitenweise ausgetauscht werden, sorgfältig zu steuern.
  • Eine weitere Ausführungsform dieses Zugangs verwendet ein Merkmal der UNIX-Betriebssysteme, um Dateien direkt in virtuelle Speichersegmente abzubilden. Bei diesem Zugang bildet der Cache-Speicher die Verzeichnistabelle unter Verwendung der Unix-Einrichtung mmap() in den virtuellen Speicher ab. Eine mmap-Anforderung mit einem Zeiger auf eine Datei oder einen Plattenplatz als Parameter wird z. B. dem Betriebssystem bereitgestellt. Die mmap-Anforderung arbeitet als eine Anforderung, um eine Datei oder einen Plattenplatz, auf die bzw. den Bezug genommen worden ist, auf einen Speicherplatz abzubilden. Danach lädt das Betriebssystem automatisch Teile der Datei oder des Plattenplatzes, auf die bzw. den Bezug genommen worden ist, von der Platte in den Speicher, wie es notwendig ist.
  • Wenn ferner der Speicherplatz aktualisiert wird oder auf den Speicherplatz zugegriffen wird, wird die Speicherversion des Objekts zurück auf die Platte geschrieben, wie es notwendig ist. In dieser Weise werden natürliche Betriebssystemmechanismen verwendet, um die Sicherungsspeicherung der Tabellen in den nichtflüchtigen Vorrichtungen zu managen. Zu irgendeinem gegebenen Zeitpunkt ist es jedoch typisch, dass sich nur ein Teil der Verzeichnistabelle 110 im Hauptspeicher befindet.
  • In einer typischen Ausführungsform sind die Verzeichnistabelle und das offene Verzeichnis unter Verwendung einer "Striping"-Technik gespeichert. Jede Menge in der Tabelle ist auf einem anderen physikalischen Plattenlaufwerk gespeichert. Die Menge 110a der Verzeichnistabelle 110 ist z. B. auf der Speichervorrichtung 90a gespeichert, die Menge 110b ist auf der Speichervorrichtung 110b gespeichert usw. In dieser Anordnung ist die Anzahl der Positionierungsoperationen, die notwendig ist, damit ein Kopf des Plattenlaufwerks an einer Menge ankommt, verringert, wobei dadurch die Geschwindigkeit und der Wirkungsgrad des Cache-Speichers verbessert werden.
  • Es sollte angemerkt werden, dass, wenn der Seitenaustausch der Daten zwischen der Platte und dem Speicher ausgeführt wird, bestimmte Vorsichtsmaßnahmen getroffen werden, um zu sichern, dass die im Speicher gespeicherten Informationen mit den entsprechenden Informationen konsistent sind, die in einer nichtflüch tigen Speichervorrichtung gespeichert sind. Diese verwendeten Techniken, um eine effiziente Konsistenz in den Objekt-Cache-Speichern bereitzustellen, sind im Kontext der Speicherbereinigung im Abschnitt mit dem Namen DIE ERZWINGUNG DER SYNCHRONISATION UND DER KONSISTENZ zusammengefasst.
  • DER VEKTOR DER ALTERNATIVEN
  • Wie oben erwähnt worden ist, ist es möglich, dass ein einzelner URL ein Objekt abbildet, das zahlreiche Versionen besitzt. Diese Versionen werden als "Alternativen" bezeichnet. In Systemen, die keinen Objekt-Cache-Speicher verwenden, werden die Versionen wie folgt ausgewählt. Der Client 10a stellt durch das Internet 20 eine HTTP-Verbindung mit dem Server 40 her. Der Client stellt die Informationen über sich selbst in einer HTTP-Nachricht bereit, die ein Objekt vom Server anfordert. Eine HTTP-Anforderung für ein Objekt enthält z. B. Kopfinformationen, die den durch den Client verwendeten Web-Browser identifizieren, die Version des Browsers, die durch den Client bevorzugte Sprache und den durch den Client bevorzugten Typ der Medieninhalte. Wenn der Server 40 die HTTP-Anforderung empfängt, extrahiert er die Kopfinformationen und wählt eine Variante des Objekts 52 basierend auf den Werten der Kopfinformationen. Die ausgewählte Alternative wird in einer Antwortnachricht zum Client 10a zurückgeschickt. Dieser Typ der Variantenauswahl wird durch das aufkommende HTTP/1.1-Hypertext-Übertragungsprotokoll unterstützt.
  • Es ist wichtig, dass ein Cache-Objekt-Speicher effizient Kopien der Alternativen für einen URL aufrechterhält. Falls ein einzelnes Objekt immer in Reaktion auf jede URL-Anforderung vom Cache-Speicher geliefert wird, kann ein Browser Inhalte empfangen, die von denen verschieden sind, die direkt von einem Server empfangen werden. Aus diesem Grund ist jeder Namensschlüssel in der Verzeichnistabelle 110 auf einen der Vektoren der Alternativen 122a–122n abgebildet, die dem Cache-Speicher 80 möglichen, eine Version eines Objekts aus mehreren in Beziehung stehenden Informationen auszuwählen. Das Objekt 52 kann z. B. eine Web-Seite sein, wobei der Server 40 Versionen des Objekts in englischer, französischer und japanischer Sprache speichern kann.
  • Jeder Vektor der Alternativen 122a–122n ist eine Struktur, die mehrere alternative Datensätze 123a–123n speichert. Jeder der alternativen Datensätze 123a–123n ist eine Struktur, die Informationen speichert, die eine alternative Version des angeforderten Objekts 52 beschreiben. Die Informationen beschreiben z. B. eine spezielle Browser-Version, eine menschliche Sprache, in der das Objekt vorbereitet worden ist, usw. Die alternativen Datensätze speichern außerdem jeder einen vollen Objektschlüssel, der ein Objekt identifiziert, das die alternative Version enthält. In der bevorzugten Ausführungsform speichert jeder der alternativen Datensätze 123a–123n die Anforderungsinformationen, die Antwortinformationen und einen Objektschlüssel 56.
  • Weil ein einzelner populärer Objektname auf viele Alternativen abgebildet sein kann, bildet in einer Ausführungsform ein Cache-Speicher einen expliziten oder impliziten Anforderungskontext mit dem Objektnamen, um die Anzahl der Elemente im Vektor zu verringern. Der Anwenderagentenkopf einer Web-Client-Anforderung (die die spezielle Browser-Anwendung anzeigt) kann z. B. mit einem Web-URL verkettet sein, um den Namensschlüssel zu bilden. Durch das Einbeziehen kontextueller Informationen direkt in den Schlüssel wird die Anzahl der Alternativen in jedem Vektor auf Kosten von mehr Einträgen in der Verzeichnistabelle verringert. In der Praxis sind die speziellen Köpfe und der implizite Kontext, die mit dem Namen des Informationsobjekts verkettet sind, konfigurierbar.
  • Diese Vektoren der Alternativen 122a–122n unterstützen die richtige Verarbeitung von verhandelten HTTP/1.1-Inhalten. Die in den Köpfen der HTTP/1.1-Nachrichten enthaltenen Anforderungs- und Antwortinformationen werden verwendet, um zu bestimmen, welcher der alternativen Datensätze 123a–123n verwendet werden kann, um eine spezielle Anforderung zu erfüllen. Wenn der Cache-Speicher 80 Anforderungen für Objekte empfängt, enthalten die Anforderungen typischerweise außer dem Namen (oder dem URL) des gewünschten Objekts Kopfinformationen. Wie oben erklärt worden ist, wird der Name verwendet, um den geeigneten Vektor der Alternativen zu lokalisieren. Sobald der geeignete Vektor der Alternativen gefunden worden ist, werden die Kopfinformationen verwendet, um den geeigneten alternativen Datensatz für die Anforderung auszuwählen.
  • Spezifisch werden im Cache-Speicher 80 die Kopfinformationen empfangen und analysiert. Der Cache-Speicher 80 versucht, die in den Kopfinformationen gefundenen Werte mit den Anforderungsinformationen von einem der alternativen Datensätze 123a–123n in Übereinstimmung zu bringen. Wenn z. B. der Cache-Speicher 80 im Kontext des World Wide Web verwendet wird, werden die Anforderungen für Objekte einem Server, der den Cache-Speicher enthält, in der Form von HTTP-Anforderungen bereitgestellt.
  • Der Cache-Speicher 80 untersucht die Informationen in einer HTTP-Anforderung, um zu bestimmen, welcher der alternativen Datensätze 123a–123n zu verwenden ist. Die HTTP-Anforderung könnte z. B. Anforderungsinformationen enthalten, die anzeigen, dass der anfordernde Client 10a ein Browser-Programm Netscape Navigator, Version 3.0, ausführt und deutschen Text bevorzugt. Unter Verwendung dieser Informationen durchsucht der Cache-Speicher 80 die alternativen Datensätze 123a bis 123n nach Antwortinformationen, die mit der Browser-Version und dem Ort des Clients aus den Anforderungsinformationen übereinstimmen. Wenn eine Übereinstimmung gefunden wird, dann ruft der Cache-Speicher den Objektschlüssel von der übereinstimmenden Alternative ab und verwendet den Objektschlüssel, um das entsprechende Objekt aus dem Cache-Speicher wiederzugewinnen.
  • Der Cache-Speicher optimiert das gewählte Objekt, indem er die in der Client-Anforderung spezifizierten Kriterien in Übereinstimmung bringt. Die Client-Anforderung kann minimale Akzeptanzkriterien (z. B. das Dokument muss ein JPEG-Bild sein oder das Dokument muss in Latein sein) spezifizieren. Die Client-Anforderung kann außerdem vergleichende Gewichtungskriterien für die Übereinstimmungen spezifizieren (wird z. B. mit einem Gewicht von 0,5 ein GIF-Bild akzeptieren, aber mit einem Gewicht von 0,75 ein JPEG-Bild bevorzugen). Die numerischen Gewichtungen werden über alle Einschränkungsachsen akkumuliert, um eine endgültige Gewichtung zu erzeugen, die optimiert wird.
  • Der Objektschlüssel wird verwendet, um das Objekt in der obenbeschriebenen Weise wiederzugewinnen. Spezifisch wird ein Unterschlüsselteil des Objektschlüssels verwendet, um eine weitere Durchsuchung der Tag-Tabelle 102 und der Verzeichnistabelle 110 einzuleiten, wobei nach einem Treffer für den Unterschlüsselwert gesucht wird. Wenn es sowohl in der Tag-Tabelle als auch in der Verzeichnistabelle einen Treffer gibt, dann wird der Block in der Verzeichnistabelle, der unter Verwendung der Unterschlüsselwerte erreicht worden ist, immer auf ein gespeichertes Objekt (z. B. das gespeicherte Objekt 124) Bezug nehmen. Folglich kann unter Verwendung des Vektors der Alternativen 122 der Cache-Speicher 80 die Anforderungen für Objekte handhaben, die mehrere Versionen besitzen, und die richtige Version an den anfordernden Client 10a ausgeben.
  • In 4 sind nur ein beispielhafter Vektor der Alternativen 122 und ein beispielhaftes gespeichertes Objekt 124 gezeigt. In der Praxis enthält der Cache-Speicher 80 jedoch irgendeine Anzahl von Vektoren und Plattenblöcken, abhängig von der Anzahl der Objekte, die indexiert werden, und der Anzahl der alternativen Versionen, die den Objekten zugeordnet sind.
  • DAS VORAUSLESEN
  • 4B ist eine graphische Darstellung, die eine Speicheranordnung für beispielhafte Vektoren der Alternativen 122a–122n zeigt. Das System versucht, das Datenobjekt kontinuierlich nach den Mieterdaten zu vereinigen. Weil die Positionierungen zeitaufwändig sind, aber sequentielle Lesevorgänge schnell sind, wird die Leistung verbessert, indem die Daten mit den Metadaten konsolidiert werden, wobei die Daten nach den Metadaten vorher geholt werden.
  • In einer der Speichervorrichtungen 90a–90n ist jeder der Vektoren der Alternativen 122a–122n an einem Platz gespeichert, der mit den gespeicherten Objekten 124a–124b zusammenhängend ist, die den im Vektor dargestellten alternativen Datensätzen 123a–123n zugeordnet sind. Ein Vektor der Alternativen 122a speichert z. B. die alternativen Datensätze 123a–123n. Der alternative Datensatz 123a speichert Anforderungs- und Antwortinformationen, die anzeigen, dass ein gespeichertes Objekt 124a, das dem alternativen Datensatz zugeordnet ist, in englischer Sprache vorbereitet ist. Ein weiterer alternativer Datensatz 123b speichert Informationen, die anzeigen, dass sein zugeordnetes gespeichertes Objekt 124b für die Verwendung mit dem Microsoft-Browser Internet Explorer vorgesehen ist. Die gespeicherten Objekte 124a, 124b, auf die durch die alternativen Datensätze 123a, 123b Bezug genommen wird, sind mit den Vektoren der Alternativen 122a–122n zusammenhängend gespeichert.
  • Der Größenwert 120 innerhalb jedes alternativen Datensatzes zeigt die Gesamtgröße in Bytes von einem der zugeordneten Vektoren der Alternativen 122a–122n und des gespeicherten Objekts 124 an. Wenn der Cache-Speicher 80 auf einen Vektor der Alternativen 122 basierend auf dem Plattenplatzwert 118 Bezug nimmt, liest der Cache-Speicher die durch den Größenwert angegebene Anzahl von Bytes. In dem Fall der Vektoren der Alternativen, die in 4B gezeigt sind, würde der Größenwert z. B. die Länge des Vektors der Alternative 122 plus die Länge seines zugeordneten gespeicherten Objekts 124a anzeigen. Demzufolge liest der Cache-Speicher 80 durch Bezugnahme auf den Größenwert sowohl den Vektor als auch das gespeicherte Objekt. In dieser Weise "liest" der Cache-Speicher 80 den Vektor der Alternativen 122 "voraus" und ruft alle Objekte 50 von den Speichervorrichtungen 90a–90n ab. Im Ergebnis werden sowohl der Vektor der Alternativen als auch die Objekte 50 unter Verwendung einer einzelnen Positionierungsoperation durch die Speichervorrichtung von der Speichervorrichtung gelesen. Folglich wird, wenn es einen Treffer im Cache-Speicher 80 gibt, in der Mehrheit der Fälle (wenn es eine einzelne Alternative gibt) das angeforderte Objekt 52 unter Verwendung einer einzelnen Positionierung von einer Speichervorrichtung wiedergewonnen.
  • Wenn der Plattenplatzwert 118 direkt auf ein gespeichertes Objekt 124 anstatt auf einen Vektor der Alternativen 122 Bezug nimmt, zeigt der Größenwert 120 die Größe des Objekts an, wie es im Plattenblock gespeichert ist. Dieser Wert wird verwendet, um die Wiedergewinnung der Objekte mit einer einzelnen Positionierung zu unterstützen, wie hierin weiter erklärt ist.
  • DAS OFFENE VERZEICHNIS
  • In einer Ausführungsform umfasst der Cache-Speicher 80 ferner ein offenes Verzeichnis 130. Das offene Verzeichnis 130 speichert mehrere verknüpfte Listen 132a–132n, die selbst aus mehreren Listeneinträgen 131a–131n bestehen. Jede der verknüpften Listen 132a–132n ist einer der Mengen 110a–110n in der Verzeichnistabelle 110 zugeordnet. Das offene Verzeichnis 130 ist im flüchtigen Hauptspeicher gespeichert. Vorzugsweise speichert jeder Listeneintrag 131a–131n des offenen Verzeichnisses 130 einen Objektschlüssel, in der die assoziative Suche nach einem Informationsobjekt unterstützt. Jedes Element innerhalb jeder verknüpften Liste 132a–132n speichert z. B. einen vollständigen Objektschlüssel 56 für ein Objekt 52.
  • Das offene Verzeichnis legt Rechenschaft über Objekte ab, die momentan Transaktionen unterzogen werden, um einen wechselseitigen Ausschluss gegen gegensätzliche Operationen zu schaffen. Das offene Verzeichnis ist z. B. beim Schützen gegen das Überschreiben oder Löschen eines Objekts nützlich, das momentan gelesen wird. Das offene Verzeichnis puffert außerdem Änderungen an der Verzeichnistabelle 110, bevor ihnen eine permanente Wirkung in der Verzeichnistabelle 110 gegeben wird. An einem geeigneten Punkt wird, wie im Folgenden erörtert ist, eine Synchronisationsoperation ausgeführt, um die im offenen Verzeichnis 130 widergespiegelten Änderungen in die Verzeichnistabelle 110 zu verschieben. Dies verhindert die Verfälschung der Verzeichnistabelle 110 im Fall eines unerwarteten Systemausfalls oder -absturzes.
  • Ferner wird in einer Ausführungsform, wenn ein Objekt vom Cache-Speicher 80 angefordert wird, das offene Verzeichnis 130 zuerst konsultiert; es wird als der wahrscheinlichste Platz betrachtet, um einen Treffer zu erzielen, weil es Referenzen auf die am kürzesten zurückliegend verwendeten Informationsobjekte enthält. Das offene Verzeichnis in dieser Form dient als ein Cache-Speicher im Hauptspeicher für die populären Daten.
  • DIE ANORDNUNG UND DIE AGGREGATION DER PLATTENDATEN
  • Nachdem auf das offene Verzeichnis 130, die Tag-Tabelle 102 und die Verzeichnistabelle 110 zugegriffen worden ist, um den Platz eines gespeicherten Objekts 124 zu bestimmen, muss das Objekt vom Speicher gelesen und zum Anwender übertragen werden, der das Objekt angefordert hat. Um den Wirkungsgrad der Leseoperationen zu verbessern, die verwendet werden, um die Objekte 50 vom Cache-Speicher 80 wiederzugewinnen, werden bestimmte Datenaggregationstechniken verwendet, wenn die Daten anfangs gespeichert werden. Wenn die Daten anfangs entsprechend den hierin beschriebenen Datenaggregationstechniken auf der Platte gespeichert werden, wird der Wirkungsgrad der nachfolgenden Lesevorgänge im hohen Maße verbessert.
  • 6 ist ein Blockschaltplan einer Datenspeicheranordnung für die Verwendung mit dem Cache-Speicher 80 und den Speichervorrichtungen 90a–90n. Eine Speichervorrichtung 90a, wie z. B. ein Plattenlaufwerk, speichert die Daten in mehreren Pools 200a–200n. Ein Pool ist ein Segment oder eine Informationseinheit des zusammenhängenden Plattenraums, vorzugsweise mit einer Größe von bis zu 4 GByte. Die Pools können aus Stücken der Dateien oder Segmenten der ursprünglichen Plattenpartitionen zugewiesen sein.
  • Jeder Pool, wie z. B. der Pool 200n, umfasst einen Kopf 202 und mehrere Speicherräume mit fester Größe, die hierin als "Arenen" 204a bis 204n bezeichnet werden. Die Größe der Arenen ist vorzugsweise konfigurierbar oder änderbar, um die Optimierung der Leistung des Cache-Speichers 80 zu ermöglichen. In der be vorzugten Ausführungsform ist jede der Arenen 204a–204n ein Block mit einer Größe von etwa 512 kBytes bis 2 MBytes.
  • Die in die Arenen zu schreibenden Daten werden eingespeichert oder vorübergehend gespeichert oder in einem "Schreibaggregationspuffer" im Speicher eingespeichert. Dieser Puffer akkumuliert die Daten, wobei der Puffer, wenn er voll ist, in einer Positionierung zusammenhängend in eine Arena auf der Platte geschrieben wird. Der Schreibaggregationspuffer verbessert die Leistung der Schreibvorgänge und erlaubt die Sektorausrichtung der Daten, sodass die Datenelemente direkt von den ursprünglichen Plattenvorrichtungen gelesen werden können.
  • Der Schreibaggregationspuffer ist groß genug, um die ganzen Inhalte einer Arena zu enthalten. Die Daten werden zuerst im Schreibaggregationspuffer eingespeichert und konsolidiert, bevor sie in die (leere) Arena auf der Platte fallen gelassen werden. Der Schreibaggregationspuffer enthält außerdem einen freien Anfangszeiger, der verwendet wird, um den Speicher aus dem Aggregationspuffer zuzuweisen, wie er gefüllt wird, und eine Kennzeichnung, die die Arena benennt, die er überdeckt, und einen Referenzzählerstand für die Anzahl der aktiven Anwender der Arena.
  • Jeder Pool-Kopf 202 speichert eine magische Nummer, einen Wert der Versionsnummer, einen Wert der Anzahl der Arenen und einen oder mehrere Arenenköpfe 206a–206n. Die magische Nummer wird nur für interne Konsistenzüberprüfungen verwendet. Der Wert der Versionsnummer speichert eine Versionsnummer des Programms oder Prozesses, der die Arenen 206a–206n im Pool erzeugt hat. Dies wird für Konsistenzüberprüfungen verwendet, um zu sichern, dass die momentan ausgeführte Version des Cache-Speichers 80 die Arenen richtig lesen und schreiben kann. Der Wert der Anzahl der Arenen speichert einen Zählerstand der Anzahl der Arenen, die innerhalb des Pools enthalten sind.
  • Für jede der Arenen im Pool speichert der Pool-Kopf 202 die Informationen in einem der Arenenköpfe 206a–206n. Jeder Arenenkopf speichert zwei Ein-Bit-Werte, die anzeigen, ob die entsprechende Arena leer ist, und ob die Arena verfälscht worden ist (z. B. zurückzuführen auf eine physikalische Beschädigung der Plattenoberfläche oder einen Anwendungsfehler).
  • Wie in 6 im beispielhaften Fall einer Arena 204a gezeigt ist, umfasst jede Arena ein oder mehrere Datenfragmente 208a–208n. Jedes Fragment 208a–208n umfasst einen Fragmentkopf 208d und die Fragmentdaten 208e. Die Fragmentdaten 208e sind die tatsächlichen Daten für ein Objekt, das im Cache-Speicher 80 gespeichert ist. Die Daten für einen ganzes gespeichertes Objekts können innerhalb eines einzelnen Fragments gespeichert sein, oder sie können in mehreren Fragmenten gespeichert sein, die in mehreren Arenen gespeichert sein können. Der Fragmentkopf 208d speichert den Wert 206c der magischen Zahl, einen Schlüsselwert 206a und einen Längenwert 206b.
  • Der Längenwert 206b stellt die Länge des Fragments in Bytes dar, einschließlich sowohl des Fragmentkopfes 208d als auch der Fragmentdaten 208e. Der Schlüsselwert 206a ist eine Kopie des Objektschlüssels, die in ihrer Gesamtheit gespeichert ist, des Objekts, dessen Daten sich im Fragment befinden. Folglich kann der Schlüsselwert 206c verwendet werden, um den Verzeichnisblock zu durchsuchen, der auf das erste Fragment zeigt, das die Daten des Objekts enthält, dessen Daten im Fragment enthalten sind.
  • Gemäß einer Ausführungsform ist der vollständige Objektschlüssel 56 in Zuordnung zu dem letzten Fragment gespeichert, das einem speziellen Objekt zugeordnet ist. Wenn ein Objekt 52 das erste Mal im Cache-Speicher 80 gespeichert wird, wird der Objektschlüssel 56 inkremental berechnet, wie die Objektdaten vom verursachenden Server 40 gelesen werden. Folglich kann der endgültige Wert des Objektschlüssels 56 nicht bekannt sein, bis das ganze Objekt 52 gelesen ist. Der Objektschlüssel 56 wird an das Ende der Kette der Fragmente geschrieben, die verwendet wird, um das Objekt zu speichern, weil der Wert des Schlüssels nicht bekannt ist, bis das letzte Fragment geschrieben ist, und weil das Modifizieren der vorhandenen Daten auf der Platte langsam ist. In alternativen Ausführungsformen kann der Fragmentkopf andere Metadaten speichern, die das Fragment oder das Objekt beschreiben.
  • Der Schreibaggregationspuffer enthält einen "freien Anfangszeiger" 210, der den obersten freien Bereich des Puffers 204a anzeigt. Der Anfangszeiger 210 identifiziert die momentane Grenze zwischen dem verwendeten und dem verfügbaren Raum innerhalb des Puffers 204a. Der Anfangszeiger 210 ist gespeichert, um dem Cache-Speicher 80 zu ermöglichen, zu bestimmen, wo zusätzliche Fragmente im Puffer zu schreiben sind. Alles unter dem (oder, in 6, links vom) Anfangszeiger 210 enthält gültige Daten oder ist bereits zugewiesen worden, um gültige Daten aufzunehmen. Der Bereich der Arena 204a über dem Anfangszeiger 210 (auf der rechten Seite in 6) ist für das Zuweisen für andere Informationsobjekte verfügbar. Vorzugsweise enthält jedes Fragment maximal 32 Kilobytes Daten. Die Fragmente beginnen und enden an den 512-Byte-Standardgrenzen der Speichervorrichtung 90a. Im Kontext des World Wide Web sind die meisten Objekte relativ klein, im Allgemeinen kleiner als eine Größe von 32 K.
  • Jede Arena kann zu einem gegebenen Zeitpunkt einen von zwei Zuständen besitzen: den leeren Zustand oder den besetzten Zustand. Der momentane Zustand einer Arena wird durch den Leerwert widergespiegelt, der in jedem Arenenkopf 206a–206n gespeichert ist. Im besetzten Zustand speichert irgendein Teil der Arena verwendbare Daten. Eine Liste aller Arenen, die momentan leer oder frei sind, ist im Speicher gespeichert. Der Hauptspeicher des Arbeitsplatzrechners, der den Cache-Speicher 80 ausführt, speichert z. B. eine Anordnung von Zeigern auf leere Arenen. In alternativen Ausführungsformen können zusätzliche Informationen im Kopf 206a–n jeder Arena gespeichert sein. Der Kopf kann z. B. Werte, die die Anzahl der gelöschten Informationsobjekte anzeigen, die in der Arena enthalten sind, und einen Zeitstempel, der anzeigt, wann zuletzt die Speicherbereinigung in der Arena ausgeführt worden ist, speichern.
  • Obwohl in 6 als ein Beispiel drei Fragmente gezeigt sind, kann in der Praxis irgendeine Anzahl von Fragmenten in einer Arena gespeichert sein, bis die Kapazität der Arena erreicht ist. Außerdem ist die Anzahl der Pools und die Anzahl der Arenen, die in 6 gezeigt sind, lediglich beispielhaft, wobei irgendeine Anzahl verwendet werden kann.
  • Die obenbeschriebene Struktur der Arenen unterstützt bestimmte konsistente und sichere Mechanismen des Aktualisierens der Daten für Objekte, die in den Fragmenten der Arenen gespeichert sind. 7 ist ein Blockschaltplan, der sich auf das Aktualisieren einer der Arenen 204a–204n nach 6 bezieht. 7 zeigt eine Arena 204a, die ein erstes Informationsobjekt 208b enthält, das einen Kopf 206 und die Datenfragmente 208a–208c enthält. Der Anfangszeiger 210 zeigt auf den obersten aktiven Teil der Arena 204a, der das Ende des Datensegments 208c ist. Vorzugsweise wird die Verzeichnistabelle nur aktualisiert, nachdem ein vollständiges Informationsobjekt in eine Arena geschrieben worden ist, das einen Kopf und Daten enthält, und nur nachdem der Anfangszeiger der Arena erfolgreich bewegt worden ist. Ein vollständiges Informationsobjekt wird z. B. in die Arena 204a über dem Anfangszeiger 210 geschrieben, wobei der Anfangszeiger bewegt wird, um den neuen oberen freien Platz der Arena anzuzeigen. Nur dann wird die Verzeichnistabelle aktualisiert.
  • Das verzögerte Aktualisieren der Verzeichnistabelle wird ausgeführt, um zu sichern, dass die Verzeichnistabelle genau bleibt, selbst falls während eines der anderen Schritte ein katastrophaler Systemausfall auftritt. Falls z. B. ein Plattenlaufwerk oder ein anderes Element des Systems vor dem Abschluss eines der Schritte abstürzt, tritt keine ungünstige Wirkung auf. In einem derartigen Fall enthält die Arena 204a verfälschte oder unvollständige Daten, aber der Cache-Speicher 80 ignoriert derartige Daten effektiv, weil nichts in der Verzeichnistabelle 110, den Indizes oder den Hash-Tabellen auf die verfälschten Daten Bezug nimmt. Außerdem werden unter Verwendung des hierin beschriebenen Prozesses der Speicherbereinigung die verfälschten oder unvollständigen Daten schließlich regeneriert.
  • OBJEKTE MIT MEHREREN FRAGMENTEN
  • In 3 enthält der Verzeichnistabellenblock 112b, der basierend auf dem Objektschlüssel des Objekts 52 erreicht worden ist, einen Zeiger direkt zu dem Fragment, in dem das Objekt 52 gespeichert ist. Dies setzt voraus, dass das Objekt 52 in einem einzelnen Fragment gespeichert worden ist.
  • Große Objekte passen jedoch aus zwei Gründen nicht immer in ein einzelnes Fragment. Zuerst besitzen die Fragmente eine feste maximale Größe (der bevorzugte Wert ist 32 kB). Objekte, die größer als 32 kB sind, werden fragmentiert. Zweitens muss das System Raum im Schreibaggregationspuffer im Voraus für neue Objekte reservieren. Falls der Objektspeicher die Größe des ankommenden Objekts nicht kennt, kann er falsch schätzen. Der Server kann außerdem die wahre (größere) Größe des Objekts falsch darstellen. In beiden Fällen würde der Objektspeicher eine Kette von Fragmenten erzeugen, um den Überlauf zu handhaben.
  • Deshalb ist ein Mechanismus vorgesehen, um zu verfolgen, welche Fragmente Daten von Objekten enthalten, die zwischen Fragmenten geteilt sind. 5 ist ein Blockschaltplan einer bevorzugten Struktur, um die in Beziehung stehenden Fragmente zu verfolgen.
  • Für den Zweck der Erklärung sollte angenommen werden, dass ein Objekt X in drei Fragmenten 208a, 208b und 208c in den Speichervorrichtungen 90a–90n gespeichert ist. Unter Verwendung des Objektschlüssels für das Objekt X durchläuft der Cache-Speicher die Tag-Tabellen, um einen speziellen Block 141a innerhalb der Verzeichnistabelle 110 zu erreichen. Der Block 141a ist der Kopf einer Kette von Blöcken, die aufeinander folgende Fragmente identifiziert, die das Objekt X enthalten. Im veranschaulichten Beispiel enthält die Kette die Blöcke 141a, 141b, 141c, 141d und 141e in dieser Reihenfolge, wobei sie durch die Zeiger 128a bis 128d gebildet ist.
  • Gemäß einer Ausführungsform umfasst der Kopfblock 141a einen Unterschlüsselwert 126 und einen Blockzeiger 128a. Vorzugsweise besitzt der Unterschlüsselwert 126 eine Länge von 96 Bits und umfasst eine Teilmenge des Wertes des Objektschlüssels 56 für das Objekt X. Der Wert des Blockzeigers 128a nimmt auf den nächsten Block 141b in der Kette Bezug.
  • Der Verzeichnistabellenblock 141a umfasst einen Fragmentzeiger 130a und einen Blockzeiger 128b. Der Fragmentzeiger 130a nimmt auf ein Fragment 208a Bezug, das den ersten Teil der Daten für das Objekt X speichert. Der Blockzeiger 128b des Zeigerblocks 141b nimmt auf den nächsten Zeigerblock 141c in der Kette Bezug. Wie der Zeigerblock 141b besitzt der Zeigerblock 141c einen Fragmentzeiger 130b, der auf ein Fragment 208b Bezug nimmt. Der Blockzeiger 128c des Zeigerblocks 141c nimmt auf den nächsten Zeigerblock 141d in der Kette Bezug. Wie der Zeigerblock 141c besitzt der Zeigerblock 141d einen Fragmentzeiger 130b, der auf ein Fragment 208c Bezug nimmt.
  • Der Objektspeicher benötigt einen Mechanismus, um die Fragmente miteinander zu verketten. Herkömmliche Plattenblock-Verkettungsschemata erfordern das Modifizieren vorher vorhandener Daten auf der Platte, um die früheren Kettenverbindungszeiger zu modifizieren, damit sie auf die neuen nächsten Blockwerte zeigen. Das Modifizieren vorher vorhandener Plattendaten ist zeitraubend und erzeugt Komplexitäten, die sich auf die Konsistenz angesichts einer nicht geplanten Beendigung des Prozesses beziehen.
  • Gemäß einer Ausführungsform der Erfindung wird die Notwendigkeit, neue Fragmentzeiger in vorhandene Fragmentzeiger zu flicken, unter Verwendung "iterativer funktionaler Zeiger" beseitigt. Jedem Fragment wird ein Schlüssel zugeordnet, wobei der Schlüssel des nächsten Fragments als eine einfache iterative Funktion des Schlüssels des vorgehenden Fragments zugeordnet wird. In dieser Weise können die Fragmente einfach verkettet werden, indem der Schlüssel des nächsten Fragments definiert wird, anstatt den Zeiger des vorhergehenden Fragments zu modifizieren.
  • Der Blockzeiger 128a wird z. B. berechnet, indem eine Funktion auf den Wert des Unterschlüssels 126 angewendet wird. Der Blockzeigerwert 128b wird berechnet, indem eine Funktion auf den Wert des Blockzeigers 128a angewendet wird. Die zum Berechnen der Zeigerwerte verwendete Funktion ist nicht kritisch, wobei viele verschiedene Funktionen verwendet werden können. Die Funktion kann eine einfache akkumulierende Funktion sein, sodass keyn = keyn–1 + 1gilt, oder die Funktion kann eine komplexe Funktion sein, wie z. B. die MD5-Hash-Funktion keyn = MD5(keyn–1).
  • Die einzige Anforderung ist, dass der Bereich der möglichen Schlüsselwerte ausreichend groß sein sollte, wobei die Iteration ausreichend ausgewählt sein sollte, dass die Möglichkeiten des Bereichskonflikts oder der zyklischen Schleifenbildung klein sind. In dem sehr unwahrscheinlichen Fall eines Schlüsselkonflikts wird das Objekt aus dem Cache-Speicher gelöscht.
  • Der letzte Zeigerblock 141d in der Kette besitzt einen Blockzeiger 128d, der auf einen Endblock 141e zeigt. Der Endblock 141e enthält eine Referenz auf den ersten Block 141a in der Kette. Gemäß einer Ausführungsform ist die im Endblock 141e enthaltene Referenz ein 96-Bit-Unterschlüssel 132 des Objektschlüssels des Objekts X. Der Cache-Speicher kann den 96-Bit-Unterschlüssel 132 verwenden, um den Kopfblock 128a der Kette zu lokalisieren. Der Endblock 141e und die schleifenförmige Zeigeranordnung, die er bereitstellt, ermöglichen dem Cache-Speicher 80, alle Blöcke in einer Kette, beginnend von irgendeinem Block in der Kette, zu lokalisieren.
  • In 5 sind drei Fragmente 208a, 208b und 208c lediglich beispielhaft gezeigt. In der Praxis kann das Informationsobjekt irgendeine Anzahl von Fragmenten bele gen oder auf irgendeine Anzahl von Fragmenten Bezug nehmen, wobei jedes von denen durch seinen eigenen Zeigerblock innerhalb der Verzeichnistabelle 110 identifiziert werden würde.
  • Wenn das Objekt 52 von der Speichervorrichtung gelesen wird, wird das letzte Fragment zuerst gelesen, um zu sichern, dass der dort gespeicherten Inhalts-MD5-Schlüssel mit dem Verzeichnisschlüsselwert übereinstimmt. Diese Prüfung wird als eine "Vernünftigkeitsüberprüfung" ausgeführt, um zu sichern, dass das richtige Objekt lokalisiert worden ist. Falls es keine Übereinstimmung gibt, ist ein Konflikt aufgetreten, wobei eine Ausnahme verursacht wird.
  • DIE RAUMZUWEISUNG
  • 10A ist ein Ablaufplan eines Verfahrens, um Raum für Objekte zu zuweisen, die neu in den Cache-Speicher eingegeben worden sind, und um derartige Objekte in den zugewiesenen Raum zu schreiben. Dieses Zuweisungs- und Schreibverfahren wird im Allgemeinen durch das Bezugszeichen 640 angezeigt. Im Allgemeinen werden die in 10A gezeigten Schritte ausgeführt, wenn in der Verzeichnistabelle und in der Tag-Tabelle ein Fehltreffer aufgetreten ist, z. B. im Schritt 898 nach 8F.
  • Demzufolge wird im Schritt 642 ein Informationsobjekt, das durch einen Client angefordert worden ist, aber nicht im Cache-Speicher gefunden worden ist, gesucht und von seinem ursprünglichen Platz wiedergewonnen. In einer vernetzten Umgebung ist der Ursprung ein Server 40, ein Cluster oder eine Platte. Wenn das Objekt wiedergewonnen wird, prüft das Verfahren im Schritt 644, ob das Objekt den Typ und die Größe besitzt, die dem Cache-Speicher gespeichert werden können, d. h., ob es "im Cache-Speicher speicherbar" ist.
  • Beispiele von Objekten, die nicht im Cache-Speicher speicherbar sind, enthaltene Web-Seiten, die durch eine Server-Anwendung dynamisch erzeugt werden, Scheiben oder Teile von Web-Seiten, die durch Applets auf der Client-Seite erzeugt werden, Objekte, die basierend auf von einer Datenbank genommenen dynamischen Daten konstruiert werden, und andere nichtstatische Objekte. Derartige Objekte können nicht im Cache-Speicher gespeichert werden, weil sich ihre Form und ihre Inhalte jedes Mal ändern, wenn sie erzeugt werden. Falls derartige Objekte im Cache-Speicher gespeichert wären, würden sie unzuverlässig oder falsch sein, falls die zugrunde liegenden dynamischen Daten zwischen den Zugriffen auf den Cache-Speicher geändert werden würden. Der Prozess bestimmt, ob das Objekt im Cache-Speicher speicherbar ist, indem er die Informationen in der HTTP-Antwort vom Server 40 oder der anderen Quelle des Objekts überprüft.
  • Wenn das Objekt im Cache-Speicher speicherbar ist, dann erhält das Verfahren im Schritt 646 die Länge des Objekts in Bytes. Wenn z. B. die Erfindung auf den Kontext des World Wide Web angewendet wird, kann die Länge einer Web-Seite in den Metadaten enthalten sein, die in einer HTTP-Transaktion übertragen werden. In einem derartigen Fall extrahiert der Cache-Speicher die Länge des Informationsobjekts aus den Antwortinformationen in der HTTP-Nachricht, die das Informationsobjekt enthält. Falls die Länge nicht vorhanden ist, wird ein Schätzwert erzeugt. Die Schätzwerte können falsch sein, wobei sie zu fragmentierten Objekten führen.
  • Wie im Block 648 gezeigt ist, wird der Raum in einem speicherresidenten Schreibaggregationspuffer zugewiesen, wobei das zu schreibende Objekt in den zugewiesenen Pufferplatz geströmt wird. In einer bevorzugten Ausführungsform umfasst der Block 648 das Zuweisen von Raum in einem Schreibaggregationspuffer, der ausreichend Raum besitzt und verfügbar ist, um das Objekt zu halten. Im Block 650 überprüft der Cache-Speicher, ob der Schreibaggregationspuffer verbleibenden freien Raum besitzt. Falls das so ist, ist der Zuweisungs- und Schreibprozess abgeschlossen, wobei der Cache-Speicher 80 andere Aufgaben ausführen kann. Wenn der Schreibaggregationspuffer voll wird, dann ist die Prüfung des Blocks 650 bejahend, wobei die Steuerung zum Block 656 übertragen wird.
  • Im Block 656 schreibt der Cache-Speicher den Aggregationspuffer in die Arena, die er schattiert. Im Schritt 660 wird das Verzeichnis aktualisiert, um den Platz des neuen Informationsobjekts widerzuspiegeln.
  • Die vorangehende Folge von Schritten ist in einer Weise geordnet, die die Integrität der Informationsobjekte sichert, die in den Cache-Speicher geschrieben werden. Das Verzeichnis wird z. B. nur aktualisiert, nachdem ein vollständiges Informationsobjekt, einschließlich des Kopfes und der Daten, in eine Arena geschrieben worden ist. Falls z. B. ein Plattenlaufwerk oder ein anderes Element des Systems vor dem Abschluss des Schrittes 652 oder des Schrittes 658 abstürzt, tritt keine ungünstige Wirkung auf. In einem derartigen Fall enthält die Arena verfälschte oder unvollständige Daten, aber der Cache-Speicher 80 ignoriert derartige Daten effektiv, weil nichts in den Indizes oder den Hash-Tabellen auf die verfälschten Daten Bezug nimmt. Außerdem werden unter Verwendung des hierin beschriebenen Prozesses der Speicherbereinigung die verfälschten oder unvollständigen Daten schließlich regeneriert.
  • DIE SPEICHERBEREINIGUNG
  • 8A ist ein Ablaufplan eines Verfahrens der Speicherbereinigung, das mit dem Cache-Speicher 80 verwendet werden kann. 8B ist ein Ablaufplan weiterer Schritte des Verfahrens nach 8A, wobei sie im Zusammenhang mit 8A erörtert wird. Vorzugsweise ist das Verfahren der Speicherbereinigung als ein unabhängiger Prozess implementiert, der parallel mit anderen Prozessen ausgeführt wird, die mit dem Cache-Speicher in Beziehung stehen. Dies ermöglicht dem Verfahren der Speicherbereinigung, periodisch Speicherbereiche des Cache-Speichers aufzuräumen, ohne die Operation des Cache-Speichers zu unterbrechen oder zu beeinflussen.
  • 1. DER ALLGEMEINE PROZESS
  • In der bevorzugten Ausführungsform bedeutet die "Speicherbereinigung" im Allgemeinen einen Prozess des Abtastens von Zielarenen, des Identifizierens aktiver Fragmente oder des Bestimmens, ob Fragmente zu löschen sind, des Schreibens der aktiven Fragmente zusammenhängend in neue Arenen und des Aktualisierens der Verzeichnistabelle, um auf die neuen Plätze der Fragmente Bezug zu nehmen. Folglich besitzt in einem sehr allgemeinen Sinn das Verfahren den Typ einer "Evakuierung", in der alte oder überflüssige Fragmente gelöscht werden, während aktive Fragmente anderswohin geschrieben werden, sodass beim Abschluss der Operation der Speicherbereinigung in einer speziellen Arena die Arena leer ist. Vorzugsweise sind sowohl die Zielarenen als auch die neuen Arenen in einem flüchtigen Speicher gespeichert und werden dort manipuliert. Wenn die Speicherbereinigung abgeschlossen ist, werden die bei der Speicherbereinigung ausgeführten Änderungen in die im nichtflüchtigen Speicher, wie z. B. auf der Platte, gespeicherten entsprechenden Arenen in einem als Synchronisation bezeichneten Prozess geschrieben.
  • Im Schritt 802 wird einer der Pools 200a–200n für die Operationen der Speicherbereinigung ausgewählt. Vorzugsweise speichert der Cache-Speicher für jeden Pool 200a–200n einer Speichervorrichtung 90a einen Wert, der die Menge des Plattenraums in einem Pool anzeigt, der momentan aktive Daten speichert, oder kann auf einen derartigen Wert zugreifen. Der Cache-Speicher speichert außerdem konstante Werte des "Tiefststandes" und des "Höchststandes", wie durch den Block 803 angezeigt ist. Wenn die Menge des aktiven Speichers in einem speziellen Pool größer als der "Höchststand" wird, wird die Speicherbereinigung eingeleitet und wiederholt ausgeführt, bis die Menge des aktiven Speichers in dem Pool unter den Wert des "Tiefststandes" fällt. Der Wert des "Tiefststandes" wird ausgewählt, damit er größer als null ist, während der Wert des "Höchststandes" ausgewählt wird, damit er etwa 20% kleiner als die gesamte Speicherkapazität des Pools ist. Dieser Weise wird die Speicherbereinigung zu einem Zeitpunkt ausgeführt, bevor der Pool überlauft oder die Kapazität der Speichervorrichtung 90a überschritten wird.
  • 2. DIE SPEICHERBEREINIGUNG, DIE SICH DER VERWENDUNG BEWUSST IST
  • Im Schritt 804 wird eine der Arenen als ein Ziel ausgewählt, um die Speicherbereinigung auszuführen. Die Arena wird durch einen Auswahlalgorithmus ausgewählt, der verschiedene Faktoren berücksichtigt. Wie durch den Block 805 angezeigt ist, enthalten die Faktoren z. B., ob die Arena die letzte Arena ist, auf die durch den Cache-Speicher 80 zugegriffen worden ist, und die Gesamtzahl der Zugriffe auf die Arena. In alternativen Ausführungsformen können die Faktoren außerdem die Anzahl der Informationsobjekte, die aus jeder Arena gelöscht worden sind, wie weit zurückliegend eine Arena verwendet worden ist, wie weit zurückliegend die Speicherbereinigung vorher in jeder Arena ausgeführt worden ist und ob eine Arena momentan für sie gesetzte Lese- und Schreibsperren besitzt enthalten. Sobald die Arena für die Speicherbereinigung ausgewählt ist, werden alle Fragmente innerhalb des Objekts separat für die Speicherbereinigung betrachtet.
  • Im Schritt 806 wird eines der Fragmente innerhalb der ausgewählten Arena die Speicherbereinigung ausgewählt. Beim Bestimmen, welches Fragment oder welche Fragmente auszuwählen ist bzw. sind, berücksichtigt der Cache-Speicher 80 mehrere Auswahlfaktoren, wie durch den Block 807 angezeigt ist. In der bevorzugten Ausführungsform enthalten die Faktoren: den Zeitpunkt des letzten Zugriffs auf das Fragment; die Anzahl der Treffer, die in einem Objekt aufgetreten sind, das Daten in dem Fragment besitzt; die erforderliche Zeit, um die Daten vom Fragment zu einem Client herunterzuladen; und die Größe des Objekts, von dem das Fragment ein Teil ist. In alternativen Ausführungsformen werden andere Faktoren betrachtet. Die Werte für diese Faktoren sind in einem Block 112a–112n gespeichert, der dem Objekt zugeordnet ist, für das das Fragment die Daten speichert.
  • Im Block 808 bestimmt der Cache-Speicher, ob ein Fragment gelöscht werden sollte. In der bevorzugten Ausführungsform umfasst der Block 808 die Bewertung bestimmter Leistungsfaktoren und Optimierungsbetrachtungen.
  • Die Cache-Speicher werden aus zwei primären und potentiell gegensätzlichen Gründen verwendet. Der erste Grund ist die Verbesserung der Leistung des Clients. Um die Leistung des Clients zu verbessern, ist es erwünscht, dass eine Speicherbereinigung Objekte beibehält, die die Server-Download-Zeit minimieren. Dies neigt dazu, die Speicherbereinigung zur Cache-Speicherung von Dokumenten zu beeinflussen, die von langsamen externen Servern empfangen worden sind. Der zweite Grund ist die Minimierung des Netzverkehrs des Servers. Um den Server-Verkehr zu minimieren ist es erwünscht, dass die Speicherbereinigung Objekte beibehält, die groß sind. Oft stehen diese Optimierungen im Gegensatz.
  • Indem Werte gespeichert werden, die die erforderliche Zeit, um ein Objekt herunterzuladen, die Größe des Objekts, und die Anzahl, wie oft das Objekt zu einem Treffer im Cache-Speicher führte, identifizieren, kann die Speicherbereinigung für jedes Objekt schätzen, wie viel Server-Download-Zeit vermieden wurde und wie viel Server-Verkehr blockiert wurde, indem die im Cache-Speicher gespeicherte Kopie geliefert wurde, im Gegensatz zum Holen vom Original-Server. Dieser Maßstab misst den inhärenten "Wert" des im Cache-Speicher gespeicherten Objekts.
  • Der Manager des Cache-Speichers konfiguriert dann einen Parameter zwischen 0 und 1, der den Grad anzeigt, in dem der Cache-Speicher für Zeitersparnisse oder für Verkehrsersparnisse optimiert werden sollte. Die vorangehen Werte werden in Bezug auf andere Objekte in der Arena, in Bezug auf die Menge des Raums, den das Objekt verbraucht, und in Bezug auf die Objekte, die vor kurzem einer Speicherbereinigung unterworfen worden sind, bewertet. Basierend auf einer derartigen Bewertung bestimmt der Cache-Speicher 80, ob das Fragment zu löschen ist, wie im Schritt 808 gezeigt ist.
  • Wenn das Fragment zu löschen ist, dann wird es im Schritt 812 aus der Arena gelöscht, indem es als gelöscht markiert wird und die Daten im Fragment überschrieben werden. Wenn ein Objekt 52 in mehreren Fragmenten gespeichert ist und der Prozess der Speicherbereinigung bestimmt, dass eines der Fragmente zu löschen ist, dann löscht der Prozess alle dem Objekt zugeordneten Fragmente. Dies kann das Verfolgen einer Kette von Fragmenten des in 5 gezeigten Typs zu einer anderen Arena oder sogar zu einem anderen Pool umfassen.
  • Wenn das Fragment nicht zu löschen ist, dann wird im Schritt 810 das Fragment in eine neue Arena geschrieben. 8B, die im Folgenden erörtert ist, zeigt bevorzugte Unterschritte, die beim Ausführen des Schritts 810 eingeschlossen sind.
  • Nachdem das Fragment gelöscht oder in eine andere Arena bewegt worden ist, wird im Schritt 814 die Verzeichnistabelle 110 aktualisiert, um den neuen Platz des Fragments widerzuspiegeln. Der Schritt 814 umfasst die Verwendung des Wertes des Schlüssels 206a im Fragmentkopf 208d, der einem zu aktualisierenden Fragment 208n zugeordnet ist, um einen Block 112a–112n zu suchen, der dem Fragment zugeordnet ist. Wenn der richtige Verzeichnistabellenblock 112a–112n identifiziert ist, wird der Plattenplatzwert 118 im Block aktualisiert, um den neuen Platz des Fragments widerzuspiegeln. Wenn das Fragment gelöscht worden ist, dann werden alle entsprechenden Verzeichnistabelleneinträge gelöscht.
  • Der Schritt 816 zeigt an, dass das Verfahren abgeschlossen ist, nachdem die Verzeichnistabelle 110 aktualisiert worden ist. Es sollte jedoch selbstverständlich sein, dass die Schritte nach 8A für alle Pools, alle Arenen innerhalb jedes Pools und alle Fragmente innerhalb jeder Arena ausgeführt werden.
  • 3. DAS SCHREIBEN DER FRAGMENTE IN NEUE ARENEN
  • 8B ist ein Ablaufplan der Schritte, die beim Ausführen des Schrittes 810 enthalten sind, nämlich des Schreibens eines zu erhaltenden Fragments in eine neue Arena. Der Prozess des Schreibens evakuierter Fragmente in neue Arenen ist zum Schreibens ursprünglicher Fragmente vollständig analog. Die Daten werden in einen Schreibaggregationspuffer geschrieben und in die Plattenarenen fallen gelassen, wenn er voll ist.
  • Im Schritt 590 werden die Verzeichnistabellen aktualisiert, um die Änderung im Platz des Fragments widerzuspiegeln. In der bevorzugten Ausführungsform umfasst der Schritt 590 das Schreiben von Aktualisierungsinformationen in das offene Verzeichnis 130 anstatt direkt in die Verzeichnistabelle 110. Zu einem späteren Zeitpunkt, zu dem der Prozess verifizieren kann, dass die Fragmentdaten 208e erfolgreich in eine der Speichervorrichtungen 90a–90n geschrieben worden sind, werden dann die im offenen Verzeichnis 130 widerspiegelten Änderungen in die Verzeichnistabelle 110 geschrieben oder mit der Verzeichnistabelle 110 synchronisiert.
  • Dieser Prozess wird verwendet, um sicherzustellen, dass die Integrität der Verzeichnistabelle 110 immer erhalten ist. Wie oben angemerkt worden ist, wird die gepufferte Speicherung für die Fragmente verwendet; folglich werden, wenn ein Fragment aktualisiert wird oder ein neues Fragment geschrieben wird, die Fragmentdaten in einen Puffer geschrieben und dann zu einem zukünftigen Zeitpunkt einer Platte oder einer anderen Speichervorrichtung übergeben. Folglich ist es während der Speicherbereinigung möglich, dass ein Fragment, das zu einer neuen Arena bewegt worden ist, tatsächlich nicht in eine der Speichervorrichtungen geschrieben worden ist, wenn der Prozess der Speicherbereinigung bereit ist, um die Verzeichnistabelle zu aktualisieren. Deshalb werden die Informationen über die Änderung im offenen Verzeichnis 130 gespeichert, bis die Änderung der Platte übergeben wird.
  • Im Schritt 592 wird die ursprüngliche Arena untersucht, um zu prüfen, ob sie andere Fragmente besitzt, die rekonstruiert oder zu einer neuen Arena bewegt werden müssten. Wenn andere Objekte vorhanden sind, dann kehrt die Steuerung zum Schritt 806 nach 8A zurück, sodass das nächste Objekt verarbeitet werden kann. Wenn keine anderen Objekte in der aktuellen Arena vorhanden sind, dann wird im Schritt 594 der Anfangszeiger der aktuellen Arena zurückgesetzt.
  • 4. DIE PUFFERUNG
  • In der bevorzugten Ausführungsform werden die durch den Cache-Speicher 80 ausgeführten Lese- und Schreiboperationen und der Prozess der Speicherbereinigung in zwei Arten gepuffert.
  • Zuerst werden die Kommunikationen zwischen dem Cache-Speicher 80 und einem Client 10a, der ein Objekt vom Browser anfordert, durch eine den Ablauf steuernde Streaming-Pufferungsdatenstruktur gepuffert, die als eine VConnection bezeichnet wird. In der bevorzugten Ausführungsform ist der Cache-Speicher 80 in einer Menge von Computer-Programmen implementiert, die in einer objektorientierten Programmiersprache vorbereitet sind. In dieser Ausführungsform ist VConnection ein durch eines der Programme vereinbartes Objekt, wobei VConnection einen Puffer im Speicher einkapselt. Vorzugsweise ist der Puffer ein FIFO-Puffer, der eine Größe von 32 kB besitzt.
  • Wenn ein Client 10a–10c mit dem Cache-Speicher verbunden ist, ordnet der Cache-Speicher den Client einer VConnection zu. Die vom Client 10a empfangenen Daten werden durch die VConnection zum Cache-Speicher 80 geleitet, wobei, wenn der Cache-Speicher Informationen zum Client 10a senden muss, der Cache-Speicher die Informationen in die VConnection schreibt. Die VConnection reguliert den Fluss der Daten vom Cache-Speicher 80, damit er mit der Datenübertragungsgeschwindigkeit übereinstimmt, die durch den Client 10a verwendet wird, um mit dem Cache-Speicher zu kommunizieren. In dieser Weise vermeidet die Verwendung von VConnection die unnötige Verschwendung von Hauptspeicher. Eine derartige Verschwendung würde sich ergeben, wenn ein Objekt, das zum Client 10a gesendet wird, in seiner Gesamtheit in den Speicher kopiert wird, und dann zum Client gesendet wird; während der Übertragung zu einem langsamen Client würde der Hauptspeicher unnötig lahm gelegt. Die gepufferte E/A unter Verwendung dieser Mechanismen neigt dazu, die Anzahl der sequentiellen Lese- und Schreiboperationen zu verringern, die auf einer Platte ausgeführt werden.
  • 5. DIE ERZWINGUNG DER SYNCHRONISATION UND DER KONSISTENZ
  • Während des Prozesses der Speicherbereinigung und während der Operation des Cache-Speichers 80 wird regelmäßig ein Synchronisationsprozess ausgeführt. Der Synchronisationsprozess übergibt im offenen Verzeichnis 130 widerspiegelte Änderungen der Verzeichnistabelle 110 und einem stabilen Speicher, wie z. B. einem nichtflüchtigen Speicher in einer oder mehreren der Speichervorrichtungen 90a–90n. Es ist das Ziel, die Konsistenz der Daten auf der Platte zu allen Zeiten aufrechtzuerhalten. Das heißt, zu einem gegebenen Zeitpunkt ist der Zustand der Datenstrukturen auf der Platte zu 100% konsistent, wobei der Cache-Speicher hochfahren kann, ohne eine Überprüfung zu erfordern. Dies wird durch das sorgfältige Anordnen des Schreibens und der Synchronisation der Daten der Metadaten zur Platte erreicht.
  • Für den Zweck der Erörterung bezieht sich in diesem Abschnitt 'Daten' auf die tatsächlichen Objekte, deren Speicherung vom Cache-Speicher verlangt wird. Falls z. B. der Cache-Speicher ein HTML-Dokument speichert, sind die Daten das Dokument selbst. 'Metadaten' bezieht sich sowohl auf die zusätzlichen Informationen, die der Cache-Speicher zum Speichern benötigt, um die 'Daten' zu indexieren, sodass sie während einer nachfolgenden lookup()-Operation gefunden werden können, als auch auf die Informationen, die er benötigt, um den Raum für die 'Daten' zuzuweisen. Die 'Metadaten' umfassen das Verzeichnis und die Pool-Köpfe. Das Verzeichnis ist der Index, den der Cache-Speicher verwendet, um einen Schlüssel (einen Namen) einem speziellen Platz auf der Platte (den Daten) zuzuordnen. Der Cache-Speicher verwendet die Pool-Köpfe, um zu verfolgen, welcher Plattenraum innerhalb des Cache-Speichers zugewiesen worden ist.
  • Der Cache-Speicher verwendet zwei Regeln, um die Konsistenz der Datenstrukturen auf der Platte aufrechtzuerhalten. Die erste Regel lautet, dass die Metadaten immer nach den Daten, auf die sie zeigen, geschrieben werden. Die logische Grundlage für die erste Regel ist, dass der Cache-Speicher keine "permanente" Kenntnis eines Objekts besitzt, das sich im Cache-Speicher befindet, bis die Metadaten geschrieben sind. Falls der Cache-Speicher die Metadaten vor den Daten schreiben würde und dann abstürzt, würden die Metadaten einem Objektnamen ungültige Objektdaten auf der Platte zuordnen. Dies ist unerwünscht, weil der Cache-Speicher dann eine Heuristik verwenden müsste, um zu probieren und zu bestimmen, welche Metadaten auf gute Daten zeigen und welche auf schlechte Daten zeigen.
  • Die zweite Regel lautet, dass eine Pool-Arena nicht im Pool-Kopf als leer markiert werden kann, bis alle Metadaten des Verzeichnisses, die auf die Arena zeigen, gelöscht und auf die Platte geschrieben worden sind. Dies ist notwendig, sodass ein Absturz nicht verursachen kann, dass eine leere Arena vorhanden ist, auf die Metadaten des Verzeichnisses zeigen. Das Problem, das dieses verursachen kann, ist, dass die leere Arena mit neuen Daten gefüllt werden kann, weil sie leer ist, wobei sie deshalb verfügbar ist, damit neue Daten in sie geschrieben werden. Die "alten" Metadaten des Verzeichnisses zeigen jedoch auf den gleichen Platz wie die neuen Daten. Es ist möglich, dass die Zugriffe auf die alten Metadaten des Verzeichnisses die neuen Daten zurückschicken, anstatt entweder die alten Daten zurückzuschicken oder abzustürzen.
  • 8C ist ein Ablaufplan eines bevorzugten Synchronisationsverfahrens 820, das die vorangehenden zwei Regeln implementiert. Im Block 822 wird ein Objekt in den Cache-Speicher geschrieben. Der Block 822 umfasst die Schritte des Blockes 824 und des Blockes 826, nämlich das Erzeugen der Metadaten im offenen Verzeichnis und das Schreiben und das Synchronisieren der Objektdaten auf der Platte.
  • Die Schritte der Blöcke 828 bis 820' werden periodisch ausgeführt. Wie im Block 828 angezeigt ist, wird für jedes Stück der Metadaten in der Tabelle des offenen Verzeichnisses eine Bestimmung ausgeführt, ob die Daten, auf die die Metadaten zeigen, bereits auf der Platte synchronisiert sind, wie im Block 821 gezeigt ist. Wenn das so ist, dann kopiert im Block 823 der Cache-Speicher die Metadaten, die auf die stabilen Daten zeigen, vom offenen Verzeichnis zur Verzeichnistabelle. Im Block 825 werden die Änderungen auf der Platte synchronisiert.
  • Im Block 827 wird die Speicherbereinigung in einer Arena ausgeführt. Der Block 827 kann die in 8A gezeigten Schritte umfassen. Alternativ umfasst die Speicherbereinigung im Allgemeinen die im Block 829, im Block 831 und im Block 820' gezeigten Schritte. Wie im Block 829 gezeigt ist, löscht der Cache-Speicher für jedes Fragment in der Arena die Metadaten des Verzeichnisses, die auf das Segment zeigen, wobei er die Metadaten des Verzeichnisses auf die Platte schreibt. Im Block 831 wird der Pool-Kopf im Speicher modifiziert, sodass die Arena als leer markiert ist. Im Block 820' wird der Pool-Kopf auf die Platte geschrieben und auf der Platte synchronisiert.
  • Die Schritte, die das Schreiben der Informationen auf die Platte umfassen, verwenden vorzugsweise eine "Spülungs"-Operation, die im Betriebssystem des Arbeitsplatzrechners bereitgestellt ist, der den Cache-Speicher 80 ausführt. Die "Spülungs"-Operation schreibt alle Daten in den Puffern, die verwendet werden, um die Objektdaten zu speichern, in eine nichtflüchtige Speichervorrichtung 90a–90c.
  • Unter Verwendung der vorangehenden Verfahren wird die Verzeichnistabelle nicht mit den Änderungen im offenen Verzeichnis aktualisiert, bis die Daten, die die Änderungen beschreiben, tatsächlich auf die Platte oder einen anderen nichtflüchtigen Speicher geschrieben worden sind. Außerdem verschiebt der Cache-Speicher 80 das Aktualisieren der Arenen auf der Platte, bis die durch den Prozess der Speicherbereinigung unternommenen Änderungen der Platte übergeben worden sind. Diese sichert, dass die Arenen in dem Fall, dass ein Systemabsturz auftritt, bevor die Verzeichnistabelle vom offenen Verzeichnis aktualisiert worden ist, weiter gültige Daten speichern.
  • 6. DIE ERNEUTE VALIDIERUNG
  • In der bevorzugten Ausführungsform schafft der Cache-Speicher eine Art, um alte Informationsobjekte im Cache-Speicher neu zu validieren, sodass die beim Prozess der Speicherbereinigung nicht zerstört werden.
  • 12 ist ein Ablaufplan eines bevorzugten Prozesses der erneuten Validierung. Im Block 1202 gibt ein externes Programm oder einen externer Prozess eine Anforderung an den Cache-Speicher aus, die fragt, ob ein spezielles Informationsobjekt vor kurzem durch einen Client geladen worden ist. In Reaktion auf die Anforderung lokalisiert der Cache-Speicher das Informationsobjekt im Cache-Speicher, wie im Block 1204 gezeigt ist. Im Block 1206 liest der Cache-Speicher einen Wert eines Lesezählers, der in den Verzeichnistabellen dem Informationsobjekt zugeordnet ist. Im Block 1208 prüft der Cache-Speicher, ob der Wert des Lesezählers hoch ist.
  • Wenn der Wert des Lesezählers hoch ist, dann ist das Informationsobjekt vor kurzem geladen worden. In diesem Fall sendet im Block 1210 der Cache-Speicher eine positive Antwortnachricht an den anfordernden Prozess. Andernfalls ist das Informationsobjekt vor kurzem nicht geladen worden, wie im Block 1212 angezeigt ist. Demzufolge sendet der Cache-Speicher eine negative Antwortnachricht an das aufrufende Programm oder den aufrufenden Prozess, wie im Block 1214 gezeigt ist. Im Block 1216 aktualisiert der Cache-Speicher den Wert des Verfallsdatums, der in Zuordnung zum Informationsobjekt gespeichert ist, um das aktuelle Datum oder den aktuellen Zeitpunkt widerzuspiegeln. Durch das Aktualisieren des Verfallsdatums sichert der Cache-Speicher, dass der Prozess der Speicherbereinigung das Objekt nicht löscht, weil es nach der Aktualisierung nicht als alt betrachtet wird. In dieser Weise wird ein altes Objekt im Cache-Speicher aufgefrischt, ohne das Objekt von seinem Ursprung wiederzugewinnen, es in den Cache-Speicher zu schreiben und die alte Kopie des Objekts zu löschen.
  • DIE AKTUALISIERUNG EINES SKALIERTEN ZÄHLERS
  • 10B ist ein Ablaufplan eines Verfahrens zur Aktualisierung eines skalierten Zählers. In der bevorzugten Ausführungsform wird das Verfahren nach 10B verwendet, um die Werte der Lesezähler zu managen, die in jedem Block 112a–112n einer Menge der Verzeichnistabelle gespeichert sind, wie in 3A gezeigt ist. Das Verfahren nach 10B ist jedoch nicht auf diesem Kontext eingeschränkt. Das Verfahren nach 10B ist auf jede Anwendung anwendbar, die das Management jedes von mehreren Objekten umfasst, das einen Zähler besitzt, und in der es erwünscht ist, die am kürzesten zurückliegend verwendeten oder die am weitesten zurückliegend verwendeten Objekte zu verfolgen. Ein Schlüsselvorteil des Verfahrens nach 10B im Vergleich zu früheren Zugängen ist, dass es ermöglicht, dass große Zählerwerte in einem kleinen Speicherbereich verfolgt werden.
  • In der bevorzugten Ausführungsform ist jeder der Werte der Lesezähler, die in den Blöcken 112a–112n gespeichert sind, in Drei-Bit-Größen gespeichert. Während der Operation des Cache-Speichers 80 wird, wenn auf einen Block zugegriffen wird, der Wert des Lesezählers des Blocks um eins inkrementiert. Die höchste Dezimalzahl, die durch eine Drei-Bit-Größe dargestellt werden kann, ist 7. Demzufolge könnte ein Lesezähler überlaufen, nachdem er siebenmal inkrementiert worden ist. Um einen Zählerüberlauf zu verhindern, während den Zählern ermöglicht wird, eine unbegrenzte Anzahl von Operationen zu verfolgen, die sie inkrementieren, wird das Verfahren nach 10B periodisch ausgeführt.
  • Die folgende Erörterung der Schritte nach 10B wird unter Bezugnahme auf die Tabelle 1 deutlicher verstanden:
  • TABELLE 1 – DIE AUFEINANDER FOLGENDEN ZÄHLERWERTE
    Figure 00500001
  • In der Tabelle 1 identifiziert die EREIGNIS-Spalte aufeinander folgende Ereignisse, die eine Menge von Zählerwerten beeinflussen, wobei sie die Art des Ereignisses kurz anzeigt. Der ZÄHLER-Kopf zeigt die drei Zählerwerte A, B und C an, die in separaten Spalten dargestellt sind. Jeder der Zählerwerte A, B, C entspricht einem Zählerwert, der in einem anderen Block 112a–112n des Verzeichnisindex 110 gespeichert ist. Folglich zeigt jede Zeile der Tabelle 1 die Inhalte der drei Zählerwerte zu aufeinander folgenden Schnappschüssen in der Zeit an.
  • Das Ereignis 1 nach Tabelle 1 stellt einen beliebigen Anfangspunkt in der Zeit dar, zu dem auf jeden der Einträge der Hash-Tabelle, die die Zählerwerte A, B, C enthalten, einmal zugegriffen worden ist. Demzufolge ist der Wert jedes Zählers A, B, C gleich eins. Beim Ereignis 2 hat der Cache-Speicher auf den Eintrag der Hash-Tabelle zugegriffen, der den Zählerwert A speichert. Demzufolge ist der Zähler A inkrementiert worden, wobei sein Wert 2 ist; die anderen Zähler B, C sind unverändert. Es wird vorausgesetzt, dass dann einige andere Zugriffe auf Einträge der Hash-Tabelle auftreten, von denen jeder verursacht, dass einer der Zähler A, B, C inkrementiert wird. Danach sind beim Ereignis 3 die Werte der Zähler A, B, C 7, 3 bzw. 1. Folglich speichert der Zähler A den maximalen Wert, den er darstellen kann, die binäre 111 oder die dezimale 7, wobei er überlaufen wird, falls ein Versuch unternommen wird, ihn auf einen Wert größer auf 7 zu inkrementieren.
  • An diesem Punkt wird das Verfahren nach 10B auf die Zähler A, B, C angewendet. Im Schritt 622 wird der Wert aller Zähler gelesen. Im Schritten 624 wird die Summe aller Zählerwerte gebildet. Im Fall der Tabelle 1 ist die Summe durch 7 + 3 + 1 = 11 gegeben. Im Schritt 626 wird die maximale Summe, die durch alle Zähler dargestellt werden kann, basierend auf der Länge in Bits der Zählerwerte berechnet. In dem Fall eines Drei-Bit-Wertes ist der maximale Wert eines Zählers 7, wobei der maximale Wert der Summe der drei Drei-Bit-Zähler 7 × 3 = 21 beträgt. Alternativ kann der Schritt 626 weggelassen werden; wobei der maximale Wert als eine Konstante gespeichert sein kann, die für das Verfahren 620 für den skalierten Zähler verfügbar ist und einfach abgerufen wird, wenn sie benötigt wird.
  • Im Schritt 628 berechnet das Verfahren den Wert (maximum_value/2), schneidet jeden Rest oder dezimalen Anteil ab und vergleicht ihn mit der Summe aller Zähler. In dem obigen Beispiel lautet die Beziehung
    Sum = 11,
    Maximum_Value = 21,
    Maximum_Value/2 = 10,
    (Sum > Maximum_Value/2) = WAHR.
  • Weil das Ergebnis wahr ist, wird die Steuerung zum Schritt 630 übertragen, in dem alle Zählerwerte um 1 dekrementiert werden. Der Zustand der Zähler A, B, C nach diesem Schritt ist durch das Ereignis 4, "dekrementieren", gezeigt. Es wird angemerkt, dass der Zähler C, der den am weitesten zurückliegend verwendeten Eintrag der Hash-Tabelle darstellt, auf null dekrementiert worden ist. An diesem Punkt können die am weitesten zurückliegend verwendeten Einträge der Hash-Tabelle regeneriert oder beseitigt werden, indem die entsprechenden Zählerwerte abgetastet werden und nach Nullwerten gesucht wird. Das Ergebnis dieses Schrittes ist im Ereignis 5 nach Tabelle 1, "regenerieren", angezeigt. Die Werte der Zähler A und B sind unverändert, während der Wert des Zählers C unbestimmt ist, weil sein entsprechender Eintrag in der Hash-Tabelle aus der Hash-Tabelle gelöscht worden ist.
  • Wenn das Verfahren nach 10B periodisch und regelmäßig wiederholt wird, wird keiner der mehreren Zählerwerte überlaufen. Außerdem werden die am weitesten zurückliegend verwendeten Einträge schnell durch einen Zählerwert von null identifiziert, wobei sie leicht aus dem Cache-Speicher beseitigt werden können. Die Zählerwerte können in wenigen Bits aufrechterhalten werden, selbst wenn auf die Einträge der Hash-Tabelle Millionen Mal zugegriffen wird. Folglich schafft das Verfahren nach 10B eine schnelle effiziente Weise, um die am weitesten zurückliegend verwendeten Einträge aus einer Liste zu beseitigen.
  • DIE CACHE-SPEICHER-OPERATIONEN
  • In der bevorzugten Ausführungsform ist der Cache-Speicher 80 in einem oder mehreren Computer-Programmen implementiert, die durch eine API, die Lese- und Schreiboperationen unterstützt, für externe Programme zugänglich sind. Die Lese- und Schreiboperationen werden im offenen Verzeichnis 130 ausgeführt, das die einzige Struktur des Cache-Speichers 80 ist, die für externe Programme oder Prozesse "sichtbar" ist. Die Leseoperation wird durch ein externes Programm aufgerufen, das ein Objekt im Cache-Speicher lokalisieren will. Die Schreiboperation wird durch ein Programm aufgerufen, das ein Objekt im Cache-Speicher speichern will. Innerhalb der Programme, die den Cache-Speicher 80 bilden, werden die Operationen unterstützt, die als Suchen, Löschen, Ausbuchen und Einbuchen bezeichnet werden. Die Suchoperation sucht ein Objekt anhand eines Schlüssels im offenen Verzeichnis. Die Löschoperation löscht ein Objekt anhand eines Schlüssels aus dem offenen Verzeichnis. Die Ausbuchoperationen erhält eine Kopie eines Blocks von der Verzeichnistabelle 110 in einer geordneten Weise, um die Datenkonsistenz zu sichern. Die Einbuchoperation schickt eine Kopie eines Blocks (der durch andere Operationen modifiziert worden sein kann) zur Verzeichnistabelle 110 zurück. In anderen Ausführungsformen kombiniert eine einzelne Durchsuchungsoperation des Cache-Speichers die Aspekte dieser Operationen.
  • 1. DAS SUCHEN
  • In einer alternativen Ausführungsform wird eine SUCH-Operation verwendet, um zu bestimmen, ob ein durch einen speziellen Namen identifiziertes spezielles Objekt momentan im Cache-Speicher 80 gespeichert ist. 9A ist ein Ablaufplan der in einer Ausführungsform der SUCH-Operation ausgeführten Schritte, der im Allgemeinen durch das Bezugszeichen 902 bezeichnet wird. Die SUCH-Operation wird durch einen Befehl von der Protokollmaschine 70 an den Cache-Speicher 80 eingeleitet, wenn eine Anforderungsnachricht von einem Client 10a versucht, ein spezielles Objekt vom Server 40 wiederzugewinnen. Die Anforderungsnachricht vom Client 10a identifiziert das angeforderte Objekt durch seinen Namen.
  • Wenn der Prozess im Kontext des World Wide Web angewendet wird, ist der Name ein einheitlicher Fundstellenanzeiger (URL). Im Schritt 904 setzt der Cache- Speicher 80 den Namen des Objekts in einen Schlüsselwert um. In der bevorzugten Ausführungsform wird der Umsetzungsschritt ausgeführt, wie in 3B gezeigt ist. Der Objektname 53 oder der URL wird zu einer Hash-Funktion geleitet, wie z. B. der MD5-Einweg-Hash-Funktion. Die Ausgabe der Hash-Funktion ist ein Objektnamensschlüssel 62. Der Objektnamenschlüssel 62 kann in einer oder mehrere Unterschlüsselwerte 64, 66 aufgebrochen sein.
  • Im Schritt 906 sucht der Cache-Speicher 80 den Anforderungs-Schlüsselwert im offenen Verzeichnis 130. Das offene Verzeichnis wird zuerst konsultiert, weil erwartet wird, dass es die am kürzesten zurückliegend angeforderten Objekte speichert, und es deshalb wahrscheinlich ist, dass es das Objekt in der Client-Anforderung enthält. Vorzugsweise umfasst der Schritt 906 die Verwendung eines der Unterschlüsselwerte als Suchschlüssel. Es kann z. B. ein 17-Bit- oder 18-Bit-Unterschlüsselwert für die Suche verwendet werden.
  • Im Schritt 908 prüft der Cache-Speicher 80, ob der Unterschlüsselwert im offenen Verzeichnis gefunden worden ist. Wenn der Unterschlüsselwert im offenen Verzeichnis gefunden worden ist, dann ruft im Schritt 910 der Cache-Speicher 80 das Objekt von einer der Speichervorrichtungen ab und gibt das Objekt an den Client aus. Der Unterschritt des Abrufens umfasst die oben im Zusammenhang mit dem Lokalisieren der Objekte in Pools, Arenen und Fragmenten des nichtflüchtigen Speichers in den Speichervorrichtungen 90a–90n beschriebenen Unterschritte. Der Ausgabe-Unterschritt umfasst das Konstruieren einer HTTP-Antwort für den Client, die die Daten des Objekts enthält, das Öffnen einer HTTP-Verbindung mit dem Client und das Senden der HTTP-Anforderung an den Client.
  • Wenn der Unterschlüsselwert im offenen Verzeichnis nicht gefunden wird, dann sucht im Schritt 912 der Cache-Speicher 80 den Anforderungs-Unterschlüsselwert in der Tag-Tabelle 102. Im Schritt 914 prüft der Cache-Speicher 80, ob der Unterschlüsselwert in der Tag-Tabelle 102 gefunden worden ist. Wenn keine Übereinstimmung gefunden worden ist, dann speichert im Schritt 916 der Cache-Speicher 80 die Informationen über die Tatsache, dass keine Übereinstimmung gefunden worden ist, für die spätere Verwendung, wie im Folgenden beschrieben ist. Die Informationen können ein Bit sein, das anzeigt, dass ein Fehltreffer in der Tag-Tabelle 102 aufgetreten ist.
  • Im Schritt 918 sucht der Cache-Speicher 80 den Unterschlüsselwert in der Verzeichnistabelle. Wenn die Prüfung des Schritts 914 bejahend gewesen ist, dann ruft der Cache-Speicher 80 einen Unterschlüsselwert, der mit dem Anforderungs-Unterschlüsselwert übereinstimmt, von einem der Einträge 106 der Tag-Tabelle 102 ab. Sein Wert wird als ein Schlüssel verwendet, um den Anforderungs-Schlüsselwert in der Verzeichnistabelle zu suchen. Im Schritt 920 prüft der Cache-Speicher 80, ob der Anforderungs-Schlüsselwert in der Verzeichnistabelle gefunden worden ist. Wenn ein Treffer auftritt und es in der Tag-Tabelle einen Fehltreffer gegeben hat, wie durch die im Schritt 916 gespeicherten Informationen angezeigt wird, dann aktualisiert im Schritt 922 der Cache-Speicher 80 das offene Verzeichnis mit den Informationen, die mit dem Treffer in der Verzeichnistabelle in Beziehung stehen. Dann wird die Steuerung zum Schritt 910 geleitet, in dem das Objekt in der oben beschriebenen Weise erhalten und an den Client ausgegeben wird.
  • Wenn die Prüfung des Schrittes 920 negativ ist, dann befindet sich das angeforderte Objekt nicht im Cache-Speicher, wobei eine Bedingung eines Cache-Speicher-Fehltreffers auftritt, wie im Schritt 924 angezeigt ist. In Reaktion auf diese Fehltreffer-Bedingung erhält im Schritt 926 der Cache-Speicher 80 eine Kopie des angeforderten Objekts vom Server, der die Quelle ist. Im Web-Kontext öffnet z. B. der Cache-Speicher 80 eine HTTP-Verbindung zum in der Anforderung des Clients bereitgestellten URL und lädt das Objekt herunter. Das Objekt wird dann dem Client bereitgestellt und für die künftige Bezugnahme im Cache-Speicher gespeichert.
  • In einer bevorzugten Ausführungsform ist die SUCH-Operation als ein Verfahren eines Objekts in einer objektorientierten Programmiersprache implementiert, das einen Schlüsselwert als einen Parameter empfängt.
  • 2. EIN OFFENER LESEPROZESS DES CACHE-SPEICHERS
  • 9E ist ein Ablaufplan eines bevorzugten Prozesses zum Lesen eines Objekts, das durch einen Objektnamen (wie z. B. einen URL) identifiziert ist, aus dem Cache-Speicher. In der bevorzugten Ausführungsform wird der Prozess nach 9E als "open_read" bezeichnet, wobei er die einzige externe Schnittstelle des Cache-Speichers 80 darstellt. Es ist vorteilhaft, die Steuerung und die Konsistenz der Daten im Cache-Speicher sicherzustellen, um externen Programmen zu erlauben, nur auf Operationen zuzugreifen, die das offene Verzeichnis 130 verwenden oder modifizieren. Vorzugsweise ist der Prozess nach 9E als ein Programm oder ein Programmobjekt implementiert, das einen Objektnamen und die Informationen über die spezielle Anforderung des Anwenders als Eingangsparameter empfängt. Der Leseprozess schickt eine Kopie eines einem Schlüssel zugeordneten Objekts zurück, das unter Verwendung des Suchprozesses im Cache-Speicher gefunden wird. Folglich sind der Leseprozess und andere Prozesse, die durch ihn aufgerufen oder gerufen werden, eine Alternative zur oben im Zusammenhang mit 9A beschriebenen SUCH-Operation.
  • Im Schritt 964 bucht der Prozess einen Vektor der Alternativen aus, sodass die Alternativen in dem Vektor gelesen werden können. Vorzugsweise umfasst der Schritt 964 das Aufrufen des hierin im Zusammenhang mit 8D beschriebenen checkout_read-Prozesses, wobei ein aus dem Objektnamen abgeleiteter Schlüssel als ein Parameter bereitgestellt wird. Das Ausbuchen eines Vektors umfasst das Ausbuchen eines Blocks aus dem offenen Verzeichnis, der einen Zeiger auf den Vektor besitzt, und das Überreichen des Blocks vom Cache-Speicher.
  • Falls die Ausbuch-Operation erfolgreich ist, dann verwendet im Schritt 966 der Prozess die Anforderungsinformationen, um eine der Alternativen aus den Alternativen im Vektor auswählen. Diese Auswahl wird in der oben im Zusammenhang mit dem Vektor der Alternativen 122 beschriebenen Weise ausgeführt. In einer Ausführungsform wird die Auswahloperation durch ein anderes Programm oder Programmobjekt ausgeführt, das eine Erfolg-/Misserfolg-Anzeige zurückschickt, abhängig davon, ob eine geeignete Alternative lokalisiert worden ist. Wenn die Auswahl erfolgreich ist, dann bucht im Schritt 968 der Prozess den Vektor der Alternativen zurück ein. Im Schritt 970 liest der Prozess das Objekt, auf das durch die ausgewählte Alternative gezeigt wird.
  • Wenn der Schritt 964 oder der Schritt 966 zu einem Misserfolg führen, dann ist das angeforderte Dokument nicht im Cache-Speicher vorhanden. Demzufolge schickt im Schritt 972 der Prozess eine "Kein-Dokument"-Fehlernachricht an das aufrufende Programm oder den aufrufenden Prozess zurück.
  • 3. EIN OFFENER SCHREIBPROZESS DES CACHE-SPEICHERS
  • 9F ist ein Ablaufplan eines Prozesses des Schreibens eines Objekts in den Cache-Speicher. Wie im Fall des oben im Zusammenhang mit 9E beschrie benen Leseprozesses ist der Schreibprozess vorzugsweise als ein "open_write"-Verfahren implementiert, das die einzige Schnittstelle des Cache-Speichers 80 zu externen Programmen ist, die Objekte im Cache-Speicher speichern müssen. Vorzugsweise ist der Prozess nach 9F als ein Programm oder ein Verfahren implementiert, das einen Objektnamen, die Anforderungsinformationen und die Antwortinformationen als die Eingangsparameter empfängt. Der Objektname identifiziert ein Objekt, das in den Cache-Speicher zu schreiben ist; in der bevorzugten Ausführungsform ist der Objektname ein aus einem URL unter Verwendung des in 3B gezeigt Mechanismus abgeleiteter Namensschlüssel 62.
  • Der Schreibprozess wird eingeleitet, wenn ein Client 10a ein Objekt 52 aus dem Cache-Speicher 80 angefordert hat, das nicht im Cache-Speicher gefunden wird. Im Ergebnis öffnet der Cache-Speicher 80 eine HTTP-Transaktion mit dem Server 40, der das Objekt speichert, und erhält eine Kopie des Objekts von ihm. Die Anforderungsinformationen, die dem Schreibprozess des Cache-Speichers bereitgestellt werden, werden aus der HTTP-Anforderung abgeleitet, die vom Client gekommen ist. Die Antwortinformationen werden aus der Antwort des Servers 40 an den Cache-Speicher 80 abgeleitet, der die Kopie des Objekts ausgibt.
  • Im Schritt 974 bucht der Prozess einen Vektor der Alternativen aus. Dieser Schritt umfasst das Berechnen eines Schlüsselwertes basierend auf dem Objektnamen, das Suchen einer Menge und eines Blocks im offenen Verzeichnis, die auf den Schlüsselwert abgebildet werden, und das Lokalisieren eines Vektors der Alternativen, der, falls es einen gibt, dem Block entspricht. Falls kein Vektor vorhanden ist, wird ein neuer Vektor erzeugt, wie im Schritt 984 gezeigt ist.
  • Wenn ein Vektor erfolgreich ausgebucht oder erzeugt worden ist, dann verwendet im Schritt 976 der Prozess die Anforderungsinformationen, um einen neuen alternativen Datensatz 123a–123n innerhalb der aktuellen Alternative zu definieren. Der neue alternative Datensatz nimmt auf den Platz des Objekts Bezug, wobei er eine Kopie der Anforderungsinformationen und die Antwortinformationen enthält. Die neue Alternative wird zum Vektor der Alternativen hinzugefügt. Doppelte alternative Datensätze sind erlaubt; der Vektor der Alternativen kann mehr als einen alternativen Datensatz enthalten, der die gleichen Anforderungs- und Antwortinformationen enthält. Das Überprüfen vorhandener alternativer Datensätze, um Duplikate zu identifizieren, wird als überflüssig betrachtet, weil nur eine kleine inkrementale Menge des Speichers durch doppelte alternative Datensätze besetzt ist.
  • Im Schritt 978 wird der modifizierte Vektor unter Verwendung der obenbeschriebenen Schritte in den Cache-Speicher eingebucht. Im Schritt 980 wird das Objekt in der obenbeschriebenen Weise unter Verwendung des Schlüsselwertes in eine der Datenspeichervorrichtungen 90a–90c geschrieben. Wenn während des Schrittes 980 festgestellt wird, dass sich der Schlüssel in Gebrauch befindet, dann ist die Schreiboperation erfolglos. Dies vermeidet das Überschreiben eines Objektes, das durch einen Schlüssel identifiziert wird, der aktualisiert wird.
  • 4. DER AKTUALISIERUNGSPROZESS FÜR DEN CACHE-SPEICHER
  • 9G ist ein Ablaufplan eines Aktualisierungsprozesses für den Cache-Speicher. Der Aktualisierungsprozess wird verwendet, um einen Vektor der Alternativen zu modifizieren, um andere Anforderungsinformationen oder Antwortinformationen zu speichern. Im Allgemeinen wird der Aktualisierungsprozess durch die Protokollmaschine 70 aufgerufen, wenn der Cache-Speicher 80 momentan ein Objekt 52 speichert, das mit einer Anforderung von einem Client 10a übereinstimmt, die Protokollmaschine aber bestimmt, dass das Objekt abgelaufen ist oder nicht länger gültig ist. Unter diesen Umständen öffnet die Protokollmaschine 70 eine HTTP-Transaktion zum Server 40, der das ursprüngliche Objekt 52 bereitgestellt hat, wobei sie eine Nachricht sendet, die den Server fragt, ob sich das Objekt im Server geändert hat. Dieser Prozess wird als die "erneute Validierung" des Objekts 52 bezeichnet. Falls der Server 40 verneinend antwortet, stellt der Server eine kurze HTTP-Nachricht mit einem Kopf bereit, der anzeigt, dass keine Änderung aufgetreten ist, und neue Antwortinformationen bereitstellt. In diesem Fall ruft die Protokollmaschine 70 den Aktualisierungsprozess für den Cache-Speicher auf, um die neuen Antwortinformationen über das Objekt 52 in den Cache-Speicher 80 zu bewegen.
  • Wenn der Server 40 bejahend antwortet, dass sich das Objekt 52 seit dem Verfallsdatum oder -zeitpunkt im Cache-Speicher 80 geändert hat, dann wird der Aktualisierungsprozess nicht aufgerufen. Stattdessen schickt der Server 40 eine Kopie des aktualisierten Objekts 52 zusammen mit einem neuen Verfallsdatum und anderen Antwortinformationen zurück. In diesem Fall ruft die Protokollmaschine 70 den Schreibprozess für den Cache-Speicher und die Erzeugungspro zesse, die oben beschrieben worden sind, auf, um das neue Objekt 52 zum Cache-Speicher 80 hinzuzufügen.
  • Wie in 9G gezeigt ist, empfängt der Aktualisierungsprozess die Eingangsparameter, die einen Objektnamen, eine "alte" Kennzeichnung, die Anforderungsinformationen und die Antwortinformationen enthalten. Der Objektname ist ein URL oder ein aus einem URL abgeleiteter Schlüssel. Die Anforderungsinformationen und die Antwortinformationen werden aus der HTTP-Anforderung des Clients für das Objekt 52 vom Cache-Speicher 80 und aus der Antwort des Servers 40, wenn der Cache-Speicher eine aktualisierte Kopie des Objekts erhält, vom Cache-Speicher abgeleitet.
  • Die "alte" Kennzeichnung ist ein Wert, der ein Paar von Anforderungsinformationen und Antwortinformationen eindeutig identifiziert. In der bevorzugten Ausführungsform werden, wenn ein Cache-Speicher-Fehltreffer verursacht, dass der Cache-Speicher 80 ein neues Objekt in den Cache-Speicher schreibt, die Informationen von der Client-Anforderung mit den Antwortinformationen vom Server, der eine Kopie des Objekts bereitstellt, paarweise angeordnet. Jedem Paar wird ein eindeutiger Kennzeichnungswert gegeben.
  • Im Schritt 986 bucht der Prozess einen Vektor der Alternativen entsprechend dem Objektnamen vom Cache-Speicher aus. Vorzugsweise wird dies durch das Aufrufen des hierin beschriebenen checkout_write-Prozesses ausgeführt. Dies umfasst die Verwendung des Objektnamens oder des URL, um ein Objekt im offenen Verzeichnis, der Tag-Tabelle und dem Verzeichnisindex zu suchen, sodass ein entsprechender Vektor der Alternativen erhalten wird. Wenn der Schritt des Ausbuchens misslingt, dann schickt im Schritt 996 der Prozess eine geeignete Fehlernachricht zurück.
  • Wenn das Ausbuchen erfolgreich ist, dann wird im Schritt 988 eine Kopie oder ein Klon des Vektors im Hauptspeicher erzeugt. Ein Anforderungs-/Antwort-Kennzeichnungswert wird innerhalb des Vektors angelegt, indem er an den alten Kennzeichnungswert, der als Eingabe in den Prozess empfangen worden ist, angepasst wird. Der alte Kennzeichnungswert wird gelöscht, wobei eine neue Kennzeichnung an seinen Platz geschrieben wird. Die neue Kennzeichnung identifiziert die neuen Anforderungs- und Antwortinformationen eindeutig, die dem Prozess als Eingabe bereitgestellt werden.
  • Im Schritt 990 wird der neue Vektor in eine der Speichervorrichtungen 90a–90c geschrieben, wobei im Schritt 992 der neue Vektor in den Cache-Speicher eingebucht wird. Beim Ausführen dieser Schritte ist es erwünscht, den Klon-Vektor vollständig in die Speichervorrichtung zu schreiben, bevor der Vektor eingebucht wird. Dies sichert, dass die Schreiboperation erfolgreich ist, bevor die Verzeichnistabellen modifiziert werden, um auf den Klon-Vektor Bezug zu nehmen. Es sichert außerdem, dass der alte Vektor für jeden Prozess oder jedes Programm verfügbar ist, der bzw. das auf ihn zugreifen muss.
  • 5. DIE DURCHSUCHUNG DES VERZEICHNISSES
  • 9C ist ein Ablaufplan einer bevorzugten Ausführungsform eines Prozesses zum Suchen von Informationen im offenen Verzeichnis 130. Der Prozess nach 9C ist als ein Programmprozess oder ein Verfahren implementiert, der bzw. das einen Unterschlüsselteil eines Namensschlüssels 62 als einen Eingangsparameter empfängt. In vorhergehenden Schritten, die nicht gezeigt sind, ist es selbstverständlich, dass die Protokollmaschine 70 einen Objektnamen, wie z. B. einen URL empfängt. Ein URL wird z. B. in einer durch einen Client an einen Server, der den Cache-Speicher betreibt, ausgegebenen HTTP-Anforderung bereitgestellt. Die Protokollmaschine 70 wendet eine Hash-Funktion auf den Objektnamen an. Die Hash-Funktion liefert als ihr Ergebnis oder ihre Ausgabe einen Namensschlüssel, der eine Menge im Cache-Speicher identifiziert.
  • Im Schritt 948 versucht der Prozess, einen oder mehrere Blöcke, die durch den Unterschlüssel identifiziert werden, aus dem Verzeichnisindex auszubuchen. Der Schritt des Ausbuchens der Blöcke umfasst vorzugsweise das Aufrufen des hierin beschriebenen checkout_read-Prozesses.
  • Wenn der Versuch des Ausbuchens zu einem Ausfallzustand führt, dann schickt im Schritt 950 der Prozess eine Fehlernachricht an das Programm oder den Prozess, das bzw. der ihn aufgerufen hat, zurück, die anzeigt, dass ein Block, der mit dem Eingangs-Unterschlüssel übereinstimmt, im Cache-Speicher nicht gefunden worden ist. Die Steuerung wird zum Schritt 952 weitergeleitet, in dem der Prozess abgeschlossen wird.
  • Wenn der Versuch des Ausbuchens erfolgreich ist, dann wird eine Kopie eines Blocks für die Verwendung durch das aufrufende Programm verfügbar. Im Schritt 954 wird der Block, der ausgebucht worden ist, abermals eingebucht. Im Schritt 956 schickt der Prozess eine Nachricht an das aufrufende Programm zurück, die anzeigt, dass der angeforderte Block gefunden worden ist. Die Verarbeitung wird im Schritt 952 abgeschlossen.
  • Folglich umfasst eine Durchsuchungsoperation des Cache-Speichers das Aufrufen mehrerer primitiver Prozesse, die versuchen, einen durch einen Schlüssel identifizierten Block aus dem offenen Verzeichnis auszubuchen. Wenn die Grundelemente den Block im offenen Verzeichnis nicht finden, wird der Verzeichnisindex durchsucht.
  • Wenn ein Block gefunden wird, wird er an den Client ausgegeben. Wenn die Erfindung z. B. auf den Kontext des World Wide Web angewendet wird, wird der Datenblock ausgegeben, indem eine HTTP-Verbindung zum Client geöffnet und der Datenblock unter Verwendung einer HTTP-Transaktion an den Client übertragen wird. Dieser Schritt kann das Puffern mehrerer Datenblöcke umfassen, bevor die Transaktion geöffnet wird.
  • 6. DER LÖSCHPROZESS FÜR DEN CACHE-SPEICHER
  • 9D ist ein Ablaufplan eines Prozesses zum Löschen eines Blocks, der sich auf ein Objekt bezieht, aus dem Cache-Speicher. Wie im Fall der Ausbuch-Operationen empfängt der Löschprozess für den Cache-Speicher einen Schlüsselwert als Eingabe. Der Prozess umfasst die Schritte 958 bis 962. Diese Schritte führen Operationen aus, die im Wesentlichen zu den Operationen nach den Schritten 948, 954 und 952 nach 9C ähnlich sind. Um das Löschen eines im Cache-Speicher gefundenen Blocks auszuführen, setzt jedoch im Schritt 960 der Prozess den Löschmerker und bucht den Block mit dem gesetzten Löschmerker ein. Wie hierin im Zusammenhang mit dem Einbuchprozess (die Schritte 938 und 944 nach 9B) beschrieben worden ist, wird, wenn der Löschmerker gesetzt ist, der Block als gelöscht markiert. Danach wird der Block schließlich aus dem Verzeichnisindex gelöscht, wenn die im offenen Verzeichnis widergespiegelten Änderungen mit im Verzeichnisindex synchronisiert werden.
  • 7. DIE AUSBUCH-LESEOPERATION
  • 8D ist ein Ablaufplan einer checkout_read-Operation, die im Zusammenhang mit der Verzeichnistabelle 110 verwendet wird. Die checkout_read-Operation wird verwendet, um eine Kopie eines Blocks von der Verzeichnistabelle 110 zu erhalten, die mit einem speziellen Schlüssel übereinstimmt. Sobald der Block aus der Verzeichnistabelle 110 ausgebucht worden ist, kann der Block durch den Prozess, der ihn ausgebucht hat, gelesen und verwendet werden, aber durch keinen anderen Prozess. Danach wird, um den Block für andere Prozesse verfügbar zu machen, der Block zurück eingebucht. Komplementäre Ausbuch-/Einbuch-Prozesse werden verwendet, um sicherzustellen, dass nur ein Prozess auf einmal einen Verzeichnistabellenblock modifizieren kann, ein Mechanismus, der wesentlich ist, um sicherzustellen, dass die Verzeichnistabelle immer genaue Informationen über die Objekte im Cache-Speicher speichert. Es ist folglich offensichtlich, dass die Ausbuch- und Einbuchprozesse primitive Prozesse sind, die beim Durchsuchen des Cache-Speichers nach einem speziellen Objekt helfen.
  • Wie in 8D angezeigt ist, empfängt die checkout_read-Operation einen Schlüsselwert als Eingabe. In der bevorzugten Ausführungsform ist der Eingangs-Schlüsselwert ein Unterschlüsselteil eines Namensschlüssels 62, der einem Objektnamen entspricht.
  • Weil der Objektspeicher Teile der Speicher- und Plattendatenstrukturen modifiziert, muss er eine kurze Periode des wechselseitigen Ausschlusses für eine Teilmenge der Datenstrukturen des Cache-Speichers garantieren, um konsistente Ergebnisse zu erreichen. Die Datenstrukturen des Cache-Speichers sind in 256 virtuelle "Scheiben" partitioniert, die durch 8 Bits des Schlüssels ausgewählt werden. Jede Scheibe besitzt eine zugeordnete Sperre für den wechselseitigen Ausschluss. Im Schritt 832 versucht der Prozess, die Sperre für den Eingangschlüssel zu erhalten. Falls eine Sperre nicht erhalten werden kann, wartet der Prozess eine kurze Zeit, bis sie verfügbar wird. Eine Sperre kann nicht verfügbar sein, falls eine andere Transaktion die kleine Menge des Speicherzustands modifiziert, die einem Schlüssel zugeordnet ist, der in dieselbe Scheibe fällt.
  • Wenn eine Sperre erhalten wird, wird der Eingangschlüssel für die Verwendung durch andere Prozesse nicht verfügbar. Im Schritt 834 bestimmt der Prozess, welche Menge 110a–110n der Verzeichnistabelle 110 dem Schlüssel entspricht. Der Prozess lokalisiert dann eine der Blocklisten 132a, 132b des offenen Verzeichnisses 130, die der Menge der Verzeichnistabelle 110 entspricht, indem er den Wert eines Unterschlüssels des Eingangschlüssels einer der Blocklisten zuordnet. Im Schritt 836 tastet der Prozess die Blöcke in der ausgewählten Blockliste des offenen Verzeichnisses 130 ab, wobei er nach einer Übereinstimmung des Eingangschlüssels mit einem in einem der Blöcke gespeicherten Schlüssel sucht.
  • Wenn eine Übereinstimmung gefunden wird, dann prüft der Prozess im Schritt 838, ob sich der übereinstimmende Block momentan in dem Prozess befindet, sodass er durch einen anderen Prozess erzeugt oder zerstört wird. Wenn sich der übereinstimmende Block momentan in dem Prozess befindet, sodass er erzeugt oder zerstört wird, dann wird im Schritt 840 eine Fehlernachricht zur Protokollmaschine 70 zurückgeschickt, die anzeigt, dass der aktuelle Block nicht verfügbar ist.
  • Wenn sich andererseits der übereinstimmende Block momentan nicht in dem Prozess befindet, sodass er erzeugt oder zerstört wird, dann kann der Block verwendet werden. Demzufolge inkrementiert im Schritt 842 der Prozess einen Lesezähler. Der Lesezähler ist eine interne Variable, die dem Block zugeordnet ist, die die Anzahl der Prozesse oder Instanzen von Programmobjekten anzeigt, die den Block lesen. Derartige Prozesse und Objekte werden als "Leser" bezeichnet. Im Schritt 844 erhält der Prozess eine Kopie des Blocks und schickt sie zum aufrufenden Programm oder Prozess zurück.
  • Wenn beim Abtasten des Schrittes 836 keine Übereinstimmung gefunden wird, dann ruft im Schritt 846 der Prozess eine Durchsuchung der Verzeichnistabelle auf, die nach einer Übereinstimmung des Schlüssels mit einer Menge und einem Block der Verzeichnistabelle unter Verwendung eines Prozesses sucht, der hierin weiter beschrieben ist. Wenn keine Übereinstimmung des Schlüssels bei der Durchsuchung gefunden wird, dann schickt der Prozess im Schritt 848 eine Fehlernachricht an das aufrufende Programm oder den aufrufenden Prozess zurück, die anzeigt, dass das angeforderte Objekt im Cache-Speicher nicht vorhanden ist. Obwohl die spezifische Antwort auf eine derartige Nachricht durch das aufrufende Programm oder den aufrufenden Prozess bestimmt ist, kontaktiert im Kontext des World Wide Web im Allgemeinen der Proxy 30 den Server 40, der das Objekt speichert, unter Verwendung einer HTTP-Anforderung und erhält eine Kopie des angeforderten Objekts.
  • Wenn während der Durchsuchung des Verzeichnisindex des Schrittes 846 eine Übereinstimmung gefunden wird, dann wird im Schritt 850 ein entsprechender Block zum offenen Verzeichnis hinzugefügt. Dies wird ausgeführt, indem im Hauptspeicher ein neuer Block des offenen Verzeichnisses erzeugt wird; der Block durch das Kopieren von Informationen vom entsprechenden Block des Verzeichnisindex initialisiert wird; und eine Referenz auf den neuen Block zur entsprechenden Liste der Blöcke 132a, 132b hinzugefügt wird.
  • 8. DIE AUSBUCH-SCHREIBOPERATION
  • 8E ist ein Ablaufplan eines checkout_write-Prozesses oder einer checkout_write-Operation, der bzw. die im Zusammenhang mit dem offenen Verzeichnis 130 verwendet wird. Die checkout_write-Operation wird verwendet, um zum Zweck des Modifizierens oder Aktualisieren der Inhalte des Blocks oder eines Objekts oder eines Vektors, das bzw. der dem Block zugeordnet ist, eine Kopie eines Blocks vom offenen Verzeichnis 130 zu erhalten, der mit einem Schlüssel übereinstimmt, der zum Prozess geleitet wird. Sobald ein Block unter Verwendung von checkout_write aus dem offenen Verzeichnis 130 ausgebucht worden ist, können andere Prozesse den Block oder sein zugeordnetes Objekt oder seinen zugeordneten Vektor modifizieren. Der Block wird dann unter Verwendung des hierin beschriebenen Einbuchprozesses zurück eingebucht. Unter Verwendung dieser Operationen werden Änderungen im offenen Verzeichnis gespeichert und dann in einer geordneten Weise zur Verzeichnistabelle übertragen.
  • Wie in 8E angezeigt ist, empfängt der checkout_write-Prozess einen Schlüsselwert als Eingabe. In der bevorzugten Ausführungsform ist der Eingangs-Schlüsselwert ein Unterschlüsselteil eines Namensschlüssels 62, der einem Objektnamen entspricht. Im Schritt 854 versucht der Prozess, eine Sperre an dem bezeichneten Schlüssel zu erhalten. Wenn keine Sperre erhalten werden kann, wartet der Prozess, bis eine verfügbar ist.
  • Wenn eine Sperre erhalten wird, wird der Schlüssel für die Verwendung durch andere Prozesse nicht verfügbar. Im Schritt 856 bestimmt der Prozess, welche Menge 110a–110n der Verzeichnistabelle 110 dem Schlüssel entspricht. Der Prozess lokalisiert dann eine der Blocklisten 132a, 132b des offenen Verzeichnisses 130, die der Menge der Verzeichnistabelle 110 entspricht. Im Schritt 858 tastet der Prozess die Blöcke in der ausgewählten Blockliste des offenen Verzeichnisses 130 ab, wobei er nach einer Übereinstimmung des Eingangschlüssels mit einem in einem der Blöcke gespeicherten Schlüssel sucht.
  • Wenn eine Übereinstimmung gefunden wird, dann prüft der Prozess im Schritt 864, ob sich der übereinstimmende Block momentan in dem Prozess befindet, sodass er durch einen anderen Prozess erzeugt oder zerstört wird. Wenn das so ist, dann wird im Schritt 866 eine Fehlernachricht zur Protokollmaschine 70 oder zum Cache-Speicher 80 zurückgeschickt, die anzeigt, dass der aktuelle Block nicht verfügbar ist. Wenn sich der übereinstimmende Block momentan nicht in dem Prozess befindet, sodass er erzeugt oder zerstört wird, dann kann der Block verwendet werden. Demzufolge inkrementiert der Prozess im Schritt 868 einen Schreibzähler. Der Schreibzähler ist eine interne Variable, die in Zuordnung zu dem Block gespeichert ist, die die Anzahl der Prozesse oder Programmobjekte anzeigt, die den Block schreiben. Im Schritt 870 erhält der Prozess eine Kopie des Blocks, schickt sie zum aufrufenden Programm oder Prozess zurück und markiert die Kopie außerdem als modifiziert. Diese Markierung sichert, dass alle an dem Block vorgenommenen Änderungen im Verzeichnisindex widergespielt werden, wenn das offene Verzeichnis mit dem Verzeichnisindex synchronisiert wird.
  • Wenn bei der Abtastung des Schrittes 858 keine Übereinstimmung gefunden wird, dann ruft im Schritt 860 der Prozess eine Durchsuchung des Verzeichnisindex unter Verwendung eines Prozesses auf, der hierin weiter beschrieben ist. Wenn bei der Durchsuchung keine Übereinstimmung gefunden wird, dann schickt der Prozess im Schritt 862 eine Fehlernachricht zum aufrufenden Programm oder Prozess zurück, die anzeigt, dass das angeforderte Objekt nicht im Cache-Speicher vorhanden ist. Im Kontext des World Wide Web würde das aufrufende Programm typischerweise den verursachenden Server, der das Objekt speichert, unter Verwendung einer HTTP-Anforderung kontaktieren und eine Kopie des angeforderten Objekts erhalten.
  • Wenn während der Durchsuchung des Verzeichnisindex des Schrittes 860 eine Übereinstimmung gefunden wird, dann wird im Schritt 874 ein entsprechender Block zum offenen Verzeichnis hinzugefügt. Dies wird ausgeführt, indem im Hauptspeicher ein neuer Block des offenen Verzeichnisses erzeugt wird; der Block durch das Kopieren von Informationen vom entsprechenden Block des Verzeichnisindex initialisiert wird; und eine Referenz auf den neuen Block zur entsprechenden Liste der Blöcke 132a, 132b hinzugefügt wird. Dann wird die Steuerung zum Schritt 868 geleitet, in dem der Schreibzählerstand inkrementiert wird, wobei der Prozess fortgesetzt wird, wie oben im Zusammenhang mit den Schritten 868–870 beschrieben worden ist.
  • 9. DIE AUSBUCH-ERZEUGUNGSOPERATION
  • 8F ist ein Ablaufplan einer checkout_create-Operation, die für die Verwendung im Zusammenhang mit dem offenen Verzeichnis 130 unterstützt wird. Die checkout_create-Operation wird verwendet, um für einen Namensschlüssel, der einem neuen Objekt entspricht, das zum Cache-Speicher hinzugefügt wird, einen neuen Block im offenen Verzeichnis 130 zu erzeugen. Sobald der Block im offenen Verzeichnis 130 erzeugt worden ist, kann das Objekt durch die Anwender durch das offene Verzeichnis 130 vom Cache-Speicher erhalten werden.
  • Wie in 8F angezeigt ist, empfängt der checkout_create-Prozess einen Schlüsselwert als Eingabe. In der bevorzugten Ausführungsform ist der Eingangs-Schlüsselwert ein Unterschlüsselteil eines Namensschlüssels 62, der einem Objektnamen entspricht. Im Schritt 876 versucht der Prozess, eine Sperre an dem bezeichneten Schlüssel zu erhalten. Wenn keine Sperre erhalten werden kann, wartet der Prozess, bis eine verfügbar ist.
  • Wenn eine Sperre erhalten wird, wird der Schlüssel für die Verwendung durch andere Prozesse nicht verfügbar. Im Schritt 878 bestimmt der Prozess, welche Menge 110a–110n der Verzeichnistabelle 110 dem Schlüssel entspricht. Der Prozess lokalisiert dann unter Verwendung der Bits des Mengen-Unterschlüssels des Eingangschlüssels die Menge des offenen Verzeichnisses 130, die der Menge der Verzeichnistabelle 110 entspricht. Im Schritt 880 tastet der Prozess die Blöcke in der ausgewählten Blockliste des offenen Verzeichnisses 130 ab, wobei er nach einer Übereinstimmung des Eingangschlüssels mit einem in einem der Blöcke gespeicherten Schlüssel sucht.
  • Wenn eine Übereinstimmung gefunden wird, in dann wird ein Versuch unternommen, um einen Block zu erzeugen, der bereits vorhanden ist. Demzufolge prüft im Schritt 882 der Prozess, ob der übereinstimmende Block als gelöscht markiert worden ist und momentan keine anderen Prozesse besitzt, die ihn lesen oder schreiben. Wenn die Werte sowohl des Leserzählers als auch des Schreiberzählers null sind, dann besitzt der Block keine anderen Prozesse, die ihn lesen oder schreiben. Wenn die Werte entweder des Leserzählers oder des Schreiberzählers nicht null sind, oder wenn der übereinstimmende Block nicht als gelöscht markiert worden ist, dann ist der Block ein gültiger vorher vorhandener Block, der nicht erzeugt werden kann. Im Schritt 884 wird eine Fehlernachricht zur Protokollmaschine 70 oder zum Cache-Speicher 80 zurückgeschickt, die anzeigt, dass der aktuelle Block nicht verfügbar ist, um erzeugt zu werden.
  • Wenn der übereinstimmende Block gelöscht ist und keine Schreiber oder Leser besitzt, die auf ihn zugreifen, dann kann der Prozess effektiv einen neuen Block erzeugen, indem er den übereinstimmenden vorher erzeugten Block löscht und initialisiert. Demzufolge löscht im Schritt 886 der Prozess den übereinstimmenden Block. Im Schritt 888 initialisiert der Prozess den gelöschten Block, indem er spezielle Felder auf null setzt und den Schlüsselwert des Blocks auf den Schlüssel setzt. Im Block 890 inkrementiert der Prozess den dem Block zugeordneten Schreiberzähler und markiert den Block als erzeugt. Im Schritt 892 schickt der Prozess eine Kopie des Blocks zum aufrufenden Prozess oder Programmobjekt zurück und markiert den Block als modifiziert.
  • Wenn bei der Abtastung des Schrittes 880 keine Übereinstimmung gefunden wird, dann ist momentan kein übereinstimmender Block im offenen Verzeichnis 130 vorhanden. Im Schritt 894 führt der Prozess eine Durchsuchung des Verzeichnisindex unter Verwendung eines Prozesses aus, der hierin weiter beschrieben ist. Wenn eine Übereinstimmung auftritt, dann schickt im Schritt 896 der Prozess eine Fehlernachricht zum aufrufenden Programm oder Prozess zurück, die anzeigt, dass der zu erzeugende Block im Cache-Speicher bereits vorhanden ist nicht gelöscht werden kann.
  • Wenn bei der Durchsuchung keine Übereinstimmung gefunden wird, dann ist im ganzen Cache-Speicher momentan kein übereinstimmender Block vorhanden. Im Schritt 898 erzeugt der Prozess einen neuen Block des offenen Verzeichnisses und fügt eine Referenz auf diesen Block zur Liste 132a, 132b hinzu, die dem im Schritt 878 berechneten Mengenwert zugeordnet ist. Die Steuerung wird zum Schritt 890 geleitet, in dem die Verarbeitung fortgesetzt wird, wie oben im Zusammenhang mit den Schritten 890–892 beschrieben worden ist.
  • 10. DER EINBUCH-PROZESS
  • 9B ist ein Ablaufplan eines Block-Einbuchprozesses. Der Cache-Speicher 80 führt den Prozess nach 9B aus, um einen Block in das offene Verzeichnis 130 einzubuchen, nachdem der Block gelesen, modifiziert oder gelöscht worden ist. In einer Ausführungsform ist der Prozess nach 9B als ein Programmprozess oder -objekt implementiert, der bzw. das eine Kennzeichnung eines Blocks als einen Parameter empfängt. Weil im ausgebuchten Block der Schlüssel vorhanden ist, muss der Schlüssel nicht als ein Argument eingereicht werden.
  • Im Schritt 930 versucht der Prozess, eine Sperre für den dem Block zugeordneten Schlüssel zu erhalten. Wenn keine Sperre verfügbar ist, dann tritt der Prozess in eine Warteschleife ein, bis eine Sperre verfügbar ist. Wenn eine Sperre verfügbar ist, prüft der Prozess im Schritt 932, ob der Block eingebucht wird, nachdem der Block modifiziert worden ist. Wenn es so ist, dann wird im Schritt 934 der Schreiberzählerstand für den Block dekrementiert, was anzeigt, dass ein Prozess das Schreiben des Blocks abgeschlossen hat.
  • Im Schritt 936 prüft der Prozess, ob der Einbuchprozess erfolgreich ausgeführt worden ist. Wenn diese Prüfung bejahend ist, dann kopiert der Prozess im Schritt 942 die Informationen im aktuellen Block in den entsprechenden ursprünglichen Block im offenen Verzeichnis. In dieser Weise wird das offene Verzeichnis mit allen Änderungen aktualisiert, die durch den Prozess ausgeführt worden sind, der die Kopie des Blocks modifiziert hat, die im Ausbuchprozess erhalten worden ist. Danach und falls die Prüfung des Schrittes 936 negativ ist, prüft der Prozess, ob ein Lösch-Einbuch-Merker gesetzt ist. Der Lösch-Einbuch-Merker zeigt an, dass der Block nach dem Einbuchen zu löschen ist. Der Löschmerker ist ein Argument für die Einbuchoperation. Wenn der Merker gesetzt ist, dann markiert der Prozess im Schritt 944 den Block als gelöscht. Die Verarbeitung wird im Schritt 940 abgeschlossen.
  • Wenn die Prüfung des Schrittes 932 negativ ist, dann ist der Block nicht modifiziert worden. Im Ergebnis ist der einzige andere mögliche Zustand, dass der Block gelesen worden ist. Demzufolge wird im Schritt 946 der Leserzählerstand dekrementiert.
  • DIE IMPLEMENTIERUNG DER VERFAHREN
  • In der bevorzugten Ausführungsform werden die hierin beschriebenen Verfahren unter Verwendung eines programmierbaren digitalen Universal-Computer-Systems des Typs ausgeführt, das in 11 veranschaulicht ist. Jedes der Verfahren kann in mehreren verschiedenen Arten implementiert sein. Die Verfahren können z. B. in der Form von prozeduralen Computer-Programmen, objektorientierten Programmen, Prozessen, Applets usw. entweder in einem Einzelprozess-Multiprozessorsystem oder in einem Mehrfachprozess-Multiprozessorsystem implementiert sein.
  • In einer bevorzugten Ausführungsform ist jeder der Prozesse unabhängig und ablaufinvariant, sodass jeder Prozess mehrmals eine Instanz bilden kann, wenn sich der Cache-Speicher in Betrieb befindet. Der Prozess der Speicherbereinigung läuft z. B. gleichzeitig mit und unabhängig von den Zuweisungs- und Schreibprozessen ab.
  • HARDWARE-ÜBERBLICK
  • 11 ist ein Blockschaltplan, der ein Computer-System 1100 veranschaulicht, auf dem eine Ausführungsform der Erfindung implementiert sein kann. Das Computer-System 1100 enthält einen Bus 1102 oder einen anderen Kommunikationsmechanismus, um Informationen zu übertragen, und einen Prozessor 1104, der mit dem Bus 1102 gekoppelt ist, um Informationen zu verarbeiten. Das Computer-System 1100 enthält außerdem einen Hauptspeicher 1106, wie z. B. einen Schreib-Lese-Speicher (RAM) oder eine andere dynamische Speichervorrichtung, der bzw. die an den Bus 1102 gekoppelt ist, um Informationen und durch den Prozessor 1104 auszuführende Befehle zu speichern. Der Hauptspeicher 1106 kann außerdem verwendet werden, um während der Ausführung der durch den Prozessor 1104 auszuführenden Befehle temporäre Variable oder andere Zwischeninformationen zu speichern. Das Computer-System 1100 enthält ferner einen Festwertspeicher (ROM) 1108 oder eine andere statische Speichervorrichtung, der bzw. die an den Bus 1102 gekoppelt ist, um statische Informationen und Befehle für den Prozessor 1104 zu speichern. Eine Speichervorrichtung 1110, wie z. B. eine Magnetplatte oder eine optische Platte, ist vorgesehen und mit dem Bus 1102 gekoppelt, um Informationen und Befehle zu speichern.
  • Das Computer-System 1100 kann über den Bus 1102 an eine Anzeige 1112, wie z. B. eine Katodenstrahlröhre (CRT), gekoppelt sein, um die Informationen einem Computer-Anwender anzuzeigen. Eine Eingabevorrichtung 1114, die alphanumerische und andere Tasten enthält, ist an den Bus 1102 gekoppelt, um eine Auswahl von Informationen und Befehlen zum Prozessor 1104 zu übertragen. Ein weiterer Typ der Anwender-Eingabevorrichtung ist die Cursor-Steuerung 1116, wie z. B. eine Maus, eine Rollkugel oder die Cursor-Richtungstasten, um Richtungsinformationen und eine Befehlsauswahl zum Prozessor 1104 zu übertragen und um die Cursor-Bewegung auf der Anzeige 1112 zu steuern. Diese Eingabevorrichtung besitzt typischerweise zwei Freiheitsgrade in zwei Achsen, eine erste Achse (z. B. x) und eine zweite Achse (z. B. y), die der Vorrichtung erlauben, Positionen in einer Ebene zu spezifizieren.
  • Die Erfindung bezieht sich auf die Verwendung des Computer-Systems 1100 für die Cache-Speicherung von Informationsobjekten. Gemäß einer Ausführungsform der Erfindung ist die Cache-Speicherung von Informationsobjekten durch das Computer-System 1100 in Reaktion auf den Prozessor 1104 vorgesehen, der eine oder mehrere Folgen von einem oder mehreren Befehlen ausführt, die im Hauptspeicher 116 enthalten sind. Derartige Befehle können von einem weiteren computerlesbaren Medium, wie z. B. der Speichervorrichtung 1110, in den Hauptspeicher 1106 gelesen werden. Die Ausführung der im Hauptspeicher 1106 enthaltenen Folgen von Befehlen veranlasst den Prozessor 1104, die hierin beschriebenen Prozessschritte auszuführen. In alternativen Ausführungsformen kann eine festverdrahtete Schaltungsanordnung anstelle von oder in Kombination mit Software-Befehlen verwendet werden, um die Erfindung zu implementieren. Folglich sind die Ausführungsformen der Erfindung nicht auf irgendeine spezifische Kombination aus Hardware-Schaltungsanordnung und Software eingeschränkt.
  • Der Begriff "computerlesbares Medium", wie er hierin verwendet wird, bezieht sich auf irgendein Medium, das am Bereitstellen von Befehlen für den Prozessor 1104 für die Ausführung teilnimmt. Ein derartiges Medium kann viele Formen annehmen, einschließlich aber nicht eingeschränkt auf nichtflüchtigen Medien, flüchtige Medien und Übertragungsmedien. Die nichtflüchtigen Medien enthalten z. B. optische oder magnetische Platten, wie z. B. die Speichervorrichtung 1110. Die flüchtigen Medien enthalten dynamischen Speicher, wie z. B. den Hauptspeicher 1106. Die Übertragungsmedien enthalten Koaxialkabel, Kupferdrähte und Faser optiken, einschließlich der Drähte, die der Bus 1102 umfasst. Die Übertragungsmedien können außerdem die Form von akustischen Wellen oder Lichtquellen annehmen, wie z. B. diejenigen, die während der Funkwellen- und Infrarot-Datenübertragungen erzeugt werden.
  • Häufige Formen der computerlesbaren Medien enthalten z. B. eine Diskette, eine flexible Platte, eine Festplatte, ein Magnetband oder irgendein anderes magnetisches Medium, einen CD-ROM, irgendein anderes optisches Medium, Lochkarten, Lochstreifen, irgendein anderes physikalische Medium mit Mustern von Löchern, einen RAM, einen PROM und einen EPROM, einen FLASH-EPROM, irgendeinen anderen Speicherchip oder irgendeine andere Speicherkassette, eine Trägerwelle, wie im Folgenden beschrieben ist, oder irgendein anderes Medium, von dem ein Computer lesen kann.
  • Es können beim Übertragen einer oder mehrerer Folgen von einem oder mehreren Befehlen zum Prozessor 1104 für die Ausführung verschiedene Formen computerlesbarer Medien einbezogen sein. Die Befehle können z. B. anfangs auf einer Magnetplatte eines entfernten Computers getragen werden. Der entfernte Computer kann die Befehle in seinen dynamischen Speicher laden und die Befehle unter Verwendung eines Modems über eine Telephonleitung senden. Ein Modem örtlich beim Computer-System 1100 kann die Daten auf der Telephonleitung empfangen und einen Infrarotsender verwenden, um die Daten in ein Infrarotsignal umzusetzen. Ein an den Bus 1102 gekoppelter Infrarotdetektor kann die im Infrarotsignal übertragenen Daten empfangen und die Daten auf den Bus 1102 legen. Der Bus 1102 überträgt die Daten zum Hauptspeicher 1106, von dem der Prozessor 1104 die Befehle abruft und ausführt. Die durch den Hauptspeicher 1106 empfangenen Befehle können optional entweder vor oder nach der Ausführung durch den Prozessor 1104 in der Speichervorrichtung 1110 gespeichert werden.
  • Das Computer-System 1100 enthält außerdem eine Kommunikationsschnittstelle 1118, die an den Bus 1102 gekoppelt ist. Die Kommunikations-Schnittstelle 1118 schafft eine Zweiweg-Datenkommunikationskopplung mit einer Netzverbindung 1120, die mit einem lokalen Netz 1122 verbunden ist. Die Kommunikationsschnittstelle 1118 kann z. B. eine Karte für ein diensteintegrierendes digitales Netz (ISDN-Karte) oder ein Modem sein, um eine Datenkommunikationsverbindung zu einem entsprechenden Typ der Telephonleitung zu schaffen. Als ein weiteres Beispiel kann die Kommunikationsschnittstelle 1118 eine Karte für ein lokales Netz (LAN-Karte) sein, um eine Datenkommunikationsverbindung mit einem kompatiblen LAN zu schaffen. Es können außerdem drahtlose Verbindungen implementiert sein. In jeder derartigen Implementierung sendet und empfängt die Kommunikationsschnittstelle 118 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen, die verschiedene Typen von Informationen darstellen.
  • Die Netzverbindung 1120 schafft typischerweise eine Datenkommunikation durch ein oder mehrere Netze zu anderen Datenvorrichtungen. Die Netzverbindung 1120 kann z. B. eine Verbindung durch das lokale Netz 1122 zu einem Host-Computer 1124 oder zu einer durch einen Internet-Diensteanbieter (ISP) 1126 betriebenen Datenausrüstung schaffen. Der ISP 1126 stellt wiederum Datenkommunikationsdienste durch das weltweite Paketdaten-Kommunikationsnetz bereit, das gegenwärtig gewöhnlich als das "Internet" 1128 bezeichnet wird. Das lokale Netz 1122 und das Internet 1128 verwenden beide elektrische, elektromagnetische oder optische Signale, die die digitalen Datenströme übertragen. Die Signale durch die verschiedenen Netze und die Signale in der Netzverbindung 1120 und durch die Kommunikationsschnittstelle 1118, die die digitalen Daten zu dem und von dem Computer-System 1100 übertragen, sind beispielhafte Formen von Trägerwellen, die die Informationen transportieren.
  • Das Computer-System 1100 kann durch das (die) Netz(e), die Netzverbindung 1120 und die Kommunikationsschnittstelle 1118 Nachrichten senden und Daten empfangen, einschließlich Programmcode. Im Internet-Beispiel könnte der Server 1130 einen angeforderten Code für ein Anwendungsprogramm durch das Internet 1128, den ISP 1126, das lokale Netz 1122 und die Kommunikationsschnittstelle 1118 übertragen. Gemäß der Erfindung sorgt eine derartige heruntergeladene Anwendung für die Cache-Speicherung von Informationsobjekten, wie hierin beschrieben ist.
  • Der empfangene Code kann wie er empfangen wird durch den Prozessor 1104 ausgeführt werden und/oder für die spätere Ausführung in der Speichervorrichtung 1110 oder einem anderen nichtflüchtigen Speicher gespeichert werden. In dieser Weise kann das Computer-System 1100 den Anwendungscode in der Form einer Trägerwelle erhalten.
  • Demzufolge ist ein Objekt-Cache-Speicher beschrieben worden, der verschiedene Vorteile gegenüber früheren Zugängen besitzt. Insbesondere beschreibt dieses Dokument einen Objekt-Cache-Speicher, der eine hohe Leistung bietet, wie sie durch eine niedrige Latenzzeit und einen hohen Durchsatz für Objektspeicheroperationen und eine große Anzahl gleichzeitiger Operationen gemessen wird. Die hierin beschriebenen Mechanismen sind auf große Objekt-Cache-Speicher anwendbar, die Terabytes von Informationen mit Milliarden von Objekten speichern, die der Wachstumsrate angemessen ist.
  • Der Objekt-Cache-Speicher nutzt die Raumeffizienz des Speichers aus, deshalb wird teurer Halbleiterspeicher sparsam und effektiv verwendet. Der Cache-Speicher bietet außerdem die Raumeffizienz des Plattenspeichers, sodass eine große Anzahl von Kopien von Internet-Objekten innerhalb der endlichen Plattenkapazität des Objektspeichers gespeichert werden kann. Der Cache-Speicher ist aliasfrei, sodass mehrere Objekte oder Objektvarianten mit verschiedenen Namen, aber mit den gleichen inhaltsgleichen Objektinhalten Objektinhalte besitzen, die nur einmal im Cache-Speicher gespeichert sind und unter den verschiedenen Namen gemeinsam verwendet werden.
  • Der hierin beschriebene Cache-Speicher besitzt Unterstützung für Multimedia-Heterogenität, die verschiedene Multimedia-Objekte aus einer großen Zahl von Typen mit Größen effizient unterstützen, die über sechs Größenordnungen von wenigen hundert Bytes zu Hunderten von Megabytes reichen. Der Cache-Speicher besitzt eine schnelle Speicherbereinigung, die sich der Verwendung bewusst ist, damit weniger nützliche Objekte effizient aus dem Objektspeicher entfernt werden können, um Raum für neue Objekte zu schaffen. Der Cache-Speicher unterstützt die Datenkonsistenz, damit Programmfehler und Hardware-Ausfälle nicht zu verfälschen Daten führen.
  • Der Cache-Speicher besitzt eine schnelle Neustartfähigkeit, deshalb kann ein Objekt-Cache-Speicher innerhalb von Sekunden nach dem Neustart beginnen, Anforderungen zu bearbeiten, ohne eine zeitraubende Operation zur Überprüfung der Datenbank oder des Dateisystems zu erfordern. Der Cache-Speicher verwendet Streaming-E/A, damit große Objekte effizient vom Objektspeicher zu langsamen Clients im Pipelinemodus übertragen werden können, ohne das ganze Objekt in den Speicher einzuspeichern. Der Cache-Speicher besitzt Unterstützung für Inhaltsverhandlung, damit Proxy-Cache-Speicher Varianten von Objekten für den gleichen URL, die auf den Client-Browser, die Client-Sprache oder ein anderes Attribut der Client-Anforderung abzielen, effizient und flexibel speichern können. Der Cache-Speicher ist universell, sodass die Objektspeicher-Schnittstelle ausreichend flexibel ist, um die Anforderungen künftiger Medientypen und Protokolle zu erfüllen.
  • Die vorangehenden Vorteile und Eigenschaften sollten als Merkmale der technischen Beschreibung in diesem Dokument betrachtet werden; derartige Vorteile und Eigenschaften bilden jedoch nicht notwendigerweise einen Teil der Erfindung, noch sind sie für irgendeinen speziellen Anspruch erforderlich, der dieser Beschreibung folgt.
  • In der vorangehenden Beschreibung ist die Erfindung unter Bezugnahme auf ihre spezifischen Ausführungsformen und unter Bezugnahme auf spezielle Ziele und Vorteile beschrieben worden. Es ist jedoch offensichtlich, dass an ihr verschiedene Modifikationen und Änderungen vorgenommen werden können, ohne von der Erfindung abzuweichen. Die Beschreibung und die Zeichnung sind demzufolge in einem veranschaulichenden anstatt in einem einschränkenden Sinn zu betrachten.

Claims (24)

  1. Verfahren zum Ausgeben eines Informationsobjekts von einem Cache-Speicher (80) für Informationsobjekte, die durch Schlüsselwerte, die den Informationsobjekten zugeordnet sind, identifiziert werden, wobei der Cache-Speicher (80) eine Tag-Tabelle (102) umfasst, die die Informationsobjekte unter Verwendung einer ersten Menge von Unterschlüsselwerten indexiert, wobei jeder Unterschlüsselwert in der ersten Menge von Unterschlüsselwerten einen Teil eines entsprechenden Schlüsselwertes bildet, wobei eine Verzeichnistabelle (40) mehrere Blöcke besitzt, die durch die erste Menge von Unterschlüsselwerten in der Tag-Tabelle (102) indexiert wird und Referenzen auf Datenspeicherbereiche besitzt, wobei das Verfahren die folgenden Schritte umfasst: (A) Empfangen eines Namens, der ein angefordertes Informationsobjekt identifiziert; (B) Berechnen eines Schlüsselwertes mit fester Größe für das angeforderte Informationsobjekt, wobei der Schlüsselwert mehrere Unterschlüssel umfasst und wobei jeder Unterschlüssel der mehreren Unterschlüssel einen Teil des Schlüsselwertes mit fester Größe bildet; (C) Suchen eines Anpassungsblocks für das angeforderte Informationsobjekt in der Verzeichnistabelle (110) unter Verwendung der Tag-Tabelle (102) und der mehreren Unterschlüssel als Suchschlüssel; und (D) Wiedergewinnen einer Kopie des angeforderten Informationsobjekts aus den Datenspeicherbereichen unter Verwendung einer Referenz, die in dem Anpassungsblock in der Verzeichnistabelle (110) enthalten ist.
  2. Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst: Auswählen einer Version des angeforderten Informationsobjekts aus einer Liste in dem Cache-Speicher (80), die mehrere Versionen der angeforderten Informationsobjekte enthält; Identifizieren eines Speicherplatzes des angeforderten Informationsobjekts in dem Cache-Speicher auf der Grundlage eines Objektschlüssels, der in der Liste in Zuordnung zu der ersten Version gespeichert ist; Wiedergewinnen des angeforderten Informationsobjekts aus dem Speicherplatz; und Ausgeben des angeforderten Informationsobjekts an den Client.
  3. Verfahren nach Anspruch 1, das ferner die folgenden Schritte umfasst: Speichern der Informationsobjekte zusammenhängend in einer Massenspeichervorrichtung (90).
  4. Verfahren nach Anspruch 3, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem zusammenhängenden Pool der Massenspeichervorrichtung (90a, 90b, ..., 90n).
  5. Verfahren nach Anspruch 4, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem von mehreren Arenen in dem Pool.
  6. Verfahren nach Anspruch 5, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem oder mehreren Fragmenten, die von Arenen zugewiesen werden.
  7. Verfahren nach Anspruch 6, bei dem die Fragmente, die ein Informationsobjekt enthalten, durch den vorhergehenden Fragmentschlüssel verknüpft sind.
  8. Verfahren nach Anspruch 2, das ferner die folgenden Schritte umfasst: Speichern der Liste zusammenhängend mit jeder der mehreren Versionen des angeforderten Informationsobjekts; in jedem der Blöcke Speichern eines Größenwertes des angeforderten Informationsobjekts in Zuordnung zu einem solchen Block, wobei der Größenwert eine Speichergröße der Liste sowie die mehreren Versionen des Informationsobjekts angibt; und wobei der Schritt (D) den Schritt des gleichzeitigen Lesens der Liste und der mehreren Versionen umfasst.
  9. Verfahren nach Anspruch 5, das ferner den Schritt umfasst, bei dem mit unterschiedlichen Geschwindigkeiten erfolgende Datenübertragungen in einem Schreibaggregationspuffer konsolidiert werden.
  10. Verfahren nach Anspruch 3, bei dem der Schritt des Speicherns der Informationsobjekte den Schritt umfasst, bei dem die Informationsobjekte in einen zusammenhängenden verfügbaren Speicherraum der Massenspeichervorrichtung geschrieben werden, während gleichzeitig die Schritte (A) bis (D) in Bezug auf ein weiteres Informationsobjekt ausgeführt werden.
  11. Verfahren nach Anspruch 1, bei dem die Tag-Tabelle (102) die erste Menge von Unterschlüsseln durch eine zweite Menge von Unterschlüsseln indexiert, wobei jeder Unterschlüssel der zweiten Menge von Unterschlüsseln einen Teil eines entsprechenden Schlüsselwertes bildet; und wobei die mehreren Unterschlüssel einen ersten Unterschlüssel und einen zweiten Unterschlüssel enthalten; und wobei das Verfahren den Schritt umfasst, bei dem ein Cache-Speicher-Treffer durch Ausführen des Schrittes des Untersuchens der Tag-Tabelle (102) bestimmt wird, um zu bestimmen, ob die Tag-Tabelle (102) den zweiten Unterschlüssel besitzt.
  12. Computerlesbares Medium, das eine oder mehrere Sequenzen von Befehlen für eine Cache-Speicherung von Informationsobjekten trägt, wobei die Ausführung der einen oder der mehreren Sequenzen von Befehlen durch einen oder mehrere Prozessoren den jeweiligen einen oder die jeweiligen mehreren Prozessoren (2) dazu veranlasst, ein Verfahren auszuführen, um ein Informationsobjekt von einem Cache-Speicher (80) für Informationsobjekte auszugeben, wobei die Informationsobjekte durch Schlüsselwerte, die den Informationsobjekten zugeordnet sind, identifiziert werden, wobei der Cache-Speicher (80) eine Tag-Tabelle (102) enthält, die die Informationsobjekte unter Verwendung einer ersten Menge von Unterschlüsselwerten indexiert, wobei jeder Unterschlüsselwert in der ersten Menge von Unterschlüsselwerten einen Teil eines entsprechenden Schlüsselwertes bildet, wobei eine Verzeichnistabelle (110) mehrere Blöcke besitzt, die durch die erste Menge von Unterschlüsselwerten in der Tag-Tabelle (102) indexiert werden und Referenzen auf Datenspeicherbereiche besitzen, wobei das Verfahren die folgenden Schritte umfasst: (A) Empfangen eines Namens, der ein angefordertes Informationsobjekt identifiziert; (B) Berechnen eines Schlüsselwertes mit fester Größe für das angeforderte Informationsobjekt, wobei der Schlüsselwert mehrere Unterschlüssel enthält, wobei jeder Unterschlüssel der mehreren Unterschlüssel einen Teil des Schlüsselwertes mit fester Größe bildet; (C) Suchen eines Anpassungsblocks für das angeforderte Informationsob jekt in der Verzeichnistabelle (110) unter Verwendung der Tag-Tabelle (102) und der mehreren Unterschlüssel als Suchschlüssel; und (D) Wiedergewinnen einer Kopie des angeforderten Informationsobjekts aus den Datenspeicherbereichen unter Verwendung einer Referenz, die in dem Anpassungsblock in der Verzeichnistabelle (110) enthalten ist.
  13. Computerlesbares Medium nach Anspruch 12, das ferner die folgenden Schritte umfasst: Auswählen einer Version des angeforderten Informationsobjekts aus einer Liste in dem Cache-Speicher, die mehrere Versionen der angeforderten Informationsobjekte enthält; Identifizieren eines Speicherplatzes des angeforderten Informationsobjekts in dem Cache-Speicher (80) auf der Grundlage eines Objektschlüssels, der in der Liste in Zuordnung zu der ersten Version gespeichert ist; Wiedergewinnen des angeforderten Informationsobjekts aus dem Speicherplatz; und Ausgeben des angeforderten Informationsobjekts an den Client.
  14. Computerlesbares Medium nach Anspruch 12, das ferner die folgenden Schritte umfasst: Speichern der Informationsobjekte zusammenhängend in einer Massenspeichervorrichtung (90).
  15. Computerlesbares Medium nach Anspruch 14, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem zusammenhängenden Pool der Massenspeichervorrichtung (90a, 90b, ..., 90n).
  16. Computerlesbares Medium nach Anspruch 15, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem von mehreren Arenen in dem Pool.
  17. Computerlesbares Medium nach Anspruch 16, das ferner die folgenden Schritte umfasst: Speichern jedes der Informationsobjekte in einem oder mehreren Fragmenten, die von Arenen zugewiesen werden.
  18. Computerlesbares Medium nach Anspruch 17, bei dem die Fragmente, die ein Informationsobjekt enthalten, durch den vorhergehenden Fragmentschlüssel verknüpft sind.
  19. Computerlesbares Medium nach Anspruch 13, das ferner die folgenden Schritte umfasst: Speichern der Liste zusammenhängend mit jeder der mehreren Versionen des angeforderten Informationsobjekts; in jedem der Blöcke Speichern eines Größenwertes des angeforderten Informationsobjekts in Zuordnung zu einem solchen Block, wobei der Größenwert eine Speichergröße der Liste und der mehreren Versionen des Informationsobjekts angibt; und wobei der Schritt (D) den Schritt des gleichzeitigen Lesens der Liste und der mehreren Versionen umfasst.
  20. Computerlesbares Medium nach Anspruch 16, das ferner den Schritt umfasst, bei dem mit unterschiedlichen Geschwindigkeiten erfolgende Datenübertragungen in einem Schreibaggregationspuffer konsolidiert werden.
  21. Computerlesbares Medium nach Anspruch 14, bei dem der Schritt des Speicherns der Informationsobjekte den Schritt des Schreibens der Informationsobjekte in einen zusammenhängenden verfügbaren Speicherraum der Massenspeichervorrichtung umfasst, während gleichzeitig die Schritte (A) bis (D) in Bezug auf ein weiteres Informationsobjekt ausgeführt werden.
  22. Verfahren nach Anspruch 11, bei dem der Schritt des Bestimmens eines Cache-Speicher-Treffers ferner den Schritt umfasst, bei dem festgestellt wird, ob der erste Unterschlüssel auf den zweiten Unterschlüssel indexiert ist.
  23. Computerprogramm, das Programmcode umfasst, der geeignet ist, ein Verfahren nach einem der Ansprüche 1 bis 10, 11 oder 22 auszuführen.
  24. Computerdatensignal, das in eine Trägerwelle eingebettet ist und Informationen für die Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 10, 11 oder 22 transportiert.
DE69915462T 1998-04-15 1999-04-15 Sehr leistungsstarker objektcache Expired - Lifetime DE69915462T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/060,866 US6128623A (en) 1998-04-15 1998-04-15 High performance object cache
US60866 1998-04-15
PCT/US1999/008281 WO1999053422A1 (en) 1998-04-15 1999-04-15 High performance object cache

Publications (2)

Publication Number Publication Date
DE69915462D1 DE69915462D1 (de) 2004-04-15
DE69915462T2 true DE69915462T2 (de) 2005-03-03

Family

ID=22032231

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69915462T Expired - Lifetime DE69915462T2 (de) 1998-04-15 1999-04-15 Sehr leistungsstarker objektcache

Country Status (6)

Country Link
US (2) US6128623A (de)
EP (1) EP1072004B1 (de)
JP (1) JP4489292B2 (de)
AU (1) AU754816B2 (de)
DE (1) DE69915462T2 (de)
WO (1) WO1999053422A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016103882A1 (de) * 2016-03-03 2017-09-07 Cadami Ug (Haftungsbeschränkt) Zuordnungsverfahren sowie Netzwerk mit einer Zuordnungsvorrichtung
DE102016108018A1 (de) * 2016-03-03 2017-09-07 Cadami Ug (Haftungsbeschränkt) Kennungscodierungseinrichtung und Kennungsdecodierungseinrichtung zur Datenverteilung in Netzwerken sowie derartige Einrichtungen aufweisende Netzwerkelemente

Families Citing this family (364)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6031995A (en) * 1996-11-06 2000-02-29 George; A. Chacko Object-oriented sequencing using hierarchical configuration streams
US6760746B1 (en) 1999-09-01 2004-07-06 Eric Schneider Method, product, and apparatus for processing a data request
US6915307B1 (en) * 1998-04-15 2005-07-05 Inktomi Corporation High performance object cache
US6128623A (en) * 1998-04-15 2000-10-03 Inktomi Corporation High performance object cache
US6289358B1 (en) * 1998-04-15 2001-09-11 Inktomi Corporation Delivering alternate versions of objects from an object cache
US6389460B1 (en) * 1998-05-13 2002-05-14 Compaq Computer Corporation Method and apparatus for efficient storage and retrieval of objects in and from an object storage device
US6591305B2 (en) * 1998-06-30 2003-07-08 Sun Microsystems, Inc. Method and system for delivering data from a server object to a client object using a non-proprietary data transfer protocol
US6308214B1 (en) 1998-09-23 2001-10-23 Inktomi Corporation Self-tuning dataflow I/O core
US6957436B1 (en) * 1999-01-29 2005-10-18 Iona Technologies, Plc Method and system for multi-threaded object loading and unloading
US6907609B1 (en) * 1999-02-01 2005-06-14 Iona Technologies Plc. Object request dispatch using matching of a segmented object key
US6453321B1 (en) * 1999-02-11 2002-09-17 Ibm Corporation Structured cache for persistent objects
US7188138B1 (en) 1999-03-22 2007-03-06 Eric Schneider Method, product, and apparatus for resource identifier registration and aftermarket services
USRE43690E1 (en) 1999-03-22 2012-09-25 Esdr Network Solutions Llc Search engine request method, product, and apparatus
US6338082B1 (en) 1999-03-22 2002-01-08 Eric Schneider Method, product, and apparatus for requesting a network resource
US8037168B2 (en) 1999-07-15 2011-10-11 Esdr Network Solutions Llc Method, product, and apparatus for enhancing resolution services, registration services, and search services
US9141717B2 (en) 1999-03-22 2015-09-22 Esdr Network Solutions Llc Methods, systems, products, and devices for processing DNS friendly identifiers
US6701415B1 (en) * 1999-03-31 2004-03-02 America Online, Inc. Selecting a cache for a request for information
US6542967B1 (en) * 1999-04-12 2003-04-01 Novell, Inc. Cache object store
US6240313B1 (en) * 1999-04-19 2001-05-29 Cardiac Pacemakers, Inc. Cardiac rhythm management system with prevention of double counting of events
US7313581B1 (en) * 1999-04-29 2007-12-25 International Business Machines Corporation Method for deferred deletion of entries for a directory service backing store
US6745368B1 (en) 1999-06-11 2004-06-01 Liberate Technologies Methods, apparatus, and systems for storing, retrieving and playing multimedia data
US6973505B1 (en) * 1999-09-01 2005-12-06 Eric Schneider Network resource access method, product, and apparatus
USRE44207E1 (en) 1999-09-01 2013-05-07 Esdr Network Solutions Llc Network resource access method, product, and apparatus
US6721780B1 (en) * 1999-11-09 2004-04-13 Fireclick, Inc. Predictive pre-download of network objects
US6553461B1 (en) * 1999-12-10 2003-04-22 Sun Microsystems, Inc. Client controlled pre-fetching of resources
US7243136B2 (en) * 2000-01-18 2007-07-10 Inktomi Corporation Approach for managing and providing content to users
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
JP2001243079A (ja) * 2000-03-02 2001-09-07 Omron Corp 情報処理システム
US7988559B2 (en) 2001-03-08 2011-08-02 Igt Computerized gaming system, method and apparatus
US7043641B1 (en) 2000-03-08 2006-05-09 Igt Encryption in a secure computerized gaming system
US6711595B1 (en) * 2000-05-09 2004-03-23 Openwave Systems Inc. Method and apparatus for sharing standard template library objects among processes
US7013340B1 (en) 2000-05-18 2006-03-14 Microsoft Corporation Postback input handling by server-side control objects
US6876997B1 (en) 2000-05-22 2005-04-05 Overture Services, Inc. Method and apparatus for indentifying related searches in a database search system
US20020032691A1 (en) * 2000-05-26 2002-03-14 Infolibria, Inc. High performance efficient subsystem for data object storage
US7673229B1 (en) 2000-06-07 2010-03-02 Ebay Inc. Apparatus and method for generating sub-codes to a turbo-encoder
EP1295293A2 (de) * 2000-06-09 2003-03-26 Koninklijke Philips Electronics N.V. Verfahren zur impliziten aufteilung des auf einem aufzeichnungsmedium zur verfügung stehenden speicherraums
US7951002B1 (en) 2000-06-16 2011-05-31 Igt Using a gaming machine as a server
JP2002002140A (ja) * 2000-06-22 2002-01-08 Riso Kagaku Corp 微多孔性孔版原紙およびその利用
US6941351B2 (en) 2000-07-11 2005-09-06 Microsoft Corporation Application program caching
US7603407B2 (en) * 2000-08-17 2009-10-13 Sun Microsystems, Inc. Method and system for registering binary data
US6694338B1 (en) * 2000-08-29 2004-02-17 Contivo, Inc. Virtual aggregate fields
US20020059499A1 (en) * 2000-09-06 2002-05-16 Hudson Michael D. System and methods for performing last-element streaming
US20020059440A1 (en) * 2000-09-06 2002-05-16 Hudson Michael D. Client-side last-element cache network architecture
US6928466B1 (en) * 2000-09-28 2005-08-09 Emc Corporation Method and system for identifying memory component identifiers associated with data
US6625591B1 (en) * 2000-09-29 2003-09-23 Emc Corporation Very efficient in-memory representation of large file system directories
US7111141B2 (en) * 2000-10-17 2006-09-19 Igt Dynamic NV-RAM
US6804763B1 (en) * 2000-10-17 2004-10-12 Igt High performance battery backed ram interface
US20020087798A1 (en) * 2000-11-15 2002-07-04 Vijayakumar Perincherry System and method for adaptive data caching
US6993523B1 (en) 2000-12-05 2006-01-31 Silicon Graphics, Inc. System and method for maintaining and recovering data consistency in a data base page
US6721739B1 (en) 2000-12-05 2004-04-13 Silicon Graphics, Inc. System and method for maintaining and recovering data consistency across multiple pages
US6751636B1 (en) * 2000-12-05 2004-06-15 Silicon Graphics, Inc. System and method for maintaining and recovering data consistency across multiple instances of a database
US7515718B2 (en) * 2000-12-07 2009-04-07 Igt Secured virtual network in a gaming environment
US8550922B2 (en) * 2006-03-03 2013-10-08 Igt Game removal with game history
US20070136817A1 (en) * 2000-12-07 2007-06-14 Igt Wager game license management in a peer gaming network
US7972214B2 (en) 2000-12-07 2011-07-05 Igt Methods and devices for downloading games of chance
US7168089B2 (en) * 2000-12-07 2007-01-23 Igt Secured virtual network in a gaming environment
US7127069B2 (en) * 2000-12-07 2006-10-24 Igt Secured virtual network in a gaming environment
US7730213B2 (en) * 2000-12-18 2010-06-01 Oracle America, Inc. Object-based storage device with improved reliability and fast crash recovery
US6931450B2 (en) 2000-12-18 2005-08-16 Sun Microsystems, Inc. Direct access from client to storage device
US6745285B2 (en) * 2000-12-18 2004-06-01 Sun Microsystems, Inc. System and method for synchronizing mirrored and striped disk writes
US6990493B1 (en) * 2000-12-22 2006-01-24 Emc Corporation File access system
US7269784B1 (en) * 2001-01-22 2007-09-11 Kasriel Stephane Server-originated differential caching
US7921033B2 (en) * 2001-01-29 2011-04-05 Microsoft Corporation System and method for high-density interactive voting using a computer network
US6721850B2 (en) 2001-02-27 2004-04-13 Lucent Technologies Inc. Method of cache replacement for streaming media
WO2002069561A2 (en) * 2001-02-27 2002-09-06 Visa International Service Association Distributed quantum encrypted pattern generation and scoring
US7380250B2 (en) 2001-03-16 2008-05-27 Microsoft Corporation Method and system for interacting with devices having different capabilities
US6754799B2 (en) * 2001-05-16 2004-06-22 Microsoft Corporation System and method for indexing and retrieving cached objects
US7269608B2 (en) * 2001-05-30 2007-09-11 Sun Microsystems, Inc. Apparatus and methods for caching objects using main memory and persistent memory
US20020184612A1 (en) * 2001-06-01 2002-12-05 Hunt Joseph R. Runtime configurable caching for component factories
US7493397B1 (en) 2001-06-06 2009-02-17 Microsoft Corporation Providing remote processing services over a distributed communications network
US6915454B1 (en) 2001-06-12 2005-07-05 Microsoft Corporation Web controls validation
EP1401546A4 (de) 2001-06-15 2006-11-02 Walker Digital Llc Verfahren und vorrichtung zur planung und individualisierung einer spielerfahrung
US7185063B1 (en) * 2001-06-22 2007-02-27 Digital River, Inc. Content delivery network using differential caching
US6880154B2 (en) * 2001-06-29 2005-04-12 Intel Corporation Alias-free test for dynamic array structures
US6854033B2 (en) * 2001-06-29 2005-02-08 Intel Corporation Using linked list for caches with variable length data
US6877066B2 (en) * 2001-06-29 2005-04-05 International Business Machines Corporation Method and system for adaptive caching in a network management framework using skeleton caches
US8019789B2 (en) * 2001-07-03 2011-09-13 Research In Motion Limited System and method of object-oriented persistence
US7594001B1 (en) * 2001-07-06 2009-09-22 Microsoft Corporation Partial page output caching
US7761497B1 (en) * 2001-07-13 2010-07-20 Vignette Software, LLC Storage medium having a manageable file directory structure
US6714934B1 (en) 2001-07-31 2004-03-30 Logika Corporation Method and system for creating vertical search engines
US7162036B2 (en) * 2001-08-06 2007-01-09 Igt Digital identification of unique game characteristics
US7092997B1 (en) 2001-08-06 2006-08-15 Digital River, Inc. Template identification with differential caching
US7188214B1 (en) 2001-08-07 2007-03-06 Digital River, Inc. Efficient compression using differential caching
US6685567B2 (en) 2001-08-08 2004-02-03 Igt Process verification
US7428548B2 (en) 2001-08-15 2008-09-23 Bentley Systems, Inc. Computer readable medium for storing large data files
EP1417800B1 (de) * 2001-08-15 2017-10-04 Bentley Systems, Incorporated Verfahren und system zum speichern grosser dateien
US6890259B2 (en) 2001-09-10 2005-05-10 Igt Modular tilt handling system
US7931533B2 (en) * 2001-09-28 2011-04-26 Igt Game development architecture that decouples the game logic from the graphics logics
US8708828B2 (en) 2001-09-28 2014-04-29 Igt Pluggable modular gaming modifiers and configuration templates for gaming environments
US6902481B2 (en) 2001-09-28 2005-06-07 Igt Decoupling of the graphical presentation of a game from the presentation logic
US7269663B2 (en) * 2001-09-28 2007-09-11 Intel Corporation Tagging packets with a lookup key to facilitate usage of a unified packet forwarding cache
TW512268B (en) * 2001-11-05 2002-12-01 Ind Tech Res Inst Single-layered consistent data cache dynamic accessing method and system
US6829679B2 (en) * 2001-11-09 2004-12-07 International Business Machines Corporation Different caching treatment of memory contents based on memory region
US6754800B2 (en) * 2001-11-14 2004-06-22 Sun Microsystems, Inc. Methods and apparatus for implementing host-based object storage schemes
US7428725B2 (en) 2001-11-20 2008-09-23 Microsoft Corporation Inserting devices specific content
US7588535B2 (en) * 2001-12-11 2009-09-15 C2Cure Inc. Apparatus, method and system for intravascular photographic imaging
US20030115421A1 (en) * 2001-12-13 2003-06-19 Mchenry Stephen T. Centralized bounded domain caching control system for network edge servers
US7565402B2 (en) 2002-01-05 2009-07-21 Eric Schneider Sitemap access method, product, and apparatus
US7316616B2 (en) * 2002-01-16 2008-01-08 Igt Gaming system license management
US9167036B2 (en) * 2002-02-14 2015-10-20 Level 3 Communications, Llc Managed object replication and delivery
US7296051B1 (en) 2002-02-19 2007-11-13 Digital River, Inc. Predictive predownload of templates with delta encoding
US7487261B1 (en) 2002-02-22 2009-02-03 Digital River, Inc. Delta caching service
US6997803B2 (en) * 2002-03-12 2006-02-14 Igt Virtual gaming peripherals for a gaming machine
US8597116B2 (en) 2002-03-12 2013-12-03 Igt Virtual player tracking and related services
US8360838B2 (en) 2006-07-03 2013-01-29 Igt Detecting and preventing bots and cheating in online gaming
US7707287B2 (en) * 2002-03-22 2010-04-27 F5 Networks, Inc. Virtual host acceleration system
US7680875B1 (en) 2002-04-01 2010-03-16 Novell, Inc. Markers for cached objects
US6950838B2 (en) * 2002-04-17 2005-09-27 Sun Microsystems, Inc. Locating references and roots for in-cache garbage collection
EP1502196A4 (de) * 2002-05-02 2008-04-02 Sarvega Inc System und verfahren zur transformation von xml-dokumenten mit stylesheets
US7243141B2 (en) * 2002-05-13 2007-07-10 Sony Computer Entertainment America, Inc. Network configuration evaluation
US7676579B2 (en) * 2002-05-13 2010-03-09 Sony Computer Entertainment America Inc. Peer to peer network communication
TWI240179B (en) * 2002-06-06 2005-09-21 Taiwan Semiconductor Mfg Parsing method for recipe data
US7918730B2 (en) 2002-06-27 2011-04-05 Igt Trajectory-based 3-D games of chance for video gaming machines
US8224985B2 (en) 2005-10-04 2012-07-17 Sony Computer Entertainment Inc. Peer-to-peer communication traversing symmetric network address translators
US8060626B2 (en) 2008-09-22 2011-11-15 Sony Computer Entertainment America Llc. Method for host selection based on discovered NAT type
US8083585B2 (en) * 2002-09-10 2011-12-27 Igt Apparatus and method for copying gaming machine configuration settings
US7552223B1 (en) * 2002-09-16 2009-06-23 Netapp, Inc. Apparatus and method for data consistency in a proxy cache
US7287046B2 (en) * 2002-09-30 2007-10-23 Emc Corporation Method and system of compacting sparse directories in a file system
US7574653B2 (en) 2002-10-11 2009-08-11 Microsoft Corporation Adaptive image formatting control
AU2002952274A0 (en) * 2002-10-24 2002-11-07 Ideadata Pty Ltd A computing device and method for recording data exchanged between electronic devices
US7162582B2 (en) * 2002-11-18 2007-01-09 Aristos Logic Corporation Caching in a virtualization system
US20040106452A1 (en) * 2002-12-02 2004-06-03 Igt Hosted game development environment
US7093099B2 (en) * 2002-12-12 2006-08-15 Alacritech, Inc. Native lookup instruction for file-access processor searching a three-level lookup cache for variable-length keys
GB0229892D0 (en) * 2002-12-21 2003-01-29 Ibm Method and apparatus for caching documents
US20040128329A1 (en) * 2002-12-31 2004-07-01 International Business Machines Corporation Parallel incremental compaction
US7827282B2 (en) * 2003-01-08 2010-11-02 At&T Intellectual Property I, L.P. System and method for processing hardware or service usage data
US7080060B2 (en) * 2003-01-08 2006-07-18 Sbc Properties, L.P. System and method for intelligent data caching
US7797626B2 (en) * 2003-02-12 2010-09-14 Sap Ag Managing different representations of information
US20040167981A1 (en) * 2003-02-25 2004-08-26 Douglas Christopher Paul Method and system for monitoring relationships between content devices in a content delivery network
US20040167977A1 (en) * 2003-02-25 2004-08-26 Douglas Christopher Paul Method and system for monitoring streaming media flow
US7975043B2 (en) 2003-02-25 2011-07-05 Hewlett-Packard Development Company, L.P. Method and apparatus for monitoring a network
US7409644B2 (en) 2003-05-16 2008-08-05 Microsoft Corporation File system shell
US7769794B2 (en) 2003-03-24 2010-08-03 Microsoft Corporation User interface for a file system shell
US7240292B2 (en) 2003-04-17 2007-07-03 Microsoft Corporation Virtual address bar user interface control
US7421438B2 (en) 2004-04-29 2008-09-02 Microsoft Corporation Metadata editing control
US7712034B2 (en) 2003-03-24 2010-05-04 Microsoft Corporation System and method for shell browser
US7627552B2 (en) 2003-03-27 2009-12-01 Microsoft Corporation System and method for filtering and organizing items based on common elements
US7823077B2 (en) 2003-03-24 2010-10-26 Microsoft Corporation System and method for user modification of metadata in a shell browser
US7827561B2 (en) 2003-03-26 2010-11-02 Microsoft Corporation System and method for public consumption of communication events between arbitrary processes
US7890960B2 (en) 2003-03-26 2011-02-15 Microsoft Corporation Extensible user context system for delivery of notifications
US7587411B2 (en) 2003-03-27 2009-09-08 Microsoft Corporation System and method for filtering and organizing items based on common elements
US7925682B2 (en) 2003-03-27 2011-04-12 Microsoft Corporation System and method utilizing virtual folders
US7526483B2 (en) 2003-03-27 2009-04-28 Microsoft Corporation System and method for virtual folder sharing including utilization of static and dynamic lists
US7536386B2 (en) * 2003-03-27 2009-05-19 Microsoft Corporation System and method for sharing items in a computer system
US7499925B2 (en) 2003-03-27 2009-03-03 Microsoft Corporation File system for displaying items of different types and from different physical locations
US7650575B2 (en) 2003-03-27 2010-01-19 Microsoft Corporation Rich drag drop user interface
US7546319B1 (en) * 2003-04-28 2009-06-09 Ibrix, Inc. File system consistency checking in a distributed segmented file system
WO2004114529A2 (en) * 2003-06-16 2004-12-29 Mentat Inc. Pre-fetch communication systems and methods
US7617203B2 (en) * 2003-08-01 2009-11-10 Yahoo! Inc Listings optimization using a plurality of data sources
US7426525B2 (en) * 2003-08-08 2008-09-16 Hewlett-Packard Development Company, L.P. Method and apparatus for identifying an object using an object description language
JPWO2005033952A1 (ja) * 2003-09-30 2006-12-14 ソニー株式会社 情報再生装置および方法、並びにプログラム
US9564004B2 (en) 2003-10-20 2017-02-07 Igt Closed-loop system for providing additional event participation to electronic video game customers
US8512144B2 (en) 2003-10-20 2013-08-20 Tipping Point Group, Llc Method and apparatus for providing secondary gaming machine functionality
US7877390B2 (en) * 2003-10-20 2011-01-25 International Business Machines Corporation Systems and methods for providing autonomous persistent storage systems
US8024335B2 (en) 2004-05-03 2011-09-20 Microsoft Corporation System and method for dynamically generating a selectable search extension
US7181463B2 (en) * 2003-10-24 2007-02-20 Microsoft Corporation System and method for managing data using static lists
US7171540B1 (en) * 2003-10-31 2007-01-30 Sun Microsystems, Inc. Object-addressed memory hierarchy that facilitates accessing objects stored outside of main memory
US7076608B2 (en) * 2003-12-02 2006-07-11 Oracle International Corp. Invalidating cached data using secondary keys
US7826600B2 (en) * 2003-12-22 2010-11-02 International Business Machines Corporation Method and procedure for compiling and caching VoiceXML documents in a voice XML interpreter
US7418464B2 (en) * 2004-01-27 2008-08-26 International Business Machines Corporation Method, system, and program for storing data for retrieval and transfer
KR101164788B1 (ko) * 2004-03-23 2012-07-11 엔디에스 리미티드 이동 가입자 단말기 재생에 적합하게 순응하는 멀티미디어콘텐트
US9092558B2 (en) * 2004-04-05 2015-07-28 International Business Machines Corporation Grouping frequently referenced data items to co-locate for cache utilization
US7694236B2 (en) 2004-04-23 2010-04-06 Microsoft Corporation Stack icons representing multiple objects
US7657846B2 (en) 2004-04-23 2010-02-02 Microsoft Corporation System and method for displaying stack icons
US7992103B2 (en) 2004-04-26 2011-08-02 Microsoft Corporation Scaling icons for representing files
US8707209B2 (en) 2004-04-29 2014-04-22 Microsoft Corporation Save preview representation of files being created
US8108430B2 (en) 2004-04-30 2012-01-31 Microsoft Corporation Carousel control for metadata navigation and assignment
US7496583B2 (en) * 2004-04-30 2009-02-24 Microsoft Corporation Property tree for metadata navigation and assignment
US7890604B2 (en) 2004-05-07 2011-02-15 Microsoft Corproation Client-side callbacks to server events
US9026578B2 (en) 2004-05-14 2015-05-05 Microsoft Corporation Systems and methods for persisting data between web pages
US7464386B2 (en) 2004-05-17 2008-12-09 Microsoft Corporation Data controls architecture
US7401102B2 (en) * 2004-10-19 2008-07-15 International Business Machines Corporation Management of global counters in transactions
KR100654447B1 (ko) * 2004-12-15 2006-12-06 삼성전자주식회사 지역별로 존재하는 컨텐츠를 글로벌로 공유하고 거래하는방법 및 시스템
US9613491B2 (en) 2004-12-16 2017-04-04 Igt Video gaming device having a system and method for completing wagers and purchases during the cash out process
JP2006185059A (ja) * 2004-12-27 2006-07-13 Fujitsu Ltd コンテンツ管理装置
US7383503B2 (en) * 2005-02-23 2008-06-03 Microsoft Corporation Filtering a collection of items
US20070073678A1 (en) * 2005-09-23 2007-03-29 Applied Linguistics, Llc Semantic document profiling
US8490015B2 (en) 2005-04-15 2013-07-16 Microsoft Corporation Task dialog and programming interface for same
US20060236253A1 (en) * 2005-04-15 2006-10-19 Microsoft Corporation Dialog user interfaces for related tasks and programming interface for same
US8195646B2 (en) 2005-04-22 2012-06-05 Microsoft Corporation Systems, methods, and user interfaces for storing, searching, navigating, and retrieving electronic information
US8522154B2 (en) 2005-04-22 2013-08-27 Microsoft Corporation Scenario specialization of file browser
MX2007013695A (es) * 2005-05-03 2008-01-24 Igt Reno Nev "dispositivo y metodo para una interfaz dinamicamente configurable de usuario en un juego de probabilidad".
US7752625B2 (en) * 2005-06-17 2010-07-06 International Business Machines Corporation Caching resources requested by applications
US7966292B1 (en) 2005-06-30 2011-06-21 Emc Corporation Index processing
US8161005B1 (en) 2005-06-30 2012-04-17 Emc Corporation Efficient index processing
US8156079B1 (en) 2005-06-30 2012-04-10 Emc Corporation System and method for index processing
US7665028B2 (en) 2005-07-13 2010-02-16 Microsoft Corporation Rich drag drop user interface
US7887420B2 (en) 2005-09-12 2011-02-15 Igt Method and system for instant-on game download
US8287379B2 (en) 2005-09-12 2012-10-16 Igt Distributed game services
US20070073745A1 (en) * 2005-09-23 2007-03-29 Applied Linguistics, Llc Similarity metric for semantic profiling
CA2621523C (en) * 2005-09-27 2010-07-13 Nathan Provo System for transforming application data using xslt extensions to render templates from cache and related methods
EP1938206A1 (de) * 2005-09-27 2008-07-02 Teamon Systems, Inc. System zum erhalten eines bildes unter verwendung einer xslt-erweiterung und diesbezügliches verfahren
US7627609B1 (en) 2005-09-30 2009-12-01 Emc Corporation Index processing using transformed values
US7698325B1 (en) 2005-09-30 2010-04-13 Emc Corporation Index processing for legacy systems
US7752211B1 (en) * 2005-09-30 2010-07-06 Emc Corporation Adaptive index processing
US20070112791A1 (en) * 2005-11-09 2007-05-17 Harvey Richard H Method and system for providing enhanced read performance for a supplemental directory
US20070112812A1 (en) * 2005-11-09 2007-05-17 Harvey Richard H System and method for writing data to a directory
US8326899B2 (en) * 2005-11-09 2012-12-04 Ca, Inc. Method and system for improving write performance in a supplemental directory
US8458176B2 (en) * 2005-11-09 2013-06-04 Ca, Inc. Method and system for providing a directory overlay
US8321486B2 (en) * 2005-11-09 2012-11-27 Ca, Inc. Method and system for configuring a supplemental directory
US7529780B1 (en) 2005-12-30 2009-05-05 Google Inc. Conflict management during data object synchronization between client and server
US7951008B2 (en) * 2006-03-03 2011-05-31 Igt Non-volatile memory management technique implemented in a gaming machine
US8968077B2 (en) 2006-04-13 2015-03-03 Idt Methods and systems for interfacing with a third-party application
US8777737B2 (en) * 2006-04-13 2014-07-15 Igt Method and apparatus for integrating remotely-hosted and locally rendered content on a gaming device
US10026255B2 (en) 2006-04-13 2018-07-17 Igt Presentation of remotely-hosted and locally rendered content for gaming systems
US9028329B2 (en) 2006-04-13 2015-05-12 Igt Integrating remotely-hosted and locally rendered content on a gaming device
US8784196B2 (en) 2006-04-13 2014-07-22 Igt Remote content management and resource sharing on a gaming machine and method of implementing same
US8992304B2 (en) 2006-04-13 2015-03-31 Igt Methods and systems for tracking an event of an externally controlled interface
US10324735B2 (en) 2006-05-15 2019-06-18 Avaya Inc. Method invocation for persistent objects with dynamic multikeys
US10289728B2 (en) * 2006-05-15 2019-05-14 Avaya Inc. Garbage collection of persistent objects with dynamic multikeys
US10185579B2 (en) 2006-05-15 2019-01-22 Avaya Inc. Dynamic multikeys for persistent objects
US7720892B1 (en) * 2006-06-30 2010-05-18 Emc Corporation Bulk updates and tape synchronization
EP2057821A1 (de) * 2006-08-29 2009-05-13 Nokia Corporation Dienstidentifikationsoptimierung
US7963839B2 (en) * 2006-09-19 2011-06-21 Mudalla Technology, Inc. Regulated gaming exchange
US9311774B2 (en) 2006-11-10 2016-04-12 Igt Gaming machine with externally controlled content display
US20090156303A1 (en) 2006-11-10 2009-06-18 Igt Bonusing Architectures in a Gaming Environment
US20090031401A1 (en) 2007-04-27 2009-01-29 Bea Systems, Inc. Annotations for enterprise web application constructor
US7995478B2 (en) 2007-05-30 2011-08-09 Sony Computer Entertainment Inc. Network communication with path MTU size discovery
US7933273B2 (en) 2007-07-27 2011-04-26 Sony Computer Entertainment Inc. Cooperative NAT behavior discovery
JP5064134B2 (ja) * 2007-08-03 2012-10-31 株式会社日立製作所 メモリ管理方法およびその方法を用いるコンピュータ
US7908393B2 (en) 2007-12-04 2011-03-15 Sony Computer Entertainment Inc. Network bandwidth detection, distribution and traffic prioritization
US20090193210A1 (en) * 2008-01-29 2009-07-30 Hewett Jeffrey R System for Automatic Legal Discovery Management and Data Collection
US20090198699A1 (en) * 2008-01-31 2009-08-06 International Business Machines Corporation Remote space efficient repository
WO2009097586A1 (en) * 2008-01-31 2009-08-06 Bea Systems, Inc. System and method for transactional cache
US7856506B2 (en) 2008-03-05 2010-12-21 Sony Computer Entertainment Inc. Traversal of symmetric network address translator for multiple simultaneous connections
CA2720353C (en) 2008-04-04 2016-01-19 Level 3 Communications, Llc Handling long-tail content in a content delivery network (cdn)
US10924573B2 (en) 2008-04-04 2021-02-16 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US9762692B2 (en) 2008-04-04 2017-09-12 Level 3 Communications, Llc Handling long-tail content in a content delivery network (CDN)
US9456054B2 (en) 2008-05-16 2016-09-27 Palo Alto Research Center Incorporated Controlling the spread of interests and content in a content centric network
US8578338B2 (en) * 2008-06-02 2013-11-05 Igt Game production and regulatory approval systems
US8386494B2 (en) * 2008-08-07 2013-02-26 Hewlett-Packard Development Company, L.P. Providing data structures for determining whether keys of an index are present in a storage system
US9934240B2 (en) * 2008-09-30 2018-04-03 Google Llc On demand access to client cached files
US8620861B1 (en) 2008-09-30 2013-12-31 Google Inc. Preserving file metadata during atomic save operations
US10235832B2 (en) 2008-10-17 2019-03-19 Igt Post certification metering for diverse game machines
US7962502B2 (en) 2008-11-18 2011-06-14 Yahoo! Inc. Efficient caching for dynamic webservice queries using cachable fragments
US8190844B2 (en) * 2008-12-02 2012-05-29 Lsi Corporation Efficient alert mechanism for overutilization of storage resources
US8055841B2 (en) 2009-02-19 2011-11-08 International Business Machines Corporation System and method for caching data on a hard disk drive
EP2402882A4 (de) * 2009-02-27 2014-09-17 Fujitsu Ltd Programm, einrichtung und verfahren für eine elektronische signatur
US20100228906A1 (en) * 2009-03-06 2010-09-09 Arunprasad Ramiya Mothilal Managing Data in a Non-Volatile Memory System
US8677329B2 (en) * 2009-06-03 2014-03-18 Apple Inc. Methods and apparatuses for a compiler server
US9117071B2 (en) * 2009-06-03 2015-08-25 Apple Inc. Methods and apparatuses for secure compilation
US8923293B2 (en) 2009-10-21 2014-12-30 Palo Alto Research Center Incorporated Adaptive multi-interface use for content networking
US8156385B2 (en) * 2009-10-28 2012-04-10 International Business Machines Corporation Systems and methods for backward-compatible constant-time exception-protection memory
US8577936B2 (en) 2010-11-29 2013-11-05 International Business Machines Corporation Fixup cache tool for object memory compaction in an information handling system
US8463765B2 (en) 2011-04-29 2013-06-11 Zachary C. LESAVICH Method and system for creating vertical search engines with cloud computing networks
US9400851B2 (en) * 2011-06-23 2016-07-26 Incapsula, Inc. Dynamic content caching
US9378138B2 (en) 2011-06-29 2016-06-28 International Business Machines Corporation Conservative garbage collection and access protection
US9466173B2 (en) 2011-09-30 2016-10-11 Igt System and method for remote rendering of content on an electronic gaming machine
US9524609B2 (en) 2011-09-30 2016-12-20 Igt Gaming system, gaming device and method for utilizing mobile devices at a gaming establishment
US9251086B2 (en) 2012-01-24 2016-02-02 SanDisk Technologies, Inc. Apparatus, system, and method for managing a cache
US8938428B1 (en) 2012-04-16 2015-01-20 Emc Corporation Systems and methods for efficiently locating object names in a large index of records containing object names
US10019371B2 (en) * 2012-04-27 2018-07-10 Hewlett Packard Enterprise Development Lp Data caching using local and remote memory
US8898376B2 (en) 2012-06-04 2014-11-25 Fusion-Io, Inc. Apparatus, system, and method for grouping data stored on an array of solid-state storage elements
US9229901B1 (en) * 2012-06-08 2016-01-05 Google Inc. Single-sided distributed storage system
US9569356B1 (en) 2012-06-15 2017-02-14 Emc Corporation Methods for updating reference count and shared objects in a concurrent system
US8909808B2 (en) * 2012-07-19 2014-12-09 Cisco Technology, Inc. Redundancy elimination for web caching
US10528262B1 (en) * 2012-07-26 2020-01-07 EMC IP Holding Company LLC Replication-based federation of scalable data across multiple sites
US9164702B1 (en) * 2012-09-07 2015-10-20 Google Inc. Single-sided distributed cache system
US9129469B2 (en) 2012-09-11 2015-09-08 Igt Player driven game download to a gaming machine
US9213646B1 (en) 2013-06-20 2015-12-15 Seagate Technology Llc Cache data value tracking
US10098051B2 (en) 2014-01-22 2018-10-09 Cisco Technology, Inc. Gateways and routing in software-defined manets
US9954678B2 (en) 2014-02-06 2018-04-24 Cisco Technology, Inc. Content-based transport security
US9836540B2 (en) 2014-03-04 2017-12-05 Cisco Technology, Inc. System and method for direct storage access in a content-centric network
US9626413B2 (en) 2014-03-10 2017-04-18 Cisco Systems, Inc. System and method for ranking content popularity in a content-centric network
US9716622B2 (en) 2014-04-01 2017-07-25 Cisco Technology, Inc. System and method for dynamic name configuration in content-centric networks
US9473576B2 (en) 2014-04-07 2016-10-18 Palo Alto Research Center Incorporated Service discovery using collection synchronization with exact names
US9992281B2 (en) 2014-05-01 2018-06-05 Cisco Technology, Inc. Accountable content stores for information centric networks
US9609014B2 (en) 2014-05-22 2017-03-28 Cisco Systems, Inc. Method and apparatus for preventing insertion of malicious content at a named data network router
US9699198B2 (en) 2014-07-07 2017-07-04 Cisco Technology, Inc. System and method for parallel secure content bootstrapping in content-centric networks
US9430387B2 (en) * 2014-07-16 2016-08-30 ClearSky Data Decoupling data and metadata in hierarchical cache system
US9621354B2 (en) 2014-07-17 2017-04-11 Cisco Systems, Inc. Reconstructable content objects
US9729616B2 (en) 2014-07-18 2017-08-08 Cisco Technology, Inc. Reputation-based strategy for forwarding and responding to interests over a content centric network
US9590887B2 (en) 2014-07-18 2017-03-07 Cisco Systems, Inc. Method and system for keeping interest alive in a content centric network
US9535968B2 (en) * 2014-07-21 2017-01-03 Palo Alto Research Center Incorporated System for distributing nameless objects using self-certifying names
US9882964B2 (en) 2014-08-08 2018-01-30 Cisco Technology, Inc. Explicit strategy feedback in name-based forwarding
US9729662B2 (en) 2014-08-11 2017-08-08 Cisco Technology, Inc. Probabilistic lazy-forwarding technique without validation in a content centric network
US9800637B2 (en) 2014-08-19 2017-10-24 Cisco Technology, Inc. System and method for all-in-one content stream in content-centric networks
US10069933B2 (en) 2014-10-23 2018-09-04 Cisco Technology, Inc. System and method for creating virtual interfaces based on network characteristics
US9710199B2 (en) 2014-11-07 2017-07-18 International Business Machines Corporation Non-volatile memory data storage with low read amplification
US9590948B2 (en) 2014-12-15 2017-03-07 Cisco Systems, Inc. CCN routing using hardware-assisted hash tables
US10237189B2 (en) 2014-12-16 2019-03-19 Cisco Technology, Inc. System and method for distance-based interest forwarding
US10003520B2 (en) 2014-12-22 2018-06-19 Cisco Technology, Inc. System and method for efficient name-based content routing using link-state information in information-centric networks
US10162700B2 (en) 2014-12-23 2018-12-25 International Business Machines Corporation Workload-adaptive data packing algorithm
US9660825B2 (en) 2014-12-24 2017-05-23 Cisco Technology, Inc. System and method for multi-source multicasting in content-centric networks
US9832291B2 (en) 2015-01-12 2017-11-28 Cisco Technology, Inc. Auto-configurable transport stack
US9916457B2 (en) 2015-01-12 2018-03-13 Cisco Technology, Inc. Decoupled name security binding for CCN objects
US9946743B2 (en) 2015-01-12 2018-04-17 Cisco Technology, Inc. Order encoded manifests in a content centric network
US9954795B2 (en) 2015-01-12 2018-04-24 Cisco Technology, Inc. Resource allocation using CCN manifests
US10333840B2 (en) 2015-02-06 2019-06-25 Cisco Technology, Inc. System and method for on-demand content exchange with adaptive naming in information-centric networks
US10075401B2 (en) 2015-03-18 2018-09-11 Cisco Technology, Inc. Pending interest table behavior
US10560543B2 (en) * 2015-03-26 2020-02-11 Fortinet, Inc. Rule based cache processing in application delivery controller for load balancing
US10075402B2 (en) 2015-06-24 2018-09-11 Cisco Technology, Inc. Flexible command and control in content centric networks
US9612754B1 (en) * 2015-06-29 2017-04-04 EMC IP Holding Company LLC Data storage system with window allocation using window cache
US9916735B2 (en) 2015-07-22 2018-03-13 Igt Remote gaming cash voucher printing system
US10701038B2 (en) 2015-07-27 2020-06-30 Cisco Technology, Inc. Content negotiation in a content centric network
US9986034B2 (en) 2015-08-03 2018-05-29 Cisco Technology, Inc. Transferring state in content centric network stacks
US10055930B2 (en) 2015-08-11 2018-08-21 Igt Gaming system and method for placing and redeeming sports bets
US9832123B2 (en) 2015-09-11 2017-11-28 Cisco Technology, Inc. Network named fragments in a content centric network
US10355999B2 (en) 2015-09-23 2019-07-16 Cisco Technology, Inc. Flow control with network named fragments
US10313227B2 (en) 2015-09-24 2019-06-04 Cisco Technology, Inc. System and method for eliminating undetected interest looping in information-centric networks
US9712190B2 (en) 2015-09-24 2017-07-18 International Business Machines Corporation Data packing for compression-enabled storage systems
US9977809B2 (en) 2015-09-24 2018-05-22 Cisco Technology, Inc. Information and data framework in a content centric network
US10440140B2 (en) * 2015-09-29 2019-10-08 Apple Inc. Browser cache management
US10454820B2 (en) 2015-09-29 2019-10-22 Cisco Technology, Inc. System and method for stateless information-centric networking
US10263965B2 (en) 2015-10-16 2019-04-16 Cisco Technology, Inc. Encrypted CCNx
US9870285B2 (en) 2015-11-18 2018-01-16 International Business Machines Corporation Selectively de-straddling data pages in non-volatile memory
US9912776B2 (en) 2015-12-02 2018-03-06 Cisco Technology, Inc. Explicit content deletion commands in a content centric network
US10097346B2 (en) 2015-12-09 2018-10-09 Cisco Technology, Inc. Key catalogs in a content centric network
US10257271B2 (en) 2016-01-11 2019-04-09 Cisco Technology, Inc. Chandra-Toueg consensus in a content centric network
US10305864B2 (en) 2016-01-25 2019-05-28 Cisco Technology, Inc. Method and system for interest encryption in a content centric network
US10043016B2 (en) 2016-02-29 2018-08-07 Cisco Technology, Inc. Method and system for name encryption agreement in a content centric network
JP6638472B2 (ja) 2016-02-29 2020-01-29 富士通株式会社 中継装置及び中継システム
US10742596B2 (en) 2016-03-04 2020-08-11 Cisco Technology, Inc. Method and system for reducing a collision probability of hash-based names using a publisher identifier
US10051071B2 (en) 2016-03-04 2018-08-14 Cisco Technology, Inc. Method and system for collecting historical network information in a content centric network
US10003507B2 (en) 2016-03-04 2018-06-19 Cisco Technology, Inc. Transport session state protocol
US10264099B2 (en) 2016-03-07 2019-04-16 Cisco Technology, Inc. Method and system for content closures in a content centric network
US10067948B2 (en) 2016-03-18 2018-09-04 Cisco Technology, Inc. Data deduping in content centric networking manifests
US10091330B2 (en) 2016-03-23 2018-10-02 Cisco Technology, Inc. Interest scheduling by an information and data framework in a content centric network
US10320760B2 (en) 2016-04-01 2019-06-11 Cisco Technology, Inc. Method and system for mutating and caching content in a content centric network
US9930146B2 (en) 2016-04-04 2018-03-27 Cisco Technology, Inc. System and method for compressing content centric networking messages
US10425503B2 (en) 2016-04-07 2019-09-24 Cisco Technology, Inc. Shared pending interest table in a content centric network
US10063414B2 (en) 2016-05-13 2018-08-28 Cisco Technology, Inc. Updating a transport stack in a content centric network
US10084764B2 (en) 2016-05-13 2018-09-25 Cisco Technology, Inc. System for a secure encryption proxy in a content centric network
US10103989B2 (en) 2016-06-13 2018-10-16 Cisco Technology, Inc. Content object return messages in a content centric network
US10305865B2 (en) 2016-06-21 2019-05-28 Cisco Technology, Inc. Permutation-based content encryption with manifests in a content centric network
US10148572B2 (en) 2016-06-27 2018-12-04 Cisco Technology, Inc. Method and system for interest groups in a content centric network
US10089025B1 (en) 2016-06-29 2018-10-02 EMC IP Holding Company LLC Bloom filters in a flash memory
US10055351B1 (en) * 2016-06-29 2018-08-21 EMC IP Holding Company LLC Low-overhead index for a flash cache
US10331561B1 (en) 2016-06-29 2019-06-25 Emc Corporation Systems and methods for rebuilding a cache index
US10146438B1 (en) 2016-06-29 2018-12-04 EMC IP Holding Company LLC Additive library for data structures in a flash memory
US10261704B1 (en) 2016-06-29 2019-04-16 EMC IP Holding Company LLC Linked lists in flash memory
US10037164B1 (en) 2016-06-29 2018-07-31 EMC IP Holding Company LLC Flash interface for processing datasets
US10009266B2 (en) 2016-07-05 2018-06-26 Cisco Technology, Inc. Method and system for reference counted pending interest tables in a content centric network
US9992097B2 (en) 2016-07-11 2018-06-05 Cisco Technology, Inc. System and method for piggybacking routing information in interests in a content centric network
US9886449B1 (en) * 2016-07-22 2018-02-06 Red Hat, Inc. Delayed allocation for data object creation
US9588976B1 (en) * 2016-07-22 2017-03-07 Red Hat, Inc. Delayed allocation for a direct access non-volatile file system
US10122624B2 (en) 2016-07-25 2018-11-06 Cisco Technology, Inc. System and method for ephemeral entries in a forwarding information base in a content centric network
US10069729B2 (en) 2016-08-08 2018-09-04 Cisco Technology, Inc. System and method for throttling traffic based on a forwarding information base in a content centric network
US10956412B2 (en) 2016-08-09 2021-03-23 Cisco Technology, Inc. Method and system for conjunctive normal form attribute matching in a content centric network
US10033642B2 (en) 2016-09-19 2018-07-24 Cisco Technology, Inc. System and method for making optimal routing decisions based on device-specific parameters in a content centric network
US10212248B2 (en) 2016-10-03 2019-02-19 Cisco Technology, Inc. Cache management on high availability routers in a content centric network
US10447805B2 (en) 2016-10-10 2019-10-15 Cisco Technology, Inc. Distributed consensus in a content centric network
US10135948B2 (en) 2016-10-31 2018-11-20 Cisco Technology, Inc. System and method for process migration in a content centric network
US10243851B2 (en) 2016-11-21 2019-03-26 Cisco Technology, Inc. System and method for forwarder connection information in a content centric network
US10289315B2 (en) 2017-03-27 2019-05-14 Western Digital Technologies, Inc. Managing I/O operations of large data objects in a cache memory device by dividing into chunks
US20180336128A1 (en) * 2017-05-22 2018-11-22 Ge Aviation Systems, Llc Methods, systems, and apparatus for safe memory object access in memory management mechanisms
US10366011B1 (en) 2018-05-03 2019-07-30 EMC IP Holding Company LLC Content-based deduplicated storage having multilevel data cache
US10705753B2 (en) * 2018-05-04 2020-07-07 EMC IP Holding Company LLC Fan-out asynchronous replication logical level caching
US10860239B2 (en) 2018-05-04 2020-12-08 EMC IP Holding Company LLC Fan-out asynchronous replication caching
US10776269B2 (en) * 2018-07-24 2020-09-15 International Business Machines Corporation Two level compute memoing for large scale entity resolution
CN109033439B (zh) * 2018-08-15 2019-11-19 中科驭数（北京）科技有限公司 流式数据的处理方法和装置
CN110929186B (zh) * 2018-08-29 2022-05-10 武汉斗鱼网络科技有限公司 一种客户端及信息显示方法、电子设备、介质
US11556470B2 (en) 2021-02-02 2023-01-17 Kinaxis Inc. Cache management for search optimization
US11775433B2 (en) 2019-02-01 2023-10-03 Kinaxis Inc. Cache management for search optimization
US10936501B2 (en) * 2019-02-01 2021-03-02 Kinaxis Inc. Cache management for search optimization
US11899620B2 (en) 2019-03-08 2024-02-13 Netapp, Inc. Metadata attachment to storage objects within object store
US11144498B2 (en) * 2019-03-08 2021-10-12 Netapp Inc. Defragmentation for objects within object store
US11016943B2 (en) 2019-03-08 2021-05-25 Netapp, Inc. Garbage collection for objects within object store
CN111930708B (zh) * 2020-07-14 2023-07-11 上海德拓信息技术股份有限公司 基于Ceph对象存储的对象标签的扩展系统及方法
US11582025B2 (en) 2020-09-29 2023-02-14 Amazon Technologies, Inc. Efficient deduplication using block-based convergent encryption
US11329803B2 (en) 2020-09-29 2022-05-10 Amazon Technologies, Inc. Redundancy controls in convergent encryption using dynamic salt values
US11341137B1 (en) * 2020-12-04 2022-05-24 Amadeus S.A.S. Processing search requests
US11954022B2 (en) * 2022-03-02 2024-04-09 International Business Machines Corporation Throttling host writes in a host buffer to a storage device
CN116467354B (zh) * 2023-06-15 2023-09-12 本原数据(北京)信息技术有限公司 数据库的查询方法和装置、计算机设备、存储介质

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58177383A (ja) * 1982-04-12 1983-10-18 Hitachi Ltd エンドレスカウント方法およびその装置
US4918646A (en) 1986-08-28 1990-04-17 Kabushiki Kaisha Toshiba Information retrieval apparatus
US4841433A (en) 1986-11-26 1989-06-20 American Telephone And Telegraph Company, At&T Bell Laboratories Method and apparatus for accessing data from data attribute tables
US4853843A (en) 1987-12-18 1989-08-01 Tektronix, Inc. System for merging virtual partitions of a distributed database
US5611049A (en) * 1992-06-03 1997-03-11 Pitts; William M. System for accessing distributed data cache channel at each network node to pass requests and data
US5381539A (en) * 1992-06-04 1995-01-10 Emc Corporation System and method for dynamically controlling cache management
US5649200A (en) 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system
US5664106A (en) * 1993-06-04 1997-09-02 Digital Equipment Corporation Phase-space surface representation of server computer performance in a computer network
US5542087A (en) * 1993-10-15 1996-07-30 Hewlett-Packard Company Linear hashing for distributed records
US5586264A (en) 1994-09-08 1996-12-17 Ibm Corporation Video optimized media streamer with cache management
US6029195A (en) 1994-11-29 2000-02-22 Herz; Frederick S. M. System for customized electronic identification of desirable objects
EP0826181A4 (de) 1995-04-11 2005-02-09 Kinetech Inc Identifizierung von daten in einem datenverarbeitungssystem
US5805809A (en) * 1995-04-26 1998-09-08 Shiva Corporation Installable performance accelerator for maintaining a local cache storing data residing on a server computer
US5748954A (en) * 1995-06-05 1998-05-05 Carnegie Mellon University Method for searching a queued and ranked constructed catalog of files stored on a network
JP2770786B2 (ja) * 1995-06-05 1998-07-02 日本電気株式会社 構造化データの多重ａｔｍ／ｓｔｍ変換装置
US5872969A (en) * 1995-06-23 1999-02-16 International Business Machines Corporation System and method for efficiently synchronizing cache and persistent data in an object oriented transaction processing system
US5956342A (en) * 1995-07-19 1999-09-21 Fujitsu Network Communications, Inc. Priority arbitration for point-to-point and multipoint transmission
US5732267A (en) * 1995-08-02 1998-03-24 Microsoft Corporation Caching/prewarming data loaded from CD-ROM
US5751993A (en) * 1995-09-05 1998-05-12 Emc Corporation Cache management system
US5592432A (en) * 1995-09-05 1997-01-07 Emc Corp Cache management system using time stamping for replacement queue
US5774670A (en) * 1995-10-06 1998-06-30 Netscape Communications Corporation Persistent client state in a hypertext transfer protocol based client-server system
US5701432A (en) * 1995-10-13 1997-12-23 Sun Microsystems, Inc. Multi-threaded processing system having a cache that is commonly accessible to each thread
US5774643A (en) 1995-10-13 1998-06-30 Digital Equipment Corporation Enhanced raid write hole protection and recovery
US5727159A (en) * 1996-04-10 1998-03-10 Kikinis; Dan System in which a Proxy-Server translates information received from the Internet into a form/format readily usable by low power portable computers
US5864852A (en) * 1996-04-26 1999-01-26 Netscape Communications Corporation Proxy server caching mechanism that provides a file directory structure and a mapping mechanism within the file directory structure
US5935207A (en) * 1996-06-03 1999-08-10 Webtv Networks, Inc. Method and apparatus for providing remote site administrators with user hits on mirrored web sites
US5918013A (en) * 1996-06-03 1999-06-29 Webtv Networks, Inc. Method of transcoding documents in a network environment using a proxy server
US6134583A (en) * 1996-07-01 2000-10-17 Sun Microsystems, Inc. Method, system, apparatus and article of manufacture for providing identity-based caching services to a plurality of computer systems (#16)
US5850443A (en) 1996-08-15 1998-12-15 Entrust Technologies, Ltd. Key management system for mixed-trust environments
US5852717A (en) * 1996-11-20 1998-12-22 Shiva Corporation Performance optimizations for computer networks utilizing HTTP
US5909540A (en) 1996-11-22 1999-06-01 Mangosoft Corporation System and method for providing highly available data storage using globally addressable memory
US5974421A (en) * 1996-12-23 1999-10-26 Microsoft Corporation Cache-efficient object loader
US5895488A (en) * 1997-02-24 1999-04-20 Eccs, Inc. Cache flushing methods and apparatus
US5870763A (en) * 1997-03-10 1999-02-09 Microsoft Corporation Database computer system with application recovery and dependency handling read cache
US5924116A (en) * 1997-04-02 1999-07-13 International Business Machines Corporation Collaborative caching of a requested object by a lower level node as a function of the caching status of the object at a higher level node
US6049810A (en) 1997-04-23 2000-04-11 Sun Microsystems, Inc. Method and apparatus for implementing a write barrier of a garbage collected heap
US6038572A (en) 1997-04-23 2000-03-14 Sun Microsystems, Inc. Method and apparatus for localizing nodes in a garbage collected carded heap
US5920876A (en) 1997-04-23 1999-07-06 Sun Microsystems, Inc. Performing exact garbage collection using bitmaps that identify pointer values within objects
US6115782A (en) 1997-04-23 2000-09-05 Sun Micosystems, Inc. Method and apparatus for locating nodes in a carded heap using a card marking structure and a node advance value
US5915255A (en) 1997-04-23 1999-06-22 Sun Microsystems, Inc. Method and apparatus for referencing nodes using links
US6078994A (en) * 1997-05-30 2000-06-20 Oracle Corporation System for maintaining a shared cache in a multi-threaded computer environment
US6026413A (en) 1997-08-01 2000-02-15 International Business Machines Corporation Determining how changes to underlying data affect cached objects
US6000006A (en) * 1997-08-25 1999-12-07 Bit Microsystems, Inc. Unified re-map and cache-index table with dual write-counters for wear-leveling of non-volatile flash RAM mass storage
US5950205A (en) * 1997-09-25 1999-09-07 Cisco Technology, Inc. Data transmission over the internet using a cache memory file system
US5987233A (en) * 1998-03-16 1999-11-16 Skycache Inc. Comprehensive global information network broadcasting system and implementation thereof
US6154769A (en) * 1998-03-27 2000-11-28 Hewlett-Packard Company Scheduling server requests to decrease response time and increase server throughput
US6128623A (en) * 1998-04-15 2000-10-03 Inktomi Corporation High performance object cache

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016103882A1 (de) * 2016-03-03 2017-09-07 Cadami Ug (Haftungsbeschränkt) Zuordnungsverfahren sowie Netzwerk mit einer Zuordnungsvorrichtung
DE102016108018A1 (de) * 2016-03-03 2017-09-07 Cadami Ug (Haftungsbeschränkt) Kennungscodierungseinrichtung und Kennungsdecodierungseinrichtung zur Datenverteilung in Netzwerken sowie derartige Einrichtungen aufweisende Netzwerkelemente

Also Published As

Publication number Publication date
WO1999053422A1 (en) 1999-10-21
US6453319B1 (en) 2002-09-17
EP1072004B1 (de) 2004-03-10
AU3747599A (en) 1999-11-01
AU754816B2 (en) 2002-11-28
JP4489292B2 (ja) 2010-06-23
JP2002511616A (ja) 2002-04-16
US6128623A (en) 2000-10-03
DE69915462D1 (de) 2004-04-15
EP1072004A1 (de) 2001-01-31

Similar Documents

Publication Publication Date Title
DE69915462T2 (de) Sehr leistungsstarker objektcache
US6289358B1 (en) Delivering alternate versions of objects from an object cache
US7805416B1 (en) File system query and method of use
US6292880B1 (en) Alias-free content-indexed object cache
US6209003B1 (en) Garbage collection in an object cache
JP7410181B2 (ja) ハイブリッド・インデックス作成方法、システム、プログラム
US6128627A (en) Consistent data storage in an object cache
US7783615B1 (en) Apparatus and method for building a file system index
US6915307B1 (en) High performance object cache
US6625604B2 (en) Namespace service in a distributed file system using a database management system
US6638314B1 (en) Method of web crawling utilizing crawl numbers
US8135763B1 (en) Apparatus and method for maintaining a file system index
US6952730B1 (en) System and method for efficient filtering of data set addresses in a web crawler
US7805568B2 (en) Method and apparatus for data storage using striping specification identification
DE60126798T2 (de) Verfahren zum durchsuchen und analysieren von informationen in datennetzen
US5920857A (en) Efficient optimistic concurrency control and lazy queries for B-trees and other database structures
US7328401B2 (en) Adaptive web crawling using a statistical model
EP1643388A1 (de) System und Verfahren zum inkrementellen Indizieren von Netzwerkdokumenten mit Hilfe von Batch-transfers
US7415467B2 (en) Database replication system
US20200364185A1 (en) Method for data replication in a data analysis system
WO2004025428A2 (en) Apparatus and method for processing data in a network
DE602004013397T2 (de) Verfahren und Apparat zum Verschieben von Daten zwischen Speichersystemen
DE112019005881T5 (de) Kryptografische überprüfung von datenbanktransaktionen
CN110287201A (zh) 数据访问方法、装置、设备及存储介质
US7895247B2 (en) Tracking space usage in a database

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: YAHOO| INC. (N.D.GES.D. STAATES DELAWARE), SUN, US