IT-Academy Logo
Sign Up Login Help
Home - Netzwerke - JXTA - eine P2P Technik für JAVA



JXTA - eine P2P Technik für JAVA

Dezentrale und offene Netzwerke ohne feste Hierarchien verbreiten sich im Internet immer stärker. Man nehme nur als Beispiele das EDonkey- oder das GNUtella-Netzwerk. Alle diese Netzwerke arbeiten nach einem Peer-to-Peer-Schema. Ziel dieser Arbeit ist ein Überblick zu schaffen bezüglich der P2P-Technologien in der JAVA-Umgebung. Als zentrales Thema wird aber grundsätzlich JXTA behandelt, da ich dieses für weitere Vertiefung gewählt habe.


Autor: Bedin Bruno (bbedin)
Datum: 29-09-2003, 20:22:37
Referenzen: JXTA.org
Schwierigkeit: Fortgeschrittene
Ansichten: 11500x
Rating: 6 (3x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Einleitung

Dezentrale und offene Netzwerke ohne feste Hierarchien verbreiten sich im Internet
immer stärker. Man nehme nur als Beispiele das EDonkey- oder das GNUtella-
Netzwerk. Alle diese Netzwerke arbeiten nach einem Peer-to-Peer-Schema.
Ziel dieser Arbeit ist ein Überblick zu schaffen bezüglich der P2P-Technologien in der
JAVA-Umgebung. Als zentrales Thema wird aber grundsätzlich JXTA behandelt, da ich
dieses für weitere Vertiefung gewählt habe.

Wie sehen die Möglichkeiten aus eine Kommunikationsplattform (Beispiel ICQ) oder
gar ein verteiltes Rechensystem (GRID, SETI@Home) mit diesen Werkzeugen zu
erstellen?

Peer-to-Peer

Was ist Peer-to-Peer?

Als Peer-to-Peer (P2P) wird eine Architektur bezeichnet, welche es erlaubt mit anderen
Peers (also gleichwertige Instanzen) in Kontakt zu treten und Services zu nutzen bzw.
anzubieten. Diese Netzwerke werden dynamisch aufgebaut und folgen praktisch keiner
Hierarchie.

Teilweise wird auch ein hybrider Betrieb gewählt, bei dem zentrale Server genutzt
werden. Dies macht Sinn, wenn Verzeichnisdienste das Auffinden von Ressourcen
erleichtern sollen.

Probleme bei P2P

Verwaltungsaufwand der Peers
Sicherheit gegenüber dritten
Authentizität
Verteilung unerwünschter Daten (Spam)
Intellektueller Schutz
Ausfallsicherheit nicht garantiert
Firewalls, NAT und Proxies als mögliche Hürde

Das Auffallendste am Peer-to-Peer-Phänomen ist, dass es uns aus den ewig gleichen
Systemen des frühen kommerziellen Internets herausbekommen hat. Ein grosser Teil
des Wachstums des Internets von 1995-2000 basierte auf simplen Webservern und
mehr oder weniger intelligenten Browsern. Aber das Internet ist soviel mehr als das!
Peer-to-Peer zeigt was Netze wirklich leisten können indem Computer sich zu
leistungsfähigen Systemen zusammenschliessen. SETI@Home machte das Internet
zum grössten Supercomputer; Napster und Gnutella machten es zu ein System für den
ungehinderten Austausch von Musik und anderen Daten.

Die ironische Sache über die Bezeichnung "Peer-to-Peer" ist, dass sie häufig
verwendet wird, um Systeme zu beschreiben, die in Wirklichkeit nicht echte Peer-to-
Peers sind. SETI@Home-Peers kommunizieren nie wirklich miteinander! Das
Anwendungsdesign wird völlig zentralisiert: jeder Client verbindet sich mit einem
Server in Berkeley, welcher das Netz koordiniert und verwaltet. Das Netz Napster ist
auch nicht dezentralisiert: es ist ein vermitteltes Peer-to-Peer-Netz. Die tatsächliche
Datenübermittlung findet direkt zwischen den Clients statt, aber der Verzeichnisservice,
der Titelsuchen oder ähnliches erlaubt, geht alleine vom Server aus. Napster steht im
Gegensatz zu Gnutella, welche eine fast identische Anwendung mit einem ganz
anderen Aufbau ist, da sie auf eine dezentralisierte Architektur setzt, die vollständig auf
Peer-to-Peer-Kommunikation beruht.

Während diese Systeme sich in ihrer Zusammensetzung unterscheiden, teilen sie eine
allgemeine Eigenschaft: die einzelnen Teilnehmercomputer tragen der Community
etwas bei. Mit Napster und Gnutella bieten Computer ihre Musikansammlungen im
Internet an, mit SETI@Home wird ungenutzte Rechenleistung für einen (hoffentlich)
guten Zweck genutzt.

Nun, was ist besser - zentralisiert oder dezentralisiert? Selbstverständlich hängt die
Antwort von der Situation ab. Ein Hauptvorteil von dezentralisierten Systemen ist
Skalierbarkeit. Bei einem völlig zentralisierten System verlangen mehr Benutzer einen
umso grösseren zentralen Server. Ein dezentralisiertes System hat den
Grundgedanken mit jedem zusätzlichen Peer die Systemlast gleichmässig zu verteilen.
Die Realisierung kann ziemlich kompliziert sein, wie die Stabilitätsprobleme am Anfang
von Gnutella zeigten. Ausserdem können dezentralisierte Systeme ohne irgendeine
bestimmte Person oder Firma bestehen, die sie unterhalten. Gnutella wäre beträchtlich
schwieriger abzuschalten als Napster. Die Fähigkeit eines dezentralisierten Systems
im Netz, anstatt an einem bestimmten Punkt zu leben, ist besonders interessant.
Zentralisierung bietet auch eine Menge Vorteile. Die Sammlung der Informationen an
einem Ort lässt einfaches Durchsuchen zu. Eine Suche in Napster ist schnell und
komplett. Eine Suche in Gnutella dauert viele Sekunden und sucht niemals das
vollständige Netz ab. Zentralisierung vereinfacht auch die Datenversorgung grosser
System. SETI@Home verfolgt sorgfältig welche Daten durch wen verarbeitet wurden.
In einem zentralisierten System, ist das eine einfache Datenbanktransaktion.
Zentralisierte Systeme haben in der Regel auch keine Schwierigkeiten mit der
Entdeckung von Peers. Entweder befindet sich die benötigte Ressource auf einem
Server (wie mit SETI@Home) oder der Server vermittelt eine gesuchte Ressource (wie
mit Napster).

Peers hinter Firewalls oder NATs haben in der Regel keine Möglichkeit sich direkt mit
diversen Peers zu verbinden solange sie nicht mit einem zentralen Server
kommunizieren. Dieser kann dann auch Tunnels zu anderen Teilnehmern öffnen und
Verbindungsschwierigkeiten so umgehen.

Wo macht P2P Sinn?

aktuelle Anwendungen

Instant Messaging (ICQ, AIM, Jabber, …)
File Sharing (Napster, Morpheus, Gnutella, Freenet, …)
Verteilte Suchmaschinen (OpenCola, Copernic, …)
Groupware (Groove, NetMeeting, …)
Verteiltes Rechnen (Seti@Home, Parabon, …)

zukünftige Anwendungen

Verteilte Filesysteme
Vertrieb lizenzierter Medien
Handel (Intel)
Intelligent Agents
Online Gaming
Dediziertes Web
Wireless network
Vernetzte Fahrzeugsysteme

JXTA

Die Lösung könnte JXTA sein

JXTA liefert Technologien, um bei P2P zwei der Vorteile der zentralisierten Systeme zu
nutzen - Entdeckung von weiteren Teilnehmern und Überwindung von Firewall und
NAT. Tatsächlich werden die gegenwärtigen Einheiten hauptsächlich zentralisiert. Aber
die Versprechung von JXTA soll die Anwendungsentwickler von diesen Problemen
erleichtern und erlaubt ihnen sich auf die Entwicklung von dezentralisierten
Anwendungen zu konzentrieren
JXTA bietet Entdeckungsfunktionalitäten. Wenn ein Peer sich mit einer JXTA-Gruppe
verbindet, kann er sie nach etwas fragen: einen Service, eine Datei, ein Peer mit einem
bestimmten Namen. Die Anwendung braucht sich nicht um den Detailablauf zu
kümmern, weil die JXTA-Plattform das Prozedere abnimmt. Man kann einen zentralen
Server fragen (wie Napster), oder man kann die Gruppe auf eine dezentralisierte Art
und Weise fragen (wie Gnutella). Egal wie, die Anwendung erhält es umsonst von
JXTA.

JXTA liefert auch Firewall-Routing-Fähigkeiten. Wenn ein JXTA-Peer sich von hinter
einer Firewall oder einem NAT-Router mit dem Netz verbindet, kann er einen anderen
Peer im Netz finden, der einen Routingservice (Relay) durchführt, damit er die Firewall
überbrückt. Anwendungen brauchen das nicht zu beachten, dass diese Überbrückung
der Firewall geschieht, da sich ausschliesslich die JXTA-Plattform darum kümmert.
Das kann die Entwicklung einer P2P-Software bedeutend erleichtern.

Was ist JXTA

Das JXTA-Projekt ist eine offene Plattform für P2P-Netze. Es soll die Basis und die
Dienste für leistungsstarke verteilte Applikationen bieten. Die Bezeichnung JXTA ist
das Pseudonym für juxtapose, also „nebeneinanderreihen" (quasi das
aneinanderreihen von Rechnern in einem globalen Netz).

JXTA standardisiert die Protokolle wie die einzelnen Peers

sich einander finden
sich in Gruppen organisieren
Dienste publizieren bzw. erforschen
miteinander kommunizieren
sich gegenseitig überwachen

Diese Protokolle sind absolut unabhängig von Programmiersprachen sowie
Transportprotokollen. Man kann in C++, JAVA, Perl o.ä. implementieren und dabei
TCP/IP, HTTP, Bluetooth, usw. für den Transport nutzen. Die Kommunikation wird
absolut transparent gehandhabt.

JXTA Architektur




Von der Architektur her unterteilt sich die Plattform in drei Hauptebenen:

JXTA Core übernimmt die Low-Level-Kommunikation (Protokoll, Bildung von
Peer Groups, usw.)
JXTA Services bietet Suchfunktionen, Filesharingdienste, Protokollübersetzung,
usw.
JXTA Application stellt schlussendlich die eigentliche Anwendung dar (Email-
Client, Content-Management, usw.)

Im Wesentlichen läuft die Kommunikation über XML-Austausch ab.

JXTA Konzepte

Peers

Als Peer kann alles genannt werden, was mindestens eines der JXTA-Protokolle
implementiert. Das können u. a. auch PDAs, Handies, Server, usw. sein. Jedes Gerät
erhält eine ID welche nur einmal existiet im Internet. Peers forschen automatisch nach
weiteren Peers im gleichen Netz.

Peer Groups

Services können auch durch sogenannte Peer Groups angeboten werden. Die Vorteile
sind dabei Lastausgleich, Redundanz und Sicherheit. Ein Peer kann gleichzeitig
mehreren Gruppen angehören.

Pipes

Verbindung zwischen Peers
zum Austausch von Messages
unidirektional
asynchron
unidirectional (many to one) oder propagate (many to many)

Message

Strukturierte Dokumente
Text oder Binärdaten (Transportabhängig)
XML für HTML
Kommunikation zwischen Peers in JXTA immer über Messages

Advertisement

spezielle Messages
geben Dienste oder Anwesenheit bekannt
Peer(Group) Advertisement
Pipe Advertisement
Service Advertisement

Überlegung

Um die Vorteile von JXTA zu veranschaulichen, wird nachfolgend eine P2PAnwendung
betrachtet, die in drei Arten geschrieben wird: zentralisiert, vermittelt und
dezentralisiert. Die Anwendung ist ein einfaches Chatprogramm. Benutzer verbinden
sich mit dem Netzwerk und können Nachrichten senden und empfangen. Die
zentralisierte und die vermittelte Anwendung bauen auf einem Server auf, um
Chatpartner einfacher finden zu können, ähnlich wie MSN-Messenger oder ICQ.
Jedoch ermöglicht es JXTA einfach, eine drittes Art zu entwickeln welche völlig
dezentralisiert und ohne Server operiert.

Serverbasiertes System

Im völlig zentralisierten Chatsystem gibt es ein JXTA-Peer, welches als der Chatserver
funktioniert. Alle Clients kommunizieren direkt über diesen Server. Am Anfang
registrieren die Clients ihren Nickname beim Server. Wenn ein Benutzer jemandem
eine Nachricht schicken möchte, schickt der Client die Nachricht zum Server, der dem
anderen Client dann die Nachricht weiterleitet. Der Server liefert die Entdeckung- und
Nachrichtenzustelldienste.

Die JXTA-Implementierung des zentralisierten Chatsystems enthält zwei
Dienstleistungen: ein Server und ein Client. Der Server stellt eine Pipe her, meldet es
der Gruppe und wartet auf Nachrichten. Der Serverpeer agiert auch als rendezvous:
wenn sich Clients mit der Gruppe verbinden, fragen sie den rendezvous Service für
Entdeckung an. Der Server versteht zwei Arten von Nachrichten: Registrierungs- und
Chatnachrichten. Die Registrierungsnachricht enthält den Nickname des
registrierenden Clienten, sowie die Mitteilung für die Pipe auf der der Client zu hört.
Wenn der Server eine Registrierungsnachricht empfängt, speichert er die
Informationen. Wenn er eine Chatnachricht empfängt, schaut er in seiner Ablage, findet
die Pipe für die Empfänger und schickt es weiter. Die Aufgabe des Clients ist fast so
kompliziert wie die des Servers. Wenn der Client beginnt, verwendet er den JXTAEntdeckungservice,
um die Pipe für den Server zu finden. Im Hintergrund tritt JXTA mit
dem Rendezvouspeer für die Gruppe (in diesem Fall, der Server) und findet die
passende Verbindung. Der Client erstellt dann eine Pipe von sich selbst, um
Nachrichten empfangen zu können und registriert diese beim Server. Chatnachrichten
werden zum Server zur Weiterleitung geschickt. Unabhängig hört der Client auch auf
seiner eigenen Pipe auf ankommende Chatnachrichten, die es dann anzeigt.
Die zentralisierte Chatanwendung arbeitet genau wie ein herkömmliches
Client/Serversystem, nur in JXTA implementiert. Der einzige Vorteil von JXTA in dieser
Art des Designs ist die Fähigkeit der Clients beim Start den Server zu finden. Aber, weil
es nur einen einzelnen Server mit örtlich festgelegter Adresse gibt, ist dieser
Entdeckungservice nicht sonderlich nützlich. Es ist zweifellos möglich, zentralisierte
Anwendungen mit JXTA zu errichten, aber nicht besonders vorteilhaft.

Das vermittelnde System

In diesem Fall verhält sich die Anwendung ganz ähnlich wie im zentralen System. Der
Unterschied liegt lediglich darin, dass die Nachrichten nicht jedes Mal vom Server
weitergeleitet werden, sondern dass die Clients selbst untereinander kommunizieren.
Der Server nimmt die Registrierungen der Clients an und vermittelt die gewünschten
Adressen der gesuchten Clients. Er hilft also lediglich beim Auffinden der Partner.
Danach werden die Pipes direkt dazwischen erstellt.

Dieses Design ist ganz wie bei anderen vermittelnden Systemen (wie Napster), wo der
Server die zwei Peers zueinander bringt und dann keinen Einfluss mehr hat. Das in
JXTA zu implementieren ist eine angemessene Menge Arbeit, besonders weil das
gegenwärtige System nicht direkt query-/response-Arten der Kommunikation
unterstützt. Wie mit dem zentralisierten System, baut die vermittelte Chatversion auf
JXTA-Entdeckung auf um den Server zu finden.

Der wahre Vorteil von JXTA in dieser Art von brokered Systemen ist die Überwindung
der Firewall. Wenn beide Peers hinter Firewalls sind, ist es in einem typischen P2PSystem
nicht möglich, einen Anschluss zueinander zu öffnen. Wir sehen dieses Muster
in den Instant Messenger wie ICQ: sie versuchen einen vermittelten Chat zu starten, in
dem Clients direkt miteinander sprechen, fallen aber zurück zu einer Server gerouteten
Übermittlung, wenn Firewalls oder NATs im Spiel sind. JXTA lässt diese
Firewallvermittlung automatisch geschehen und erlaubt Entwicklern, Anwendungen zu
schreiben, als ob zwei Peers direkt miteinander kommunizieren, selbst wenn sie hinter
Firewalls sind.

Dezentralisierter Fall

In der dezentralisierten Implementierung kann JXTA seinen vollen Wert entfalten. In
diesem Fall benimmt sich das Chatsystem anders. Es gibt überhaupt keinen
Chatserver und keinen zentralen Peer. Alle Clients laufen unabhängig voneinander,
hören auf Chatnachrichten und senden diese einander zu. JXTA-Discovery macht es
möglich. Wenn ein Client startet, erstellt dieser eine Pipe für sich wie in den anderen
zwei vorgängigen Systeme. Jedoch anstatt, JXTA-Discovery zu verwenden, um einen
Server zu finden um die Pipe bekannt zu machen, veröffentlicht der Client die
Nachricht selbst der Peergruppe. Wenn Clients sich finden möchten, müssen sie nicht
mehr einen Server anfragen, stattdessen verwenden sie einfach JXTA-Entdeckung, um
die Clients direkt zu finden. Alles wird viel einfacher und der Code wird viel kleiner.
Die entscheidende Sache von JXTA, die das System ermöglichen, sind die
Rendezvous-Peers und die Rolle, die sie in der Entdeckung spielen. In zentralisierten
und vermittelten Szenarien wird die JXTA-Entdeckung lediglich zur Auffindung des
Servers genutzt. Das Entdecken anderer Clients wurde in der Serveranwendung selbst
eingeleitet. Im wesentlichen kopierte der Server die Funktion des JXTA-Rendezvous
und spürte die Veröffentlichungen der Clientpipes auf. Für die dezentralisierte
Implementierung sind die Clientpeers in der Gruppe selbst Rendezvous-Peers. JXTA
kümmert sich dann um die korrekte Verteilung der Bekanntmachung auf die
umliegenden Clientcaches, damit, wenn ein Client einen anderen sucht, er ihn in der
Gruppe schnell finden kann. Diese Strategie ist nicht ohne Gefahr: wenn es nicht
genug Rendezvous gibt, oder wenn die Synchrounisierungsalgorithmen nicht arbeiten,
dann kann die Entdeckung möglicherweise nicht erfolgen. Jedoch ist es die
Verantwortlichkeit der JXTA-Plattform, diese Rendezvous Pufferspeicher
beizubehalten und zu synchronisieren. Der Anwendungsprogrammierer wird von dieser
Belastung befreit.

Fazit

JXTA liefert zwei Schlüsseltechnologien, die Anwendungsentwicklern helfen, die P2PSysteme
entwerfen. JXTA-Discovery macht es einfacher für Peers Services und Pipes
zu erstellen und diese im Netzwerk bekannt zu machen. Die JXTA-Plattform kümmert
dann um die darunterliegenden Details. Und die JXTA-Nachrichtenübermittlungs-
Architektur erlaubt Peers hinter Firewalls, JXTA-Nachrichten zu empfangen, ohne dass
die Entwickler das mit eigenen Überbrückungsmethoden umgehen müssen.
Jedoch ist JXTA nicht nur Gold - die Plattform selbst ist noch in der
Entwicklungsphase. Es ist noch etwas früh um die Technologie genau zu bewerten.
Die gegenwärtigen Algorithmen sind noch nicht ganz optimiert und skalieren bei
grosser Last wahrscheinlich auch noch nicht wie gewünscht. Die zugrundeliegende
Abstraktion von JXTA stellt aber ein wertvolles Werkzeug zur Verfügung, womit sich
der Entwickler auf die Kernfunktion seiner P2P-Anwendung konzentrieren kann anstatt
sich mit der Kommunikation herumschlagen zu müssen.



[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04506
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06243
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1142
Comments: 0