DE102008026373B4

DE102008026373B4 - Verfahren, Vorrichtung und System zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk

Info

Publication number: DE102008026373B4
Application number: DE102008026373A
Authority: DE
Inventors: Udo BARTLANG
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2008-06-02
Filing date: 2008-06-02
Publication date: 2012-09-20
Anticipated expiration: 2028-06-03
Also published as: DE102008026373A1

Abstract

Verfahren zum Bereitstellen von Datenobjekten in einem Peer-to-Peer-Netzwerk (P2P), welches mehrere Peer-Einrichtungen (P, S1, S2, M) aufweist, wobei mindestens ein Datenobjekt redundant in Peer-Einrichtungen (M, S1, S2), welche einer Replikationsgruppe (RG) zugeordnet sind, gespeichert werden, wobei das Datenobjekt in einen von mindestens zwei Datentypen typisiert wird, bei einer Datenoperation für das gespeicherte Datenobjekt eine Überprüfung des Datentyps erfolgt, wobei eine Typisierung in veränderbare und nichtveränderbare Datenobjekte als Datentypen erfolgt, und in Abhängigkeit von dem jeweiligen Datentyp bei der Datenoperation für das gespeicherte Datenobjekt in einer Replikationsgruppe (RG) eine Konsistenzüberprüfung erfolgt oder das Datenobjekt direkt der Datenoperation unterzogen wird, wobei für die nichtveränderbaren Datenobjekte keine Konsistenzprüfung bei der Datenoperation erfolgt.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen von Daten in oder durch ein Peer-to-Peer-Netzwerk, eine geeignete Peer-Einrichtung sowie eine entsprechende Netzwerkanordnung. Die Erfindung betrifft ferner ein Computerprogrammprodukt, welches die Durchführung eines entsprechenden Verfahrens auf mehreren programmgesteuerten Rechnereinrichtungen veranlasst.
Peer-to-Peer-Netzwerke werden aus gleichberechtigten Peer-Einrichtungen aufgebaut, die über ein untergeordnetes Kommunikationsnetzwerk, wie beispielsweise dem Internet, miteinander vernetzt sind. Im Gegensatz zu sogenannten Client-Server-Netzwerken, bei denen Servereinrichtungen bestimmte Dienste oder Funktionalitäten anbieten, die von den Client-Einrichtungen genutzt werden können, teilen sich in Peer-to-Peer-Netzwerken die beteiligten Peer-Einrichtungen, insbesondere ihre Hardware-Ressourcen wie Rechenleistung, Speichermöglichkeiten, Netzwerkanbindung oder auch Druckereinrichtungen gemeinsam. In Peer-to-Peer-Netzwerken kann prinzipiell jede Peer-Einrichtung mit jeder anderen Peer-Einrichtung, die dem Peer-to-Peer-Netzwerk angeschlossen ist, kommunizieren und deren Ressourcen nutzen. Das Peer-to-Peer-Netzwerk ist dabei vollständig dezentral organisiert.
Als Peer-to-Peer-Netzwerkprotokolle, die beispielsweise Adressauflösungen und das Hinzustoßen weiterer Peer-Einrichtungen zu dem bestehenden Netzwerk oder Abmelden von Peer-Einrichtungen von den Peer-to-Peer-Netzwerken realisieren, seien beispielsweise Freenet oder Chord genannt. In der Regel setzt ein Peer-to-Peer-System auf einem bestehenden Netzwerk, insbesondere dem Internet, auf. Man spricht auch von sogenannten Overlay-Protokollen.
Im Folgenden wird die Bezeichnung Peer und Peer-Einrichtung verwendet, es sind jedoch auch Bezeichnungen, wie Netzelement, Komponente, Kommunikationsendgerät, Teilnehmer, Instanz oder Station geläufig.
Die Kommunikation zwischen Peers erfolgt dabei über das Protokoll des untergeordneten Kommunikationsnetzwerkes, welches in der Regel das Internet ist. Eine Datenverbindung zwischen zwei Peers eines P2P-Netzwerkes erfordert zunächst die Ermittlung der Netzwerkadresse des angefragten Peers aus der Knoten-Adresse, die dem anfragenden Peer bekannt ist. Ein anfragender Peer macht dabei dynamisch weitere Peers des P2P-Netzwerkes ausfindig und kommuniziert mit diesen, um Daten und Informationen auszutauschen. Die Adressauflösung, also das Ausfindigmachen der Netzwerkadresse des durch eine Knoten-Adresse in dem P2P-Netzwerk charakterisierten angefragten Peers, erfolgt dynamisch über ein Routing-Protokoll.
Eine Möglichkeit besteht beispielsweise in der Verwendung einer verteilten Hash-Tabelle (DHT = Distributed Hash Table). Dabei ist die Tabelle, welche jedem Peer bzw. jeder Knoten-Adresse eine entsprechende Netzwerkadresse in dem übergeordneten Kommunikationsnetzwerk zuordnet, auf alle beteiligten Peers in dem P2P-Netzwerk verteilt. Bei einer ringförmig organisierten logischen Anordnung der Peers bzw. der Knoten-Adressen können die Peers beispielsweise eine Anzahl von benachbarten Peers bzw. Knoten-Adressen und deren Netzwerkadressen in einer lokalen Zuordnungs- oder Hash-Tabelle abspeichern. Der Knotenadressraum weist dabei eine Metrik auf, die Abstände zwischen Peers bzw. Knoten-Adressen definiert. Ein geeigneter Algorithmus zur Adressauflösung in einem ringförmig organisierten dezentralen P2P-Netzwerk ist z. B. der Chord-Algorithmus, welcher in Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan: ”CHORD: A Scalable Peer-to-Peer Lookup Service for Internet Applications, MIT-LCS-TR-819 beschrieben ist.
Die Zuordnung einer Knoten-Adresse oder Knoten-ID (node-ID) kann beispielsweise durch Anwendung einer Hash-Funktion auf einen Benutzernamen des betreffenden Peers oder des Dateinamens eines gesuchten Datenobjekts bestimmt werden. Analog können auch Suchbegriffe, wie beispielsweise Dateinamen einer Hash-Funktion unterzogen werden, was einen Hash-Wert liefert. Jedem Peer ist ein Bereich von Hash-Werten zugeordnet, die z. B. wiederum aufsteigend geordnet sind. Der erste Hash-Wert des einen jeweiligen Peer zugeordneten Bereichs entspricht dann z. B. der Knoten-Adresse des betreffenden Peers. Dadurch wird beispielsweise festgelegt, welche Daten unter dem gehashten Dateinamen bei einem Peer verfügbar sind.
Eine Suche nach Daten oder Teilnehmern bzw. Peers wird durchgeführt, indem der anfragende oder suchende Peer den Hash-Wert des vorgegebenen Schlüsselwortes, wie Dateiname, Benutzername oder z. B. Telefonnummer berechnet. Um die Netzwerkadresse der sich durch das Hashen ergebenden, zu suchenden Knoten-ID aufzufinden, sendet der anfragende Peer eine Suchanfrage an einen Peer, der mit seiner Knoten-Adresse und zugehörigen Netzwerkadresse in einer Liste bekannter Peers, beispielsweise einer Nachbarliste und/oder Fingerliste, des anfragenden Peers verzeichnet ist. Falls der angefragte Peer für den gesuchten Hash-Wert zuständig ist, sendet er die angefragten Daten an den anfragenden Peer über das übergeordnete Netzwerk.
Falls der zuerst angefragte Peer nicht für den Hash-Wert zuständig ist, antwortet er mit der Adresse eines Peers aus seiner Peerliste, dessen Knoten-ID dem gesuchten Hash-Wert ähnlicher ist als seine eigene Knoten-Adresse. Ob die eigene Knoten-ID mit der gesuchten Knoten-ID bzw. dem gesuchten Hash-Wert ähnlich ist, ergibt sich aus der verwendeten Metrik des Knotenadressraums. Der zuerst angefragte Peer sendet somit dem anfragenden Peer eine Knoten-ID und IP-Adresse, die dem gesuchten Hash-Wert näher kommt. Der anfragende Peer kann nun eine zweite Suchanfrage an den Peer mit der näheren Knoten-Adresse senden. Dieses Verfahren wird weitergeführt, bis ein Peer gefunden wird, der für den Hash-Wert zuständig ist und die gesuchten Daten liefern kann.
Peer-to-Peer-Netzwerke auf der Basis von DHTs eigenen sich insbesondere zum verteilten sicheren Speichern von Daten durch die beteiligten Peer-Einrichtungen. Da die Zusammensetzung des Peer-to-Peer-Netzwerkes zeitlich variieren kann, z. B. wenn Peer-Einrichtungen zu dem Netzwerk hinzutreten oder es verlassen, werden Datenobjekte auch redundant durch Peer-Einrichtungen abgespeichert, die einer sogenannten Replikationsgruppe zugehörig sind, Mehrere Peers liefern dann dasselbe Datenobjekt mit demselben Dateninhalt. Es erfolgt somit eine Speicherung an verschiedenen physikalischen Speicherorten. Um bei einer Dateioperation, wie z. B. einem Lesen (get) oder Schreiben von Datenobjekten (put) oder auch einem Abgleich der tatsächlich gespeicherten Dateninhalte untereinander in einer Replikationsgruppe (recast) konsistente Dateninhalte zu garantieren wurden Algorithmen, wie in A. Muthitacharoen, et al.: ”Etna: a Fault-tolerant Algorithm for Atomic Mutable DHT Data” MIT-LCS technical report MIT-LCS-TR-993, June 2005 beschrieben vorgeschlagen.
Die US 2006/0168154 A1 offenbart ein System und ein Verfahren zum Verteilten Speichern von Objekten in einem Camputernetzwerk. Dabei ist vorgesehen, dass insbesondere unveränderbare Datenobjekte verteilt und redundant abgespeichert werden. Für jedes Datenobjekt soll dabei ein Replikationsgrad vorgegeben werden, der die Anzahl der Kopien des Datenobjektes an verschiedenen Stellen im Netzwerk vorgibt.
Die Druckschrift FADELELMOULA, A. A. et al.: »Optimistic replication in mobile traffic control environment«, 2007 IEEE, Conference Proceeding Articles, International Conference an Intelligent and Advanced Systems 2007, p. 543–548, XP031397614 beschreibt ein Verfahren zum Datenmanagement für den Datenaustausch von mobilen Geräten.
Die Druckschrift CHEN, X. et al.: »SCOPE: Scalable Consistency Maintenance in Structured P2P-Systems, 2005 IEEE, Conference Proceeding Articles, p. 1502–1513, XP010829115 beschreibt Peer-to-Peer-Systeme zum Verwalten von dynamisch veränderlichen Dateien.
Aus der Druckschrift WO 01/95556A1 geht eine Vorrichtung und ein Verfahren zur Erhöhung der Sicherheit von mobilen Anwendungen in Peer-to-Peer-Netzwerken hervor. Dabei ist vorgesehen, Sicherheitsüberprüfungen generell für mobile Applikationen vorzunehmen. Konsistenzprüfungen werden bei Datenoperationen gemäß dieser Druckschrift auch für nicht veränderliche Datentypen durchgeführt.
In der Regel wird zwischen veränderlichen (mutable) Daten und unveränderlichen (immutable) Daten unterschieden. Insbesondere bei nebenläufigen Operationen an veränderbaren Daten, welche verteilt in einem Peer-to-Peer-Netzwerk abgespeichert vorliegen, ist eine aufwändige Konsistenzprüfung notwendig. Bei dem vorgenannten Verfahren ist dazu der Austausch mehrerer Nachrichten zwischen den Peers einer Replikationsgruppe erforderlich. Man spricht in diesem Zusammenhang auch von atomaren Operationen, also nebenläufige beziehungsweise parallele Lese- oder Schreiboperationen mehrerer Bearbeiter, die über alle Replikate des Datenobjektes in der Replikationsgruppe konsistent erfolgen muss. Es ist dabei gewünscht, möglichst wenige Nachrichten austauschen zu müssen und somit die (Rechen-)Kosten bei der Durchführung derartiger atomarer Operationen niedrig zu halten.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zu schaffen, das eine sichere und zuverlässige Bereitstellung von Daten durch Peers in einem Peer-to-Peer-Netzwerk ermöglicht.
Diese Aufgabe wird durch ein Verfahren gemäß Patentanspruch 1 gelöst.
Demgemäß wird bei einem Verfahren zum Bereitstellen von Datenobjekten in einem Peer-to-Peer-Netzwerk, welches mehrere Peer-Einrichtungen aufweist, mindestens ein Datenobjekt redundant in Peer-Einrichtungen, welche einer Replikationsgruppe zugeordnet sind, gespeichert. Das Datenobjekt wird in einen von mindestens zwei Datentypen typisiert. Bei einer Datenoperation für das gespeicherte Datenobjekt erfolgt eine Überprüfung hinsichtlich des Datentyps, wobei eine Typisierung in veränderbare und nicht veränderbare Datenobjekte als Datentypen erfolgt. Bei einer Datenoperation für das gespeicherte Datenobjekt in einer Replikationsgruppe wird in Abhängigkeit von dem jeweiligen Datentyp eine Konsistenzüberprüfung durchgeführt, oder das Datenobjekt wird direkt der Datenoperation unterzogen, wobei für die nichtveränderbaren Datenobjekte keine Konsistenzüberprüfung bei der Datenoperation erfolgt.
Dabei kann ein Datenobjekt als abstrakte Datenstruktur aufgefasst werden, welche einen Dateninhalt verkörpert. Für ein Datenobjekt ist auch der Begriff Datenressource geläufig. Der Dateninhalt ist dann in mehreren Peer-Einrichtungen der jeweiligen Replikationsgruppe abgelegt, wobei es prinzipiell möglich ist, dass zum Beispiel durch äußere Störungen der Dateninhalt bei verschiedenen Peer-Einrichtungen untereinander abweicht, dennoch jedoch demselben Datenobjekt zugehörig ist.
Unterschiedliche Dateninhalte desselben Datenobjektes können auch auftreten, wenn als Datenoperationen Schreib- oder Lesezugriffe erfolgen, die vorübergehend nur einzelne der Peers einer Replikationsgruppe betreffen. In der weiteren Beschreibung und Erläuterung der Erfindung wird davon ausgegangen, dass die verwendeten Peer-Einrichtungen nicht selbständig die Dateninhalte ändern oder von Datenfehlern betroffen sind. Zur vereinfachten Erläuterung wird angenommen, dass Peers ausfallen können und andere Peers zu einer Replikationsgruppe hinzustoßen können. Derartige Ereignisse erfordern dann eine Recast-Operation.
Veränderbare Datentypen sind zum Beispiel Indizierungsdaten oder Messdaten, die beispielsweise durch Schreib- beziehungsweise Put-Zugriffe beim Betrieb des Peer-to-Peer-Netzwerkes beziehungsweise dem verteilten Speichern geändert werden. Diese veränderbaren Datenobjekte werden auch als Mutable Ressources bezeichnet. Nicht veränderbare Datenobjekte, beispielsweise feste Mediadaten oder Konfigurationsdaten oder Versionen werden hingegen in der Regel nicht aktiv geändert, so dass deren Behandlung im Peer-to-Peer-Netzwerk einfacher gestaltet werden kann. Bei dem vorgeschlagenen Verfahren zum Bereitstellen von Datenobjekten in einem Peer-to-Peer-Netzwerk mit redundanter Speicherung der Dateninhalte in verschiedenen Peer-Einrichtungen einer Replikationsgruppe werden die Datentypen unterschiedlich behandelt. Beispielsweise ist insbesondere bei nicht veränderbaren Datenobjekten keine aufwändige Konsistenzprüfung bei Datenoperationen innerhalb der Replikationsgruppe notwendig. Dies führt zu einer Einsparung von zwischen den Peer-Einrichtungen auszutauschenden Nachrichten.
Bei einer Variante des Verfahrens überprüft eine jeweilige Peer-Einrichtung zu vorgebbaren Zeitpunkten, ob in Abhängigkeit von dem Datentyp des gespeicherten Datenobjektes eine Recast-Operation für ein konsistentes, redundantes Speichern notwendig ist. Es kann beispielsweise periodisch eine Überprüfung erfolgen. Insbesondere bei unveränderbaren Datentypen in einer Replikationsgruppe kann eine Recast-Operation durch Schreiben des Datenobjektes an eine jeweilige Folge-Peer-Einrichtung in einem Satz von geordneten Peer-Einrichtungen erfolgen. Insofern ist es günstig die Replikationsgruppe als geordneten Satz von Peer-Einrichtungen vorzusehen. In einer Replikationsgruppe können die beteiligten Peer-Einrichtungen beispielsweise fortlaufend indiziert oder nummeriert werden.
Gemäß einer weiteren Variante wird in einer jeweiligen Replikationsgruppe eine Peer-Einrichtung als Master-Peer-Einrichtung festgelegt, welcher die übrigen Peer-Einrichtungen der Replikationsgruppe als Slave-Peer-Einrichtungen zugeordnet sind. Falls nebenläufige Anfragen für ein Datenobjekt veränderbaren Datentyps vorliegen, wird gemäß eines Ausführungsbeispiels des Verfahrens durch die Master-Peer-Einrichtung die jeweilige Datenoperation an dem Datenobjekt sequenziell abgearbeitet. Dadurch ergibt sich eine Einsparung an Koordinierungsnachrichten innerhalb der Replikationsgruppe bei atomaren Datenoperationen.
Zur Gewährleistung der Konsistenz der abgespeicherten Dateninhalte eines Datenobjektes kann eine Übereinstimmung von Datenspeicherungszuständen der durch die Peer-Einrichtung einer jeweiligen Replikationsgruppe gespeicherten Dateninhalte verwendet werden. Es erfolgt zum Beispiel ein Quorum, um den aktuellen und richtigen Dateninhalt des Datenobjektes festzustellen.
Bei einer Erweiterung des Verfahrens zum Bereitstellen von Datenobjekten wird einem jeweiligen Datenobjekt mindestens ein weiterer Replikationsparameter zugeordnet. Mögliche Replikationsparameter sind zum Beispiel;

– eine Identifikation des Datenobjektes in dem Peer-to-Peer-Netzwerk, wobei die Identifikation als Schlüssel für die Anwendung der verwendeten Hash-Funktion aufgefasst werden kann;
– eine Zählvariable für erfolgreich erfolgte Schreibzugriffe; eine Zählvariable für versuchte atomare Schreibzugriffe;
– ein Dateninhalt des Datenobjektes;
– ein Replikationsfaktor, welcher zum Beispiel angibt, wie häufig ein Datenobjekt redundant innerhalb der Replikationsgruppe abgespeichert werden muss;
– eine Identifikation der Replikationsgruppe;
– eine Identifikation einer jeweiligen Master-Peer-Einrichtung; oder
– eine Datenstruktur, welche den Satz von Peer-Einrichtungen, welche die Replikationsgruppe bilden, beschreibt.

Selbstverständlich sind weitere Replikationsparameter, die die Durchführung eines entsprechenden Verfahrens beispielsweise in der Form eines Algorithmus verbessern denkbar. Diesbezüglich sei auch auf die folgende Beschreibung der Ausführungsbeispiele verwiesen.
Bei dem Verfahren kann eine Zuordnung von Peer-Einrichtungen zu einer Replikationsgruppe mit Hilfe eines Paxos-Algorithmus erfolgen. Beispielsweise ist der Paxos-Algorithmus in R. Boichat et al.: ”Deconstructing paxos” in SIGACT News, 34 (1), pages 47–67, 2003 beschrieben. Ein Rückgriff auf den in der Beschreibungseinleitung angedeuteten Etna-Algorithmus kann bei der Konsistenzprüfung erfolgen.
Die Erfindung betrifft darüber hinaus eine programmgesteuerte Peer-Einrichtung, welche derart eingerichtet ist, dass ein Verfahren, wie vorbeschrieben, durchgeführt wird. Ferner liefert die Erfindung eine Netzwerkanordnung mit mehreren programmgesteuerten Peer-Einrichtungen, welche über ein Kommunikationsnetzwerk Nachrichten austauschen, wobei die Peer-Einrichtungen derart eingerichtet sind, dass in entsprechendes Verfahren zum Bereitstellen von Datenobjekten in der Netzwerkanordnung durchgeführt wird.
Schließlich betrifft die Erfindung ein Computerprogrammprodukt, welches die Durchführung eines Verfahrens zum Bereitstellen von Daten auf einer oder mehreren programmgesteuerten Rechnereinrichtungen veranlasst. Denkbar ist z. B. eine Codierung des Verfahrens in computerlesbarer Form auf einem Datenträger. Als Datenträger kommen insbesondere USB-Sticks, Floppy-Disks, CD-ROMs, DVDs oder eine beispielsweise von einer Servereinrichtung herunterladbaren Dateien in Frage.
Weitere vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung sind Gegenstand der Unteransprüche sowie der im Folgenden in Bezug auf die Figuren näher erläuterten Ausführungsbeispiele.
Es zeigt:
1: eine Darstellung eines Ausführungsbeispiels eines Peer-to-Peer-Netzwerks;
2: ein Ausführungsbeispiel für eine Einbettung des Verfahrens zum Bereitstellen von Daten in einer Peer-to-Peer-Umgebung;
3: ein Ablaufdiagramm für ein Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk;
4: eine Darstellung einer Replikationsgruppe bei einer Get-Operation;
5: eine Darstellung einer Replikationsgruppe bei einer Recast-Operation;
6: ein beispielhafter Algorithmus zur Implementierung einer Trigger-Funktion für einen Recast bei einem Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk;
7: ein beispielhafter Algorithmus zur Implementierung einer Recast-Operation bei einem Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk;
8: ein beispielhafter Algorithmus zur Implementierung einer Put-Operation bei einem ein Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk; und
9: ein beispielhafter Algorithmus zur Implementierung einer Get-Operation bei einem ein Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem Peer-to-Peer-Netzwerk.
In den Figuren sind, soweit nichts Anderes angegeben ist, gleiche oder funktionsgleiche Elemente mit denselben Bezugszeichen versehen worden.
Die 1 zeigt eine beispielhafte Darstellung eines Ausführungsbeispiels für ein Peer-to-Peer-Netzwerk, welches mittels verteilter Hash-Tabellen Daten oder Datenobjekte, beispielsweise für einen Nutzer bereitstellt. Dabei erfolgt eine redundante Abspeicherung der Dateninhalte eines jeweiligen Datenobjektes durch mehrere Peer-Einrichtungen, die einer Replikationsgruppe zugeordnet sind.
Das Peer-to-Peer-Netzwerk P2P weist eine Vielzahl von Peer-Einrichtungen P, M, S1, S2, C auf, die untereinander beispielsweise über ein Internetprotokoll, welches in der 1 nicht näher dargestellt ist, Nachrichten austauschen können. Häufig wird das Internet IN als Kommunikationsmedium verwendet. Es sind jedoch auch andere Protokolltypen, wie LAN oder proprietäre Protokolle denkbar. Die Peer-Einrichtungen P, welche auch als Instanzen bezeichnet werden können, sind beispielsweise PCs, die an das Internet gekoppelt sind. es sind aber auch mobile Einrichtungen wie Mobiltelefone oder andere Handheld-Devices möglich, welche über ein Kommunikationsnetzwerk miteinander kommunizieren können.
1 zeigt in dem Peer-to-Peer-Netzwerk P2P eine Replikationsgruppe RG, welche drei Peer-Einrichtungen M, S1, S2 aufweist. Dabei ist eine Peer-Einrichtung als Master-Peer-Einrichtung M eingerichtet, welche im Wesentlichen die Kommunikation bei Dateioperationen koordiniert. Eine Peer-Einrichtung C, welche als Client-Peer-Einrichtung fungiert, sendet beispielsweise eine Schreibanfrage oder einen Put-Request (PUT-REQ) an die Replikationsgruppe RG und da an die Master-Peer-Einrichtung M. Dies ist über den Pfeil M1 dargestellt.
Eine Adressauflösung für das Auffinden des Master-Peers M kann wie einleitend erläutert ist, erfolgen.
Es ist beispielsweise denkbar, dass die Client-Peer-Einrichtung C ein unveränderbares Datenobjekt, wie beispielsweise ein Audiofile, im Peer-to-Peer-Netzwerk P2P abspeichern möchte. Dazu wird der entsprechende Dateninhalt physikalisch unabhängig auf allen Peer-Einrichtungen der Replikationsgruppe RG abgelegt. Somit sendet die Master-Peer-Einrichtung M Put-Operationsbefehle beziehungsweise Schreib-Operationsbefehle oder Nachrichten M2 an die übrigen Peer-Einrichtungen S1 und S2 der Replikationsgruppe RG. Der von der Client-Peer-Einrichtung C empfangene Dateninhalt des gewünschten zu schreibenden Datenobjektes wird somit an den beiden Slave-Peer-Einrichtungen S1, S2 repliziert abgespeichert. Die beiden Slave-Peer-Einrichtungen S1, S2 senden eine Bestätigungsnachricht Put Acknowledge (PUT-ACK) M3 an die Master-Peer-Einrichtung M zurück, woraufhin die Master-Einrichtung M eine entsprechende Bestätigungsnachricht Put Result (PUT-RES) an die Client-Einrichtung C sendet.
Bei dem im Weiteren beschriebenen Verfahren zum Bereitstellen von Datenobjekten unter Verwendung redundanter Speicherung in Replikationsgruppen, werden die Datenressourcen, also das Datenobjekt, welches einer jeweiligen Operation, wie zum Beispiel Put oder Get unterzogen wird, zunächst typisiert. Dadurch wird eine Entscheidung, ob ein beispielsweise veränderbares oder unveränderbares Datenobjekt vorliegt möglich und eine Anpassung der Operationen beim Datenmanagement adaptiv ermöglicht. Nebenläufige Datenoperationen von atomaren Zugriffen werden daher individuell für jede Replikationsgruppe in dem Peer-to-Peer-Netzwerk vorgenommen.
Die Einbettung des Datenmanagements gemäß dem vorgeschlagenen Verfahren in ein Konzept für DHT P2P-Netzwerke ist in der 2 schematisch erläutert. Bei der weiteren Beschreibung wird davon ausgegangen, dass eine dynamische Anzahl von idealen Peer-Einrichtungen, die mit {p₁, p₂, ..., p_n} in dem Peer-to-Peer-Netzwerk vorliegen. Als Ereignisse, die einen Recast, also eine Veränderung der jeweiligen Replikationsgruppe notwendig machen, wird zur vereinfachenden Beschreibung lediglich der Ausfall oder das Hinzustoßen einer Peer-Einrichtung in bzw. zu einer Replikationsgruppe angenommen. Eine entsprechende Peer-Einrichtung kann ferner mit einem volatilen und einem nicht-volatilen Speicherbereich ausgestattet werden, so dass eine Wiederherstellungsprozedur nach einem Ausfall auf Basis der zuletzt in dem festen Speicher abgelegten Daten möglich ist.
Das vorgeschlagene Verfahren, welches auch als DhtFlex 4 bezeichnet wird, bildet das Daten- und Replikationsmanagement 1, welches auf einem schlüsselbasierten Routing-Overlay-Netzwerk 2 ansetzt. Wie bereits eingangs erläutert, kann das Overlay-Netzwerk über verschiedene Adressauflösungsmechanismen oder Protokolle wie Chord, CAN, Pastry, Tapestry oder Kademlia 5–9 verfügen. Dies ist in der 2 durch die funktionellen Blöcke 5–9 dargestellt. Als untergeordnete Kommunikationsnetzwerkstruktur dient in der Regel das Internet 3 mit implementierten TCP/IP- und UDP/IP-Protokollen 10, 11.
Bei einer auf DHTs basierten Schreib- oder Leseanfragen (Put beziehungsweise Get) OP1 wird anhand des Verfahrens zum Bereitstellen von Datenobjekten in einem Peer-to-Peer-Netzwerk, welches als Datenmanagementmodul 1 dargestellt ist, koordiniert, das heißt, es werden entsprechende Operationen wie Recast oder Bilden einer Replikationsgruppe sowie koordinierende Maßnahmen OP2, OP3, OP4 für die hierarchisch darunter liegenden Strukturen 2, 3 vorgenommen. Im Wesentlichen wird dabei auf die Funktionen, welche ein DHT-Overlay-Network bietet, zurückgegriffen. Allerdings erfolgt die Durchführung von Operationen hinsichtlich von Datenressourcen beziehungsweise Datenobjekten in dem Peer-to-Peer-Netzwerk in Abhängigkeit von einem zugeordneten Datentyp.
Dies ist in der 3 als vereinfachtes Ablaufdiagramm für ein Ausführungsbeispiel des Verfahrens zum Bereitstellen von Daten in einem entsprechenden Peer-to-Peer-Netzwerk mit DHT-Funktion dargestellt.
In einem ersten Schritt A1 erfolgt eine Typisierung des oder der betrachteten Datenobjekte. Das heißt, jedem Datenobjekt wird ein Datentyp zugeordnet. Dabei wird zwischen veränderbaren (mutable) und unveränderbaren (immutable) Daten unterschieden.
Wird in einem Folgeschritt eine Datenoperation für ein Datenobjekt angefragt (Schritt A2), erfolgt in einem Auswahlschritt A3 eine Überprüfung hinsichtlich des Datentyps.
Falls es sich um einen unveränderbaren Datentyp handelt, kann im Schritt A4 eine vereinfachte direkte Ausführung der angefragten Datenoperation, wie beispielsweise ein Lesen oder Schreiben vorgenommen werden. Insbesondere ist keine Konsistenzprüfung, zum Beispiel beim Auslesen, eines Datenobjektes mit unveränderbarem Dateninhalt erforderlich. Dies gilt ebenso, wenn gleichzeitig eine Lesedatenoperation an dieselbe Replikationsgruppe herangetragen wird. Da sich die Daten bei einem unveränderbaren Datentyp nicht zeitlich ändern, ist eine erheblich vereinfachte Bearbeitung derartiger Datenoperationen möglich.
Falls im Schritt A3 erkannt wird, dass es sich um veränderbare Daten handelt, wird eine Konsistenzprüfung im Schritt A5 durchgeführt. Die Konsistenzprüfung ist notwendig, da die Aktualität der Dateninhalte in verschiedenen Peer-Einrichtungen einer Replikationsgruppe differieren kann. Bei einer einfachen beispielhaften Konsistenzprüfung wird im Schritt A51 von der Mastereinrichtung ausgehend bei den zugeordneten Slave-Einrichtungen der jeweilige Dateninhalt abgefragt. Im Folgeschritt kann aufgrund einer Mehrheitsentscheidung A52 ermittelt werden, welcher Dateninhalt tatsächlich aktuell für das angefragte Datenobjekt korrekt ist. Es ist dabei möglich, wie es im Folgenden beschrieben wird, dass bei gleichzeitigen und nebenläufigen Anfragen, diese seriell über den Master abgewickelt werden.
In der 4 ist beispielhaft eine Replikationsgruppe bei einer Lese- beziehungsweise Get-Operation hinsichtlich eines veränderbaren Datentyps dargestellt. Die Replikationsgruppe RG umfasst die Master-Peer-Einrichtung M und zwei Slawe-Peer-Einrichtungen S1, S2. Eine Client-Einrichtung C sendet eine Leseanfrage Get Request (GET-REQ) M11 an die Master-Peer-Einrichtung M. Die Adressauflösung erfolgt nach dem jeweilig verwendeten Overlay-Protokoll.
Bei veränderbaren Datentypen ist eine Konsistenzprüfung erforderlich. Daher werden von der Master-Einrichtung M jeweils eine Get- also Lesenachricht M21 an die Slave-Einrichtungen S1 und S2 versendet. Die Slave-Einrichtungen liefern eine Bestätigungsnachricht beziehungsweise Get Acknowledge (GET-ACK) M31, woraufhin die Master-Einrichtung beurteilen kann, welcher abgespeicherte Dateninhalt als Ergebnis der Leseanfrage M11 durch den Client C angegeben werden soll. Beispielsweise kann eine Mehrheitsentscheidung als Konsistenzprüfung dienen, das heißt, es wird verglichen, ob die Dateninhalte, beziehungsweise gespeicherte, an den jeweiligen Peers vorliegenden Daten, übereinstimmen. Falls dies nicht der Fall ist, wird derjenige Dateninhalt als Ergebnis der Leseoperation verwendet, welcher von den meisten Peer-Einrichtungen M1, S1, S2 der Replikationsgruppe angegeben ist. Anschließend sendet die Master-Einrichtung M eine Nachricht Get Result (GET-RES) M41 an die anfragende Peer-Einrichtung C.
Die 5 zeigt eine Darstellung einer Replikationsgruppe bei einer Recast-Operation. In der 5 ist wiederum eine Replikationsgruppe RG mit einer Master-Peer-Einrichtung M und Slawe-Peer-Einrichtungen S1, S2, S3 dargestellt. Die Slave-Einrichtung S1 fällt dabei zum Beispiel aus, und die Slave-Einrichtung S2 tritt zu der Replikationsgruppe RG hinzu. Die Master-Einrichtung erhält einen Recast Request (RECAST-REQ) M12, was zum Beispiel periodisch durch jede Peer-Einrichtung selbst in dem Netzwerk getriggert werden kann. Weitere Aspekte der Recast-Operation sind später näher erläutert.
Der Master-Peer M sendet eine Recast-Nachricht (RECAST) M22 an die Slave-Einrichtung S2, welche der aktuellen Replikationsgruppe RG zugehörig ist. Beispielsweise über ein Publish- oder Subscribe-Mechanismus ist dem Master M auch bekannt, dass die Slave-Einrichtung S1 ausgefallen ist und S3 bereitsteht. Die Slave-Einrichtung S2 übermittelt an die Master-Einrichtung M eine Recast-Bestätigungsnachricht (RECAST-ACK) M32. Im Wesentlichen erfolgen Nachrichtenaustausche:

1) Master empfängt RECAST-ACK M32 von Slave
2) Master sendet RECAST-PROCEED M42 an Slave
3) Master empfängt RECAST-PROCEED-ACK M52 von Slave

Dabei sind Nachrichten vorgesehen, dass der Recast-Prozess abläuft (RECAST-PROCEED) M42 und entsprechende Bestätigungsnachrichten (RECAST-PROCEED-ACK) M52. Ebenso übermittelt die Master-Peer-Einrichtung M entsprechende Nachrichten M12, M62, dass eine Recast-Operation notwendig ist, beziehungsweise vollzogen wurde (Recast Result = RECAST-RES). Das heilt: Der MASTER sendet RECAST-RES an alle Slaves der neuen RECAST-Gruppe (an S2 und S3 und sich selbst)
Im Folgenden werden weitere detailliertere Aspekte des Verfahrens zum Bereitstellen von Daten durch verteiltes Speichern in einem Peer-to-Peer-Netzwerk näher erläutert. Dabei wird auf beispielhafte computerimplementierbare Algorithmen, welche beispielsweise auf einer als programmgesteuerte Einrichtung ausgestaltete Peer-Einrichtung ablaufen können, Bezug genommen. Teilalgorithmen, die als Computerprogrammprodukte oder Module oder Funktionen realisiert werden können, sind dabei in den 6–9 schematisch dargestellt.
Die betrachteten Datenressourcen oder Datenobjekte werden wie bereits zum Beispiel hinsichtlich der 3 näher erläutert, einer Typisierung unterzogen. Das heißt, dem jeweiligen Datenobjekt, wie zum Beispiel einem File oder einem Index oder einer Variablen, welche Datenstrukturen näher charakterisiert, werden Replikationsparameter zugeordnet. Atomare Operationen für veränderbare Datenobjekte werden dabei über einen, vorzugsweise den Master-Peer einer Replikationsgruppe abgewickelt. Das verwendete DHT-Overlay-Protokoll verfügt dabei über Funktionen wie Senden: ”send” zum Übertragen einer Nachricht von einem ersten Peer p₁ zu einem zweiten Peer p_j. Ebenfalls die Funktion des Empfangens: ”receive” zum Empfangen einer Nachricht durch einen Peer p_j, ist vorhanden.
Die Sende- und Empfangsfunktionen werden in der Regel durch ein Internetprotokoll bereitgestellt. Das Peer-to-Peer schlüsselbasierte Routing-Overlay stellt eine Funktion replicaSet (Key, N) bereit, welche eine schlüsselbasierte Auflösung in dem Peer-to-Peer-Overlay-Netzwerk anstößt. Das Ergebnis von replicaSet (Key, N) ist eine Anzahl von N Peer-Einrichtungen, die dem angegebenen Key (= Schlüssel) am nächsten kommt, wobei die Peers in einer aufsteigenden Sequenz angegeben werden. Beispielsweise liefert replicaSet (Key, 1) im Rahmen eines Chord-Protokolls den direkten Folge-Peer hinsichtlich eines Identifikators, welcher durch Key vorgegeben ist.
Den Datenressourcen beziehungsweise Datenobjekten können eine oder mehrere der im Folgenden angegebenen Replikationsparameter zugeordnet werden:
id bezeichnet den Schlüssel, durch den eine Datenressource oder ein Datenobjekt eindeutig in dem Peer-to-Peer-Overlay-Network identifiziert werden kann. Es kann zum Beispiel die UUID sein.
type_id ist zum Beispiel ein Merker, der den Datentyp der jeweiligen Datenressource festlegt. Dabei sind die Werte ”immutable” für nicht veränderbare Daten und ”mutable” für veränderbare Daten in atomaren Put- oder Get-Operationen benannt. Der Merker kann ebenfalls ”freezed” sein, um einen ablaufenden Recast-Prozess anzuzeigen.
seqNr_id: dieser Zähler, welcher größer 0 ist, zeigt die Anzahl der zuletzt erfolgreich durchgeführten Put-Operationen an und wird auf 0 initialisiert.
seqNr*_id ist eine Zählervariable größer 0, welche die Anzahl der zuletzt versuchten atomaren Schreib-Anfragen hinsichtlich einer Master-Peer-Einrichtung (welche mit replicaMaster_id festgelegt ist (s. u.)) bezeichnet. Diese Variable wird zu 0 initialisiert.
value_id zeigt den aktuellen Dateninhalt eines Datenobjektes an. value_id entspricht jeweils einer bestimmten SeqNr_id.
replicaSize_id bestimmt den Replikationsfaktor für eine Ressource. Beispielsweise kann diese anfänglich zu 4 gesetzt werden.
replicasNF_id: ist eine Zählervariable größer 0 um die aktuelle Replikationsgruppe einer Datenressource zu bezeichnen.
replicaMaster_id ist eine Replikation eines aktuell möglichen Peers als Master-Peer-Einrichtung für eine Datenressource.
replicas_id liefert eine geordnete Gruppe oder einen Satz von Peer-Einrichtungen, die die aktuelle Replikationsgruppe für die Datenressource darstellen. Der erste durch die replicas_id angezeigte Peer ist in der Regel der Master-Peer also replicaMaster_id.
replicasNr*_id ist eine Backup-Zählvariable, welche die Replikationsgruppe identifiziert, welche einem Recast-Prozess unterzogen werden muss.
replicas*_id liefert einen Satz von Peer-Einrichtungen, die replicasNr*_id entsprechen und eine Replikationsgruppe für veränderbare Datenobjekte bilden.
recastNr_id ist eine Zählvariable, welche Vorschläge für derzeit stattfindende Recast-Operationen anzeigt.
replicas**_id zeigt einen Satz von Peer-Einrichtungen an, welche eine mögliche neue Replikationsgruppe in einem Recast-Prozess für veränderbare Ressourcen darstellen.
recastNr^α _id ist die höchste empfangene Recast-Nummer einer Recast-Nachricht.
recastNr^β _id ist die zuletzt akzeptierte Vorschlagsnummer in einer Schreibphase des Paxos-Algorithmus. Dies entspricht der höchsten empfangenen Recast-Nummer einer Recast-Proceed-Message.
recastReplicas_id entspricht der zuletzt akzeptierten recastNr*_id und zeigt den akzeptierten Vorschlagswert, also die potenzielle neue Replikationsgruppe für eine veränderliche Datenressource an.
Durch die Replikationsparameter und insbesondere die Angabe des Datentyps zu jeder Datenressource, welche in dem DHT-Overlay-Netzwerk verteilt gespeichert werden soll, können flexible Datenoperationen hinsichtlich veränderbarer und unveränderbarer Datenobjekte erzielt werden. Die zuletzt erfolgreich geschriebene value_id wird durch ein Inkrementieren der seqNr_id indiziert. Der Replikationsfaktor replicaSize_id zeigt an, wie häufig der Dateninhalt eines Datenobjektes redundant gespeichert wird. In dem Satz von Peer-Einrichtungen, welcher durch replicas_id festgelegt wird, kann bei Operationen an veränderbaren beziehungsweise mutable Datenobjekten zum Beispiel der Master-Peer replicaMaster_id Serialisierung der Operationen vornehmen. Üblicherweise wird durch den Schlüssel key die replicaMaster_id aufgelöst. Um insbesondere bei veränderbaren Daten eine strikte Konsistenz der abgelegten Inhalte zu gewährleisten, wird der geordnete Satz von Peer-Einrichtungen, die die Replikationsgruppe bilden replicas_id konsistent gehalten. Verändert sich die Zusammensetzung einer Replikationsgruppe, wird replicasNr_id hoch gezählt.
In der 6 ist ein beispielhafter Ausschnitt eines Algorithmus zur Implementierung einer Trigger-Funktion für einen Recast dargestellt. Beispielsweise wird die Prozedur CheckReplicas(id), die in der 6 angedeutet ist, periodisch durch jeden Peer einer Replikationsgruppe durchgeführt.
In der Zeile 2 werden diejenigen Peer-Einrichtungen berücksichtigt, welche hinsichtlich der Identifikation id der Datenressource in dem Peer-to-Peer-Overlay-Netzwerk am nächsten liegen. Für unveränderbare Datentypen ist lediglich eine einfache Put-Operation (Schreiboperation) notwendig, um eine Kopie der vorliegenden Dateninhalte anderen Peer-Einrichtungen der Replikationsgruppe anzuzeigen. Dies ist in der Zeile 4 dargestellt.
Für veränderbare Datenobjekte kann beispielsweise auf einen Paxos-ähnlichen Algorithmus zurückgegriffen werden, der konsistent eine neue Replikationsgruppenzusammensetzung bestimmt. Insofern ist in der Zeile 8 angedeutet, dass der aktuelle Peer die Master-Peer-Einrichtung für eine potenzielle neu zusammengesetzte Replikationsgruppe informiert und somit einen Recast-Prozess beginnt. Der mit nextReplicas.replicaMaster bezeichnete Peer ist üblicherweise der für die id Zuständige.
Der Recast-Prozess für die Replikationsgruppe ist bei veränderbaren Datenressourcen notwendig. Es kann dabei ein wie in der 7 dargestellter Recast-Algorithmus gestartet werden. In Zeile 1 des in der 7 dargestellten Algorithmus wird ein möglicher Master für eine neue Replikationsgruppenzusammensetzung mit den notwendigen Informationen über die alten und neuen Replikations-Peer-Einrichtungen versorgt. Dieser Master führt ein Backup durch und startet den Recast mit einer wohl definierten Vorschlagsnummer. Ein dem Paxos-Algorithmus ähnliches Vorgehen wird dann durchgeführt. Die Merker-Variable recasting zeigt einen vorliegenden und ablaufenden Recast-Prozess an, damit nötige parallel ablaufende Prozesse ausgeschlossen werden können. Somit wird die benötigte Rechenkapazität sowie der Versand von Nachrichten reduziert.
recasting wird üblicherweise zeitgesteuert zurückgesetzt, so dass der entsprechende Master den Vorgang mit einer höheren Voranschlagsnummer wieder versuchen kann. Im Ergebnis des Prozesses sollen die alten Peer-Einrichtungen eine Übereinstimmung über eine neue Komposition der Replikationsgruppe erzielen. Eine Mehrheitsentscheidung oder ein Quorum kann zum Beispiel durch eine einfache Mehrheit erzielt werden. Eine Recast-Nachricht (RECAST) startet dann eine Lesephase im Rahmen eines Paxos-Algorithmusses. Die Nachricht RECAST-PROCEED startet dann eine Schreibphase. In einer Lesephase erhält der Master Informationen über die zuvor akzeptierten Sätze von Peers der Replikationsgruppen. Sobald eine Peer-Einrichtung eine Recast-Nachricht erhält, setzt sie die type_id der entsprechenden Datenressource auf ”freezed”, so dass keine weiteren Put- oder Get-Operationen ausgeführt werden. Dies ist in der Zeile 14 angedeutet.
Der Einfachheit halber ist im Algorithmus 2 der Versand von NACK-Nachrichten, also eine Nachricht, die einen Fehler beziehungsweise eine Nichtbestätigung andeutet, nicht vorgesehen.
Sobald ein Master gemäß Zeile 20 eine Mehrheitsentscheidung beziehungsweise ein Quorum erzielt, wird die Schreibphase eingeleitet. Dies schließt damit, dass in der Zeile 39 der Master die neue Replikationsgruppe betreut und den zuletzt erfolgreich geschriebenen Datenwert erhält.
Um die benötigte Übertragungsbandbreite in dem zugrunde gelegten Kommunikationsnetzwerk zu reduzieren, sendet eine Peer-Einrichtung einer Replikationsgruppe nur dann den tatsächlichen Dateninhalt, falls dies auch relevant ist. Dies ergibt sich aus der Zeile 32 in der 7. Sobald der Master während der Schreibphase (Zeile 42) ein Quorum erzielt, werden die erhaltenen Resultate weitergeleitet, so dass die neue Replikationsgruppe in der Zeile 55 starten kann.
In der 8 ist ein beispielhafter Algorithmus zur Implementierung einer Put- also einer Schreiboperation für einen Peer p₁ dargestellt. Dabei werden die Funktionen max(v₁, v₂) verwendet, welche den Maximalwert zwischen den Werten v₁ und v₂ liefert und die Funktion δ(v), welche den Digest-Wert von v ausgibt.
Gemäß Zeile 1 überträgt eine Peer-Einrichtung ihren gespeicherten Dateninhalt und eine variable policy an den zuständigen Peer in dem Peer-to-Peer-Overlay-Netzwerk. Die Variable poliCy legt mindestens einen Replikationsfaktor policy.replicaSize und einen Datentyp policy.type fest. Diese Variablen können dynamisch während des Betriebs des Peer-to-Peer-Netzwerkes spezifiziert werden.
In Zeile 2 berechnet die Master-Einrichtung die Replikationsgruppe und verteilt Kopien zusammen mit entsprechenden notwendigen Replikationsinformationen (Zeile 7). Für den einfachen Fall, dass unveränderbare Datenobjekte betroffen sind, speichert jede Peer-Einrichtung der Replikationsgruppe den entsprechenden Dateninhalt (Zeile 19). Schließlich wird die Peer-Einrichtung p_j darüber informiert, welcher Wert erfolgreich publiziert wurde, indem der Digest-Wert zurück gesendet wird.
Falls allerdings eine änderbare Datenressource erkannt wird, müssen zusätzliche Konsistenzüberprüfungen stattfinden. Dann initialisiert die Master-Peer-Einrichtung die neue Ressource mit ihrem Wert und startet einen Recast-Prozess, um die notwendige Replikationsgruppe zusammenzustellen (Zeile 10).
Für eine normale Put- beziehungsweise Schreib-Operation (siehe Zeile 12) überprüft der betroffene Peer, ob er der Master der entsprechenden Replikationsgruppe ist. Falls dies nicht der Fall ist, wird die Schreibanfrage (PUT-REQ) an die replicaMaster_id weitergeleitet. Der entsprechende Master verteilt dann den neuen Dateninhalt beziehungsweise Wert value an die übrigen der Replikationsgruppe zugehörigen Peer-Einrichtungen (Zeile 15). Es ergibt sich somit, dass alle Schreibanfragen durch die Master-Einrichtung serialisiert werden.
Falls eine Peer-Einrichtung eine Schreibanfrage beziehungsweise Schreibnachricht erhält (Zeile 23), wird verifiziert, dass der dem Datenobjekt zugehörige Datentyp veränderbar ist und dass der Master-Peer nach wie vor gültig ist (Zeile 25). Für jede replicasNr_id existiert ein eindeutiger Master. Eine der Replikationsgruppe zugehörige Peer-Einrichtung akzeptiert nur dann die erhaltenen Dateninhalte, falls diese neuer sind als die lokal vorliegenden Dateninhalte (Zeile 27). Dadurch wird verhindert, dass ein aktuellerer Wert mit älteren upgedatet wird. Es können ferner Nachrichten generiert werden, die eine Nichtbestätigung anzeigen (NACK), um zu verhindern, dass ein veralteter Master arbeitet.
Ein Master-Peer aktualisiert seine value_id, falls ein Quorum der zugeordneten Slave-Peer-Einrichtungen für eine bestimmte seqNr (Zeile 35) erhalten wird. Wiederum wird in Zeile 36 verhindert, dass veraltete Daten für eine Aktualisierung zugrunde gelegt werden. Sobald der neue Wert erfolgreich in der Replikationsgruppe abgelegt wurde, wird der den Schreibvorgang anfragende Peer durch PUT-RES benachrichtigt (Zeile 39).
Schließlich ist in der 9 ein beispielhafter Algorithmus zur Implementierung einer Lese- beziehungsweise Get-Operation dargestellt. Eine eine Leseanfrage sendende Instanz oder auch Peer-Einrichtung sendet eine entsprechende Anfrage an den zuständigen Peer, welcher durch replicaSet(id, 1) festgelegt ist.
Falls es sich bei der angefragten Datenressource beziehungsweise dem angefragten Datenobjekt um einen nicht veränderbaren Datentyp handelt, kann die Anfrage sofort in Zeile 2 beantwortet werden.
Falls es sich bei der Anfrage um eine veränderbare Datenressource handelt, bestätigt die betroffene Peer-Einrichtung ihre Zuständigkeit und sendet Get-Nachrichten an die Peer-Einrichtungen seiner Replikatiansgruppe um festzustellen, ob die Replikationsgruppe nach wie vor zuständig ist (Zeile 7). Um einen veralteten Master zu stoppen, werden optional die Peer-Einrichtungen, welche Leseanfragen erhalten, eine NACK-Nachricht versenden. Da der zuständige Master jeweils den letzten Wert der angefragten Datenressource kennt, ist es nicht notwendig, dass die Slave-Peer-Einrichtungen der Replikationsgruppe die abgespeicherten Dateninhalte beziehungsweise Werte an den Master übertragen. Sofern das angefragte Datenobjekt nicht festgesetzt ist (freezed), da zum Beispiel eine Recast-Operation durchgeführt wird (Zeile 13) und der Master ein Quorum aus positiven Antworten seiner Slave-Peer-Einrichtungen erhält (Zeile 16), wird der anfragenden Instanz der Dateninhalt beziehungsweise Wert korrekt übermittelt (Zeile 17).
Die vorgeschlagenen und beschriebenen Aspekte für ein Verfahren zum Bereitstellen von Daten in Peer-to-Peer-Netzwerken, die insbesondere auf DHT-verteilter Speicherung beruhen, ermöglichen zuverlässig und aufwandsgünstig eine sichere Speicherung von Datenobjekten. Es wird immer der bis zuletzt konsistent geschriebene Dateninhalt eines Datenobjekts bereitgestellt. Atomare Schreib- und Lese-Operationen werden aufwandsgünstig durch eine Master-Peer-Einrichtung in einer Replikationsgruppe serialisiert. Insbesondere die Unterscheidung und unterschiedliche Behandlung von verschiedenen Datentypen, wie veränderbar und nicht veränderbar, liefert eine Einsparung von zu versendenden Nachrichten bei Datenoperationen und erhöht die Geschwindigkeit bei Zugriffen.

Claims

Verfahren zum Bereitstellen von Datenobjekten in einem Peer-to-Peer-Netzwerk (P2P), welches mehrere Peer-Einrichtungen (P, S1, S2, M) aufweist, wobei mindestens ein Datenobjekt redundant in Peer-Einrichtungen (M, S1, S2), welche einer Replikationsgruppe (RG) zugeordnet sind, gespeichert werden, wobei das Datenobjekt in einen von mindestens zwei Datentypen typisiert wird, bei einer Datenoperation für das gespeicherte Datenobjekt eine Überprüfung des Datentyps erfolgt, wobei eine Typisierung in veränderbare und nichtveränderbare Datenobjekte als Datentypen erfolgt, und in Abhängigkeit von dem jeweiligen Datentyp bei der Datenoperation für das gespeicherte Datenobjekt in einer Replikationsgruppe (RG) eine Konsistenzüberprüfung erfolgt oder das Datenobjekt direkt der Datenoperation unterzogen wird, wobei für die nichtveränderbaren Datenobjekte keine Konsistenzprüfung bei der Datenoperation erfolgt.
Verfahren nach Anspruch 1, wobei jedem Datenobjekt ein Datentyp zugeordnet wird.
Verfahren nach einem der Ansprüche 1–2, wobei zum redundanten Speichern der Dateninhalt des Datenobjektes an verschiedenen Peer-Einrichtungen (S1, S2, M) der Replikationsgruppe (RG) abgespeichert wird.
Verfahren nach einem der Ansprüche 1–3, wobei eine jeweilige Peer-Einrichtung (M, S1, S2) zu vorgebbaren Zeitpunkten überprüft, ob in Abhängigkeit von dem Datentyp des gespeicherten Datenobjektes eine Recast-Operation für ein konsistentes redundantes Speichern notwendig ist.
Verfahren nach einem der Ansprüche 1–4, wobei eine Peer-Einrichtung (S1, 52, M) einer jeweiligen Replikationsgruppe als Master-Peer-Einrichtung (M) festgelegt wird, welcher die übrigen Peer-Einrichtungen (S1, S2) als Slave-Peer-Einrichtungen zugeordnet sind.
Verfahren nach Anspruch 5, wobei gleichzeitige Datenoperationen an dem Datenobjekt an verschiedenen Peer-Einrichtungen (S1, S2, M) der Replikationsgruppe (RG), welche den Dateninhalt des Datenobjektes abspeichern, durch die Master-Peer-Einrichtung (M) sequenziell abgearbeitet werden.
Verfahren nach einem der Ansprüche 1–6, wobei die Replikationsgruppe (RG) von einem Satz geordneter Peer-Einrichtungen (M, S1, S2) gebildet wird.
Verfahren nach einem der Ansprüche 1–7, wobei einem jeweiligen Datenobjekt mindestens ein weiterer Replikationsparameter zugeordnet wird.
Verfahren nach Anspruch 8, wobei der Replikationsparameter eine Identifikation des Datenobjektes in dem Peer-to-Peer-Netzwerk, eine Zählvariable (seqNrid) für erfolgreich erfolgte Schreibzugriffe, eine Zählvariable (seqNr*id) für versuchte atomare Schreibzugriffe, einen Dateninhalt (valueid) des Datenobjektes, einen Replikationsfaktor (replicaSizeid), eine Identifikation (replicasNrid) der Replikationsgruppe, eine Identifikation einer Master-Peer-Einrichtung (replicaMasterid) oder einen Satz von Peer-Einrichtungen, welche die Replikationsgruppe bilden (replicasid) umfasst.
Verfahren nach einem Ansprüche 1–9, wobei zur Gewährleistung der Konsistenz der abgespeicherten Dateninhalte des Datenobjekts eine Übereinstimmung von Datenspeicherungszuständen der durch die Peer-Einrichtungen (S1, S2, M) einer Replikationsgruppe (RG) gespeicherten Dateninhalte verwendet wird.
Verfahren nach einem der Ansprüche 1–10, wobei die unveränderbaren Datentypen Mediadaten, insbesondere Audio-, Video-, oder Textdateien, Konfigurationsdaten, Versionen oder umfassen.
Verfahren nach einem der Ansprüche 1–11, wobei die veränderbaren Datentypen Indizierungsdaten oder Messdaten umfassen.
Verfahren nach einem der Ansprüche 7–12, wobei für unveränderbare Datentypen in einer Replikationsgruppe (RG) eine Recast-Operation durch Schreiben des Datenobjektes an eine jeweilige Folge-Peer-Einrichtung (S1, S2, M) in dem Satz geordneter Peer-Einrichtungen erfolgt.
Verfahren nach einem der Ansprüche 1–13, wobei eine Zuordnung von Peer-Einrichtungen (S1, S2, M) zu einer Replikationsgruppe (RG) nach einem Paxos-Algorithmus erfolgt.
Verfahren nach einem der Ansprüche 1–14, wobei die Konsistenzprüfung mittels eines ETNA-Algorithmus erfolgt.
Programmgesteuerte Peer-Einrichtung (M, S1, S2), welche derart eingerichtet ist, dass ein Verfahren nach einem der Ansprüche 1–15 durchgeführt wird.
Netzwerkanordnung (P2P) mit mehreren programmgesteuerten Peer-Einrichtungen (P, M, S1, S2), welche über ein Kommunikationsnetzwerk (IN) Nachrichten austauschen, wobei die Peer-Einrichtungen (P, M, S1, S2) derart eingerichtet sind, dass ein Verfahren nach einem der Ansprüche 1–15 durchgeführt wird.
Computerprogrammprodukt, welches die Durchführung eines Verfahrens nach einem der Ansprüche 1–15 auf mehreren programmgesteuerten Rechnereinrichtungen (P, M, S1, S2), veranlasst.