-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft Computernetze und insbesondere ein
System und ein Verfahren zum Beantworten einer Ressourcenanforderung
in einem verteilten Computernetz.
-
Grundlagen
der Erfindung
-
Computernetze
wie beispielsweise das Internet ermöglichen Benutzern die gemeinsame
Nutzung von Ressourcen, zum Beispiel Dateien und Hardware. Die Ausdehnung
des Internet und die Übernahme
von Standards für
das World Wide Web haben ein nahezu müheloses Anschauen und Herunterladen von
Dateien durch einen Benutzer möglich
gemacht. Der Benutzer muss keinerlei Programmiersprachen kennen.
Durch einfaches Ausführen
eines Internet-Browser muss der Benutzer zum Anschauen und Herunterladen
gewünschter
Dateien lediglich auf diese zeigen und sie anklicken. Die Verfügbarkeit
solcher Programme ermöglicht
eine problemlose Zusammenarbeit und eine gemeinsame Nutzung von Dateien
zwischen gleich gesinnten Personen, die durch große Entfernungen
voneinander getrennt sind, über
ein verteiltes Computernetz, das buchstäblich den gesamten Globus umspannen
kann.
-
Herkömmlicherweise
wird ein verteiltes Computernetz mit einem Client/Server-Gerüst eingerichtet.
Insbesondere ist jeder Benutzer ein Client, der über das Netz auf einen Serverknoten
zugreifen kann und mit der ordnungsgemäßen Berechtigung Dateien im
Serverknoten veröffentlichen
kann. Sobald eine Datei im Serverknoten veröffentlicht worden ist, können andere
Clients im Netz auf den Serverknoten zugreifen, um die Datei anzuschauen
oder herunterzuladen. Außerdem
kann der Serverknoten einem Client das automatische Übertragen
einer Datei an einen anderen über
das Netz erreichbaren Client ermöglichen.
Der Client überträgt die Datei
einfach zusammen mit Daten, die den gewünschten Empfänger kennzeichnen,
an den Serverknoten, und der Serverknoten leitet die Datei weiter
an den entsprechenden Client. Außerdem kann der Serverknoten
verwendet werden, um den Clients die gemeinsame Nutzung von Hardwareressourcen,
beispielsweise eines Druckers, zu ermöglichen.
-
Bei
einem solchen Client/Server-Gerüst
ist der Serverknoten für
die Bereitstellung von Sicherheitsvorkehrungen verantwortlich. Beispielsweise muss
der Serverknoten sicherstellen, dass nur berechtigte Clients die
Netzressourcen (z.B. Dateien herunterzuladen) verwenden können und
nur einwandfreie Dateien veröffentlicht
werden. Außerdem stellt
der Serverknoten eine einzelne Fehlerstelle (single point of failure)
dar. Folglich muss der Serverknoten in jeder Client/Server-Umgebung,
in der Zuverlässigkeit
erforderlich ist, Industriestärke
bereitstellen und redundante Systeme aufweisen, um das Herunterfahren
des Systems und Datenverlust zu verhindern. Da alle Ressourcenübertragungen
von Client zu Client über
den Serverknoten laufen, stellt das Hinzufügen eines weiteren Client zum
Netz außerdem
eine zusätzliche
Belastung für
den Serverknoten dar und verschlechtert die Netzleistung.
-
In
einem solchen Client/Server-Gerüst
besteht für
die Clients wenig Datenschutz. Normalerweise verlangt der Serverknoten
eine Berechtigungsüberprüfung, bevor
er einem Client den Zugriff auf Netzressourcen ermöglicht.
Sobald der Client Berechtigungsnachweise (authentication credentials) bereitgestellt
hat, kann der Serverknoten alle Netzaktivitäten des Client problemlos protokollieren.
Beispielsweise könnte
der Serverknoten ein Protokoll aller vom Client hoch- und heruntergeladenen
Dateien aufbewahren. Selbst wenn der Zugriff durch unberechtigte
Clients gestattet ist, kann der Serverknoten ein beliebiges von
verschiedenen eindeutigen Identifizierungsverfahren verwenden, um
die Clientaktivität im
Lauf der Zeit zu verfolgen. Beispielsweise kann der Serverknoten
ein eindeutiges Cookie im Client platzieren und dieses zu einem
späteren
Zeitpunkt bei jedem Zugriff des Client auf den Serverknoten zum
Identifizieren des Client verwenden.
-
Eine
Lösung
für einige
der Nachteile des herkömmlichen
Client/Server-Gerüstes
wird von einem „viralen" Netz bereitgestellt.
In einem solchen Netz ist ein Benutzerknoten mit einem oder mehreren
bekannten Hosts verbunden, die an einem virtuellen Netz mit hoher
Verbindungsdichte beteiligt sind. Anschließend wird der Benutzerknoten
selbst ein Hostknoten, der Anforderungen nach Ressourcen und verfügbaren Rosts
beantworten kann. Jeder Benutzer im Netz leitet Ressourcenanforderungen
an alle bekannten benachbarten Knoten weiter, so dass jede Anforderung
möglicherweise
durch das gesamte Netz geleitet wird. Beispielsweise verwendet das System
Gnutella ein solches Gerüst
eines viralen Netzes. Gnutella hat ein veröffentlichtes Netzprotokoll
und stellt Benutzern eine Client/Server-Anwendung bereit (erhältlich unter
http://gnutella.wego.com), die es jedem Benutzer ermöglicht,
in einem Netz mit gemeinsamer Dateinutzung als Hostknoten zu agieren.
Das System Gnutella kann zum sicheren Verteilen von kommerziellen
Inhalten verwendet werden, die durch Verschlüsselung und Lizenzvergabe (licensing)
geschützt
sind.
-
Virale
Netze beruhen auf einer nichthierarchischen Datenübertragung
(peer-to-peer communication). In diesem nichthierarchischen Datenübertragungsmodell
hat jeder Teilnehmer ähnliche
Fähigkeiten
und kann eine Datenaustauschsitzung einleiten. Beispielsweise verwendet
die Gnutella-Anwendung einen nichthierarchischen Datenaustausch,
um Benutzern das Austauschen von Dateien untereinander über das
Internet zu ermöglichen.
Das in einem viralen Netz verwendete nichthierarchische Modell beruht
darauf, dass jeder Partner (d.h. Benutzerknoten) Kenntnis von mindestens
einem der anderen Partner im Netz hat. Wenn nach einer Ressource
wie beispielsweise einer Datei gesucht wird, überträgt ein Partner eine Ressourcenanforderung
an andere bekannte Partner, die diese ihrerseits an ihre bekannten Partner
weiterleiten und so weiter, um die Anforderung durch das Netz zu
leiten. Ein Partner, der über die
Ressource verfügt
und die Anforderung empfängt,
kann die Ressource (oder eine Nachricht, die deren Verfügbarkeit
anzeigt) an den anfordernden Partner rückübertragen. Da ein solches Gerüst Unabhängigkeit
von einer zentralen Netzautorität
(network authority) (z.B. einem Serverknoten) bietet, haben Benutzer
in einem viralen Netz einen besseren Datenschutz, und die einzelne
Fehlerstelle fällt
weg.
-
1 zeigt
ein beispielhaftes virales Netz. Jeder Knoten im Netz stellt einen
Benutzer dar, der sowohl als Client als auch als Host agiert, und
ist mit einem oder mehreren anderen Knoten verbunden. Wenn ein erster
Knoten 210 eine bestimmte Ressource (z.B. eine Datei) wünscht, gibt
er eine Anforderung an alle bekannten Knoten 202, 204, 206 und 208 aus,
die ihrerseits das gleiche tun. Beispielsweise erreicht die Anforderung
einen zweiten Knoten 212, indem sie nacheinander durch
die Knoten 208, 216 und 218 geleitet
worden ist. Falls der zweite Knoten 212 die anforderte
Ressource hat, antwortet er durch das Übertragen einer entsprechenden
Nachricht an den ersten Knoten 210 (z.B. zurück über denselben
Pfad, über
den die Anforderung geleitet wurde). Da ein Knoten identifiziert
wurde, der über
die anforderte Ressource verfügt,
kann der erste Knoten 210 eine direkte nichthierarchische
Verbindung mit dem zweiten Knoten 212 einleiten, um die
Ressource herunterzuladen. Im gesamten viralen Netz kann eine beliebige
Anzahl solcher Ressourcenanforderungen, Bestätigungen und Übertragungen
gleichzeitig erfolgen.
-
Obwohl
virale Netze einen besseren Datenschutz bieten und eine einzelne
Fehlerstelle wegfällt, hat
das Gerüst
Nachteile in Bezug auf die Verfügbarkeit.
In einem großen
dezentralisierten viralen Netz wird ein leistungsfähiges Ausfindigmachen
von Ressourcen unmöglich,
wenn die Anzahl von teilnehmenden Knoten steigt. Insbesondere kann
eine Ressourcenanforderung nur von Knoten zu Knoten geleitet werden,
und jeder Knoten leitet die Anforderung lediglich an eine verhältnismäßig geringe
Anzahl anderer Knoten weiter. Zur Steuerung des Netzverkehrs und
zur Verhinderung von unmäßigen Antwortzeiten
muss ein praktisches System eine „Lebensdauer" („time-to-live") oder eine Begrenzung
der Anzahl von Malen, die eine Anforderung weitergeleitet werden
kann (d.h. eine maximale Anzahl von Partnersprüngen), verwenden. Dies unterbricht
in der Tat die Verbindung zweier beliebiger Knoten oder Gruppen
von Knoten, die durch einen Pfad getrennt sind, der es erforderlich
machen würde,
dass eine Anforderung durch eine unverhältnismäßig hohe Anzahl von Zwischenknoten
geleitet würde.
Außerdem macht
jede solche Begrenzung der Anforderungsweiterleitung es unmöglich, eine
erschöpfende
Suche nach einer Ressource auszuführen, da eine solche Suche
die Weiterleitung der Anforderung an alle Knoten im Netz erforderlich
machen würde.
-
Außerdem wurde
vor kurzem eine inhaltsbasierte Publish/Subscribe-Infrastruktur
zur Nachrichtenübermittlung
(publish-subscribe messaging infrastructure) vorgeschlagen, die
einen Datenflussgraphen (information flow graph) verwendet. Beispielsweise
wurde das System Gryphon (unter http://www.research.ibm.com/gryphon
beschrieben) vom Anmelder der vorliegenden Erfindung entwickelt.
Dieses System stellt einen inhaltsbasierten Subskriptionsdienst
(subscription service) bereit und führt eine Nachrichtenverteilung
(message brokering) aus, indem die Merkmale von verteilten Publish/Subscribe-Datenübertragungen
und Datenbanktechnologie vermischt werden. Im Kern des Gryphon-Systems
befindet sich ein Datenflussgraph, der die selektive Lieferung von
Ereignissen, die Umformung von Ereignissen und die Erzeugung neuer
Ereignisse angibt.
-
2 zeigt
eine beispielhafte inhaltsbasierte Publish/Subscribe-Infrastruktur
zur Nachrichtenübermittlung,
die Datenflussgraphen verwendet. In diesem System werden aus zwei
Datenquellen NYSE und NASDAQ abgeleitete Aktienhandelsgeschäfte verknüpft, umgeformt,
gefiltert und teilnehmenden Clients zugestellt. Beispielsweise kann
ein Benutzer 312 am Nachrichtenverteilungs-Server 302 teilnehmen
und den Empfang aller Aktienhandelsgeschäfte sowohl der NYSE als auch
der NASDAQ anfordern, die einen Wert von über einer Million Dollar haben. Der
Nachrichtenverteiler 302 empfängt unbearbeitete Daten zum
Aktienhandel, beispielsweise Preis und Menge, von der NYSE 324 und
der NASDAQ 326.
-
Aufgrund
der Datenanforderung des Benutzers 312 mischt der Server 302 die
Aktienhandelsdaten aus den beiden Quellen, formt die unbearbeiteten Preis-
und Mengendaten in Wertedaten für
jedes Handelsgeschäft
um und filtert anschließend
die abgeleiteten Werte, um die Teilmenge von Handelsgeschäften zu
erzeugen, die einen Wert von über
einer Million Dollar haben. Auf ähnliche
Weise gibt jeder teilnehmende Benutzer (z.B. die Knoten 304, 306 und 308)
seine eigenen Kriterien an, und der Nachrichtenverteilungs- Server 302 führt die
Datenauswahl, -filterung und -zustellung aus, um jeden Benutzer
mit den angeforderten Daten zu versehen.
-
Obwohl
die Publish/Subscribe-Infrastruktur zur Nachrichtenübermittlung
von 2 eine gute Skalierbarkeit für ein Nachrichtenübermittlungssystem
mit einer großen
Anzahl von Benutzern bereitstellt, haben die Benutzer wie im herkömmlichen
Client/Server-Gerüst
wenig Datenschutz. Alle Benutzer müssen sich identifizieren, wenn
sie am System teilnehmen, und alle Daten werden dem Benutzer durch den
zentralen Server zugestellt. Folglich kann der zentrale Server problemlos
ein Protokoll aller Benutzer des Systems und der genauen Daten verwalten, die
jeder wünscht
und empfängt.
Der zentrale Nachrichtenverteilungs-Server stellt ebenfalls eine
einzelne Fehlerstelle für
das System dar.
-
BESCHREIBUNG
DER ERFINDUNG
-
Eine
Ausführungsform
der vorliegenden Erfindung stellt ein Verfahren zum Beantworten
einer Ressourcenanforderung von einem anfordernden Benutzerknoten
in einem Netz von Benutzerknoten bereit. Gemäß dem Verfahren wird eine Antwort
auf die Ressourcenanforderung in einem ersten Benutzerknoten des
Netzes empfangen, und als willkürliche,
von einem ersten Benutzerknoten getroffene Entscheidung wird festgelegt,
ob die Antwort an den anfordernden Benutzerknoten rückübertragen
wird. Wenn festgelegt wird, die Antwort nicht an den anfordernden
Benutzerknoten rückzuübertragen,
wird sie über
eine direkte Verbindung an einen zweiten Benutzerknoten des Netzes
weitergeleitet. Wenn festgelegt wird, die Antwort an den anfordernden
Benutzerknoten rückzuübertragen,
wird sie an diesen rückübertragen.
-
Eine
andere Ausführungsform
der vorliegenden Erfindung stellt einen Benutzerknoten zur Verwendung
in einem Computernetz des Typs bereit, der Benutzerknoten beinhaltet,
die über
eine direkte Verbindung jeweils mit mindestens einem anderen Benutzerknoten
verbunden sind. Der Benutzerknoten enthält eine Empfangsschnittstelle
zum Empfangen einer Antwort auf eine Ressourcenanforderung von einem
anfordernden Benutzerknoten, ein Steuermittel zum willkürlichen
Entscheiden, ob die Antwort an den anfordernden Benutzerknoten rückübertragen wird,
und mindestens eine Übertragungsschnittstelle zum
selektiven Weiterleiten der Antwort an einen zweiten Benutzerknoten
des Netzes über
eine direkte Verbindung oder zum Rückübertragen der Antwort an den
anfordernden Benutzerknoten. Die Übertragungsschnittstelle leitet
die Antwort an den zweiten Benutzerknoten weiter, wenn das Steuermittel
entscheidet, diese nicht an den anfordernden Knoten rückzuübertragen,
und rücküberträgt die Antwort
an den anfordernden Benutzerknoten, wenn das Steuermittel diese
Entscheidung trifft. In einer bevorzugten Ausführungsform wählt das
Steuermittel willkürlich einen
der anderen Benutzerknoten des Netzes als den zweiten Benutzerknoten
aus, an den die Antwort weitergeleitet wird.
-
Außerdem stellt
die Erfindung ein maschinenlesbares Medium nach Anspruch 8 bereit.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Nun
wird die Erfindung lediglich beispielhaft mit Bezugnahme auf die
begleitenden Zeichnungen beschrieben, in denen:
-
1 eine
Darstellung eines beispielhaften viralen Netzes ist;
-
2 eine
Darstellung einer beispielhaften inhaltsbasierten Publish/Subscribe-Infrastruktur
zur Nachrichtenübermittlung
ist;
-
3 eine
Darstellung eines skalierbaren Netzgerüstes gemäß einer bevorzugten Ausführungsform
der vorliegenden Erfindung ist;
-
4 ein
Flussdiagramm eines Prozesses zum Erhalten einer Ressource in einem
skalierbaren Netzgerüst
gemäß einer
ersten Ausführungsform
der vorliegenden Erfindung ist;
-
5 ein
Flussdiagramm eines Prozesses zum Erhalten einer Ressource in einem
skalierbaren Netzgerüst
gemäß einer
zweiten Ausführungsform der
vorliegenden Erfindung ist;
-
6 ein
Flussdiagramm eines Prozesses zum Erhalten einer Ressource in einem
skalierbaren Netzgerüst
gemäß einer
dritten Ausführungsform
der vorliegenden Erfindung ist;
-
7 eine
Darstellung eines skalierbaren Netzgerüstes ist, das eine beispielhafte
Ausführung eines
Teils des Prozesses von 6 zeigt;
-
8 eine
Darstellung eines skalierbaren Netzgerüstes ist, das eine beispielhafte
Ausführung eines
anderen Teils des Prozesses von 6 zeigt;
-
9 ein
Flussdiagramm eines Prozesses zum Bereitstellen einer angeforderten
Ressource in einem skalierbaren Netzgerüst gemäß einer vierten Ausführungsform
der vorliegenden Erfindung ist;
-
10 eine
Darstellung eines skalierbaren Netzgerüstes ist, das eine beispielhafte
Ausführung eines
Teils des Prozesses von 9 zeigt; und
-
11 eine
Darstellung eines skalierbaren Netzgerüstes ist, das eine alternative
Ausführung
eines Teils des Prozesses von 9 zeigt.
-
AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG
-
3 zeigt
ein skalierbares Netzgerüst
gemäß einer
bevorzugten Ausführungsform
der vorliegenden Erfindung. Wie gezeigt wird, beinhaltet das Gerüst einen
Publish/Subscribe-Serverknoten 402 und
mehrere Benutzerknoten (z.B. 404, 406 und 410).
In Ausführungsformen
der vorliegenden Erfindung kann der Serverknoten 402 von
einem einzelnen Server oder einer „Serverwolke" realisiert werden,
die aus einer beliebigen Anzahl von Servern besteht. Die einzelnen
Server einer solchen Serverwolke können auf verschiedene Arten
miteinander und mit dem Internet verbunden sein und auch durch große Entfernungen
voneinander getrennt sein, so dass ein entsprechender Servicegrad
(level of service) und vorteilhafte Merkmale bereitgestellt werden,
beispielsweise Daten- und Pfadredundanz.
-
In
diesem Gerüst
geht ein Benutzerknoten 416 eine Verbindung mit dem Netz
ein durch Kontaktieren des Publish/Subscribe-Serverknotens 402 und Abonnieren
bestimmter Nachrichten„Kanäle". Außerdem fordert
der die Verbindung eingehende Benutzerknoten 416 Verbindungen
an und geht sodann eine direkte Verbindung mit mindestens einem
anderen Benutzerknoten 410, 418 und 420 ein
(z.B. aufgrund bestimmter Kriterien, beispielsweise der geographischen
Position, der Verbindungsgeschwindigkeit oder gemeinsamer Interessen).
Auf diese Weise sind alle Benutzerknoten im Netz zur Nachrichtenübermittlung
mit dem zentralen Publish/Subscribe-Serverknoten (der Klarheit halber nicht
gezeigt) und durch nichthierarchische Verbindungen miteinander verbunden,
die ein dezentralisiertes Netz vom viralen Typ zur gemeinsamen Ressourcennutzung bilden.
-
4 ist
ein Flussdiagramm eines Prozesses zum Erhalten einer Ressource in
einem solchen skalierbaren Netzgerüst gemäß einer ersten Ausführungsform
der vorliegenden Erfindung. Jedes Mal, wenn ein erster Benutzerknoten 416 im
Netz eine Ressource (z.B. eine Datei) wünscht, wird eine Ressourcenanforderung
(oder -anfrage) an den Serverknoten 402 übertragen
(Schritt S10), und der Serverknoten 402 veröffentlicht
die Ressourcenanforderung, indem er sie an alle Benutzerknoten überträgt, die
den Kanal abonnieren, der diesem Typ von Anforderung entspricht
(Schritt S12). Ein zweiter Benutzerknoten 422, der die
Anforderung empfängt
und die Ressource bereitstellen möchte, kontaktiert den ersten
Benutzerknoten 416 (Schritt S14), und der erste und der
zweite Benutzerknoten 416 und 422 richten eine
nichthierarchische Verbindung ein, um die angeforderte Ressource
an den ersten Benutzerknoten 416 zu übertragen (Schritt S16). Auf
diese Weise ermöglicht
es die Schicht der Publish/Subscribe-Infrastruktur zur Nachrichtenübermittlung,
dass eine Ressourcenanforderung Knoten erreicht, die vom anfordernden
Knoten durch einen direkten Verbindungspfad getrennt sind, der eine
sehr große
Anzahl von Zwischenknoten beinhaltet.
-
Folglich
wird in dem von der vorliegenden Erfindung bereitgestellten skalierbaren
Netzgerüst
ein leistungsfähiges
Ausfindigmachen von Ressourcen bereitgestellt, wenn die Anzahl von
Benutzerknoten im Netz steigt. Gleichzeitig werden die Ressourcen selbst
nicht an den Server veröffentlicht,
und die eigentliche gemeinsame Ressourcennutzung bezieht den Server
nicht mit ein, so dass die Anforderungen an den Server geringer
als im herkömmlichen
Client/Server-Gerüst
sind. Da jede Suchanforderung für alle
Benutzerknoten veröffentlicht
wird, die den entsprechenden Kanal abonniert haben, ist es außerdem möglich, in
einem annehmbaren Zeitrahmen eine erschöpfende (oder zumindest sehr
ausgedehnte) Suche nach der angeforderten Ressource in einem Netz
auszuführen,
das eine sehr hohe Anzahl von Benutzerknoten beinhaltet.
-
In
bevorzugten Ausführungsformen
unterstützt
die Publish/Subscribe-Infrastruktur zur Nachrichtenübermittlung
zwei Typen von „Kanälen" oder gemeinsam genutzten
Datenströmen.
Der erste Kanaltyp ist ein „Kanal
zum Ausfindigmachen von Knoten" (node
discovery channel), der zum Unterstützen des Ausfindigmachens anderer
Benutzerknoten im dezentralisierten Netz verwendet wird. Um eine
Verbindung mit dem Netz einzugehen, meldet ein Benutzerknoten sich
selbst an unter Verwendung der Publish/Subscribe-Infrastruktur zur
Nachrichtenübermittlung
des Serverknotens. Insbesondere wird eine Verbindungsankündigung
(join announcement) vom neuen Benutzerknoten über den Serverknoten an einen
oder mehrere der Kanäle
zum Ausfindigmachen von Knoten geleitet, um Verbindungen von anderen Benutzerknoten
anzufordern. Folglich fungiert die Publish/Subscribe-Infrastruktur
als eine Universaltransportschicht (wie eine Schicht über IP),
die Verbindungen mit anderen Benutzerknoten einrichtet, um die Rundsendung
von Verbindungsankündigungen
auszuführen.
-
Solche
Verbindungsankündigungen
können auf
der Grundlage bestimmter Kategorien, beispielsweise der geographischen
Position, der Netzverbindungsgeschwindigkeit, der Typen verfügbarer Ressourcen
und/oder gemeinsamer Interessen, unter einzelnen Kanälen zum
Ausfindigmachen von Knoten aufgeteilt werden. Folglich kann der
neue Benutzerknoten ferne Benutzerknoten (sowohl geographisch als
auch in Bezug auf Netzsprünge)
ausfindig machen, und bei Eingehen einer Verbindung Knoten mit dem
gewünschten
Ressourcentyp oder annehmbaren Verbindungsattributen bevorzugen.
Da jede Verbindungsankündigung
lediglich an die Benutzerknoten übertragen
wird, die bestimmte Kanäle
abonniert haben, werden die Benutzerknoten eines sehr großen Netzes
nicht ständig
mit Verbindungsankündigungen überhäuft.
-
Der
zweite Kanaltyp ist ein „Ressourcenanforderungskanal", der zum Optimieren
der Veröffentlichung
von Ressourcenanforderungen verwendet wird. Wie oben erläutert wurde,
veröffentlicht
der Serverknoten jede Ressourcenanforderung, indem er sie an alle
Benutzerknoten überträgt, die
einen bestimmten Kanal (oder bestimmte Kanäle) abonniert haben. Diese
Ressourcenanforderungskanäle
können
in eine umfangreiche Taxonomie von Ressourcentypen unterteilt werden,
um den Benutzerknoten eine wirksame Ausfilterung unerwünschter
Anforderungen zu ermöglichen.
Anstatt jeden Benutzerknoten im Netz zu erreichen, macht die Verwendung
von Ressourcenanforderungskanälen
es außerdem
möglich, dass
eine Ressourcenanforderung nur eine entsprechende Teilgruppe von
Benutzerknoten erreicht (d.h. jene, die den/die entsprechenden Kanal/Kanäle abonniert
haben).
-
Folglich
wird ein Benutzerknoten, der lediglich technische Dokumentationen
gemeinsam nutzen möchte,
nicht mit Anforderungen nach Multimediainhalten bombardiert. In
Abhängigkeit
von der Anwendung können
der Benutzerknoten und/oder der Serverknoten den oder die Kanäle festlegen,
auf denen eine einzelne Ankündigung
oder Ressourcenanforderung veröffentlicht
wird. In bevorzugten Ausführungsformen
besteht ein Kanal lediglich aufgrund der Veröffentlichung durch einen Benutzerknoten.
Folglich kann jeder Benutzerknoten einen neuen Ressourcenkanal erzeugen
und anschließend
dessen Verfügbarkeit
zum Abonnement auf eine beliebige herkömmliche Weise unterstützen (z.B.
durch eine Web-Site, ein Diskussionsforum (newsgroup), das Fernsehen
oder durch direkte Postwerbesendungen).
-
5 ist
ein Flussdiagramm eines Prozesses zum Erhalten einer Ressource in
einem skalierbaren Netzgerüst
gemäß einer
zweiten Ausführungsform
der vorliegenden Erfindung. Jedes Mal, wenn ein erster Benutzerknoten 416 im
Netz eine Ressource (z.B. eine Datei) wünscht, wird eine Ressourcenanforderung
an den Serverknoten 402 übertragen (Schritt S10), und
der Serverknoten 402 veröffentlicht die Ressourcenanforderung,
indem er sie an alle Benutzerknoten überträgt, die den Kanal abonniert
haben, der diesem Typ von Anforderung entspricht (Schritt S12).
In der zweiten Ausführungsform überträgt der erste
Knoten 416 die Ressourcenanforderung außerdem an alle Benutzerknoten 410, 418 und 420,
mit denen er im dezentralisierten Netz verbunden ist.
-
Dieser
Prozess wird wiederholt, wobei jeder Benutzerknoten, der die Anforderung
empfängt,
diese an die mit ihm verbundenen Benutzerknoten leitet, so dass
die Anforderung durch die Benutzerknoten des dezentralisierten Netzes
geleitet wird (Schritt S11). Beispielsweise erreicht die Anforderung
einen zweiten Benutzerknoten 404, indem sie nacheinander
durch die Knoten 410 und 414 geleitet worden ist. In
einigen Ausführungsformen überträgt jeder
Benutzerknoten, der die Ressourcenanforderung vom Serverknoten (z.B.
dem Benutzerknoten 422) empfängt, diese außerdem an
alle Benutzerknoten, mit denen er im dezentralisierten Netz verbunden
ist. Falls der zweite Benutzerknoten 404 die Anforderung
empfängt
(entweder durch Weiterleitung von einem Benutzerknoten oder vom
Serverknoten) und bereit ist, die Ressource bereitzustellen, kontaktiert
er den ersten Benutzerknoten 416 (Schritt S14), und es
wird eine nichthierarchische Verbindung eingerichtet, um die angeforderte
Ressource gemeinsam zu nutzen (Schritt S16).
-
In
der zweiten Ausführungsform
werden Ressourcenanforderungen folglich sowohl durch die Schicht
der Nachrichtenübermittlungsinfrastruktur (wie
in der ersten Ausführungsform)
als auch durch Weiterleitung durch die Benutzerknoten im dezentralisierten
Netz veröffentlicht.
Da dieser Prozess mit doppeltem Pfad (dual path process) eine Alternative zu
dem über
den zentralen Serverknoten laufenden Anforderungsweiterleitungspfad
bietet, gibt es keine einzelne Fehlerstelle mehr. Mit anderen Worten,
die Ressourcenanforderung wird selbst dann an andere Benutzerknoten
geleitet, wenn der Serverknoten nicht erreichbar ist. In der zweiten
Ausführungsform ist
es außerdem
nicht nötig,
dass alle Benutzerknoten mit der Publish/Subscribe-Infrastruktur
verbunden sind oder auch nur Kenntnis von deren Vorhandensein haben.
Ein solcher Benutzerknoten kann lediglich Ressourcenanforderungen
an alle mit ihm verbundenen Benutzerknoten weiterleiten. Dieses Merkmal
ermöglicht
eine Realisierung der zweiten Ausführungsform in einem vorhandenen
Netz, ohne dass eine Änderung
aller Benutzerknoten notwendig wird.
-
6 ist
ein Flussdiagramm eines Prozesses zum Erhalten einer Ressource in
einem solchen skalierbaren Netzgerüst gemäß einer dritten Ausführungsform
der vorliegenden Erfindung. In dieser Ausführungsform werden Ressourcenanforderungen nicht direkt
an den Serverknoten übertragen,
um dem anfordernden Benutzerknoten einen besseren Datenschutz zu
bieten. Jedes Mal, wenn in der dritten Ausführungsform eine Ressource (z.B.
eine Datei) gewünscht
wird, überträgt der anfordernde
erste Benutzerknoten 410 eine Ressourcenanforderung an einen
zweiten Benutzerknoten 414, mit dem er im dezentralisierten
Netz verbunden ist (Schritt S20), wie durch die gestrichelten Pfeile
in 7 gezeigt wird. Der zweite Benutzerknoten 414 legt
sodann fest, ob die Anforderung an den Publish/Subscribe-Serverknoten 402 oder
an einen anderen Benutzerknoten übertragen
wird, mit dem er im dezentralisierten Netz verbunden ist (Schritt
S22). Vorzugsweise sind alle Benutzerknoten zur Nachrichtenübermittlung
mit dem zentralen Publish/Subscribe-Serverknoten verbunden (der
Klarheit halber nicht gezeigt).
-
Falls
gegen eine Übertragung
an den Serverknoten 402 entschieden wird, leitet der zweite
Benutzerknoten 414 die Ressourcenanforderung an einen anderen
mit ihm verbundenen Benutzerknoten 420 weiter (Schritt
S20), wie in 7 gezeigt wird. Dieser Weiterleitungsprozess
wird wiederholt, wobei jeder die Ressourcenanforderung empfangende
Benutzerknoten dieselbe Entscheidung ausführt (Schritt S22). Wenn ein
dritter Benutzerknoten 416 sich für eine Übertragung an den Serverknoten 402 entscheidet, wird
die Ressourcenanforderung an den Serverknoten 402 übertragen
(Schritt S24), und dieser veröffentlicht
die Ressourcenanforderung, indem er sie an alle Benutzerknoten überträgt, die
den Kanal abonniert haben, der diesem Typ von Anforderung entspricht
(Schritt S26).
-
In
bevorzugten Ausführungsformen
ist jede Entscheidung, ob die Anforderung an den Publish/Subscribe-Serverknoten übertragen
wird, eine „willkürliche" Entscheidung, die
vom Benutzerknoten auf der Grundlage eines Bewertungsfaktors zwischen
0 und 1 getroffen wird, der die Wahrscheinlichkeit angibt, dass
die Anforderung an den Serverknoten übertragen wird. Falls der Bewertungsfaktor
beispielsweise 0,25 ist, besteht eine 25 %ige Wahrscheinlichkeit,
dass der Benutzerknoten die Anforderung an den Serverknoten überträgt, und
eine 75 %ige Wahrscheinlichkeit, dass die Anforderung an einen anderen
Benutzerknoten weitergeleitet wird. Folglich muss ein Bewertungsfaktor
von 0,25 bewirken, dass Ressourcenanforderungen durchschnittlich
dreimal an andere Benutzerknoten weitergeleitet werden, bevor sie
an den Publish/Subscribe-Serverknoten übertragen werden. Der Wert
des Bewertungsfaktors wird auf der Grundlage von Faktoren wie beispielsweise
dem gewünschten
Grad an Datenschutz eingestellt. Außerdem kann der Bewertungsfaktor
ein feststehender Wert sein, der im gesamten Netz verwendet wird,
oder kann von den Benutzerknoten Nachricht für Nachricht (on a per message
basis) eingestellt werden. Andere Kriterien, beispielsweise eine
maximale Anzahl von Weiterleitungen oder eine maximal vergangene
Zeit, können ebenfalls
in die Entscheidung einbezogen werden, die von jedem die Anforderung
empfangenden Benutzerknoten getroffen wird.
-
In
weiteren Ausführungsformen
wird die Entscheidung, ob die Anforderung an den Publish/Subscribe-Serverknoten übertragen
wird, auf der Grundlage anderer Kriterien getroffen, beispielsweise
einer feststehenden Anzahl von Weiterleitungen. In einer Ausführungsform
wird jede Ressourcenanforderung beispielsweise stets durch drei
Benutzerknoten weitergeleitet und anschließend an den Publish/Subscribe-Serverknoten übertragen.
Jedes Mal, wenn eine Ressourcenanforderung an einen anderen Benutzerknoten
weitergeleitet werden muss, erfolgt die Wahl, welcher andere Benutzerknoten
die weitergeleitete Anforderung empfängt, vorzugsweise durch eine
willkürliche
Auswahl eines der Benutzerknoten, mit denen der weiterleitende Benutzerknoten
verbunden ist.
-
Nachdem
die Ressourcenanforderung vom Serverknoten 402 veröffentlicht
wurde, kontaktiert ein vierter Benutzerknoten 422, der
die Anforderung empfängt
und die Ressource bereitstellen möchte, den ersten Benutzerknoten 410.
Wie in 8 gezeigt wird, überträgt der vierte Benutzerknoten 422 insbesondere
eine Antwort an den dritten Benutzerknoten 416 (Schritt
S28), der die Ressourcenanforderung zur Veröffentlichung an den Serverknoten 402 übertragen
hatte. Der dritte Benutzerknoten 416 leitet die Antwort
den Benutzerknoten 420 weiter, von dem er die Ressourcenanforderung
empfing, und dieser Weiterleitungsprozess wird wiederholt, bis die
Antwort den ersten Benutzerknoten 410 erreicht (Schritt S30).
An diesem Punkt kann der erste Benutzerknoten 410 den vierten
Benutzerknoten 422 kontaktieren, um eine direkte nichthierarchische
Verbindung zur gemeinsamen Nutzung der angeforderten Ressource einzurichten
(Schritt S32).
-
In
bevorzugten Ausführungsformen
enthält die
Antwort von dem die Ressource aufweisenden Benutzerknoten Metadaten
bezüglich
der Ressourcenübereinstimmung.
Wenn die Antwort empfangen wird, wertet der anfordernde Benutzerknoten
die Metadaten aus und entscheidet sodann, ob er eine direkte Verbindung
mit dem antwortenden Knoten einrichtet, um die Ressource selbst
zu nutzen (z.B. die angeforderte Datei herunterzuladen). Falls mehrere Antworten
empfangen werden, kann der anfordernde Benutzerknoten die Metadaten
in jeder Antwort auswerten und anschließend einen oder mehrere der antwortenden
Benutzerknoten auf der Grundlage beliebiger Kriterien (z.B. vergangener
Erfahrung, Empfangsreihenfolge, Verbindungsgeschwindigkeit oder physische
Position) auswählen.
-
Außerdem werden
in bevorzugten Ausführungsformen
Antworten von Benutzerknoten, die die Ressource aufweisen, über bestehende
Verbindungen geleitet (beispielsweise diejenige, über die
die Anforderung durch den Serverknoten geleitet wurde), und eine
neue Punkt-zu-Punkt-Verbindung wird lediglich zur tatsächlichen Übertragung
der Ressource eingerichtet. Wenn andernfalls jeder antwortende Benutzerknoten
eine neue Punkt-zu-Punkt-Verbindung einleiten
würde,
könnte
der die Antworten empfangene Benutzerknoten bei jedem Empfang einer
großen Anzahl
von Antworten überlastet
werden. Alternativ könnte
der Serverknoten einen übereinstimmenden „einmaligen" Antwortkanal oder
einen dauerhaften Antwortkanal einrichten, der von Benutzerknoten
verwendet werden könnte,
die die Ressourcenanforderung beantworten. Die Veröffentlichung
von Antworten über
einen dauerhaften Antwortkanal würde „passive" Benutzerknoten ermöglichen,
die Antworten von möglichem
Interesse für
eine künftige
Verwendung archivieren.
-
Da
Ressourcenanforderungen anstelle einer direkten Übertragung an den Serverknoten
durch einen oder mehrere Benutzerknoten weitergeleitet werden, bietet
die dritte Ausführungsform
Datenschutz für
die anfordernden Benutzerknoten. Der eigentliche eine Ressource
anfordernde Benutzerknoten bleibt für den Serverknoten anonym,
folglich kann der Serverknoten nicht verfolgen, welche Benutzer welche
Ressourcen gemeinsam nutzen (oder auch nur anfordern). Wie in einem
herkömmlichen
viralen Netz hat in der dritten Ausführungsform nur ein Benutzerknoten,
der die Ressource tatsächlich
bereitstellt, Kenntnis von der gemeinsamen Nutzung der Ressource
und der Identität
des anfordernden Knotens. Im Gegensatz zu einem herkömmlichen
viralen Netz ermöglicht
die Verwendung einer Publish/Subscribe-Infrastrukturschicht zur
Nachrichtenübermittlung
in der dritten Ausführungsform
ein leistungsfähiges
Ausfindigmachen von Ressourcen in einem Netz mit einer sehr hohen
Anzahl von Benutzerknoten. Folglich ermöglicht die vorliegende Erfindung
eine Skalierbarkeit, die in einem dezentralisierten Netz ausgeführt werden
kann, während
ein besserer Benutzerdatenschutz aufrechterhalten wird.
-
9 ist
ein Flussdiagramm eines Prozesses zur Bereitstellung einer angeforderten
Ressource in einem skalierbaren Netzgerüst gemäß einer vierten Ausführungsform
der vorliegenden Erfindung. In dieser Ausführungsform werden Antworten
auf Ressourcenanforderungen nicht direkt an den anfordernden Benutzerknoten
zurückgeleitet,
um diesem einen besseren Datenschutz zu gewährleisten. Jedes Mal, wenn
eine Ressource (z.B. eine Datei) gewünscht wird, überträgt der anfordernde
erste Benutzerknoten 410 eine Ressourcenanforderung an
einen zweiten Benutzerknoten 414, mit dem er im dezentralisierten
Netz verbunden ist (Schritt S20), wie durch die gestrichelten Pfeile
in 7 gezeigt wird. Wie in der dritten Ausführungsform
legt der zweite Benutzerknoten 414 sodann fest, ob er die
Anforderung an den Publish/Subscribe-Serverknoten 402 oder
an einen anderen Benutzerknoten überträgt, mit dem
er im dezentralisierten Netz verbunden ist (Schritt S22).
-
Falls
gegen eine Übertragung
an den Serverknoten 402 entschieden wird, leitet der zweite
Benutzerknoten 414 die Ressourcenanforderung an einen anderen
Benutzerknoten 420 weiter, mit dem er verbunden ist (Schritt
S20), wie in 7 gezeigt wird. Dieser Weiterleitungsprozess
wird wiederholt, wobei jeder Benutzerknoten, der die Ressourcenanforderung
empfängt,
dieselbe Entscheidung ausführt (Schritt
S22). Wenn ein dritter Benutzerknoten 416 sich für eine Übertragung
an den Serverknoten 402 entscheidet, wird die Ressourcenanforderung
an den Serverknoten 402 übertragen (Schritt S24), und
der Serverknoten 402 veröffentlicht die Ressourcenanforderung,
indem er sie an alle Benutzerknoten überträgt, die den Kanal abonniert
haben, der diesem Typ von Anforderung entspricht (Schritt S26).
-
Nachdem
die Ressourcenanforderung vom Serverknoten 402 veröffentlicht
worden ist, bereitet ein vierter Benutzerknoten 422, der
die Anforderung empfängt
und die Ressource bereitstellen möchte, eine Antwort vor. Wie
oben erläutert
wurde, wird die Antwort vom vierten Benutzerknoten 422 in
dieser Ausführungsform
nicht direkt rückübertragen.
Stattdessen überträgt der vierte
Benutzerknoten 422 die Antwort an einen fünften Benutzerknoten 426,
mit dem er im dezentralisierten Netz verbunden ist (Schritt S40),
wie durch die gestrichelten Pfeile in 10 gezeigt
wird. Ähnlich
wie beim Prozess zum Weiterleiten der Ressourcenanforderung legt
der fünfte
Benutzerknoten 426 fest, ob die Antwort an den anfordernden
Benutzerknoten 410 oder an einen anderen Benutzerknoten übertragen
wird, mit dem er im dezentralisierten Netz verbunden ist (Schritt
S42).
-
Falls
gegen eine Übertragung
an den anfordernden Benutzerknoten 410 entschieden wird,
leitet der fünfte
Benutzerknoten 426 die Antwort an einen anderen Benutzerknoten 428 weiter,
mit dem er verbunden ist (Schritt S40), wie in 10 gezeigt
wird. Dieser Weiterleitungsprozess wird wiederholt, wobei jeder
Benutzerknoten, der die Antwort empfängt, dieselbe Entscheidung
ausführt
(Schritt S42). Wenn ein sechster Benutzerknoten 424 entscheidet,
die Antwort an den anfordernden Benutzerknoten 410 zu übertragen,
wird die Antwort an diesen zurück
geleitet (Schritt S44). Insbesondere in der in 10 gezeigten
beispielhaften Ausführungsform überträgt der sechste
Benutzerknoten 424 die Antwort direkt an den dritten Benutzerknoten 416,
der die Ressourcenanforderung zur Veröffentlichung an den Serverknoten 402 übertragen
hatte.
-
In
einer in 11 gezeigten alternativen Ausführungsform überträgt der sechste
Benutzerknoten 424 die Antwort über den Serverknoten 402 an
den dritten Benutzerknoten 416. Obwohl die Quelle der Antwort
noch anonym gehalten wird, ermöglicht
diese alternative Ausführungsform
es dem Server, Kenntnis über
Antworten im Allgemeinen zu erlangen. In jedem Fall leitet der dritte
Benutzerknoten 416 die Antwort sodann zurück an den
Benutzerknoten 420, von dem er die Ressourcenanforderung empfing,
und dieser Weiterleitungsprozess wird wiederholt, bis die Antwort
den ersten Benutzerknoten 410 erreicht, der die ursprüngliche
Anforderung ausgeführt
hatte.
-
In
bevorzugten Ausführungsformen
enthält die
Antwort von dem die Ressource aufweisenden Benutzerknoten die tatsächliche Ressource
selbst (z.B. die angeforderte Datei). Wenn die Antwort den anfordernden
Benutzerknoten erreicht, ist die Ressource folglich sofort verfügbar, und
es besteht keine Notwendigkeit für
weitere Maßnahmen
zum gemeinsamen Nutzen der Ressource. Außerdem wird dadurch für den antwortenden
Knoten ein hoher Grad an Anonymität bereitgestellt. In weiteren
Ausführungsformen
enthält
die Antwort Metadaten bezüglich
der Ressourcenübereinstimmung.
Wenn die Antwort empfangen wird, wertet der anfordernde Benutzerknoten
die Metadaten aus und entscheidet sodann, ob er die Ressource selbst
vom antwortenden Benutzerknoten abruft. In solchen Ausführungsformen
kann die Ressource auf vielfältige
Art und Weise vom antwortenden Benutzerknoten abgerufen werden.
-
Beispielsweise
könnte
der anfordernde Benutzerknoten 410 eine Zustimmung an den
antwortenden Benutzerknoten 422 rückübertragen, wobei eine direkte
Verbindung mit dem sechsten Benutzerknoten 424 verwendet
wird, der die Antwort zur Rückübertragung
an den anfordernden Benutzerknoten 410 an den dritten Benutzerknoten 416 übertragen hatte.
Alternativ könnte
der anfordernde Benutzerknoten 410 die Zustimmung über denselben
Pfad, über
den die Antwort übertragen
wurde, zurück
an den antwortenden Benutzerknoten 422 leiten (d.h. über die
Knoten 414, 420, 416, 424, 428 und 426). Für einen
besseren Datenschutz könnte
der anfordernde Benutzerknoten 410 außerdem erneut den indirekten
Weiterleitungsprozess verwenden, so dass die Zustimmung durch einen
oder mehrere andere Benutzerknoten weitergeleitet wird, bevor sie
zur Rückleitung
an den antwortenden Benutzerknoten 422 an den sechsten
Benutzerknoten 424 übertragen wird.
Wenn die Zustimmung empfangen wird, hat der antwortende Benutzerknoten 422 einen
analogen Satz von Antwortalternativen, die zum Rückübertragen der eigentlichen Ressource
an den anfordernden Benutzerknoten 410 verwendet werden
können.
-
In
einer weiteren Ausführungsform
nimmt der anfordernde Benutzerknoten einen „einmaligen" öffentlichen Schlüssel in
die Ressourcenanforderung auf, und der antwortende Benutzerknoten
verschlüsselt
die Antwort, so dass sie nur vom anfordernden Benutzerknoten gelesen
werden kann. Folglich kann der antwortende Benutzerknoten sich selbst
in der Antwort identifizieren und bleibt dennoch für alle außer dem
anfordernden Benutzerknoten anonym. Außerdem ermöglicht diese Ausführungsform
es dem anfordernden Benutzerknoten, den antwortenden Knoten direkt
zu kontaktieren, um eine nichthierarchische Verbindung zum gemeinsamen
Nutzen der angeforderten Ressource einzurichten.
-
Wie
bei Ressourcenanforderungen werden Antworten vorzugsweise über vorhandene
Verbindungen oder einen übereinstimmenden
Antwortkanal geleitet, um zu verhindern, dass ein Benutzerknoten bei
jedem Empfang einer großen
Anzahl von Antworten überlastet
wird. Ebenso ist jede Festlegung, ob die Antwort an den anfordernden
Benutzerknoten rückübertragen
wird, vorzugsweise eine „willkürliche" Entscheidung, die
vom Benutzerknoten auf der Grundlage eines Bewertungsfaktors getroffen
wird, der die Wahrscheinlichkeit darstellt, dass die Anforderung
an den anfordernden Benutzerknoten rückübertragen wird. Es können jedoch
auch andere Kriterien (beispielsweise eine maximale Anzahl von Weiterleitungen
oder eine maximal verstrichene Zeit) in die vom Benutzerknoten getroffene
Entscheidung aufgenommen werden, oder die Entscheidung kann lediglich
auf einigen anderen Kriterien beruhen (beispielsweise einer feststehenden
Anzahl von Weiterleitungen). Jedes Mal, wenn eine Antwort an einen anderen
Benutzerknoten weitergeleitet werden muss, wird die Wahl, welcher
andere Benutzerknoten die weitergeleitete Antwort empfängt, außerdem vorzugsweise
durch eine willkürliche
Auswahl eines der Benutzerknoten getroffen, mit denen der weiterleitende
Benutzerknoten verbunden ist.
-
Da
Antworten anstelle einer direkten Rückübertragung an den anfordernden
Benutzerknoten durch einen oder mehrere andere Benutzerknoten weitergeleitet
werden, bietet die vierte Ausführungsform
Datenschutz für
antwortende Benutzerknoten. Der eigentliche Benutzerknoten, der
die Ressource bereitstellt (oder bereitstellen möchte), bleibt für den anfordernden
Benutzerknoten und den Serverknoten anonym. Folglich können weder
der anfordernde Benutzerknoten noch der Serverknoten verfolgen,
welche Benutzer welche Ressourcen bereitstellen (oder auch nur besitzen).
In der Tat ist es bei der vierten Ausführungsform möglich zu
verhindern, dass der antwortende Knoten die Identität des anfordernden Knotens
kennt und umgekehrt. Im Gegensatz zu einem herkömmlichen viralen Netz ermöglicht die
Verwendung einer Publish/Subscribe-Infrastruktur zur Nachrichtenübermittlung
in der vierten Ausführungsform
außerdem
ein leistungsfähiges
Ausfindigmachen von Ressourcen in einem Netz mit einer sehr großen Anzahl
von Benutzerknoten. Folglich ermöglicht
die vorliegende Erfindung die Skalierbarkeit in einem dezentralisierten
Netz, wobei ein besserer Benutzerdatenschutz aufrechterhalten wird.
-
Die
oben beschriebenen Ausführungsformen der
vorliegenden Erfindung benötigen
einen Mechanismus zum Kennzeichnen einzelner Nachrichten. In bevorzugten
Ausführungsformen
wird jeder Nachricht (d.h. Ressourcenanforderung oder Antwort) eine eindeutige
Kennung zugewiesen. Eine Ausführungsform
verwendet beispielsweise einen von Microsoft Corporation entwickelten
Algorithmus, der es jedem Benutzerknoten ermöglicht, jeweils global eindeutige
Nachrichtenbezeichner (global-unique message identifiers – GUIDs)
zu erzeugen, die mit hoher Wahrscheinlichkeit global eindeutig sind.
Außerdem muss
jeder Benutzerknoten mindestens ein begrenztes Protokoll von weitergeleiteten
Nachrichten speichern (z.B. in einer Tabelle), um es zu ermöglichen, dass
Antworten (die möglicherweise
die Ressource selbst enthalten) den Benutzerknoten erreichen, der eine
Nachricht über
denselben Pfad übertrug.
Außerdem
enthalten einige Ausführungsformen
einen Mechanismus, um eine Endlosübertragung (looping) einer
Ressourcenanforderung zu verhindern. Beispielsweise können global
eindeutige Nachrichtenbezeichner (GUIDs) und Knotenprotokolltabellen problemlos
verwendet werden, um einen Anti-Schleifenbildungsmechanismus (anti-looping
mechanism) zu erzeugen.
-
Obwohl
die oben beschriebenen Ausführungsformen
der vorliegenden Erfindung einen einzelnen Serverknoten betreffen,
können
mehrere Publish/Subscribe-Serverknoten im Netz bereitgestellt werden,
um „Fehlerstellen" auf ein Minimum
herabzusetzen. Außerdem
können
konkurrierende Anbieter nebeneinander im Netz auftreten, indem sie
verschiedene Serverknoten betreiben und um Abonnements durch Benutzerknoten
konkurrieren. Außerdem
können
die Merkmale der verschiedenen oben beschriebenen Ausführungsformen
für weitere
Anwendungen kombiniert werden. Beispielsweise beinhaltet eine Ausführungsform
der vorliegenden Erfindung sowohl die willkürliche Antwortweiterleitung
der vierten Ausführungsform
als auch die willkürliche Weiterleitung/Veröffentlichung
der zweiten Ausführungsform.
Andere Gestaltungsmöglichkeiten,
beispielsweise Netzprotokolle, Weiterleitungskriterien und Zugehörigkeitskriterien
(membership criteria) könnten
problemlos angepasst werden.
-
Die
vorliegende Erfindung kann in Form von Hardware, Software oder einer
Kombination aus Hard- und Software realisiert werden. Jede Art von Computersystem – oder eine
andere Vorrichtung, die zum Ausführen
der hierin beschriebenen Verfahren in der Lage ist – ist geeignet.
Eine typische Kombination aus Hardware und Software könnte ein
Universalcomputersystem mit einem Computerprogramm sein, das, wenn
es geladen und ausgeführt
wird, das Computersystem so steuert, dass es die hierin beschriebenen
Verfahren ausführt.
-
Außerdem kann
die vorliegende Erfindung in einem Computerprogrammprodukt ausgeführt werden,
das alle Merkmale umfasst, die die Ausführung der hierin beschriebenen
Verfahren ermöglichen,
und das – wenn
es in ein Computersystem geladen wird – diese Verfahren ausführen kann.
Im vorliegenden Zusammenhang enthält ein „Computerprogramm" einen beliebigen
Ausdruck in einer beliebigen Sprache, einem beliebigen Code oder
einer beliebigen Schreibweise eines Satzes von Befehlen, die dafür vorgesehen
sind, ein System mit einer Datenverarbeitungsfähigkeit zu veranlassen, eine
bestimmte Funktion direkt oder nach einem oder beiden von folgenden
Vorgängen
auszuführen:
a) einer Umsetzung in eine andere Sprache, einen anderen Code oder eine
andere Schreibweise; und b) einer Wiedergabe in einer anderen materiellen
Form.
-
Zu
jedem Computersystem können
ein oder mehrere Computer und ein computerlesbares Medium gehören, das
dem Computer das Lesen von Daten, Befehlen, Nachrichten oder Nachrichtenpaketen und
anderen computerlesbaren Daten aus dem computerlesbaren Medium ermöglicht.
Zu dem computerlesbaren Medium kann ein nichtflüchtiger Speicher, beispielsweise
ein ROM, ein Flash-Speicher,
eine Festplatte oder Diskette, eine CD-ROM oder ein anderer nichtflüchtiger
Speicher gehören.
Außerdem können zu
einem computerlesbaren Medium ein flüchtiger Speicher wie beispielsweise
ein RAM, Puffer, ein Cachespeicher und Netzschaltungen gehören. Außerdem kann
das computerlesbare Medium computerlesbare Daten in einem vorübergehend
genutzten Medium beinhalten, beispielsweise in einer Netzverbindung
und/oder einer Netzschnittstelle (darunter ein verkabeltes Netz
oder ein kabelloses Netz), das einem Computer das Lesen solcher
computerlesbaren Daten ermöglicht.