Paper - Lehre und Forschung Thorsten Strufe

Studienarbeit
Analyse von JXTA und prototypische
Implementierung eines Peer-to-PeerSystems
Hochschullehrer:
Prof. Dr. Ing. habil. D. Reschke
Betreuer:
Dipl.-Inf. Thorsten Strufe
Name:
Ronny Heidenreich
Studiengang:
Informatik
Fakultät:
Fakultät für Informatik und Automatisierung
Universität:
Technische Universität - Ilmenau
1
Inhaltsverzeichnis
1. Einleitung
1.1
4
Aufgabenstellung
. . . . . . . . . . . . . . . . . .
2. Grundlagen zu Peer-to-Peer und JXTA
2.1
2.2
4
5
Übersicht zu Peer-to-Peer . . . . . . . . . . . . . . . .
5
2.1.1
P2P-Begriffe . . . . . . . . . . . . . . . . .
5
2.1.2
Dezentrale und zentrale Netzwerke . . . . . . . . . .
5
2.1.3
P2P-Einsatzgebiete . . . . . . . . . . . . . . .
6
2.1.4
Allgemeine Probleme in P2P-Netzwerken . . . . . . .
7
2.1.5
JXTA als gemeinsame Grundlage für P2P-Anwendungen . .
7
Übersicht zu JXTA . . . . . . . . . . . . . . . . . .
8
2.2.1
Entwicklungsgeschichte von JXTA. . . . . . . . . .
8
2.2.2
Die Ziele von JXTA . . . . . . . . . . . . . . .
8
2.2.3
Die JXTA-Architektur im Überblick . . . . . . . . .
10
2.2.4
Die Bestandteile der JXTA-Architektur . . . . . . . .
11
2.2.4.1 Der Core Layer. . . . . . . . . . . . . .
11
2.2.4.2 Core Layer - Konzepte . . . . . . . . . . .
11
2.2.4.3 Core Layer - Protokolle
. . . . . . . . . .
18
2.2.4.4 Der Service Layer. . . . . . . . . . . . .
21
2.2.4.5 Der Application Layer . . . . . . . . . . .
21
JXTA Anwendungen. . . . . . . . . . . . . . .
22
2.2.5.1 Die JXTA Shell . . . . . . . . . . . . .
22
2.2.5.2 myJxta . . . . . . . . . . . . . . . .
22
2.2.5
3. Stand der Technik
23
4. Die prototypische Implementierung des P2P-Systems
24
4.1
Entwurf . . . . . . . . . . . . . . . . . . . . . .
24
4.2
Implementierung . . . . . . . . . . . . . . . . . . .
26
4.2.1
Die Hauptklasse (TestApp.java) . . . . . . . . . . .
26
4.2.2
Das Content Management System (CMSystem.java) . . . .
28
2
4.2.3
Der Group Manager (GroupManager.java). . . . . . . .
31
4.2.4
Informationen zum Netzwerk (NetworkInfo.java) . . . . .
35
4.2.5
Hilfsklasse (Utility.java) . . . . . . . . . . . . .
35
4.2.6
Die graphische Benutzerschnittstelle (GUI.java) . . . . .
35
4.3. Probleme während der Umsetzung des Entwurfs . . . . . . . .
36
5. Fazit
37
6. Abkürzungsverzeichnis
38
7. Literaturverzeichnis
39
A. Softwareinstallation
40
B. Bedienungsanleitung
42
3
1.
Einleitung
Derzeit existieren die verschiedensten P2P-Anwendungen für die unterschiedlichsten
Bereiche. Dazu zählen Applikationen für File-Sharing, Instant-Messaging sowie
Distributed-Computing. Trotz ihrer unterschiedlichen Ansätze und vielfältigen
Einsatzmöglichkeiten haben diese Anwendungen eine Gemeinsamkeit: Während ihrer
Entwicklungsphase musste ein beträchtlicher Aufwand betrieben werden, um die
grundlegenden Funktionen eines jeden P2P-Systems zu integrieren. Zu diesem Zweck
wurden entsprechende Protokolle geschaffen und integriert. Diese Protokolle haben
aber einen erheblichen Nachteil: Sie sind untereinander nicht kompatibel, enthalten aber
zum Teil die gleichen Funktionalitäten. In der Folge entstanden getrennte Communities
zur Nutzung der inkompatiblen Anwendungen.
Diese Entwicklungen im P2P-Bereich wurden von der Firma „SUN“ als Anlass
genommen, das Projekt JXTA ins Leben zu rufen. Das Ziel dieses Projektes ist es, eine
dünne und universell einsetzbare Netzwerkzwischenschicht zu schaffen, die von den
verschiedensten P2P-Systemen gemeinsam genutzt werden kann. Mit JXTA entstand
somit ein Framework, das offene Protokolle enthält, plattformunabhängig ist und mit
dem es möglich sein soll, die Interoperabilität zwischen den Anwendungen zu
verbessern. Durch den Einsatz von JXTA soll auch der Aufwand für die
Anwendungsentwicklung verringert werden. Die Erleichterung bezieht sich dabei vor
allem auf den Umgang mit dem unterliegenden Netzwerk, das zu großen Teilen von
JXTA verwaltet werden soll.
1.1
Aufgabenstellung
Ziel dieser Arbeit ist zum einen die Analyse von JXTA und zum anderen die
prototypische Implementierung eines P2P-Systems. Zu diesem Zweck wird sich die
Arbeit in zwei Teile gliedern. Der Inhalt des ersten Teils ist die Analyse von JXTA. Das
Umfasst die Erläuterung der einzelnen Bestandteile von JXTA, sowie die Erklärung der
Funktion und des Einsatzes der enthaltenen Protokolle. Im zweiten Teil wird es dann
vor allem um den Entwurf und die konkrete Implementierung eins auf JXTAbasierenden P2P-Systems gehen.
4
2.
Grundlagen zu Peer-to-Peer und JXTA
Dieses Kapitels enthält eine kurze Einführung in die Peer-2-Peer Thematik und befasst
sich hauptsächlich mit den Grundlagen und Bestandteilen von JXTA. Die Ausführungen
zu JXTA enthalten dabei die Entwicklungsgeschichte und die Ziele von JXTA, sowie
die wichtigsten Konzepte und Protokolle die JXTA ausmachen. Zum Abschluss des
Kapitels werden einige Beispiele für bereits bestehende JXTA-Projekte etwas genauer
beschrieben.
2.1
Übersicht zu Peer-2-Peer
2.1.1 P2P-Begriffe
Unter dem Begriff Peer(s) versteht man alle Geräte in einem geschichteten
Kommunikationsnetzwerk, die auf der gleichen Protokollebene arbeiten. Peer-to-Peer
bedeutet etwa soviel wie „von gleich zu gleich“. Die Peer-to-Peer Kommunikation ist
der
Informationsaustausch
zwischen
Geräten,
die
in
einer
geschichteten
Netzwerkarchitektur auf der gleichen Protokollebene arbeiten.
2.1.2 Dezentrale und zentrale Netzwerke
Bei P2P-Netzwerken spricht man von so genannten dezentralisierten Netzwerken.
Kennzeichnend für ein solches Netzwerk ist, dass die Inhalte und Dienste von den
teilnehmenden Peers angeboten werden. Man nennt die Peers in diesem Zusammenhang
auch Servents, da sie Server und Client gleichzeitig sind. Typisch ist für diese
Netzwerke die Autonomie der Peers sowie das dynamische Betreten und Verlassen des
Netzwerks durch die Peers. Ein solches Netzwerk ist gegenüber Ausfällen sehr robust,
da die Funktionalität über das gesamte Netzwerk verteilt wird.
5
Den Gegensatz zu den dezentralen Netzwerken bilden die zentralen Netzwerke.
Diese Netzwerke funktionieren nach dem Client / Server Prinzip - d.h. es gibt dort
einen zentralen Server oder Serververbund, der alle anfragenden Clienten bedient.
Derzeit ist diese Architektur die am häufigsten anzutreffende.
Die bekanntesten Formen von existierenden P2P-Netzwerken sind entweder
total dezentralisiert (z.B. Gnutella) oder aber kombiniert zentralisiert &
dezentralisiert (z.B. KaZaA). Zentralisierte Netzwerke mit einem zentralen Indexserver
a la Napster sind nicht mehr so erfolgreich.
2.1.3 P2P-Einsatzgebiete
Bei dem P2P-Konzept handelt es sich nicht um eine Neuentwicklung, sondern um eine
bereits bekannte Organisationsform von Netzen, die schon im frühen Internet zum
Einsatz kam. Als Beispiele seien hier stellvertretend das Usenet und DNS genannt.
Der P2P-Gedanke wurde zwischenzeitlich immer wieder aufgegriffen, aber nie wirklich
in großem Rahmen umgesetzt. Heute wird dieser Typ von Netzwerken wieder
interessant, da sehr leistungsfähige PCs kostengünstig und in großer Stückzahl zur
Verfügung stehen. Die Rechner haben ein enormes Potenzial an Rechenkraft und
Speicherkapazität, welches durch die oft breitbandige Anbindung an das Internet auch
in geeigneter Weise genutzt werden kann.
Einige Beispiele für aktuelle P2P-Einsatzbereiche und Anwendungen:
-
Instant-Messaging (ICQ, AIM, Jabber)
-
File-Sharing (KaZaA, Gnutella, eDonkey2000, Overnet, Freenet)
-
Distributed-Search-Engines (OpenCola, Copernic)
-
Group-Collaboration (Groove, NetMeeting)
-
Distributed-Computing (Seti@Home, Parabon)
Mögliche zukünftige Anwendungsbereiche für P2P sind unter anderem DistributedStorage, Licensed-Media-Distribution und Online-Gaming.
6
2.1.4 Allgemeine Probleme in P2P-Netzwerken
Trotz der vielfältigen Einsatzbereiche und den Vorteilen, die ein P2P-Netzwerk bietet,
bringt diese Art von Netzwerken auch eine Reihe von Problemen mit sich, die hier nicht
unerwähnt bleiben sollen. So ist z.B. die Administration der einzelnen Peers sehr
schwierig. Auch Aspekte wie Anonymität, Sicherheit und Vertraulichkeit sind bei
bestehenden Lösungen meist nur unzureichend umgesetzt. Die Problematik der
Ausbreitung von unerwünschten Inhalten und die Garantie der Verfügbarkeit von
Inhalten, ist ein weiteres Problem. Häufig gibt es auch Schwierigkeiten beim Umgang
mit Firewalls und NATs. Nicht zuletzt müssen auch die Performance und Skalierbarkeit
in einem solchen Netzwerk beachtet werden, wenn eine P2P-Lösung mit bereits
existierenden zentralen Systemen konkurrieren soll.
2.1.5 JXTA als gemeinsame Grundlage für P2P-Anwendungen
In der P2P-Welt gibt es derzeit eine Vielzahl von Anwendungen für die
unterschiedlichsten Bereiche. Das Problem dabei ist, dass eine Anwendung meist nur
einen
einzigen
Bereich
abdeckt
und
ihr
eigenes
Programmierungs-
und
Kommunikationsmodell mitbringt. Die so entstanden Anwendungen existieren
unabhängig voneinander und sind untereinander nicht kompatibel. Zur Lösung dieses
Problems will JXTA beitragen. Es bietet dafür ein Framework, das eine gemeinsame
Grundlage für die Entwicklung von zukünftigen P2P-Anwendungen bieten soll. Der
Aufwand für die Entwicklung von grundlegenden Netzwerkfunktionen soll damit
verringert und die Interoperabilität zwischen den Anwendungen verbessert werden.
7
2.2
Übersicht zu JXTA
2.2.1 Entwicklungsgeschichte von JXTA
JXTA ist die Abkürzung für juxtaposition und heißt soviel wie „nebeneinander stellen“.
Das Konzept wurde von Bill Joy, Chefwissenschaftler bei Sun, entwickelt. Die ersten
Informationen zu JXTA stammen vom 15.02.2001 und wurden im Rahmen einer P2PKonferenz der Öffentlichkeit vorgestellt. Die JXTA Web-Site (www.jxta.org) wurde am
25.04.2001 eröffnet. Zeitgleich wurde ein Open Source Projekt ins Leben gerufen, das
den Namen Project JXTA hat. Dieses Projekt ist eine Referenzimplementierung der
Spezifikation von JXTA, und soll die weitere Entwicklung von JXTA vorantreiben.
Die Implementierung wurde in Java vorgenommen.
2.2.2 Die Ziele von JXTA
Bei der Entwicklung von JXTA wurden im Wesentlichen drei Hauptziele verfolgt:
—
Interoperabilität (Interoperability)
Bei genauerer Analyse von existierenden P2P-Systemen hatte man festgestellt, dass
viele der bisher entstandenen Systeme lediglich einen bestimmten Dienstetyp
realisierten. So wurde z.B. Napster nur für Musik-File-Sharing, Gnutella für
allgemeines File-Sharing oder AIM explizit für Instant-Messaging entwickelt. Die
verschieden Eigenschaften der Dienste und das Fehlen einer gemeinsamen zugrunde
liegenden P2P-Infrastruktur führte dazu, dass inkompatible Systeme entstanden sind.
Ein weiteres Ergebnis der Untersuchungen war die Feststellung, dass ähnlich gelagerte
Grundanforderungen der jeweiligen Dienste mehrfach neu entwickelt wurden, was
einen nicht unerheblichen Aufwand für das Gesamtprojekt bedeutete. Damit ein Nutzer
die angebotenen Dienste letztendlich auch nutzen konnte, war es notwendig, dass er
jede einzelne Implementierung eines P2P-Systems unterstützte. Durch den Einsatz von
JXTA sollen diese Schwierigkeiten beseitigt werden. JXTA stellt aus diesem Grund ein
Framework zur Verfügung, mit dem Peers in die Lage versetzt werden, die
verschiedensten Dienste anzubieten, diese aufzufinden, zu nutzen und mit anderen Peers
8
ganz allgemein zu kommunizieren. Die Interoperabilität erstreckt sich dabei auf die
verschiedenen P2P-Systeme und Communities.
— Plattformunabhängigkeit (Platform Independence)
Die meisten P2P-Systeme sind an ein bestimmtes Betriebssystem oder eine bestimmte
Programmiersprache gebunden. Das hat zur Folge, dass diese Systeme nur auf einem
Teil der denkbaren Peers lauffähig sind. Um eine Nutzung auf weiteren Plattformen zu
ermöglichen, ist eine erneute Entwicklung einer solchen Anwendung nötig. Bei JXTA
geschieht
die
Entwickelung
Programmiersprachen
und
Kommunikationsprotokollen
deshalb
unabhängig
von
Entwicklungsumgebungen,
sowie
den
eingesetzten
den
den
bevorzugten
verschiedenen
Plattformen
bzw.
Betriebssystemen.
— Globale Erreichbarkeit (Ubiquity)
Man verfolgt dieses Ziel mit der Absicht, die JXTA Technologie in jedes Gerät mit
einem „digitalen Herzschlag“ implementieren zu können. So z.B. in Sensoren,
Verbraucherelektronik, PDAs, Router, Desktop Computer, große Datenserver und
Speichersysteme. Somit erstreckt sich der Einsatzbereich über die Großsysteme der
Unternehmen bis hin zu den verbraucherorientierten Kleinsystemen der Endanwender.
JXTA kann somit theoretisch auf jedem digitalen Gerät eingesetzt werden, wobei klar
ist, dass der Funktionsumfang entsprechend angepasst werden muss. Alle Geräte
innerhalb des so entstehenden JXTA-Netzwerks lassen sich nach einem festgelegten
Schema auffinden und ansprechen.
Abbildung 2.1: Einordnung von JXTA in die bisherigen Strukturen
9
2.2.3 Die JXTA-Architektur im Überblick
Die Architektur von JXTA gliedert sich in drei Hauptebenen:
— Plattform (Core Layer)
Diese Ebene enthält im Wesentlichen das Basiswissen für alle P2P-Operationen und
beinhaltet die Funktionalität der JXTA-Basisprotokolle.
— Dienstebene (Service Layer)
Diese Schicht enthält die Dienste, die ein P2P-System anbieten oder nutzen kann.
— Anwendungsebene (Application Layer)
Stellt die Benutzerschnittstelle für Applikationen wie z.B. Tauschbörsen, InstantMessaging-Systeme und andere mögliche Anwendungen dar.
Abbildung 2: Die Architektur von JXTA
Abbildung 2.2: Die Architektur von JXTA
10
2.2.4 Die Bestandteile der JXTA-Architektur
2.2.4.1 Der Core Layer
Der JXTA Core Layer definiert die grundlegende Funktionalität für die P2P-Dienste
und Anwendungen. Er beinhaltet die gemeinsamen, minimalen und wesentlichen
Grundlagen für das P2P-Netzwerk.
Beispiele für diese grundlegenden Funktionen sind:
-
Basiskommunikation & Erkundungsmechanismus
-
grundlegende Sicherheitskonzepte & Mitgliedschaftsmechanismen
-
grundlegende Monitoring-Mechanismen
Konkret heißt das, es geht um den Aufbau von Kommunikationskanälen, das Aufspüren
von kommunikationswilligen Partnern und die Sicherung des Datenaustauschs. In einer
sicheren Umgebung werden dazu verschiedene Mechanismen zur Verfügung gestellt.
Der Core Layer umfasst im Wesentlichen Konzepte (Concepts) und Protokolle
(Protocols).
Zu den Konzepten gehören:
Peers, Peer Groups, Network Services, Pipes, Messages, Advertisements, Identifiers,
Credentials und Content
2.2.4.2 Core Layer - Konzepte
— Peer
Peers sind alle am Netzwerk angebundenen Teilnehmer, die JXTA nutzen. Ausgehend
von ihrem jeweiligen Einsatzzweck haben sie dafür ein oder mehrere Protokolle von
JXTA implementiert. Peers im Sinne von JXTA sind Prozessoren, Prozesse oder
Benutzer sowie Sensoren, Telefone, PDAs, PCs, Server und Super-Computer. Jeder
Peer im JXTA-Netzwerk besitzt eine eindeutige ID, die es erlaubt den Peer unabhängig
von seinem physischen Standort sicher zu adressieren. Da ein Peer mehrere
11
Netzwerkschnittstellen haben kann, wird jede veröffentlichte Schnittstelle als ein Peer
Endpoint bekannt gemacht und lässt sich damit eindeutig identifizieren und adressieren.
Die Peer Endpoints werden genutzt, um direkte Punkt-zu-Punkt Verbindungen
zwischen den Peers einrichten zu können. Da dies aber nicht in jedem Fall möglich ist,
z.B. wegen Trennung der Peers durch NATs, Firewalls und Proxys, gibt es einige
spezielle Peers, die dafür sorgen, dass trotzdem eine Verbindung aufgebaut werden
kann.
An dieser Stelle ein kurzer Überblick über die verschiedenen Peertypen:
Minimal Peer:
-
kann Messages senden und empfangen
-
kann keine Advertisements für andere Peers speichern oder Messages
weiterleiten
-
sind meist Geräte mit begrenzten Ressourcen
Simple Peer: (der überwiegende Anteil der Peers)
-
kann Messages senden und empfangen
-
kann Advertisements speichern
-
kann keine Discovery Requests weiterleiten
-
kann aber auf Discovery Requests antworten - mit Hilfe seine gespeicherten
Advertisements
Relay Peer:
-
hält Informationen über Routen zu anderen Peers (dynamische RoutingInformationen)
-
wird benutzt, um Messages weiterzuleiten bzw. zu routen
-
die Weiterleitung wird oft dann genutzt, wenn Peers nicht direkt zu erreichen
sind z.B. wegen physischer oder logischer Trennung des Netzes
=> die Überwindung von Firewalls wird möglich
-
speichern Messages für vorübergehend nicht erreichbare Peers
12
Rendezvous Peer:
-
kann Advertisements speichern
-
kann Discovery Requests weiterleiten
-
hält eine Liste aller ihm bekannten anderen Rendezvous Peers und der an ihn
angeschlossenen Peers => zum Messages verteilen
-
agiert als Zugangspunkt für das JXTA Netzwerk
Jeder Peer agiert unabhängig und asynchron mit anderen Teilnehmern. Ein Peer kann
Dienste anbieten, nutzen oder Informationen zwischenspeichern. Die Interaktion eines
Peers ist typischerweise auf wenige andere Teilnehmer im Netzwerk beschränkt. Diese
Peers haben sich meist als Gruppe organisiert, um ein bestimmtes Interessengebiet
abzudecken.
— Peer Group
Eine Peer Group ist eine virtuelle Einheit, die typischerweise aus einer Ansammlung
von kooperierenden Peers besteht. Die Mitglieder einer Gruppe verfolgen gemeinsame
Interessen und bieten gemeinsam Dienste an. Eine Peer Group bietet eine sichere,
spezialisierte und beobachtbare Umgebung. Dabei wird von der JXTA Spezifikation
nicht vorgeschrieben wann, wo oder warum eine Peer Group zu entstehen hat. Genauso
beliebig kann der Typ und die Mitgliedschaft einer Gruppe gewählt werden. Die JXTA
Spezifikation beschreibt lediglich, wie Peers eine Peer Group veröffentlichen, finden,
beitreten oder überwachen können. Ein Peer kann verschiedenen Peer Groups beitreten.
JXTA definiert standardmäßig eine WorldPeerGroup, in der alle Peers automatisch
vertreten sind. Jede Peer Group kann eigene Aufnahmekriterien für neue Mitglieder
definieren (z.B.: jeder beliebige Peer kann Mitglied werden, oder Peers müssen sich
autorisieren).
Motivation für die Gründung einer Peer Group könnte z.B. sein:
-
Erstellen einer sicheren Umgebung
-
Peer Groups können dafür beispielsweise einen Sicherheitsmechanismus
wie Public-Key Verfahren implementieren oder auch nur eine
Autorisierung mittels Benutzername und Kennwort fordern.
13
-
Erstellen einer spezialisierten Umgebung
-
Peers, die gemeinsamen Interessen nachgehen, schließen sich zusammen.
Innerhalb dieser Gruppe können dann Dateien ausgetauscht werden oder
gemeinsam nutzbare Rechnerleistung zur Verfügung gestellt werden.
-
Erstellen einer überwachten Umgebung
-
Peer Groups erlauben die Überwachung von Peers (Accountig, Tracing,
usw.)
Wie schon erwähnt, bietet eine Peer Group bestimmte Dienste an, so genannte Peer
Group Services. JXTA definiert einige grundlegende Peer Group Services, die natürlich
jederzeit um weitere zusätzliche Dienste ergänzt werden können.
Zu den grundlegenden Diensten (Core Services) gehören:
Discovery Service, Membership Service, Access Service, Pipe Service, Resolver Service,
Monitoring Service
— Network Services
Peers kooperieren und kommunizieren miteinander, um Network Services zu
veröffentlichen, zu finden und daran teilzunehmen. Ein Peer findet einen solchen
Network Service mittels des Peer Discovery Protocols (PDP).
Das JXTA Protokoll kennt 2 Ebenen von Network Services:
Peer Services
Darunter fallen alle Dienste, die nur ein einzelner Peer anbietet. Ein solcher Dienst steht
dem Netzwerk nur solange zur Verfügung, wie der Peer korrekt arbeitet und erreichbar
ist. Anderenfalls ist dieser Dienst nicht mehr nutzbar.
Peer Group Services
Diese Art Dienst wird von mehreren Mitgliedern einer Peer Group angeboten und ist
solange erreichbar, wie es noch Peers dieser Gruppe gibt, die den Dienst anbieten
können.
14
— Pipes
Pipes sind virtuelle Kommunikationskanäle zum Senden und Empfangen von
Nachrichten (Messages). In ihrer Grundform sind sie als asynchrone, unidirektionale
und unsichere Verbindung ausgelegt. Dieser geringe Funktionsumfang resultiert daraus,
dass JXTA keine Anforderungen an die darunter liegenden Transportschichten stellt.
Die jeweiligen Enden einer Pipe werden als Pipe Endpoints bezeichnet, wobei das
empfangende Ende als Input Pipe und das sendende Ende als Output Pipe bezeichnet
wird. Die Pipe Endpoints werden dynamisch zur Laufzeit an die Peer Endpoints
gebunden. Pipes verbinden also Peers miteinander. Dies kann direkt geschehen oder
aber mittels einem oder mehreren Relay Peers, wenn keine direkte Verbindung möglich
ist. In JXTA wird zwischen zwei Basistypen von Pipes unterschieden:
Point-to-Point Pipes:
Verbinden immer genau zwei Peers miteinander. Dabei liefert ein Peer die Messages
und der andere konsumiert diese. Eine Unterform dieser Art von Pipe ist die Secure
Unicast Pipe, die im Wesentlichen eine sichere Point-to-Point Pipe darstellt.
Propagate Pipes: (Point-to-Multipoint Pipes).
Verbinden einen Produzenten mit beliebig vielen Konsumenten; d.h. eine Output Pipe
wird mit vielen Input Pipes verbunden. Diese Art von Verbindung kommt im Rahmen
von Peer Groups zum Einsatz, um Messages an die einzelnen Mitglieder zu verteilen.
JXTA bietet auch die Möglichkeit, aufbauend auf den bestehenden Pipes, neue Typen
von Pipes zu erzeugen. So enthält z.B. die Java Implementierung von JXTA
bidirektionale und zuverlässige Pipes.
— Advertisements
Ein Advertisement ist ein XML strukturiertes Dokument, das Netzwerkressourcen
benennt, beschreibt und deren Existenz bekannt gibt. Netzwerkressourcen sind z.B.
Peers, Peer Groups, Pipes oder ein Dienst. Advertisements sind also Metadaten zum
Beschreiben von Ressourcen. Sie werden verteilt, um verfügbare Ressourcen bekannt
zu machen und sie somit auffinden zu können. Jedes Advertisement hat eine bestimmte
15
„Lebenszeit“, die eine Angabe über die Dauer der Verfügbarkeit einer entsprechenden
Ressource macht. JXTA definiert nur ein Basis-Set an Advertisements. Neue Subtypen
können mit Hilfe der Basistypen und unter Zuhilfenahme der XML Notation definiert
werden.
Die JXTA Protokolle definieren folgende Core Advertisements:
Peer Advertisement, Peer Group Advertisement, Pipe Advertisement, Module
Advertisement,
Peer
Info
Advertisement,
Content
Advertisement,
Rendezvous
Advertisement
— Messages
Messages sind in JXTA die Grundform für den Datenaustausch zwischen den Peers. Es
gibt je nach Einsatzzweck zwei verschiedene Formen für die Darstellung einer
Messsage:
-
Binär: kompakte Form
-
XML: sprachenunabhängig und selbstbeschreibend
Eine Message besteht prinzipiell aus einer Hülle, einem Stapel an Protokoll-Headern
und den dazugehörigen Rümpfen (bodies). Die Hülle an sich enthält einen Header, eine
Message-ID, den Quell Endpunkt (optional) und den Ziel Endpunkt. Ein Endpunkt in
JXTA ist ein logisches Ziel, das in Form einer URI (Uniform Resource Identifier)
gegeben ist. Endpoints werden auf reale physische Adressen abgebildet, um so die
Messages zustellen zu können. Durch das so gewählte Message-Format ist es möglich,
die verschiedensten Transportstandards zu unterstützen.
Die Informationen einer Message sind in den so genannten Elements enthalten. Ein
Element ist dabei ein Name, dem ein bestimmter Inhalt zugeordnet wird. Eine Message
besteht aus einer Liste von Name/Wert Paaren. Zusätzlich enthält eine Message so
genannte Credentials, das sind Informationen, welche den Sender gegenüber dem
Empfänger identifizieren.
16
—
Identifiers
Dienen zum Eindeutigen identifizieren und lokalisieren von Peers, Peer Groups, Pipes
und anderen JXTA-Ressourcen. Zu diesem Zweck wurden in JXTA so genannte UUIDs
definiert. Eine solche UUID ist eine 128-bit ID, die es ermöglicht eine Instanz eindeutig
zu identifizieren und somit auch lokalisieren zu können. Zur Darstellung der JXTA-IDs
werden URNs (Uniform Ressource Name) eingesetzt. Eine solche ID ist eindeutig,
einzigartig (höchstwahrscheinlich), beständig und ortsunabhängig.
Ein Beispiel für eine JXTA Peer ID ist:
urn:jxta:uuid59616261646162614A78746150325033F3BC76FF13C2414CBC0AB663666DA53903
Ein Beispiel für eine JXTA Pipe ID ist:
urn:jxta:uuid59616261646162614E504720503250338E3E786229EA460DADC1A176B69B731504
— Credential
Das sind Zusatzinformationen, die einen Sender gegenüber einem Empfänger
identifizieren. Das exakte Format und der genaue Inhalt sind nicht weiter spezifiziert.
Denkbar wären z.B. eine Unterschrift, die die Originalität einer Message beweist oder
genauere Informationen zur Verschlüsselung einer Message.
— Content
Das sind jegliche Daten, die zwischen den Peers ausgetauscht werden können. Das
umfasst sowohl Code als auch Daten (Codat). Content ist eindeutig identifizierbar.
17
2.2.4.3 Core Layer - Protokolle
Damit die einzelnen Peers einer Peer Group miteinander interagieren können, müssen
sie die erforderlichen Protokolle kennen und implementiert haben. Welche Protokolle
dabei genau benötigt werden ist aus den Advertisements der Peer Groups ersichtlich. Da
alle Knoten standardmäßig der WorldPeerGroup angehören, müssen sie auch deren
Protokolle verstehen können. Diese grundlegenden Protokolle stellen die Basis von
JXTA dar und werden daher auch als Basis Protokolle betrachtet.
Die Protokolle:
-
Peer Resolver Protocol (PRP)
-
Peer Discovery Protocol (PDP)
-
Peer Information Protocol (PIP)
-
Pipe Binding Protocol (PBP)
-
Peer Endpoint Protocol (PEP)
-
Rendezvous Protocol (RVP)
— Peer Resolver Protocol
Das Peer Resolver Protocol (PRP) ermöglicht es einem Peer durch das Senden und
Empfangen von allgemeinen Anfragen nach weiteren Peers, Peer Groups, Pipes und
anderen Informationen zu suchen. Eine Anfrage kann dabei an einen bestimmten Peer
oder an einen Rendezvous Peers gesendet werden. Der Rendezvous Peer übernimmt
dann die Verteilung der Anfrage auf die Mitglieder einer Peer Group. PDP und PIP
nutzen beide das PRP, jedoch sind die Anfragen bzw. Antworten dieser beiden
Protokolle spezifischer. So werden mittels PIP Statusinformationen abgefragt und PDP
wird genutzt, um Peer Ressourcen zu finden. Für die Bearbeitung der Anfragen sind so
genannte Handler zuständig. Diese können bei Bedarf von jedem Dienst registriert
werden und sind von da an für die Bearbeitung der Anfragen und für die Generierung
der entsprechenden Antworten zuständig. Üblicherweise wird dieses Protokoll nur von
Peers
implementiert,
die
Zugriff
auf
Datenspeicher
haben
und
erweiterte
Suchmöglichkeiten anbieten wollen.
18
— Peer Discovery Protocol
Mit Hilfe des Peer Discovery Protocol (PDP) kann ein Peer seine eigenen Ressourcen
bekannt machen und nach bereits veröffentlichten Ressourcen suchen. Ressourcen
werden in JXTA durch Advertisements repräsentiert, so dass mit Hilfe des PDP das
Netzwerk nach jeglichen Advertisements, die eine Ressource veröffentlicht hat,
durchsucht werden kann. Das PDP ist das standardmäßige Discovery Protocol für alle
selbst definierten Peer Groups und der WorldPeerGroup. Es ist natürlich jederzeit
möglich, einen eigenen Peer Discovery Service zu implementieren und ihn der Peer
Group zur Verfügung stellen. Die Java Version von JXTA verwendet für die Erkundung
eine Kombination aus IP Multicasts in einem lokalen Subnetz (Broadcast im LAN) und
Rendezvous Peers im WAN.
Um ein Advertisement zu finden, erzeugt ein Peer eine Discovery Message und schickt
diese an einen Peer oder an einen Rendezvous Peer. Die Message enthält Informationen,
die den anfragenden Peer gegenüber dem Empfänger identifizieren. Der sendende Peer
erhält dann entweder eine, keine oder mehrere Antwort-Messages.
— Peer Information Protocol
Ein Peer kann mit Hilfe des Peer Information Protocol (PIP) die Fähigkeiten und den
Status eines anderen Peers abfragen. Mittels PIP ist es z.B. möglich, Informationen über
die Erreichbarkeit und die Auslastung eines Peers zu gewinnen. Die Erreichbarkeit kann
mittels der so genannten PIP Ping Message abgefragt werden. Es ist dann von der
genauen Ping Message abhängig, ob man nur ein alive, uptime oder aber ein
vollständiges Advertisement als Antwort zurückbekommt. Dieses Protokoll wird
überwiegend beim Peer Monitoring eingesetzt.
— Pipe Binding Protocol
Das Pipe Binding Protocol (PBP) dient zum Aufbau von Pipes. Mittels des PBP kann
ein Peer die zwei oder mehr Enden einer Pipe, die zu einer Verbindung gehören, mit
einem physischen Peer Endpoint verbinden. Eine Pipe kann hierbei als eine abstrakte,
mit einem Namen versehene Message Warteschlange angesehen werden, die verschiede
19
abstrakte Operationen unterstützt. Zu diesen Operationen gehören create, open, close,
delete, send und receive.
— Peer Endpoint Protocol
Das Peer Endpoint Protocol (PEP) dient zum dynamischen Finden von Routen, die das
Versenden von Messages an andere Peers ermöglichen. Das PEP definiert dafür ein Set
von Frage/Antwort Messages, um die Routing Informationen zu finden. Wenn nun ein
Peer eine Massage verschicken will und keine Informationen über die Route in seinem
lokalen Cache hat wendet er sich an einen Relay Peer. Wenn dieser die Route kennt,
gibt er als Antwort eine entsprechende Route zurück, die im Wesentlichen aus einer
Liste von Hops besteht. Auf diesem Weg kann dann die Message zum Ziel Peer
geschickt werden. Zum Einsatz kommt das PEP immer dann, wenn zwei Peers nicht
direkt miteinander verbunden sind oder nicht dasselbe Netzwerk-Transport-Protokoll
benutzen oder durch Firewalls getrennt sind. Jeder Peer der das PEP unterstützt, kann
ein Relay Peer werden. Ein solcher Peer speichert dann typischerweise Routing
Informationen.
— Rendezvous Protocol
Das Rendezvous Protocol (RVP) wird verwendet, um Messages innerhalb einer Peer
Group zu verbreiten. Ein Rendezvous Peer kann damit Messages an alle seine Klienten
und an andere ihm bekannte Rendezvous Peers weiterleiten. Das RVP ist ein simples
Protokoll, das es Peers erlaubt sich mit einem Service zu verbinden und die Verbreitung
von Messages zu kontrollieren.
Ein Peer der mit einem Rendezvous Peer verbunden ist, kann so Messages verbreiten
und verbreitete Messages empfangen. Ein unnötiges Kreisen der Messages im Netzwerk
wird verhindert, indem die Message-ID überprüft wird (loopback detection) und ein
TTL-Mechanismus zu Anwendung kommt. PRP und PBP verwenden das Rendezvous
Protocol, um ihre Messages zu verbreiten.
20
Abbildung 2.3: Project JXTA Protokolle
2.2.4.4 Der Service Layer
Der Kern von JXTA stellt lediglich die grundlegenden Funktionalitäten für ein P2PSystem zur Verfügung. Aufbauend auf dem Core Layer, also den Konzepten und
Protokollen von JXTA, definiert die JXTA-Dienstebene einen Satz von erweiterten
Funktionalitäten. Solche Dienste umfassen zum Beispiel File-Sharing, Namens- und
Suchdienste oder auch einen Indexmechanismus. Nicht zuletzt stellen die Dienste auch
allgemeingültige Funktionalitäten bereit. Einige der Dienste werden von SUN und der
JXTA-Community bereitgestellt und weitere können von jedem selbst entwickelt
werden. An dieser Stelle sei gesagt, dass es nicht notwendig ist, dass jeder Peer alle
Dienste unterstützt.
Beispiele für bereits bestehende Dienste sind z.B. cms (Content Management System),
jxta-spaces (Shard Memory) und jxta-rmi (Remote Method Invocation).
2.2.4.5 Der Application Layer
Aufbauend auf dem JXTA-Kern und den JXTA-Diensten können letztendlich die
JXTA-Anwendungen
entwickelt
werden.
Diese
Ebene
ist
somit
die
Benutzerschnittstelle (User Interface) und ermöglicht so die Nutzung der Dienste. Die
Programme können die Vorteile einer einheitlichen Architektur und eines einheitlichen
21
Kontroll- und Transportmechanismus nutzen. Sie können damit vermutlich einfacher
und schneller entwickelt werden. Beispiele für denkbare Anwendungen wären FileSharing, Ressourcen-Sharing, Instant-Messaging, Kalender oder Terminprogramme.
Eine strikte Trennung zum Service Layer ist nicht immer möglich.
Bisher
bekannte
Anwendungen
sind
z.B.
die
JXTA-Shell,
jxAuction
(Auktionsplattform) und vop2p (Voice Over P2P).
2.2.5 JXTA Anwendungen
2.2.5.1 Die JXTA-Shell1
Fester Bestandteil der JXTA-Architektur ist die JXTA-Shell. Diese stellt für Entwickler
und Anwender ein Hilfsmittel bereit, um sich mit den Möglichkeiten des Systems
vertraut zu machen. Es ist damit möglich, die Umgebung gezielt zu beeinflussen bzw.
zu kontrollieren. Die Shell an sich ist ein zeilenorientierter Kommandointerpreter
(Konsole), der es erlaubt, direkt mit der JXTA Plattform zu interagieren. Es sind
Kommandos für die verschiedensten Aufgaben enthalten, so z.B. zum Erstellen von
Advertisements, um Skripte auszuführen oder auch um mit anderen Peers
kommunizieren zu können. Die Shell kann beliebig um weitere Kommandos erweitert
werden.
2.2.5.2 myJxta2
Dient überwiegend zur Demonstration der Möglichkeiten von JXTA. Mit dieser
Anwendung wird ein leichtes navigieren im JXTA-Netzwerk ermöglicht. Bestandteile
der Anwendung sind Instant-Messaging, File-Sharing und Secure-Chat.
1
http://shell.jxta.org
http://myjxta.jxta.org
2
22
3.
Stand der Technik
Derzeit gibt es verschiedene File-Sharing-Anwendungen im Internet, die parallel
existieren und genutzt werden. Zu den Bekanntesten zählen Morpheus, KaZaA,
eMule, eDonky2000 und BearShare. Als Grundlage nutzen diese das
FastTrack-Netzwerk, das Gnutella-Protokoll oder eigene Protokolle. Weitere
Vertreter mit erweiterten Ansätzen, die über das bloße File-Sharing hinausgehen sind
z.B. Freenet und MojoNation. Die Mehrzahl dieser Anwendungen ist in C/C++
oder Java programmiert und für Windows-Umgebungen und zunehmend auch für
Einsatz unter Linux vorgesehen.
Projekte, die auf die Kombination von JXTA & Java setzen, gibt es kaum. Als
einer der wenigen Vertreter wäre die Anwendung Jnushare1 zu nennen, die aber noch
keine besondere Verbreitung gefunden hat. Die wesentlichen Bestandteile der
Anwendung sind JXTA, GISP2 und CMS3 und sie wurde mittels Java programmiert.
GISP und CMS sind JXTA-Services und als offizielle Projekte auf der JXTAHompage4 zu finden. CMS dient bei diesem Projekt lediglich zum Dateiaustausch und
GISP ist für die Suche nach Dateien verantwortlich. Bei der Implementierung des P2PSystems im Rahmen dieser Arbeit wird hauptsächlich JXTA und CMS zum Einsatz
kommen und um Aspekte der Gruppenverwaltung erweitert werden. Die Suche wird
mittels CMS geschehen.
Ein weiters aktuelles und interessantes Projekt bei dem JXTA im großem
Rahmen zum Einsatz kommt, wurde vom DFN5 (Deutsches-Forschungs-Netz) ins
Leben gerufen. Der Name des Projektes ist Science-To-Science6 (S2S). Dabei
handelt es sich um eine Kombination aus einem P2P-Netzwerk und einer
leistungsfähigen Suchmaschine. Es wird damit es möglich sein, nach wissenschaftlichen
Dokumenten zu suchen und diese auszutauschen. Das System wird auch die Suche nach
Metadaten unterstützen.
1
4
2
5
http://jnushare.jxta.org
http://gisp.jxta.org
3
http://cms.jxta.org
http://www.jxta.org
http://www.dfn.de
6
http://s2s.neofonie.de
23
4.
Die prototypische Implementierung des P2PSystems
Der Inhalt dieser Arbeit setzt sich zusammen aus der Analyse von JXTA und der
konkreten Implementierung eines P2P-Systems unter Nutzung von JXTA. Der erste Teil
der Aufgabenstellung wurde bereits im zweiten Kapitel ausführlich behandelt. Thema
dieses Kapitels wird daher der Entwurf und die konkrete Umsetzung des P2P-Systems
sein.
4.1
Entwurf
Das Haupteinsatzgebiet des P2P-Systems soll der File-Sharing-Bereich sein, d.h. es
wird primär um die Suche und den Austausch von Dateien zwischen den einzelnen
Teilnehmern des Netzwerks gehen. Bei der Umsetzung des Systems werden Teile des
von JXTA bereitgestellten Funktionsumfangs zum Einsatz kommen und neu
miteinander kombiniert werden. Am Ende der Arbeit sollte es dann möglich sein,
Aussagen über Vorteile bzw. Nachteile bei der Anwendungsentwicklung mit JXTA
machen zu können.
Bei der Entscheidung der Programmiersprache fiel die Wahl auf Java. Der
entscheidende
Grund
dafür
war,
dass
es
bereits
eine
sehr
ausgereifte
Referenzimplementierung von JXTA für diese Sprache gibt. An dieser Stelle sei
erwähnt,
dass
es
noch
weitere
Umsetzungen
von
JXTA
für
andere
Programmiersprachen gibt. Stellvertretend seien hier C/C++, Perl und Python genannt.
Alle diese Umsetzungen weisen jedoch noch nicht den Entwicklungsstand der JavaReferenzimplementierung auf. Ein weiterer Grund für den Einsatz von Java liegt in der
Natur von Java selbst. Denn ein unter Java entwickelter Klient ist problemlos auf den
verschiedensten Betriebssystemen lauffähig, wenn diese über eine Java-Unterstützung
verfügen. Dies ist bei aktuellen Betriebssystemen so gut wie immer der Fall. So war es
z.B. während der Implementierungsphase problemlos möglich, den Klienten auf einem
Windows-System zu entwickeln und später in einer Netzwerkumgebung zu testen, die
überwiegend aus Linux- und Unix-Maschinen bestand.
24
Um den Einsatzbereich des Klienten möglicht groß zu gestalteten, wurde er
derart entworfen, dass er sowohl in einer fensterbasierten als auch in einer fensterlosen
Umgebung lauffähig ist. Die Bedienung geschieht im fensterlosen Modus durch die
Konsole, mit der Einschränkung, dass nur die wesentlichsten Funktionen der
Anwendung verfügbar sind. Ein Vorteil dieses Modus ist, dass es z.B. möglich wird
sich per Telnet oder SSH auf einer Maschine einzuwählen und dann den Klienten zu
starten, zu konfigurieren und zu bedienen.
Weitere Überlegungen, die in dieser Phase notwendig waren, betreffen die
Struktur des Netzwerks, die von den Peers geschaffen wird. In der jetzigen Form
handelt es sich dabei um eine flache Struktur. Das bedeutet, dass alle Teilnehmer am
Netzwerk gleichberechtigt sind und alle dieselben Aufgaben und Funktionen
übernehmen bzw. anbieten. Neuere Konzepte bei der Organisation der Peers wie z.B.
das Superpeer-Konzept haben keinen Eingang in den Entwurf gefunden. Der
Hauptbeweggrund für diese Entscheidung war, dass das eingesetzte und bereits
bestehende Content Management System (CMS) diese Form der Strukturierung nicht
unterstützt. Das CMS ist ein Projekt der JXTA-Community und lässt sich problemlos in
die JXTA-Umgebung einbinden.
Ein weiter Aspekt der den Entwurf beeinflusste, war die Organisation der Peers
innerhalb des JXTA-Netzwerks, als eine eigenständige und abgeschlossene Gruppe. Das
Gruppenkonzept
ist
ein
zentraler
Bestandteil
von
JXTA
und
wurde
im
Grundlagenkapitel schon genauer erläutert. Die wichtigste Eigenschaft in diesem
Zusammenhang ist, dass potentielle Teilnehmer die neue Gruppe nur mit dem
entsprechenden Login und Passwort betreten dürfen.
Ein weiteres Ziel dieser Arbeit ist es, den Einsatz von JXTA ganz allgemein zu
erproben. Zu diesem Zweck wurden einige Funktionen vorgesehen, die z.B. das Suchen
nach Peers & Groups sowie das Sammeln von Informationen unterstützen. Das ist z.B.
dann sinnvoll, wenn man die Erreichbarkeit von Peers testen will, die durch
Hindernisse, wie etwa eine Firewall, nicht direkt erreichbar sind. Auch auftretende
Ereignisse, wie das korrekte Absetzen bzw. Eintreffen von Suchanfragen lassen sich
damit besser nachvollziehen.
Die Hauptfunktion des zu entwickelnden Klienten besteht im Austauschen und
Finden von Dateien. Alle Teilnehmer der Gruppe haben dabei die Möglichkeit Dateien
freizugeben und verfügbare Dateien anzufordern.
25
4.2
Implementierung
In diesem Abschnitt geht es um die konkrete Implementierung des P2P-Systems mit den
im Entwurf vorgesehen Aufgaben und Eigenschaften. Zu diesem Zweck wird ein
Überblick über die definierten Klassen und deren Aufgaben gegeben. Anhand der
einzelnen Klassen wird dann genauer erläutert, wie die einzelnen Anforderungen
umgesetzt wurden.
4.2.1 Die Hauptklasse (TestApp.java)
Diese Klasse ist die Hauptklasse der Anwendung. Sie dient zum Starten und
Initialisieren
der
Anwendung.
Sie
enthält
Methoden
zur
Auswertung
der
Konsolenparameter und -befehle, so dass das Programm im fensterlosen Modus
gestartet, bedient und konfiguriert werden kann.
Eine wichtige Aufgabe dieser Klasse ist die Konfiguration des JXTA-Peers.
Generell sind dafür zwei mögliche Wege vorgesehen. Die erste Möglichkeit besteht
darin, den JXTA eigenen Konfigurationsdialog aufzurufen (Abbildung 4.1). Mit diesem
Dialogfenster können alle wichtigen Einstellungen vorgenommen werden, damit der
Peer in der gewünschten Weise arbeitet. Dazu gehören unter anderem der Peer-Name,
die Verbindungseinstellungen, Rendezvous- bzw. Relay-Einstellungen sowie die
Angaben über den Login und das Passwort für den Peer allgemein. Jeder JXTA-Peer
verfügt über ein solches Login und Passwort, um ihn vor ungewolltem Zugriff besser zu
schützen. Die zweite Möglichkeit den Peer zu konfigurieren besteht darin, die
gewünschten Einstellungen in einer Datei einzutragen und diese Datei dem Programm
beim Start zu übergeben. Diese Form der Konfiguration ist unter anderem dann
sinnvoll, wenn der Klient auf einem System laufen soll, das über keine
Fensterunterstützung verfügt und somit der JXTA-Standard-Konfigurationsdialog nicht
verfügbar ist.
Nachdem der JXTA-Peer mit Hilfe von einer der beiden oben vorgestellten
Möglichkeiten konfiguriert wurde, werden die vorgenommenen Einstellungen
automatisch gesichert.
26
Abbildung 4.1: Der JXTA-Konfigurationsdialog
Zu diesem Zweck wird dazu von JXTA im JXTA-Home-Verzeichnis die in Abbildung
4.2 dargestellte Struktur aus Dateien und Ordnern angelegt. Der Order „cm“ dient dazu,
alle empfangenen oder erstellten Advertisements zu speichern. Diese Informationen
werden bei neueren JXTA-Versionen um zusätzliche Indextabellen ergänzt, die eine
verbesserte
Verwaltung
gewährleisten.
Der
Ordner
„pse“
enthält
sämtliche
Sicherheitseinstellungen des Peers. Das ist z.B. der Peer-Login und das verschlüsselt
gespeicherte Peer-Passwort. Die Datei „jxta.properties“ enthält einige JXTA-interne
Einstellungen. Die eigentliche Konfiguration wird letztendlich in der Datei
„PlatformConfig“ gespeichert. Diese Datei liegt im XML Format vor und kann bei
Bedarf von Hand editiert werden.
/.jxta
|-------- - /cm
|--------- /pse
|--------- jxta.properties
|--------- PlatformConfig
Abbildung 4.2: Verzeichnisstruktur die durch JXTA angelegt wird
27
Eine weitere Aufgabe dieser Klasse ist die Initialisierung der Anwendung. Dazu
gehört das Starten der JXTA-Plattform und der NetPeerGroup, als Grundlage für alle
weiteren Aktivitäten. Es werden außerdem das Content Management System und der
Group Manager gestartet. Diese beiden Komponenten werden im Rahmen ihrer
Klassenbeschreibung noch genauer erläutert. Es wird während der Initialisierung auch
der bereits oben erwähnte Ordner „cm“ samt Inhalt gelöscht, da es damit immer wieder
zu Problemen mit veralteten Advertisements von Peers, Groups und anderem Content
kam. Dieses Problem tritt verstärkt bei besonders kurzen Laufzeiten von Peers auf und
wird mit wachsender Dauer geringer. Das liegt daran, dass dann das JXTA-eigene
System die Verwaltung der Advertisements übernimmt. Die dazu notwendigen
Aktualisierungsinformationen
werden
von
JXTA
an
Hand
der
eingestellten
Lebensdauer der Advertisements bestimmt. Eine solche Lebensdauer kann für jedes
Advertisement einzeln vergeben werden.
Eine weitere Aufgabe dieser Klasse ist es, die programmeigene Einstellungsdatei
(„testapp_pref.txt“) zu laden und zu speichern. In dieser Datei sind unter anderem die
Informationen zum Download- und Freigabeverzeichnis abgelegt. Auch die Logins und
Passwörter für den Peer und die Peer Group können mit dieser Datei eingestellt werden.
4.2.2 Das Content Management System (CMSystem.java)
Das CMS ist die Grundlage für die Realisierung der File-Sharing-Funktionalität der
Anwendung. Beim CMS handelt es sich um einen einfachen Service von JXTA, der
wiederum selbst auf anderen JXTA Services aufsetzt. Aus diesem Grund werden in der
folgenden Beschreibung die Grundlagen des CMS etwas genauer erläutert und dann
beschrieben, wie der Service in dieser Arbeit genutzt wird.
Das CMS ist ein Service mit dem Dateien zwischen den Peers einer Gruppe
geteilt werden können. Der Service bietet die Möglichkeit Dateien anzubieten, zu
suchen bzw. zu finden und letztendlich die angeforderten Dateien von anderen Peers zu
empfangen. Beim CMS handelt es sich in der jetzigen Form noch um einen sehr
einfachen Service mit begrenztem Funktionsumfang. So verfügt das CMS über keinen
ausgereiften Suchmechanismus und auch die Verteilung bzw. Erreichbarkeit der Daten
ist in keinster Weise zuverlässig.
28
Für zukünftige Versionen ist es deshalb angedacht, die CMS-Suche durch die
deutlich leistungsfähigere Suche des Projektes „JXTA Search“ zu ersetzen. „JXTA
Search“ ist ein weiteres Projekt der JXTA-Community und ist auf der Homepage von
JXTA zu finden. Es ist weiterhin geplant, den Datentransfer deutlich zu verbessern, da
dieser bisher sehr simpel gehalten ist. So fehlen z.B. Funktionen um abgebrochene
Downloads wieder aufzunehmen oder eine Datei von mehreren Quellen (gleichzeitig)
zu laden.
Der folgende Abschnitt wird sich etwas genauer mit der Arbeitsweise und der
Funktion des CMS befassen. So ist es beispielsweise eine der ersten Aktionen beim
Starten des CMS, dass ein Verzeichnis mit dauerhaften Informationen eingelesen wird.
Sollte dieses Verzeichnis noch nicht vorhanden sein, so wird es neu erstellt. Dieses
Verzeichnis enthält Informationen über eigene Freigaben, sowie Angaben über bereits
empfangene Informationen und über Freigaben von anderen Peers. Das Verzeichnis
wird
dann
einem
so
genannten
ContentManager
übergeben.
Der
ContentManager ist ein wichtiger Bestandteil des CMS und übernimmt die weitere
Verwaltung der Freigabeinformationen. Seine Aufgabe ist es dann, auf Anfragen von
anderen Peers zu warten. Die eintreffenden Suchanfragen (Requests) werden so
automatisch durch den ContentManager verarbeitet.
Beim CMS kann im Wesentlichen zwischen zwei Request-Typen unterschieden
werden: Den so genannten LIST-Requests und den GET-Requests. Ein LIST-Request
wird abgesetzt, um eine Liste mit allen Freigaben eines Peers zu bekommen. Die
Antwort auf einen solchen Request enthält die Content-Advertisements von dem
gesamten Content, der freigegeben wurde. Der GET-Request wird verwendet, um einen
bestimmten Content anzufordern. Ein solcher Request enthält einen Content-Identifier,
um den gewünschten Content eindeutig bestimmen zu können. Die entsprechende
Antwort enthält dann die aktuellen Daten des angeforderten Content.
Im weiteren Teil zur Beschreibung dieser Klasse wird es nun um den konkreten Einsatz
des CMS gehen. Eine der ersten Methoden dieser Klasse dient dazu, den Service zu
starten und ihn somit nutzen zu können. Wie bereits oben beschrieben, wird nach dem
Starten des Service ein Verzeichnis angelegt, in dem die dauerhaften Informationen
über die freigegeben Dateien abgelegt werden. Das Verzeichnis selbst enthält wiederum
Unterverzeichnisse für alle Gruppen, in denen der Peer Mitglied ist. Die
Freigabeinformationen werden so gruppenweise gespeichert. Die Klasse enthält
29
weiterhin eine Methode, mit der ein Verzeichnis mit Dateien für die Peer Group
freigegeben werden kann. Diese Methode übergibt das Freigabeverzeichnis an den
ContentManager, der dann wieder die weitere Verwaltung übernimmt. Das
Verzeichnis wird rekursiv durchlaufen, so dass eventuelle weitere Verzeichnisse mit
Dateien erfasst werden können.
Zwei weitere Methoden sind für die Suche und den Download der Dateien
verantwortlich. Diese funktionieren im Wesentlichen nach den bereits erwähnten LISTund GET-Requests.
Bei einer konkreten Suche nutzt der CMS bisher nur den Namen einer Datei und
bietet keine erweiterten Möglichkeiten, wie etwa nach der eindeutigen ContentID zu
suchen. Dieses Manko wird etwas dadurch entschärft, dass es die Möglichkeit gibt, auch
nach Teilstrings zu suchen. Das ist immer dann sinnvoll, wenn der vollständige Name
einer Datei nicht genau bekannt ist. Eine weitere Möglichkeit der einfachen Suche
besteht bei lokalen Advertisements. Diese können mittels eines ContentFilter
nach den gewünschten Kriterien durchsucht werden. Der ContentFilter ist ein
Bestandteil des CMS und kommt bei dieser Arbeit nicht zum Einsatz.
Ein weiterer Bestandteil der Klasse sind Subklassen für die Bearbeitung der
LIST- und GET-Requests. Sie sind daher eng mit den Methoden für die Suche bzw. den
Download der Dateien verknüpft. Sie sind dafür verantwortlich, den CMS betreffende
Meldungen zu erfassen und auszuwerten. So werden z.B. eingehende Suchanfragen
registriert und Antworten auf selbst gesendete Anfragen angezeigt. Es lässt sich auch
der Fortschritt bei der Übertragung einer angeforderten Datei ablesen, was von Vorteil
sein kann, wenn diese sehr groß ist.
An
dieser
Stelle
noch
ein
kurzer
Hinweis
zum
Verhalten
des
ContentManagers. Dies betrifft eventuelle längere Wartezeiten, wenn ein
Verzeichnis mit Freigaben das erste Mal an diesen übergeben wurde oder aber der
Inhalt des Verzeichnisses geändert wurde. Diese Wartezeiten resultieren daraus, dass
der ContentManager für jede Datei die eindeutige ContentID, eine MD5Checksumme berechnet. Die Bestimmung dieser ID kann bei größeren Dateien eine
gewisse Zeit dauern, abhängig von der vorhandenen Rechenkraft und Auslastung eines
Peers.
30
4.2.3 Der Group Manager (GroupManager.java)
Die Aufgabe dieser Klasse ist es, die geplante Gruppenverwaltung zu realisieren. Dazu
gehören Methoden zum Anlegen der Gruppe, die Möglichkeit die Gruppe zu betreten
bzw. wieder zu verlassen und die Authentifizierung der Peers.
Eine Entscheidung die im Zusammenhang mit der Erstellung der neuen Gruppe
getroffen wurde, ist, dass die Gruppe eine eindeutige Identifizierung braucht. Das
Problem hierbei ist, dass JXTA standardmäßig bei jedem Erstellen einer Gruppe nur
eine temporär eindeutige ID vergibt, d.h. bei jedem Starten der Anwendung würde sich
die Gruppen-ID ändern. Aus diesem Grund wird die Gruppen-ID statisch vergeben. Die
vergebene Gruppen-ID lautet: jxta:uuid-4d6172676572696e204272756e6f202002.
Eine der wichtigsten Aufgaben der Klasse ist die Realisierung der Authentifizierung,
die dafür sorgt, dass nur dafür vorgesehene Peers die Gruppe betreten dürfen. Eine
Standardgruppe unter JXTA stellte einen solchen Mechanismus nicht zur Verfügung, so
dass dieser nachträglich integriert werden musste. Im Folgenden wird es also
hauptsächlich um das Vorgehen beim Erstellen der Gruppe und die Implementierung
der Authentifizierung gehen.
Ganz allgemein handelt es sich bei der Anmeldung bzw. Mitgliedschaft einer
Gruppe um einen Service, den die Gruppe bereitstellt. Damit für die neue Gruppe nicht
alle Standardservices einer JXTA-Gruppe neu erstellt werden müssen, ist es sinnvoll,
diese von der NetPeerGroup zu übernehmen. Die NetPeerGroup ist dafür besonders
geeignet, da diese Gruppe in JXTA die Grundlage für alle weiteren Gruppen ist.
Nachdem die Services übernommen wurden besteht der nächste Schritt darin, die Liste
der Services zu Durchlaufen und den bestehenden Service für die Mitgliedschaft zu
entfernen.
Bei
JXTA
ist
das
standardmäßig
der
so
genannte
NullMembershipService, der keine weitere Authentifizierung der Peers verlangt.
Die Stelle des entfernten Services kann dann der neue Membership-Service einnehmen.
Um die Entwicklung eines solchen Services zu erleichtern, ist bei JXTA bereits ein sehr
einfacher, auf Login und Passwort basierender Membership-Service in der
Referenzeimplementierung vorgesehen. Dieser Service wird bei der hier vorliegenden
Arbeit
auch
zum
Einsatz
kommen.
Der
Name
des
Services
lautet
PasswdMembershipService. Dabei ist anzumerken, dass dieser Service nur zur
31
Veranschaulichung dient und keine wirkliche Zugangssicherheit zur Gruppe bietet. Das
liegt vor allem daran, da das Verschlüsselungsschema, welches bei der Kodierung des
Passworts zum Einsatz kommt, recht einfach gehalten ist. Das so verschlüsselte
Passwort, welches in jedem GroupAdvertisement mitgeschickt wird, ist nicht
mehr geheim zu halten. Es ist aber durchaus vorstellbar, an dieser Stelle eine sichere
Verschlüsselung
des
Passworts
zu
gewährleisten,
wenn
die
JXTA-eigenen
Verschlüsselungsbibliotheken zum Einsatz kommen.
Bei der realen Implementierung werden die Services in Form von
Advertisements verwaltet. Um das weitere Vorgehen beim Erstellen der Gruppe zu
erläutern, werden die nächsten Schritte an Hand dieser Advertisements gezeigt, da diese
sehr anschaulich gehalten sind.
Nachdem also das Advertisement für den Membership-Service ausgetauscht
wurde, muss das vollständige Advertisement, welches alle Services der Gruppe enthält,
noch verbreitet werden. Bei diesem neuen Advertisement handelt es sich um ein so
genanntes ModuleImplAdvertisement, welches in JXTA eine veröffentlichte
Implementation einer gegebenen Spezifikation darstellt - d.h. damit werden angebotene
Services für potentielle Teilnehmer bekannt gemacht. Zur besseren Veranschaulichung
sind die oben beschrieben Advertisements in Abbildung 4.3 & Abbildung 4.4 noch
einmal in ihrer XML-Notation angegeben. Diese Notation entspricht gleichzeitig der
Form, mit der die Advertisements im JXTA-Netzwerk ausgetaucht werden.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jxta:MIA>
gekürzt!
<jxta:MIA xmlns:jxta="http://jxta.org">
<MSID>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000050206
</MSID>
<Code>
net.jxta.impl.membership.PasswdMembershipService
</Code>
<PURI>
http://www.jxta.org/download/jxta.jar
</PURI>
<Prov>
sun.com
</Prov>
<Desc>
ModuleImplAdvertisement for the PasswdMembership Service
</Desc>
</jxta:MIA>
Abbildung 4.3: Advertisement des neuen Membership-Service (moduleAdv)
32
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jxta:MIA>
gekürzt!
<jxta:MIA xmlns:jxta="http://jxta.org">
<Code> net.jxta.impl.peergroup.StdPeerGroup </Code>
<Desc> General Purpose Peer Group Implementation </Desc>
<Parm>
<Svc>
<Code> net.jxta.impl.access.always.AlwaysAccessService </Code>
<Desc> Reference Implementation of the Always Access service <Desc>
<Code> net.jxta.impl.rendezvous.RendezVousServiceImpl </Code>
<Desc> Reference Implementation of the Rendezvous service <Desc>
<Code> net.jxta.impl.membership.PasswdMembershipService </Code>
<Desc> ModuleImplAdvertisement for the PasswdMembership Service <Desc>
<Code> net.jxta.impl.endpoint.EndpointServiceImpl </Code>
<Desc> Reference Implementation of the Endpoint service <Desc>
<Code> net.jxta.impl.discovery.DiscoveryServiceImpl </Code>
<Desc> Reference Implementation of the Discovery service <Desc>
<Code> net.jxta.impl.peer.PeerInfoServiceImpl </Code>
<Desc> Reference Implementation of the Peerinfo service <Desc>
<Code> net.jxta.impl.resolver.ResolverServiceImpl </Code>
<Desc> Reference Implementation of the Resolver service <Desc>
<Code> net.jxta.impl.pipe.PipeServiceImpl </Code>
<Desc> Reference Implementation of the Pipe service <Desc>
</Svc>
<App>
...
</App>
</Parm>
</jxta:MIA>
Abbildung 4.4: Advertisement mit allen Services der Gruppe (ModuleImplAdv)
Der nächste Schritt beim Erzeugen der Gruppe besteht darin, ein
PeerGroupAdvertisement zu erstellen. Ein solches Advertisement enthält die
wichtige GroupID, den Namen der Gruppe und eine kurze Beschreibung. Zusätzlich
wird bei diesem Advertisement noch die Information für den Membership-Service
angehangen. Diese Information ist wie zu erwarten, der Login und das in verschlüsselter
Form abgelegte Passwort. Das so erweiterte PeerGroupAdvertisement (Abbildung
4.5) muss dann wiederum verbreitet werden, damit Peers die Möglichkeit haben die
Gruppe zu finden und ihr beizutreten.
33
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jxta:PGA>
<jxta:PGA xmlns:jxta="http://jxta.org">
<GID>
urn:jxta:uuid-4D6172676572696E204272756E6F202002
</GID>
<MSID>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE000000010406
</MSID>
<Name>
SecureGroup
</Name>
<Desc>
SecureGroup -> Mit Login/Password - MembershipService
</Desc>
<Svc>
<MCID>
urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000505
</MCID>
<Parm>
<login>
login:SWPPDJFA:
</login>
</Parm>
</Svc>
</jxta:PGA>
Abbildung 4.5: Das PeerGroupAdvertisement (pgAdv)
Die Klasse enthält neben der Methode zum Erstellen der Gruppe eine zweite wichtige
Methode. Diese Methode regelt den Ablauf, mit dem der Gruppe beigetreten werden
kann. Der Vorgang beim Beitritt kann in drei Schritte unterteilt werden. Der erste
Schritt besteht darin, die Methode applyToMembershipService aufzurufen, um
die Aufnahme in den Membership-Service zu beantragen. Das Ergebnis dieser Methode
wird an einen „Authenticator“ übergeben. Im zweiten Schritt wird mit diesem
Authenticator die Methode completeAuth aufgerufen und damit die Richtigkeit des
Logins und des Passworts überprüft. Am Ende dieser Überprüfung wird eine
Rückmeldung über den Erfolg bzw. Misserfolg ausgegeben. Der letzte Schritt nach
einer erfolgreichen Prüfung besteht darin, die Methode joinMembershipService
aufzurufen und so dem Membership-Service beizutreten. Die Folge dieses Aufrufs ist
dann die ordnungsgemäße Mitgliedschaft in der Gruppe.
34
4.2.4 Informationen zum Netzwerk (NetworkInfo.java)
Zusätzlich zur reinen Erstellung des P2P-Systems ist es ein weiteres Ziel dieser Arbeit,
JXTA und dessen Funktionsweise etwas genauer zu analysieren. Um sinnvolle
Informationen über das JXTA-Netzwerk sammeln zu können, wurde die Klasse
„NetworkInfo“ implementiert. Sie enthält bislang nur die Möglichkeit nach Peers und
Groups zu suchen. Zu Peers und Groups, die mit dieser Suchfunktion gefunden wurden,
lassen sich genauere Informationen abrufen. Dazu gehören z.B. die eindeutige ID, eine
kurze Beschreibung und der Name.
Eine andere Methode der Klasse dient dazu, den lokalen Cache zu leeren. Dieser
enthält alle empfangenen Advertisements zu bereits gefundenen Peers und Peer Groups.
Die Notwendigkeit solche Advertisements löschen zu können, entstand daraus, dass es
immer wieder zu Problemen mit nicht mehr aktuellen Daten kam. So konnte es z.B.
durchaus passieren, dass einige Peers noch angezeigt wurden, obwohl sie das Netzwerk
schon längere Zeit verlassen hatten.
4.2.5 Hilfsklasse (Utility.java)
Diese Klasse enthält einige wenige Methoden, die programminterne Aufgaben lösen.
Das sind z.B. das Festlegen der Fenstergröße der Anwendung und die Positionierung
auf dem Desktop. Es ist auch eine Subklasse enthalten, die zum korrekten Beenden der
Anwendung dient.
4.2.6 Die graphische Benutzerschnittstelle (GUI.java)
Der Zweck dieser Klasse lässt sich leicht aus dem Namen erschließen. Die Aufgabe
dieser Klasse ist somit die Realisierung der grafischen Schnittstelle zum Programm. Die
dort vereinbarten Methoden werden also immer dann benötigt, wenn das Programm im
Fenstermodus betrieben werden soll. Die Dialogelemente werden mittels der JavaSwing-Komponenten erzeugt.
35
Abbildung 4.6: Das graphische Interface der Anwendung
4.3
Probleme während der Umsetzung des Entwurfs
Einige der Schwierigkeiten dieser Arbeit entstanden beim Wechsel der eingesetzten
JXTA-Version. Es kam zu diesen Problemen, weil zu Beginn des Entwurfs und zu
Testzwecken eine JXTA-Version vom Juli 2002 zum Einsatz kam und es im Verlauf der
Implementierung notwendig wurde, auf eine aktuellere Version umzusteigen. Mit der
neuen Version war es dann möglich, alle Funktionen zu integrieren, die im Entwurf
vorgesehen waren. Eine der Änderung betraf z.B. das Erstellen der JXTA-Einstellungen
mit Hilfe der Konfigurationsdatei im fensterlosen Modus, dass in dieser Form nicht in
der alten Version vorgesehen war. Beim Versionswechsel kam es zu auch zu Problemen
mit anderen JXTA-Funktionen, die durch Änderungen an JXTA allgemein verursacht
wurden. Das umfasst Namensänderungen von Konstanten und Variablen sowie
Änderungen bei der Übergabe von Parametern an bestimmte Methoden. Diese
Änderungen an JXTA sind aber nicht als Nachteil zu werten, da JXTA so ständig
weiterentwickelt und verbessert wird. Diese Modifikationen sind somit als vorteilhaft
für den Entwickler einzuschätzen.
36
An dieser Stelle möchte ich auch auf darauf hinweisen, dass JXTA das sehr
verbreitete CVS-Konzept vollständig unterstützt. Damit war es zum Beispiel in relativ
kurzer Zeit möglich, den oben beschrieben Problemen auf den Grund zu gehen und
diese zu beheben. Sämtliche Quellcodes von JXTA und viele der JXTA-Projekte
werden mittels CVS verwaltet. Diese Tatsache und der sehr gut nutzbaren CVSFunktionen auf der JXTA-Hompage sind geeignete Mittel, um Änderungen im
Quellcode von JXTA nachzuvollziehen und das eigene Programm entsprechend
anzupassen.
5.
Fazit
Das wesentliche Ziel dieser Arbeit bestand im Erstellen eines P2P-Systems mit Hilfe
von JXTA. Dabei sollten die Vorteile von JXTA genutzt werden und eventuelle
Nachteile aufgezeigt werden. Zum Abschluss dieser Arbeit kann man sagen, das JXTA
eine solide Grundlage für die Entwicklung von P2P-Systemen ist. Es besitzt einen
großen Funktionsumfang und eine gute Dokumentation. Zudem erfährt es eine ständige
Weiterentwickelung, Erweiterung und Verbesserung. Die Erleichterung beim Umgang
mit dem zugrunde liegenden Netzwerk ist durchaus vorhanden und es konnte mehr
Augenmerk auf die Realisierung der eigentlichen Funktion der Anwendung gelegt
werden. Dazu war es natürlich notwendig, sich zu Beginn der Arbeit intensiv mit JXTA
und seinen Bestandteilen auseinander zusetzen, um die bestehenden Möglichkeiten auch
nutzen zu können. Die Frage mit der tatsächlichen Interoperabilität lässt sich nicht
eindeutig beantworten. Das liegt daran, dass die verschiedenen Anwendungen zwar
JXTA nutzen können aber für spezielle Dienste entsprechend vorbereitet werden
müssen und so nur über grundlegende gemeinsame Funktionen verfügen. Das zweite
wesentliche Ziel von JXTA, die Plattformunabhängigkeit, kann bei dieser Arbeit als
erreicht angesehen werden.
37
6.
Abkürzungsverzeichnis
P2P
Peer-to-Peer
NAT Network Adress Translation
PDA Personal Digital Assistant
XML Extensible Markup Language
URI
Uniform Resource Identifier
URN Uniform Resource Name
UUID Universal Unique Identifier
TTL
Time To Live
SSH
Secure Shell
GUI
Graphical User Interface
CMS Content Management System
GISP Global Information Sharing Protocol
CVS
Concurrent Versions System
38
7.
Literaturverzeichnis
1.
JXTA Hompage
URL: http://www.jxta.org/
2.
Gong, Li (2001): JXTA: A Network Programming Environment
URL: http://www.jxta.org/project/www/docs/JXTAnetworkProgEnv.pdf
3.
Traversat, Bernard (2002): Project JXTA Virtual Network
URL:
4.
http://www.jxta.org/project/www/docs/JXTAprotocols_01nov02.pdf
Sun Microsystems, Inc.: Project JXTA: Java Programmer’s Guide
URL: http://www.jxta.org/docs/jxtaprogguide_final.pdf
5.
Baehni, Sebastien: Java User Group Switzerland: P2P-JXTA-TPS
URL:
http://lpdwww.epfl.ch/sbaehni/work/presentations/tbpsjxta/jugs.ppt
6.
Brookshier, Daniel (2002): JXTA: Java P2P Programming
7.
Wilson, Brendon (2002): JXTA
URL: http://www.brendonwilson.com/projects/jxta
8.
Project JXTA Tutorials: ProgGuideExamples
URL: http://www.jxta.org/project/www/Tutorials.html
39
A. Softwareinstallation
Systemvoraussetzungen
Da die Anwendung mit Java programmiert wurde, ist sie auf allen Betriebssystemen die
Java
unterstützen
lauffähig.
Um
einen
ungefähren
Anhaltspunkt
für
die
Systemvoraussetzungen zu bekommen, sind nachstehend die Bedingungen aufgeführt,
unter denen die Anwendung entworfen wurde:
-
PC mit einem Betriebssystem vom Typ Windows(TM)oder Linux
-
Java(TM) 2 Runtime Environment (Version 1.3.1-1.4)
Benötigte Software
Zum installieren sind folgende Dateien notwendig:
-
die JXTA-Bibliotheken
(jxta.jar, log4j.jar, jxtasecurity.jar, jxtaptls.jar,
minimalBC.jar, cryptix-asn1.jar, cryptix32.jar,
jxtacms.jar, javax.servlet.jar, org.mortbay.jetty.jar,
jxtashell.jar)
-
die Quelldateien
(CMSystem.java, GroupManager.java, GUI.java,
NetworkInfo.java, TestApp.java, Utility.java)
-
die beiden Konfigurationsdateien testapp_pref.txt und configfile.txt
-
die Dateien compileIt, jarIt und startIt
Installationsschritte
0.
Installation der Java(TM) 2 Runtime Environment.
40
1.
Ein beliebiges Verzeichnis anlegen und darin die Ordner lib, src,
classes und Cms_dirs erstellen.
2.
Im Verzeichnis Cms_dirs die Ordner Download und Share anlegen.
3.
Die JXTA-Bibliotheken (*.jar) in den lib Ordner kopieren.
4.
Die Quelldateien der Anwendung (*.java) im Ordner src ablegen.
5.
Die beiden Konfigurationsdateien testapp_pref.txt und configfile.txt
in das Verzeichnis aus Schritt eins kopieren.
6.
Die Dateien compileIt, jarIt und startIt mit den Endungen bat bzw. sh
auch in das Verzeichnis aus Schritt eins kopieren.
7.
Wenn die Verzeichnisstruktur der Schritte 1-6 eingehalten wurde, können die
drei Dateien wie folgt benutzt werden:
-
compIt: zum Kompilieren der Quelldateien
-
jarIt: zum Packen der mittels compIt erstellten Java Klassendateien
-
startIt: zum Starten der Anwendung
Sollte die Verzeichnisstruktur nicht so aussehen, wie in Schritt 1-6 vorgesehen, dann
müssen die obigen Dateien entsprechend angepasst werden, um sie nutzen zu können.
41
B.
Bedienungsanleitung
An dieser Stelle eine kurze Übersicht zu den Parametern und Befehlen mit der die
Anwendung ohne GUI gestartet, gesteuert und konfiguriert werden kann.
1.
Zum Start der Anwendung ohne GUI ist der Parameter „nowindow“ vorgesehen
und wird zu diesem Zweck wie folgt übergeben:
„java -classpath ... TestApp –nowindow“
2.
Damit die Anwendung ohne GUI bedient werden kann sind folgende Befehle
enthalten und können über die Kommandozeile eingegeben werden:
„c [ENTER]“ - zum Anzeigen der verfügbaren Befehle
„p [ENTER]“ - initiiert die Suche nach Peers
„g [ENTER]“ - initiiert die Suche nach Peer Groups
„f [ENTER]“ - leert den lokalen Advertisement-Cache
„x [ENTER]“ - beendet die Anwendung
„s "SearchString" [ENTER]“
- sucht nach Dateien, die den Inhalt des SearchString im Namen aufweisen
- ist der SearchString leer, werden alle verfügbaren Dateien gesucht
„d "FileIndex" [ENTER]“
- überträgt eine durch den FileIndex gewählte Datei
- der FileIndex einer Datei steht in eckigen Klammern am Beginn einer
Zeile, die bei einer Suche als Suchergebnis ausgegeben wird,
z.B. „[x] Ergebnis1“
3.
Damit der JXTA-Peer auch im fensterlosen Modus konfiguriert werden kann,
ist der Parameter „setconfig“ vorgesehen und wird wie folgt eingesetzt:
„java –classpath ... TestApp –setconfig „configfile.txt“ “
Die Datei configfile.txt enthält alle notwendigen Parameter, um den Peer
zu konfigurieren und muss entsprechend dem vorgesehenen Einsatzbereich
angepasst werden.
42