Entwurf und Implementierung eines verteilten Systems zur Suche

Entwurf und Implementierung eines verteilten Systems zur Suche

Diplomarbeit
Entwurf und Implementierung
eines verteilten Systems
zur Suche und Analyse
von Dateien in Peer-to-Peer
Netzen
Michael Wagner
#653287
Alter Wetzlarer Weg 3
35392 Giessen
[email protected]
Betreuer
:
Prof. Peter Sturm (Universität Trier)
Dr. Martin Steinebach (Fraunhofer IPSI)
Eingereicht am
:
8. Januar 2007
Erklärung
Hiermit erkläre ich, dass ich die Diplomarbeit selbstständig verfasst und keine anderen als
die angegebenen Quellen und Hilfsmittel benutzt und die aus fremden Quellen direkt oder
indirekt übernommenen Gedanken als solche kenntlich gemacht habe. Die Diplomarbeit habe
ich bisher bei keinem anderen Prüfungsamt in gleicher oder vergleichbarer Form vorgelegt.
Sie wurde bisher auch nicht veröffentlicht.
Trier, 8. Januar 2007
”
Phantasie ist wichtiger als Wissen,
denn Wissen ist begrenzt.“
Albert Einstein
Für meine Eltern. Und Anke.
Danksagung:
Ich danke meinen Eltern, die mir dieses Studium ermöglicht haben und die mir auch in
schweren Zeiten zur Seite gestanden haben. Weiter gilt mein Dank meiner Liebe Anke, die
immer für mich da ist. Eine besondere Anerkennung verdient Herr Dr. Martin Steinebach,
der mich während der ganzen Diplomarbeitsphase sehr geduldig unterstützt hat. Nicht zu
vergessen an dieser Stelle ist Herr Professor Peter Sturm, der durch seine unterhaltsamen
und zugleich lehrreichen Vorlesungen, mein Interesse für das Gebiet der verteilten Systeme
geweckt hat. Zudem gilt ihm mein Dank für die Unterstützung und Betreuung während
der Diplomarbeit. Ein letzter Dank gilt meinen Geschwistern, die mir, wo sie nur konnten,
geholfen haben und meinen Korrekteuren für ihre gründliche Arbeit.
VI
Kurzfassung
Trotz aller Versuche der Musik- und Filmindustrie gegen angebliche Datenpiraten und
Tauschbörsennutzer vorzugehen, wird Filesharing immer beliebter. Wasserzeichen stellen dabei eine gute Methode dar, um urheberrechtlich geschütztes Material zu markieren. Damit
ist es möglich, unerlaubte Kopien zu identifizieren und gegen den Benutzer vorzugehen. Um
diese Identifizierung durchführen zu können, müssen zuerst einmal in der entsprechenden
Filesharing-Software von jedem anbietenden Benutzer die Datei bzw. ein Teil der Datei heruntergeladen werden.
Ziel der Diplomarbeit ist es, eine verteilte Lösung zum Download von diesen Dateien auf der
Basis einer von Schlüsselworten gesteuerten Suche zu entwerfen. Hierzu wird ein geeignetes
Netzwerk ausgewählt und ein als Open Source vorliegender Client so modifiziert, dass er
(a) automatisiert abhängig von Schlüsselworten Dateien herunterladen kann und (b) diesen
Suchvorgang mit anderen Clients gleichen Typs synchronisieren und Kollisionen auflösen
kann.
VII
Abstract
Despite all attempts of the Music and Film industries to fight them, data piracy and the
use of file sharing programmes are becoming increasingly popular. Watermarks offer a good
possibility of identifying illegal copies and to prosecute their users as they can be used to
mark copyrighted materials. Preliminary to this identification, users have to have downloaded
the concerned data at least partially by use of the corresponding file sharing software.
The aim of this Diplomarbeit is to find a distributed solution to download said data based
on a keyword-driven search. For this thesis, a suitable network must be chosen and an Open
Source Client must be modified in such a way that it a) is able to automatically download
files appropriate to the given keyword, and that it b) is able to synchronise this search with
other clients of a similar type whilst preventing collisions.
IX
Inhaltsverzeichnis
Erklärung
III
Kurzfassung
VI
Abstract
VII
Abkürzungsverzeichnis
XV
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen und Analyse
2.1 Piraterie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Geschichte der Schwarzkopie . . . . . . . . . . . . . . . .
2.1.2 Motivation und Psychologie des Schwarzkopierens . . . .
2.1.3 Rechtliche Aspekte . . . . . . . . . . . . . . . . . . . . .
2.1.4 Maßnahmen gegen Schwarzkopierer . . . . . . . . . . . .
2.1.5 Ökonomische Folgen . . . . . . . . . . . . . . . . . . . .
2.1.6 Existierende Lösungsansätze zur Pirateriebekämpfung . .
2.2 Digitale Wasserzeichen . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Eigenschaften eines Wasserzeichen-Verfahrens . . . . . .
2.2.2 Anwendungsgebiete digitaler Wasserzeichen . . . . . . .
2.2.3 AlgorithmManager . . . . . . . . . . . . . . . . . . . . .
2.3 Verteilte Systeme . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Tauschbörsen . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1.1 Napster . . . . . . . . . . . . . . . . . . . . . .
2.4.1.2 Bittorrent . . . . . . . . . . . . . . . . . . . . .
2.4.1.3 eDonkey . . . . . . . . . . . . . . . . . . . . . .
2.4.1.4 Kademlia . . . . . . . . . . . . . . . . . . . . .
2.4.2 JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2.1 Wichtige Grundbegriffe der JXTA-Technologie .
2.4.3 Klassifizierung von Peer-to-Peer-Systemen . . . . . . . .
1
1
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
7
8
10
11
13
15
18
18
19
20
23
24
26
28
28
31
31
32
34
3 Entwurf
3.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Ablauf der Suche und Analyse . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
37
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
X
Inhaltsverzeichnis
3.3
3.4
3.5
3.6
3.7
.
.
.
.
.
.
.
.
39
41
42
43
44
44
45
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
47
48
49
54
55
55
56
57
57
59
60
60
61
.
.
.
.
62
62
64
65
66
6 Zusammenfassung und Ausblicke
6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Ausblicke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
68
69
A Klassendiagramme
71
B Die optimale Konfiguration von eMule
73
C Anleitung zur Nutzung des entwickelten Systems
75
D Inhalt der CD-ROM zur Arbeit
77
E Kuriositäten-Sammlung
78
Literaturverzeichnis
80
3.8
Anforderungen . . . . . . . . . . . . . . . .
Ausnahmefälle . . . . . . . . . . . . . . . . .
Lastverteilung . . . . . . . . . . . . . . . . .
Schnittstelle zu Internet-Tauschbörsen . . .
Wahl der verwendeten Komponenten . . . .
3.7.1 Wahl der Tauschbörse . . . . . . . .
3.7.2 Wahl der Kommunikationsplattform
Datei-Identifikation . . . . . . . . . . . . . .
4 Implementierungsaspekte
4.1 Entwicklungsumgebung . . . . . . . .
4.2 Aufbau des Prototypen . . . . . . . .
4.2.1 Basisklasse Peer . . . . . . . .
4.2.2 Datenverwaltung . . . . . . .
4.2.3 Aufbau des Masters . . . . . .
4.2.3.1 Monitoring . . . . .
4.2.3.2 Dispatcher . . . . .
4.2.3.3 Dienste des Masters
4.2.3.4 Benutzerschnittstelle
4.2.4 Aufbau eines Slaves . . . . . .
4.2.4.1 Anbindung an eMule
4.2.4.2 Systeminformationen
4.2.4.3 AlgorithmWorker . .
4.2.4.4 Dienste des Slaves .
5 Evaluation und Leistungsbeurteilung
5.1 Testumgebung . . . . . . . . . . .
5.2 Funktionstests . . . . . . . . . . .
5.3 Laborversuch . . . . . . . . . . .
5.4 Praxistest . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XI
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
Verbreitungspyramide . . . . . . . . . . . . . . . . . .
Gründe gegen eine Nutzung kommerzieller Angebote .
Umsatzverluste durch Piraterie . . . . . . . . . . . . .
Nutzung verschiedener Kanäle für den Musik-Download
Einbetten und Auslesen eines digitalen Wasserzeichens
algoDescription.xml . . . . . . . . . . . . . . . . . . . .
Middleware . . . . . . . . . . . . . . . . . . . . . . . .
Serverbasiertes und serverloses Peer-to-Peer-Netz . . .
Aufbau des Napster-Netzwerkes . . . . . . . . . . . . .
BitTorrent-Netzwerk . . . . . . . . . . . . . . . . . . .
eDonkey-Netzwerk . . . . . . . . . . . . . . . . . . . .
Die JXTA-Architektur . . . . . . . . . . . . . . . . . .
. .
. .
. .
im
. .
. .
. .
. .
. .
. .
. .
. .
. . . . .
. . . . .
. . . . .
Internet
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
7
11
12
17
20
22
25
28
29
30
33
3.1
3.2
3.3
3.4
3.5
Digitales Wasserzeichen zur Identifikation .
Blackbox Wasserzeichen-Analyse . . . . .
Systemübersicht . . . . . . . . . . . . . . .
Ablauf der Suche und Analyse . . . . . . .
Schnittstelle zu Internet-Tauschbörsen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
37
38
43
4.1
4.2
4.3
4.4
4.5
4.6
4.7
Überklasse Peer . . . . . . . . . . . . .
Schnittstelle zur Datenbank . . . . . .
Peer Monitor . . . . . . . . . . . . . .
Dispatcher . . . . . . . . . . . . . . . .
Benutzerschnittstelle . . . . . . . . . .
Benutzerschnittstelle Slave - Übersicht
Benutzerschnittstelle Analyse . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
49
55
56
58
58
59
5.1
5.2
5.3
5.4
5.5
Testumgebung 1 . . . . .
Testumgebung 2 . . . . .
Testumgebung 3 . . . . .
Ergebnisse Laborversuch
Feldversuch . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
64
66
67
A.1 Klassendiagramm Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Klassendiagramm Slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
72
C.1 Einstellungsassistent des Slaves . . . . . . . . . . . . . . . . . . . . . . . . .
75
E.1 Buch: The Crow Who Could Fly . . . . . . . . . . . . . . . . . . . . . . . .
78
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XII
Abbildungsverzeichnis
E.2 Buch: The Pig And The Box . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.3 Parodie RIAA - Plakat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
79
XIII
Tabellenverzeichnis
2.1
Klassifizierung der Peer-to-Peer-Systeme . . . . . . . . . . . . . . . . . . . .
34
3.1
Kriterien zur Lastverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
peers.xml . . . . .
results.xml . . . . .
searches.xml . . . .
server.xml . . . . .
files.xml . . . . . .
wm results.xml . .
algorithms.xml . .
peer downloads.xml
settings.xml . . . .
50
50
51
51
52
52
53
53
54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XV
Abkürzungsverzeichnis
Business Software Alliance (BSA)
Compact Disc (CD)
Distributed Hashtable (DHT)
Digital Rights Management (DRM)
Digital Subscriber Line (DSL)
eDonkey2000 (ed2k)
File Exchange Protocol (FXP)
Graphical User Interface (GUI)
Globally Unique Identifier (GUID)
Gesellschaft zur Verfolgung von Urheberrechtsverletzungen e.V. (GVU)
Hypertext Markup Language (HTML)
Integrierten Entwicklungsumgebung (IDE)
International Federation of the Phonographic Industry (IFPI)
Instant Messager (IM)
Fraunhofer-Institut für Integrierte Publikations- und Informationssysteme (IPSI)
Integrated Services Digital Network (ISDN)
Internet Service Provider (ISP)
Kademlia (Kad)
Mediensicherheit in der IT (MERIT)
Network Address Translation (NAT)
Organisation for Economics Co-operation and Development (OECD)
Peer-to-Peer (P2P)
XVI
Pipe Binding Protocol (PBP)
Peer Discovery Protocol (PDP)
Peer Endpoint Protocol (PEP)
Peer Information Protocol (PIP)
Peer Resolver Protocol (PRP)
Recording Industry Association of America (RIAA)
Rendezvous Protocol (RVP)
Strafprozeßordnung (StPO)
Telekommunikationsgesetz (TKG)
Gesetz über Urheberrecht und verwandte Schutzrechte (UrhG)
Uniform Resource Locator (URL)
World Wide Web Consortium (W3C)
World Wide Web (WWW)
Extensible Markup Language (XML)
Abkürzungsverzeichnis
1
1 Einleitung
In den letzten Jahren veränderte die Peer-to-Peer Technologie das Internet und dessen Gebrauch. Peer-to-Peer ist zu einem Synonym für Internet-Tauschbörsen geworden und viele
denken dabei an den Tausch von Bildern, Musik oder Filmen. Durch die Zunahme der unerlaubten Verbreitung von urheberrechtlich geschütztem Material über Internet-Tauschbörsen
erlangt die Pirateriebekämpfung einen immer höheren Stellenwert für die Medien- und Softwareindustrie. Das Kapitel 1.1 motiviert zunächst die wissenschaftliche Auseinandersetzung
mit dieser Problematik und das Kapitel 1.2 skizziert den Aufbau dieser Arbeit und die damit
verbundene Vorgehensweise.
1.1 Motivation
Bild-, Ton- und Filmmedien sind in unserer heutigen Informationsgesellschaft allgegenwärtig
und nicht mehr wegzudenken. Seitdem die digitalen Medien die analoge Technologie abgelöst
haben, ist es möglich, Kopien dieser Medien in unbegrenzter Stückzahl mit gleichbleibender
Qualität anzufertigen. Durch das digitale Format sind Werke nicht mehr an ein Trägermedium wie eine Video- oder Audiokassette gebunden, sondern können ohne großen Aufwand
über Datennetzwerke, wie z.B. das Internet, verbreitet werden.
1999 programmierte der Student Shawn Fanning eine Software zum Austausch von Musikdateien über das Internet. Das Programm wurde innerhalb von wenigen Monaten weltweit
unter dem Namen Napster“ bekannt. Fanning legte mit seiner Entwicklung den Grundstein
”
für eine bis heute anhaltende, fortwährende Verbreitung von Internet-Tauschbörsen. Fannings System basierte auf der einfachen Idee der dezentralen Datenhaltung. Dadurch wurde
ermöglicht, dass Nutzer Dateien direkt von einem anderen Computer herunterladen konnten.
Der zentrale Internet-Server diente dabei lediglich der Indexierung der Datenbestände.
Inzwischen existieren zahlreiche, verschiedene Internet-Tauschbörsensysteme. Dank immer
schnellerer Internet-Verbindungen und der fortwährenden Weiterentwicklung der Übertragungs- und Komprimierungstechnologien und der Tauschbörsen ist es aber heute nicht mehr
2
1 Einleitung
nur möglich, Audio-Dateien zu tauschen, sondern auch Filme, Bücher und Computerprogramme.
Allerdings lässt die einfache Möglichkeit der Vervielfältigung und Verbreitung digitaler Medien viele Tauschbörsen-Nutzer über rechtliche Aspekte hinwegsehen. Eine Verbreitung der
Dateien in Tauschbörsen ist allerdings nur erlaubt, wenn dies vom Urheber explizit genehmigt
wurde. Schließlich möchte der Urheber in der Regel mit seinem Werk Geld verdienen. Weiterhin betrachten viele Tauschbörsennutzer den unentgeltlichen Tausch als Kavaliersdelikt
und weniger als Straftat (vgl. dazu Kapitel 2.1.2).
Aus diesen Gründen beschäftigt sich die Wissenschaft mit Internet-Tauschbörsen und dem
Verhindern von strafrechtlichen Handlungen in diesen. Weiterhin untersucht die Wissenschaft
Methoden zur nachträglichen Aufdeckung solcher Verstöße. In diesem Bereich ist auch diese
Arbeit einzuordnen. Viele Schutzmechanismen für digitale Medien führen zu Restriktionen.
Somit ist allerdings auch eine legale Kopie nicht mehr möglich. Teilweise unterbinden solche
Systeme sogar das Abspielen auf bestimmten Geräten. Ein nicht-restriktiver Ansatz ist die
Einbettung von digitalen Wasserzeichen etwa mit einer Kundennummer. Dadurch wird zum
Einen ein sogenannter psychologischer Kopierschutz“ aufgebaut, zum Anderen ermöglicht
”
das Wasserzeichen eine Rückverfolgung bei einer eventuellen Rechtsverletzung. Um derartige
Rechtsverletzungen aufzudecken, müssen alle Dateien aus Tauschbörsen erst lokal verfügbar
gemacht und im Anschluss auf ein etwaiges Wasserzeichen untersucht werden. Durch die
große Menge an Dateien in Internet-Tauschbörsen bietet ein verteiltes System zur Suche und
Analyse dieser Dateien eine schnelle und gut erweiterbare Möglichkeit, um diesen Anforderungen gerecht zu werden.
Diese Arbeit weist die Aspekte der nachträglichen Aufdeckung von unberechtigten Vervielfältigungen und Veröffentlichungen von Dateien in Internet-Tauschbörsen unter Zuhilfenahme
von digitalen Wasserzeichen in einem verteilten System auf. Der Schwerpunkt dieser Arbeit
liegt dabei beim Entwurf eines verteilten Systems zur Suche und zur Verfügbarmachung von
Dateien aus Tauschbörsen. Die anschließende Analyse nach Wasserzeichen wird skizziert.
1.2 Aufbau der Arbeit
Der Einstieg in die Thematik erfolgt im nächsten Kapitel 2. In diesem Kapitel werden die
Grundlagen angesprochen und es erfolgt eine erste Analyse der Ausgangssituation. Das
Kapitel gliedert sich in die vier Teilbereiche Piraterie, Digitale Wasserzeichen, Verteilte Systeme und Peer-to-Peer.
1.2 Aufbau der Arbeit
3
Im anschließenden Kapitel 3 wird der Entwurf eines verteilten Systems zur Suche und Analyse von Dateien in Internet-Tauschbörsen vorgestellt. Die Idee zu diesem System beruht
auf einem Konzept des Fraunhofer Instituts für Integrierte Publikations- und Informationssysteme (IPSI). In diesem Kapitel wird zunächst die Zielsetzung dieser Arbeit erläutert.
Im Anschluss erfolgt eine Darstellung über den Ablauf einer möglichen Suche und Analyse.
Zudem werden Anforderungen, mögliche Ausnahmefälle und weitere Aspekte des zu entwickelnden Systems beschrieben.
Das Kapitel 4 beschreibt verschiedene Implementierungsaspekte. Hierbei erfolgt die Darstellung des Systemaufbaus sowie die Beschreibung der verschiedenen implementierten Komponenten.
Zum Abschluss erfolgt im Kapitel 5 eine Evaluation und Leistungsbewertung des Systems. Dabei gilt es lediglich einen ersten Eindruck über Potenzial und Effizienz des Systems
zu vermitteln.
Eine Zusammenfassung und Ausblicke für zukünftige Entwicklungen bilden den Abschluss der Arbeit.
4
2 Grundlagen und Analyse
Dieses Kapitel soll einen Überblick über die verwendeten Techniken und über den aktuellen Stand der Technik liefern. Nach einer Einführung in das Thema Piraterie“ werden in
”
den folgenden Abschnitten der Stand der Technik in Bezug auf digitale Wasserzeichen als
auch in Bezug auf Peer-to-Peer beschrieben. Dabei erfolgt eine erste für eine solche Arbeit
unerlässliche Analyse.
2.1 Piraterie
In diesem Abschnitt erfolgt eine Einführung in die verschiedenen Aspekte der InternetPiraterie. Nach einer kurze Einführung in ihre Geschichte werden die rechtlichen Aspekte,
die ökonomischen Folgen und die möglichen Gegenmaßnahmen behandelt.
Das Internet hat die Produktion, die Nutzung und den Vertieb von digitalen Medien (z.B.
Bilder, Musik oder Film) revolutioniert. Betroffen von dieser Revolution sind alle Mitglieder
der Wertschöpfungskette, u.a. die Konsumenten, Produzenten und der Vertrieb. Insbesondere
die Möglichkeit, Medien in nicht physischer Form zu vertreiben, hat neue legale und illegale
Geschäftsfelder entstehen lassen.
Auf den folgenden Seiten sollen hauptsächlich die illegalen Seiten – die sogenannten Raubkopien1 – beleuchtet werden. Nichtsdestotrotz sollen relevante legale Seiten nicht verschwiegen
werden.
1
Im Folgenden wird der Ausdruck Raubkopie“ durch den Ausdruck Schwarzkopie“ ersetzt. Dieser Aus”
”
druck beschreibt wesentlich treffender die begangene Straftat. §249 (1) des Strafgesetzbuch definiert einen
Raub wie folgt: [...] mit Gewalt gegen eine Person oder unter Anwendung von Drohungen mit gegen”
wärtiger Gefahr für Leib oder Leben eine fremde bewegliche Sache einem anderen [...] wegnimmt [...]“.
2.1 Piraterie
5
2.1.1 Geschichte der Schwarzkopie
Zu Beginn der Computerentwicklung bestand das Hauptaugenmerk auf der Weiterentwicklung der Hardware. Software galt als frei verfügbar und wurde beliebig kopiert und verändert.2
Einer der Vorreiter kommerzieller Software war Bill Gates, der 1975 zusammen mit Paul
Allen Microsoft gründete mit dem Ziel, Software zu verkaufen. Das erste Microsoft-Produkt
war eine Weiterentwicklung der Programmiersprache BASIC. Da zahlreiche Programmierer
weiterhin ihrer alten Praxis der freien Vervielfältigung treu blieben, schrieb Bill Gates den
sogenannten Open Letter“3 , in dem er jeden des Diebstahls bezichtigte, der die Software
”
ohne Bezahlung nutzte und kopierte4 .
Mit dem Aufkommen von sogenannten Home-Computern in den 1980er Jahren wandelte
sich der Computer vom Spiel- und Arbeitsgerät für Wissenschaftler und Freaks“ zu einem
”
Gerät für das gemeine“, wenn auch weiterhin technisch versierte Volk. Durch diesen Wandel
”
wurde das Kopieren zu einer Art Volkssport“. So sahen und sehen es noch heute viele als
”
Hobby an, einen Kopierschutz zu umgehen. War dieses anfangs noch eher trivial, so wurde
der Kopierschutz bis heute immer ausgeklügelter.
Die Schwarzkopie wurde anfangs hauptsächlich im Schulhoftausch verbreitet. Mit dem Aufkommen der ersten Kopierschutzmechanismen entstanden die ersten Cracking Groups.5 In
diesen Gruppen vereinigten sich Cracker, um gemeinsam dem Hobby des Kopierschutzentfernens nachzugehen.
Das Aufkommen des World Wide Web (WWW) wirkte wie eine Revolution der bisherigen
Szene rund um die Schwarzkopie. Wurde früher Software über langsame Modems und Disketten getauscht, veränderte sich durch Integrated Services Digital Network (ISDN), Digital
Subscriber Line (DSL) und das WWW einiges. Erst durch die neuen Technologien wurde es
möglich, auch bis dahin viel zu große Werke, wie Audio, Video und Software, zu tauschen.
Selbstverständlich spielten für diese Entwicklung auch noch weitere Technologien eine wichtige Rolle. Die Entwicklung der Compact Disc (CD), von Komprimierungsverfahren und nicht
zuletzt die Entwicklung immer schnellerer Computer sind nur einige Beispiele.
Zudem nahm die Qualität der Kopie von analogen Medien mit der Anzahl der hergestellten
Kopien ab. Dieses Problem existiert bei digitalen Medien nicht mehr. Heute ist das Anfertigen
2
(Vgl.
(Vgl.
4
(Vgl.
5
(Vgl.
3
Krömer und Sen 2006, S.22)
Gates 1976)
Krömer und Sen 2006, S.26)
Krömer und Sen 2006, S.32)
6
2 Grundlagen und Analyse
Abbildung 2.1: Verbreitungspyramide (Vgl. Krömer und Sen 2006, S.48)
von beliebig vielen Kopien ohne Qualitätsverlust möglich.
Parallel zu diesen technologischen Entwicklungen bildete sich eine Szene, wie sie in Abbildung
2.1 zu sehen ist. In dieser Verbreitungspyramide soll der typische Weg von sogenannten
Warez“6 gezeigt werden.
”
Im Folgenden werden die einzelnen Gruppierungen kurz beschrieben:
Die Release-Szene bzw. Cracker-Szene ist zuständig für die Versorgung der ganzen
Schwarzkopie-Szene mit neuen Warez. Es sei dabei angemerkt, dass ein Großteil der Gruppen dieser Szene nicht aus kommerziellen Zwecken handeln. Zwischen den Gruppen herrscht
ein reger Wettbewerb um die meisten 0-Days-Releases. Mit diesem Namen werden Warez
bezeichnet, die mit oder sogar vor dem offiziellen Marktstart veröffentlicht werden.
Die FXP-Szene7 sorgt für die Verbreitung der durch die Release-Szene in Umlauf gebrachten
Warez. Auch hier herrscht ein reger Wettbewerb innerhalb der Szene um die Anzahl der
verbreiteten Warez.
Die Filesharing-Szene umfasst die Gelegenheitskopierer, sozusagen die Konsumenten der
Schwarzkopie-Szene. Diese Szene entwickelte sich erst 1999 mit der Veröffentlichung der
Internent-Tauschbörse Napster“.
”
6
Warez“ ist ein Sammelbegriff für Schwarzkopien, der in der Filesharing-Szene Verwendung findet. Mehr
”
zum Szenejargon unter (Krömer und Sen 2006, S.36)
7
Der Name dieser Szene kann auf das File Exchange Protocol (FXP) zurückgeführt werden. Dabei handelt
es sich um ein zur schnellen Daten-Übertragung zwischen FTP-Servern unterlässliches Protokoll.
2.1 Piraterie
7
2.1.2 Motivation und Psychologie des Schwarzkopierens
In diesem Abschnitt soll über Motive des Schwarzkopierens und über die Psychologie des
Kopierens gesprochen werden. Es würde allerdings zu weit gehen, über die Zubringer“ bzw.
”
Lieferanten“ (also die Release-Szene und FXP-Szene) zu sprechen. Dazu sei auf Krömer und
”
Sen (2006) S.175 ff verwiesen.
Die Motive für das Tauschen sind sehr unterschiedlich. Sie reichen von wirtschaftlichen über
ideologische bis zu sozialen Motiven. Zu den wirtschaftlichen Motiven zählt u.a. die Theorie
des Homo oeconomicus, d.h. das Handeln zum größtmöglichen Nutzen. Dies unterstreicht
auch eine Studie der Universität Zürich aus dem Jahr 2004, in der unter anderem die Gründe,
warum keine kommerziellen Angebote genutzt werden, untersucht wurden (siehe Abbildung
2.2).
Abbildung 2.2: Gründe gegen eine Nutzung kommerzieller Angebote (Vgl. Bamert u. a. 2004,
S.5)
Ein Beispiel für ideologische Gründe ist die Meinung: Freie Information für alle“. Zu den
”
sozialen Motiven zählt u.a. sozialer Druck, der beispielsweise durch Freunde und Bekannte
ausgeübt wird, die etwas kopiert haben wollen. Weitere Motive sind u.a. ein Sammeltrieb
oder einfach Gewohnheit.
Diese Motive können aber nicht zu 100% auf Internet-Tauschbörsen übertragen werden.
Hier greifen weitere Motive, wie mangelndes Unrechtsbewußtsein. Zudem vermuten die Filesharer kein Risiko und fühlen sich anonym und unbeobachtet. Diesen Tatbestand belegen
8
2 Grundlagen und Analyse
mehrere Studien. Unter anderem geht aus der Studie Digitale Mentalität“ der Universi”
tät Witten/Herdecke herbor, dass es ein verbreitetes Bewusstsein für die Tatsache, dass
”
Raubkopieren eine Straftat ist, die wirtschaftlichen Schaden verursacht [gibt]“. Weiter heißt
es, dass dieses Bewusstsein [. . . ] jedoch meist nur geringen Einfluss auf das tatsächliche
”
Raubkopierverhalten [hat]. Im Falle der Urheberrechtsverletzung, die durch digitale Vervielfältigung begangen wird, bleibt ein intuitives Geständnis für das damit verbundene Unrecht
aus, weil das Tatbestandsmerkmal der Wegnahme fehlt, das unseren historisch gewachsenen
Vorstellungen von Diebstahl zu Grunde liegt“.8
Markus Giesler zeigt zudem in seiner Studie Rethinking Consumer Risk“, dass das Risiko,
”
einer Straftat in Form eines Urheberrechtsvergehens überführt zu werden, gegen Null tendiert. Dies führt er in seiner Studie auf das Prinzip der Kollektivierung von Risiko zurück.
Das bedeutet: Je größer die Zahl der Nutzer in einer Tauschgemeinschaft ist, desto geringer
ist das Risiko für den Einzelnen.9
2.1.3 Rechtliche Aspekte
Um eine Analyse der rechtlichen Situation durchführen zu können, müssen zunächst einmal
die rechtlichen Grundlagen erläutert werden. Das in Deutschland wichtigste Gesetz in diesem
Zusammenhang ist das Gesetz über Urheberrecht und verwandte Schutzrechte (UrhG) . Der
erste Paragraph dieses Gesetzes lautet: Die Urheber von Werken der Literatur, Wissenschaft
”
und Kunst genießen für ihre Werke Schutz [...].“10 Durch dieses Gesetz sind u.a. auch alle
digitalen Medien geschützt.11 Grundgedanke des Urhebergesetzes ist die Ermöglichung eines
wirtschaftlichen Ertrags für den Urheber aus seiner geistigen Leistung12 . Das Gesetz soll den
Urhebern die rechtliche Grundlage dafür geben, Art und Umfang der Nutzung ihrer Werke
zu kontrollieren.
Tauschbörsen werden vermehrt zum Tausch von urheberrechtlich geschützten Medien genutzt. Tauschbörsennutzer verstoßen daher häufig gegen das Urhebergesetz. So bedeutet
eine Veröffentlichung eines urheberrechtlich geschützen Mediums in einer Tauschbörse für
den Anbieter einen Verstoß gegen §15 (2) und §19 des UrhG. In diesen Paragraphen wird
das Recht der öffentlichen Zugänglichmachung beschrieben. 13
8
(Vgl.
(Vgl.
10
(Vgl.
11
(Vgl.
12
(Vgl.
13
(Vgl.
9
für Strategieentwicklung in Kooperation mit der Universität Witten/Herdecke 2004, S.4)
Giesler 2004, S.35)
GesetzUeberUrheberrechtUnd, §1)
GesetzUeberUrheberrechtUnd, §2)
Krömer und Sen 2006, S.190)
GesetzUeberUrheberrechtUnd, §15(2) u. §19)
2.1 Piraterie
9
Lädt dagegen der Tauschbörsennutzer urheberrechtlich geschützes Material aus einer Tauschbörse herunter, so verstößt der Nutzer gegen §16 des UrhG. Dieser Paragraph billigt dem
Urheber Rechte zu, ob und wie sein Werk veröffentlicht, vervielfältigt und verbreitet werden
darf.14
Das Urheberrecht hat allerdings auch viele Ausnahmen, um die Informationsfreiheit und das
Entstehen von neuen Werken nicht zu gefährden. Unter anderem erlaubt der §53 Nutzern
Filme und Musikstücke für den privaten Gebrauch zu kopieren. Zudem ist eine Weitergabe
von Kopien im Kreise der Familie und Freunde legal, an Arbeitskollegen und Nachbarn
allerdings nicht. Des Weiteren ist das Kopieren nur in geringen Stückzahlen erlaubt.15
Die Gesetzesänderung des UrhG zum 13.09.200316 brachte zwei wichtige Einschränkungen
für die Privatkopie. Grund für die Gesetzesänderung war eine EU-Richtlinie von 200117 .
Nach der Gesetzesänderung sind Privatkopien von offensichtlich rechtswidrig hergestellten
”
Vorlagen“ illegal.18 Zudem ist eine Privatkopie nur erlaubt, wenn hierfür kein Kopierschutz
umgangen werden muss.19
Die Gesetzesänderung von 2003 setzte allerdings nur diejenigen Teile der EU-Richtlinie um,
die zwingend nötig waren. Des Weiteren ist die Regelung der Privatkopie seit der Novellierung
sehr missverständlich. Wie bereits erwähnt, ist die Vervielfältigung zum privaten Gebrauch
unter Verwendung einer offensichtlich rechtswidrig hergestellten Vorlage explizit verboten.
Die meisten in Tauschbörsen verfügbaren Vorlagen sind allerdings keine rechtswidrig hergestellten, sondern nur“ unerlaubt zugänglich gemachten Vorlagen.
”
Daher herrscht seitdem eine rege Diskussion über weitere Anpassungen, den sogenannten
zweiten Korb.
Doch gehen auch hier die Meinungen stark auseinander. So befürworten einige, vor allem die
Vertreter der Musik- und Filmindustrie, die Abschaffung der Privatkopie. Dadurch befürchten allerdings viele eine Kriminalisierung der Tauschbörsen, was wiederum einen weiteren
technologischen Fortschritt verhindert könnte. Weitere Diskussionspunkte des zweiten Korbes sind eine sogenannte Kulturflatrate“ und eine sogenannte Bagatellklausel“. Unter der
”
”
Kulturflatrate versteht man eine Pauschalabgabe, wodurch aber Downloads aus jeglichen
Quellen legalisiert werden. Die Bagatellklausel sieht eine Straffreiheit bei rechtswidrigem
14
(Vgl. GesetzUeberUrheberrechtUnd, §16)
(Vgl. iRights.info 04.02.2005)
16
(GesetzUeberUrheberrechtUnd, Vgl.)
17
(Vgl. Richtlinie2001/29/EGDesEuropaeischen:22.05.2001 22.05.2001)
18
(Vgl. GesetzUeberUrheberrechtUnd, §53 Abs. 1)
19
(Vgl. GesetzUeberUrheberrechtUnd, §95a)
15
10
2 Grundlagen und Analyse
Kopieren in geringer Stückzahl und ausschließlich zum privaten Gebrauch vor. Dies würde
vor allem Polizei und Staatsanwaltschaften entlasten.
2.1.4 Maßnahmen gegen Schwarzkopierer
Schwarzkopieren ist nicht nur eine Ordnungswidrigkeit, wie etwa ein Parkvergehen, sondern
stellt eine Straftat dar. So drohen Schwarzkopierern neben Geldstrafen auch Freiheitsstrafen.
Zusätzlich zur strafrechtlichen Verfolgung von Schwarzkopierern können diese auch noch
zivilrechtlich belangt werden. Hier drohen dann zudem hohe Schadensersatzforderungen.
In der Praxis wird allerdings nur ein Bruchteil der Vergehen verfolgt. Polizei und Staatsanwaltschaft haben selten Interesse und Zeit, kleinen Fischen“ das Handwerk zu legen. Darauf
”
weisen auch die Befürworter der Bagatellklausel“ hin.
”
Gefahr droht diesen kleinen Fischen“ allerdings von Seiten der Industrie und den Urhe”
bern. Hier haben sich zahlreiche Industrieverbände gebildet, um gemeinsam gegen Verstöße
zivilrechtlich vorzugehen. So verfolgt die Business Software Alliance (BSA) als eine ihrer
Hauptaufgaben Unternehmen, die nicht korrekt lizensierte Software einsetzen. Hinter der
BSA stehen Unternehmen wie Microsoft, Apple und IBM.20
Für die Musikbranche sind als wichtigste Verbände der Verband der US-Musikindustrie Recording Industry Association of America (RIAA) sowie der Weltverband der Phonoindustrie
International Federation of the Phonographic Industry (IFPI) genannt. Für die deutsche
Filmbranche und Unterhaltsungsindustrie tritt zusätzlich häufig die Gesellschaft zur Verfolgung von Urheberrechtsverletzungen e.V. (GVU) in Aktion.
Anfangs beschränkte sich die Pirateriebekämpfung auf die großen Fische“, die Release”
Groups. Dann ging man dazu über, auch gegen Tauschbörsen vorzugehen. 2002 veröffentlichte
die RIAA erste Pläne, gegen Nutzer von Tauschbörsen vorzugehen.21 Um ein Exempel zu
statuieren, wurden 261 Tauschbörsennutzer verklagt.22 Allerdings mussten mehrere Klagen
unter dem Druck der Öffentlichkeit fallen gelassen werden und der Großteil der restlichen
Klagen wurde außergerichtlich nach Schadensersatzzahlungen beigelegt.23
Unter anderem weisen aber Messungen der britischen Firma CacheLogic darauf hin, dass sich
keinerlei Erfolge dieser Maßnahmen einstellen. Aktuelle Messungen weisen auf eine anhaltend
20
(Vgl.
(Vgl.
22
(Vgl.
23
(Vgl.
21
BSA 2000)
Schotzger 03.07.2002)
Wilkens 08.09.2003)
IFPI)
2.1 Piraterie
11
hohe Nutzung von P2P-Systemen hin.24
2.1.5 Ökonomische Folgen
Eine Studie von PriceWaterhouseCoopers25 weist für 2004 zwar einen Rückgang des Wertes
der illegal getauschten Musik auf, allerdings ist dieser mit 820 Millionen Euro immer noch
immens. 2003 betrug nach dieser Studie der Wert sogar 1,1 Milliarden Euro. Zudem besagt
die Studie, dass 2004 der Anteil der illegal getauschten Musik an den Gesamtausgaben für
traditionelle Tonträger 42% betrug. Abbildung 2.3 zeigt die Verteilung der Umsatzverluste
auf Teilverluste durch Tausch im Internet, durch Schulhoftausch und durch traditionellen
Tausch. Dabei kann festgestellt werden, dass der Internettausch immer noch mit Abstand
den größten Posten stellt.
Abbildung 2.3: Umsatzverluste durch Piraterie (Vgl. Müller u. a. Oktober 2005, S.37)
Eine der wichtigsten Quellen für Gewinnausfälle bzw. -verluste durch Schwarzkopierer ist die
Piracy Study der BSA26 . Allerdings ist bei diesen Quellen immer auch eine genaue Analyse
der Datengewinnung durchzuführen, um eine objektive Sicht zu erhalten. Um den Schaden
24
(Vgl. CacheLogic 2005)
(Vgl. Müller u. a. Oktober 2005)
26
(Vgl. BSA 2005)
25
12
2 Grundlagen und Analyse
zu berechnen, wurden beispielsweise bei der Piracy Study von einem Marktforschungsinstitut
zuerst aufwendige Marktforschungen durchgeführt. Dabei wurde ermittelt, welche Software
für einen durchschnittlichen Computer benötigt wird. Diese Daten wurden dann mit den
Verkaufszahlen verglichen und so der Gesamtschaden berechnet.
Laut IFPI stehen derzeit rund 775 Millionen Musikstücke in Tauschbörsen illegal zum Download bereit.27 Zudem zeigte eine Studie von 2005 über einen Zeitraum von 5 Monaten, dass
94% der Hollywood-Produktionen vor oder kurz nach dem Kinostart verfügbar waren.28
Ähnliche Studien wie zur Musikindustrie existieren auch für Film und Software29 .
Eine Studie der Universität Zürich von Dezember 2004 belegt zudem, dass Tauschbörsen
ungebrochen die beliebteste Quelle für Musik aus dem Internet sind (vgl. Abbildung 2.4
).30
Abbildung 2.4: Nutzung verschiedener Kanäle für den Musik-Download im Internet (Vgl.
Bamert u. a. 2004, S.4)
Die Organisation for Economics Co-operation and Development (OECD) stellte in ihrer
Studie Digital Broadband Content: Music“ zwei unterschiedliche Hypothesen für die ökono”
mische Relevanz auf.31 Die erste Hypothese lautet, dass die heruntergeladenen Musikstücke
von den Tauschbörsennutzern als vollwertiger Ersatz genutzt werden und anschließend nicht
mehr gekauft werden. Diese Hypothese bestätigt die Meinung der Musikindustrie. Die zweite
27
(Vgl.
(Vgl.
29
(Vgl.
30
(Vgl.
31
(Vgl.
28
IFPI)
Krempl 12.07.2005)
Deutschland 2006)
Bamert u. a. 2004)
OECD 13.12.2005, S.77)
2.1 Piraterie
13
Hypothese besagt, dass die heruntergeladene Musik nur zum Probehören genutzt wird und
somit der Absatz durch die Tauschbörsen gefördert wird. Diese These wird durch mehrere
andere Studien gestützt.32
Die Musikindustrie kritisierte diese Studien33 und gab als Antwort wiederum eigene Studien
in Auftrag34 .
Zusammenfassend kann dies wie folgt gedeutet werden: Die meisten Studien kommen zum
Ergebnis, dass Internet-Tauschbörsen sowohl positive wie auch negative Einflüsse auf den
Umsatz der Tonträger haben.35
2.1.6 Existierende Lösungsansätze zur Pirateriebekämpfung
Es gibt verschiedene Ansätze zur Pirateriebekämpfung. Jeder dieser Ansätze greift einen
anderen Punkt auf. Ein Ansatzpunkt ist das Vorgehen gegen die Tauschnetzwerke selbst.
Hier muss zwischen dem Vorgehen gegen Netz-Betreiber und Netz-Entwickler differenziert
werden. Ein weiterer Ansatzpunkt ist das Vorgehen gegen die Internetzugangsanbieter (engl.
Internet Service Provider (ISP)) und gegen die Tauschbörsennutzer36 . Wie bereits im Artikel
2.1.3 beschrieben, muss hier zwischen Up- und Downloadern unterschieden werden. Zuletzt
ist der Kopierschutz nicht zu vergessen.
Der Prozess gegen Napster war der Beginn immer neuer Prozesse gegen Anbieter von Tauschbörsen-Software37 . Mehr über Napster folgt im Abschnitt 2.4.1.1.
Abschluss einer ganzen Serie von Prozessen bildet der zur Zeit noch laufende Prozess gegen
den Tauschbörsen-Anbieter Limewire. Andere Tauschbörsen-Anbieter gingen in letzter Zeit
dazu über, außergerichtliche Vergleiche mit den Rechtsvertretern zu schließen, um einem Gerichtsprozess aus dem Weg zu gehen. So zahlte im September 2006 der inzwischen aufgelöste
eDonkey-Betreiber MetaMachine 30 Millionen US-Dollar an die RIAA38 . Zuvor hatte schon
der Anbieter der Software Kazaa nach einem langen Rechtsstreit einer außergerichtlichen
Einigung zugestimmt.
Gleich zweifach sind die Internet-Zugangsanbieter von der Pirateriebekämpfung betroffen.
Zum einen forderte die RIAA 2003 erstmals die Anbieter auf, technische Vorkehrungen zu
32
(Vgl.
(Vgl.
34
(Vgl.
35
(Vgl.
36
(Vgl.
37
(Vgl.
38
(Vgl.
33
Streit 19.06.2000)(Vgl. Wilkens 05.05.2002)
Wilkens 10.05.2002)
Wilkens 22.01.2003)
OECD 13.12.2005, S.79)
OECD 13.12.2005, S.78)
Röttgers 2003, S.23)
Jurran 13.09.2006)
14
2 Grundlagen und Analyse
treffen, Filesharing zu unterbinden39 . Diese Forderungen wurden immer wieder wiederholt.
Zuletzt durch den Branchenverband IFPI auf der Messe Popkomm40 .
Zum anderen sind die Zugangsanbieter durch Forderungen seitens der Urheberrechtsvertreter
zur Ermittlung von Kundendaten durch eine IP-Adresse betroffen. In Deutschland ist dies
aber rechtlich umstritten. So hat ein Urheber zur Zeit keinen Auskunftsanspruch. Nur die
Strafverfolgungsbehörden verfügen über diesen Anspruch nach Strafprozeßordnung (StPO)
§100g. Daher wählen die Rechteinhaber derzeit den Umweg über ein Strafverfahren. Wesentlich problematischer ist dabei noch, dass Zugangsanbieter nach dem Telekommunikationsgesetz (TKG) §96 verpflichtet sind, nach Beenden einer Verbindung alle Daten zu löschen,
es sei denn, sie seien aus abrechungstechnischen Gründen zwingend erforderlich. Allerdings
erfordert eine am 21. Februar 2006 durch den Rat der Europäischen Union verabschiedete
Richtlinie über die Vorratsdatenspeicherung eine Anpassung des Gesetzes bis spätestens zum
März 200941 . Der Richtlinie nach müssen bestimte Daten – insbesondere Verkehrsdaten und
Standortdaten, die bei der Bereitstellung und Nutzung öffentlicher elektronischer Kommunikationsdienste anfallen von den Diensteanbietern auf Vorrat für mindestens sechs Monate
gespeichert werden.
Ein weiterer Versuch, die Piraterie einzuschränken, besteht darin, den Austausch von urheberrechtlich geschützem Material uninteressant zu machen. Dies kann u.a durch die Verbreitung manipulierter Musikstücke in den jeweiligen Tauschbörsen und den Einsatz von
manipulierten Servern geschehen42 .
Einer der aktuellsten Ansätze zur Pirateriebekämpfung stammt von der Schweizer Firma
Logistep. Diese entwickelte eine Software, die automatisch nach unerlaubten DownloadAngeboten in Tauschbörsen sucht. Jede Rechtsverletzung wird automatisch über eine Anwaltskanzlei zur Anzeige gebracht. Gleichzeitig wird eine Email an den entsprechenden
Service-Provider abgesetzt mit der Aufforderung, die entsprechenden IP-Adressen und die
zugehörigen Kundendaten zu sichern.43
Der Kopierschutz ist auch zu den Maßnahmen der Pirateriebekämpfung zu zählen. Waren
früher bei analogen Medien eine Art natürlicher Kopierschutz durch die Qualitätsverluste
beim Kopieren gegeben, ist es heute dank digitaler Technik möglich, grenzenlos Kopien in
fortdauernd gleichbleibender Qualität anzufertigen. Daher existieren heute mehrere verschiedene Kopierschutzverfahren.
39
(Hansen 24.01.2003, Vgl.)
(Vgl. Krempl 20.09.2006)
41
(Vgl. Richtlinie2006/24/EGDesEuropaeischen:15.03.2006 15.03.2006)
42
(Vgl. Röttgers 2003, S.67)
43
(Vgl. Bleich 26.01.2006)
40
2.2 Digitale Wasserzeichen
15
Eine Möglichkeit greift auf gezielte Abweichungen vom Standard im Speichermedium (CD,
DVD,. . . ) zurück. Die meisten Kopierprogramme für CDs gleichen diese Abweichungen als
Beschädigungen aus. Der Kopierschutz bei Programmen überprüft eben diese Abweichungen.
Fehlen diese, wird das Programm nicht ausgeführt. Bei Musik-CDs basieren die Abweichungen auf Fehlern, die von CD-Playern ignoriert werden aber in CD-Laufwerken in Computern
zu Fehlern führen, so dass diese dort nicht gelesen werden können. Allerdings gibt es inzwischen zahlreiche Möglichkeiten diesen Kopierschutz zu überwinden, z.B. Brennprogramme,
die jede Abweichung mitkopieren, oder neue CD-Laufwerke, die diese CDs auch lesen können.
Moderne Kopierschutzverfahren setzen auf Verschlüsselung der Inhalte. Dadurch entsteht ein
entsprechender Abspielschutz. Mit diesem sogenannten Digital Rights Management (DRM)
lässt sich nun über spezielle Abspiel-Hard- und Software kontrollieren, was der Nutzer mit
dem Medium machen darf.
Allerdings schränkt dieses System die Nutzung stark ein. Zudem wirkt eine zu starke Restriktion wohl eher kundenfeindlich und hat somit auf dem freien Markt kaum eine Chance.
So verwendet der zur Zeit mit Abstand erfolgreichste kommerzielle Download-Anbieter Apple in einem iTunes Music Store nur ein nominelles DRM. Richard Stallmann sagt hierzu
in einem Interview44 , dass statt einem Digital Rights Management“ lediglich ein Digital
”
”
Inconvenience Management“ zum Einsatz kommt, da iTunes es erlaubt, erworbene Musikstücke auf eine Audio-CD zu brennen. Diese können von dieser CD aus wiederum problemlos
in ein digitales Format umgewandelt werden. Beim zur Zeit zweitgrößten Download-Dienst,
eMusic.com, kommt sogar gar kein DRM zum Einsatz.
Auf diesen Grundlagen und Erkenntnissen aufbauend wird im nächsten Abschnitt die Technik der digitalen Wasserzeichen und ihre möglichen Einsatzgebiete zur Pirateriebekämpfung
beschrieben.
2.2 Digitale Wasserzeichen
Digitale Medien haben, wie bereits mehrfach erwähnt, in den letzten Jahren stark an Bedeutung gewonnen. Allerdings kann für diese die Authentizität der Daten, um die Identität
des Besitzers oder Senders zu garantieren, nicht gewährleistet werden. Außerdem ist auch
der Nachweis der Integrität, d.h. Unversehrtheit und Unverfälschtheit, um Manipulationen
zu erkennen, nicht gewährleistet.45
44
45
(Vgl. p2pnet 06.02.2006)
(Vgl. Dittmann 2000, S.1)
16
2 Grundlagen und Analyse
Digitale Wasserzeichenverfahren bieten Lösungsmöglichkeiten für die oben genannten Probleme. Das digitale Wasserzeichen wird ähnlich wie das klassische Wasserzeichen (z.B. das
Geldnotenwasserzeichen) in ein Trägermedium eingebettet. Im Unterschied zum klassischen
kann das digitale Wasserzeichenverfahren auf jeder Art von digitalen Mediendateien verwendet werden und nicht nur auf Papier. Digitale Wasserzeichen erlauben es, Authentizität
oder Integrität nachzuweisen, indem Informationen direkt in das Datenmaterial eingefügt
werden.
Grundsätzlich kann man zwischen zwei Arten von Wasserzeichen unterscheiden:
• Wahrnehmbare digitale Wasserzeichen
• Nicht wahrnehmbare digitale Wasserzeichen
Wahrnehmbare digitale Wasserzeichen sind wie das klassische Wasserzeichen sichtbar bzw.
hörbar. Dies könnte z.B. ein Firmenlogo sein.
Die durch nicht wahrnehmbare Wasserzeichen eingebettete Informationen sind im Allgemeinen für das menschliche Auge nicht sichtbar, für das menschliche Ohr nicht hörbar und
so mit dem Datenmaterial verwoben, dass ein einfaches Entfernen unmöglich ist, ohne das
Datenmaterial zu beschädigen.46
Für diese Arbeit sind ausschließlich die nicht wahrnehmbaren Wasserzeichen relevant. Die
wahrnehmbaren Wasserzeichen disqualifizieren sich für den Einsatz durch ihre offensichtliche
Existenz. Hierbei ist es nicht ausschlaggebend, dass die Existenz bekannt ist. Dies wird sogar teilweise auch bei nicht wahrnehmbaren Wasserzeichen gewünscht zwecks Abschreckung
der Benutzer. Aufbauend auf denen in Abschnitt 2.1.2 erläuterten Erkenntnissen, dass sich
Tauschbörsen-Benutzer zumeist unbeobachtet und anonym fühlen, spricht man auch gerne
von einem psychologischen“ Kopierschutz. Ein maßgeblicher Grund gegen eine Verwendung
”
wahrnehmbarer Wasserzeichen und für eine Verwendung nicht wahrnehmbarer Wasserzeichen ist, dass die Nutzbarkeit der Mediendateien durch die Sichtbarkeit bzw. Hörbarkeit des
Wasserzeichens stark eingeschränkt wird.
Die Abteilung Mediensicherheit in der IT (MERIT) des Fraunhofer-Institut für Integrierte
Publikations- und Informationssysteme (IPSI) definiert auf ihrer Homepage47 nicht wahrnehmbare Wasserzeichen wie folgt.
Definition 1 Digital Watermarking ist ein Verfahren, durch nicht-wahrnehmbare, gezielte Veränderungen an Multimediadaten, beliebige Informationen in digitale Medien (wie zum
46
47
(Vgl. Dittmann 2000, S.2)
(Vgl. MERIT, http://www.ipsi.fraunhofer.de/merit/mediensicherheit/was ist watermarking.de.html)
2.2 Digitale Wasserzeichen
17
Beispiel Audio, Video, Bilder, etc.) einzubetten. Dabei wird die Sicherheit und Geheimhaltung
der eingebetteten Information durch einen geheimen Schlüssel garantiert. Ohne den geheimen
Schlüssel lässt sich das Wasserzeichen nicht auslesen oder verändern. Wasserzeichen können so gestaltet werden, dass sie robust gegenüber Veränderungen des Trägermediums sind.
Dies bedeutet, dass die eingebettete Information auch nach der Veränderung des markierten
Mediums noch vorhanden ist.
Der Wasserzeichenalgorithmus besteht aus zwei Prozessen: dem Einbettungsprozess (Watermark Embedding) und dem Abfrage- bzw. Ausleseprozess (Watermark Retrieval) (vgl.
Abbildung 2.5).
Abbildung 2.5: Einbetten und Auslesen eines digitalen Wasserzeichens
Der Einbettungsprozess fügt die Wasserzeicheninformation (Watermark Message) in das Datenmaterial (Cover) ein und es entsteht das markierte Trägersignal. Der geheime Schlüssel
wird dabei benutzt, damit das Wasserzeichen nicht von Angreifern manipuliert oder gelöscht
werden kann.
Der Abfrageprozess funktioniert umgekehrt. Er extrahiert mit dem geheimen Schlüssel aus
dem markierten Material die Wasserzeicheninformation. Da das Wasserzeichen nicht entfernbar sein soll, kann man mit dem Abfrageprozess nur die Wasserzeicheninformation auslesen,
aber nicht das Original wiederherstellen.
In der Praxis werden oft zusätzliche Parameter verwendet, z.B. Wasserzeichenstärke, Initialisierungswerte, . . . 48
48
(Vgl. Dittmann 2000, S.19 f)
18
2 Grundlagen und Analyse
2.2.1 Eigenschaften eines Wasserzeichen-Verfahrens
Digitale Wasserzeichen besitzen eine Vielzahl von verschiedenen Eigenschaften. Hier werden
nur die wichtigsten Eigenschaften kurz aufgeführt. Weitere Eigenschaften und ausführlichere
Informationen werden in (Dittmann 2000, S.25 ff) und in(Dittmann u. a. 2005/12//, S.457 f)
aufgeführt.
• Robustheit: Unter einem robusten Wasserzeichen versteht man ein Wasserzeichen, welches gegenüber Transformationen des Trägermediums widerstandsfähig ist. Das Gegenstück zum robusten Wasserzeichen ist das fragile Wasserzeichen, welches nach jeglicher
Transformation des Trägermediums zerstört ist.
• Nicht-Wahrnehmbarkeit: Diese Eigenschaft beschreibt, inwiefern ein eingebettetes Wasserzeichen akustisch bzw. optisch wahrgenommen werden kann.
• Security: Ein Wasserzeichen wird als sicher (secure) eingestuft, wenn die eingebettete
Information durch einen Angreifer, dem das Verfahren bekannt ist und dem mindestens
ein markiertes Datenmaterial vorliegt, nicht zerstört, verfälscht oder aufgespürt werden
kann.
• Komplexität: Diese Eigenschaft beschreibt den Aufwand, der erbracht werden muss,
um die Wasserzeichen-Information einzubringen und wieder auszulesen.
• Kapazität: Dieser Parameter misst, welche Datenmenge in das Trägermedium eingebracht werden kann.
2.2.2 Anwendungsgebiete digitaler Wasserzeichen
Für Wasserzeichen gibt es eine Vielzahl von Anwendungsgebieten. Die wichtigsten sind im
Folgenden aufgeführt 49 .
• Verfahren zur Urheberidentifizierung (Authentifizierung): Robust Authentication Watermark
• Verfahren zur Kundenidentifizierung (Authentifizierung): Fingerprint Watermark
• Verfahren zur Annotation des Datenmaterials: Caption Watermark, Annotation Watermark
• Verfahren zur Durchsetzung des Kopierschutzes oder Übertragungskontrolle: Copy Control Watermark, Broadcast Watermark
49
(Vgl. Dittmann 2000, S.30 f)
2.2 Digitale Wasserzeichen
19
• Verfahren zum Nachweis der Unversehrtheit (Integritätsnachweis): Integrity Watermark, Verification Watermark
2.2.3 AlgorithmManager50
Der AlgorithmManager ist eine generische Lösung zum Zugriff auf Wasserzeichenfunktionalitäten. Er wurde in der Abteilung MERIT des Fraunhofer IPSI entwickelt. Trotz der
Implementierung in JAVA ist der AlgorithmManager unabhängig von allen WasserzeichenAlgorithmus spezifischen Eigenschaften, wie Entwicklungssprache, Medien-Typ oder den benötigten Parametern.
Dies wird durch drei wesentliche Punkte erreicht:
1. Die Entwickler eines Wasserzeichenalgorithmus spezifizieren den Gebrauch ihres Algorithmus in einer XML-Datei. Durch diese wird eine Interpretation des Algorithmus
durch den AlgorithmManager ermöglicht.
2. Das Wasserzeichenverfahren selber ist hinter Interfaces versteckt. Der AlgorithmManager stellt wiederum Instanzen dieser Interfaces nach Definition aus der XML-Datei
zur Verfügung.
3. Die Wasserzeichennachricht, die jeder Algorithmus nutzen muss, ist flexibel und kann
aus Bits, Bytes, Characters oder als Zeichenkette (String) realisiert werden.
Jeder Algorithmus besteht aus drei Objekten:
• algoDescription.xml
Wie bereits erwähnt, stehen in dieser Datei alle über einen Algorithmus benötigten
Informationen. Der AlgorithmManager sucht diese Datei und erstellt daraus die interne
Präsentation des Wasserzeichenalgorithmus.
• Embedder
Der Embedder stellt die Funktionen zum Einbetten einer Wasserzeicheninformation in
ein Medium zur Verfügung.
• Detektor
Der Detektor liest die eingebetteten Informationen aus einem Medium aus.
Der AlgorithmManager bietet einen einfachen Umgang mit den verschiedensten Implementierungsformen von Wasserzeichen-Algorithmen.
50
Dieser Abschnitt beruht auf der Präsentation von Patrick Wolf (Vgl. Wolf 2006)
20
2 Grundlagen und Analyse
Abbildung 2.6: algoDescription.xml (Vgl. Wolf 2006, Folie 4)
2.3 Verteilte Systeme
Es existieren verschiedene Definitionen für ein verteiltes System.
Leslie Lamport definiert ein verteiltes System sehr allgemein:
Definition 2 A distributed system is one in which the failure of a computer you didn’t even
know existed can render your own computer unusable.
Andrew Tanenbaum definiert ein verteiltes System wie folgt:
Definition 3 Ein verteiltes System ist eine Menge voneinander unabhängiger Computer,
”
die dem Benutzer wie ein einzelnes kohärentes System erscheinen“51 .
George Coulouris definiert ein verteiltes System wie folgt:
Definition 4 Als verteiltes System wird ein System bezeichnet, bei dem sich die Hardwareund Softwarekomponenten auf vernetzten Rechnern befinden und nur über den Austausch
von Nachrichten kommunizieren und ihre Aktionen koordinieren52 .
51
52
(Vgl. Tanenbaum u. a. 2003, S.18)
(Vgl. Coulouris u. a. 2005)
2.3 Verteilte Systeme
21
Zusammenfassend besagen die Definitionen zwei Dinge. Zum einen sind die verwendeten
Computer autonom und miteinander vernetzt, zum anderen verbirgt ein verteiltes System
die Verwendung mehrerer Computer. Diese Eigenschaft wird als Transparenz bezeichnet.
Durch die Definition von Leslie Lamport wird deutlich, dass Fehlertoleranz von verteilten
Systemen eine sehr wichtige Eigenschaft ist, die noch heute in vielen Systemen fehlt.
Die verschiedenen Definitionen zeigen allerdings auch, dass es verschiedene Auffassungen
über ein verteiltes System gibt. Um ein besseres Bild über ein verteiltes System zu bekommen, werden im Folgenden die wichtigsten Eigenschaften eines guten verteilten Systems
aufgezählt:
• Eine der wichtigsten Eigenschaften ist, wie bereits erwähnt, die Eigenschaft der Transparenz. Diese Eigenschaft kann noch feiner untergliedert werden53 :
– Zugriffstransparenz : Diese verbirgt Unterschiede in der Datendarstellung und der
Zugriffsart auf eine Ressource.
– Positions-/Ortstransparenz : Die Ortstransparenz bezeichnet die Eigenschaft, dass
der Ort der Ressource verborgen bleibt.
– Migrationstransparenz : Unter dieser Art der Transparenz versteht man die Eigenschaft, dass eine Ressource verschoben werden kann.
– Relokationstransparenz : Diese Eigenschaft ist eine verstärkte Eigenschaft der Migrationstransparenz: Eine Ressource kann verschoben werden, während sie genutzt
wird.
– Replikationstransparenz : Diese Eigenschaft verbirgt, dass eine Ressource repliziert
ist.
– Nebenläufigkeitstransparenz : Unter dieser Eigenschaft versteht man, dass eine Ressource zeitgleich von mehreren Benutzern genutzt werden kann.
– Fehlertransparenz : Diese Eigenschaft verbirgt einen Systemausfall, d.h. einen Ausfall eines einzelnen Systems im großen Ganzen.
– Persistenztransparenz : Unter Persistenztransparenz versteht man die Eigenschaft,
dass verborgen bleibt, ob sich eine Ressource im Hauptspeicher oder auf der Festplatte befindet.
• Eine weitere wichtige Eigenschaft ist eine gute Skalierbarkeit. Diese Eigenschaft resultiert direkt aus der Definition, dass verschiedene Computer verwendet werden.
• Da die Wahrscheinlichkeit für Fehler und Ausfälle mit der Größe des verteilten Systems
stark zunimmt, ist eine weitere wichtige Eigenschaft die Fehlertoleranz.
53
(Vgl. Tanenbaum u. a. 2003, S.21 ff)
22
2 Grundlagen und Analyse
• Eine weiterere wünschenswerte Eigenschaft ist die Offenheit des Systems. Mit dieser
Eigenschaft wird bestimmt, wie gut sich das System auf verschiedenen Wegen erweitern
lässt.
Verteilte Systeme werden oft mit Hilfe sogenannter Middleware organisiert. Darunter versteht
man eine Realisierung als Softwareschicht, die zwischen dem Betriebssystem und der Ebene
aus Benutzern und Anwendungen eingefügt wird (vgl. Abbildung 2.7). Ein Beispiel dafür ist
die in Abschnitt 2.4.2 vorgestellte Peer-to-Peer-Plattform JXTA.
Abbildung 2.7: Middleware (Vgl. Tanenbaum u. a. 2003, S.19)
Der Entwurf und Betrieb eines verteilten Systems ist offensichlich komplexer als der eines
zentralisierten Systems. Daher sollen im Folgenden die wichtigsten Motive für den Einsatz
eines verteilten Systems erläutert werden.
1. Beschleunigung der Verarbeitung durch Parallelarbeit
Einfachste Vorgehensweise nach dem Divide-and-Conquer-Prinzip:
• Aufteilung der zu verarbeitenden Daten in Teilmengen
• Verteilung der Arbeit an eine unabhängige Verarbeitungseinheit
• Parallele Verarbeitung und anschließende Zusammensetzung der Ergebnisse
2. Ausfallsicherheit durch Redundanz ; redundante Datenspeicherung und/oder redundante Ausführung von Rechenoperationen, um Ausfälle abzufangen
2.4 Peer-to-Peer
23
2.4 Peer-to-Peer
Wie schon das englische Wort Peer (engl. Peer: Ebenbürtiger, Gleichgestellter) vermuten
lässt, versteht man unter einem Peer-to-Peer (P2P)-Netzwerk ein Computernetzwerk, in
dem alle Teilnehmer nahezu gleichberechtigt sind und sowohl Dienste in Anspruch nehmen
(Client) als auch Dienste zur Verfügung stellen (Server).
Da bisher keine grundlegende formale Definition existiert bzw. die vorhandenen Definitionen
sehr verschieden sind, wird Peer-to-Peer wie folgt definiert:
Definition 5 Unter einem Peer-to-Peer-Netzwerk versteht man ein Kommunikationsnetzwerk zwischen Rechnern, in dem jeder Teilnehmer sowohl Client- als auch Server-Aufgaben
durchführt.
Eine Beschreibung eines Peer-to-Peer-Systems ist durch die folgenden Eigenschaften möglich54 :
• Rollensymmetrie: Jeder Peer ist sowohl Server als auch Client ( Servent“)
”
• Dezentralisierung
– keine zentrale Instanz zur Steuerung oder Koordination
– Information einer Gruppe sind keinem Peer vollständig bekannt, sondern über die
Gruppe verteilt
– Peer kennt zumeist nur seinen Nachbarn und nicht die ganze Gruppe
• Selbstorganisation: Das globale Verhalten der Gruppe ergibt sich aus den lokalen Entscheidungen des Peers und der Interaktion zu ihr
• Autonomie: Peers sind in ihren Entscheidungen und ihrem Verhalten autonom.
• Zuverlässigkeit: Peers und Netzverbindungen sind nicht zuverlässig. Peers können ausfallen, Netzwerkverbindungen unterliegen Störungen und anderen Umwelteinflüssen.
• Verfügbarkeit: In Peer-to-Peer-Netzen sind nicht alle Peers zu jeder Zeit verfügbar. Daher müssen entsprechende Vorkehrungen in Form von Replikationen getroffen werden.
Das älteste Peer-to-Peer-Netz ist das ARPANET, ein Vorreiter des heutigen Internets. Peerto-Peer wurde in den letzten Jahren zunehmend populärer. Ausschlaggebend dafür war u.a.
Napster (vgl. Abschnitt 2.4.1.1).
54
(Vgl. Hauswirth und Dustdar 09.11.2006)
24
2 Grundlagen und Analyse
Bei Peer-to-Peer-Systemen handelt es sich um so genannte Overlay-Netze. Diese bauen auf
einer konkreten Netzwerk-Topologie eines Basisnetzwerkes auf und legen über dieses ein übergeordnetes unabhängiges Netzwerk. Das Peer-to-Peer-System ist für Aufbau und Verwaltung
eines solchen Overlay-Netzes verantwortlich.
Wie im vorherigen Abschnitt über verteilte Systeme (Abschnitt 2.3) bereits erwähnt, sind
zwei der Hauptforderungen an verteilte Systeme Skalierbarkeit und Fehlertoleranz. Diese
werden in Peer-to-Peer-Systemen durch Aufbau des Netzes automatisch erfüllt:
• Es ist für das Gesamtsystem unerheblich, ob ein Knoten ausfällt (Fehlertoleranz).
• Sind alle Knoten des Systems ausgelastet, lässt sich die Menge der Knoten vergrößern,
auf welche die Gesamtlast verteilt wird (Skalierbarkeit).
Größter Nachteil der Peer-to-Peer-Netze ist die teilweise wesentlich höhere Komplexität.
Zu den bekanntesten Anwendungen des Peer-to-Peer-Prinzips zählen Tauschbörsen, Instant
Messager (IM) und Voice over IP. Da Tauschbörsen in dieser Arbeit eine herausragende
Rolle spielen, werden diese im nächsten Unterabschnitt näher betrachtet. Zudem wird das
Peer-to-Peer-Framework JXTA, welches als Basis der prototypischen Implementierung dient,
vorgestellt. Im Anschluss erfolgt eine Klassifizierung der vorgestellten Technologien.
2.4.1 Tauschbörsen
Definition 6 Internet-Tauschbörsen sind Plattformen zum Autausch von Dateien über das
Internet. Sie kombinieren Suchalgorithmen für verteilte Systeme und eine dezentrale Speicherung von Daten55 und werden durch Peer-to-Peer-Netzwerke realisiert.
Die Nutzung erfolgt durch Computerprogramme (sogenannte Clients), die auf jedem teilnehmenden Rechner installiert sind. Diese Clients implementieren Kommunikationsprotokolle und stellen Anwendern deren Funktionalitäten über eine Benutzerschnittstelle (engl.
Graphical User Interface (GUI) ) zur Verfügung.
Das Downloadangebot einer Tauschbörse besteht aus der Summe der von allen Teilnehmenern bereitgestellten Daten. Die Freigabe von Dateien für den Zugriff anderer Nutzer wird
als File Sharing“ bezeichnet. File Sharing steht inzwischen synonym für den Dateiaustausch
”
in Internet-Tauschnetzwerken.
55
(Vgl. Schoder und Fischbach 2002, S.6)
2.4 Peer-to-Peer
25
Grundsätzlich kann zwischen zwei Grundtypen von Peer-to-Peer-Netzen unterschieden werden (vgl. Abbildung 2.8). Man unterscheidet zwischen serverbasiertem und serverlosem Peerto-Peer-Netz. Beim serverbasierten Peer-to-Peer-Netz übernimmt ein übergeordneter Server die Koordinierung des Netzes. Die Verwaltung der Nutzer und der Dateien findet zentral statt. Lediglich der eigentliche Dateiaustausch findet direkt zwischen zwei Peers statt.
Man spricht bei dieser Lösung auch von hybridem Peer-to-Peer, da es eine Zwischenlösung
zwischen einer Client/Server-Architektur und einer vollständigen Peer-to-Peer-Lösung ist56 .
Beim serverlosen Peer-to-Peer-Netz gibt es keine zentrale koordinierende Instanz.
Abbildung 2.8: Serverbasiertes und serverloses Peer-to-Peer-Netz (Vgl. Schoder und Fischbach 2002, S.27)
Des Weiteren können Peer-to-Peer-Netze unterschiedlich strukturiert sein. Sie können flach
oder hierarchisch aufgebaut sein. Beim hierarchischen Aufbau haben einige Peers besondere
Funktionen, z.B. Verwaltungsaufgaben in serverlosen Netzen. Diese ausgewählten Computer
werden als Supernodes“ bezeichnet und dienen als Knotenpunkte. Diese Struktur kann unter
”
anderem zu einer besseren Skalierbarkeit verhelfen.
Eines der wichtigsten Merkmale der Tauschbörsen ist das verwendete Suchverfahren. Es kann
hier zwischen drei gebräuchlichen Algorithmen unterschieden werden:
1. ein zentraler Suchindex auf einem Server
2. Jeder Peer verwaltet sein eigenes Dateiangebot. Suchanfragen müssen an jeden Teilnehmer geschickt werden (Broadcast).
3. Verteilter Suchindex
56
(Vgl. Schoder und Fischbach 2002, S.27)
26
2 Grundlagen und Analyse
Tauschbörsen sind wohl die bekannteste Anwendung von Peer-to-Peer-Netzen. Daher werden Peer-to-Peer-Netze bzw. der Begriff Peer-to-Peer oft fälschlicherweise synonym mit den
Begriffen Internettauschbörsen bzw. engl. Filesharing verwendet.
Im Folgenden wird mit dem Tauschbörsen-Netz und der gleichnamigen Software Napster der
erste Vertreter der Internet-Tauschbörsen vorgestellt. Im Anschluss werden die beiden zur
Zeit in Deutschland populärsten Vertreter der Internet-Tauschbörsen, BitTorrent und eDonkey, kurz charakterisiert. Zudem erfolgt eine kurze Zusammenfassung über das KademliaProtokoll, welches zusätzlich zum eDonkey-Protokoll in der Software eMule (eMule ist die mit
Abstand meistgenutzte Software für das eDonkey-Netz) zum Einsatz kommt und zusätzlich
die Grundlage für eine Beta-Version einer neuen serverlosen BitTorrent-Version darstellt57 .
2.4.1.1 Napster
Shawn Fanning brachte im Juni 1999 eine Beta-Version seines Tauschbörsen-Netzes und der
gleichnamigen Tauschbörsen-Software Napster heraus. Er bezeichnete Napster anfangs nur
als Chat mit Download-Funktion für MP3-Dateien“.
”
Dabei bedient sich Napster eines simplen aber effektiven Grundprinzips:
Jeder Nutzer stellt nach dem Starten der Software Dateien auf seiner Festplatte anderen
Nutzern zur Verfügung. Im Gegenzug erhält er Zugriff auf die freigegebenen Dateien der
momentan angemeldeten Nutzer. Der Server dient dabei nur zur Anmeldung und verwaltet
zudem einen zentralen Index.
Bei der Suche eines Nutzers nach einer bestimmten Datei wird der entsprechende Suchbegriff
an den zentralen Server gesendet. Dieser durchsucht den Index und sendet dem suchenden
Nutzer eine Liste mit allen Nutzern, die diese Datei zur Verfügung stellen. Anschließend kann
der suchende Nutzer sich einen entsprechenden Tauschpartner aus den Resultaten aussuchen.
Der eigentliche Tausch, also der Download der Datei, findet ohne Einfluss des Servers direkt
zwischen den Clients statt.
1999 erkannte auch RIAA die zunehmende Gefahr“ durch Napster und startete eine erste
”
Klage gegen Napster58 . Kurz darauf folgten Klagen von der Band Metallica“ und dem Rap”
per Dr Dre“. Jetzt war erstmals die Rede vom Ausschluss urheberrechtsgeschützer Musik aus
”
Napster. Napster verlor die Klagen und sperrte im Mai 2000 erstmals 335.435 Nutzer anhand
von den Musikern vorgelegten Listen59 . Dies war allerdings mit einer einfachen Neuanlegung
57
(Vgl. BitTorrent.org, http://www.bittorrent.org/Draft DHT protocol.html)
(Vgl. mbb 08.12.1999)
59
(Vgl. online 10.05.2000)
58
2.4 Peer-to-Peer
27
eines Benutzerkontos zu umgehen. Ende Juli 2000 erfolgte eine einstweilige Verfügung, die
eine kurzfristige Einstellung des Dienstes zur Folge hatte. Napster erhob Einspruch gegen
diese Verfügung und durfte daraufhin vorerst online bleiben.
Die Gerichtsprozesse dämpften den Erfolg allerdings nicht und hatten vielmehr die Wirkung
einer Marketingkampagne. Durch das wachsende Interesse der Medien an den Prozessen
wurde Napster immer populärer. So hatten zu der Zeit etwa 20 Millionen Nutzer ein NapsterKonto. Ein Jahr zuvor waren es gerade mal 200.000.
Im Berufungsprozess änderte Napster die Argumentationslinie. Sie stellten sich als Dienst
dar, der nicht per se für Urherberrechtsverletzungen entworfen wurde, aber eben für diese
benutzt wird und beriefen sich auf das Betamax-Urteil, in dem einst die Verbreitung von Videorekordern erfasst wurde. Der Prozess lief nun darauf hinaus, Lösungen zur Verhinderung
der Verbreitung von urheberrechtsgeschützem Material zu finden und und diese Verbreitung
zu blockieren60 .
Im November 2000 verkündete Napster überraschend eine Kooperation mit der Bertelsmann
eCommerce Group. Diese wollten zusammen eine kommerzielle Lösung entwickeln und dazu
eine Art Abo-Modell aufbauen.
Im Februar 2001 erfolgte das Urteil im Berufungsprozess. Zwar blieb danach der Betrieb
erlaubt, allerdings musste das Tauschen von urheberrechtlich geschütztem Material unterbunden werden. Um das Urteil umzusetzen, wurde ein Filterverfahren auf den zentralen
Index angewandt. Dazu erstellte die RIAA eine Liste mit 135.000 zu sperrenden Liedern.
Im März 2001 bemängelte die vorsitzende Richterin des Berufungsgerichtes die unzureichenden Filtermechanismen. Napster überarbeitete daraufhin den Filtermechanismus und erzielte
deutlich bessere Ergebnisse. Allerdings wurden dadurch auch sehr viele nicht durch das Verbot betroffene Lieder ausgefiltert.
Im Juni 2001 erfolgte die endgültige Ablehnung des Berufungsverfahrens. Um die Filterwirkung zu erhöhen, wurde ein neuer Client entwickelt, wodurch jetzt auch die Filterung mittels
digitaler Fingerabdrücke möglich wurde. Um die Wirksamkeit sicherzustellen und einen Umstieg auf die neue Software zu erzwingen, sperrte Napster die alten Clients kurzerhand aus.
Dadurch sank die Nutzerzahl von 1,57 Millionen im Feb 2001 auf 320.000 im Juni. Viele
Nutzer stiegen auf eines der zahlreichen alternativen Angebote um.
Im August 2001 erfolgte eine vorübergehende“ Einstellung des Betriebs wegen angeblicher
”
Filterprobleme. Daraufhin legte das Gericht fest, dass Napster erst wieder online gehen dürfe,
wenn sichergestellt sei, dass kein illegales Lied durch den Filter komme.
60
(Vgl. Kossel 14.09.2000)
28
2 Grundlagen und Analyse
Dadurch wurde der Untergang von Napster besiegelt. Vom kommerziellen Programm in
Zusammenarbeit mit Bertelsmann hört man nur noch wenig. Auch Metallica“ und Dr Dre“
”
”
erkannten die Situation und einigten sich außergerichtlich.
Abbildung 2.9: Aufbau des Napster-Netzwerkes (Vgl. Steinmetz u. a. 19.12.2002, S.5)
2.4.1.2 Bittorrent
BitTorrent ist ein kollaboratives Filesharing-Protokoll, das besonders für die schnelle Verteilung großer Dateien geeignet ist. Technisch ist das Protokoll der OSI-Schicht 7, also der
Anwendungsschicht, zuzuordnen und setzt daher auf das TCP/IP-Referenzmodell auf61 .
BitTorrent besteht aus dem Tracker“ genannten Server-Programm, der Informationen zu
”
einer oder mehreren Dateien über Torrents verwaltet, und einem Client, der vom Tracker
erfährt, wer sonst noch die Datei herunterlädt und verteilt. In einer Torrent-Datei befinden
sich die Adresse des Trackers sowie Dateiname, Größe und Prüfsummen der herunterzuladenden Datei. Sobald ein Client ein kleines Stück der Datei erhalten hat und die Prüfsumme
verifiziert hat, meldet er dies dem Tracker und kann dieses Datei-Stück schon an andere
Clients weitergeben.
2.4.1.3 eDonkey62
eDonkey2000 (ed2k) bezeichnet zum einen ein Internet-Filesharing-Netz und zum anderen
den ersten Client für dieses Netz. In eDonkey2000 kommen sowohl Teile des Peer-to-PeerPrinzips als auch Teile des Client-Server-Prinzips zum Tragen.
61
62
(Vgl. Wikipedia, http://www.de.wikipedia.org/wiki/Bittorrent)
(Vgl. Wikipedia, http://www.de.wikipedia.org/wiki/EDonkey)
2.4 Peer-to-Peer
29
Abbildung 2.10: BitTorrent-Netzwerk (BitTorrent.org, Vgl.)
Zunächt war das Netz nur mit der gleichnamigen Software von MetaMachine nutzbar. 2002
entstand dann aber das Projekt eMule. Der Client eMule ist inzwischen mit Abstand der
meist genutzte Client für des eDonkey2000-Netz.
2005 stellten die Entwickler der ursprünglichen Software, nach Drohungen mit Schadensersatzforderungen seitens der RIAA, die Weiterentwicklung vorübergehend ein. Im März 2006
wurde die Entwicklung fortgesetzt.
Am 21.Februar 2006 erfolgte der schwerste Schlag gegen das edonkey2000-Netz. Bei einer groß
angelegten Aktion wurde in Belgien der größte Server Razorback 2.0“ abgeschaltet63 .
”
Am 12.09.2006 stellte MetaMachine den Vertrieb der eDonkey2000-Software endgültig ein64
und meldete am 13.09.2006, dass sie 30 Millionen US-Dollar an die Musikindustrie zahlen würden, um rechtlichen Auseinandersetzungen mit der RIAA aus dem Weg zu gehen65 .
Allerdings fristete zu dieser Zeit die eDonkey2000-Software sowieso nur noch ein Nischendasein66 .
Abbildung 2.11 zeigt den Aufbau des eDonkey-Netzwerks.
Nutzen der Client-Server-Architktur:
63
(Vgl.
(Vgl.
65
(Vgl.
66
(Vgl.
64
Zota 22.02.2006)
Zota 12.09.2006)
Jurran 13.09.2006)
Zota 12.09.2006)
30
2 Grundlagen und Analyse
Abbildung 2.11: eDonkey-Netzwerk (Vgl. Kulbak und Bickson January 20, 2005, S.5)
• Der Client übermittelt Informationen über seine freigegebenen Dateien an einen der
Server, der diese indiziert.
• Zur Suche übermittelt ein Client Suchinformationen (Bsp. Dateiname, Typ, . . . ) an den
Server. Der Server durchsucht seine Indizes und schickt entsprechenende Dateiquellen in
Form von ed2k-Links zurück. ed2k-Links dienen zur einfachen Aufnahme eines Servers
in die Serverliste oder einer Datei in die Downloadliste des Clients. Bsp. ed2k-Link:
ed2k://|file|datei.txt|123|1234567890abcdef1234567890abcdef|
• Der Client schickt regelmäßig Anfragen zum Server, welche Clients die Dateien, die er
herunterladen möchte, freigegeben haben. Der Server schickt entsprechende Einträge
zurück.
eMule nutzt das Peer-to-Peer-Konzept auf ähnliche Weise wie bereits Napster. Nach Erhalt der Informationen vom Server in Form von ed2k-Link versucht der Client, sich zu den
entsprechenden Clients direkt zu verbinden. In diesem Fall haben die Clients echte PeerFunktionalität und der Server spielt keine Rolle mehr.
Zur Minimierung der Netzlast wurde in eMule neben dem eDonkey-Protokoll ein neues
Netzwerk-Protokoll implementiert. Daher ist bei allen neueren Versionen von eMule auch
das Kademlia-Protokoll (vgl. Abschnitt 2.4.1.4 S.31) verfügbar.
2.4 Peer-to-Peer
31
2.4.1.4 Kademlia
Kademlia (Kad) gehört zu einer neuen Generation von Peer-to-Peer-Protokollen. Wie bereits
erwähnt, gibt es verschiedene Herangehensweisen:
• zentraler Suchindex auf Server (Bsp. Napster)
• kein zentraler Indexierungsserver; Suchanfragen werden an einen Teil des Netzes geschickt. Peers, die die gesuchte Datei besitzen, melden dies an den suchenden Peer.
Problem: nicht alle Peers werden durchsucht. (Bsp. Gnutella67 )
• Verwendung einer verteilten Hashtabelle (Distributed Hashtable (DHT)); diese Struktur ersetzt den zentralen Indexierungsserver. Durch die verteilte Hashtabelle werden
allen verfügbaren Dateien mit einem Aufwand von O(log n) gefunden. (Bsp. Kademlia)
Zur Funktionsweise von Kademlia:
Es erfolgt eine eindeutige Identifizierung eines jeden Peers durch eine eindeutige Nummer,
die sogenannte Node-ID. Vor dem Eintritt in das Kademlia-Netzwerk wird ein sogenannter Bootstrapping-Prozess durchgeführt. Dazu muss man wissen, dass man, um sich zum
Kademlia-Netzwerk verbinden zu können, eigentlich schon erstmal selbst ein Teil des
Kademlia-Netzwerkes sein muss. Um dies zu ermöglichen, verbindet man sich im
Bootstrapping-Prozess über lediglich einen bekannten Client bzw. über dessen Kontakte.
Nach und nach verbindet man sich so mit dem gesamten Kademlia-Netzwerk.
Im Anschluss erfolgt die Berechung der verteilten Hashtabelle. Dazu wird für jede freigegebene Datei ein Hash-Wert berechnet. Der Datei-Hash und die Node-ID sind gleich lang
(160 bit). Der Kademlia-Algorithmus sucht nun im Netz nach Knoten, deren ID die kleinste Distanz“ zum Datei-Hash aufweisen, und übermittelt ihm seine Daten. Eine bitweise
”
exklusive-ODER-Verbindung - als Interger interpretiert - wird zum Abstand zwei IDs definiert (d.h. d(x, y) = x ⊗ y)).
Bei der Suche nach einer Datei nutzt der Peer die gleiche Prozedur wie beim Einfügen einer
Datei in die verteilte Hashtabelle. Da normalerweise ständig Peers ein- und austreten, werden
die Informationen auf mehrere Peers verteilt und alle paar Stunden aktualisiert.
2.4.2 JXTA
JXTA (engl. juxtapose = nebeneinander stellen) ist ein von Sun Microsystems ins Leben gerufenes Projekt. Es wurde im April 2001 unter der Leitung von Bill Joy und Mi67
Gnutella ist ein vollständig dezentrales Netzwerk (Vgl. Wikipedia, http://de.wikipedia.org/wiki/Gnutella).
32
2 Grundlagen und Analyse
ke Clary gegründet. JXTA definiert auf sehr abstrakte Weise eine Reihe von Protokollen und XML-Formaten, die für alle Anwendungen, die Peer-to-Peer nutzen möchten, eine
ausgereifte und wiederverwendbare Basis sein können. Dazu verwendet JXTA eine DreiSchichten-Architektur, XML-basierte Protokolle und einige grundlegende Abstraktionen wie
Peer Groups, Pipes und Advertisements, um eine einheitliche Programmierplattform für
Peer-to-Peer-Anwendungen zu schaffen und Interoperabilität und Unabhängigkeit von
Software- und Hardwareplattformen zu ermöglichen68 .
2.4.2.1 Wichtige Grundbegriffe der JXTA-Technologie
Das JXTA-Netzwerk besteht wie jedes Peer-to-Peer Netz aus einer Reihe untereinander verbundener Knoten, den sogenannten Peers. Ein Peer ist hierbei nicht an ein physikalisches
Endgerät gebunden. Vielmehr können auf jedem Gerät parallel mehrere Peers gestartet werden. Jeder Peer wird eindeutig durch eine Peer-ID identifiziert.
In JXTA existieren vier verschiedene Typen von Peers:
• Unter einem Minimal Peer versteht man einen Peer, der nur die grundlegendsten Funktionen, nämlich das Senden und Empfangen, ermöglicht. Diese Peers werden zumeist
auf Rechner mit minimalen Systemleistungen, wie z.B. PDAs oder Mobiltelefonen,
verwendet.
• Der Edge Peer ist der Standard-Peer. Jeder Peer implementiert standardmäßig die
Funktionen eines Edge Peers. Der Minimal Peer ist eine eingeschränkte Version des
Edge Peers. Der Edge Peer legt zusätzlich zu den Sende- und Empfangsfunktionalitäten
Informationen über bekannte Ressourcen wie andere Peers, Peergruppen oder Dienste
lokal ab. Des Weiteren implementiert der Edge Peer alle Dienste, die eine Anwendung
aus Sicht des Nutzers benötigt, um zu funktionieren.
• Um Nachrichten über Firewalls, Network Address Translation (NAT), . . . hinweg zu
übermitteln, wird ein Relay-Peer benötigt. Dieser wird darüber hinaus benötigt, um
einen Minimal Peer in das Netzwerk einzubinden. Der Relay-Peer erhält Informationen
über Wege zu anderen Peers und nutzt diese, um Nachrichten weiterzuleiten (Routing).
• Der Rendezvous-Peer bildet eine server-ähnliche Instanz im hybriden JXTA-Netzwerk.
Über diesen Peer erfolgt eine Auflösung von Anfragen nach Ressourcen. Dazu wird eine
Distributed Hash Table gebildet, die sich über alle bekannten Peers und RendezvousPeers erstreckt.
68
(Vgl. Hauswirth und Dustdar 09.11.2006, S.9)
2.4 Peer-to-Peer
33
Ein weiterer wichtiger Bestandteil von JXTA ist die Metadaten-Struktur der Advertisements.
Ein Advertisement ist ein XML-Dokument zur Beschreibung von Ressourcen (Peers, Pipes,
Gruppen, Dienste, . . . ). Jedes Advertisement besitzt eine eindeutige ID und verfügt über eine
individuell definierte Lebenszeit, die dazu genutzt wird, veraltete Ressourcen zu entfernen,
ohne dazu eine zentrale Kontrollinstanz zu nutzen. Nach Ablauf der Lebenszeit muss das
Advertisement neu veröffentlicht werden, um es weiter nutzen zu können. Abbildung 2.12
zeigt die Architektur von JXTA.
Abbildung 2.12: Die JXTA-Architektur (Vgl. Hauswirth und Dustdar 09.11.2006, S.10)
Im JXTA-Kern befindet sich der Code zur Implementierung der Protokolle. Diese Protokolle
stellen die Funktionalitäten für Peers, Peer Groups, die Sicherheit und die Überwachung
der Peers (engl. Monitoring) zur Verfügung. Auf dem Kern bauen die bekannten Dienste
wie Suche und File-Sharing auf, welche wiederum als Grundlage für JXTA-Anwendungen
dienen.
Wie bereits erwähnt, bilden sechs Protokolle den Kern von JXTA. Das Peer Resolver Protocol
(PRP) dient zum Senden von Suchanfragen zu allen anderen Peers und zum Empfangen
von einer Antwort. Über das Peer Discovery Protocol (PDP) veröffentlichen die Peers ihre
Dienste und suchen nach Diensten der anderen Peers. Mit dem Peer Information Protocol
(PIP) können Statusinformationen über Peers abgefragt werden. Das Pipe Binding Protocol
(PBP) stellt die Pipes für die Kommunikation. Dabei sorgt das Peer Endpoint Protocol
(PEP) dafür, dass zwischen den beiden beteiligten Peers eine Route mit Hilfe anderer Peers
gefunden werden kann. Das Rendezvous Protocol (RVP) wird benötigt, um Nachrichten auch
über Firewalls hinweg zu verbreiten69 .
69
(Vgl. Gradecki 2002, S.16)
34
2 Grundlagen und Analyse
2.4.3 Klassifizierung von Peer-to-Peer-Systemen
Um eine Klassifizierung der zuvor vorgestellten Peer-to-Peer-Systeme zu ermöglichen müssen
zuerst einmal verschiedene Kriterien zur Klassifizierung eingeführt werden70 :
• Strukturierungsgrad : Hier muss zwischen unstrukturierten Systemen und strukturierten
Systemen unterschieden werden. In einem unstrukturierten System verfügt ein Peer
über keine Informationen über andere Peers. Ein Beispiel hierfür sind alle InternetTauschbörsen, die über einen zentralen Index verfügen. In strukturierten Systemen
verwaltet ein Peer hingegen lokal Informationen über andere Peers. Kademlia ist ein
Beispiel dafür.
• Hierarchiegrad : Hier muss zwischen einem flachen und einem hierarchischen Hierarchiegrad unterschieden werden. In einem flachen Peer-to-Peer-System gibt es keine verschiedenen Rollen, die ein Peer spielen kann. In hierarchischen Peer-to-Peer-Systemen
existieren hingegen verschiedene Rollen, die ein Peer spielen kann. Ein Beispiel sind
alle Tauschbörsen, die über einen zentralen Server verfügen. Dieser kann als spezieller
Peer mit sehr speziellen Aufgaben interpretiert werden.
• Kopplungsgrad : Hier muss zwischen lose und eng gekoppelten Systemen unterschieden werden. In stark gekoppelten Systemen übernimmt ein Peer innerhalb einer PeerGruppe eine spezielle Aufgabe, beispielsweise in Kademlia die Verwaltung eines Teils
der verteilten Hashtabelle oder in JXTA die Art der Nachrichtenbehandlung. Dahingegen ist es für einen Peer in einem lose gekoppelten System unnötig, derartige Aufgaben zu übernehmen. Dies hat zur Folge, dass in einem stark gekoppelten System das
Ausscheiden eines Peers besonders behandelt werden muss, wohingegen in einem lose
gekoppelten System das Ausscheiden eines Peers für das Gesamtsystem ohne Belang
ist.
Napster
eDonkey
BitTorrent
Kademlia
JXTA71
70
71
Struktierungsgrad
Hierarchiegrad Kopplungsgrad
unstrukturiert strukturiert flach hierarchisch eng
lose
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
√
( )
( )
( )
( )
( )
( )
Tabelle 2.1: Klassifizierung der Peer-to-Peer-Systeme
(Vgl. Hauswirth und Dustdar 09.11.2006, S.4)
Klassifizierung abhängig von der jeweiligen Implementierung.
35
3 Entwurf
Die Entwicklung einer verteilten Lösung zum Download und zur Analyse von urheberrechtlich geschützem Material aus Internet-Tauschbörsen erfordert zunächst die Erstellung eines
Konzepts. Hierzu wird ein abstraktes Modell einer implementierbaren Lösung entworfen. Der
in dieser Arbeit vorgestellte Entwurf basiert auf der Idee, Dateien auf der Basis einer von
Schlüsselworten gesteuerten Suche zu finden und anschließend diese Dateien in einem verteilten System nach digitalen Wasserzeichen zu untersuchen.
3.1 Zielsetzung
Ziel der Arbeit ist der Entwurf eines verteilten Systems zum effizienten Auffinden und Herunterladen von mit digitalen Wasserzeichen markiertem Material in Internet-Tauschbörsen.
Die gefundenen Dateien werden nach dem Download an die integrierte Analyse-Komponente
übergeben. Die zu findenden digitalen Medien wurden mit einem digitalen Wasserzeichen,
wie z.B. einer Kundennummer, versehen. Damit ist eine eindeutige Identifizierbarkeit des
Käufers möglich (vgl. Abbildung 3.1).
Abbildung 3.1: Digitales Wasserzeichen zur Identifikation
36
3 Entwurf
Abbildung 3.1 zeigt, wie eine auf legalem Wege erworbene Datei in einer Internet-Tauschbörse
veröffentlicht wird. Das in dieser Arbeit entworfene System dient zum Auffinden derartiger
Dateien und zur anschließenden Analyse, also dem Auslesen der eingebetteten Wasserzeicheninformation. Um dabei eine hohe Effizienz und Performance zu erreichen, wurde dazu
ein verteiltes System entworfen. Da das Auslesen eines Wasserzeichens einen Zeitaufwand nahe Echtzeit benötigt sowie durch die große Anzahl der in Internet-Tauschbörsen verfügbaren
Dateien, kann durch die parallele Verarbeitung in einem verteilten System eine wesentlich
höhere Such- und Analyseleistung gegenüber einer Einzelrechnerlösung erreicht werden.
Da das Hauptaugenmerk auf dem effizienten Download der gesuchten Dateien liegt, wird das
Analyseverfahren nur als Blackbox-Verfahren betrachtet und es erfolgt keine Überprüfung
auf Validität der Analyseparameter. Abbildung 3.2 zeigt diese Blackbox.
Abbildung 3.2: Blackbox Wasserzeichen-Analyse
Um den Such- und Analysevorgang zu synchronisieren und um Kollisionen zu vermeiden,
wird das verteilte System nach dem Master-Slave-Prinzip realisiert. Dabei übernimmt eine
Instanz im System, der sogenannte Master, die Aufgabe, die Suche und Analyse zentral zu
koordinieren. Die untergeordneten Instanzen, die sogenannten Slaves, sind dabei nur Befehlsempfänger. Abbildung 3.3 zeigt einen möglichen Systemaufbau eines verteilten Systems mit
einem Master und 5 Slaves. In diesem Beispiel wurde auf das Internet-Tauschbörsennetzwerk
eMule bzw. eDonkey zurückgegriffen.
Bei diesem Systemaufbau ist auch eine zentrale Steuerung des Systems durch einen Benutzer vorgesehen. Dieser kann alle für einen Such- und Analysevorgang nötigen Parameter,
z.B. Suchparameter wie Metallica“, Auswahl des Wasserzeichen-Algorithmus oder Wahl des
”
zu suchenden Medientyps, zentral an einer Benutzerschnittstelle (engl. GUI ) des Masters
eingeben und verwalten.
3.2 Ablauf der Suche und Analyse
37
Abbildung 3.3: Systemübersicht
3.2 Ablauf der Suche und Analyse
Abbildung 3.4 zeigt wie ein Such- und Analysevorgang im Idealfall ablaufen kann.
Im ersten Schritt erfolgt eine Eingabe des Suchparameter in der Benutzerschnittstelle des
Masters. Dabei legt der Anwender zunächst fest, mit welchem Suchwort nach welchem
Medientyp (z.B. Audio-Dateien) gesucht werden soll. Zudem erfolgt eine Auswahl des in
diesem Vorgang zu verwendenden Wasserzeichen-Algorithmus und des zu verwendenden
Wasserzeichen-Schlüssels.
Nach Eingabe der Parameter werden diese an alle dem Master bekannten Slaves geschickt.
Jeder der Slaves führt im Anschluss eine Suche in dem ihm bekannten Tauschbörsen-Netzwerk
38
3 Entwurf
Abbildung 3.4: Ablauf der Suche und Analyse
durch. Im Beispiel wurde dabei wieder das eMule- bzw. eDonkey-Netwerk ausgewählt. In
diesem Netzwerk wird eine Suche an einen der zentralen Server geschickt und dieser sendet
eine entsprechende Ergebnisliste zurück.
Nach Erhalt der Suchergebnisse aus dem Internet-Tauschbörsennetzwerk sendet jeder der
Slaves diese Ergebnisse an den Master zurück. Der Master koordiniert diese Suchergebnisse
nun und wählt zu jeder gefundenen Datei (mehrere Slaves können die selbe Datei in Tauschbörsennetzwerk finden) den bestmöglichen Slave zur weiteren Verarbeitung aus. Mehr zur
Verteilung der Dateien findet sich in Abschnitt 3.5 über Lastverteilung auf Seite 42.
Nach der Verteilung aller Suchergebnisse sendet der Master an jeden Slave eine individuelle
Bearbeitungsliste. Diese Liste enthält neben den verschiedenen Datei-IDs die zur anschließenden Analyse nötigen Angaben zu Wasserzeichen-Algorithmus und zu verwendendem Schlüssel.
3.3 Anforderungen
39
Jeder Slave beginnt nun mit dem
Download der ihm zugewiesenen Dateien. Nach dem Download einer der Dateien beginnt der
Slave mit dem Auslesen des Wasserzeichens unter Verwendung des zugewiesenen WasserzeichenAlgorithmus und des Schlüssels. Nach der Analyse sendet der Slave das Analyse-Ergebnis,
im Idealfall ein ausgelesenes Wasserzeichen, zum Master.
Dieses Beispiel beschreibt lediglich den Ablauf im Idealfall. Allerdings treten in einem verteilten System zahlreiche Ausnahmen, wie z.B. der Ausfall eines Slaves, auf. Um diese zu
berücksichtigen, werden im Abschnitt 3.4 verschiedene Ausnahmefälle und entsprechende
Ausnahmebehandlungsmethoden entworfen.
3.3 Anforderungen
Bei der Beschreibung der Anforderungen an das zu entwickelnde System wird zwischen primären und sekundären Anforderungen unterschieden. Primäre Anforderungen müssen zwingend durch die prototypische Implementierung erfüllt werden, während sekundäre Anforderungen nur im Idealfall erfüllt sein müssen.
Primäre Anforderungen:
• Effizientes Auffinden und Analysieren von mit digitalen Wasserzeichen versehenen Dateien
• Transparenz gegenüber der verwendeten Internet-Tauschbörse
• Unerkannter Betrieb im Internet-Tauschbörsennetz
• Bestmögliche Ausnutzung der zur Verfügung stehenden Ressourcen
• Gute Skalierbarkeit des Systems
• Fehlertoleranz bei Ausfall eines Slaves
• Gute Erweiterbarkeit um neue Wasserzeichen-Algorithmen
• Erweiterbarkeit um weitere Internet-Tauschbörsen
Sekundäre Anforderungen:
• Vollständige Analyse aller zu einer Suchanfrage gefundenen Dateien
• Fehlertoleranz bei Ausfall des Masters
40
3 Entwurf
Wichtigste Anforderung an das System ist die aus dem Ziel hervorgehende Anforderung
des effizienten Auffindens und Analysierens von mit digitalen Wasserzeichen versehene Dateien. Diese Anforderung wird durch den Aufbau eines verteilten Systems und durch eine
entsprechende Lastverteilung (siehe Abschnitt 3.5) erfüllt.
Die Anforderung der Transparenz gegenüber der verwendeten Internet-Tauschbörse
beschreibt die Anforderung, dass es für das ganze System unerheblich sein soll, welcher Slave
welche Tauschbörse nutzt. Dazu wird in Abschnitt 3.6 eine Schnittstelle eingerichtet.
Um gute Ergebnisse zu erreichen und um eine gute Leistung zu erzielen, ist das unerkannte
Verbleiben im Tauschbörsen-Netzwerk sehr wichtig. Viele Internet-Tauschbörsen verfügen
über Mechanismen, auffällige Clients aus dem Netzwerk auszuschließen. In vielen Systemen
ist z.B. der übermäßige Download gegenüber geringem oder keinem Upload, d.h. dem Anbieten von Dateien in der Tauschbörse, ein Ausschlusskriterium. Einfache Gegenmaßnahme
gegen dieses Ausschlusskriterium ist das Anbieten von legalen Dateien in der Tauschbörse,
wie z.B. von Open-Source-Produkten.
Weitere sehr wichtige Anforderungen für das System sind die bestmögliche Ausnutzung der
zur Verfügung stehenden Ressourcen, eine gute Skalierbarkeit und eine Fehlertoleranz bei
Ausfall eines Slaves. Diese Anforderungen werden durch die Wahl der verwendeten Kommunikationsplattform (siehe Abschnitt 3.7), durch eine gute Lastverteilung (siehe Abschnitt
3.5) und durch den Entwurf von Behandlungsmethoden in Ausnahmefällen (siehe Abschnitt
3.4) gewährleistet.
Zuletzt werden eine gute Erweiterbarkeit um neue Wasserzeichenalgorithmen und um weitere Internet-Tauschbörsen gefordert. Diese Forderungen sind nötig, um das System an die
sich ständig weiterentwickelnden Technologien anzupassen. Zudem wird durch diese Anpassungsfähigkeit das System auf die verschiedenen Bedürfnisse von verschiedensten Kunden
anpassbar.
Anforderungen, die lediglich im Idealfall erfüllt sein müssen, sind die vollständige Analyse
aller zu einer Suchanfrage gefundenen Dateien und die Fehlertoleranz bei Ausfall des Masters.
Die vollständige Analyse kann kein zwingendes Kriterium sein, da in einem Peer-to-PeerTauschbörsensystem in regelmäßigen Abständen Clients ein- und austreten. Daher ist es
möglich, dass seltene Dateien bei Austritt eines oder mehrerer Clients aus dem System nicht
mehr verfügbar sind.
Desweiteren ist die Fehlertoleranz bei Ausfall des Masters für eine erste prototypische Implementierung nicht zwingend erforderlich.
3.4 Ausnahmefälle
41
3.4 Ausnahmefälle
In diesem Abschnitt werden die verschiedenen Ausnahmefälle vorgestellt, die für die Entwicklung des Systems betrachtet wurden, und zudem wird ein erster Lösungsansatz zur
Fehlerbehandlung vorgestellt. Folgende Fälle wurden beachtet:
1. Normalstart → Start Master → Start der Slaves
2. Start des Systems nach kompletter Abschaltung des Systems → Möglichkeit des Fortsetzens unabgeschlossener Aufträge
3. Slave stürzt ab oder wird beendet → Neuverteilung der Aufträge des ausfallenden
Slaves
4. Neuer Slave tritt während laufender Analyse ein → Abgabe von ungestarteten Aufträgen an diesen Slave
5. Slave beendet seine Aufträge → Neuverteilung ungestarteter Aufträge
6. Absturz des Masters, Slaves laufen noch → Aufträge pausieren
Fall 1 stellt den Normalstart dar, d.h. dass das System ohne zuvor aufgetretene Fehler gestartet wird. Dazu wird zunächst der Master
gestartet und im Anschluss alle Slaves.
Fall 2 beschreibt den Start des Systems, nachdem das System entweder durch den Nutzer
beendet wurde oder durch einen Fehler ein Neustart des gesamten Systems nötig war. Hierbei
ist eine Wiederaufnahme der unabgeschlossenen Analyse-Aufträge angedacht.
In Fall 3 wird der Ausfall eines Slaves während einer laufenden Analyse behandelt. Grund für
diesen Ausfall kann das Beenden des Slaves durch einen Nutzer oder ein Systemausfall sein.
Der Master reagiert mit einer Neuverteilung aller von diesem Slave übernommenen Aufträge
auf die noch vorhandenen Slaves.
Fall 4 zeigt den Konstellation, dass ein neuer Slave während einer bereits laufenden Analyse dem System beitritt. Ein mögliches Herangehen dabei wäre, den Slave für diese Sitzung
zu ignorieren und erst bei einer neuen Analyse mit einzubeziehen. Da aber eine optimale
Nutzung erreicht werden soll, wird eine Neuverteilung noch ungestarter Aufträge als Ausnahmebehandlung vorgezogen. Ungestartete Aufträge sind in diesem Fall alle Aufträge, die
zwar bereits an verschiedene Slaves vergeben wurden, deren Download aber noch nicht begonnen hat.
In Fall 5 hat ein Slave alle aufgetragenen Analysen ausgeführt. Darauf wird wie in Fall 4 mit
einer Neuverteilung der ungestarteten Aufträge reagiert.
42
3 Entwurf
Der letzte Fall ist der mögliche Absturz des Masters. Da dieser in der ersten prototypischen
Implementierung als zentraler Dienst implementiert wird, ist eine Pausierung und Zwischenspeicherung aller Analyseaufträge auf den Slaves am praktischsten.
3.5 Lastverteilung
In diesem Kapitel wird beschrieben, mit welchen Kriterien eine Verteilung der durch die
Suche gefundenen Resultate unter den einzelnen Slaves erfolgt.
Kriterium
Gewichtung
Geschwindigkeit des Prozessors in MHz
0,4
Größe des Arbeitsspeichers in MByte
0,4
Geschwindigkeit der Internet-Anbindung in KBit/s 0,2
Anzahl der Analysen auf dem Slave
1
Tabelle 3.1: Kriterien zur Lastverteilung
Tabelle 3.1 zeigt eine Übersicht über die verwendeten Kriterien. Die Geschwindigkeit des
Prozessors und die Größe des Arbeitsspeichers sind Anhaltspunkte für die Leistungsfähigkeit
des Rechners. Die Geschwindigkeit der Internetanbindung gibt Aufschluss über die Anbindung des Rechners an das Internet. Im Falle dieser Arbeit wird dabei nur die Downloadrate
betrachtet. Die drei genannten Kriterien dienen zur Bestimmung der Gesamtleistung eines
Slaves. Dazu erfolgt zudem eine Gewichtung der einzelnen Kriterien. Damit wird erreicht,
dass ein leistungsstarker Slave mit einer eher schwachen Internetanbindung dennoch besser
bewertet wird als ein eher leistungsschwacher Slave mit einer guten Internet-Anbindung. Die
Gewichtung ist nötig, da der eigentliche Analyse-Prozess, also das Auslesen der Wasserzeichen, wesentlich rechenintensiver ist als der Download-Prozess.
Die Gesamtleistung eines Slaves wird somit durch die Addition der gewichteten Kriterien
Prozessor-Leistung, Arbeitsspeicher-Größe und Download-Geschwindigkeit berechnet. Durch
die Division durch die Anzahl der auf dem Slave gestarteten Analysen wird eine Lastverteilung erreicht. Ohne die Division würde der stärkste Slave alle Analyseaufträge erhalten,
wohingegen alle anderen Slave ohne Auftrag wären.
Die Formel zur Lastverteilung lautet somit:
y=
0, 4xP rozessor−Leistung + 0, 4xArbeitsspeicher−Größe + 0, 2xDownload−Geschwindigkeit
xAnzahlderAuf träge
Der Slave mit dem höchsten Wert für y erhält den Analyse-Auftrag für die Datei.
3.6 Schnittstelle zu Internet-Tauschbörsen
43
Die hier verwendete Lastverteilung ist für eine erste prototypische Implementierung ausreichend. Darüber hinaus wäre die Verwendung der folgenden Kriterien möglich:
• Verfügbarkeit der Datei im Tauschbörsen-Netzwerk (Diese ist abhängig vom verwendeten Tauschbörsen-Netzwerk. Weitere Einflussfaktoren für die Verfügbarkeit sind abhängig von der Wahl des Tauschbörsen-Netzwerkes. Im eMule- bzw. eDonkey-Netzwerk
wären dies z.B. der verbundene Indexierungsserver)
• Auslastung des Systems (z.B. Prozessorauslastung, Arbeitsspeicherauslastung, Auslastung der Internet-Verbindung)
3.6 Schnittstelle zu Internet-Tauschbörsen
Durch die Definition einer allgemeinen Schnittstelle zwischen Slave und Internet-Tauschbörse
wird die in Abschnitt 3.3 geforderte Anforderung nach einer guten Erweiterbarkeit um verschiedene Internet-Tauschbörsen und der Transparenz gegenüber der gewählten InternetTauschbörse erfüllt.
Abbildung 3.5: Schnittstelle zu Internet-Tauschbörsen
Abbildung 3.5 zeigt das Klassendiagramm der entworfenen Schnittstelle zu Internet-Tauschbörsen. In der Schnittstelle wurden verschiedene Methoden definiert.
Die Methoden getInfo() und getServerInfo() dienen zur Anforderung von Informationen über
das Tauschbörsen-Netz und über einen – je nach gewähltem Netz – verbundenen Server.
44
3 Entwurf
Durch die Methoden getState(), downloadState() und searchState werden verschiedene Statusmeldungen abgefragt. Die Methode searchState dient nur der Anfrage, ob eine Suchanfrage beendet ist und somit ob Suchresultate vorliegen. Diese Ergebnisse können dann mit
der Methode getResult abgefragt werden. Die Methode downloadState() liefert dagegen die
verschiedenden Download-Zustände der herunterzuladenden Dateien. Und die Methode getState() liefert den Status der Internet-Tauschbörse.
Die Methoden connect() und connect(String to) sind zum Aufbau der Verbindung in das
Tauschbörsennetzwerk vorgesehen. Dabei wird je nach Tauschbörse ein Parameter mit z.B.
einer Server-ID benötigt. Die Methode disconnect() trennt die Verbindung zum Tauschbörsennetzwerk.
Zuletzt dienen die Methoden downloadFile(), stopDownload(), pauseDownload() und resumeDownload() zur Aufnahme bzw. zum Stoppen, Pausieren oder zur Wiederaufnahme des
Downloads der angegebenden Datei.
3.7 Wahl der verwendeten Komponenten
In diesem Abschnitt wird die Wahl der verschiedenen, in der prototypischen Implementierung verwendeten Komponenten begründet. Die Umsetzung des Prototyps erfolgt in der
objektorientierten Programmiersprache JAVA.
3.7.1 Wahl der Tauschbörse
In der ersten exemplarischen Implementierung wird der Internet-Tauschbörsen-Client eMule
verwendet. Dieser ist der zur Zeit neben Bittorrent meistgenutzte Client. Vorteile gegenüber
Bittorrent sind die bessere Suchfunktion und das bereits vorhandene Webinterface. Dadurch
ist eine Anbindung des Clients an den Slave ohne Eingriff in den Quellcode möglich. Dies hat
zum Vorteil, dass bei einem Update nur auf zumeist geringe Änderungen am Webinterface
reagiert werden muss und nicht auf die oft weitreichenden Änderungen im Quellcode. Die
Anpassung des Webinterfaces an die in Abschnitt 3.6 definierte Schnittstelle zu den InternetTauschbörsen erfolgt mittels des in Gamma und Riehle (2000) definierten Entwurfsmusters
des sogenannten Adapters bzw. Wrappers1 (siehe Abschnitt 4.2.4.1).
1
(Vgl. Gamma und Riehle 2000, S.151 ff)
3.8 Datei-Identifikation
45
3.7.2 Wahl der Kommunikationsplattform
Die Vor- und Nachteile von Peer-to-Peer-Anwendungen gegenüber Client-Server-Anwendungen wurden bereits in Abschnitt 2.4 erörtert. Zwar ist der hier entwickelte Prototyp noch
sehr stark an einer Client-Server-Anwendung orientiert, allerdings soll durch den Einsatz
von JXTA ein Ausbau zu einem reinen Peer-to-Peer-System wesentlich vereinfacht werden.
Zudem besitzt JXTA weitere Vorteile gegenüber anderen Kommunikations-Formen wie RMI,
CORBA, . . . :
• Unabhängig von einer Programmiersprache
• Unabhängig von Hardware und Betriebssystem
• Interoperabilität
• kein Design der grundlegenden Kommunikationsmechanismen nötig
• Verwendung des XML-Formates zum Datenaustausch
Allerdings müssen auch einige Nachteile erwähnt werden:
• JXTA selbst noch in der Entwicklungsphase
• wenige, oft veraltete Literatur zu JXTA
3.8 Datei-Identifikation
Um jede Datei korrekt bearbeiten zu können, wird eine eindeutige Datei-ID im System zur
Identifikation einer Datei benötigt. Um eine eindeutige Zuordnung zu gewährleisten, ist eine
ID nicht auf den Dateinamen zurückzuführen.
eMule verwendet zwei verschiedene Arten von IDs zur Identifikation von Dateien, die durch
Hashing des Dateiinhalts berechnet werden. Der sogenannte File Hash wird zur eindeutigen Identifizierung einer Datei im Netzwerk genutzt und der sogenannte Root Hash“ ist
”
hauptsächlich zur Feststellung und Behebung von Übertragungsfehlern.
Der File Hash ist eine 128bit Globally Unique Identifier (GUID) . Die GUID wird unter
Verwendung des MD4-Algorithmus verwendet. Während der Berechnung der File ID wird
die Datei in 9,28 MB große Dateiteile zerlegt. Die GUID wird für jeden dieser Dateiteile
berechnet und dann werden diese Hashs zu einer eindeutigen File ID kombiniert.
Der Root Hash wird für jeden der 9,28 MB großen Dateiteile durch den SHA1-Algorithmus
berechnet.
46
3 Entwurf
Desweiteren müssen die verschiedenen Arten der Dateisuche und der Download-Vorgang im
eMule-Netzwerk betrachtet werden. Bei der Dateisuche kann zwischen den Methoden Ser”
ver“, Global (Server)“ und Kad Netzwerk“ unterschieden werden. Die Suchmethode Server“
”
”
”
bedeutet eine Suche ausschließlich auf dem verbundenen eMule- bzw. eDonkey-Server. Unter der Suchmethode Global (Server)“ versteht man die Suche auf allen Servern, die in der
”
Serverliste des eMule-Clients eingetragen sind. Und zuletzt bedeutet die Suchmethode Kad
”
Netzwerk“ eine Suche nur im Kademlia-Netzwerk. Die Suchmethode Global (Server)“ hat
”
sich als die effizienteste erwiesen und wird daher in der prototypischen Implementierung
verwendet.
Der Download-Vorgang im eMule-Netzwerk läuft folgendermaßen ab: Nach Hinzufügen der
Datei in die Downloadliste werden zunächst alle Server in der Serverliste des Clients nach
Quellen durchsucht. Die Downloadquellen werden dann in die Warteschlange gesetzt. Weitere
Quellen werden durch die Suche im Kademlia Netzwerk hinzugefügt. Nachdem die ersten
Quellen für einen Download gefunden wurden, werden diese Quellen nach möglichen weiteren
Quellen gefragt. Diese werden dann auch in die Liste hinzugefügt. Weitere Quellen sind
sogenannte passive Quellen. Diese Quellen sind Clients, die selber nach der Datei suchen
und daher in der Warteschlange zum Upload stehen. Von diesen Quellen ist zwar nicht der
Bezug der kompletten Datei, aber von Dateiteilen möglich.2
Die vorangegangenen Überlegungen reichen aus, um zu bestimmen, dass die in eMule verwendete GUID auch zur Identifikation der Dateien im zu implementierenden System verwendet
werden kann. Zudem kann durch die Einsicht in den Download-Vorgang weiter festgelegt
werden, dass ein Datei-Download von einem beliebigen Slave heruntergeladen werden kann.
Allerdings sollte generell jeder eMule-Client regelmäßig mit einer neuen aktuellen Serverliste aktualisiert werden. Dazu kann die automatische Update-Funktion des Clients genutzt
werden, um eine neue Liste aus dem Internet zu laden.
2
Die Kapitel zu den eMule-Details stammen aus dem Paper The eMule Protocol Specification“ (Vgl.
”
Kulbak und Bickson January 20, 2005)
47
4 Implementierungsaspekte
In diesem Abschnitt wird die Entwicklung eines Prototyps in Form eines ausführbaren Computerprogramms aus dem im vorherigen Abschnitt beschriebenen Entwurf erklärt. Diese Software setzt den geforderten Funktionsumfang unter Berücksichtigung der in Abschnitt 3.3
gestellten Forderungen für den vorgegebenen Anwendungsbereich um.
4.1 Entwicklungsumgebung
Die Entwicklung der prototypischen Implementierung erfolgte unter Microsoft Windows XP
unter Verwendung der Open-Source-Integrierten Entwicklungsumgebung (IDE) Eclipse. Die
Software wurde in der objektorientierten Programmiersprache Java mit der Version 5.0 entwickelt. Des Weiteren kommt, wie bereits im Abschnitt 3.7 beschrieben, das Peer-to-PeerFramework JXTA in seiner aktuellen Version 2.0 zum Einsatz. Zudem wurde die deutsche
Version 0.47c des Internet-Tauschbörsen-Clients eMule verwendet.
4.2 Aufbau des Prototypen
Sowohl der Master als auch die Slaves erben zunächst einmal von der Basisklasse Peer (siehe
Abschnitt 4.2.1). Des Weiteren verwenden sowohl Master als auch Slaves die Schnittstelle
Database sowie deren Implementierung XMLData. Eine weitere Gemeinsamkeit von Master
und Slaves ist, dass beide Typen mehrere Dienste im JXTA-Netzwerk anbieten bzw. nutzen.
Der gesamte Programmfluss erfolgt im Allgemeinen ereignisgesteuert. Mögliche Ereignisse
sind unter anderem:
• Eintritt eines neuen Slaves
• Start einer neuen Analyse
• Resultate zur ausgeführten Analyse im Filesharing-Netzwerk gefunden
• Neuer Download-Auftrag
48
4 Implementierungsaspekte
• Analyse zu einer Datei abgeschlossen
• Austritt eines Slaves
• Abbruch einer Analyse
• Ausfall des Masters
4.2.1 Basisklasse Peer
In der Basisklasse Peer wird die grundlegende Konfiguration für den Eintritt in das JXTANetzwerk vorgenommen und im Anschluss erfolgt der Beitritt in die JXTA-Gruppe distri”
butedFilesharingAnalysisPeerGroup“. Abbildung 4.1 zeigt das Klassendiagramm der Überklasse Peer. Die Konfiguration von Master und Slave unterscheiden sich. Der Master legt
einerseits die JXTA-Gruppe an und zudem fungiert er als JXTA Rendezvous- und RelayPeer. Ein Slave tritt lediglich in eine existierende JXTA-Gruppe ein und wird als Edge-Peer
konfiguriert. Zur Beschreibung der verschiedenen Peer-Typen vergleiche Abschnitt 2.4.2.
Abbildung 4.1: Überklasse Peer
Der Konstruktor erzeugt eine neue Instanz. Der Paramter instanceName“ enthält dabei den
”
Namen der zu erzeugenden Instanz. Mit dem Paramter type“ wird entweder die Zeichenkette
”
master“ übergeben und die neue Instanz wird als Master konfiguriert oder es wird die
”
Adresse des aktuellen Masters übergeben.
4.2 Aufbau des Prototypen
49
Die weiteren verfügbaren Methoden werden hauptsächlich durch den Konstruktor zur Konfiguration verwendet. Einige andere werden zur Abfrage von erzeugten Werten genutzt, wie
z.B. der ID.
4.2.2 Datenverwaltung
Die Datenverwaltung erfolgt in der prototypischen Implementierung mit Hilfe der Extensible
Markup Language (XML) . Um allerdings eine spätere Datenverwaltung in beispielsweise einer Datenbank zu ermöglichen, wurde zunächst die Schnittstelle Database“ (siehe Abbildung
”
4.2) entworfen, die dann durch die Klasse XMLData implementiert wurde.
XML ist eine vom World Wide Web Consortium (W3C) definierte Auszeichungssprache und
erlaubt eine hierarchisch strukturierte Speicherung in Form eines maschinen- und menschenlesbaren Dokuments1 .
Abbildung 4.2: Schnittstelle zur Datenbank
Die einzelnen XML-Dateien des Masters werden in den Tabellen 4.1, 4.2, 4.3, 4.4, 4.5 und
4.6 dargestellt und beschrieben.
1
(Vgl. Consortium 16.08.2006)
50
peers.xml
Beschreibung
Element
peers
peer
Attribut
ID
Hostname
OS
Speed
Memory
Rate
Emule
Start
ed2kServer
Status
results.xml
Beschreibung
Element
results
result
Attribut
Name
Size
Hash
Sources
CompleteSources
SearchID
ServerID
PeerID
Status
4 Implementierungsaspekte
Datei dient zur Speicherung aller Slaves und zugehörigen Informationen
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere peer-Elemente, beinhaltet
Dient zur Erfassung eines einzelnen Slaves und der Informationen
Beschreibung
eindeutige ID zur Identifikation des Slaves sowohl im JXTA-Netzwerk als
auch innerhalb des Systems
Name des Rechners, auf dem der Slave ausgeführt wird
Betriebssystem des Rechners
Prozessor-Geschwindigkeit des Rechners in MHz
Arbeitsspeicher des Rechners in MB
Durchschnittliche Download-Rate der Internet-Verbindung des Rechners
in KByte/s
Informationen über den Emule-Client
Zeitstempel des Systemstatus
Aktueller eDonkey-Server des Slaves
Status des Slaves, (Mögliche Werte: online oder offline)
Tabelle 4.1: peers.xml
Datei dient zur Speicherung aller Suchergebnisse
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere result-Elemente, beinhaltet
Dient zur Erfassung eines Ergebnisses
Beschreibung
Name der gefundenen Datei
Größe der gefundenen Datei
File ID der gefundenen Datei
Anzahl der Dateien im Tauschbörsen-Netz
Anzahl der vollständigen Quellen der Datei im Tauschbörsen-Netz
ID der Suche, durch die die Datei gefunden wurde
ID des Servers, mit dem der Slave zum Zeitpunkt der Suche verbunden
war
ID des Slaves, der das Ergebnis lieferte
Status des Ergebnisses (Mögliche Werte: started, stopped, finished)
Tabelle 4.2: results.xml
4.2 Aufbau des Prototypen
searches.xml
Beschreibung
Element
searches
search
Attribut
ID
Keyword
Type
WmAlgo
WmKey
Status
server.xml
Beschreibung
Element
servers
server
Attribut
ID
Name
Description
Version
Users
Files
51
Datei dient zur Speicherung aller durchgeführten Suchen
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere search-Elemente, beinhaltet
Dient zur Erfassung einer Suche
Beschreibung
ID der Suche und Zeitstempel des Starts
Schlagwort zur Suche
gesuchter Dateityp (Mögliche Werte: Audio, Image, Video)
der zur Analyse der Datei zu verwendende Wasserzeichen-Algorithmus
der bei der Analyse der Datei zu verwendende Wasserzeichen-Schlüssel
Status der Suche (Mögliche Werte: started, stopped, finished)
Tabelle 4.3: searches.xml
Datei dient zur Speicherung aller Server, zu denen Slaves bisher verbunden waren
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere server-Elemente, beinhaltet
Dient zur Erfassung eines Servers
Beschreibung
ID des Servers (eMule nutzt zur Identifikation eines Servers die IPAdresse in Verbindung mit dem Port)
Name des Servers
Beschreibung des Servers im Tauschbörsen-Netz
Version der eingesetzten Server-Software
Anzahl der zu diesem Server vebundenen Nutzer
Anzahl der auf diesem Server indizierten Dateien
Tabelle 4.4: server.xml
52
files.xml
Beschreibung
Element
files
file
Attribut
Hash
peer
searchid
Status
4 Implementierungsaspekte
Datei dient zur Speicherung aller Daten zu einer Datei nach der Verteilung auf einen Slave
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere file-Elemente, beinhaltet
Dient zur Erfassung eines Datei
Beschreibung
File ID der gefundenen Datei
ID des Slaves, der die Analyse dieser Datei durchführt
ID der zugehörigen Suche
Status der Datei (Mögliche Werte: started, stopped, finished)
Tabelle 4.5: files.xml
wm results.xml
Beschreibung
Datei dient zur Speicherung der Ergebnisse aller Wasserzeichen-Analysen
Element
Beschreibung
wm results
Wurzelverzeichnis, das alle Einträge, d.h. mehrere wm result-Elemente,
beinhaltet
wm result
Dient zur Erfassung eines Ergebnisses
Attribut
Beschreibung
filehash
ID der Datei
searchID
zugehörige Suche mit den entsprechenden Analyse-Parametern
wm
gefundene Wasserzeichen-Informations oder Zeichenkette unknown“
”
oder ERROR“
”
timestamp
Zeitstempel des Eintrags, d.h. des Endes der Analyse
Tabelle 4.6: wm results.xml
4.2 Aufbau des Prototypen
algorithms.xml
Beschreibung
Element
algorithms
algorithm
Attribut
name
53
Datei dient zur Speicherung der Namen der verfügbaren WasserzeichenAlgorithmen
Beschreibung
Wurzelverzeichnis, das alle Einträge, d.h. mehrere algorithm-Elemente,
beinhaltet
Dient zur Erfassung eines Wasserzeichens
Beschreibung
Name des Wasserzeichens
Tabelle 4.7: algorithms.xml
peer downloads.xml
Beschreibung
Datei dient zur Speicherung aller Analyse-Aufträge einer Slaves
Element
Beschreibung
downloads
Wurzelverzeichnis, das alle Einträge, d.h. mehrere download-Elemente,
beinhaltet
download
Dient zur Erfassung eines Auftrags
Attribut
Beschreibung
hash
ID der zu bearbeitenden Datei
SearchID
ID der Suche, durch die die Datei gefunden wurde
WmKey
Wasserzeichen-Schlüssel, der bei der anschließenden Analyse genutzt werden soll
WmAlgo
Wasserzeichen-Algorithmus, der bei der anschließenden Analyse genutzt
werden soll
Status
Status des Auftrags (Mögliche Werte: started, stopped, finished)
Timestamp
Zeitpunkt des Eintrags und somit der Auftragserteilung
Tabelle 4.8: peer downloads.xml
Des Weiteren verwendet der Master eine XML-Datei zur Speicherung der Namen aller verfügbaren Wasserzeichen-Algorithmen (vgl. Tabelle 4.7). Diese Datei wird nicht über die Schnittstelle Database angesprochen.
Der Slave nutzt auch mehrere XML-Dateien zur Speicherung von Daten. Allerdings wird die
Datei peer results.xml nur zur temporären Speicherung eines Suchresultats genutzt und ist
daher hier irrelevant. Die Datei peer downloads.xml wird in Tabelle 4.8 beschrieben.
Der Slave verwendet darüber hinaus die XML-Datei settings.xml zur Speicherung aller Einstellungen (vgl. Tabelle 4.9). Diese Datei wird nicht über die Schnittstelle Database sondern
mit der Klasse settings angesprochen.
54
settings.xml
Beschreibung
Element
Settings
eMule
DistributedAnalysis
Attribut
Address
Password
Folder
MasterAddress
AlgorithmRoot
4 Implementierungsaspekte
Datei dient zur Speicherung aller Einstellungen einer Slaves
Beschreibung
Wurzelverzeichnis, das alle Einträge beinhaltet
Dient zur Erfassung aller Einstellungen bezüglich des eMule-Clients
Dient zur Erfassung aller Einstellung bezüglich des Slaves
Beschreibung
Adresse des eMule Webinterfaces (default: http://127.0.0.1:4711)
Passwort des eMule Webinterfaces
Sowohl für das Element eMule als auch das Element DistributedAnalysis
verfügbar. Beim Element eMule dient dieses Attribut zur Speicherung des
Pfades des Ordners, in dem die Dateien nach dem Download abgespeichert werden. Beim Element DistributedAnalysis wird in diesem Attribut
der Pfad des Ordners beschrieben, in den die Datei nach dem Download
aus dem eMule-Verzeichnis verschoben und gespeichert werden soll.
Adresse des Masters (inklusive Protokoll und Port) (Beispiel:
tcp://192.168.2.42:9700)
Pfad des Verzeichnisses, in dem die Algorithmen für den AlgorithmManager gespeichert sind.
Tabelle 4.9: settings.xml
4.2.3 Aufbau des Masters
In diesem Abschnitt wird der Aufbau des Masters behandelt. Der genaue Aufbau des Masters
ist auf Abbildung A.1 im Anhang auf Seite 71 abgebildet. Wie das Klassendiagramm zeigt,
besteht der Master zunächst einmal aus einer großen Anzahl von Klassen. Diese können
unterteilt werden in die Klassen der GUI , Klassen, die Dienste im JXTA-Netzwerk anbieten,
Klassen, die in eigenständigen Threads ausgeführt werden und in Klassen, die Dienste im
JXTA-Netzwerk suchen und nutzen.
Zu den Klassen, die in eigenständigen Threads ausgeführt werden, zählen die Klassen PeerMonitor (siehe Abschnitt 4.2.3.1) und Dispatcher (siehe Abschnitt 4.2.3.2 S.55).
Die Klassen RegisterNewClientService, SearchResultInputService, AnalysisResultInputService
und StoppedUnstartedDownloadsInputService sind Klassen, die Dienste im JXTA-Netzwerk
anbieten und die Klassen SendSearchCommand, SendDownloadCommand und
SendStopUnstartedDownloadsCommand sind Klassen, die Dienste im JXTA-Netzwerk suchen und nutzen (siehe Abschnitt 4.2.3.3 S.56).
Die GUI besteht aus drei Klassen (siehe Abschnitt 4.2.3.4 S.57). Dazu zählen die Klassen
4.2 Aufbau des Prototypen
55
GUI, PeerTable und SearchTable.
4.2.3.1 Monitoring
Durch das Monitoring erfolgt eine Überwachung der registrierten Slaves. Dazu wurde die
Klasse Peer Monitor entwickelt (vgl. Abbildung 4.3). Diese Klasse erbt von der Klasse Thread
und überschreibt die Methode run. Alle 30 Sekunden wird eine Nachricht an jeden der
Slaves gesendet. Dies geschieht mittels des JXTA-Dienstes PeerInfoServices. Dieser sendet
eine Nachricht an den angegebenen Peer. Der angesprochene Peer quittiert den Empfang
der Nachricht mit einer Nachricht. Sollte der angesprochene Peer nach der Zeitspanne von
25 Sekunden noch nicht reagiert haben, so wird das Ereignis peerMonitorInfoNotReceived“
”
ausgelöst. Sollte ein Peer dreimal nicht auf eine Anfrage des Masters reagieren, so wird er
aus der Liste der registrierten Slaves entfernt und die auf ihm ausgeführten Aufträge werden
durch den Dispatcher neu verteilt.
Abbildung 4.3: Peer Monitor
Ein Slave wird nicht direkt nach der ersten ausbleibenden Reaktion auf die Master-Anfrage
als ausgeschieden behandelt, sondern erst nach der dritten ausbleibenden Reaktion hintereinander. Dies wurde gewählt, um einen Slave nicht vorzeitig zu entfernen, wenn eine Nachricht
nicht angekommen ist oder wenn ein stark belasteter Slave nicht rechtzeitig reagieren sollte.
4.2.3.2 Dispatcher
Die Verteilung der Download- und Analyse-Aufträge erfolgt durch die Klasse Dispatcher
(vgl. Abbildung 4.4). Diese Klasse erbt ebenfalls von der Klasse Thread und überschreibt
die Methode run. Der Dispatcher überprüft alle 30 Sekunden, ob Suchergebnisse zu einer
neuen Suche eingegangen sind und ob alle registrierten Clients auf diese Suche geantwortet
haben, also Suchresultate zurückgesendet haben. Wenn eine neue Suche in Arbeit ist und
wenn alle Slaves Suchresultate zu dieser Suche gesendet haben, so startet der Dispatcher
56
4 Implementierungsaspekte
mit der Verteilung aller durch die Suche gefundenen Dateien. Dazu wird die Methode startNewSearchResultDispatchingProcess mit der entsprechenden ID der Suche verwendet. Diese
Methode wird zudem aufgerufen, wenn eine neue Suche gestartet wurde und zu dieser zwar
nicht alle Slaves Resultate gesendet haben, aber eine Zeit von 200 Sekunden seit dem Start
der Suche vergangen ist. Dadurch wird verhindert, dass eine Suche nicht ausgeführt wird,
wenn ein Slave keine Resultate zurücksendet.
Abbildung 4.4: Dispatcher
Weiter wird die Methode startNewDispatchingProcessForHashSet im Falle des Ausscheidens
eines Slaves mit der Menge der auf diesem Slave ausgeführten Aufträge ausgeführt.
4.2.3.3 Dienste des Masters
Die Klassen RegisterNewClientService, SearchResultInputService, AnalysisResultInputService
und StoppedUnstartedDownloadsInputService sind Klassen, die Dienste im JXTA-Netzwerk
anbieten.
Die Klasse RegisterNewClientService veröffentlich den gleichnamigen Dienst im JXTA-Netzwerk. Über diesen Dienst können sich die Slaves beim Master registrieren und die zur Lastverteilung nötigen Informationen an den Master übermitteln.
Mittels der Klasse SearchResultInputService wird der Dienst SearchResultInputService veröffentlicht. An diesen Dienst können die Slaves nach einer Suche die Suchresultate übermitteln.
Entsprechend dient die Klasse AnalysisResultInputService zur Veröffentlichung eines Dienstes, um Resultate der Analyse von einem Slave zu verarbeiten.
4.2 Aufbau des Prototypen
57
Die Klasse StoppedUnstartedDownloadsInputService veröffentlicht den gleichnamigen Dienst
im JXTA-Netzwerk. An diesen Dienst melden die Slaves alle ungestarteten Aufträge bei einer
Neuverteilung, z.B. dem Eintritt eines neuen Slaves ins Netzwerk während einer laufenden
Analyse.
Die Klassen SendSearchCommand, SendDownloadCommand und SendStopUnstartedDownloadsCommand sind Klassen, die Dienste im JXTA-Netzwerk suchen und nutzen.
Die Klasse SendSearchCommand sucht den Dienst NewSearchInput, der von allen Slaves
angeboten wird, und sendet an jeden dieser Dienste die Suchparameter einer neuen Suche.
Die Klasse SendDownloadCommand dient der Suche nach dem DownloadService eines Slaves,
um diesem einen neuen Download-Auftrag zu übermitteln.
Zuletzt sucht die Klasse SendStopUnstartedDownloadsCommand den von jedem Slave angebotenen Dienst StopUnstartedDownloadsService, um z.B. bei einem Eintritt eines neues
Slaves ins Netzwerk während einer laufenden Analyse alle ungestarteten Aufträge zu beenden und neu zu verteilen.
4.2.3.4 Benutzerschnittstelle
Mittels der Benutzerschnittstelle (siehe Abbildung 4.5) werden die Such- und Analyseparameter eingegeben. Des Weiteren werden alle registrierten Slaves in einer Tabelle angezeigt
(siehe Abbildung 4.6) und es erfolgt eine Überwachung der laufenden Analyse (siehe Abbildung 4.7).
4.2.4 Aufbau eines Slaves
In diesem Abschnitt wird der Aufbau eines Slaves behandelt. Der genaue Aufbau eines Slaves ist auf Abbildung A.2 im Anhang auf Seite 72 abgebildet. Wie das Klassendiagramm
zeigt, besteht ein Slave zunächst einmal aus einer großen Anzahl von Klassen. Diese können
unterteilt werden in die Klasse der GUI
, Klassen, die Dienste im JXTA-Netzwerk anbieten, Klassen, die zur Anbindung an die
Internet-Tauschbörse genutzt werden, und Klassen, die Dienste im JXTA-Netzwerk suchen
und nutzen, und zuletzt noch die in einem eigenem Thread laufende Klasse AlgorithmWorker.
Mehr zu dieser Klasse folgt in Abschnitt 4.2.4.3.
58
4 Implementierungsaspekte
Abbildung 4.5: Benutzerschnittstelle
Abbildung 4.6: Benutzerschnittstelle Slave - Übersicht
Die Klassen NewSearchInput, DownloadService und StopUnstartedDownloadsService bieten
Dienste im JXTA-Netzwerk an und die Klassen RegisterNewClient, SendSearchResult, SendAnalysisResult und SendStoppedDownloads suchen und nutzen die Dienste im JXTA-Netzwerk (siehe Abschnitt 4.2.4.4). Die Klasse RegisterNewClient verwendet zudem zwei weitere
Klassen NetworkBandwidth und WindowsSystemInformation zur Bestimmung der Systeminformationen. Mehr zu diesen Klassen folgt im Abschnitt 4.2.4.2.
Die GUI besteht hier nur aus einer Klasse. Weiterhin verfügt die Klasse settings über eine
eigene GUI. Diese Klasse dient zur Verwaltung und zum Lesen und Schreiben der Einstellungen.
Die Internet-Tauschbörse wird über die in Abschnitt 3.6 entworfene Schnittstelle Filesharing
4.2 Aufbau des Prototypen
59
Abbildung 4.7: Benutzerschnittstelle Analyse
angesprochen. Diese wird durch die Klasse Emule implementiert. Zudem existieren dazu die
beiden Klassen FilesharingError und FilesharingMonitor. Mehr zu diesen Klassen folgt im
Abschnitt 4.2.4.1.
4.2.4.1 Anbindung an eMule
Die Klasse Emule ist eine Implementierung der Schnittstelle Filesharing. Mit dieser wird
der transparente Zugriff auf eine Tauschbörse gewährleistet. Die Nutzung der Datei-IDs aus
dem eMule-System als interne Datei-IDs spielt dabei keine Rolle. Die Nutzung dieser IDs ist
lediglich der einfachste Weg, auch intern eine eindeutige Identifizierbarkeit zu gewährleisten.
Wenn eine weitere Tauschbörse neben eMule angebunden werden soll, müsste zudem eine
Übersetzung“ zwischen den Datei-IDs der verschiedenen Systeme erfolgen, um eine doppelte
”
Behandlung der Dateien zu vermeiden.
Da, wie bereits erwähnt, in diesem Prototyp der Internet-Tauschbörsenclient eMule zum
Einsatz kommt, erfolgt durch die Klasse Emule die Anpassung des Webinterfaces des eMuleClients an die in Abschnitt 3.6 definierte Schnittstelle zu den Internet-Tauschbörsen. Diese
Anpassung erfolgt mittels des in Gamma und Riehle (2000) definierten Entwurfsmusters des
sogenannten Adapters bzw. Wrappers2 .
Eine Adapter- oder Wrapperklasse übersetzt eine Schnittstelle in eine andere Schnittstelle
und ermöglicht somit eine Kommunikation über diese. Da es sich in diesem Fall um ein Webinterface handelt, besteht die Übersetzung aus einer Umwandlung der Befehle der FilesharingSchnittstelle in einen entsprechenden Uniform Resource Locator (URL)
”
“ des Webinterfaces und in der anschließenden Konvertierung der durch die URL bezogenen
Daten im Hypertext Markup Language (HTML)
-Format in entsprechende Java-Variablen. Dies erfolgt mittels eines HTML-Parsers. Hierbei
2
(Vgl. Gamma und Riehle 2000, S.151 ff)
60
4 Implementierungsaspekte
ist wichtig, dass beim verwendeten eMule-Client die Sprache auf Deutsch“ gestellt ist, da
”
ansonsten Fehler beim Parsen auftreten.
4.2.4.2 Systeminformationen
Die Systeminformationen werden zur Lastverteilung benötigt (vgl. Abschnitt 3.5). Dazu
sind die Parameter Prozessorgeschwindigkeit, Arbeitsspeichergröße und die durchschnittliche
Downloadrate notwendig.
Die Klasse WindowsSystemInformation dient der Ermittlung verschiedener Systemparameter
unter dem Betriebssystem Microsoft Windows XP. Dazu wird das in dieser Windows-Version
standardmäßig verfügbare Programm systeminfo.exe genutzt. Die Ausgabe des Programms
wird durch die Klasse interpretiert und in ein Zeichenketten-Feld umgewandelt. Dabei werden
folgende Werte gewonnen:
• Name des Rechners (Hostname)
• Name des Betriebssystems
• Geschwindigkeit des Prozessors in MHz
• Größe des Arbeitsspeichers in MB
Die notwendige durchschnittliche Downloadrate wird durch die Klasse NetworkBandwidth
ermittelt. Um die Geschwindigkeit der Download-Internet-Verbindung zu messen, werden
drei verschiedene Dateien von verschiedenen Adressen aus dem Internet geladen. Dabei wird
die Zeitdauer für diese Aktion gemessen. Durch die Berücksichtigung der Größe der Dateien
kann im Anschluss die Geschwindigkeit in KByte pro Sekunde berechnet werden. Die Werte
dieser Messungen können allerdings stark differieren. Schließlich kann nicht berücksichtigt
werden, ob die Internet-Verbindung eventuell von mehreren Rechnern genutzt wird oder ob
andere Programme die Verbindung schon nutzen. Dies ist allerdings auch nicht erforderlich,
da durch die Messung lediglich die noch verfügbare Downloadrate festgestellt werden soll.
4.2.4.3 AlgorithmWorker
Die Anbindung an den zur Wasserzeichen-Analyse genutzten AlgorithmManager erfolgt über
die Klasse AlgorithmWorker. Diese Klasse basiert auf einer Warteschlange, in die jeder einzelne Analyse-Auftrag eingereiht wird. Jeder Auftrag wird nacheinander ausgeführt. Dazu
wird eine den Analyse-Parametern entsprechende Instanz des AlgorithmManagers geladen.
4.2 Aufbau des Prototypen
61
Mit dieser wird dann ein neuer Detektor geladen, der dann unter Verwendung des angegebenen Wasserzeichen-Algorithmus und Schlüssels die angegebene Datei untersucht. Nach
der Analyse wird entweder die gefundenene Wasserzeichen-Information oder die Zeichenkette unknown“ an den Slave übergeben, der diese dann an den Master sendet. Zudem ist es
”
möglich, die Wasserzeichen-Analyse durch den AlgorithmManager zu übergehen, um diese
durch ein externes Programm durchführen zu lassen.
4.2.4.4 Dienste des Slaves
Die Klassen NewSearchInput, DownloadService und StopUnstartedDownloadsService sind
Klassen, die Dienste im JXTA-Netzwerk anbieten.
Die Klasse NewSearchInput bietet den Dienst SearchService im JXTA-Netzwerk an. Dieser
wird vom Master zur Übermittlung einer neuen Suche an die Slaves genutzt.
Mit der Klasse DownloadService wird der gleichnamige Dienst im Netzwerk angeboten. Über
diesen werden Kommandos zum Download von Dateien entgegengenommen.
Zuletzt bietet die Klasse StopUnstartedDownloadService den Dienst zum Anhalten aller bisher noch nicht angefangenen Aufträge an. Dieser wird, wie bereits erwähnt, z.B. bei dem
Eintritt eines neuen Slaves in das Netzwerk bei einer bereits laufenden Analyse benötigt.
Die Klassen RegisterNewClient, SendSearchResult, SendAnalysisResult und SendStoppedDownloads sind Klassen, die Dienste im JXTA-Netzwerk suchen und nutzen.
Die Klasse RegisterNewClient sucht den vom Master angebotenen Dienst RegisterNewClientService und sendet ihm zur Anmeldung die Systeminformationen (siehe Abschnitt 4.2.4.2).
Die Klassen SendSearchResult und SendAnalysisResult suchen die entsprechenden Dienste
des Masters, um Such- bzw. Analyseresultate an diesen zu übermitteln.
Zuletzt wird die Klasse RegisterNewCleintService zur Übermittlung aller gestoppten Aufträge verwendet, nachdem vom Master der StopUnstartedDownloadService aufgerufen wurde.
62
5 Evaluation und Leistungsbeurteilung
In diesem Kapitel erfolgt eine abschließende Evaluation und Leistungsbeurteilung des entwickelten Systems. Durch die Evaluation der prototypischen Implementierung wird überprüft, ob
diese Lösung den geforderten Funktionsumfang bereitstellt und ob alle Anforderungen erfüllt
werden. Der Prototyp wird zu diesem Zweck in verschiedenen Testfällen getestet und hinsichtlich seiner Konformität bezüglich der Anforderungen bewertet. Zudem erfolgt abschließend
in einem weiteren Schritt ein Leistungsvergleich. Dabei wird das System in verschiedenen
Fällen in Bezug auf Ergiebigkeit und Schnelligkeit bewertet.
5.1 Testumgebung
Die Evalutation der prototypischen Implementierung erfolgt in mehreren Phasen. Dazu werden verschiedene Testumgebungen genutzt.
Bereits während der Implementierung erfolgte eine regelmäßige Überprüfung des geforderten Funktionsumfangs und der Anforderungen. Dies geschah auf einem minimalen, verteilten
System, bestehend aus zwei Rechnern, und einem Router mit Switch-Funktion (vgl. Abbildung 5.1). Beide Rechner waren mit jeweils einem eMule-Client ausgestattet und über eine
DSL-Leitung mit dem Internet verbunden. Einer der Rechner fungierte während der Tests als
Master und beherbergte zudem noch einen Slave. Der zweite Rechner führte noch einen weiteren Slave aus. Während dieser Tests wurden mehrfach alle in Abschnitt 3.4 beschriebenen
Ausnahmefälle getestet. Mehr zu den Funktionstests folgt in Abschnitt 5.2.
In der zweiten Phase der Evalutation wurde ein Laborversuch durchgeführt. Dazu erfolgte
ein Test unter simulierten Bedingungen im lokalen Netz. Dabei wurde ein lokales System
bestehend aus fünf Rechnern aufgebaut (vgl. Abbildung 5.1). Auf einem dieser Rechner
wurde ein eigener eMule Server installiert. Dazu wurde die Software von Lugdunum gewählt1 .
Diese Software ist im Internet frei verfügbar und zur Zeit die am häufigsten verwendete
Server-Software für das eDonkey- bzw. eMule-Netz. Während des Testens simulierten zwei
1
Vgl. http://lugdunum2k.free.fr/kiten.html
5.1 Testumgebung
63
Abbildung 5.1: Testumgebung 1
Rechner gewöhnliche Tauschbörsenteilnehmer und die verbleibenden zwei Rechner bildeten
– wie schon in der ersten Phase – zusammen das Analyse-System. Dabei übernahm wieder
einer der Rechner die Funktion sowohl als Master als auch als Slave und der zweite Rechner
wieder nur als Slave. Mehr dazu folgt im Abschnitt 5.3.
Abbildung 5.2: Testumgebung 2
In der dritten und letzten Phase wurde ein Praxistest durchgeführt. Dazu wurden drei mit
dem Internet über eine gemeinsame DSL-2000-Leitung verbundene und untereinander vernetzte Rechner genutzt (vgl. Abbildung 5.1). Um während des Tests im System nicht aufzufallen und somit die Anforderung nach einem unerkannten Verbleiben im Tauschbörsennetz
zu gewährleisten, bot jeder der drei Rechner freie Software zum Download an. Mehr zum
Praxistest folgt im Abschnitt 5.4.
64
5 Evaluation und Leistungsbeurteilung
Abbildung 5.3: Testumgebung 3
5.2 Funktionstests
Funktionstests werden anhand von Anwendungsfällen (engl. use cases) durchgeführt. Das zu
prüfende Computerprogramm hat dabei alle gestellten Aufgaben gemäß seiner Spezifikation
zu lösen. Beim entwickelten System galt es, sowohl die entworfenen Ausnahmefälle (vgl.
Abschnitt 3.4) als auch die vollständige Funktion der Download- und Analyse-Komponenten
zu überprüfen.
Zunächst einmal wurden sämtliche Ausnahmefälle mehrfach wiederholt simuliert. Dazu wurden Slave- und Master-Ausfälle durch gezieltes Ausschalten provoziert und die Reaktionen
des Systems überwacht.
Zudem erfolgten regelmäßige Tests mit verschiedenen Suchparametern, um die Verteilung
und die Suchfunktionen zu überprüfen.
Da das System nicht über eine Redundanz des Masters verfügt, wurden hauptsächlich Ausfälle eines oder mehrere Slaves in verschiedenen Phasen simuliert. Unter anderem wurden
dabei folgende Situationen getestet:
• Ausfall eines Slaves vor Start einer Analyse → Reduktion der verfügbaren Slaves
• Ausfall eines Slaves unmittelbar nach dem Start der Analyse, während alle Slaves die
Tauschbörse durchsuchen, um die Ergebnisse anschließend zurückzusenden → Master
verteilte alle Ergebnisse nach Erreichen des Timeouts von 200 Sekunden.
5.3 Laborversuch
65
• Ausfall eines Slaves nach der Verteilung der Aufträge → Master registrierte Ausfall →
Neuverteilung aller dem ausgefallenen Slave zugeteilten Aufträge
• Eintritt eines Slaves unmittelbar nach dem Start der Analyse, während alle Slaves die
Tauschbörse durchsuchen, um die Ergebnisse anschließend zurückzusenden → Master
verteilte alle Ergebnisse nach Erreichen des Timeouts von 200 Sekunden.
• Eintritt eines Slaves nach der Verteilung der Aufträge → Master registrierte Eintritt →
Anhalten aller ungestarteten Download-Aufträge und Neuverteilung dieser unter allen
Slaves
5.3 Laborversuch
Im Laborversuch erfolgte ein Vergleich zwischem einem normalen Tauschbörsen-Client und
dem implementierten, aus 2 Slaves bestehenden System in einer simulierten Umgebung (vgl.
Abbildung 5.2). Dazu wurde ein Netzwerk bestehend aus einem eDonkey- bzw. eMule-Server,
zwei normalen eMule-Clients und zwei Rechnern mit dem Prototypen aufgebaut. Durch den
Aufbau wurden lange Wartezeiten auf Dateien oder vorzeitiges Ausscheiden eines DateiAnbieters und somit Ausscheiden einer eventuell einzigen Quelle verhindert. Zudem ist dadurch das System unabhängig von der Anzahl der Nutzer im Tauschbörsen-Netzwerk, der
Tageszeit und dem Uhrzeit abhängigen Internet-Verkehr.
Die beiden normalen eMule-Clients dienten als Daten-Anbieter. Diese boten insgesamt 108
MP3-Dateien zum Download an.
Durch die Verwendung des implementierten Systems mit nur einem Slave konnte das Verhalten eines einzigen normalen Tauschbörsen-Clients simuliert werden. Bei zwei Testläufen
wurde die Zeit gemessen, die ein derartiges System benötigt, um alle 108 Dateien herunterzuladen. Diese Zeiten wurden mit den durch das aus zwei Slaves bestehenden Referenz-Systems
benötigten Zeiten verglichen (vgl. Abbildung 5.4).
Wie zu erwarten, benötigt ein Client nahezu doppelt so lange zum Download aller Dateien
wie das aus zwei Slaves bestehende System.
Die erreichten Zeiten können durch eine moderne Hardware verbessert werden. Als größte
Schwachstelle erwies sich der eMule-Server, der auf einem 150 MHz Pentium I Rechner
ausgeführt wurde.
66
5 Evaluation und Leistungsbeurteilung
Abbildung 5.4: Ergebnisse Laborversuch
5.4 Praxistest
Im Praxistest wurde das entwickelte System im realen eDonkey- bzw. eMule-Netzwerk evaluiert. Um Vergleichswerte zu erlangen, wurden dazu verschiedene Tests durchgeführt. Wie
beim Laborversuch wurde zunächst das System bestehend aus nur einem Slave und einem
Master als Simulation eines normalen Filesharing-Clients ausgeführt. Im Anschluss wurde
das System bestehend aus zwei Slaves und einem Master getestet und zum Schluß das System
bestehend aus drei Slaves und einem Master.
Während des Praxistests wurde im Gegensatz zum Laborversuch nicht die Zeitdauer für
das Downloaden einer bestimmten Menge von Dateien gemessen, sondern die Anzahl und
die Größe der heruntergeladenen Dateien zu einem Suchwort in einem gegebenen Zeitraum.
Die Tests wurden für eine Zeitdauer von zwei Stunden ausgeführt und jeweils zweimal für
zwei verschiedene Suchbegriffe ausgeführt. Der erste Test erfolgte für das Suchwort Tomte“.
”
Dadurch wurde das System für eine sehr begrenzt verfügbare Menge von Dateien getestet. Im
zweiten Test wurde nach dem Suchwort Metallica“ gesucht. Dabei wurde immer die Grenze
”
von 300 Suchresultaten pro Client erreicht.
Abbilung 5.5 zeigt die Durchschnittswerte der verschiedenen Tests. Auffällig dabei ist, dass
die Unterschiede beim Suchwort Tomte“ minimal sind. Dahingegen verbessern sich die Er”
5.4 Praxistest
67
Abbildung 5.5: Feldversuch
gebnisse beim Suchwort Metallica“ mit der Anzahl der Slaves. Durch eine schnellere Internet”
Verbindung wären die Verbesserungen noch deutlicher.
Die Unterschiede zwischen den Ergebnissen für das Suchwort Tomte“ und Metallica“ sind
”
”
hauptsächlich durch die stark differierende Anzahl von den im Tauschbörsen-Netzwerk verfügbaren Dateien zum Suchwort zu erklären.
Während der verschiedenen Testverfahren wurde das optionale Analyseverfahren
unterschiedlich behandelt. Während der Funktionstests wurden verschiedene WasserzeichenAlgorithmen getestet. Allerdings musste während der Labor- und Feldversuche darauf verzichtet werden, da kein Wasserzeichen-Algorithmus für das MP3-Format verfügbar war, der
zum AlgorithmManager kompatibel war.
68
6 Zusammenfassung und Ausblicke
Zum Abschluss der Arbeit soll in diesem Kapitel eine Zusammenfassung des Erarbeiteten
dargestellt werden und ein Ausblick auf potentielle zukünftige Projekte im Anschluss an diese
Arbeit beschrieben werden.
6.1 Zusammenfassung
Diese Arbeit hat sich das effiziente Auffinden und Analysieren von urheberrechtlich geschütztem Material, das ohne Einwillung des Urhebers in Internet-Tauschbörsen veröffentlicht wurde, zum Ziel gesetzt. Der Schwerpunkt der Arbeit lag hierbei bei der verteilten Suche und
Verfügbarmachung der Dateien aus Tauschbörsen.
Internet-Tauschbörsen sind Plattformen zum Austausch von Dateien über das Internet.
Durch sie haben Nutzer Zugriff auf eine große Menge von urheberrechtlich geschütztem
Material, wie Filme, Musik, Bücher und Software. Die Veröffentlichung von urheberrechtlich
geschütztem Material verstößt ohne die Zustimmung des Urhebers gegen das Urheberrecht.
Da das Material in der Regel aus Gründen der Wertschöpfung, sprich zum Verdienst, geschützt ist, sehen die betroffenen Urheber und die betroffene Industrie den Tausch im Internet als wachsende Bedrohung an. Viele Methoden zum Schutz vor unerlaubten Kopien sind
mit starken Restriktionen verbunden, durch die die Nutzbarkeit des Mediums beeinträchtigt
wird.
Das Fraunhofer Institut für Integrierte Publikations- und Informationssysteme (IPSI) hat
mit digitalen Wasserzeichen eine neue Technologie mitentwickelt, die eine nicht-restriktive
Methode darstellt. Mit digitalen Wasserzeichen kann eine beliebige Information robust in eine
Datei eingebracht werden. Dies kann z.B. beim Kauf im Internet eine Kundennummer sein.
Somit ist eine Rückverfolgung bei einer etwaigen Urheberrechtsverletzung gewährleistet. Zudem kann in diesem Zusammenhang von einem psychologischen Kopierschutz“ gesprochen
”
werden. Damit wird dann dem laut mehreren Studien vorherrschenden Gefühl der Anonymität im Internet entgegengewirkt.
6.2 Ausblicke
69
Allerdings sind digitale Wasserzeichen lediglich passiv, so dass eine aktive Kontrolle ausgeführt werden muss, um eine eventuell eingebettete Information zu erhalten oder um Urheberrechtsverletzungen zu registrieren. Vor einer Analyse ist es nötig, die Datei lokal verfügbar
zu machen. Um eine effiziente und auf die ständig wachsende Anzahl an Dateien in InternetTauschbörsen angepasste Lösung zu erhalten, wurde mit dieser Arbeit ein grundlegender
Entwurf zum verteilten Download und zur verteilten Analyse geschaffen.
Wichtigste Anforderung an das System waren neben einer guten Skalierbarkeit eine gute
Ausnutzung der zur Verfügung stehenden Ressourcen und eine gute Erweiterbarkeit um
weitere Internet-Tauschbörsen zusätzlich zu dem im Prototypen verwendete eMule. Um Kollisionen zu vermeiden und um eine Lastverteilung zu erreichen, wurde das System nach
dem Master-Slave-Prinzip entworfen. Diese hierarchische Struktur sieht vor, dass eine oder
mehrere Instanzen eine steuernde Rolle übernehmen, während untergeordnete Instanzen, die
sogenannten Slaves, lediglich Befehlsempfänger darstellen.
Durch die Lastverteilung konnte die gewünschte Anforderung der optimalen Ausnutzung
der Ressourcen erfüllt werden. Einfluss auf die Anzahl der einem Slave zugeteilten Aufträge
haben dabei, neben der Größe des Arbeitsspeichers und der Prozessorgeschwindigkeit als
Systemfaktoren, der Faktor Downloadgeschwindigkeit und die Anzahl der bisher dem Slave
zugeteilten Aufträge.
Als Kommunikationsplattform für die prototypische Implementierung wurde JXTA verwendet. Dieses Peer-to-Peer-Framework bietet neben einer guten Skalierbarkeit auch die Möglichkeit, das System in einer zukünftigen Arbeit problemlos auf ein vollwertiges Peer-to-PeerSystem umzustellen. Durch geeignete Ausnahmebehandlungsmethoden ist zwar ein Ausfall
eines Slaves problemlos, allerdings stellt der Master einen Single- Point-of-Failure dar. Somit
ist bei Ausfall des Masters in der Regel ein vollständiger Neustart des Systems notwendig.
Da aber diese Arbeit zunächst einmal den Entwurf eines grundlegenden Systems zur Aufgabe
hatte, war die Anforderung der Ausfallsicherheit des Masters nicht gestellt.
6.2 Ausblicke
Das entwickelte System bietet Raum für vielfältige Weiterentwicklungen. Wie bereits oben
erwähnt, wäre eine Umsetzung eines vollständigen Peer-to-Peer-Systems denkbar. Eine weitere Möglichkeit wäre eine Weiterentwicklung der Analyse-Komponente. Das in dieser Arbeit
verwendete Modul stellt nur das Grundgerüst für eine Analyse dar und es wird auf eine
Überprüfung der Analyse-Parameter und der Wasserzeichen-Parameter, wie z.B. Dateityp,
70
6 Zusammenfassung und Ausblicke
verzichtet. Zudem ist der verwendete AlgorithmManager auch noch im Entwicklungsstadium
und dementsprechend anfällig.
Weitere Entwicklungsmöglichkeiten wären die Erweiterung des Systems um weitere Tauschbörsen-Typen und somit um weitere Implementierungen der Schnittstelle Filesharing. Zudem
wäre eine dynamischere Lastverteilung denkbar. Zur Zeit überprüft der Monitor lediglich die
Verfügbarkeit eines Slaves. Denkbar wäre hier eine Abfrage der Systemauslastung und eine
eventuelle Neuverteilung als Reaktion auf diese Auslastung.
Eine weitere Entwicklungsmöglichkeit wäre ein inkrementelles Analyse-Verfahren. Dabei
könnte die Suche in einem wählbaren Zeitabstand wiederholt aufgerufen und alle noch nicht
analysierten Dateien untersucht werden.
Die zukünftige Entwicklung von Maßnahmen zur Pirateriebekämpfung in Internet-Tauschbörsen wird sich vermutlich weiterhin sehr stark an den Möglichkeiten der modernen Informationstechnologie orientieren. Wie diese Arbeit zeigt, liegt in diesem Bereich viel Potenzial
für zukünftge Forschungsarbeiten verborgen.
71
A Klassendiagramme
Abbildung A.1: Klassendiagramm Master
72
A Klassendiagramme
Abbildung A.2: Klassendiagramm Slave
73
B Die optimale Konfiguration von eMule
In diesem Abschnitt wird die für das entwickelte System optimale Konfiguration des InternetTauschbörsen-Clients eMule beschrieben.
Zunächst muss der eMule-Client installiert werden. Dabei sollte die empfohlene Version 47c
in deutscher Sprache installiert werden. Diese Version ist auf der mitgelieferten CD-ROM
verfügbar. Dabei kann zwischen einer .exe-Datei, die ein Installationsprogramm beinhaltet,
oder einer .zip-Datei, die nur die nötigen Dateien enthält, gewählt werden.
Nach der Installation wird beim ersten Start der Erst-Start-Assistent ausgeführt. Im Menüpunkt Allgemein können die Standard-Einstellungen beibehalten werden. Im nächsten Menüpunkt Ports und Verbindung erfolgt die Konfiguration der beiden für den optimalen Betrieb
nötigen freigeschalteten Ports. Diese müssen in einer eventuell vorhandenen Firewall umbedingt freigegeben werden. Durch Ausführen von Ports testen“ können die gewählten Ein”
stellungen überprüft werden.
Die weiteren Standard-Einstellungen können beibehalten werden. Nach Abschluss des ErstStart-Assistenten wird der Assistent zur Verbindungseinstellung geöffnet. Dabei sollten folgenden Einstellungen gewählt werden:
• Betriebssystem: Win2k/XP
• Gleichzeitige Downloads: 16+
• Internetanbindung: Wahl der vorhandenen Internetanbindung. Sollte darüber keine
Information vorhanden sein, kann diese Einstellung auch nach Ausführen des Slaves
neu eingegeben werden. Die Durchschnittsrate der Anbindung ist dabei in der Peer
”
Table“ des Masters ablesbar.
Im Anschluss an die Assistenten müssen weitere Einstellungen vorgenommen werden. Diese
können unter dem Menüpunkt Optionen“ vorgenommen werden. Dabei sollten folgende
”
Einstellungen vorgenommen werden:
74
B Die optimale Konfiguration von eMule
• Unter dem Menüpunkt Server sollte der Punkt Serverliste beim Programmstart ak”
tualisieren“ aktiviert werden. Dazu muss zudem die URL http : //www.server −
met.de/dl.php?load = gz&trace = 32442850.5278 in der Liste eingetragen werden.
Um zu verhindern, dass schlechte Server auf die Liste in eMule gelangen, müssen folgende Einstellungen vorgenommen werden:
– Server-Adressen vom verbundenen Server beziehen
– Server-Adressen von verbundenen Clients beziehen
• Weiterhin muss das Webinterface unter dem Menüpunkt Webinterface aktiviert werden und das Administrator-Passwort muss gesetzt werden. Dieses wird später bei den
Einstellungen des Slaves benötigt. Weiterhin muss die Zeit des Session Timeout“ hoch”
gesetzt werden auf 20 Minuten.
• Zum Abschluss die Einstellungen durch OK oder Übernehmen bestätigen.
75
C Anleitung zur Nutzung des
entwickelten Systems
Vor dem Ausführen des Systems muss zunächst nach der Anleitung im vorherigen Kapitel
die Installation des eMule-Clients auf jedem vorhergesehenen Slave vorgenommen werden.
Dabei ist anzumerken, dass der Master und ein Slave auf einem Rechner ausgeführt werden
können.
Für den Start des Systems muss zunächst das ganze Verzeichnis auf jeden der Rechner kopiert
werden. Dann wird zunächst der Master gestartet und im Anschluss die einzelnen Slaves.
Dies geschieht jeweils durch Ausführen von distributedAnalysis.bat. Der Master bedarf keiner
weiteren Konfiguration. Die Einstellungen für den Slave werden in der Datei settings.xml,
die sich im Verzeichnis data befindet, vorgenommen. Sollte die Datei nicht vorhanden sein,
wird der Konfigurations-Assistent beim Start des Slaves geöffnet (vgl. Abbildung C.1).
Abbildung C.1: Einstellungsassistent des Slaves
In diesem Assistent können die folgenden Einstellungen vorgenommen werden:
76
C Anleitung zur Nutzung des entwickelten Systems
• Filesharing Webinterface Address: Mit dieser Einstellung wird die Adresse des
Webinterfaces des eMule-Clients festgelegt. Diese Einstellung muss nur geändert werden, wenn der Port in den eMule-Einstellungen des Webinterfaces geändert wurde.
• Filesharing Webinterface Pssword: Hier wird das während der Konfiguration nach
der obigen Anleitung festgelegte Passwort für das eMule-Webinterface eingetragen.
• Filesharing Folder to store files: In dieser Variablen wird der Pfad des Ordners
Incoming im eMule-Verzeichnis festgelegt. Als Standardangabe wird der Wert nach
einer Standard-Installation von eMule festgelegt.
• Folder to store all downloaded files: Hier wird der Pfad zum Arbeitsordner des
Slaves angelegt. Standardmäßig wird dazu der Ordner files im System-Ordner verwendet. In diesen Ordner werden die Dateien nach dem erfolgreichen Download aus dem
eMule-Verzeichnis verschoben und dort gespeichert.
• Distributed eMule Analysis Master Address: In dieser Variablen wird die Adresse
des Masters angegeben. Die Adresse setzt sich aus dem zu verwendenden Protokoll (tcp
oder http), der IP-Adresse des Masters und dem zu verwendendem Port (9700 bei tcp
und 9702 bei http) zusammen.
• Folder to store watermarking algorithms: Hier wird der Pfad zum Speicherordner der Wasserzeichen-Algorithmen angegeben. Standardangabe dabei ist der Ordner
algorithmRoot im Systemorder.
Nach der Eingabe der Parameter und dem Abspeichern versucht der Slave eine Verbindung
zum Master aufzubauen. Sollte er die JXTA-Gruppe DistributedFilesharingAnalysisGroup“
”
nicht finden, so beendet er mit einer entsprechenden Fehlermeldung. Dann ist die Verbindung zum Master zu überprüfen und die Einstellungen anzupassen. Einfachster Weg dazu
ist das manuelle Bearbeiten der Datei settings.xml. Durch Löschen dieser Datei werden die
Einstellungen zurückgesetzt und bei einem erneuten Start erscheint wieder der Einstellungsassistent.
Der Slave ist einsatzbereit, sobald er im Master als registriert erscheint. Zum einen kann
dies durch die angezeigte Anzahl an verbundenen Slaves überprüft werden und zum anderen
werden alle Slaves in der Peer Table angezeigt.
Probleme bei einem Neustart des Systems können durch den JXTA-Cache entstehen. Dabei
werden alle Advertisements temporär gespeichert. Zwar wird für alle eine time-to-live gesetzt,
allerdings ist es teilweise möglich, dass diese zu lang ist. Einfachstes Mittel gegen dieses
Problem ist das Löschen des Ordners .cache.
77
D Inhalt der CD-ROM zur Arbeit
Die CD-ROM zu dieser Arbeit enthält neben der Arbeit in digitaler Form die entwickelte
Software und alle zum Betrieb nötigen Komponenten. Zudem ist eine Dokumentation der
Software eingefügt. Hier der Inhalt der Verzeichnisse im einzelnen:
• \Software:
emule0.47.zip: .zip-Datei, die nur die nötigen Dateien des Tauschbörsen-Clients eMule
enthält
emule0.47c-Installer.exe: .exe-Datei, die ein Installationsprogramm des TauschbörsenClients eMule beinhaltet
jre-1 5 0 10-windows-i586-p.exe: .exe-Datei, die ein Installationsprogramm der JavaLaufzeitumgebung in der Version 5.0
• \Diplomarbeit: Entwickelte Software mit der vollständigen Dokumentation, den Quelldateien und allen benötigten Paketen. Zudem ist die Eclipse-Projekt-Datei, das antBuild-Skript und das gepackte Programm selber vorhanden.
\adv: benötigte Advertisements
\algorithmRoot: Verzeichnis der Wasserzeichen-Algorithmen. Die CD-ROM enthält aus
rechtlichen Gründen keinen Wasserzeichen-Algorithmus, sondern nur einen DummyAlgorithmus, der lediglich den Datei-Hash mit dem Inhalt der Datei DummyMessages.xml vergleicht und so einen Wasserzeichen-Algorithmus simuliert.
\data: In diesem Ordner werden die XML-Dateien abgespeichert. Um einen sauberen“
”
Systemzustand herzustellen, können in diesem alle Dateien außer der algorithms.xml
bedenkenlos gelöscht werden.
\doc: Dokumentation
\files: Speicherort der heruntergeladenen Dateien
\lib: Ordner enthält alle benötigten Pakete
\src: Quelldateien
78
E Kuriositäten-Sammlung
In diesem Abschnitt wurden einige während der Recherche gefundenen Kuriositäten rund um
die Themen Urheberschutz, DRM, Schwarzkopierer, . . . zusammengetragen. Dies zeigt, wie
weit diese Themen inzwischen in die Öffentlichkeit vorgedrungen sind und und auf welchen,
wenn auch teilweise unkonventionellen, Wegen dieser Themenkomplex diskutiert wird.
Abbildung E.1: Buch: The Crow Who Could Fly
(http://www.dustrunners.com/dl/Crow Who Could Fly German.pdf)
- Ein Kinderbuch zum Thema DRM
• Anti-Piraterie-Kampangne der MPAA im Rahmen der Fußball-Weltmeisterschaft 2006
zusammen mit Fußballer Pelé: PELÉ SAYS SCORE A GOAL AGAINST PIRACY“
”
- http://www.mpaa.org/press releases/2006 06 09.pdf
• Kampagne Privat Kopieren ist kein Verbrechen!“ mit Internet-Gefängnis zum Selbst”
einliefern: http://www.wir-haben-privat-kopiert.de/
79
Abbildung E.2: Buch: The Pig And The Box
(http://www.dustrunners.com/dl/Pig and the Box German.pdf)
- Ein Kinderbuch zum Thema Urheberrecht
Abbildung E.3: Parodie RIAA
Plakat: http://modernhumorist.com/mh/0004/propaganda/mp3.cfm
80
Literaturverzeichnis
AmtsblattDerEuropaeischenUnion
: Amtsblatt der Europäischen Union
GesetzUeberUrheberrechtUnd
: Gesetz über Urheberrecht und verwandte Schutzrechte. –
gesetze-im-internet.de/bundesrecht/urhg/gesamt.pdf
URL http://www.
Richtlinie2006/24/EGDesEuropaeischen:15.03.2006 15.03.2006
: Richtlinie 2006/24/EG des europäischen Parlaments und des Rates vom 15. März 2006
über die Vorratsspeicherung von Daten, die bei der Bereitstellung öffentlich zugänglicher
elektronischer Kommunikationsdienste oder öffentlicher Kommunikationsnetze erzeugt
oder verarbeitet werden, und zur Änderung der Richtlinie 2002/58/EG. 15.03.2006. Siehe (AmtsblattDerEuropaeischenUnion). – URL http://europa.eu.int/eur-lex/lex/
LexUriServ/site/de/oj/2006/l_105/l_10520060413de00540063.pdf
Richtlinie2001/29/EGDesEuropaeischen:22.05.2001 22.05.2001
: Richtlinie 2001/29/EG des Europäischen Parlaments und des Rates vom 22. Mai
2001 zur Harmonisierung bestimmter Aspekte des Urheberrechts und der verwandten
Schutzrechte in der Informationsgesellschaft. 22.05.2001. Siehe (AmtsblattDerEuropaeischenUnion). – URL http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.
do?uri=CELEX:32001L0029:DE:HTML
Bamert u. a. 2004
Bamert, Thomas ; Meier-Bickel, Thomas S. ; Rüdt, Christoph ; Zürich, Universität (Hrsg.): Musik- Downloads. 2004. – Kurzbericht zur Studie
BitTorrent.org
BitTorrent.org: BitTorrent.org - Introduction. – URL http://www.bittorrent.
org/introduction.html
Bleich 26.01.2006
Bleich, Holger: Generalstaatsanwaltschaft klagt über ungebremste P2P-StrafanzeigenMaschine. 26.01.2006. – URL http://www.heise.de/newsticker/meldung/68882
BSA 2000
BSA: Homepage Business Software Alliance. 2000. – URL http://www.bsa.org
BSA 2005
BSA: Piracy Study 2005. 2005. – URL http://www.bsa.org/germany/presse/
newsreleases/upload/IDC-Pirateriestudie-2005.pdf
CacheLogic 2005
CacheLogic: Peer-to-Peer in 2005. 2005. – URL http://www.cachelogic.com/home/
pages/research/p2p2005.php
Literaturverzeichnis
81
Consortium 16.08.2006
Consortium, World Wide W.: Extensible Markup Language. 16.08.2006. – URL http:
//www.w3.org/TR/REC-xml/
Coulouris u. a. 2005
Coulouris, George ; Dollimore, Jean ; Kindberg, Tim: Distributed systems. Harlow : Addison-Wesley, 2005 (International computer science series). – URL http:
//www.gbv.de/dms/ilmenau/toc/502901764coulo.PDF. – ISBN 0321263545
Deutschland 2006
Deutschland, GfK Panel S. ; Deutschland, GfK Panel S. (Hrsg.): Brennerstudie
2006. 2006
Dittmann 2000
Dittmann, Jana: Digitale Wasserzeichen. Berlin : Springer, 2000 (Xpert-press). –
ISBN 3-540-66661-3
Dittmann u. a. 2005/12//
Dittmann, Jana ; Franz, Elke ; Schneidewind, Antje: Steganographie und Wasserzeichen - Aktueller Stand und neue Herausforderungen. In: Informatik-Spektrum 28
(2005/12//), Nr. 6, S. 453–461. – URL http://www.springerlink.com/openurl.asp?
genre=article&id=doi:10.1007/s00287-005-0043-y
Gamma und Riehle 2000
Gamma, Erich ; Riehle, Dirk: Entwurfsmuster. München : Addison-Wesley, 2000
(Professionelle Softwareentwicklung). – ISBN 3893199500
Gates 1976
Gates, Bill: An Open Letter to Hobbyists. URL http://www.blinkenlights.com/
classiccmp/gateswhine.html, 1976
Giesler 2004
Giesler, Markus ; Giesler, Markus (Hrsg.): Rethinking Consumer Risk. 2004. – URL
http://www.markus-giesler.com
Gradecki 2002
Gradecki, Joseph D.: Mastering JXTA. Indianapolis Ind. : Wiley, 2002. – ISBN
0471250848
Hansen 24.01.2003
Hansen, Sven: Service Provider sollen Filesharing unterbinden. 24.01.2003. – URL
http://www.heise.de/newsticker/meldung/33955
Hauswirth und Dustdar 09.11.2006
Hauswirth, Manfred ; Dustdar, Schahram: Peer-to-Peer: Grundlagen und Architektur. 09.11.2006. – URL http://www.infosys.tuwien.ac.at/Staff/sd/papers/
DBS-P2P.pdf
IFPI
IFPI: Digital Music Report 2006. – URL http://www.ifpi.org/content/library/
digital-music-report-2006.pdf
82
Literaturverzeichnis
iRights.info 04.02.2005
iRights.info, Oliver P.: Privatkopie und Co. 04.02.2005. – URL http://irights.
info/index.php?id=90
Jurran 13.09.2006
Jurran, Nico: eDonkey-Betreiber zahlt 30 Millionen US-Dollar an Musikindustrie.
13.09.2006. – URL http://www.heise.de/newsticker/meldung/78126
Kossel 14.09.2000
Kossel, Axel: Kann das Betamax-Urteil Napster retten? 14.09.2000. – URL http:
//www.heise.de/newsticker/meldung/11932
Krempl 12.07.2005
Krempl, Stefan: Studie: Zwei Drittel der Kinofilme online verfügbar. 12.07.2005. – URL
http://www.heise.de/newsticker/meldung/61617
Krempl 20.09.2006
Krempl, Stefan: Popkomm: Musikwirtschaft will Zugangsanbieter zur Kasse bitten.
20.09.2006. – URL http://www.heise.de/newsticker/meldung/78462
Krömer und Sen 2006
Krömer, Jan ; Sen, Evrim: No copy. Berlin : Tropen-Verl., 2006. – ISBN 3-932170-82-2
/ 3932170822 (Ebr.) :
Kulbak und Bickson January 20, 2005
Kulbak, Yoram ; Bickson, Danny: The eMule Protocol Specifikation. January 20,
2005. – URL http://prdownloads.sourceforge.net/emule/protocol_guide.pdf
mbb 08.12.1999
mbb: Anklage gegen MP3-Tauschsite. 08.12.1999. – URL http://www.heise.de/
newsticker/meldung/7213
MERIT
MERIT:
Wasserzeichen - Digital Watermarking. –
URL http://www.ipsi.
fraunhofer.de/merit/mediensicherheit/was_ist_watermarking.de.html
Müller u. a. Oktober 2005
Müller, Reinhard ; Heintz, Linda ; Iwaowitsch, Dirk ; Meyer, Christoph ;
Mackenroth, Frank ; König, Silke ; Breuer, Wolfgang ; WPG, PricewaterhouseCoopers A. (Hrsg.):
German Entertainment and Media Outlook: 20052009.
Oktober 2005. –
URL http://www.pwc.com/Extweb/pwcpublications.
nsf/docid/C3A3CC7C707F052E8025709D0030670C,http://www.pwc.com/Extweb/
pwcpublications.nsf/docid/C3A3CC7C707F052E8025709D0030670C
OECD 13.12.2005
OECD: Digital Broadband Content: Music. 13.12.2005. – URL http://www.oecd.org/
dataoecd/13/2/34995041.pdf
online 10.05.2000
online, Heise: MP3-Tauschbörse sperrt 335.435 Benutzer. 10.05.2000. – URL http:
//www.heise.de/newsticker/meldung/9449
Literaturverzeichnis
83
p2pnet 06.02.2006
p2pnet: Richard Stallman interview. 06.02.2006. – URL http://www.p2pnet.net/
story/7840
Röttgers 2003
Röttgers, Janko: Mix, Burn & R.I.P. Hannover : Heise, 2003 (Telepolis). –
URL http://www.gbv.de/du/services/agi/65C51D6EF13670ADC1256E2A004E06B9/
420000115193. – ISBN 3936931089
Schoder und Fischbach 2002
Schoder, Detlef ; Fischbach, Kai:
Peer-to-peer.
Berlin : Springer, 2002
(Xpert.press). –
URL http://www.gbv.de/du/services/agi/
5871BFD008A120ACC1256D2E00492C25/420000088548. – ISBN 3-540-43708-8
Schotzger 03.07.2002
Schotzger, Erwin: Musikindustrie will nun einzelne User klagen. 03.07.2002. – URL
http://www.pressetext.at/pte.mc?pte=020703025
Steinmetz u. a. 19.12.2002
Steinmetz, Ralf ; Schmitt, Jens ; Heckmann, Oliver: Peer-to-Peer Tauschbörsen Eine Protokollübersicht. 19.12.2002. – URL ftp://ftp.kom.e-technik.tu-darmstadt.
de/pub/papers/HSS02-3-paper.pdf
Streit 19.06.2000
Streit, Klaus-Michael: MP3 kurbelt CD-Verkäufe an. 19.06.2000. – URL http://www.
heise.de/newsticker/meldung/10112
Tanenbaum u. a. 2003
Tanenbaum, Andrew S. ; Steen, Maarten van ; Muhr, Judith: Verteilte Systeme.
München : Pearson Studium, 2003 (Pearson StudiumInformatik, Verteilte Systeme). –
ISBN 3827370574
für Strategieentwicklung in Kooperation mit der Universität Witten/Herdecke
2004
Universität Witten/Herdecke, Institut für Strategieentwicklung in Kooperation mit der ; Wittern/Herdecke, Universität (Hrsg.):
Digitale Mentalität.
2004. –
URL http://download.microsoft.com/download/D/2/B/
D2B7FE98-CA92-4E18-ACD6-94A915B4CAFF/Digitale_Mentalitaet.pdf
Wikipedia
Wikipedia: Wikipedia. – URL http://www.wikipedia.de
Wilkens 05.05.2002
Wilkens, Andreas: Studie: Tauschbörsen helfen der Musikindustrie. 05.05.2002. – URL
http://www.heise.de/newsticker/meldung/27168
Wilkens 08.09.2003
Wilkens, Andreas: RIAA verklagt 261 Tauschbörsen-Nutzer. 08.09.2003. – URL http:
//www.heise.de/newsticker/meldung/40147
Wilkens 10.05.2002
Wilkens, Andreas: Musikverband kritisiert Studie über Tauschbörsen. 10.05.2002. –
URL http://www.heise.de/newsticker/meldung/27301
84
Literaturverzeichnis
Wilkens 22.01.2003
Wilkens, Andreas: Marktforscher: Tauschbörsen schaden Europas Musikindustrie.
22.01.2003. – URL http://www.heise.de/newsticker/meldung/33869
Wolf 2006
Wolf, Patrick: An Introduction to the AlgorithmManger. 2006
Zota 12.09.2006
Zota, Volker: eDonkey-Betreiber wirft endgültig das Handtuch. 12.09.2006. – URL
http://www.heise.de/newsticker/meldung/78093
Zota 22.02.2006
Zota, Volker: Größter eDonkey-Server beschlagnahmt. 22.02.2006. – URL http://www.
heise.de/newsticker/meldung/69924