DE60317403T2 - Mehrstufige Cache-Speicherarchitektur und Cache-Speicherverwaltungsverfahren für gleichrangiges Namensauflösungs-Protokoll - Google Patents

Mehrstufige Cache-Speicherarchitektur und Cache-Speicherverwaltungsverfahren für gleichrangiges Namensauflösungs-Protokoll Download PDF

Info

Publication number
DE60317403T2
DE60317403T2 DE60317403T DE60317403T DE60317403T2 DE 60317403 T2 DE60317403 T2 DE 60317403T2 DE 60317403 T DE60317403 T DE 60317403T DE 60317403 T DE60317403 T DE 60317403T DE 60317403 T2 DE60317403 T2 DE 60317403T2
Authority
DE
Germany
Prior art keywords
peer
segment
cache
ids
instantiated
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
DE60317403T
Other languages
English (en)
Other versions
DE60317403D1 (de
Inventor
John L. Bellevue Miller
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.)
Microsoft Corp
Original Assignee
Microsoft 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 Microsoft Corp filed Critical Microsoft Corp
Publication of DE60317403D1 publication Critical patent/DE60317403D1/de
Application granted granted Critical
Publication of DE60317403T2 publication Critical patent/DE60317403T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/58Caching of addresses or names
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • GEBIET DER ERFINDUNG
  • Diese Erfindung betrifft Cache-Speicher-Datenstrukturen und Speicherverwaltungsverfahren im Allgemeinen und im Besonderen Cache-Speicherarchitekturen und Verfahren zum Speichern und Sortieren von Peer-to-Peer(P2P)-Namensauflösungsinformationen.
  • HINTERGRUND DER ERFINDUNG
  • Peer-to-Peer(P2P)-Netzwerke waren die Grundlage des Internets und erfahren derzeit einen Aufschwung ihrer Popularität und Verwendung. Die Abkehr von den neuesten, serverzentriert betriebenen Netzwerken macht es jedoch erforderlich, dass jeder einzelne Peer Kontakt- und Standortinformationen für die anderen Peers und für feststellbare, im Netzwerk verfügbare Ressourcen erwirbt und vorhält. Es gibt zwar einige Hybrid-P2P-Systeme, die einen Server verwenden, der als Index oder zentrale Adress-Hinterlegungsstelle (address depository) verfügbarer Peers und/oder Ressourcen dient, echte P2P-Systeme nutzen jedoch keine derartigen Server. Somit und durch die ungeheure Anzahl von Peers und feststellbaren Ressourcen, die in einem großen P2P-Netzwerk verfügbar sind, wird die interne Verwaltung der gespeicherten Kontakt- und Verzeichnisinformationen innerhalb jedes Peers zu einer Aufgabe von größter Wichtigkeit. Ohne ein solches Verwaltungssystem kann der eigene Speicher des Peers durch die Kontakt- und Verzeichnisinformationen aufgebraucht werden.
  • Viele verteilte Auflösungsmechanismen für P2P-Netzwerke werden um eine strukturierte Kenntnis des Namensraumes herum aufgebaut, in dem die Peer- und Ressourcenauflösung durchgeführt wird. Das Namensraum-Wissen, das entwickelt und vorgehalten wird, ist üblicherweise um jeden Namen strukturiert, der lokal in dem Namensraum registriert ist. Das heißt, Informationen über andere Peers innerhalb einer bestimmten Entfernung von dem registrierten Namen werden in der Wissensdatenbank für jeden registrierten Namen vorgehalten. Wenn zwei oder mehrere Namen lokal registriert werden, kann es zwischen den Wissensdatenbanken, die für jeden Namen vorgehalten werden, zu einer signifikanten Überlappung kommen, insbesondere dann, wenn die Namen in großer Nähe zueinander registriert sind. Diese redundante Kenntnis verbraucht zusätzliche Ressourcen an jedem Knoten (node) und im Netzwerk. In Anbetracht der Tatsache, dass ein typischer Peer mehrere, mögli cherweise hunderte, Namen registriert hat (um jeder verfügbaren, feststellbaren Ressource, Datei, Anwendung, jedem Dienst und dergleichen Rechnung zu tragen, die an diesem Peer verfügbar sind), wird die sich daraus ergebende Redundanz in Wissensdatenbanken untragbar. in einigen Fällen können auf Grund der Duplizierung dieser Informationen in den überlappenden Wissensdatenbanken die auf einem einzigen Host gespeicherten Informationen die Anzahl aktiver Informationen in dem gesamten Namensraum überschreiten.
  • Das Dokument EP 1 248 441 A2 , das am 09.10.2008 veröffentlicht wurde, offenbart ein Peer-to-Peer-Namensauflösungsprotokoll und einen Mehrebenen(multilevel)-Cache zur Verwendung damit.
  • Stoica et al., „MIT-LCS-TR-819-Choral: A scalable Peer-to-peer lookup service for Internet applications", MIT Technical Report, 23.03.2001, offenbart einen dezentralisierten Nachschlagedienst (lookup service), der Paare aus Schlüssel und Wert für verteilte Netzwerke speichert.
  • Somit besteht also ein Bedarf nach einer Speicherstruktur und einem Informationsvorhaltungssystem, das eine effiziente P2P-Namensauflösung durch den Erwerb und das Vorhalten einer Wissensdatenbank für registrierte Namen in dem P2P-Namensraum ermöglicht und das nicht übermäßig viele Peer-Ressourcen durch das Duplizieren von Informationen über Namens-/Ressourcenregistrierungen verbraucht.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Unter Berücksichtigung des oben Genannten ist es eine Aufgaben der vorliegenden Erfindung, eine neue und verbesserte Cache-Speicherstruktur sowie ein Informationsverwaltungssystem bereitzustellen, das eine effiziente Namensauflösung in einer Peer-to-Peer-„Wolke" (cloud) ermöglicht und auch und selbst dann nicht exzessiv Ressourcen verbraucht, wenn mehrere Ressourcen und/oder Dienste an dem Peer registriert sind.
  • Die Architektur eines segmentierten Caches einer Ausführungsform der vorliegenden Erfindung speichert PNRP-IDs in unterschiedlichen Segmenten entsprechend der Anzahl der gespeicherten PNRP-IDs und ihrer relativen Entfernung in dem PNRP-Namensraum. Der vorliegenden Erfindung liegt die statistische Annahme zugrunde, dass die Wahrscheinlichkeit, eine bestimmte PNRP-ID zu kennen, zu der Entfernung dieser ID von der lokal registrierten PNRP-ID umgekehrt proportional ist. Durch das Speichern von PNRP-IDs in Übereinstim mung mit dem System und dem Verfahren der vorliegenden Erfindung wird das Speichern doppelter Informationen in unterschiedlichen Caches verringert und die für die Namensauflösung erforderliche Anzahl von Sprüngen kann verringert werden.
  • Wenn mit der statistischen Annahme fortgesetzt wird, dass die Peers in dem Namensraum näherungsweise gleichmäßig über den Namensraum verteilt sind, und wenn die Anzahl instanziierter IDs bekannt ist, kann der durchschnittliche Abstand zwischen Peers bestimmt werden. Auf der Basis dieser Informationen können die Cache-Regionen oder -Ebenen in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung auf Basis dieses durchschnittlichen Abstandes zwischen Peers in Bezug auf jede lokal registrierte PNRP-ID bestimmt werden. Eine erste oder unterste Cache-Region oder -Ebene enthält PNRP-IDs mit einer Granularität der durchschnittlichen Entfernung und überspannt den Bereich von ungefähr der zehnfachen durchschnittlichen Entfernung von der lokal registrierten ID. Die nächste Cache-Region besitzt PNRP-IDs mit einer Granularität von einem Vielfachen der durchschnittlichen Entfernung und überspannt den Bereich von ungefähr der einhundertfachen durchschnittlichen Entfernung von der lokal registrierten ID, schließt jedoch die erste Region aus. Dieser Anstieg der Größenordnung der Granularität und des Bereiches erhöht sich bis zu der N-ten Cache-Region. Diese N-te Cache-Region besitzt PNRP-IDs mit einer Granularität des 10N-1-fachen der durchschnittlichen Entfernung und überspannt den Bereich von ungefähr der 10N-fachen durchschnittlichen Entfernung von der lokal registrierten ID, schließt jedoch die vorangehenden N – 1 Regionen aus. Die Anzahl N der erforderlichen Cache-Ebenen ist näherungsweise gleich log(Anzahl instanziierter IDs).
  • In einer großen Peer-to-Peer-Wolke ist die Anzahl instanziierter PNRP-IDs möglicherweise auf Grund der dynamischen Natur der Peers selbst nicht bekannt oder es ist unmöglich, sie zu kennen. Daher wird in einer alternativen Ausführungsform der vorliegenden Erfindung eine Cachesegment-Teilungsrichtlinie (cache segment splitting policy) implementiert. In dieser Ausführungsform wird die höchste Cache-Region so aufgebaut, dass sie den gesamten Namensraum abdeckt und zwanzig PNRP-IDs enthält. Wenn diese höchste Region gefüllt ist, führt der Empfang eines anderen Peer-Adresszertifikates(peer address certificate – PAC) dazu, dass eine Cache-Region einer niedrigeren Ebene instanziiert wird. Diese Region deckt zehn Prozent der nächsthöheren Region ab, die an der lokal registrierten ID zentriert ist. Alle Informationen aus der höheren Cache-Region innerhalb dieses Bereiches werden in diese niedrigere Cache-Region migriert, um eine Duplizierung von Informationen zu eliminieren. Sobald diese neue Region mit zwanzig Einträgen gefüllt ist, bewirkt der Empfang eines weiteren PAC, das in diese Region passt, die Instanziierung einer niedrigeren Cache-Region als zehn Prozent dieser neu gefüllten Region. Alle Informationen aus der höheren Cache-Region innerhalb dieses Bereiches werden in diese niedrigere Cache-Region migriert, um eine Duplizierung von Informationen zu eliminieren. Dieser Prozess wird jedes Mal durchgeführt, wenn die Cache-Region der untersten Ebene voll wird und ein anderes PAC empfangen wird, das in diese Region passt. Wenn jedoch PACs empfangen werden, die in Cache-Regionen der oberen Ebenen gehören, muss ein im Cache gespeichertes PAC aus dieser Region gelöscht werden, ehe das neue PAC hinzugefügt werden kann.
  • Unter Anerkennung der Tatsache, dass viele Peers mehrere Ressourcen und Dienste besitzen, die in der P2P-Wolke feststellbar sind, unterstützen die Cache-Architektur und das Verfahren einer Ausführungsform der vorliegenden Erfindung mehrere lokal registrierte PNRP-IDs, ohne dass Informationen in dem Cache verdoppelt werden. Dies wird gemäß einer Ausführungsform erreicht, indem überlappende Cache-Segmente innerhalb einer Region kombiniert werden, da sie alle innerhalb dieser speziellen Cache-Region dieselbe Granularität besitzen. Diese Kombination beeinträchtigt nicht die Instanziierung von Cache-Regionen unterer Ebenen, in denen keine Überlappung auftritt.
  • Eine Ausführungsform der vorliegenden Erfindung verwendet einen PAC-Cache-Baum, einen Baum instanziierter Segmente sowie einen Baum uninstanziierter Segmente. Der Cache-Baum ist eine Sammlung von PACs, die nach ihrer PNRP-ID sortiert und in einem Binärbaum organisiert sind wie beispielsweise einem Rot-Schwarz-Baum in einer Ausführungsform, um das Einfügen, Lokalisieren und Löschen von PACs zu vereinfachen. Der Baum instanziierter Segmente ist eine Sammlung von Zeigern, die die Startadresse von jedem instanziierten Segment in der Cache-Architektur anzeigen. Dieser Baum instanziierter Segmente ist ebenfalls vorzugsweise als ein Rot-Schwarz-Baum organisiert, um die Suche nach dem geeigneten Cache-Segment zu vereinfachen, in das ein neu empfangenes PAC hineingehört. Der Baum uninstanziierter Segmente enthält die nächsten Cache-Segmente, die zu instanziieren sind, wenn das nächsthöhere Cache-Segment, das sie jeweils überlappen, voll wird. In einer Ausführungsform werden nur die Cache-Segmente in den Baum uninstanziierter Segmente eingeschlossen, die sich in der nächsten unmittelbaren Cache-Region befinden.
  • Zusätzliche Eigenschaften und Vorteile der Erfindung werden aus der folgenden ausführlichen Beschreibung veranschaulichender Ausführungsformen ersichtlich, die jeweils in Bezug auf die begleitende Figur abläuft.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Während die beigefügten Ansprüche die Eigenschaften der vorliegenden Erfindung in ihren wesentlichen Grundzügen darstellt, ist die Erfindung zusammen mit ihren Aufgaben und Vorteilen am besten aus der folgenden ausführlichen Beschreibung ersichtlich, die im Zusammenhang mit den beigefügten Zeichnungen zu betrachten ist, in denen:
  • 1 ein Blockdiagramm ist, das ein beispielhaftes Computersystem allgemein darstellt, in dem sich die vorliegende Erfindung befindet;
  • 2 ist ein Liniendiagramm des Peer-to-Peer-Zahlenraums, das das Konzept der Entfernung zwischen Peers modulo ID_MAX darstellt;
  • 3 ist eine grafische Darstellung von Cache-Regionen und -Segmenten, die in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung in Bezug auf eine lokal registrierte PNRP-ID in einem vereinfachten Peer-to-Peer-Zahlenraum instanziiert sind;
  • die 4A bis 4D sind grafische Darstellungen der schrittweisen Instanziierung von Cache-Regionen und -Segmenten in Übereinstimmung mit einer Segmentteilungs-Richtlinie einer Ausführungsform der vorliegenden Erfindung, wobei in einem vereinfachten Peer-to-Peer-Zahlenraum zusätzliche Peer-Adresszertifikate (peer address certificates – PACs) in Bezug auf eine einzige, lokal registrierte PNRP-ID empfangen werden;
  • die 5A bis 5D sind grafische Darstellungen der schrittweisen Instanziierung von Cache-Regionen und -Segmenten in Übereinstimmung mit einer Segmentteilungs-Richtlinie einer Ausführungsform der vorliegenden Erfindung, wobei in einem vereinfachten Peer-to-Peer-Zahlenraum zusätzliche Peer-Adresszertifikate (PACs) in Bezug auf mehrere, lokal registrierte PNRP-IDs empfangen werden, sowie des Abtretens von Cache-Regionen und -Segmenten beim Entfernen einer lokal registrierten PNRP-ID; und
  • 6 ist eine grafische Darstellung einer Beziehung zwischen einem PAC-Segment-Baum, einem Baum instanziierter Segmente sowie einem Baum uninstanziierter Segmente in einer Stufe der in 5B in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung dargestellten, schrittweisen Instanziierung.
  • AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
  • In Bezug auf die Zeichnungen, in denen gleiche Referenznummern auf gleiche Elemente verweisen, wird die Erfindung als in einer geeigneten Computerumgebung implementiert dargestellt. Es ist zwar nicht erforderlich, trotzdem wird die Erfindung in dem allgemeinen Kontext von durch einen Computer ausführbaren Befehlen wie beispielsweise Programmmodulen, die durch einen Personalcomputer ausgeführt werden, dargestellt. Im Allgemeinen enthalten Programmmodule Hilfsprogramme (Routinen), Programme, Objekte, Komponenten, Datenstrukturen und dergleichen, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Darüber hinaus ist es für Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik ersichtlich, dass die Erfindung auch mit anderen Konfigurationen eines Computersystems durchgeführt werden kann, dies schließt mobile Handcomputer(Handheld)-Vorrichtungen, Mehrprozessorsysteme, auf Mikroprozessoren basierende oder programmierbare Unterhaltungs- und Haushaltselektronik, Netzwerk-PCs, Minicomputer, Großrechner und dergleichen ein. Die Erfindung kann darüber hinaus auch in verteilten Computerumgebungen praktiziert werden, wobei Aufgaben durch entfernte Verarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetzwerk miteinander verbunden sind. In einer verteilten Computerumgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernten Computerspeichermedien befinden.
  • In 1 wird ein Beispiel einer geeigneten Computersystemumgebung 100 dargestellt, in der die Erfindung implementiert werden kann. Die Computersystemumgebung 100 ist nur ein Beispiel für eine geeignete Computerumgebung und ist nicht dafür vorgesehen, irgendeine Beschränkung hinsichtlich des Verwendungsumfanges oder der Funktionalität der Erfindung nahe zu legen. Des Weiteren umfasst die Computerumgebung 100 auch keinerlei Abhängigkeit oder Anforderung hinsichtlich einer beliebigen Komponente oder einer Kombination von Komponenten, die in der beispielhaften Betriebsumgebung 100 gezeigt werden.
  • Die Erfindung ist mit zahlreichen anderen Computersystemumgebungen oder -Konfigurationen für allgemeine oder für spezielle Anwendungen einsetzbar. Beispiele für allseits bekannte Computersysteme, Computerumgebungen und/oder Computerkonfigurationen, die zum Verwenden mit der Erfindung geeignet sein können, umfassen Personalcomputer, Servercomputer, mobile Handcomputer-(Handheld) oder Notebook-Vorrichtungen, Mehrprozessorsysteme, auf Mikroprozessoren basierende Systeme, Set-Top-Boxen, programmierbare Unterhaltungs- und Haushaltselektronik, Netzwerk-PCs, Minicomputer, Großrechner, verteilte Computerumgebungen, die irgendeines der oben aufgeführten Systeme oder Vorrichtungen enthalten, und dergleichen, sind jedoch nicht auf diese begrenzt.
  • Die Erfindung wird in dem allgemeinen Kontext von durch einen Computer ausführbaren Befehlen wie beispielsweise Programmmodulen, die durch einen Computer ausgeführt werden, dargestellt. Im Allgemeinen enthalten Programmmodule Hilfsprogramme (Routinen), Programme, Objekte, Komponenten, Datenstrukturen und dergleichen, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datentypen implementieren. Die Erfindung kann darüber hinaus auch in verteilten Computerumgebungen praktiziert werden, wobei Aufgaben durch entfernte Verarbeitungsvorrichtungen durchgeführt werden, die über ein Kommunikationsnetzwerk miteinander verbunden sind. In einer verteilten Computerumgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernten Computerspeichermedien einschließlich Hauptspeichervorrichtungen (memory storage devices) befinden.
  • In Bezug auf 1 umfasst ein beispielhaftes System zum Implementieren der Erfindung eine für alle Zwecke geeignete Computervorrichtung in der Form eines Computers 110. Die Komponenten des Computers 110 können folgende Komponenten enthalten, sind jedoch nicht auf diese begrenzt, eine Verarbeitungseinheit (Prozessor) 120, einen Systemspeicher 130 sowie einen Systembus 121, der verschiedene Systemkomponenten einschließlich des Systemspeichers mit der Verarbeitungseinheit 120 verbindet. Der Systembus 121 kann ein beliebiger aus mehreren Arten von Busstrukturen einschließlich eines Speicherbus oder einer Speichersteuerung (memory controller), eines Peripheriebus sowie eines lokalen Bus sein, die jeweils jede beliebige einer Vielfalt von Busarchitekturen nutzen. Beispielhaft und nicht einschränkend umfassen derartige Architekturen den Industry Standard Architecture(ISA)-Bus, den Micro Channel Architecture(MCA)-Bus, den Enhanced ISA(EISA)-Bus, den Video Electronics Standards Associate (VESA) lokalen Bus sowie den Peripheral Component Interconnect(PCI)-Bus, der auch als Mezzanine-Bus bekannt ist.
  • Der Computer 110 umfasst typischerweise eine Vielfalt von computerlesbaren Medien. Ein computerlesbares Medium kann jedes verfügbare Medium sein, auf das der Computer 110 zugreifen kann, dies umfasst sowohl flüchtige als auch nichtflüchtige Medien, Wechselmedien und nicht wechselbare Medien. Beispielhaft und nicht einschränkend können computerlesbare Medien Computerspeichermedien und Kommunikationsmedien umfassen. Computerspeichermedien umfassen sowohl flüchtige als auch nichtflüchtige Medien, Wechselmedien und nicht wechselbare Medien, die in jedem beliebigen Verfahren oder jeder beliebigen Technologie zum Speichern von Informationen wie beispielsweise computerlesbaren Befehlen, Datenstrukturen, Programmmodulen oder anderen Daten implementiert werden können. Computerspeichermedien umfassen (sind jedoch nicht begrenzt auf) RAM, ROM, EEPROM, Flashspeicher oder andere Speichertechnologien, CD-ROM, DVDs (digital versatile disks) oder andere optische Scheibenspeicher, Magnetkassetten, Magnetband, Magnetscheibenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das zum Speichern der gewünschten Informationen verwendet werden kann und auf das durch den Computer 110 zugegriffen werden kann. Kommunikationsmedien umfassen typischerweise computerlesbare Befehle, Datenstrukturen, Programmmodule oder andere Daten in einem modulierten Datensignal wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus und umfassen jedes Informationsbereitstellungsmedium. Die Bezeichnung „moduliertes Datensignal" bezeichnet ein Signal, bei dem eine oder mehrere seiner Eigenschaften auf eine Weise eingestellt oder geändert werden, dass Informationen in dem Signal verschlüsselt werden. Beispielhaft und nicht einschränkend umfassen Kommunikationsmedien kabelgebundene Medien wie beispielsweise ein Kabelnetzwerk oder eine Kabeldirektverbindung sowie drahtlose Medien wie beispielsweise akustische, Funk-, Infrarot- und andere drahtlose Medien. Kombinationen aus allen oben genannten Möglichkeiten sind darüber hinaus im Umfang der computerlesbaren Medien enthalten.
  • Der Systemspeicher 130 umfasst Computerspeichermedien in der Form flüchtiger und/oder nichtflüchtiger Speicher wie beispielsweise Nurlesespeicher (read only memory – ROM) 131 und Direktzugriffsspeicher (random access memory – RAM) 132. Ein Basisdatenaustauschsystem 133 (basic input/output system – BIOS), das die Haupthilfsprogramme enthält, mit denen Informationen zwischen den Elementen innerhalb des Computers 110 übertragen werden, beispielsweise während des Hochfahrens, ist typischerweise im ROM 131 gespeichert. Der RAM 132 enthält typischerweise Daten- und/oder Programmmodule, auf die sofort zugegriffen werden kann und/oder die derzeit von der Verarbeitungseinheit 120 bearbeitet werden. Beispielhaft und nicht einschränkend werden in 1 das Betriebssystem 134, Anwendungsprogramme 135, andere Programmmodule 136 und Programmdaten 137 dargestellt.
  • Der Computer 110 kann darüber hinaus andere wechselbare/nicht wechselbare, flüchtige/nichtflüchtige Computerspeichermedien enthalten. 1 stellt nur beispielhaft ein Festplattenlaufwerk 141 dar, das von nicht wechselbaren, nichtflüchtigen Magnetmedien liest oder auf diese schreibt, ein Magnetscheibenlaufwerk 151, das von einer wechselbaren, nichtflüchtigen Magnetscheibe 152 liest oder auf diese schreibt, sowie ein optisches Scheibenlaufwerk 155, das von einer wechselbaren, nichtflüchtigen optischen Scheibe 156 wie beispielsweise einer CD-ROM oder von anderen optischen Medien liest oder auf diese schreibt. Andere wechselbare/nicht wechselbare, flüchtige/nichtflüchtige Computerspeichermedien, die in der beispielhaften Betriebsumgebung verwendet werden können, umfas sen, sind jedoch nicht begrenzt auf, Magnetbandkassetten, Flashspeicherkarten, DVDs (digital versatile disks), digitales Videoband, Festkörper-RAM, Festkörper-ROM und dergleichen. Das Festplattenlaufwerk 141 ist typischerweise mit dem Systembus 121 über eine nicht wechselbare Speicherschnittstelle wie beispielsweise die Schnittstelle 140 verbunden, und das Magnetscheibenlaufwerk 151 und das optische Scheibenlaufwerk 155 sind typischerweise mit dem Systembus 121 über eine Schnittstelle für wechselbaren Speicher wie beispielsweise die Schnittstelle 150 verbunden.
  • Die oben diskutierten und in 1 dargestellten Laufwerke und ihre zugeordneten Computerspeichermedien stellen einen Speicher computerlesbarer Befehle, Datenstrukturen, Programmmodule und anderer Daten für den Computer 110 bereit. In 1 beispielsweise wird das Festplattenlaufwerk 141 als Speicher für das Betriebssystem 144, Anwendungsprogramme 145, andere Programmmodule 146 und Programmdaten 147 dargestellt. Es ist darauf hinzuweisen, dass diese Komponenten mit dem Betriebssystem 134, den Anwendungsprogrammen 135, anderen Programmmodulen 136 und Programmdaten 137 identisch oder von diesen verschieden sein können. Dem Betriebssystem 144, den Anwendungsprogrammen 145, anderen Programmmodulen 146 und Programmdaten 147 werden hier unterschiedliche Nummerierungen zugewiesen, um darzustellen, dass sie mindestens unterschiedliche Kopien sind. Ein Benutzer kann durch Eingabevorrichtungen wie beispielsweise eine Tastatur 162 und eine Zeigevorrichtung 161, die üblicherweise als Maus, Trackball oder integriertes Berührungsfeld (Touchpad) bezeichnet wird, Befehle und Informationen in den Computer 110 eingeben. Andere Eingabevorrichtungen (nicht dargestellt) können ein Mikrofon, ein Handsteuergeber (joystick), ein Berührungsfeld für Spiele (game pad), eine Satellitenschüssel, ein Scanner oder dergleichen sein. Diese und andere Eingabevorrichtungen werden oft mit der Verarbeitungseinheit 120 über eine Benutzereingabeschnittstelle 160 verbunden, die mit dem Systembus 121 verbunden ist, sie können jedoch auch über andere Schnittstellen- und Busstrukturen wie beispielsweise einen Parallelanschluss (parallel port), einen Handsteuergeber-Anschluss (game Port) oder einen universellen seriellen Bus (USB) verbunden werden. Ein Bildschirm (Monitor) 191 oder eine andere Art der Anzeigevorrichtung ist ebenfalls über eine Schnittstelle wie beispielsweise eine Videoschnittstelle 190 mit dem Systembus 121 verbunden. Zusätzlich zu dem Bildschirm können Computer auch andere Peripherie-Ausgabevorrichtungen wie beispielsweise Lautsprecher 197 und Drucker 196 enthalten, die über eine Ausgabeperipherie-Schnittstelle 195 verbunden sein können.
  • Der Computer 110 kann in einer Netzwerkumgebung arbeiten und logische Verbindungen zu einem oder mehreren entfernten (remote) Computern wie beispielsweise einem entfern ten Computer 180 besitzen. Der entfernte Computer 180 kann ein anderer Personalcomputer, ein Server, ein Router, ein Netzwerk-PC, eine Peer-Vorrichtung oder ein anderer gebräuchlicher Netzwerkknoten (network node) sein und umfasst typischerweise viele oder alle Elemente, die oben in Bezug auf den Personalcomputer 110 beschrieben wurden, obwohl in 1 nur eine Speichervorrichtung (memory storage device) 181 dargestellt wird. Die in 1 dargestellten, logischen Verbindungen umfassen ein lokales Netzwerk (local area network – LAN) 171 und ein Weitverkehrsnetzwerk (wide area network – WAN) 173, sie können darüber hinaus jedoch auch andere Netze umfassen. Derartige Netzwerkumgebungen sind in Büros, unternehmensweiten Computernetzen, Intranets und dem Internet gängig.
  • Wenn der Computer 110 in einer LAN-Netzwerkumgebung verwendet wird, ist er mit dem LAN 171 über eine Netzwerkschnittstelle oder einen Netzwerkadapter 170 verbunden. Wenn der Computer 110 in einer WAN-Netzwerkumgebung verwendet wird, umfasst der Computer 110 typischerweise ein Modem 172 oder eine andere Einrichtung zum Einrichten einer Kommunikation über das WAN 173, wie beispielsweise das Internet. Das Modem 172 kann ein internes oder ein externes Modem und mit dem Systembus 121 über die Benutzereingabeschnittstelle 160 oder andere geeignete Mechanismen verbunden sein. In einer Netzwerkumgebung können die in Bezug auf den Personalcomputer 110 dargestellten Programmmodule oder Teile davon in der entfernten Speichervorrichtung gespeichert sein. Beispielhaft und nicht einschränkend werden in 1 entfernte Anwendungsprogramme 185 als in der Speichervorrichtung 181 angesiedelt dargestellt. Es wird festgestellt, dass die dargestellten Netzwerkverbindungen beispielhaft sind und dass andere Mittel zum Einrichten einer Kommunikationsverbindung zwischen den Computern verwendet werden können.
  • In der folgenden Beschreibung wird die Erfindung in Bezug auf Handlungen und symbolische Darstellungen von Operationen beschrieben, die von einem oder mehreren Computern durchgeführt werden, sofern nicht anders dargestellt. Somit versteht es sich, dass solche Handlungen und Operationen, auf die dahingehend Bezug genommen wird, als dass sie durch einen Computer ausgeführt werden, die Bearbeitung elektrischer Signale, die Daten in einer strukturierten Form darstellen, durch die Prozessoreinheit des Computers einschließen. Diese Bearbeitung wandelt die Daten um oder hält sie an Orten in dem Speichersystem des Computers vor, was den Betrieb des Computer auf eine Weise neu konfiguriert oder verändert, die von Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik wohl verstanden wird. Die Datenstrukturen, in denen Daten vorgehalten werden, sind physikalische Orte des Speichers, die besondere Eigenschaften besitzen, welche durch das For mat der Daten definiert werden. Während die Erfindung in dem vorangegangenen Kontext beschrieben wird, ist dies jedoch nicht als begrenzend zu verstehen, da Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik erkennen, dass verschiedene der im Folgenden beschriebenen Handlungen und Operationen auch in Hardware implementiert sein können.
  • Ein echtes, serverloses oder Peer-to-Peer(P2P)-Namensauflösungsprotokoll, für das die vorliegende Erfindung in ihren wesentlichen Grundzügen besonders geeignet ist, wird in dem Dokument US 7.065.587 „PEER-TO-PEER NAME RESOLUTION PROTOCOL (PNRP) AND MULTILEVEL CACHE FOR USE THEREWITH" beschrieben, das am 29.08.2001 angemeldet und an den Zessionar der vorliegenden Anmeldung abgetreten wurde. Dieses PNRP stellt eine Konvergenz in großen P2P-Netzwerken mit Hilfe zweier Mechanismen sicher: ein Mehrebenen-Cache (multilevel cache) und eine proaktive Cache-Initialisierungsstrategie. Der Mehrebenen-Cache ermöglicht es, dass das Protokoll an Netzwerke verschiedener Größen anpassbar ist und nur als Logarithmus der Größe des Netzwerkes wächst (und nicht linear, wie für frühere Peer-to-Peer-Protokolle erforderlich). Dem Mehrebenen-Cache liegt das Konzept eines zirkulären Zahlenraumes (circular number space) zu Grunde. Jede Ebene in dem Cache enthält Informationen von unterschiedlichen Ebenen von Teilen („Splittern” – slivers) des zirkulären Zahlenraumes. Die Anzahl der Ebenen in dem Cache ist abhängig von der Größe des Netzwerkes, an das er angehängt ist. Da diese Größe jedoch unbekannt ist, wird ein Mechanismus eingebaut, der dem Mehrebenen-Cache eine Ebene hinzufügt, wenn der Knoten (node) feststellt, dass die letzte Ebene voll ist. Auf diese Weise ist eine schnelle Konvergenz sichergestellt.
  • Im Allgemeinen ist der PNRP-Cache eine Sammlung von Peer-Adresszertifikaten (PACs), die eine Kenntnis über ausgewählte Teilnehmer in der PNRP-Wolke darstellen. Aus der Sicht des PNRP-Caches bildet jedes PAC in dem Cache ein Paar mit einer PNRP-ID mit einem PNRP-Netzwerk-Endpunkt. PNRP-IDs sind unsignierte Ganzzahlen mit 256 Bit, die aus zwei Feldern, einer P2P-ID sowie einem Ort des Dienstes (service location) bestehen. Wie in der oben identifizierten Anwendung beschrieben, ist die P2P-ID ein kryptografischer Streuwert (hash) eines P2P-Namens und sie ist die 128 Bits mit dem höchsten Stellenwert (most significant 128 bits) einer PNRP-ID. Der kryptografische Streuwert stellt sicher, dass die P2P-IDs in dem Zahlenraum 2128 zufällig verteilt sind. Der Ort des Dienstes sind die 128 Bits mit dem geringsten Stellenwert (least significant 128 bits) einer PNRP-ID. Seine 64 Bits mit dem höchsten Stellenwert sind eine 0-aufgefüllte (0-padded) IPv4-Adresse oder der Aggregator von einer IPv6-Adresse. Die verbleibenden 64 Bit sind ein Streuwert der IP- Adresse, des Anschlusses (port), des Protokolls sowie des öffentlichen Schlüssels, der zum Erzeugen eines PAC für diese ID verwendet wird. Die IP-Adresse an dem Ort des Dienstes erzeugt eine Struktur in diesen Teil einer PNRP-ID. Die Verbindung von P2P-IDs mit Orten von Diensten kann als zufällig verteilt betrachtet werden, wodurch bewirkt wird, dass PNRP-IDs insgesamt zufällig verteilt sind.
  • Da PNRP-IDs unsignierte Ganzzahlen sind, können IDs arithmetisch verglichen werden. Die ,Entfernung' wird durch die arithmetische Differenz zwischen zwei IDs modulo PNRP-ID-Zahlenraum oder 2256 gemessen. DistID(), die Entfernung zwischen zwei IDs, kann in der modulo-Arithmetik als die kleinste arithmetische Entfernung zwischen den IDs modulo ID_MAX wie folgt berechnet werden: DistID = MIN({(A – B) mod ID_MAX}, {(B – A) mod ID_MAX}) (1)
  • So wird beispielsweise angenommen, dass es drei PNRP-IDs X 200, Y 202 und Z 204 gibt, wie in 2 dargestellt. In diesem Diagramm befindet sich X 200 näher an Z 204 als an Y 202. Mathematisch ist DistID(X, Z) = 0,2·ID_MAX, während DistID(X, Y) = 0,3·ID_MAX ist.
  • PNRP vertraut auf eine zufällige Verteilung der PNRP-IDs über den Zahlenraum der IDs. Unter der Annahme einer solchen zufälligen Verteilung mit einem Zahlenraum, der eine Mächtigkeit von 2 besitzt, und wenn beispielsweise 24 instanziierte PNRP-IDs vorhanden wären, dann wären im Durchschnitt die zufällig instanziierten IDs (2256/24) = 2252 von der nächsten instanziierten ID entfernt. Dies ist keine Anforderung für jede PNRP-ID, sondern es ist stattdessen eine Erwartung für eine ,typische' ID-Verteilung unter PNRP. Trotz der Tatsache, dass der PNRP-Zahlenraum eine Mächtigkeit von 2256 besitzt, wird zum besseren Verständnis der Cache-Verwaltung der vorliegenden Erfindung die verbleibende Diskussion Algorithmen und Funktionen in einem vereinfachten PNRP-ID-Raum beschreiben. Dieser vereinfachte Raum besteht aus IDs zwischen 0 und 9999 (statt zwischen 0 und 2256), das heißt, die Gruppe der Ganzzahlen modulo 10000. Hierdurch ist die Mathematik leichter verständlich. Die ersten zwei Ziffern entsprechen der P2P-ID und die letzten zwei Ziffern entsprechen dem Ort des Dienstes.
  • PNRP ist ein Routingprotokoll auf Anwendungsebene. Das Protokoll wurde entworfen, um eine Auflösungsanforderung (RESOLVE) zu dem Eigentümer der Ziel-ID, die aufgelöst wird, zu lenken. Im Idealfall ist jeder PNPR-Host, der eine RESOLVE-Anforderung „berührt" (touch), in der Lage, die Entfernung zu der Ziel-ID um eine Zehnerpotenz zu verringern. Um diese Verringerung um eine Zehnerpotenz zu erreichen, wird es anerkannt, dass die bereitgestellte Größenordnung der Verringerung log(Basis K/2) = log((Basiszahl der Einträge in dem Cache)/2) ist. Um somit eine Verringerung um eine Zehnerpotenz in jeder Ebene zu erzielen, wird der Cache mit K = 20 Einträgen populiert. Im Allgemeinen kann jedoch das System der vorliegenden Erfindung eine vom Benutzer auswählbare Größenordnung der Verringerung bereitstellen, indem K in Übereinstimmung mit der soeben diskutierten logarithmischen Funktion ausgewählt wird und indem jede Cache-Region 1/(K/2) des durch die vorangehende Region abgedeckten Zahlenraumes abdeckt und es zulässt, dass K Einträge darin gespeichert werden.
  • So wird beispielsweise angenommen, dass der Eigentümer von PNRP-ID J = 1234 die PNRP-ID Z = 5432 auflösen will. J ist 4198 von Z entfernt, wie gemessen durch DistID(J, Z) = MIN({1234 – 5432 mod 10000), {5432 – 1234 mod 10000}) = MIN({5802}, {4198}) = 4198. J weiß wahrscheinlich nicht genau, wo sich Z befindet, sollte jedoch in der Lage sein, die Auflösungsanforderung RESOLVE an einen in seinem Cache gespeicherten Peer K, der eine PNRP-ID besitzt, die nicht weiter als (4198/10) = 420 von Z entfernt ist, weiterzuleiten (forward). K leitet seinerseits die Auflösungsanforderung RESOLVE an L weiter, der nicht weiter als (420/10 = 42 von Z entfernt ist. L leitet die Auflösungsanforderung RESOLVE an M weiter, der nicht weiter als (42/10) = 4 von Z entfernt ist. M gibt anschließend die Auflösungsanforderung RESOLVE direkt an Z weiter, der die Auflösungsanforderung RESOLVE mit einer Antwort RESPONSE beantwortet. In diesem Beispiel ist die Anzahl der Sprünge gleich log(ID_MAX). In einer Ausführungsform ist die Anzahl der Sprünge sogar log(Anzahl instanziierter IDs). Wenn es in diesem vereinfachten Zahlenraum nur 100 aktive PNRP-IDs gibt, sollte die Auflösung log(100) = 2 Sprünge und nicht log(10000) = 4 Sprünge benötigen. Dies ist nicht eingängig, das folgende Beispiel sollte dies jedoch erläutern.
  • Es wird angenommen, dass in der P2P-Wolke nur 100 aktive PNRP-IDs instanziiert sind. Mit der Erwartung, dass diese IDs gleichmäßig in dem PNRP-ID-Raum verteilt sind, kann angenommen werden, dass es einen durchschnittlichen Abstand von 100 zwischen den Peers gibt, wie von der folgenden Gleichung berechnet:
    Figure 00130001
  • In dem oben genannten Beispiel gibt es wahrscheinlich keine IDs L und M, da es statistisch gesehen unwahrscheinlich ist, dass IDs im Abstand von 42 oder 4 von Z existieren. Stattdessen würde auf Grund von Zs relativer Nähe zu K dieser (K) die Adresse von Z kennen. Ein weiterer Denkansatz ist der folgende: Wenn sich 100 IDs in N10000 befinden, die jeweils 100 voneinander entfernt sind, können diese IDs 100 IDs in N1000 zugeordnet werden, die jeweils 10 voneinander entfernt sind, oder selbst 100 IDs in N100, die nur 1 voneinander entfernt sind. Da die Auflösung in N100 zwei Sprünge benötigen sollte (log(100) = 2), wie dies bei dem oben genannten Beispiel in N10000 mit 100 instanziierten IDs der Fall war.
  • Damit der Cache diese Eigenschaften aufweist, muss er sorgfältig strukturiert werden. Ein idealer Cache besitzt eine solche Verteilung von Wissen, dass die Wahrscheinlichkeit, eine bestimmte PNRP-ID zu kennen, zu der Entfernung dieser ID von der lokal registrierten PNRP-ID umgekehrt proportional ist. Die Instanziierung des Caches der vorliegenden Erfindung wendet eine Schrittfunktion auf diese Anforderung an. Es sei angenommen, dass es 1000 instanziierte PNRP-IDs gibt, die alle durchschnittlich DIST_AVG = 10 voneinander entfernt sind. Ein Cache sollte PACs für die zehn ihm am nächsten seienden, instanziierten IDs in jeder Richtung (das heißt, geringer als, größer als) von ihm selbst in der Region besitzen [ID_LOCAL – (DIST_AVG·101), ID_LOCAL + (DIST_AVG·101)]. (3)
  • Dies impliziert eine durchschnittliche Entfernung zwischen PACs in dieser Ebene von DIST_AVG·10°. Diese erste Region ist mit 20 PACs populiert. Die nächste Ebene der Granularität ist die Region [ID_LOCAL – (DIST_AVG·102), ID_LOCAL + (DIST_AVG·102), (4)sie schließt jedoch den ersten Bereich aus. Die Ausschließung summiert sich auf ein Zehntel des Bereiches dieser zweiten Region. Da 10% des Bereiches dieser Cache-Region ausgeschlossen sind, sollte der Cache PACs für 90% von 20 = 18 IDs in dieser Region haben. Dies impliziert eine durchschnittliche Entfernung zwischen PACs von (DIST_AVG·101). Dieser Prozess wird fortgesetzt, bis die Region mit der geringsten Granularität N erreicht ist. Diese letzte Ebene N besitzt PACs in der Region [ID_LOCAL – (DIST_AVG·10N), ID_LOCAL + (DIST_AVG·10N), (5)sie schließt jedoch den ersten bis N – 1-ten Bereich aus. Diese Ausschließungen summieren sich auf ein Zehntel des Bereiches dieser N-ten Region. Somit sollte der Cache der N-ten Region PACs für 90% von 20 = 18 IDs in diesem Bereich besitzen, dies impliziert eine durchschnittliche Entfernung zwischen diesen PACs von (DIST_AVG·10N-1). In dem vollständigen PNRP-Zahlenraum von 2256 beträgt die Anzahl von Cache-Regionen log(2256) dies ist näherungsweise gleich 78 Cache-Regionen. Wird jedoch das Vorhandensein eines statistischen Phänomens, das unter der Bezeichnung „Geburtstagsparadoxon" bekannt ist, auf den PNRP-Zahlenraum angewendet, verringert sich die tatsächliche Anzahl aktiver PNRP-Namen, die wahrscheinlich existieren, auf näherungsweise die Quadratwurzel aus 2256 oder auf nur etwa 2128 aktive Namen. Als ein Ergebnis basiert die Anzahl der Cache-Regionen tatsächlich auf dem log(2128) und ist näherungsweise gleich 38 Cache-Regionen.
  • Diese Cache-Struktur ermöglicht ein effizientes Lenken (routing) einer Auflösungsanforderung RESOLVE auf Basis einer PNRP-ID-Nähe. Ein Peer sollte für jede lokal registrierte PNRP-ID in der Lage sein, die Auflösungsanforderung RESOLVE eine Größenordnung näher an ihr Ziel zu lenken (route). Die oben aufgeführten Regeln sind nahezu ausreichend, um dies sicherzustellen. Damit jedoch die Auflösung konvergiert, sollten die Einträge in jeder Region des Caches einen näherungsweise gleichmäßigen Abstand besitzen. Der gleichmäßige Abstand ermöglicht, dass statistische Garantien über die maximale Entfernung einer aufzulösenden ID von einem Cache-Eintrag gemacht werden können. Insbesondere sind die Bereiche so strukturiert, dass eine zufällig ausgewählte ID in jeder Region nicht mehr als ein Zehntel der Größe der Region von einem im Cache gespeicherten PAC-Eintrag in dieser Region entfernt ist. In dem Idealfall mit 20 im Cache gespeicherten PAC-Einträgen mit gleichmäßigem Abstand ist eine in der Region zufällig ausgewählte ID nicht mehr als 1/40 der Größe der Region von einem im Cache gespeicherten PAC-Eintrag in dieser Region entfernt. Das heißt, da es 20 Einträge mit gleichmäßigem Abstand in einer Region gibt (eine pro 1/20-ten der Region) und da jede zufällig ausgewählte ID nicht weiter als 1/2 der Entfernung zwischen zwei aufeinander folgenden Einträgen von einem Eintrag entfernt sein kann, kann keine zufällig ausgewählte ID mehr als 1/20·1/2 = 1/40 der Größe der Region von einem im Cache gespeicherten PAC-Eintrag in dieser Region entfernt sein. Cache-Regionen werden gemäß der vorliegenden Erfindung in Segmenten organisiert, um die Anforderungen an den Inhalt des Caches zu erfüllen und um den Fall effizient bewältigen zu können, wenn mehrere lokale PNRP-IDs von einem einzigen Cache registriert und unterstützt werden, wie im Folgenden ausführlicher diskutiert werden wird.
  • Ein Peer umfasst vorzugsweise einen unterstützenden Cache für jede einzelne seiner veröffentlichten PNRP-IDs. Der Cache enthält PACs mit strategisch ausgewählten PNRP-IDs.
  • Der Cache besteht aus einer Liste von Segmenten; dies sind nicht überlappende Intervalle, die den gesamten ID-Raum abdecken. Jedes Segment enthält eine Liste von PACs, die nach PNRP-ID sortiert ist. Wie in 3 dargestellt, ist ein Beispiel-PNRP-ID-Zahlenraum 206 von 0 bis 9999 in Cache-Segmente A bis E unterteilt. Die Einheit von auf derselben horizontalen Ebene angezeigten Segmenten entspricht einer einzigen Region, wie oben definiert. Das Segment C 208 entspricht der Region 1, das Segment B 210 und das Segment D 212 entsprechen der Region 2 und das Segment A 214 und das Segment E 216 entsprechen der Region N = 3. Folglich sind die Anteile der Segmente in dieser Figur (A + E) = 10·(B + D) = 111·C. C 208 besitzt eine andere Größe, da jeweils 10% der Breite der Region 3 und der Region 2 durch Ausschließungen für niedrigere Bereiche belegt sind und die Region C 208 keine derartigen Ausschließungen besitzt. Somit besitzt diese im Vergleich zu den anderen Bereichen eine relative Größe von (100/90) = 1,11.
  • Jedes Segment in dem Cache der vorliegenden Erfindung ist gekennzeichnet durch zwei Attribute, den Bereich und den idealen Abstand (oder nur Abstand). Der Bereich ist der Start- und Endpunkt eines Segmentes. Der Abstand ist die ideale PNRP-ID-Entfernung zwischen aneinander angrenzenden PACs in dem Segment. Bereich und idealer Abstand werden zum Berechnen der für ein Segment zulässigen Anzahl PACs verwendet. Die Formel ist
    Figure 00160001
  • So kann beispielsweise ein Segment für die IDs 5000 bis 5449 mit einem idealen Abstand von 50 bis zu (5449 – 5000 + 1)150 = 9 PACs enthalten.
  • In einer Ausführungsform der vorliegenden Erfindung ist der Cache vorzugsweise entsprechend der Anzahl instanziierter IDs und nicht entsprechend dem gesamten Zahlenraum strukturiert. Die Anzahl instanziierter IDs stellt fest, wie viele Bereiche benötigt werden, und somit, wie viele Segmente benötigt werden. Für einen Cache, der eine einzige, lokal registrierte ID bedient, beträgt die Anzahl der Bereiche log(Anzahl instanziierter IDs), und die Anzahl von Segmenten ist 2·(Bereiche) – 1. Als ein Beispiel wird angenommen, dass es in dem vereinfachten Zahlenraum von 0 bis 9999 eine Anzahl von 2000 instanziierten PNRP-IDs gibt. Somit ist die Anzahl der Bereiche log(2000) = 3 Bereiche, und die Anzahl der Segmente ist 2·(3) – 1 = 5.
  • Wenn eine lokale ID 218 bei der ID – 5459 registriert ist, überspannt die erste Region (Segment C 208 in 3) die IDs +/– DIST_AVE·101 in Übereinstimmung mit Gleichung (3) mit einem durchschnittlichen Abstand innerhalb der Cache-Region von DIST_AVE·10°. Wenn ein Zahlenraum von 0 bis 9999 2000 instanziierte IDs besitzt, ist DIST_AVE = 10000/2000 = 5. Daher überspannt Segment C 208 die IDs 5495 – 50 = 5445 bis 5495 + 50 = 5545 mit einem durchschnittlichen Abstand zwischen den IDs von 5 und einer PAC-Kapazität von 20 IDs innerhalb dieser Region gemäß Gleichung (6) oben.
  • Die nächste Region reicht in Übereinstimmung mit der Gleichung (4) oben von 5495 – 500 = 4995 bis 5495 + 500 = 5995, minus Segment C 208, mit einem durchschnittlichen Abstand zwischen den IDs von 50. Somit reicht Segment B 210 von 4995 bis 5444 mit einer PAC-Kapazität von 9 in Übereinstimmung mit der Gleichung (6) oben und Segment D 212 reicht von 5546 bis 5995 mit einer PAC-Kapazität von 9.
  • Die dritte und letzte Region reicht in Übereinstimmung mit der Gleichung (5) oben von 5495 – 5000 = 495 bis (5495 + 5000) mod 10000 = 495 minus die Segmente B 210, C 208 und D 212. Da sich jedoch diese Region um den zirkulären Zahlenraum herumlegt (mod 10000), kann man Segment A 214 als den Bereich von 0 bis 4994 abdeckend betrachten, während man Segment E 216 als den Bereich von 5996 bis 9999 abdeckend betrachten kann. Als ein Ergebnis besitzt das Segment A 214 eine PAC-Kapazität von 10, während das Segment E 216 lediglich eine PAC-Kapazität von 8 besitzt, jeweils bei einem durchschnittlichen Abstand von 500.
  • Unglücklicherweise gibt es in einer großen P2P-Netzwerk-Wolke keine Möglichkeit, die Anzahl instanziierter IDs zu kennen. Dies trifft insbesondere deswegen zu, weil die dynamische Natur der Peers in einer derartigen Wolke berücksichtigt wird. Stattdessen vertraut das System der vorliegenden Erfindung auf die zufällige Verteilung der PNRP-IDs und auf eine Segmentteilungs-Richtlinie zum Strukturieren des Caches auf eine geeignete Weise. In Übereinstimmung mit dieser Richtlinie wird ein erstes Cache-Segment A 218, wie dargestellt in 4A, erstellt, das den gesamten Zahlenraum abdeckt und bis zu 20 PACs enthalten kann. Sind weniger als 20 IDs in der Wolke aktiv, fließt das Segment A 218 nicht über und der Cache bleibt in einer Region 222. 4A zeigt das Segment A 218 mit 20 PACs, die gleichmäßig über den Zahlenraum verteilt sind, sowie eine vertikale Strichlinie 220, die der lokal registrierten PNRP-ID von 5495 entspricht.
  • Wenn ein neues PAC mit einer PNRP-ID, die sich nicht bereits in dem Cache befindet, emp fangen wird, weiß das PNRP, dass der Informationsraum es erfordert, dass sich Dienstinstanzen mit wenigstens zwei Bereichen spezialisieren. Schließlich ist es möglich, dass ein Bedarf nach mehr Bereichen besteht; das Cacheverwaltungsverfahren der vorliegenden Erfindung wartet jedoch, bis das Bedürfnis tatsächlich auftritt, ehe es entsprechende Maßnahmen ergreift. Dieses Verfahren wendet drei Datenstrukturen an, die in Rot-Schwarz-Bäumen (symmetrische binäre B-Bäume) organisiert sind, um diese Vorgehensweise zu vereinfachen Diese Datenstrukturen enthalten einen PAC-Cache-Baum, einen Baum instanziierter Segmente sowie einen Baum uninstanziierter Segmente. Der PAC-Cache-Baum ist einfach eine Sammlung der PACs, die nach der PNRP-ID sortiert und in einem Rot-Schwarz-Baum angeordnet sind. Hierdurch wird das Einfügen, Lokalisieren und Löschen von PACs innerhalb O(Ig2N) vereinfacht. Da der PAC-Cache-Baum nach PNRP-IDs sortiert ist, sind die PACs, die jedem Segment entsprechen, fortlaufend, wie sie beim Durchqueren des Baumes angetroffen werden.
  • Eine instanziierte Segmentstruktur wird ebenfalls für jedes logische Cache-Segment vorgehalten, das instanziiert wurde. Diese Segmentliste umfasst die Segment-Mindest- und Höchstgrenzen (Bereich), den erwarteten Abstand zwischen Einträgen sowie einen Rot-Schwarz-Baum instanziierter Segmente. Dieser Baum instanziierter Segmente enthält Zeiger zu Knoten in dem PAC-Cache-Baum, die der PNRP-ID des PAC entsprechen, das der Start des Segmentes ist. Dieser Baum instanziierter Segmente wird verwendet, um zu bestimmen, in welches Segment ein neu erworbenes PAC hineingehört.
  • Ein Baum uninstanziierter Segmente wird auch von dem System der vorliegenden Erfindung vorgehalten. Dieser Baum uninstanziierter Segmente enthält eine Auflistung des nächsten Segmentes oder der nächsten Segmente in der nächsten Region, die instanziiert werden könnten, wenn die nächsthöhere Region gefüllt ist und ein anderes PAC für diese Region empfangen wird. Das heißt, das System der vorliegenden Erfindung prüft den Baum uninstanziierter Segmente daraufhin, ob ein PAC empfangen wurde, das in ein volles Segment gehören würde, um zu sehen, ob ein uninstanziiertes Segment oder uninstanziierte Segmente in der nächstniedrigeren Region, die das volle Segment überlappt, vorhanden ist oder sind. Wenn dies der Fall ist, instanziiert das System der vorliegenden Erfindung das neue Segment oder die neuen Segmente, wie im Folgenden ausführlicher beschrieben wird, bewegt das neue Segment von dem Baum uninstanziierter Segmente zu dem Baum instanziierter Segmente und berechnet das nächste uninstanziierte Segment oder die nächsten uninstanziierten Segmente für den Baum uninstanziierter Segmente.
  • Zurück zum vorliegenden Beispiel, hier erstellt das System der vorliegenden Erfindung eine zweite Region 224, wenn die Region 1 222 voll ist und ein anderes PAC empfangen wird. Dies wird bestimmt, indem der Baum uninstanziierter Segmente betrachtet und festgestellt wird, dass das Segment B 226 das nunmehr volle Segment A 218 überlappt. Somit wird der Zahlenraum, der vorher von Segment A 218 in 4A eingenommen wurde, in die Segmente A 228, B 226 und C 230 unterteilt, wie in 46 dargestellt. Die Segmente A 228 und C 230 bilden die Region 1 222 und das Segment B 226 bildet die Region 2 224. Die Endpunkte für das Segment B 226 werden bestimmt, indem 10% des Zahlenraumes von Region 1 222, zentriert an der lokal registrierten ID 220, genommen werden. In diesem beispielhaften Zahlenraum würde das Segment B 226 5495 +/– 1000 oder von 4495 bis 6495 überspannen, das Segment A 228 würde 0 bis 4494 überspannen und das Segment C 230 würde 6496 bis 9999 überspannen. Die Segmente sind nicht überlappend, und alle PACs werden in dasjenige Segment migriert, das ihren Teil des PNRP-ID-Raumes 206 abdeckt.
  • Nun wird angenommen, dass die Segmente A 228 und C 230 beide voll sind. Wird ein neues PAC in den Bereich eines dieser beiden Segmente hinzugefügt, muss es in Übereinstimmung mit der PNRP-Verwaltung, die in der oben diskutierten Anwendung beschrieben wird, ein PAC ersetzen, das bereits im Cache in diesem Segment gespeichert ist, da der Baum uninstanziierter Segmente anzeigt, dass es keine uninstanziierten Segmente gibt, die diese Segmente überlappen. Das Segment B 226 befindet sich in der Region 2 224, dies bedeutet, dass sein Abstand ein Zehntel von dem der Segmente A 228 und C 230 beträgt. Folglich besitzt die Region B 224 eine Kapazität von 20 PACs. Da sie jedoch nach ihrer Instanziierung nur 2 PACs enthält, kann sie weitere 18 aufnehmen, ehe sie voll ist. Sind alle PNRP-IDs gut verteilt, müsste es wenigstens 200 instanziierte IDs geben, damit das Segment B 226 voll wird, da B 226 ein Zehntel des vollen Zahlenraumes der IDs 206 abdeckt und ein Zehntel aller registrierten PNRP-IDs potentiell in seinen Bereich hineinpassen.
  • Wenn die zweite Region 224 voll wird und ein anderes PAC empfangen wird, das in diese zweite Region 224 hineinpasst, instanziiert das System der vorliegenden Erfindung eine weitere Cache-Region 232, die in dem Baum uninstanziierter Segmente als 10% der Region 2 224, zentriert an der lokalen ID 220, aufgelistet ist, wie in 4C dargestellt. Das mittlere Zehntel der Region 224 wird in eine neue Region 232 aufgeteilt, und die verbleibenden Teile der Region 2 224 bilden die Segmente B 224 und E 236. Diese Teilung ist analog zu der Teilung, mit der die Segmente 226, 230 aus der ursprünglichen Region A 218 gebildet wurden. Insbesondere überspannt Segment D 238 5495 +/–100 oder von 5395 bis 5595, Segment B 234 überspannt nun 4495 bis 5394 und Segment E 236 überspannt 5596 bis 6495.
  • Nun wird angenommen, dass die Segmente B 234 und E 236 beide ,voll' sind. Wird ein neues PAC in den Bereich eines dieser beiden Segmente hinzugefügt, muss es in Übereinstimmung mit der PNRP-Verwaltung, die in der oben diskutierten Anwendung beschrieben wird, ein PAC ersetzen, das bereits im Cache in diesem Segment gespeichert ist, da es keine uninstanziierten Segmente gibt, die diese Segmente überlappen. Das Segment D 238 befindet sich in der Region 3 232, dies bedeutet, dass sein Abstand ein Zehntel von dem der Segmente B 234 und E 236 beträgt. Folglich besitzt das Segment D 238 eine Kapazität von 20 PACs. Da es jedoch nach seiner Instanziierung nur 2 PACs enthält, kann es weitere 18 aufnehmen, ehe es voll ist. Sind die PNRP-IDs gut verteilt, müsste es wenigstens 2000 instanziierte IDs geben, damit das Segment D 238 voll wird, da es ein Hundertstel des vollen ID-Zahlenraumes 206 abdeckt und ein Hundertstel aller registrierten PNRP-IDs potentiell in seinen Bereich hineinpassen.
  • Wenn die Region 232 voll wird und ein anderes PAC empfangen wird, prüft das System der vorliegenden Erfindung den Baum uninstanziierter Segmente, um zu bestimmen, ob eine zusätzliche Region instanziiert werden sollte. Wenn anerkannt wird, dass ein derartiges Segment existiert, instanziiert das System eine weitere Cache-Region 240 als 10% von der Region 232, zentriert an der lokalen ID 220, wie in 4D dargestellt. Das mittlere Zehntel der Region 232 wird in eine neue Region 240 aufgeteilt, und die verbleibenden Teile der Region 232 bilden die Segmente D 242 und G 244. Diese Teilung ist analog zu der Teilung, mit der die Segmente 238, 236 aus der ursprünglichen Region 224 gebildet wurden. Insbesondere überspannt das Segment F 246 5495 +/– 10 oder von 5485 bis 5505, das Segment D 242 überspannt nun 5395 bis 54844 und Segment G 244 überspannt 5506 bis 5595.
  • Nun wird angenommen, dass die Segmente D 242 und G 244 beide ,voll' sind. Wird ein neues PAC in den Bereich eines dieser beiden Segmente hinzugefügt, muss es in Übereinstimmung mit der PNRP-Verwaltung, die in der oben diskutierten Anwendung beschrieben wird, ein PAC ersetzen, das bereits im Cache in diesem Segment gespeichert ist, da es keine uninstanziierte Segmente gibt, die diese Segmente überlappen. Das Segment F 246 befindet sich in der Region 4 240, dies bedeutet, dass sein Abstand ein Zehntel von dem der Segmente D 242 und G 244 beträgt. Folglich besitzt die Region 240 eine Kapazität von 20 PACs. Da sie jedoch nach ihrer Instanziierung nur 2 PACs enthält, kann sie weitere 18 aufnehmen, ehe sie voll ist. Sind alle PNRP-IDs gut verteilt, müsste es wenigstens 20000 instanziierte IDs geben, damit das Segment F 246 voll wird, da F 246 ein Tausendstel des vollen Zahlenraumes der IDs 206 abdeckt und ein Tausendstel aller registrierten PNRP-IDs po tentiell in seinen Bereich hineinpassen. Da dieser beispielhafte Zahlenraum 206 jedoch nur eine Mächtigkeit von 10000 besitzt und daher nur 10000 registrierte PNRP-IDs aufnehmen kann, ist es in einer gut verteilten Wolke statistisch unwahrscheinlich, dass diese Region voll wird.
  • Die vorangegangenen Diskussionen konzentrierten sich darauf, wie ein Cache um eine einzige, lokal registrierte PNRP-ID zu strukturieren ist, um ein Verständnis der Konzepte der vorliegenden Erfindung hervorzubringen. In der Praxis muss jeder Cache typischerweise jede Anzahl von 10 bis 100 oder mehr lokal registrierter PNRP-IDs unterstützen. Dies liegt daran, dass jede Ressource, für die der Peer es zulässt, dass sie in der Wolke feststellbar ist, mit einer PNRP-ID registriert wird. Allerdings wird jeder durch den Peer bereitgestellte Dienst auch mit einer PNRP-ID registriert. Die oben diskutierten Regeln zum Erstellen von Segmenten in Bezug auf eine einzige PNRP-ID ändern sich nur wenig, wenn mehrere IDs unterstützt werden.
  • Zum Darstellen dieser Mehr-ID-Cacheverwaltungs-Ausführungsform der vorliegenden Erfindung wird angenommen, dass es drei lokal registrierte IDs gibt, beispielsweise X 248, Y 250 und Z 252, die durch denselben Cache unterstützt werden, wie in 5A dargestellt. Wie in der vorangehenden Ausführungsform beginnt der Cache mit einem einzigen Segment, das in diesem Beispiel nun voll ist. A 254 ist an diesem Punkt das einzige instanziierte Segment in dem Cache, und der Baum uninstanziierter Segmente listet die Segmente H 256, I 258 und J 260 (die nächsten uninstanziierten Segmente) auf. Der Bereich des Zahlenraumes, der potentiell von den Segmenten H bis J 256 bis 260 in Region zwei 262 und von P bis R 264 bis 268 in Region drei 270 abgedeckt wird, wird in 5A mit Strichlinien dargestellt. Die Segmente H 256, I 258, J 260, P 264, Q 266 und R 268 existieren noch nicht, sie stellen lediglich dar, wo zusätzliche Segmente hinzugefügt werden könnten, wenn dies notwendig wird. Es sind jedoch, wie oben beschrieben, nur die Segmente H 256, I 258 und J 260 in dem Baum uninstanziierter Segmente enthalten. Die Segmente P, Q und R werden dem Baum uninstanziierter Segmente erst hinzugefügt, wenn die Segmente H, I und J instanziiert sind.
  • Wie aus diesem speziellen Beispiel ersichtlich wird, ist die lokale ID X 248 der ID_MIN so nahe, dass sich ihr Segment der Region zwei als ein Ergebnis der modulo-Arithmetik (das heißt, ID_LOCAL +/– 1/10·{ID_MAX – ID_MIN +1} mod ID_MAX), wenn es instanziiert ist, leicht um ID_MAX wickelt (wrap). Zum Vereinfachen der Suche in dem oben diskutierten Segment-Baum wird diese zweite Region in zwei Segmente H 256 und J 260 geteilt. Auf diese Weise besitzt jedes der Segmente H 296 und J 260 Startadressen, die geringer sind als ihre Endadressen, wodurch es möglich ist, für den Suchvorgang einfache Lineararithmetik statt modulo-Arithmetik (mod ID_MAX) zu verwenden.
  • Wie darüber hinaus aus diesem Beispiel ersichtlich ist, befinden sich die lokalen PNRP-IDs Y 250 und Z 252 in einem Abstand von einem Zehntel des Zahlenraumes voneinander. Somit würden sich ihre potentiellen Segmente der Region zwei 262 überlappen, wenn beide instanziiert würden. Würden zwei derartige Segmente instanziiert und getrennt vorgehalten, würde sich daraus eine Duplizierung von Informationen ergeben, wodurch Ressourcen verschwendet werden. Da diese Segmente dieselbe Granularität besitzen, kombiniert das System dieser Ausführungsform der vorliegenden Erfindung diese beiden in ein einziges Segment I 258. Dieses Segment I besitzt die Startadresse des Beginns desjenigen Segmentes, das auf Basis der lokalen PNRP-ID Y 250 (das heißt, ID_LOCALY_ 1/10·{ID_MAX – ID_MIN + 1} mod ID_MAX) instanziiert worden wäre, und es besitzt die Endadresse des Endes desjenigen Segmentes, das auf Basis der lokalen PNRP-ID Z 252 (das heißt, ID_LOCALZ + 1/10·{ID_MAX – ID_MIN + 1) mod ID_MAX) instanziiert worden wäre. Anders als das typische Teilen von Segmenten in einem Cache unter dem System der vorliegenden Erfindung wurde das einzige obere Segment in dieser Ausführungsform in drei Region-2-Segmente geteilt, die etwas weniger als 30% des Zahlenraumes abdecken. Sie decken weniger als 30% ab, da sich die Region-zwei-Segmente von Y und Z etwas überlappen, um das Segment I 258 zu bilden.
  • Jedes Segment wird durch seinen Bereich und seinen Abstand (bestimmt durch seine Region) gekennzeichnet. Immer, wenn einem Segment ein PAC hinzugefügt wird, wird das Segment zuerst untersucht. Hat das Segment Platz für ein PAC, wird dieses einfach hinzugefügt. Ist das Segment voll, prüft das PNRP, ob es potentielle (uninstanziierte) Segmente in der nächsten Region gibt, die den Bereich dieses Segments überlappen. In dem vorliegenden Beispiel würde das Hinzufügen von einem PAC zu dem Segment A 254, das voll ist, eine Instanziierung der Segmente H 256, I 258 und J 260 bewirken, wie in 5B dargestellt, da diese alle das ursprüngliche Segment A 254 überlappen und sich in der nächsten Region 262 befinden. Alle instanziierten Segmente unterliegen den Regeln für Segmente. Erstens deckt die Einheit aller Segmente den gesamten Zahlenraum ab. Zweitens überlappen sich Segmente nicht. Die Segmente A 272 und B 274 sind voll und kein potentielles Segment überlappt sie. Soll einem dieser Segmente A 272 und B 274 ein PAC hinzugefügt werden, muss ein Eintrag gelöscht werden, ehe der neue Eintrag hinzugefügt werden kann.
  • Die Segmente H 256, I 258 und J 260 können jeweils noch einige weitere Einträge aufnehmen, bevor weitere Teilungen vorgenommen werden müssen. Wird das Segment J 260 voll, muss ein Eintrag darin gelöscht werden, ehe ein neuer hinzugefügt werden kann, da es keine uninstanziierten Bereiche gibt, die das Segment J 260 in der nächsten Region überlappen. Wenn jedoch das Segment H 256 voll wird, führt der Versuch, H 256 einen weiteren Eintrag hinzuzufügen, zu einer Instanziierung von dem Segment P 264, da das uninstanziierte Segment P 264 das Segment H 256 überlappt und sich in der nächsten Region befindet. Wenn das Segment I 258 voll wird, führt der Versuch, einen weiteren Eintrag hinzuzufügen, dazu, dass beide Segmente Q 266 und R 268 instanziiert werden. Dies liegt daran, dass beide Segmente I 258 überlappen und sich in der nächsten Region 270 befinden.
  • Um diesen Punkt grafisch darzustellen, wird nun kurz auf 6 Bezug genommen, worin die Beziehung zwischen dem PAC-Cache-Baum 290, dem Baum instanziierter Segmente 292 und dem Baum uninstanziierter Segmente 294 bildlich dargestellt wird. Wie oben beschrieben, ist der PAC-Cache-Baum 290 ein Rot-Schwarz-Baum, der nach den PNRP-IDs der in dem Cache gespeicherten PACs sortiert ist. Wie bildlich dargestellt, wird jedes tatsächlich in dem Cache gespeicherte PAC in dem PAC-Cache-Baum 290 dargestellt. Der Baum instanziierter Segmente 292 ist ebenfalls in einem Rot-Schwarz-Baum angeordnet, dieser enthält jedoch anstelle der PACs Zeiger zu der Startadresse von jedem in dem Cache instanziierten Segment. Die Organisation in einem Rot-Schwarz-Baum ist bei der Suche nach dem ordnungsgemäßen Segment hilfreich, in das ein neu empfangenes PAC platziert werden soll. Der Baum uninstanziierter Segmente 294 ist ebenfalls als ein Rot-Schwarz-Baum angeordnet, um die Suche zu vereinfachen, und er enthält nur die Segmente in der nächsten Region des Caches, die instanziiert werden könnten, wenn die Bereiche, die sie überlappen, voll werden.
  • Unter der Voraussetzung, dass das Segment I 258 voll ist und ein anderes PAC empfangen wird, das eine PNRP-ID besitzt, wegen der es in dem Segment I 258 platziert werden würde, werden die Segmente Q 266 und R 268 instanziiert, wie in der 5C dargestellt. Als ein Ergebnis des Instanziierens der Segmente Q 266 und R 268 wird das Segment I in die Segmente I 276, K 278 und L 280 unterteilt.
  • Wenn die Segmente Q 266 und R 268 instanziiert wurden, wie in 5C dargestellt, und die an PNRP-ID Y 250 registrierte Ressource oder der Dienst wird entfernt, tritt das System der vorliegenden Erfindung das Cache-Segment Q 266 an die höhere Ebene I 276 ab. Da jedoch das Cache-Segment 1276 als eine Kombination der zwei überlappenden Segmente ausgebildet wurde, die für die in der Nähe befindlichen IDs Y 250 und Z 252 instanziiert worden wären, wird unglücklicherweise auch ein Teil des Segmentes I 276 an das höhere Segment A 284 abgetreten. Wie in 5D dargestellt, decken die verbleibenden Segmente K 282 und L 280 nun nur mehr den Bereich ID_LOCALZ +/- (ID_MAX – ID_MIN + 1) mod ID_MAX ab. Da die höheren Segmente bereits voll sind, werden die PACs in dem Teil der niedrigeren Bereiche, die abgetreten werden, als neue Informationen für die höheren Segmente betrachtet. Somit ist deren Hinzufügung zu diesem höheren Segment von den oben diskutierten PNRP-Regeln abhängig, die das Hinzufügen von Informationen zu einem vollen Segment regeln.
  • Wenn eine neue Ressource oder ein neuer Dienst registriert wird, wenn mehrere Cache-Segmente instanziiert worden sind, wird der Baum uninstanziierter Segmente mit dem nächsten Segment populiert, das instanziiert werden müsste, wenn ein neues PAC in einer vollen Region darunter empfangen würde, die diese neue, uninstanziierte Region überlappt. Wenn ein neues PAC empfangen wird, wird der Baum uninstanziierter Segmente geprüft, wie oben beschrieben, und die Region der niedrigeren Ebene wird gegebenenfalls instanziiert. Existieren Überlappungen mit anderen instanziierten Segmenten, werden die Segmente kombiniert, wie oben beschrieben.
  • Alle hierin zitierten Referenzen, einschließlich Patenten, Patentanmeldungen und Veröffentlichungen werden hiermit jeweils zur Gänze als Referenz eingeschlossen.
  • Unter Berücksichtigung der vielen möglichen Ausführungsformen, auf die die Prinzipien dieser Erfindung angewendet werden können, muss festgestellt werden, dass die hierin beschriebene Ausführungsform in Bezug auf die abgebildeten Figuren lediglich veranschaulichend ist und den Umfang der Erfindung in keinster Weise einschränkt. So erkennen beispielsweise Personen mit gewöhnlicher Erfahrung auf dem Gebiet der Technik, dass die Elemente der dargestellten Ausführungsform, die in Software dargestellt sind, auch in Hardware implementiert werden können und umgekehrt, oder dass die dargestellte Ausführungsform in Bauart und Einzelheiten modifiziert werden kann, ohne von der Erfindung abzuweichen. Daher umfasst die Erfindung, wie hierin beschrieben, alle derartigen Ausführungsformen, die innerhalb des Umfanges der folgenden Ansprüche und ihrer Äquivalente auftreten können.

Claims (22)

  1. Cache-Speicher zur Verwendung in einem Peer mit wenigstens einer lokal registrierten Peer-ID innerhalb eines Peer-Namensraumes, wobei der Peer-Namensraum eine erste Anzahl NumActive-IDs von Peer-IDs darin instanziiert hat und die erste Anzahl von Peer-IDs einen durchschnittlichen Abstand dazwischen aufweisen, umfassend: eine zweite Anzahl N von Speicherregionen zum Speichern von Peer-IDs, dadurch gekennzeichnet, dass jede Speicherregion von 1, ..., N Peer-IDs innerhalb eines Bereiches von +/– K1...N mal den durchschnittlichen Abstand von der wenigstens einen lokal registrierten Peer-ID speichert, wobei K eine positive Ganzzahl größer als 1 ist, jede von den Speicherregionen 2, ..., N die in vorhergehenden Speicherregionen 1, ... N – 1 gespeicherten Peer-IDs ausschließt, die Anzahl N von Speicherregionen als der Logarithmus zur Basis K der ersten Anzahl von in dem Namensraum instanziierten Peer-IDs bestimmt wird und der durchschnittliche Abstand bestimmt wird als
    Figure 00250001
    wobei ID MAX und ID MIN die oberen und unteren Grenzen des Peer-Namensraumes bezeichnen.
  2. Cache-Speicher nach Anspruch 1, wobei K gleich 10 ist.
  3. Cache-Speicher nach Anspruch 2, wobei jede der N Speicherregionen eine Kapazität aufweist, um eine dritte Anzahl von Peer-IDs darin zu speichern, und die dritte Anzahl für jede Speicherregion gleich dem Bereich geteilt durch den durchschnittlichen Abstand ist.
  4. Cache-Speicher nach Anspruch 3, wobei die dritte Anzahl für jede Speicherregion von 2, ..., N gleich dem Bereich seiner zugehörigen Speicherregion weniger den Bereich der vorhergehenden Regionen 1, ... N – 1 ist.
  5. Cache-Speicher nach Anspruch 2, wobei jede Speicherregion von 1, ..., N Peer-IDs speichert, die eine Granularität von 100...N-1 mal den durchschnittlichen Abstand aufweisen.
  6. Cache-Speicher nach Anspruch 2, wobei der Peer wenigstens zwei lokal registrierte Peer-IDs hat, wobei wenigstens eine der zweiten Anzahl von Speicherregionen für jede der zwei lokal registrieren Peer-IDs wenigstens einen gemeinsamen Teil des Namensraumes abdeckt und wobei die wenigstens eine der zweiten Anzahl von Speicherregionen für jede der zwei lokal registrierten Peer-IDs, die wenigstens einen gemeinsamen Teil des Namensraumes abdeckt, in einer einzelnen Speicherregion zusammengefasst wird, um Duplizierung von darin gespeicherten Peer-IDs zu eliminieren.
  7. Cache-Speicher nach Anspruch 2, wobei jede der Speicherregionen N – 1, ..., 1 nur instanziiert wird, nachdem eine nächsthöhere Speicherregion N, ..., 2 voll wird.
  8. Cache-Speicher zur Verwendung in einem Peer mit wenigstens einer ersten lokal registrierten Peer-ID innerhalb eines Peer-Namensraumes, wobei der Namensraum eine unbekannte Anzahl von Peer-IDs darin registriert hat, umfassend: ein erstes Cache-Speichersegment zum Speichern von Peer-IDs, die irgendwo in dem Peer-Namensraum instanziiert sind, wobei das erste Cache-Speichersegment eine vorgegebene Höchstanzahl von Peer-IDs, die darin gespeichert werden können, aufweist, ein zweites Cache-Speichersegment, das eingerichtet ist, um instanziiert zu werden, wenn das erste Cache-Speichersegment die vorgegebene Höchstanzahl von Peer-IDs übersteigt, wobei das zweite Cache-Speichersegment einen Bereich von einem Zehntel des ersten Cache-Speichersegments, zentriert an der ersten lokal registrierten Peer-ID, umspannt, das zweite Cache-Speichersegment in dem ersten Cache-Speichersegment eine Ausschließung bildet und das zweite Cache-Speichersegment eine vorgegebene Höchstanzahl von Peer-IDs, die darin gespeichert werden können, aufweist, ein drittes Cache-Speichersegment, instanziiert, wenn das zweite Cache-Speichersegment die vorgegebene Höchstanzahl von Peer-IDs übersteigt, wobei das dritte Cache-Speichersegment einen Bereich von einem Zehntel des zweiten Cache-Speichersegments, zentriert an der ersten lokal registrierten Peer-ID, umspannt, das dritte Cache-Speichersegment in dem zweiten Cache-Speichersegment eine Ausschließung bildet und das dritte Cache-Speichersegment eine vorgegebene Höchstanzahl von Peer-IDs, die darin gespeichert werden können, aufweist.
  9. Cache-Speicher nach Anspruch 8, des Weiteren ein viertes Cache-Speichersegment, instanziiert, wenn das dritte Cache-Speichersegment die vorgegebene Höchstanzahl von Peer-IDs übersteigt, umfassend, wobei das vierte Cache-Speichersegment einen Bereich von einem Zehntel des dritten Cache-Speichersegments, zentriert an der ersten lokal registrierten Peer-ID, umspannt, und das vierte Cache-Speichersegment in dem dritten Cache-Speichersegment eine Ausschließung bildet.
  10. Cache-Speicher nach Anspruch 8, wobei der Peer wenigstens die erste und eine zweite lokal registrierte Peer-ID enthält, des Weiteren ein fünftes Cache-Speichersegment, instanziiert, wenn das erste Cache-Speichersegment die vorgegebene Höchstanzahl von Peer-IDs übersteigt, umfassend, wobei das fünfte Cache-Speichersegment einen Bereich von einem Zehntel des ersten Cache-Speichersegments, zentriert an der zweiten lokal registrierten Peer-ID, umspannt, das fünfte Cache-Speichersegment in dem ersten Cache-Speichersegment eine Ausschließung bildet und das fünfte Cache-Speichersegment eine vorgegebene Höchstanzahl von Peer-IDs, die darin gespeichert werden können, aufweist.
  11. Cache-Speicher nach Anspruch 10, wobei ein Teil des zweiten und des fünften Cache-Speichersegments einen gemeinsamen Bereich des Namensraumes abdecken und wobei das zweite und das fünfte Cache-Speichersegment in ein sechstes Cache-Speichersegment zusammengefasst werden, um Duplizierung von Information zu verhindern.
  12. Cache-Speicher nach Anspruch 11, des Weiteren ein siebtes Cache-Speichersegment, instanziiert, wenn das sechste Cache-Speichersegment die vorgegebenen Höchstanzahl übersteigt, umfassend, wobei das siebte Cache-Speichersegment einen Bereich von einem Zehntel des zweiten Cache-Speichersegments, zentriert an der zweiten lokal registrierten Peer-ID, umspannt.
  13. Verfahren der Cache-Speicherverwaltung für eine segmentierte Cache-Architektur, die in einem Peer-to-Peer-Namensauflösungssystem verwendet wird, in dem Peers IDs in einem Peer-Namensraum registrieren können, wobei das System wenigstens eine lokal registrierte Peer-ID enthält und das Verfahren die folgenden Schritte umfasst: Populieren eines ersten Cache-Segments mit einer Anzahl von Peer-IDs, die durch das Peer-to-Peer-Namensauflösungssystem festgestellt wurden, Instanziieren eines zweiten Cache-Segments, das einen Bruchteil des ersten Cache-Segments abdeckt und an der lokal registrierten Peer-ID zentriert ist, nach Empfang einer zusätzlichen Peer-ID, die durch das Peer-to-Peer-Namensauflösungssystem festgestellt wurde, nachdem die Anzahl von Peer-IDs, die in das erste Cache-Segment populiert wurde, eine vorgegebene Höchstanzahl erreicht, wobei das zweite Cache-Segment einen Bereich eines Zehntels des ersten Cache-Segments umspannt und die Instanziierung des zweiten Cache-Segments zu einer Ausschließung in dem ersten Cache-Segment führt, und Instanziieren eines dritten Cache-Segments, das einen Bruchteil des zweiten Cache-Segments abdeckt und an der lokal registrierten Peer-ID zentriert ist, nach Empfang einer zusätzlichen Peer-ID, die durch das Peer-to-Peer-Namensauflösungssystem festgestellt wurde, nachdem die Anzahl von Peer-IDs, die in das zweite Cache-Segment populiert wurde, eine vorgegebene Höchstanzahl erreicht, wobei das dritte Cache-Segment einen Bereich eines Zehntels des ersten Cache-Segments umspannt und die Instanziierung des dritten Cache-Segments zu einer Ausschließung in dem zweiten Cache-Segment führt.
  14. Verfahren nach Anspruch 13, das des Weiteren die folgenden Schritte umfasst: Bilden eines ersten Binärbaums, der alle die Peer-IDs enthält, die durch das Peer-to-Peer-Namensauflösungssystem festgestellt wurden, Bilden eines zweiten Binärbaums, der Startadressen in dem Peer-Namensraum für alle der instanziierten Cache-Segmente enthält, und Bilden eines dritten Binärbaums, der uninstanziierte Cache-Segmente, die sich auf ein unmittelbar vorhergehendes instanziiertes Cache-Segment beziehen, enthält.
  15. Verfahren nach Anspruch 14, das des Weiteren die folgenden Schritte umfasst: Empfangen einer neuen Peer-ID, festgestellt durch das Peer-to-Peer-Namensauflösungssystem, Durchsuchen des zweiten Binärbaums, um zu bestimmen, in welches instanziierte Segment die neue Peer-ID gehört, Bestimmen, dass die vorgegebene Höchstanzahl für das instanziierte Segment, in das die neue Peer-ID gehört, nicht erreicht worden ist, und Hinzufügen der neuen Peer-ID zu dem instanziierten Segment, in das die neue Peer-ID gehört, wenn die vorgegebene Höchstanzahl noch nicht erreicht worden ist.
  16. Verfahren nach Anspruch 14, des Weiteren die folgenden Schritte umfassend: Empfangen einer durch das Peer-to-Peer-Namensauflösungssystem festgestellten neuen Peer-ID, Durchsuchen des zweiten Binärbaums, um zu bestimmen, in welches instanziierte Segment die neue Peer-ID gehört, Bestimmen, dass die vorgegebene Höchstanzahl für das instanziierte Segment, in das die neue Peer-ID gehört, erreicht worden ist, und Durchsuchen des dritten Binärbaums, um zu bestimmen, ob ein uninstanziiertes Segment vorhanden ist, das das instanziierte Segment, in das die neue Peer-ID gehört, überlappt, wenn die vorgegebene Höchstanzahl erreicht worden ist, und Instanziieren eines neuen Cache-Segments, wenn der Schritt des Durchsuchens des dritten Binärbaums das uninstanziierte Segment identifiziert, das das instanziierte Segment, in das die neue Peer-ID gehört, überlappt.
  17. Verfahren nach Anspruch 14, des Weiteren die folgenden Schritte umfassend: Empfangen einer durch das Peer-to-Peer-Namensauflösungssystem festgestellten neuen Peer-ID, Durchsuchen des zweiten Binärbaums, um zu bestimmen, in welches instanziierte Segment die neue Peer-ID gehört, Bestimmen, dass die vorgegebene Höchstanzahl für das instanziierte Segment, in das die neue Peer-ID gehört, erreicht worden ist, Durchsuchen des dritten Binärbaums, um zu bestimmen, ob ein uninstanziiertes Segment vorhanden ist, das das instanziierte Segment, in das die neue Peer-ID gehört, überlappt, und zufallsbestimmtes Ersetzen einer Peer-ID in dem instanziierten Segment, in das die neue Peer-ID gehört, wenn der Schritt des Durchsuchens des dritten Binärbaums kein uninstanziiertes Segment identifiziert, das das instanziierte Segment, in das die neue Peer-ID gehört, überlappt.
  18. Verfahren nach Anspruch 13, wobei das System wenigstens eine zweite lokal registrierte Peer-ID enthält, des Weiteren den Schritt des Instanziierens eines vierten Cache-Segments umfassend, das einen Bruchteil des ersten Cache-Segments abdeckt und an der zweiten lokal registrierten Peer-ID zentriert ist, nach dem Empfang einer durch das Peer-to-Peer-Namensauflösungssystem festgestellten zusätzlichen Peer-ID, nachdem die in das erste Cache-Segment populierte Anzahl von Peer-IDs eine vorgegebene Höchstanzahl erreicht, wobei das vierte Cache-Segment einen Bereich von einem Zehntel des dritten Cache-Segments umspannt und die Instanziierung des vierten Cache-Segments zu einer Ausschließung in dem ersten Cache-Segment führt.
  19. Verfahren nach Anspruch 18, wobei das zweite und das vierte Cache-Segment in einem Ausmaß überlappen, des Weiteren den Schritt des Zusammenfassens des zweiten und des vierten Cache-Segments in einem einzelnen Cache-Segment umfassend, um Duplizierung von Informationen in dem zweiten und vierten Cache-Segment zu eliminieren.
  20. Verfahren nach Anspruch 18, wobei die zweite lokal registrierte Peer-ID durch das Peer-to-Peer-Namensauflösungssystem unregistriert ist, des Weiteren die Schritte des Uninstanziierens des vierten Cache-Segments umfassend.
  21. Verfahren nach Anspruch 13, wobei der Schritt des Instanziierens des zweiten Cache-Segments, einen Bruchteil des ersten Cache-Segments abdeckend, den Schritt des Instanziierens des zweiten Cache-Segments, ein Zehntel des ersten Cache-Segments abdeckend, umfasst und wobei der Schritt des Instanziierens des dritten Cache-Segments, einen Bruchteil des zweiten Cache-Segments abdeckend, den Schritt des Instanziierens des dritten Cache-Segments, ein Zehntel des zweiten Cache-Segments abdeckend, umfasst.
  22. Computerlesbares Medium, Befehle umfassend, die, wenn durch einen Computer ausgeführt, den Computer veranlassen, jeden der Verfahrensschritte nach einem der Ansprüche 13 bis 21 auszuführen.
DE60317403T 2002-04-15 2003-04-10 Mehrstufige Cache-Speicherarchitektur und Cache-Speicherverwaltungsverfahren für gleichrangiges Namensauflösungs-Protokoll Expired - Lifetime DE60317403T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/122,863 US6912622B2 (en) 2002-04-15 2002-04-15 Multi-level cache architecture and cache management method for peer-to-peer name resolution protocol
US122863 2002-04-15

Publications (2)

Publication Number Publication Date
DE60317403D1 DE60317403D1 (de) 2007-12-27
DE60317403T2 true DE60317403T2 (de) 2008-09-18

Family

ID=28674662

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60317403T Expired - Lifetime DE60317403T2 (de) 2002-04-15 2003-04-10 Mehrstufige Cache-Speicherarchitektur und Cache-Speicherverwaltungsverfahren für gleichrangiges Namensauflösungs-Protokoll

Country Status (4)

Country Link
US (1) US6912622B2 (de)
EP (1) EP1355477B1 (de)
AT (1) ATE378773T1 (de)
DE (1) DE60317403T2 (de)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7065587B2 (en) * 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
US7493363B2 (en) 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US7299351B2 (en) 2001-09-19 2007-11-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US20030126199A1 (en) * 2002-01-02 2003-07-03 Kadri Seemab Aslam Peer-to-peer namespace directory and discovery
US7051102B2 (en) * 2002-04-29 2006-05-23 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US20040064523A1 (en) * 2002-10-01 2004-04-01 Zheng Zhang Placing an object at a node within a logical space in a peer-to-peer system
JP2006506847A (ja) 2002-11-12 2006-02-23 ゼテーラ・コーポレイシヨン 通信プロトコル、システムおよび方法
US8005918B2 (en) 2002-11-12 2011-08-23 Rateze Remote Mgmt. L.L.C. Data storage devices having IP capable partitions
US7170890B2 (en) * 2002-12-16 2007-01-30 Zetera Corporation Electrical devices with improved communication
US7649880B2 (en) 2002-11-12 2010-01-19 Mark Adams Systems and methods for deriving storage area commands
US7613812B2 (en) 2002-12-04 2009-11-03 Microsoft Corporation Peer-to-peer identity management interfaces and methods
US20040160975A1 (en) * 2003-01-21 2004-08-19 Charles Frank Multicast communication protocols, systems and methods
US7139760B2 (en) * 2003-01-27 2006-11-21 Microsoft Corporation Peer-to-peer record structure and query language for searching and discovery thereof
US7596625B2 (en) 2003-01-27 2009-09-29 Microsoft Corporation Peer-to-peer grouping interfaces and methods
US7437440B2 (en) * 2003-01-27 2008-10-14 Microsoft Corporation Peer-to-peer networking framework application programming interfaces
US8261062B2 (en) 2003-03-27 2012-09-04 Microsoft Corporation Non-cryptographic addressing
US20040254977A1 (en) * 2003-06-13 2004-12-16 Microsoft Corporation Extensible peer-to-peer graphing messages
US7533184B2 (en) * 2003-06-13 2009-05-12 Microsoft Corporation Peer-to-peer name resolution wire protocol and message format data structure for use therein
US8260857B2 (en) * 2003-10-23 2012-09-04 Microsoft Corporation One to many data projection system and method
US7496648B2 (en) * 2003-10-23 2009-02-24 Microsoft Corporation Managed peer name resolution protocol (PNRP) interfaces for peer to peer networking
US7949996B2 (en) 2003-10-23 2011-05-24 Microsoft Corporation Peer-to-peer identity management managed interfaces and methods
US7716273B2 (en) * 2003-10-24 2010-05-11 Microsoft Corporation Systems and methods for projecting content from computing devices
US7336623B2 (en) * 2003-10-30 2008-02-26 Microsoft Corporation Peer-to-peer cloud-split detection and repair methods
JP2005198201A (ja) 2004-01-09 2005-07-21 Ntt Docomo Inc ネットワークトポロジー構成方法及びノード
US20050177715A1 (en) * 2004-02-09 2005-08-11 Microsoft Corporation Method and system for managing identities in a peer-to-peer networking environment
US7603716B2 (en) * 2004-02-13 2009-10-13 Microsoft Corporation Distributed network security service
US7814543B2 (en) * 2004-02-13 2010-10-12 Microsoft Corporation System and method for securing a computer system connected to a network from attacks
US7716726B2 (en) * 2004-02-13 2010-05-11 Microsoft Corporation System and method for protecting a computing device from computer exploits delivered over a networked environment in a secured communication
US20080281950A1 (en) * 2004-03-08 2008-11-13 First Oversi Ltd Method and Device for Peer to Peer File Sharing
US8688803B2 (en) 2004-03-26 2014-04-01 Microsoft Corporation Method for efficient content distribution using a peer-to-peer networking infrastructure
US7929689B2 (en) 2004-06-30 2011-04-19 Microsoft Corporation Call signs
US7716727B2 (en) * 2004-10-29 2010-05-11 Microsoft Corporation Network security device and method for protecting a computing device in a networked environment
US8683020B2 (en) 2005-02-26 2014-03-25 Coco Communications Corp. Naming system layer
US7826396B2 (en) 2005-03-07 2010-11-02 Miller John L System and method for implementing PNRP locality
US7702850B2 (en) 2005-03-14 2010-04-20 Thomas Earl Ludwig Topology independent storage arrays and methods
US7817647B2 (en) * 2005-04-22 2010-10-19 Microsoft Corporation Flower-petal resolutions for PNRP
US8036140B2 (en) 2005-04-22 2011-10-11 Microsoft Corporation Application programming interface for inviting participants in a serverless peer to peer network
US7571228B2 (en) 2005-04-22 2009-08-04 Microsoft Corporation Contact management in a serverless peer-to-peer system
US7620981B2 (en) 2005-05-26 2009-11-17 Charles William Frank Virtual devices and virtual bus tunnels, modules and methods
US20070011231A1 (en) * 2005-07-06 2007-01-11 Microsoft Corporation Application and user interface for facilitating a meeting
US7743214B2 (en) * 2005-08-16 2010-06-22 Mark Adams Generating storage system commands
US8819092B2 (en) 2005-08-16 2014-08-26 Rateze Remote Mgmt. L.L.C. Disaggregated resources and access methods
US20070050450A1 (en) * 2005-08-29 2007-03-01 Microsoft Corporation Interfacing an applet with a collaboration program
US8255546B2 (en) * 2005-09-30 2012-08-28 Microsoft Corporation Peer name resolution protocol simple application program interface
US9270532B2 (en) 2005-10-06 2016-02-23 Rateze Remote Mgmt. L.L.C. Resource command messages and methods
US7516116B2 (en) * 2006-04-07 2009-04-07 Microsoft Corporation Range and cover queries in overlay networks
US7924881B2 (en) 2006-04-10 2011-04-12 Rateze Remote Mgmt. L.L.C. Datagram identifier management
US20070250590A1 (en) * 2006-04-21 2007-10-25 Microsoft Corporation Ad-hoc proxy for discovery and retrieval of dynamic data such as a list of active devices
US8086842B2 (en) 2006-04-21 2011-12-27 Microsoft Corporation Peer-to-peer contact exchange
US7617322B2 (en) * 2006-09-29 2009-11-10 Microsoft Corporation Secure peer-to-peer cache sharing
US20080209053A1 (en) * 2007-02-28 2008-08-28 Microsoft Corporation HTTP-Based Peer-to-Peer Framework
WO2009007587A1 (fr) 2007-06-27 2009-01-15 France Telecom Procede et dispositif de mise en relation de pairs dans un reseau
US8055847B2 (en) 2008-07-07 2011-11-08 International Business Machines Corporation Efficient processing of data requests with the aid of a region cache
CN101483604B (zh) * 2009-02-16 2011-09-14 华为技术有限公司 资源列表发送方法、装置和系统
AU2010239086A1 (en) * 2009-04-24 2011-12-15 Aaron Antony Peapell Data storage system
US9253548B2 (en) 2010-05-27 2016-02-02 Adobe Systems Incorporated Optimizing caches for media streaming
WO2012015396A1 (en) * 2010-07-28 2012-02-02 Hewlett -Packard Development Company L.P. File based cache loading
US8443086B2 (en) 2011-06-22 2013-05-14 National Chiao Tung University Decentralized structured peer-to-peer network and load balancing methods thereof
US20130212210A1 (en) * 2012-02-10 2013-08-15 General Electric Company Rule engine manager in memory data transfers
CN102880555B (zh) * 2012-07-28 2016-02-24 福州大学 面向实时系统的内存算法
US9961527B2 (en) 2016-06-30 2018-05-01 Verizon Patent And Licensing Inc. Access control and scheduling mechanism for MTC devices

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987376A (en) 1997-07-16 1999-11-16 Microsoft Corporation System and method for the distribution and synchronization of data and state information between clients in a distributed processing system
US7065587B2 (en) * 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
US7299351B2 (en) * 2001-09-19 2007-11-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) security infrastructure and method
US7493363B2 (en) * 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US7068789B2 (en) * 2001-09-19 2006-06-27 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method

Also Published As

Publication number Publication date
DE60317403D1 (de) 2007-12-27
US20030196060A1 (en) 2003-10-16
ATE378773T1 (de) 2007-11-15
EP1355477A2 (de) 2003-10-22
EP1355477B1 (de) 2007-11-14
US6912622B2 (en) 2005-06-28
EP1355477A3 (de) 2005-08-10

Similar Documents

Publication Publication Date Title
DE60317403T2 (de) Mehrstufige Cache-Speicherarchitektur und Cache-Speicherverwaltungsverfahren für gleichrangiges Namensauflösungs-Protokoll
DE60317925T2 (de) Steuerung von netzwerkverkehr in einer peer-to-peer umgebung
DE60211524T2 (de) Verfahren und vorrichtung zur verteilten lieferung von inhalten innerhalb eines computernetzwerkes
DE69728182T2 (de) Verfahren und gerät zum entfernten netzwerkzugriffseintrag und netzwerkzugriffsbericht
DE69909839T2 (de) Optimierte Lokalisierung von Netzwerkbetriebsmittel
DE69628769T2 (de) System und Verfahren um die Belastung von Datei-Server zu verteilen
DE69928860T2 (de) System und Verfahren zur Auswahl von Servern für gespiegelte Sites
DE60126798T2 (de) Verfahren zum durchsuchen und analysieren von informationen in datennetzen
DE602004005756T2 (de) Ein verfahren zur verwaltung von netzwerken durch analyse der konnektivität
DE69935920T2 (de) Lastausgleich in einer netzwerkumgebung
DE60308260T2 (de) Verfahren und Vorrichtung zum effizienten Vergleich von Antworten auf vorher vermittelte Anforderungen durch einen Netzknoten
EP0703534B1 (de) Speicherverwaltungssystem eines Rechnersystems
DE60131900T2 (de) Verfahren und system zur verwaltung von verteilten inhalten und verwandten metadaten
DE60015423T2 (de) Verfahren und Vorrichtung zur Objektwiedergabe in einem Netzwerk
DE60117818T2 (de) Verwaltung des ersetzens von daten in einem zwischenspeicher auf einem knoten aufgrund von zwischenspeichern anderer knoten
DE10296682T5 (de) Integriertes Verfahren zur Aufteilung von Netzwerkdatendienstleistungen unter mehreren Teilnehmern
DE112010003458B4 (de) Verfahren und System für die Verwaltung der P2P-Dateiübertragung
DE10148357A1 (de) System und Verfahren zur gemeinsamen Nutzung digitaler Literaturwerke mit einem Schutz gegen illegale Kopien durch Kommunikationsnetze
DE202012013432U1 (de) Speichern von Daten auf Speicherknoten
DE202020005693U1 (de) Externe berechtigungsnachweisfreie Stufen für Datenbankintegrationen
DE602004009819T2 (de) Instrumentationssystem und verfahren zur schätzung von kenngrössen eines dezentralisierten netzwerks
EP2095611B1 (de) Verfahren zur lastverteilung bei einem peer-to-peer-overlay-netzwerk
DE60132360T2 (de) Verwaltung von netzwerk-verkehr durch anwendung einer hashfunktion
DE112017006993T5 (de) System und Verfahren zum Erfassen einer Netztopologie
DE60303384T2 (de) Lastausgleich in datennetzwerken

Legal Events

Date Code Title Description
8364 No opposition during term of opposition