Bachelorarbeit

Bachelorarbeit
Verteilte Datenhaltung einer Website durch
ein browserbasiertes Peer-to-Peer-System
Marten Schälicke
22.01.2013
Hochschule für Technik und Wirtschaft Berlin
Fachbereich 4 – Wirtschaftswissenschaften II
Internationale Medieninformatik
Prüfungsvorsitzende: Erstgutachter: Zweitgutachter: Prof. Dr. Debora Weber-Wulff
Prof. Dr. (USA) Ralph Lano
Sascha Baumeister
Dieses Dokument ist lizensiert als Inhalt der Creative Commons Namensnennung - Nicht-kommerziell
- Weitergabe unter gleichen Bedingungen 3.0 UnportedLizenz. Um eine Kopie der Lizenz zu sehen, besuchen Sie
http://creativecommons.org/licenses/by-nc-sa/3.0/.
Inhaltsverzeichnis
1. Einleitung
6
1.1. Problem
6
1.2. Analyse
6
1.3. Anforderungen
7
1.4. Vorgehensweise
7
2. HTML5
2.1. JavaScript
8
9
2.2. WebRTC
10
2.3. Lokaler Speicher
11
2.3.1. Web Storage
11
2.3.2. IndexedDB
12
2.3.3. Web SQL Database
13
2.3.4. File System API
13
2.3.5. Cache Manifest
14
3. Prozess- / Programmiermodell
15
4. Programmiersprache
16
5. Netzwerk
17
5.1. Verbindungsstruktur
17
5.1.1. Soziale- / Zufalls-Netzwerke
18
5.1.2. Strukturierte Netzwerke
18
5.1.3. Hybride Netzwerke
21
5.1.4. Schlussfolgerung
21
5.1.5. Umsetzung
5.1.5.1. PeerID
22
23
3
5.1.5.2. Entfernungen zwischen Peers
5.1.5.3. Routing-Tabelle
5.1.5.4. Einwahl in das Netzwerk
5.1.5.5. Suche nach Knoten
5.1.5.6. Routing
5.1.5.7. Verbindungsaufbau zwischen Peers
5.2. Web-Service-Protokoll
24
24
28
29
29
31
32
5.2.1. REST
32
5.2.2. WSDL + SOAP
33
5.2.3. Zusammenfassung und Schlussfolgerung
33
5.2.4. Umsetzung Netzwerk-Protokoll
5.2.4.1. Network
5.2.4.1.1. nodeLookup
5.2.4.1.2. peerDescription
5.2.4.1.3. ringSegmentSearch
5.2.4.1.4. pcDescription
5.2.4.1.5. iceProcess
5.2.4.2. Public
5.2.4.2.1. valueStore
5.2.4.2.2 valueManage
5.2.4.2.3. valueLookup
5.2.4.3. Friendship
5.2.4.3.1. userAuthentication
5.2.4.3.2. humanAuthentication
5.2.4.3.3. changesRequest
5.2.4.3.4. changesPush
5.2.4.3.5. valueStore, valueGet & valueDelete
35
36
37
37
37
37
38
38
38
38
39
39
39
39
40
40
40
6. Datenhaltung
6.1. Datenhaltung öffentlicher Daten
41
42
6.1.1. Datenformat
42
6.1.2. Erzeugung von DatenIDs
42
6.1.3. Datenverteilung
43
6.1.4. Datenversionierung
44
6.1.5. Speichermanagement
46
6.1.6. Suche
46
6.1.7. Cache
48
6.2. Datenhaltung privater Daten
49
4
7. Freundschaften
50
7.1. Einwahl von anderem Rechner
50
7.2. Suche nach eingeloggten Freunden
51
8. Fazit und Ausblick
8.1. Sicherheit & Anonymität
52
53
8.1.1. Onion-Routing
53
8.1.2. Herkunft von Dokumenten
53
8.2. Steigerung Nutzerakzeptanz
54
8.2.1. Suchmaschinen
54
8.2.2. Import von Daten
54
8.3. weitere Verbesserungen
55
I Literaturverzeichnis
56
II Darstellungsverzeichnis
61
III Abkürzungsverzeichnis
62
IV Anhang
63
Anwendungsfalldiagramm
63
Klassendiagramm
64
Aktivitätsdiagramm „Einwahl“
65
weitere Anhänge
66
Installation
V Eidesstattliche Erklärung
66
67
5
1. Einleitung
Websites werden von einer Personengruppe erstellt, von dieser verwaltet und von dieser gehostet. Auch der Inhalt wurde früher von dieser
Gruppe geschaffen. Schließlich begann aber mit Foren und Ähnlichem
die Entwicklung von Websites mit User-generated-Content, woraus Internetportale, wie YouTube, Flickr oder Wikipedia, entstanden, die nur von
nutzergenerierten Inhalten leben. Eines ist jedoch geblieben: die Daten
liegen auf einem zentralen Punkt.
1.1. Problem
Gerade bei Open-Source Projekten, wie Wikipedia, führen die Kosten
für die Server des öfteren zu Problemen. Auch ist ein einziger zentraler
Punkt eine Schwachstelle im System – sei es durch Ausfälle der Hardware oder Ausnutzung von Macht durch Dritte, wie es in totalitären Staaten leider praktiziert wird. Zentralität lässt sich durch Redundanz lösen,
Machtmissbrauch hingegen nur durch Umgehung der offiziellen Netzwerke. Technische Lösungen wie VPN-Verbindungen sind allerdings für
den Laien oft schwer einzurichten.
1.2. Analyse
Eine Lösung, die sowohl die Finanzierungsprobleme von kostenfrei
erhältlichen Webseiten, als auch möglicherweise eine Zensur, beheben
kann, sollte daher möglichst einfach für den Nutzer sein und darf kaum
von seinem normalen Internetverhalten abweichen, um akzeptiert zu
werden.
Der Hauptansatz wäre die Verteilung der Daten auf viele Punkte, so
dass ein Netzwerk aus Peers entsteht. Weiterhin sollte der Anwender keine weitere Software installieren müssen, um den Dienst auch von öffentlichen Geräten aus nutzen zu können. Ein Browser ist auf nahezu jedem
Computer vorhanden, daher könnte dieser genutzt werden. Mit den Neu6
erungen im Zusammenhang mit HTML5 ist dies auch zum Greifen nah.
Die Lösung ist also eine Website, deren Inhalte von den Nutzern generiert
werden. Diese werden anschließend automatisch verteilt, gespeichert
und somit für andere Nutzer auf Abruf erfahrbar macht.
Weiterhin stellt die direkte Kommunikation zwischen Personen eine
Hauptnutzungsart des Internet dar. Jene ist zwar weniger durch Zensur,
aber umso mehr von Überwachung betroffen. Da hier ebenso das Hauptproblem zentrale Strukturen sind, ließe sich dies gleichermaßen durch
ein Peer-to-Peer-Netzwerk entschärfen.
1.3. Anforderungen
Somit ergeben sich folgende Anforderungen:
• Die Bedienung muss leicht und intuitiv sein.
• Das Nutzungserlebnis darf nicht zu sehr von
dem normaler Webseiten abweichen.
• Das Netzwerk muss browserbasiert sein.
• Das Netzwerk muss rückwärtskompatibel sein und
darf nicht nur die neueste Software unterstützen.
• Die Speicherung und Suche von Daten muss möglich sein.
• Eine Art soziales Netzwerk sollte integriert sein.
• Eine Sicherung und Anonymisierung sollte möglich sein.
• Die Teilnahme am Netzwerk darf nicht durch
Spuren auf dem Computer erkenntlich sein.
1.4. Vorgehensweise
Diese Arbeit beschreibt ein Netzwerk – genannt PeerWeb – , welches
zur Lösung des Problems benutzt werden kann. Hierbei liegt der Fokus
auf einer effizienten und einfachen Nutzung. Vorrangig geht es in der Arbeit um den öffentlichen Teil von PeerWeb, daher werden Sicherheitsaspekte nur so weit bedacht, dass ihre spätere Umsetzung keine Änderung
des vorgestellten Konzepts ergeben.
7
2. HTML5
HTML steht für Hypertext Markup Language und ist die für das Internet, wie es der gemeine Nutzer versteht, benutzte Auszeichnungssprache.
Die Inspiration zum Hypertext stammt bereits aus dem Jahre 1945. Vannevar Bush beschrieb in seinem Artikel „As We May Think“ (erschienen
im „The Atlantic Monthly“) mit „Memex“ ein Gerät zum Speichern von Informationen, bei dem der Fokus auf Assoziationen lag 1. Die grundlegende
Idee ist wohl viel älter. So referenzieren sich bereits die Kommentare des
Talmuds 2 gegenseitig. Den Begriff „Hypertext“ verwendete Ted Nelson
zum ersten Mal im Jahre 1965 3.
In einem 1990 erschienenen Memo beschreibt Sir Tim Berners-Lee ein
verteiltes Hypertext System für das CERN 4. Dieses Memo gilt als Erfindung des World Wide Web, da darin bereits von mehreren HypertextServern die Rede ist. So konnte auch zu Texten auf anderen Servern verwiesen werden. Der erste Vorschlag für eine Spezifikation von HTML als
Internetstandard erschien im Juni 1993 5. 1994 wurde das W3C (World
Wide Web Consortium) gegründet 6, welches am 14. Januar 1997 ihre erste
Empfehlung veröffentlichte. Dabei handelte es sich um eine Spezifikation
von HTML 3.2 7. 2004 wurde die „Web Hypertext Application Technology
Working Group“ (WHATWG) als Reaktion auf die eingeschlagene Richtung des W3C gegründet 8.
Die aktuelle Version von HTML bildet HTML5, wobei dieser Standard
sowohl von dem W3C als auch von der WHATWG entwickelt wird. Die
WHATWG möchte dabei jedoch keine neue Version der Auszeichnungssprache hervorrufen, sondern einen „lebendigen Standard“ schaffen 9.
Das W3C behält seine Vorgehensweise bei und veröffentlicht regelmäßig
1
vgl. [BUSH-1945]
2
„‚Belehrung‘, ‚Unterweisung‘. Rabbinische Auslegung des Gesetzes [des Judentums d.V.] sowie die in zwei Rezensionen vorliegenden Textkorpora [...]“ [GOLZ-2000]
Seite 91
3
vgl. [NELS-1965], [W3HI-2000]
4
vgl. [BERN-1990]
5
vgl. [BERN-CONN-1993]
6
vgl. [W3HI-2000]
7
vgl. [W3HT-1997]
8
vgl. [WHAT-2013] Abschnitt 1.6 „History“
9
vgl. [WHAT-2013]
8
aktuelle Versionen seines Konzepts 10. Beide Entwürfe sind nahezu identisch 11. HTML5 beinhaltet nicht nur Neuerungen für das Markup, sondern auch JavaScript APIs. Außerdem werden neue CSS (Cascading Style
Sheet) Funktionen mit HTML5 gleichgesetzt.
So kamen unter anderem hinzu:
• Elementtypen, wie header und footer, welche sich an
gängigen Praktiken des Webdesign orientieren,
• Formularfelder, wie eMail, Number, Time,
• Markup für Audio und Video, sowie entsprechende APIs,
• Webworker, welche Parallelisierung in JavaScript ermöglichen,
• Möglichkeiten Daten im Browser zu speichern,
• Geolocation, zur Abfrage des Standortes im Browser
• und mit Web Real Time Communication
Peer-to-Peer-Verbindungen. 12
2.1. JavaScript
1995 wurde JavaScript mit dem Netscape 2.0 erstmalig veröffentlicht.
Damals galt es nur Formulare zu validieren und das Data Object Model
(DOM) anzupassen. Die Sprache wurde jedoch ständig weiterentwickelt
und wird heutzutage nicht mehr nur im Browser verwendet. Dabei sind
Anwendungsfälle wie Datenvalidierung in PDF-Formularen noch nah an
der ursprünglichen Idee. Mit Node.js gibt es mittlerweile auch Webserver,
welche mit JavaScript programmiert werden.
JavaScript ist eine prototyp-basierte, objektorientierte – aber klassenlose – Scriptsprache. Klassen können dennoch durch First-Class-Objekte
verwendet werden. Generell kann diese Sprache stark angepasst werden.
10
vgl. [W3HT-2012]
11
Die WHATWG listet die Unterschiede in ihrem Entwurf, siehe [WHAT-2013] Abschnitt 1.2.1 „How do the WHATWG and W3C specifications differ?“
12[MINT-2011]
9
2.2. WebRTC
Web Real Time Communication verfolgt das Ziel, Latenzen in der Kommunikation zwischen Nutzern auf ein Minimum zu verringern, ohne
den Einsatz von Browserplugins. Das Hauptaugenmerk bei der Entwicklung dieses Standards liegt auf der Durchführung von Videokonferenzen.
So wurden zunächst Audio- und Videoverbindungen implementiert. Seit
kurzem wird auch die angedachte Datenverbindung umgesetzt.
Dar. 2.1 – Benötigte Verbindungen zum Aufbau einer RTCPeerConnection [DUTT-2012]
Die RTCPeerConnection ist blau dargestellt. Peer A und B ermitteln ihre Erreichbarkeit von außen mittels der
STUN-Server, anschließend tauschen sie sich diese Informationen über eine nicht weiter definierte Verbindung
aus.
Um eine Verbindung zwischen zwei Browsern 13 (RTCPeerConnection)
aufzubauen, wird ein zusätzlicher Kanal benötigt, über den die Verbindungspartner Informationen austauschen können. Dieser kann beliebig
realisiert werden. So könnten die Nachrichten einfach über einen Server geleitet werden, mit dem beide Browserclients verbunden sind. Aber
auch ein bereits bestehendes Netzwerk kann genutzt werden, um weitere
Verbindungen aufzubauen. Die über diesen Weg transportierten Daten
sind:
• Informationen zur lokalen Konfiguration
• Informationen zur entfernten Konfiguration
• Transport-/Verbindungsinformationen
13
zur Zeit werden nur Verbindungen zwischen zwei Peers unterstützt, Verbindungen zu mehreren sind möglich, erfordern jedoch jeweils eine zusätzliche RTCPeerConnection
10
Die Erreichbarkeit von Peers hinter NATs wird durch STUN (Session
Traversal Utilities for NAT) bzw. TURN (Traversal Using Relays around
NAT) Server ermöglicht. Diese werden im zur Verbindungsfindung genutzten ICE-Framework verwendet. Es können jedoch beim aktuellen
Stand der Entwicklung mehrere STUN bzw. TURN Server über ein Konfigurationsobjekt übergeben werden 14, wodurch der Ausfall einzelner Server abgemildert wird.
Noch befindet sich dieser Standard in der Phase einer Arbeitsfassung.
So sollen die Statuscodes der Verbindung noch denen von Websockets angepasst werden.
2.3. Lokaler Speicher
Durch die Entwicklung von HTML5 entstand auch die Möglichkeit,
größere Mengen an Informationen im Browser persistent zu speichern.
Vorher stand mit der Verwendung von Cookies nur ein sehr begrenztes Volumen zur Verfügung. Zu dem beeinflusste diese Technik die Geschwindigkeit von Seitenaufrufen negativ. Dank der folgenden Neuerungen kann je nach Browser, Anwendungs- und Speicherart die gesamte
Festplattenkapazität verwendet werden 15. Dabei gilt jedoch bei allen Möglichkeiten die Same-Origin-Policy. So können nur Anwendungen von der
gleichen Herkunft auf den selben Speicher zugreifen. Die Herkunft wird
dabei über das Protokoll, die Domain und den Port beschrieben.
2.3.1. Web Storage
Web Storage beschreibt eine einfache Key/Value basierte Speicherlösung
im Browser. Sowohl Key als auch Value können dabei nur vom Typ String
sein. Dabei gibt es die zwei Varianten localStorage und sessionStorage.
Während sessionStorage nur für die Dauer einer Sitzung Gültigkeit besitzt, werden im localStorage Daten persistent gespeichert. Dabei können mehrere Tabs einer Domain auf den selben Speicher zugreifen. Die
14
15
vgl. [W3WR-2012] Abschnitt 5 „Peer-to-peer connections“
vgl. [GOOG-2012]
11
Defaultspeichergröße ist nicht in der Spezifikation festgelegt und variiert
somit von Browser zu Browser. Firefox 16 und Opera 17 lassen 5MB zu, Internet Explorer hingegen 10MB 18 (jeweils für eine Quelle). Somit steht wesentlich mehr Speicher zur Verfügung als mit Cookies (4KB 19). Außerdem
wird der Inhalt des Storage nicht an den Server geschickt. Web Storage
wird von rund 91% der verwendeten Browser unterstützt 20.
Die APIs der beiden Storagevarianten unterscheiden sich nicht. Da
nur das Ablegen von Strings unterstützt wird, müssen Objekte vorher in
JSON-Strings (JavaScript Object Notation) umgewandelt werden.
Durch das Hinzufügen eines Handlers für das Storage-Event lassen
sich zudem Änderungen im Speicher verfolgen 21.
2.3.2. IndexedDB
IndexedDB speichert wie Web Storage Key-Value-Paare. Hierbei können
jedoch auch Objekte als Wert abgelegt werden. Der Schlüssel kann dabei eine Eigenschaft des Objektes sein. Weiterhin können Indices erstellt
werden. Zugriffe auf die Datenbank sind an Transaktionen gebunden, so
können nicht mehrere Veränderungen oder Schreibvorgänge innerhalb
eines Scopes gleichzeitig stattfinden. Sollte die Applikation mehrere solcher Transaktionen gleichzeitig starten, werden sie nacheinander ausgeführt. Lesevorgänge können sich jedoch überschneiden 22. Durch die Verwendung der Indices ist auch das Suchen in bestimmten Feldern möglich,
ohne das über jedes Objekt iteriert werden muss.
Weiterhin sind die meisten Aufrufe asynchron gehalten, so dass ein
Callback übergeben werden muss. Es ist zwar eine synchrone API vorgesehen, bisher wird diese jedoch von keinem Browser unterstützt. Dadurch
gibt es Überlegungen seitens des W3C, diese wieder fallen zu lassen 23.
16
17
18
19
20
21
22
23
vgl. [FIRE-2006] Zeile 67
vgl. [OPER-2012]
vgl. [MSDN-2012]
vgl. [IETF-2011] Abschnitt 6.1
vgl. [CANI-2013]
vgl. [PILG-2011]
vgl. [MBID-2012] Abschnitt „Definitions“
vgl. [W3ID-2012] Abschnitt „Features at Risk“
12
Die maximale Größe der Datenbank ist nicht festgelegt und ist somit
von Browser zu Browser unterschiedlich. Im Firefox gibt es keine Limitierung, jedoch wird der Nutzer ab 50MB um Erlaubnis gefragt 24. Unter
Chrome wird der zur Verfügung stehende Speicher abhängig von der
Festplattenbelegung errechnet 25.
Obwohl IndexedDB vom W3C weiterverfolgt wird, liegt die Verfügbarkeit nur bei rund 46% bzw. 49%. Zudem müssen in einigen Browsern
Präfixe verwendet werden 26. Über ein Polyfill kann jedoch IndexedDB in
Browsern welche WebSQL unterstützen verwendet werden 27.
2.3.3. Web SQL Database
Wie der Name schon erahnen lässt, sollte mit der Web SQL Database
eine auf SQLite basierende relationale Datenbank in Browser integriert
werden. Leider wurde die Entwicklung vom W3C abgebrochen 28, obwohl
einige Browser 29 sie bereits implementiert hatten. In diesen Browsern ist
die Datenbank jedoch noch nutzbar.
2.3.4. File System API
Die File System API (oftmals auch File API, welche jedoch nur das Lesen von lokalen Daten beschreibt) stellt ein lokales Dateisystem zur Verfügung. In diesem können Anwendungen lesen, schreiben, Dateien und
Ordner erzeugen, sowie durch sie navigieren. Es gibt zwei Arten des Speicherplatzes: einen temporären und einen persistenten. Auf beide kann
asynchron oder synchron zugegriffen werden. Die synchrone API ist
hierbei jedoch WebWorkern (JavaScript Threads) vorbehalten. Die asynchrone API verwendet Callbacks 30.
24
per Default, Wert ist vom Nutzer veränderbar; vgl. [MIDB-2013] Abschnitt „Storage Limit“
25
für Websites; vgl. [GOOG-2012] Abschnitt „Temporary Storage“
26
vgl. [CANI-2013]
27
vgl. [IDBS-2012]
28
vgl. [W3WD-2010]
29
u.a. Chrome, Safari, Opera; Verbreitung ca. 47%; vgl. [CANI-2013]
30
vgl. [W3FA-2012], [MFAP-2012]
13
Das virtuelle Laufwerk wird in einer Sandbox erzeugt. Dadurch hat
die Anwendung keinen Zugriff auf normale Dateien, welche für Desktopapplikationen erreichbar sind. Ein Austausch von Dateien muss daher in
Form eines „Imports“ bzw. „Exports“ erfolgen. Der Import sieht für den
Nutzer wie ein klassischer Dateiupload aus. Der Export hingegen wie ein
Download.
Diese API hat die geringste Verbreitung. So ist sie nur in Chrome per
Präfix verwendbar. Die Verbreitung liegt daher nur bei rund 30% 31. Für
die Größe des Speichers gelten bei der temporären Version die gleichen
Bedingungen wie für die IndexedDB. Für die Nutzung von persistentem Speicher muss der Nutzer explizit gefragt werden. Dabei ist die gewünschte Größe anzugeben. Diese kann jedoch später unter Zustimmung
des Nutzers erhöht werden. Außerdem kann jederzeit abgefragt werden,
wie viel freier Speicher noch zur Verfügung steht.
2.3.5. Cache Manifest
Das Cache Manifest ermöglicht es Webseiten, die einmal von einem
Browser geladen wurden, auch erreichbar zu sein, wenn gerade keine Internetverbindung besteht. Somit können Anwendungen erschaffen werden, welche zwar im Browser ausgeführt werden, aber dennoch keine
ständige Verbindung in das Internet benötigen. Verfügbar ist dieses Feature in rund 66% der verwendeten Browserclients 32.
Um das Cache Manifest zu nutzen, muss im öffnenden html-Tag der
Seite auf das entsprechende Manifest verwiesen werden. Dieses muss zudem mit dem richtigen MIME-Typ übertragen werden. Die Datei selbst
ist recht einfach aufgebaut. In der ersten Zeile muss „CACHE MANIFEST"
stehen. Anschließend können drei Abschnitte (CACHE, NETWORK, FALLBACK)
beschrieben werden, diese können mehrmals und in beliebiger Reihenfolge auftreten.
31
32
vgl. [CANI-2013]
vgl. [CANI-2013]
14
Dateien unter CACHE werden explizit gespeichert. Unter NETWORK aufgeführte Einträge werden auf jeden Fall vom Server angefragt und mittels
FALLBACK können Alternativen für nicht erreichbare Ressourcen angegeben werden.
Soll der Browser eine gecachte Datei neu laden, so muss das Manifest
verändert werden. Dazu reicht ein Kommentar, wie das Datum der letzten Änderung, in diesem. 33
3. Prozess- / Programmiermodell
Neben der reinen Webanwendung – also einer Applikation, welche im
Browser ausgeführt wird – gibt es die Möglichkeit zweier Prozesse. Dabei würde ein Prozess im Hintergrund laufen, welcher zum Beispiel die
Kommunikation zu anderen Peers abwickelt. Dieser Prozess würde einen
lokalen Server darstellen, der über eine Browseranwendung gesteuert
wird. Dieses Modell verwendet das Peer-to-Peer-Netzwerk Freenet 34. Damit ist der Vorteil verbunden, dass auch Programmiersprachen wie Java
oder C++ verwendet werden könnten, welche zu mehr Freiraum in der
Umsetzung beitragen. Jedoch würde es sich dadurch um keine browserbasierte Anwendung mehr handeln. Zudem ergäben sich weitere Nachteile. Der Nutzer müsste so unter Umständen Software installieren – an
fremden Computern ist dies oftmals keine Option. Die zusätzliche Software könnte zwar auch portabel konzipiert werden, dennoch bedeutete
es Mehraufwand für den Nutzer.
Eine Applikation die nur im Browser ausgeführt wird, stellt für den
Benutzer das normale Nutzungsverhalten des Internets her. Er kann von
jedem beliebigen mit dem Internet verbundenen Gerät die Seite öffnen
und nutzen, somit auch an fremden Geräten.
33
34
vgl. [BIDE-2011]
vgl. [FREE-2012] Abschnitt „Techincal Questions“ Frage 1
15
4. Programmiersprache
Durch die Zielsetzung, ein browserbasiertes Peer-to-Peer-Netzwerk zu
entwickeln, ist die Wahl der zu verwendenden Sprache bereits stark eingeschränkt. So bleiben nur Skriptsprachen, welche von der Mehrheit der
zur Zeit benutzten Browser 35 unterstützt werden.
Dar. 4.1 – Verteilung relevanter Browserplugins (auf Grundlage von [STAT-2010], [STAT-2011], [WEBH-2013])
Erhebungszeitraum Dezember 2010 bis Januar 2013
In dem Diagramm sind die Verteilungen relevanter Browserplugins
und somit Skriptsprachen abgebildet. Auf Grund der geringen Verbreitung fallen Visual Basic Scripting sowie Java aus der Betrachtung. Zu dem
ist Visual Basic Scripting nur auf Windows Systemen verfügbar. Flash
stellt das einzige Plugin mit einer steigenden Verbreitung dar, außerdem bietet es die Möglichkeit Peer-to-Peer-Verbindungen aufzubauen 36.
Jedoch handelt es sich dabei um ein proprietäres System, wodurch die
Applikation auf Server von Adobe angewiesen ist.
Allen aktuellen Versionen gemein ist jedoch die Scriptsprache JavaScript. Hierbei gibt es Unterschiede im Funktionsumfang. So ist die
für PeerWeb verwendetbare RTCPeerConnection erst in den aktuellen
Versionen von Chrome und Firefox vorhanden. Deren benötigter Teil
„DataChannel“ wird hingegen zur Zeit in den nightly Builds von Firefox
implementiert und soll im Januar 2013 in die reguläre Version integriert
35
36
restriktive Browserversionen inklusive Plugins bzw. Addons
über NetStream, vgl. [ADOB-2010]
16
werden. In den Browser Google Chrome soll mit Version 25 eine experimentelle Version einfließen, ab Version 26 soll auch die Kommunikation
zu Firefox möglich sein 37.
Weiterhin besteht die Möglichkeit zwischen JavaScript und dem in
Flash verwendeten ActionScript zu kommunizieren 38, wodurch die Möglichkeit besteht, eine fehlende WebRTC Unterstützung des Browsers durch
Flash abzufangen.
5. Netzwerk
Wie bereits in der Einleitung erwähnt, soll ein Peer-to-Peer-Netzwerk
entstehen. Die Frage nach der konkreten Struktur ist jedoch nicht beantwortet. Weiterhin muss geklärt werden, wie die Teilnehmer des Netzwerks miteinander kommunizieren.
5.1. Verbindungsstruktur
Je nach Zielsetzung eines Netzwerkes sind bestimmte Eigenschaften
wichtig. Sollen allgemein Daten abgelegt und genutzt werden, ist ein geringer Durchmesser von entscheidender Bedeutung. Weiterhin ist auch
der Grad des Netzwerkes wichtig. Grad steht hierbei für die Anzahl an
Verbindungen, die ein Peer unterhält.
In Freundschaftsnetzwerken wird die Verbindungsstruktur durch die
Nutzer determiniert. Werden diese gewissenhaft benutzt, stellen sie aus
sich heraus einen guten Schutz gegen Zensur dar. Hybride Netzwerke
können Teilnehmer, die für eine Aufgabe besonders geeignet sind, herausstellen und somit die Effektivität erhöhen. Allen gemein ist, dass ein
geringer Nachrichtenbedarf und eine hohe Robustheit gegen Ausfälle
wichtig sind.
37
38
vgl. [DUTT-2012] Abschnitt „WebRTC Support Summary“
vgl. [ADFL-2013]
17
5.1.1. Soziale- / Zufalls-Netzwerke
Soziale Netzwerke bieten den Vorteil, trotz durchschnittlich kleiner
Grade nur einen geringen Durchmesser zu besitzen. Hierbei folgt die Verteilung der Grade jedoch der Pareto-Verteilung, was zur Folge hat, dass
es einige Teilnehmer mit sehr vielen Verbindungen gibt. Dies spricht gegen das Gleichheitsprinzip von Peer-to-Peer-Netzwerken. Soll ein solches
Netzwerk künstlich erschaffen werden, so ist die Anwendung mehrerer
zufallsbedingter Operationen nötig. Bei besonders kleinen Durchmessern spricht man zu dem von Small-World-Netzwerken 39.
Der Beitritt in ein solches Netzwerk ist besonders kostengünstig, da
keine bestimmte Struktur erzeugt werden muss. Auch ist der Ausfall einzelner Peers sehr leicht zu beheben. Zu dem bleibt das Netzwerk bei einem Wegfall größerer Teilnehmermengen mit hoher Wahrscheinlichkeit
zusammenhängend 40. Weiterhin kann ein solches Netzwerk recht anonym betrieben werden, da zur Teilnahme nur Informationen über die
unmittelbaren Nachbarn benötigt werden.
Jedoch gibt es entscheidende Nachteile in der Datenhaltung. So kann
das Auffinden eines vorhandenen Datums nicht garantiert werden oder
ist mit einem sehr hohen Nachrichtenaufwand verbunden 41.
5.1.2. Strukturierte Netzwerke
In diesen Netzwerken wird durch das verwendete Peer-to-Peer-Protokoll eine gewisse Verbindungsstruktur festgelegt. Diese beruht auf eindeutigen IDs. Um diese eindeutig zu halten, müssen sie von bereits vorhandenen eindeutigen Merkmalen (wie einer IPv6-Adresse) abgeleitet sein
oder aus einem Zufallsprozess mit ausreichend großem Ergebnisraum 42
stammen, um Kollisionen zu vermeiden. Somit lassen sich verteilte HashTabellen (Distributed Hash Tables – DHT) realisieren, wodurch ein Datum effektiv abgelegt und wieder aufgefunden werden kann. Jedoch ergeben sich zusätzliche Kosten für den Beitritt eines Peers in ein solches
39
40
41
42
vgl. [MAHL-SCHI-2007] S. 174 ff (Kapitel 9.1)
vgl. [MAHL-SCHI-2007] S. 184
vgl. [MAHL-SCHI-2007] S. 57 ff (Kapitel 3.2)
häufig 2m, wobei m 128 - 160 beträgt
18
Netzwerk, da Verbindungen zu Nachbarn nicht willkürlich aufgebaut
werden können. Zu dem kann der Ausfall von Knoten kritisch werden, da
durch die Struktur benötigte Verbindungen unter Umständen nicht mehr
vorhanden sind und das Netzwerk auseinander brechen könnte.
Die Effektivität solcher Netzwerke hängt stark von ihrer durch das
Protokoll entstehenden Routing-Tabelle ab. Um den Nachrichtenaufwand
zu minimieren und gleichzeitig die Robustheit gegenüber Ausfällen bzw.
fehlerhaften Einträgen zu erhöhen, werden häufig Verbindungsinformationen zu vielen anderen Peers verwaltet. Dies hat jedoch den Nachteil,
dass neben dem Speicherverbrauch auch der Wartungsaufwand für einen Teilnehmer steigt. Zu dem ist ab einem bestimmten Grad die Benutzung von dauerhaften Verbindungen zu Nachbarn nicht mehr möglich.
Chord ordnet die beteiligten Knoten entlang eines Kreises mit zusätzlichen „Abkürzungen“ (Fingerzeiger genannt), wobei jedoch ein gerichteter Graph die Grundlage bildet. Somit wird ein Datum mit hoher Wahrscheinlichkeit nach O(log n) Schritten lokalisiert. Die Grade der Peers
sind einheitlich, wobei die Nachbarschaft höchstwahrscheinlich nur
eine logarithmische Größe aufweist. Das Beitreten eines Peers beinhaltet nicht nur das Einrichten der eigenen Fingerzeiger, sondern auch das
Benachrichtigen der bereits vorhandenen Knoten, deren Fingerzeiger auf
den neuen Peer zeigen könnten 43.
Das auf dem Plaxton et al. 44 Routing beruhende System Pastry verwendet drei Nachbarschaftsklassen. Die erste Klasse (Routing-Tabelle) besteht aus nach ihren IDs in sogenannte Level geordneten Peers. Die Level
beschreiben dabei die Länge des gemeinsamen Präfixes (gemeinsame
Bitfolgen zu Beginn der ID) der eigenen ID und des Nachbarpeers. Die
zweite Klasse (Leaf-Set) besteht aus, über die numerische Interpretation
der ID ermittelten, l nächsten Peers. l beschreibt dabei eine programmweite Konstante. Der letzte Teil (Nachbarschaftsmenge) beinhaltet einfach latenznahe Peers. Bereits durch den zweiten Teil der Routing-Tabelle
lässt sich ein Routing mit maximal O(n/l) Schritten realisieren. 45
43
44
45
vgl. [MAHL-SCHI-2007] S. 81 ff (Kapitel 5)
Plaxton, Rajamaran und Richa
vgl. [MAHL-SCHI-2007] S. 100 ff (Kapitel 6.2), sowie [ROWS-DRUS-2001]
19
Betrachtet man Kademlia näher so nutzt es ebenfalls das Plaxton Routing 46. Jedoch ist es einfacher aufgebaut als Pastry, da es nur eine RoutingTabelle besitzt. Für diese wird die k-Bucket-Struktur verwendet. k ist eine
systemweite Konstante und in der Originalspezifikation 20. Da die IDs in
Kademlia 160 bits lang sind, beträgt die maximale Größe der RoutingTabelle 160k, wobei Buckets nahe der eigenen ID zunehmend nicht voll
besetzt werden können. 47
Sowohl Pastry als auch Kademlia können auf gerichtete wie ungerichtete Graphen aufbauen. Ebenso können beide, obwohl sie aus relativ zufälligen Verbindungen bestehen (mit zunehmender Entfernung der
Knoten 48 können Teilnehmer ihre Verbindungspartner aus einer größer
werdenden Menge wählen), mit sich aus der sozialen Komponente ergebenen Verbindungen ohne größere Modifikationen 49 umgehen.
Kademlia beruht auf einem iterativem Routing 50, so dass Nachrichten
nicht weitergereicht werden. Dem Anfragenden werden lediglich Verbindungsinformationen des nächsten zu kontaktierenden Peers mitgeteilt.
Dies schont zwar die Bandbreite, da große Nachrichten mit Daten nur an
den Zielknoten übertragen werden, führt jedoch zu erhöhtem Nachrichtenaufkommen. Pastry hingegen verwendet rekursives Routing 51. In beiden Fällen ist die Anzahl an Verbindungen verglichen mit Chord relativ
hoch 52.
46
vgl. [MAHL-SCHI-2007] S. 247 (Kapitel 13.4)
47
vgl. [MAYM-MAZI-2002]
48
basierend auf den IDs der Knoten; Entfernungen sind in beiden Fällen symmetrisch
49
nur wenn für ein bestimmtes Level bzw. Bucket dadurch mehr Verbindungen
als vorgesehen nötig werden
50
in [MAYM-MAZI-2002] Kapitel 2.3 wird dies fälschlich rekursiv genannt; vgl.
[CROS-WaLL-2007] Kapitel 4 bzw. [XLAT-2010] Kapitel „Node Lookup“
51
vgl. [MAHL-SCHI-2007] S. 110 f bzw. [CROS-WaLL-2007] Kapitel 4
52
vgl. [MAHL-SCHI-2007] S. 113
20
5.1.3. Hybride Netzwerke
Die Netzwerke Skype, FastTrack und der Gnutella-Nachfolger Gnutella-2 sind zwar Peer-to-Peer-Netzwerke, statten aber im Einsatz einige
Peers mit zusätzlichen Aufgaben aus. Für die Bestimmung dieser Peers
werden bestimmte Eigenschaften wie Bandbreite und Verfügbarkeit herangezogen. FastTrack und Skype sind proprietäre Software, daher können sie nicht als Vorlage verwendet werden.
Gnutella-2 verbessert durch die hybride Struktur aus Leafs (normale
Peers) und Hubs (Superpeers – Peers mit erweiterten Aufgaben) die Effizienz und Zuverlässigkeit der Suche, indem Indexdaten auf den Superpeers gespeichert werden. Allerdings stellt das Netzwerk so kein reines
Peer-to-Peer-System mehr dar 53.
5.1.4. Schlussfolgerung
Für PeerWeb erscheinen sowohl Freundschafts-/Zufallsnetzwerke als
auch verteile Hash-Tabellen als Grundlage dienen zu können. Beide sind
jedoch nicht ohne Verluste von Effizienz im Suchen nach Daten oder von
Privatsphäre vereinbar. Durch die recht offene Wahl der Verbindungspartner von Pastry und Kademlia lassen sich in diesen Netzwerken gut
Verbindungen zwischen Peers, welche auf Freundschaften basieren integrieren. Das in Kademlia vorgesehene iterative Routing kann auf Grund
der – durch den Verbindungsaufbau – hohen Kosten nicht sinnvoll umgesetzt werden. Ein weiterer Grund gegen ein iteratives Routing ist die
Abwärtskompatibilität, durch die nicht gewährleistet werden kann, dass
sich zwei Teilnehmer verbinden können.
Die Abwärtskompatibilität, sowie die Tatsache, dass ein zusätzlicher
Kanal benötigt wird, um zwischen zwei Browsern per RTCPeerConnection
eine direkte Verbindung aufzubauen, bedingt die Verwendung einer hybriden Netzwerkstruktur. Somit müssen Peers integriert werden, welche
auf klassische Weise (AJAX mit Polling, Websockets) von Browsern kontaktiert werden können.
53
vgl. [MAHL-SCHI-2007] Kapitel 13
21
5.1.5. Umsetzung
Da Pastry durch das Leaf-Set bereits mit wenigen Verbindungen ein
Routing ermöglicht, dient es als Grundlage für PeerWeb. Weiterhin wird
auf eine hybride Netzwerkstruktur aus Peers und Superpeers gesetzt.
Dabei bilden Knoten, welche in Browsern laufen, die Menge der Peers.
Superpeers können nicht aus dieser Menge generiert werden. Grund
hierfür ist die für die Einwahl mangelhafte Erreichbarkeit 54. Um dieses
Hindernis zu umgehen, müssen Knoten erreichbar sein, welche wie klassische Server bereitstehen und von anderen Peers jederzeit kontaktiert
werden können. Da das Netzwerk jedoch weiterhin den Ansprüchen eines Peer-to-Peer-Netzes gerecht werden soll, darf weder die Anzahl dieser Superpeers willkürlich festgelegt sein, noch dürfen sie von einer einzelnen Gruppe bereitgestellt werden. Weiterhin darf diesen Knoten keine
weitere zusätzliche Aufgabe zu Teil werden, als die Einwahl in das Netzwerk zu ermöglichen. Der Betrieb nach der Einwahl darf nicht von ihnen
abhängig sein, kann durch sie aber erleichtert werden (z.B. in Form einer
Steigerung der Effizienz bei Suchanfragen).
Die Wahl der Programmiersprache für Superpeers ist offen, da keine
weiteren Anforderungen gestellt werden. Da es ohne weiteres möglich
sein soll, einen solchen Knoten aufzusetzen, sollten die im Internet besonders stark verbreiteten Sprachen PHP, Ruby und Python 55 favorisiert
werden.
Weiterhin folgt das Netzwerkdesign den Grundlagen von verteilten
Hash-Tabellen. Somit sind Teilnehmer über eine eindeutige Kennung adressierbar, über welche auch Inhalte verteilt werden. Diese Kennziffer
entspricht nur dem Knoten und ist nicht an Nutzer des Netzwerkes gebunden.
Durch die Verwendung von unterschiedlichen Technologien im Bereich
der p2p-Verbindungen 56, welche nicht miteinander kompatibel sind, ergeben sich besondere Umstände. Diese werden in den Abschnitten 5.1.5.3
Routing-Tabelle und 5.1.5.6 Routing behandelt. Auch musste eine geson-
54
siehe Abschnitt 5.1.4
55
eine Statistik zur Verteilung kann nicht angeführt werden, sie kann jedoch von
[UDEM-2012] abgeleitet werden
56
JavaScripts RTCPeerConnection und deren Fallback auf Flashs NetStream
22
derte Nachricht eingeführt werden, welche in 5.2.4.1.3 vorgestellt wird.
Da die Verwendung der NetStreams aus Flash nur den Fallback darstellt,
wird auf diese nicht weiter eingegangen.
5.1.5.1. PeerID
Um Knoten des Netzwerks eindeutig erkennbar zu machen wird eine
160 bit lange Kennung (Identifier – ID) verwendet. Diese kann nicht von
der IP-Adresse der Teilnehmer abgeleitet werden. Dies folgt aus der Aufteilung des Internets. Die Wahrscheinlichkeit, dass zwei Teilnehmer über
denselben Internetzugang das Netzwerk benutzen, ist hoch. Da sie somit
nach außen die gleiche IP-Adresse besitzen, würde es bei einer Generierung der ID über diese zu einer Kollision kommen. Aber auch bei Verwendung der IP-Adresse, welche die Knoten von ihrem jeweiligen LAN
erhalten, kann es zu Kollisionen kommen. Denn diese IP-Adresse ist zwar
in dem jeweiligen Netzwerk einmalig, jedoch nicht weltweit. Eine Erzeugung der Kennung über die Kombination von externer und interner
IP-Adresse würde dieses Problem beheben. Dies wäre jedoch mit zusätzlichem Aufwand für die Datenhaltung verbunden, da sich die zugewiesenen IP-Adressen ändern können. Somit würde der Peer eine neue ID und
somit einen anderen Zuständigkeitsbereich erhalten.
Dieses Problem wird durch die einmalige Generierung der ID und der
Beibehaltung dieser gelöst. Dafür kann aber nicht die IP-Adresse herangezogen werden, da diese zu einem anderen Zeitpunkt einem anderen
Teilnehmer gehört, welcher somit die gleiche Kennung erzeugen würde.
Eine zentrale Generierung und Zuweisung der ID würde zwar auf der einen Seite Kollisionen vermeiden können, auf der anderen Seite allerdings
eine angreifbare – weil zentrale – Stelle darstellen.
Wird jedoch die Größe der Kennung weit genug gewählt, kann sie –
bei einer vernachlässigbar kleinen Wahrscheinlichkeit von Kollisionen
– zufällig erzeugt werden. So ergeben sich bei einer Weite von 160 bit
1,46*1046 Kombinationsmöglichkeiten. IDs werden als Zahlen zur Basis
|B| = 2b interpretiert. In PeerWeb gilt – wie in Pastry – hierfür: b = 4 57.
57
vgl. [ROWS-DRUS-2001] Kapitel 2
23
Um die Güte der Zufallszahlen zu steigern, wird diese über den Dienst
random.org generiert. Dieser stellt echte Zufallszahlen zur Verfügung 58.
Somit wird die Wahrscheinlichkeit einer Gleichverteilung der IDs gesteigert. Sollte der Dienst nicht verfügbar sein, werden die IDs von den Peers
selbst erzeugt.
5.1.5.2. Entfernungen zwischen Peers
Die Entfernung zwischen zwei Knoten wird nicht wie in Kademlia
über die XOR-Metrik ihrer Kennungen bestimmt 59. Dies begründet sich
durch die geringe Anzahl an Verbindungen, mit denen PeerWeb bereits
funktionsfähig sein soll. Würde der erste Teil der Routing-Tabelle durch
eine auf XOR basierende Entfernung aufgebaut werden, können sich in
diesem Teil separate Gruppen bilden. Auch der zweite Teil der RoutingTabelle kann eine Abspaltung dieser Gruppen nicht verhindern. Auch
wäre, wenn der Zusammenhang des Netzwerks gewahrt bleiben könnte,
das Routing nicht optimal 60.
Entfernungen werden daher numerisch bestimmt, wobei dadurch
auch auf die Länge ihres gemeinsamen Präfixes geachtet wird. Für die
Länge des Präfixes gilt auch der Begriff Level. Peers die in Level 0 miteinander verbunden sind, haben kein gemeinsames Präfix; Peers in Level 1
haben ein Präfix der Länge 1; usw. 61.
5.1.5.3. Routing-Tabelle
Die Routing-Tabelle eines Peers besteht aus vier Teilen und basiert in
ihren Grundannahmen auf den Nachbarschaftsklassen von Pastry. Die
Mindestgröße beträgt dabei 2,5l Einträge, wobei jeder Eintrag für eine
aktive Verbindung steht. l ist eine Konstante die zur Skalierung des Netzwerkes dient. Somit ist eine Anpassung an kleinere Umgebungen, in denen ein kleinerer Namensraum verwendet werden kann, einfach realisierbar. Der Wert von l wird durch eine gerade Integerzahl bestimmt. In
der hier vorgestellten Umsetzung wurde für l der Wert 6 gewählt. Grund
58
erzeugt mittels atmosphärischen Rauschens
59
vgl. [MAYM-MAZI-2002] Kapitel 2.1
60
auf Grund der in Teil 1 entstehenden Gruppen, aus denen eine Nachricht nur
mit zusätzlichem Aufwand entkäme
61
vgl. [MAHL-SCHI-2007] Kapitel 6.2.1 bzw. [ROWS-DRUS-2001] Kapitel 2.1
24
hierfür ist die überschaubare Mindestanzahl von 15 Verbindungen 62.
Diese ist jedoch bereits groß genug, um einzelne Knotenausfälle zu verkraften.
Nach oben ist die Anzahl offen und wird von dem Nutzer durch die Anzahl seiner Freunde und seinen Einstellungen bestimmt. Hierbei stehen
die Auswahlmöglichkeiten „Verbindungen zu meinen (online) Freunden
und x“ und „maximal x zusätzliche Verbindungen (inklusive Freunde)“
zur Verfügung. Bis auf den dritten Teil der Routing-Tabelle, der mit Superpeers besetzt wird, werden Verbindungen zu Peers in der Tabelle unterhalten.
Dar. 5.1 – Netzwerkstruktur in PeerWeb
Bei diesem Beispielnetzwerk mit l = 4 und 50 Teilnehmern ist die doppelte Ringstruktur gut erkennbar. Blau sind
Verbindungen aus dem ersten Teil der Routing-Tabelle, Verbindungen aus dem dritten Teil sind Grün dargestellt
und Verbindungen, die auf Freundschaften beruhen Orange. Durchgehende Linien stehen für RTCPeerConnections, gestrichelte für Verbindungen auf Flashbasis und Punkt-Strich-Linien für Websocket-Verbindungen.
Aus Gründen der Übersichtlichkeit wurde auf Darstellung des zweiten Teils der Routing-Tabelle sowie weiterer
Freundschaften verzichtet.
62
für Peers, die eine Möglichkeit für p2p-Verbindundungen besitzen; Peers mit
beiden Verbindungsarten weisen bis zu 21 Verbindungen auf
25
Den ersten und wichtigsten Teil bilden die l nächsten Nachbarn des
Knotens. Wobei nach links und rechts jeweils l/2 Verbindungen aufgebaut werden. Somit bildet dieser Teil einen Ring, durch den bereits der
Zusammenhang des Netzes (bei mindestens 2 korrekten Einträgen aller
Teilnehmer) garantiert werden kann. Sind alle l Einträge korrekt, beträgt
der Durchmesser O(n/l). Dieser Teil entspricht dem Leaf-Set von Pastry 63
und wird in PeerWeb ebenso genannt und mit L abgekürzt.
Die Verwendung unterschiedlicher p2p-Verbindungstechniken hat auf
das Leaf-Set besondere Auswirkungen. So kann sich ein Knoten unter
Umständen nicht zu einem anderen verbinden, obwohl er es auf Grund
der Nähebeziehung müsste. Da das Leaf-Set dennoch voll besetzt werden
soll, wird es mit den nächsten Peers gefüllt, zu denen eine Verbindung
möglich ist. Es entstehen daher zwei parallele Ringe, welche sich an einigen Knoten berühren. In Darstellung 5.1 ist dies gut erkennbar.
Der zweite Teil der Routing-Tabelle dient der Erhöhung des Zusammenhalts und so der Verringerung des Durchmessers. Die Gesamtmenge
an Einträgen ist für diesen Teil wiederum l. Zunächst werden Verbindungen zu Peers mit einem gemeinsamen Präfix aufgebaut. Längere Präfixe
werden dafür bevorzugt. Die Verbindungen dürfen hierbei nicht schon in
einem anderen Teil der Routing-Tabelle beinhaltet sein. Weiterhin wird
pro Level nur eine Verbindung aufgebaut. Können keine l Nachbarn bestimmt werden, fällt die Wahl auf zufällig ausgewählte Knoten aus dem
Level 0. Dieser Teil entspräche der Routing-Tabelle von Pastry. In dieser
Arbeit wird R für diesen Teil verwand.
Um die Effizienz des Netzwerkes zu erhöhen, werden im dritten Teil
der Routing-Tabelle nur Superpeers geführt. Die angestrebte Anzahl an
Verbindungen ist hierbei l/2, wodurch die eingangs erwähnte Mindestzahl an Verbindungen erreicht ist. Die Einträge werden wiederum durch
Nähebeziehungen bestimmt. Hierbei werden zwei Verbindungen zu den
nächsten erreichbaren Superpeers zwingend aufgebaut. Die weiteren
Verbindungen werden wie in dem zweiten Teil nach den Leveln vergeben. Hier wird jedoch mit Level 0 begonnen. Die Abkürzung für diesen
Teil ist S.
Die Freundschaftsbeziehungen des jeweils angemeldeten Nutzers
stellen den vierten Teil der Verbindungsstruktur dar. Da die Wahl der
Freunde nicht von PeerWeb beeinflusst werden kann, können keine wei63
vgl. [ROWS-DRUS-2001] Kapitel 2.1
26
Dar. 5.2 – Durchschnittliche Freundesanzahl bei Facebook 2010 (auf Grundlage von [TNSF-2010])
Norwegen führt die Liste mit 216 Freunden an, gefolgt von Polen mit 201 und Griechenland mit 198 Freunden.
Großbritannien (164) und Frankreich (95) sind ebenso deutlich vernetzter als Deutschland mit einem Durchschnitt von 75 Freunden.
tere Angaben gemacht werden. Ein durchschnittlicher Nutzer sozialer
Netzwerke in Deutschland hatte im Dezember 2010 75 Freunde. Wird
die Option „maximal x zusätzliche Verbindungen (inklusive Freunde)“
genutzt, werden Verbindungen zu Freunden bevorzugt. Freundschaftsbeziehungen werden in der Routing-Tabelle berücksichtigt, um direkte
Verbindungen und somit erhöhte Sicherheit für sensible Daten zu ermöglichen. Außerdem erhöhen diese Verbindungen den Zusammenhang des
Netzwerkes und verringern dessen Durchmesser. Obwohl dieser Teil für
das Routing mit in R aufgenommen wird, erhält er mit F eine eigene Abkürzung.
Lässt der Nutzer mehr Verbindungen zu, werden diese in den zweiten
Teil der Routing-Tabelle einsortiert. Dieser wird dann wie die RoutingTabelle von Pastry aufgebaut. Somit werden für jedes Level bis zu 2b -1
Einträge gesucht.
Superpeers besitzen hingegen nur eine zweiteilige Routing-Tabelle. Einen Teil für Verbindungen zu Peers, den anderen Teil für Verbindungen
zu Superpeers. Der Betreiber eines solchen Knotens kann über die Konfiguration die maximale Anzahl an Einträgen festlegen. Dabei sollten we27
PeerID: 1114C5
Leaf-Set L
E89E9E
FF8CF8
18804C
33E132
Teil 2 R
53A6F1
7A100C
A580CE
B9C0C1
Superpeers S
0D4E95
2C68E5
Freunde F
4A9C2C
659D7A
C0DF4D
D0D7D5
Dar. 5.3 – Routing-Tabelle für Peer 1114C5 aus dem Beispielnetzwerk (Dar. 5.1)
sentlich mehr Verbindungen für Peers als zu Superpeers zur Verfügung
stehen. Der Teil für Superpeers wird dabei von dem Knoten selbstständig
aufgebaut und folgt der Routing-Tabelle von Pastry.
5.1.5.4. Einwahl in das Netzwerk
Nach dem Laden von PeerWeb werden zunächst die nötigen Eigenschaften des Browsers geprüft. Ist die Software in dem vom Nutzer
verwendeten Browser lauffähig, wird die ID des Knotens geladen bzw.
erzeugt. Gleichzeitig werden Standardwerte geladen, diese umfassen
Superpeers, die zur Einwahl verwendet werden können und eine Reihe
von STUN bzw. TURN Servern. Nachdem der Peer so initialisiert wurde,
werden Verbindungen zu allen hinterlegten Superpeers aufgebaut. Dabei
muss mindestens ein Superpeer erreichbar sein, welcher nun für das folgende Bootstrapping genutzt wird. Sind mehrere Superpeers erreichbar,
werden diese entsprechend der Routing-Tabelle bzw. der Einstellungen
des Knotens gewählt.
28
Nachdem ein Superpeer für den Bootstrapping-Prozess ausgewählt
wurde, werden Verbindungen zur unmittelbaren Nachbarschaft aufgebaut, das heißt, der erste Teil der Routing-Tabelle gefüllt. Hierzu wird der
Suchalgorithmus für Knoten mit der eigenen ID als Parameter verwendet.
Ist der erste bis dritte Teil der Routing-Tabelle aufgebaut, schließt sich
die Suche nach Freunden an. Zuletzt werden mögliche zusätzliche Verbindungen aufgebaut. Dies geschieht durch Suchanfragen nach zufälligen
PeerIDs. Diese müssen jedoch in den jeweils zu füllenden Bereich liegen.
Superpeers bauen bei der Einwahl nur Verbindungen zu anderen Superpeers aktiv auf.
5.1.5.5. Suche nach Knoten
Durch die Verwendung von Pastry als Netzwerkstruktur ist die Suche
nach Knoten einfach zu implementieren. Hierfür ist es ausreichend eine
entsprechende Nachricht zu verschicken. Diese hat die gewünschte ID als
Ziel. Bereits der anfragende Peer füllt den Body der nodeLookup-Nachricht
mit dem ihm bekannten l nächsten Peers. Diese Liste wird von jedem
weiterleitenden Knoten aktualisiert, indem dieser wiederum die ihm bekannten nächsten Peers einordnet. Der endgültige Empfänger der Liste
tut dies ebenfalls und schickt eine Antwort zurück. Für diese Suche gilt
ebenso das in 5.1.5.6 vorgestellte Routing mit der Bedingung zur Findung
des finalen Knotens.
5.1.5.6. Routing
Das Routing funktioniert nach dem Prinzip, nach dem grundlegend
alle verteilten Hash-Tabellen arbeiten. So werden Anfragen an den Peer
aus der Routing-Tabelle weitergeleitet dessen ID am nächsten zu der ID
des angefragten Datums ist. Dies geschieht bis ein Peer erreicht ist, der
keinen näheren Eintrag in seiner Routing-Tabelle hat. Somit weiß dieser,
dass er für das Datum verantwortlich wäre.
29
Zur Steigerung der Geschwindigkeit und Verringerung des Nachrichtenaufkommens, werden Nachrichten (Anfragen, wie Antworten) vom
Sender, an den nächsten verbundenen Superpeer geschickt. Ausgenommen hiervon sind Peers, die bereits eine Verbindung zu dem Empfänger
besitzen. Diese versenden die Nachricht direkt.
Für den anschließenden Routingalgorithmus gibt es nur das Leaf-Set
(L) und den zweiten Teil (R) der Routing-Tabelle, welcher hierfür durch
die Einträge aus den weiteren Teilen ergänzt wird. Der Routingalgorithmus als solches ist an den von Pastry angelehnt. Er wurde jedoch für den
Fall, dass die ID nicht vom Leaf-Set abgedeckt wird, angepasst. Durch die
geringere Größe der Routing-Tabelle von PeerWeb gegenüber Pastry ist
die Wahrscheinlichkeit einen leeren Eintrag zu treffen, sehr hoch. Daher
verwendet PeerWeb direkt die als „seltener Fall“ angegebene Methode.
Suche( id ){
if( L-l/2 <= id <= Ll/2 ){
//die gesuchte id wird vom Leaf-Set abgedeckt
leite an Peer p’ weiter, für den
|id - p’.id| minimal
}
else{
//Wähle aus allen Verbindungen
level = präfixlänge( PeerID, id );
leite an Peer (aus L oder R) weiter, für den
präfixlänge( PeerID, id ) >= level &&
|p’.id - id| < |p.id - id|
}
}
Dar. 5.4 – Routingalgorithmus in Pseudocode (nach [MAHL-SCHI-2007] Seite 105, [ROWS-DRUS-2001] Kapitel 2.2)
L-l/2 bzw. Ll/2 bezeichnen die IDs der beiden äußeren Peers des ersten Teils der Routing-Tabelle L.
Durch die verschiedenen Technologien im Bereich der Verbindungen zwischen Peers 64, kann eine Nachricht fälschlich zu einem nahen,
aber nicht dem nächsten gesuchten, Knoten weitergereicht werden. Dies
kann jedoch nur geschehen, wenn die Nachricht nicht über den nächsten Superpeer zu diesem Knoten gelangt. Um ein solches Fehlverhalten
zu erkennen, existieren zwei Möglichkeiten. Sind Superpeers vorhanden,
reicht es aus, wenn der vermeintlich letzte Peer, die Anfrage zusätzlich
an seine zwei nächsten Superpeers weiterleitet. Da diese alle vorhande-
64
siehe Abschnitt 5.1.5.3 bzw. 5.1.5.6
30
nen Knoten in der Umgebung kennen, kennt einer von ihnen auch einen
näheren, sofern er im Netzwerk anwesend ist. Somit kann der Superpeer
die Nachricht an den wirklichen Empfänger schicken.
Sind hingegen keine Superpeers vorhanden, müssen wenigstens Teilnehmer anwesend sein, die beide Verbindungstechniken beherrschen.
Um in diesem Fall den näheren Peer zu finden, wird lediglich das LeafSet und eine ringSegementSearch-Nachricht verwendet. Mittels dieser
wird die eigentliche Anfrage verpackt und in Richtung des nächsten bekannten Knotens, welcher beide Verbindungsarten unterstützt, geschickt.
Ist ein solcher nicht bekannt, wird die Nachricht entsprechend der gesuchten ID nach links oder rechts gereicht. Wurde ein entsprechender
Peer erreicht, schickt er die Nachricht in die Richtung zurück, aus der sie
kam, verwendet dabei jedoch die andere Verbindungsart. Wird auf dem
so erreichten Ringabschnitt ein näherer Knoten gefunden, weiß dieser,
dass er antworten muss. Andernfalls gelangt die Nachricht zurück zum
Sender der ringSegmentSearch-Nachricht. Somit ist dieser der nächste anwesende Peer.
Eine Anfrage muss jedoch nicht bis zu diesem Ende geleitet werden,
da wie im Kapitel 6.1.3 beschrieben, mehrere Knoten dasselbe Dokument
speichern. Selbst diese Teilnehmer müssen nicht zwangsläufig erreicht
werden, da Peers auch Anfragen mittels ihres Caches beantworten können.
Es muss bedacht werden, dass ein Peer beim Routing keine Weiterleitung einer Nachricht an den Knoten vornimmt, von dem er die Nachricht
empfangen hat.
5.1.5.7. Verbindungsaufbau zwischen Peers
Der Verbindungsaufbau zwischen Peers und Superpeers kann aus
technischen Gründen nur auf Initiative des Peers erfolgen, benötigt jedoch kein weiteres Zutun von außen. Zwischen zwei Peers müssen bei
Verwendung einer RTCPeerConnection von beiden Seiten aus Nachrichten
ausgetauscht werden. Ein Verbindungsaufbau ist somit nur über aktives
Handeln auf beiden Seiten und einem zusätzlichen Kanal möglich.
31
Dar. 5.5 – Nachrichtenfluss bei Verbindungsaufbau zwischen Peers
Dargestellt sind hierbei nur die Nachrichten von PeerWeb, für eine umfangreichere Darstellung siehe [W3WR2012].
5.2. Web-Service-Protokoll
Neben der Festlegung des p2p-Protokoll und der somit entstehenden
Netzwerkstruktur, muss auch geklärt werden, wie die Knoten miteinander kommunizieren.
5.2.1. REST
Representational State Transfer (REST) 65 erläutert ein Programmierparadigma zur Erstellung von Web-Services und integriert sich vollständig in HTTP. Über die URL wird hierbei nicht der Web-Service als solches adressiert, sondern eine Ressource. Die durch HTTP verwendeten
Request-Methoden werden interpretiert und auf die Ressource angewendet. Daraus folgt, dass für jede Ressource eine eindeutige URL bereitge-
65
vgl. [FIEL-2000]
32
stellt werden muss, was als Nachteil angesehen werden kann. REST ist
zustandslos, weshalb sämtliche für einen Aufruf benötigte Informationen mit der Anfrage verschickt werden müssen. Weiterhin ist REST plattform- und sprachunabhängig. So kann jederzeit die Kommunikation zu
jedem Teilnehmer erfolgen. Es muss jedoch ein gewisses Vorwissen über
die erreichbaren Ressourcen bestehen. 66
Die Fehlerbehandlung erfolgt über Statuscodes in der Antwort.
5.2.2. WSDL + SOAP
Zur Beschreibung der Schnittstelle eines Webservice kann die Web
Service Description Language (WSDL) 67 verwendet werden. Diese baut
auf XML auf und muss vor der eigentlichen Verwendung des Webservice
abgerufen werden. Aus ihr kann auf Clientseite automatisch ein Stellvertreterobjekt generiert werden. Es werden im Fehlerfall die vom Webservice geworfenen Errors zum Client übertragen und dort wiederum erzeugt. Somit wird kaum zusätzlicher Aufwand zur Implementierung auf
der Clientseite benötigt.
5.2.3. Zusammenfassung und Schlussfolgerung
In dem entstehenden Netzwerk ist die Wahrscheinlichkeit gering,
dass der Sender einer Nachricht direkt mit dem Empfänger verbunden
ist. Weiterhin kann ein rein auf den PeerIDs beruhendes Routing versagen, werden nicht mit den Paketen Informationen mitgeschickt, wenn
ein Paket über einen bestimmten Peer geleitet werden soll. Somit muss
das genutzte Protokoll die Möglichkeit bieten, zusätzliche Informationen
für das Routing zu übertragen. SOAP bietet die Möglichkeit den Header
mit eben solchen Informationen zu füllen, wodurch es als Grundlage für
das verwendete Protokoll in Frage kommt. Zudem kann REST durch die
Verwendung von für jede Ressource eindeutigen URLs nicht umgesetzt
66
67
vgl. [BAYE-2002]
vgl. [WSDL-2001]
33
werden, da die Verbindungen zwischen den Peers nicht den Aufruf verschiedener URL erlauben. Somit sind auch mehrere Service-URLs für die
verschiedenen Aufgabenbereiche 68 des Netzwerkes nicht möglich.
Die Verwendung von WSDL-Dateien zur Beschreibung der Schnittstelle
von Knoten ist nicht möglich, da grundsätzlich bereits die Notwendigkeit
des Abrufes dieser Datei besteht. Eine Verbindung zu einem Teilnehmer
kann jedoch nur durch aktives Handeln auf beiden Seiten aufgebaut werden 69. Da somit bereits eine Kommunikation mit dem Verbindungspartner über einen weiteren Kanal (vermittelnder dritter Peer) vorhanden
sein muss, würden bereits Daten der WSDL zum Abruf eben dieser benötigt. Da jedoch ein Peer-to-Peer-Netzwerk – also ein Netzwerk aus gleichberechtigten Teilnehmern – entstehen soll, ist davon auszugehen, dass
Peer B die gleiche Schnittstelle zur Verfügung stellt wie Peer A. Ausnahmen hiervon können nur bei Versionsunterschieden der auf den Peers
verwendeten Software entstehen. Hierbei muss jedoch Abwärtskompatibilität bestehen. Um solche Versionskonflikte erkennen zu können, sollte
das Protokoll eine Versionsnummer enthalten. Diese darf sich dabei nicht
auf die verwendete Software, sondern muss sich auf das Protokoll beziehen.
Auf Grund der Implementierung im Browser liegt die Verwendung von
JSON (JavaScript Object Notation 70) nahe. Dies hätte besondere Auswirkungen auf die Belastung der Bandbreite, da per JSON verfasste Nachrichten kleiner sind als ihre XML-Pendants. Die Verschiebung zugunsten
der Nutzlast begründet sich darin, dass XML die eigentlichen Werte in
öffnende und schließende Tags einschließt. JSON verwendet dafür nur
den Feldnamen gefolgt von einem Doppelpunkt. Weiterhin können JSONStrings in rund 94% 71 nativ erzeugt bzw. geparst werden. 72
Ein somit passendes Protokoll stellt SOAP Junior da (SOAPjr). Dieses
wird jedoch nicht mehr weiter verfolgt, wodurch nur noch der Eintrag in
der englischsprachigen Wikipedia verfügbar ist 73.
68
Verbindungsebene (z.B. Austausch von Verbindungsinformation), Anwendungsschicht (z.B. Anforderung von Texten, Freundschaftsbeziehungen)
69
siehe vorheriges Kapitel
70
siehe [CROC-2006]
71
vgl. [CANI-2013]
72
siehe auch [NURS-PAUL-REYN-IZUR-2009]
73
vgl. [WSOJ-2012]
34
5.2.4. Umsetzung Netzwerk-Protokoll
Um die verschiedenen Bereiche des Netzwerks getrennt voneinander
behandeln zu können, werden drei Services (Network, Public, Friendship)
adressiert. Technisch gesehen ist die Trennung von Network- und PublicService kontraproduktiv, da ein Peer nur den Netzwerk-Dienst bereitstellen muss, um sich zu verbinden und durch ein Nichtanbieten des Öffentlichen Daten-Dienstes das Netzwerk stört. Da jedoch die Aufgabenbereiche
der Dienste sehr unterschiedlich sind, ist eine Trennung durchaus sinnvoll. Der Dienst zur Abwicklung von Daten, die durch Freundschaften
von Nutzern entstehen, ist davon losgelöst, da er nur einen Nutzer bzw.
dessen Freunde betrifft.
Das Nachrichtenprotokoll baut – wie im vorangegangen Kapitel geschlussfolgert – auf SOAPjr auf. Entsprechend handelt es bei den Nachrichten zwischen den teilnehmenden Knoten um JSON-Strings. Diese sind
in Head und Body unterteilt. Der Kopf beinhaltet dabei Angaben zum adressierten Service und der gewünschten Methode. Weiterhin sind die verwendete Protokollversion, der Absender, ein Zeitstempel, sowie ein pro
Anfrage (die Antwort verwendet den gleichen) zufälliger 160 bits langer
Referenzcode pflicht. Der Referenzcode wird dabei verwendet um Kreise
im Netzwerk zu erkennen 74.
Zusätzlich kann der Kopf enthalten:
• to -> um den Empfänger zu adressieren, sonst gilt der
•
Verbindungspartner als Empfänger; es können mehrere
Empfänger in einem Array definiert werden.
via / sendVia -> genutzt falls das Routingsystem auf Grund
der vorhandenen Verbindungen 75 versagen würde
Die Angabe von mehreren Empfängern eines Pakets hat den Vorteil,
dass es nur einmal versendet werden muss. Dies schont die Bandbreite
und senkt das Nachrichtenaufkommen. Jedoch muss jeder weiterleitende
Knoten prüfen, ob die Nachricht auf Grund der Wege zu den Empfängern
bei ihm geteilt werden muss.
74
vgl. vgl. [XLAT-2010] Kapitel „Protocol / PING“ und [CLAR-SAND-WILEHONG-2001] Kapitel 3; Seite 4
75
durch die Abwärtskompatibilität ist nicht gewährleistet, dass die entstehende
Verbindungsstruktur der gewünschten entspricht.
35
Felder zur Fehlererkennung bei der Übertragung sind nicht notwendig, da diese bereits durch die verwendeten Verbindungsarten berücksichtigt wird 76.
Bei Anfragen enthält der Body der Nachricht die zum Aufruf benötigten Attribute. Antworten enthalten einen Statuscode im Kopf der Nachricht. Dieser Statuscode folgt den von HTTP bekannten Codes. Für PeerWeb sind folgende Codes relevant: 100, 102, 200, 201, 202, 207, 300, 302,
304, 400, 401, 404, 410, 421 (uminterpretiert), 429, 500, 501, 504, 507.
{
“head”: {
“service”: “network”,
“action”: “peerDescription”,
“from”: “10E844530188F910C0EF3ECC4E413D63E
CE79604”,
"refCode": "326435E86B659C7D34D47CA9FC21E1A44
2EB9555",
"date": "1358825257049",
"protocolVersion": "0.1"
},
“body”: {
“peerDescription”: {
“ID”: “10E844530188F910C0EF3ECC4E413D63E
CE79604”,
“ws”: "ws://peerweb.mar-mar.de:8080"
}
}
}
Dar. 5.6 – Beispielnachricht
Hierbei handelt es sich um die Beschreibung eines Superpeers, welche von ihm selber verschickt wurde.
5.2.4.1. Network
Nachrichten dieses Dienstes dienen der Knotenfindung und dem Verbindungsaufbau.
76
vgl. [W3WR-2012] Kapitel 11.1 „DataChannel“
36
5.2.4.1.1. nodeLookup
Die Anfrage enthält die gesuchte ID im Body und wird anhand dieser weitergeleitet. Außerdem wird in dem Body eine Liste der Beschreibungen der nächsten Peers geführt. Diese wird bereits vom anfragenden
Knoten erstellt und von jedem weiterleitenden aktualisiert. Für die Findung der Knoten siehe auch Abschnitt 5.1.5.5.
5.2.4.1.2. peerDescription
Mittels dieser Nachricht wird die Beschreibung eines Peers übermittelt. Diese beinhaltet neben der PeerID Informationen zu Verbindungsmöglichkeiten zu dem Peer. Handelt es sich dabei um einen Superpeer ist
dies seine Websocket-Adresse bzw. die Adresse seiner AJAX-Schnittstelle.
Da RTCPeerConnections nur auf Anfrage erstellt werden, wird für diese
nur ein Binärfeld verwendet. Ist es einem Knoten nicht möglich sich über
eine bestimmte Methode zu verbinden, wird diese nicht in der Beschreibung aufgeführt.
5.2.4.1.3. ringSegmentSearch
Diese Nachricht wird für den finalen Routingschritt verwendet, sollten
keine Superpeers erreichbar sein. Für diese Nachricht gilt ein gesondertes Routing, daher wird ihre Verwendung in dem Abschnitt 5.1.5.6 Routing erklärt.
Ihr Body enthält die ursprüngliche Anfrage und die Beschreibung des
Absenders der ringSegmentSearch-Nachricht – des vermeintlichen Zielknotens.
5.2.4.1.4. pcDescription
Der Versand einer pcDescription-Nachricht markiert den Beginn der
Verbindungsherstellung per RTCPeerConnection. Der Sender hat bereits
ein neues Objekt erzeugt und schickt dem Verbindungspartner die dazugehörige Beschreibung, wodurch er den Wunsch einer direkten Verbindung bekannt gibt.
37
Auf den Empfang einer solchen Nachricht wird durch das Verschicken
einer Response reagiert. Ist eine Verbindung erwünscht, versendet der
Empfänger zusätzlich eine eigene pcDescription-Nachricht.
5.2.4.1.5. iceProcess
Diese Nachricht bildet den zweiten Schritt in der Herstellung einer
p2p-Verbindung zwischen Browsern. Über diese Art von Mitteilung einigen sich die Verbindungspartner auf eine Verbindung. Um analog zu dem
Versand anderer Nachrichten zu bleiben, wird jeweils mit einer Response
geantwortet. Der weitere Austausch geschieht über neue „Anfragen“.
5.2.4.2. Public
Dieser Service dient dem öffentlichen Teil von PeerWeb. Daher beinhaltet er nur das Speichern und Auffinden von Dokumenten.
5.2.4.2.1. valueStore
Diese Nachricht ist zweiteilig angedacht, muss jedoch nicht so umgesetzt werden, um zum Beispiel ein schnelleres Speichern zu ermöglichen.
Der zweite Teil ist dabei von Bedeutung. Zunächst wird an die in Frage
kommenden Peers ein valueStore mit der benötigten Größe geschickt. So
erhalten Knoten die Möglichkeit Daten abzulehnen bzw. ohne zusätzliche Belastung freien Speicher zu schaffen. Dies hat auch den Nebeneffekt,
dass eine unnötige Belastung der Bandbreite vermieden werden kann.
Wird dieser erste Teil positiv beantwortet, wird eine valueStoreNachricht mit dem Dokument als Body geschickt.
5.2.4.2.2 valueManage
Um eine Versionierung mit Versionsgeschichte zu ermöglichen, wird
mit dieser Nachricht dem für die Titel-ID verantwortlichen Peer mitgeteilt, dass eine Änderung vorgenommen wurde und er die Versionszeiger
38
entsprechend anpassen muss. Inhalt dieser Nachricht ist die neue Version-ID und diejenige, auf welche sich die Veränderungen beziehen. Siehe
auch Kapitel 6.1.4.
5.2.4.2.3. valueLookup
Die Nachricht ist analog zu nodeLookup aufgebaut. Sie beinhaltet die ID,
nach der gesucht wird und wird anhand dieser weitergereicht. Sollte auf
dem Weg zum finalen Peer jedoch ein Knoten eine Kopie des Datums im
Cache besitzen, so antwortet er mit dieser. Ist dies nicht gewünscht, kann
ein Flag in der Nachricht gesetzt werden. Siehe auch Kapitel 6.1.6.
5.2.4.3. Friendship
Zwischen befreundeten Nutzern sind besondere Aktionen möglich. Um
diese zu schützen, müssen sich Nutzer bzw. deren Knoten verifizieren.
Werden Anfragen an geschützte Inhalte ohne eine vorherige Anmeldung
verschickt, wird mit dem Fehlercode 401 und der gewünschten Authentifizierungsmethode geantwortet.
5.2.4.3.1. userAuthentication
Über diese Nachricht lässt sich der angemeldete Nutzer eines Knoten
verifizieren. Dem Peer wird ein für den Nutzer verschlüsselter Zufallstring zugesandt. Dieser muss dort entschlüsselt und dem anfragenden
Knoten zurückgeschickt werden.
5.2.4.3.2. humanAuthentication
Um den an einem anderen Gerät angemeldeten Freund ohne Zuhilfenahme eines asymmetrischen Verschlüsselungsverfahren zu bestätigen,
muss dem Nutzer direkt eine Frage gestellt werden. Dabei wird der Body
jeweils verschlüsselt übertragen.
39
5.2.4.3.3. changesRequest
Meldet sich ein Nutzer im Netzwerk an, muss er auch – während seiner Abwesenheit vorgenommene – Änderungen seiner Freunde erhalten.
Diese werden aktiv angefragt. Ist der Body der Anfrage leer, gilt sie für
den mittels des Headers, adressierten Empfänger. Es können jedoch auch
gemeinsame Freunde angegeben werden. Hierzu kann zur Vermeidung
mehrerer Nachrichten ein Array verwendet werden. Weiterhin kann das
Datum des letzten Erhalts von Änderungen mitgeschickt werden, wodurch sich die Antwort potentiell verkleinert.
Unter Änderungen werden auch private Mitteilungen zwischen Nutzern verstanden.
5.2.4.3.4. changesPush
changesPush ist das Gegenstück zu changesRequest. Um den Austausch
von Neuigkeiten schneller zu gestalten, können diese auch aktiv an verbundene Freunde geschickt werden. Hierbei werden einfach die geänderten Daten im Body der Anfrage übertragen.
5.2.4.3.5. valueStore, valueGet & valueDelete
Die Namen der Nachrichten besagen schon ihre Aufgabe. Mit valueStore
werden Daten bei Freunden abgelegt, wobei diese dies auch auf Grund
von mangelndem Speicherplatz verweigern können. Der Speichervorgang erfolgt wie unter 5.2.4.2.1 beschrieben.
Daten können über valueGet wieder erhalten werden. Dabei können
direkt Namen oder IDs von Dateien angegeben werden. Wird der Body
einer solchen Anfrage leer gelassen, antwortet der Knoten hingegen mit
einer Liste von für den Nutzer verfügbaren Daten. Da bei Freunden hinterlegte Dateien einen eindeutigen Besitzer haben, können diese auch gelöscht werden.
40
6. Datenhaltung
Neben der Möglichkeit, direkte Verbindungen zwischen Browserclients aufzubauen, sind die Speichermöglichkeiten durch HTML5 von entscheidender Bedeutung für PeerWeb.
Session Storage
Local Storage
IndexedDB
Filesystem API
• kurzlebige
Knoteninformationen
• PeerID
• Index
• Nutzerdaten
• Einstellungen • Superpeers
• Informationen über
Nachrichten
• STUN/TURNServer
• öffentliche
Dokumente
• Dokumente
von Freunden
• Cache
Dar. 6.1 – Übersicht Speichernutzung in PeerWeb
Dabei bezeichnen kurzlebige Informationen nur für die aktuelle Sitzung relevante Daten. Ebenso werden hier die entschlüsselten Daten des
Nutzers abgelegt, um einen erneuten Zugriff zu beschleunigen. Nachrichteninformationen sind zum einen Daten zu weitergeleiteten Paketen, um
z.B. Ringe zu erkennen. Zum anderen fallen unter sie auch eigene verschickte Nachrichten. Diesen dienen zur Behandlung von Übertragungsfehlern (z.B. durch Time Outs).
Der Index hat nur eine begrenzte Reichweite. Er muss dabei mindestens die auf dem Knoten gespeicherten öffentlichen Dokumente beinhalten, kann aber auch weitere listen. In der Tabelle „Superpeers“ werden
Verbindungsinformationen zu Superpeers gehalten. Diese umfassen die
URL für Websockets und/oder für AJAX. Die ID sollte auch abgelegt sein.
Diese Daten werden gespeichert, da Superpeers für die Einwahl in das
Netzwerk benötigt werden. Zudem sind sie mit hoher Wahrscheinlichkeit
zukünftig erreichbar, was für normale Peers nicht gilt.
Um die Bereiche im Filesystem unterscheiden zu können, wird eine
Ordnerstruktur angelegt. Daten eines Nutzers werden verschlüsselt in einer Datei abgelegt, welche zufällig benannt wird. Dokumente von Freunden des Nutzers werden zusätzlich in Unterordnern organisiert.
41
6.1. Datenhaltung öffentlicher Daten
Daten werden im Netzwerk auf verschiedenen Peers gespeichert. Um
die Ausfallsicherheit zu erhöhen, wird hierfür immer versucht ein Datum auf l 77 Knoten zu verteilen. Die Menge des Speicherplatzes auf den
jeweiligen Knoten kann von ihren Nutzern eingestellt werden.
6.1.1. Datenformat
Die im Netzwerk zu speichernden Daten werden entsprechend ihres
Formats abgelegt. Artikelinhalte können dabei mit HTML-Tags verfasst
werden. Dadurch lässt sich ein späteres Übersetzen in HTML zur Anzeige
einsparen. Jedoch müssen zusätzliche Sicherheitsmaßnahmen, wie die
Löschung möglicherweise eingebetteten JavaScript, eingeführt werden.
Diese sollten vor dem Speichern und Anzeigen durchgeführt werden.
Zudem wird der Inhalt von Artikeln mit zusätzlichen Angaben versehen. Dazu wird JSON verwendet. Das umschließende Objekt enthält Metaangaben wie Versionsnummer, Titel, Kategorie.
6.1.2. Erzeugung von DatenIDs
Die zufällige Erzeugung von DatenIDs bietet kaum Vorteile. So kann
keine Zuordnung zwischen Inhalt bzw. Namen des Datums und der ID
erzeugt werden. Dies ist für verschleierte Inhalte wichtig, da es die Suche erschwert. Somit könnten Inhalte nur über Indexverzeichnisse ihren
IDs zugeordnet werden, es sei denn, die ID nach der gesucht werden soll,
ist anderweitig bekannt. Für eine erleichterte Suche muss die ID eines
Datums jederzeit wieder erzeugt werden können. Dies ist möglich, wenn
die ID abhängig vom Namen erzeugt wird. Das erfordert jedoch hohe
Aufmerksamkeit bei der Wahl des Algorithmus zur Erstellung, da Namen
recht kurz sind, wodurch das verwendete Hash-Verfahren besonders gut
streuen muss. Jedoch hat dies den weiteren Nachteil, dass identische Namen die gleiche ID ergeben. Somit ist auch eine Versionierung nur über
77
siehe 5.1.5.3
42
Umwege möglich. Sollen unterschiedliche Versionen einer Datei zur unterschiedlichen IDs führen, ist das Erzeugen der IDs über den Inhalt ratsam. Dies erschwert jedoch wiederum die Suche.
Generell ist auch die Länge der IDs von Bedeutung. Da IDs nicht zentral erzeugt werden, muss gewährleistet sein, dass sie nicht kollidieren.
Somit haben längere IDs einen Vorteil gegenüber kürzeren, allerdings
führen sie zu zusätzlichem Speicherverbrauch.
In PeerWeb werden Dokumente über zwei Kennungen beschrieben.
So erhalten sie eine Titel-ID und eine Version-ID. Die Titel-ID wird dabei
über den Namen, die Version-ID aus dem Inhalt des Artikels generiert.
Siehe dazu auch Abschnitt 6.1.4.
6.1.3. Datenverteilung
Werden Artikel beliebig im Netzwerk verteilt, verringert sich die Wahrscheinlichkeit sie (effektiv) zu finden signifikant, da Anfragen nicht gerichtet weitergeleitet werden können. Jedoch stellt es die einfachste Möglichkeit zur Datenhaltung dar. Lässt man aber die Spezialisierung von
Knoten – in Verbindung mit einem entsprechenden Routing – zu, lässt
sich die Wahrscheinlichkeit erhöhen, Daten in einem solchen Netzwerk
wiederzufinden. Jedoch muss dann die Routing-Tabelle Informationen zu
den von Nachbarn (wahrscheinlich) verwalteten Schlüsseln beinhalten 78.
Wesentlich effektiver ist die Verwendung einer verteilten Hash-Tabelle, wie sie bereits in Kapitel 5.1.2 beschrieben ist. Hier werden Daten auf
Knoten verteilt, deren ID nahe zu der eigenen ist. Um die Ausfallsicherheit
zu erhöhen, werden zudem mehrere nahe Peers dafür gewählt. Dies hat
den Vorteil, dass Anfragen nur mit dem Wissen der IDs von benachbarten Knoten an das potentielle Ziel weitergeleitet werden können. Nachteil
dieser Methode ist jedoch, dass der Speicherort von unliebsamen Inhalten ebenso bekannt ist. Eine Zensur wird somit erleichtert. Dies wird für
die Effizienz des Netzwerks in Kauf genommen.
78
vgl. [CLAR-SAND-WILE-HONG-2001] Kapitel 3.2
43
Weiterhin wird ein Datum nicht nur auf einen Peer verteilt, sondern
auf die l 79 gerade zu der ID nächsten Peers. Der Speichervorgang wird
etwa eine Stunde nach der letzten Speichernachricht von einem dieser
Knoten erneut ausgelöst 80. Somit ist die Anzahl der speichernden Peers
nahezu gesichert.
6.1.4. Datenversionierung
Durch die Verwendung von zwei Schlüsseln für einen Artikel ist eine
Versionierung relativ einfach umsetzbar. Wird ein Dokument gesucht,
kann über dessen Titel-ID der Speicherort bestimmt werden. An diesem
wird nicht der Artikel hinterlegt, sondern nur die ID der aktuellen Version. Diese wird dem Anfragenden zurückgegeben, welcher diese Variante
lädt.
Möchte ein Nutzer ein Dokument ändern, lädt er zunächst die aktuelle Version. An dieser führt er die gewünschten Änderungen durch und
speichert das Dokument. Dabei wird über den jetzigen Inhalt eine neue
Version-ID generiert. An die für diese ID zugehörigen Knoten wird eine
Nachricht zum Speichern des Dokumentes geschickt. Da noch die Änderungen bekannt gegeben werden müssen, damit zukünftige Anfragen an
das Dokument mit der neuen Version beantwortet werden, wird gleichzeitig eine Nachricht (valueManage) an den für die Titel-ID zuständigen
Peer „Master“ genannt) geschickt. Diese beinhaltet die sich durch die Änderung ergebene Version-ID und die ID der Version, auf deren Grundlage
die Änderungen passierten. Der verantwortliche Peer ist hierbei der jeweils (einzelne) an der Titel-ID nächste Peer.
Der Empfänger der Nachricht prüft, ob er wirklich der für die Titel-ID
zuständige Knoten ist. Hierzu verwendet dieser den Algorithmus zur Suche von Knoten. Ist er dies, kann er Änderungen ablehnen, in dem er die
„alte“ Version-ID gegen die für ihn noch aktuelle Version-ID prüft. Sind
diese unterschiedlich wird die neue Version nicht übernommen. Um Dokumente vor missbräuchlichen Änderungen zu schützen werden die letzten drei Versionen referenziert.
79
80
in PeerWeb gilt l = 6, siehe 5.1.5.3
vgl. [MAYM-MAZI-2002] Kapitel 2.5 „Efficent key re-publishing“
44
Dar. 6.2 – Nachrichtenaufkommen bei Änderung eines Dokuments
Peer 18804C ändert dabei das Dokument mit der Titel-ID 8E4446 zu Version 40E1BE. Die folgenden Nachrichten
werden dabei verwendet: 1 – valueStore, 2 – valueManage (an Master für die Titel-ID), 3 – valueManage (von Master an Replikate der Versionsgeschichte). Die mit 2A gekennzeichneten Verbindungen stehen für ein alternatives
Routing, welches verwendet werden würde, wenn keine Superpeers vorhanden wären. Weiterhin wurden nur
Verbindungen aus dem Leaf-Set und zu Superpeers berücksichtigt.
Bei Annahme der Änderung propagiert der Master diese, wie bei einem normalen Speichervorgang, an weitere Peers, welche seine Nachbarn sein werden. Hierzu wird ebenso eine valueManage-Nachricht benutzt. Die Empfänger prüfen ebenso die Zuständigkeit, erkennen jedoch,
dass sie nur ein Replikat der Versionshistorie führen und übernehmen
somit die Änderungen.
45
6.1.5. Speichermanagement
Um Speicherplatz zu schonen, können Daten mit Verfallsdatum versehen werden. Wird dieses erreicht, wird die dazugehörige Datei automatisch gelöscht. Zudem können Dokumente priorisiert werden. Dies soll
erreichen, dass bei knappen Speicher auf einem Peer, dieser zunächst weniger wichtige Daten, wie alte Versionen, löscht.
Weiterhin hat der Knoten selber die Möglichkeit eine Priorisierung
durchzuführen. Hierfür werden die Daten anhand der Entfernung ihrer
(Titel oder Version) ID zu der Peer-ID sortiert. Je weiter ein Datum hierbei
entfernt ist, desto wahrscheinlicher ist seine Löschung. Dies begründet
sich darin, dass mit zunehmender Entfernung zu diesem Peer die Entfernung zu einem anderen Peer sinkt, welcher somit selbiges Datum eher
behält.
Kommt es zum Fall einer Löschung, wird zunächst versucht, das Datum erneut zu verteilen. Weiterhin merkt sich der Peer, dass er das Dokument bereits in Besitz hatte, es also potentiell noch im Netzwerk vorhanden ist. Diese Liste von verdrängten Daten ist wichtig zur Beantwortung
temporär nicht vorhandener Daten.
6.1.6. Suche
Werden die IDs der Artikel über ihre Titel generiert und nach der ID im
Netzwerk abgelegt, ist eine Suche zumindest nach vollständig bekannten Titeln einfach und effizient. Die Suche nach Artikeln, deren Titel nur
zu einem Teil bekannt ist, bleibt jedoch erschwert. Um dieses Problem
zu verringern, werden in Artikeln auch Verweise zu anderen Artikeln
gespeichert. So ist es möglich über ähnliche Artikel auf einen bestimmten zu stoßen. Zudem führt jeder Peer eine Liste mit Zuordnungen von
Namen zu IDs. Diese wird beiläufig, zum Beispiel durch weitergeleitete
Dokumente, aufgebaut. Eine Suche nach Fragmenten eines Titels wäre so
durch ein teilweises Fluten des Netzwerks möglich. Da auch hier Super-
46
Dar. 6.3 – Nachrichtenfluss bei Anforderung eines Dokuments
Hierbei fordert Peer DC1DE7 das Dokument mit der Titel-ID 8E4446 an (1 – valueLookup). Er erhält die Antwort,
dass die aktuelle Version unter die ID 40E1BE besitzt. Daraufhin wird per (2) valueLookup eine Anfrage nach
dieser ID gestellt.
peers mit hoher Wahrscheinlichkeit mehr Speicher zu Verfügung stellen,
ist die Wahrscheinlichkeit der Beantwortung einer Anfrage durch sie
recht hoch.
Ist die gesuchte ID bekannt, wird die Anfrage, wie in Kapitel 5.1.5.6 beschrieben, weitergereicht. Kann der finale Knoten die Suche nicht beantworten, kommt die im vorherigen Abschnitt vorgestellte Liste verdrängter Daten ins Spiel. Falls kein Eintrag in ihr für die gesuchte ID vorhanden
ist, ist die Wahrscheinlichkeit, dass es das gesuchte Datum gibt, recht gering. Somit wird eine 404-„Not Found“-Nachricht zurückgeschickt. Wenn
hingegen ein Eintrag zu der angefragten ID vorhanden ist, wird der anfragende Peer gemerkt und zunächst mit einer 202-„Accepted“-Nachricht
geantwortet. Somit wird die Anfrage für eine Woche gespeichert. Sollte
in dieser Zeit Traffic über den Knoten laufen, der auf den Speicherort
des angefragten Dokumentes hinweist, wird die Anfrage entsprechend
47
beantwortet. Dies geschieht in dem Fall mit einer 302-„Found“-Nachricht.
Kann die Anfrage nach Ablauf der Woche nicht beantwortet werden,
wird 410-„Gone“ versendet.
Der Eintrag zum verdrängten Dokument wird eine Woche nach der
letzten Nachricht mit Bezug auf dieses Dokument gelöscht.
6.1.7. Cache
Die Verwendung von Caching-Funktionen kann die Geschwindigkeit
enorm erhöhen. So können Anfragen eventuell schon vor dem Erreichen
des eigentlichen Speicherortes eines Datum beantwortet werden. Da so
auch weniger Nachrichten notwendig sind, verringert sich auch die Last
auf das Netzwerk. Ein weiterer Vorteil ist die zusätzliche Speicherung
von Daten innerhalb des Netzwerkes. Ist der für ein Datum eigentlich zuständige Knoten nicht erreichbar, ist die Verfügbarkeit des Datums zwar
nicht zwangsläufig gegeben, sie erhöht sich jedoch.
Es ergeben sich aber auch Nachteile. So muss potentiell mehr Speicher
zur Verfügung gestellt werden. Auch entspricht die zurückgegebene Version einer Information nicht unbedingt der aktuellen Version. Lösungen
für dieses Problem sind immer mit zusätzlichem Nachrichtenaufwand
verbunden. Eine Invalidierung der im Cache befindlichen Kopien durch
den zuständigen Peer 81 ist dabei nur über ein Fluten des Netzwerks möglich, da Kopien nicht lokalisiert werden können. Die Verwendung von
versionierten Caches kann auch nicht garantieren, dass veraltete Versionen erkannt werden.
Weiterhin ergeben sich zusätzliche Fragen zum Umgang mit vollen
Caches. Hier stehen mehrere Lösungen parat. Die einfachste ist das Löschen eines zufälligen Datums, da sie kein Speichern von zusätzlichen
Informationen, wie Anfragestatistiken, benötigt. Dies kann jedoch bei
populären Inhalten dazu führen, dass dasselbe Datum sofort wieder angefragt wird. Somit geht der Vorteil der höheren Geschwindigkeit bei Anfragen unter Umständen verloren. Auf der anderen Seite kann es die Verfügbarkeit von selten angefragten Dokumenten erhöhen.
81
Peer der das Datum ändert oder auf dem das Datum gespeichert ist
48
Die Löschung des am längsten nicht verwendeten Datums (least recently used – LRU) benötigt nur wenig zusätzlichen Speicheraufwand.
Dieses Verfahren bietet jedoch nicht optimale Resultate, da es nicht die
Zugriffshäufigkeit beachtet. Das LFU-Verfahren (least frequently used –
am wenigsten verwendet) berücksichtigt hingegen die Anzahl von Zugriffen. Es beinhaltet den Nachteil, dass Daten mit einem einmalig hohem Anfrageaufkommen lange im Cache verbleiben.
Durch die Struktur des Netzwerkes ergibt sich zudem eine weitere Verdrängungsstrategie. So kann die Entfernung des im Cache befindlichen
Datums zur eigenen ID betrachtet werden. Das so am weitesten entfernte
Datum wird gelöscht. Dies bietet den Vorteil, dass die Wahrscheinlichkeit
einer Anfrage nach eben diesem Datum an diesen Peer berücksichtigt
wird.
PeerWeb verwendet eine Kombination aus Entfernung, dem letzten Zugriff und der Zugriffshäufigkeit. Wobei die Wahrscheinlichkeit die sich
aus dem Zeitpunkt des letzten Zugriffs ergibt, den Faktor zwei erhält.
6.2. Datenhaltung privater Daten
Der Speicherort für private und sensible Daten ist nicht diskussionswürdig, da er besonders geschützt werden muss und somit bei vertrauenswürdigen Personen liegen sollte. Nun sind dennoch nicht alle privaten
Daten gleich schützenswert. So ist es sogar von Vorteil, wenn die Liste der
Freunde von Person A für dessen Freund Person B einsehbar ist. Dadurch
entsteht die Möglichkeit, dass beide sich auch Nachrichten schicken können, wenn der andere offline ist und diese dennoch bei vertrauenswürdigen Personen zwischengelagert werden sollen.
Die Einordnung der Profil- und sonstigen Daten nach Sicherheitsbedarf, wird dabei dem Nutzer überlassen, ebenso die Quantität des Speicherplatzes für Freunde. Zur Einstellung der Sicherheit der Daten stehen
folgende Optionen zu Auswahl:
• von Freunden einsehbar
• nur vom Besitzer einsehbar – im Ganzen
bei Freunden gespeichert
• nur vom Besitzer einsehbar – in mehrere Teile geteilt
49
Eine von den Daten abhängige Klassifizierung der Freunde nach vertrauenswürdig / nicht vertrauenswürdig (Freund A darf Datum I speichern, aber Datum II nicht) ist zunächst nicht vorgesehen. Eine generelle
Einteilung in Zusammenhang mit den vorgestellten Sicherheitsklassen
von Daten ist jedoch ohne weiteres umsetzbar.
7. Freundschaften
Da Personen in Netzwerken organisiert sind, liegt es nahe, dass PeerWeb auch Verbindungen zwischen Menschen unterstützt. Um die Entstehung von Freundschaftsbeziehungen in PeerWeb für das System einfach
und dennoch sehr sicher zu gestalten, werden diese über einen vom Nutzer gewählten Weg außerhalb von PeerWeb geschlossen. Dazu tauschen
die Freunde ihre öffentlichen Schlüssel sowie eine Liste von Knoten, welche sie benutzen, aus. Dieser Austausch kann über E-Mail oder andere
Kanäle erfolgen. Auch ein Austausch über bereits gemeinsame Freunde
wäre denkbar.
7.1. Einwahl von anderem Rechner
Eine Einwahl in das Netzwerk beschreibt den Vorgang, dass sich ein
Nutzer anmeldet. Die Einwahl für den dafür benutzten Knoten ändert
sich nicht. Der einfachste Weg ist die Mitnahme der Nutzerdaten von einem Knoten zum anderen. Hierfür kann eine verschlüsselte Datei dienen,
welche an Knoten A erzeugt wird und über E-Mail oder einen USB-Stick
zu Knoten B gelangt, wo sie eingelesen wird. Dies stellt jedoch Mehraufwand für den Nutzer da. Bequemer wäre es, wenn er sich, wie von anderen Netzwerken gewohnt, ohne diese Datei von jedem beliebigen Rechner aus anmelden könnte. Ein solcher Vorgang würde die Akzeptanz des
Netzwerks fördern 82.
82
Annahme des Verfassers
50
Das Prinzip hierzu fußt auf der Tatsache, dass auch verschlüsselte Dokumente in dem öffentlichen Teil von PeerWeb abgelegt werden können.
Da aber somit wichtige Daten bei Fremden abgelegt werden, muss der
Nutzer diesem Verfahren aktiv zustimmen. Über die Logindaten des Nutzers (Name und Passwort) wird ein symmetrischer Schlüssel sowie eine
ID erzeugt. Nun werden die für die Verbindungserzeugung zu Freunden
benötigten Daten symmetrisch verschlüsselt. Die so erhaltene Datei wird
unter der erzeugten ID im Netzwerk abgelegt. Zudem erhalten die Freunde weitere Teile der Nutzerdaten, wie auch den privaten Schlüssel des
Nutzers. Da diese Daten zum Identitätsdiebstahl einladen, werden sie,
unabhängig von dem Vertrauen des Nutzers in seine Freunde, über die
sicherste Methode an diese verteilt.
Möchte sich nun der Nutzer A von einem anderen Rechner aus anmelden, kann der Speicherort der Daten und der dazugehörige Schlüssel rekonstruiert werden. Somit können Verbindungen zu Freunden aufgebaut
werden. Da aber der Nutzer seinen privaten Schlüssel nicht besitzt, kann
er nicht automatisiert von seinen Freunden verifiziert werden. Daher
wird zwischen einem Freund B und A eine gesicherte Verbindung aufgebaut. Dies könnte bei direkten Verbindungen zum Beispiel mittels DiffieHellman-Verfahren geschehen. Anschließend werden ein oder mehrere
– je nach Einstellungen – vom Freund (bzw. dessen Knoten) ausgewählte
Nachrichten an A geschickt. Diese muss A korrekt beantworten. Ist so die
Identität des Nutzers bestätigt, erhält dieser den bei B gespeicherten Teil
seiner Daten. Dieses Verfahren wird so lange mit weiteren Freunden wiederholt, bis die Mindestanzahl zur Wiederherstellung der Daten erreicht
ist.
7.2. Suche nach eingeloggten Freunden
Um die Suche nach Freunden zu erleichtern, werden Freunde mit Knoten assoziiert. Geht ein Benutzer A online, so sucht er nicht direkt nach
seinen Freunden (diese müssen bereits online sein), sondern nach Knoten, von denen sich die Freunde bereits einmal angemeldet haben. Wird
ein solcher Knoten gefunden, wird der dort angemeldete Nutzer B verifiziert. Hierzu wird ein zufälliger String mit dem öffentlichen Schlüssel
51
des potentiellen Freundes B verschlüsselt und dem Knoten zugesandt. Ist
der Freund dort wirklich angemeldet, kann diese Nachricht entschlüsselt
werden. Der Zufallsstring wird mit dem öffentlichen Schlüssel des Initiators A verschlüsselt und zurückgeschickt.
Dieser Prozess funktioniert jedoch nicht, wenn beide Freunde an dem
jeweils anderen unbekannten Knoten angemeldet sind. Ist hingegen der
Nutzer an einem für Freunde neuen Peer angemeldet, muss er lediglich
den Vorgang regelmäßig durchführen.
Für die Sicherheit des Verfahrens ist es von Vorteil, wenn Freunde ihren Freunden mitteilen, wie vertrauensvoll der Knoten ist, von dem sie
sich gerade angemeldet haben. Weiterhin ist es von Vorteil, Freunde davon zu unterrichten, dass der Nutzer sich nicht ein weiteres Mal von diesen Knoten aus anmelden wird. Beide Fälle werden von Freunden gleichbehandelt, indem sie die PeerID nicht mit dem Freund verbinden.
8. Fazit und Ausblick
Die vorliegende Arbeit zeigt, dass Peer-to-Peer-Netzwerke im Browser
mittlerweile möglich sind, auch wenn sie einige Anpassungen benötigen
und bei möglichst hoher Kompatibilität sehr komplex werden. Allerdings
kann auch heute noch nicht vollständig auf einen Server verzichtet werden, da dieser für die Einwahl benötigt wird.
Im Rahmen dieser Arbeit wurde bereits ein Teil umgesetzt, dieser befindet sich auf der CD im Anhang und umfasst das Speichern und Wiederaufrufen von Dokumenten im Netzwerk. Auch das Routing ist bereits
umgesetzt.
Das Programm PeerWeb soll zunächst weiter umgesetzt werden, bis
eine erste Version, nach den hier vorgestellten Funktionen fertig gestellt
ist. Hierzu ist ein Team von drei bis vier Personen angedacht. Anschließend ist eine Lizenzierung unter einer Open-Source-Lizenz geplant. Ab
diesem Zeitpunkt könnte die Entwicklung für Interessierte geöffnet werden. Bis dahin muss auch der Arbeitstitel PeerWeb geändert werden, da
dieser bereits belegt ist.
52
8.1. Sicherheit & Anonymität
Die bisherige Arbeit an PeerWeb hatte ein leicht benutzbares, stabiles sowie effizientes System als Ziel. Die Sicherheit und auch Anonymität wurde hierbei weniger berücksichtigt, eine spätere Implementierung
von bekannten Verfahren jedoch bedacht. Dennoch müssen an einigen
Stellen gesonderte Überlegungen angestellt werden.
8.1.1. Onion-Routing
Ein leicht umsetzbarer Sicherheitsaspekt ist die Verschleierung von
Absender, Empfänger und Inhalt von Nachrichten. Um dies zu integrieren werden nur noch öffentliche und private Schlüssel (z.B. durch RSA)
für Knoten benötigt 83. Würde Onion-Routing verwendet, ließe sich die
Peer-ID über den öffentlichen Schlüssel generieren.
8.1.2. Herkunft von Dokumenten
Noch ist für den Leser der Autor eines Artikels nicht ersichtlich. Es
könnten jedoch Artikel mit Identitäten unterschrieben werden. Hierzu
können die durch das Onion-Routing benötigten Schlüssel verwendet
werden. Da somit nur der ausstellende Knoten bekannt ist nicht aber der
Nutzer, ist eine digitale Unterschrift durch den Nutzer sinnvoller. Dadurch wird allerdings seine Identität auch für Nicht-Freunde bekannt.
Hier ist daher noch Raum für Überlegungen zu einer sinnvollen Kombination zweier Identitäten eines Nutzers – einer für Freunde und eine zum
Erstellen von Dokumenten.
83
vgl. [MAHL-SCHI-2007] Kapitel 11.2; Seite 214 – „Onion Routing“
53
8.2. Steigerung Nutzerakzeptanz
Mittels eines besonders gestellten Peers, welcher schon als Server bezeichnet werden kann, ließe sich die Akzeptanz des durchschnittlichen
Nutzers sicher steigern.
8.2.1. Suchmaschinen
Da die Suchmaschine Google bei ihrer Indexierung kein JavaScript berücksichtigt, kann der Inhalt von PeerWeb nicht erfasst werden. Dies ist
zwar auf der einen Seite eine einfache Möglichkeit die Schwierigkeit versteckte Daten zu finden hoch zu halten, auf der anderen Seite geht somit
aber ein großes Nutzeraufkommen verloren. Gäbe es einen Server, der
dem Googlebot die Daten zur Verfügung stellt, werden automatisch mehr
Nutzer erreicht. Dies begründet sich in den dadurch möglichen Zufallstreffern.
Weiterhin würde diese Vorgehensweise die Suche nach Artikeln deutlich vereinfachen, da der Marktführer hierfür benutzt werden kann. Somit läge jederzeit ein komplettes Verzeichnis der Daten bereit.
Natürlich dürften Nutzer die Daten nicht vom Server laden, sondern
würden diese über das Netzwerk erhalten.
8.2.2. Import von Daten
Eine einfache Möglichkeit den potentiellen Nutzern den Umzug zu
PeerWeb zu erleichtern ist ein automatischer Import seiner Daten von
anderen sozialen Netzwerken. Da Facebook eine offene API hat, muss der
Nutzer nur diesen Vorgang bei PeerWeb anstoßen und den Zugriff auf
seine Daten bei Facebook bestätigen. Wie sicher jedoch eine solche Vorgehensweise ist, muss geklärt werden. Ungeklärt ist außerdem ob dieser
Vorgang auch ohne Server funktioniert.
54
8.3. weitere Verbesserungen
Mittels der in 6.1.4 vorgestellten Methode zur Versionsverwaltung
könnten auch Änderungen zurückgenommen werden, wenn diese als
nachteilig empfunden werden. So bräuchte der „Master“ nur entsprechende Nachrichten der Nutzer zählen. Hat die Anzahl eine bestimmte
Masse erreicht, wird die Änderung zurückgenommen. Auch ein System
aus gut/schlecht Bewertungen 84 könnte herangezogen werden. Dies hätte
den Vorteil, dass nicht nur negative Äußerungen berücksichtigt werden.
Ebenso ist eine Kommentar-/Diskussionsmöglichkeit umsetzbar, ohne
dass eine Änderung des Artikels deren Inhalt löscht.
84
analog zu Bewertungen von Videos bei YouTube
55
I Literaturverzeichnis
[ADFL-2007]
livedocs.adobe.com: „Externalinterface“, Adobe, 12. Oktober 2007, siehe: http://livedocs.adobe.com/flash/9.0_de/ActionScriptLangRefV3/flash/external/ExternalInterface.html (letzter
Zugriff: 12.01.2013)
[ADOB-2010]
Jozsef Vass: „Cirrus service for developing endto-end applications using RTMFP in FLash Player 10“, Adobe, 1. Juni
2011, siehe: http://www.adobe.com/devnet/flashplayer/articles/rtmfp_
cirrus_app.html (letzter Zugriff: 13.01.2013)
[BAYE-2002]
Thomas Bayer: „REST Web Services Eine Einführung“, Orientation in Objects, 27. November 2002, siehe: http://www.
oio.de/public/xml/rest-webservices.pdf (letzter Zugriff: 12.01.2013)
[BERN-1990]
Tim Berners-Lee: “Information Management:
A Proposal“, CERN, Mai 1990, siehe: http://www.w3.org/History/1989/
proposal.html (letzter Zugriff: 12.01.2013)
[BERN-CONN-1993]
Tim Berners-Lee, Daniel Connolly: „Hypertext
Markup Language (HTML)“, IETF, Juni 1993, siehe: http://www.w3.org/
MarkUp/draft-ietf-iiir-html-01.txt (letzter Zugriff: 12.01.2013)
[BIDE-2011]
Eric Bidelman: „A Beginner’s Guide to Using the
Application Cache“, HTML5 Rocks, 27. Mai 2011, siehe: http://www.
html5rocks.com/en/tutorials/appcache/beginner/ (letzter Zugriff:
12.01.2013)
[BUSH-1945]
Vannevar Bush: „As We May Think“, in: „the Atlantic“, Juli 1945; siehe: http://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/2/?single_page=true (letzter Zugriff: 12.01.2013)
[CANI-2013]
12.01.2013)
siehe:
http://caniuse.com/
(letzter
Zugriff:
[CLAR-SAND-WILE-HONG-2001]
Ian Clarke, Oskar Sandberg, Brandon Wiley, Theodore W. Hong: „Freenet: A Distributed Anonymous Information Storage and Retrieval System“, 2001, siehe: http://homepage.
cs.uiowa.edu/~ghosh/freenet.pdf (letzter Zugriff: 12.01.2013)
56
[CROC-2006]
D. Crockford, „The application/json Media Type
for JavaScript Object Notation (JSON)“, IETF, Juli 2006, siehe: https://
tools.ietf.org/html/rfc4627 (letzter Zugriff: 12.01.2013)
[CROS-WALL-2007]
Scott A. Crosby, Dan S. Wallach: „An Analysis
of BitTorrents’s Two Kademlia-Based DHTs“, Department of Computer Science, Rice University, Juni 2007, siehe: http://www.cs.rice.
edu/~scrosby/tr/BTMeasure-Main.pdf (letzter Zugriff: 12.01.2013)
[DUTT-2012]
Sam Dutton, „Getting Started with WebRTC“,
HTML5 Rocks, 23. Juli 2012, siehe: http://www.html5rocks.com/en/tutorials/webrtc/basics/ (letzter Zugriff: 12.01.2013)
[FIEL-2000]
Roy Thomas Fielding: „Architectural Styles and
the Design of Network-based Software Architectures“, 2000, siehe:
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_
dissertation_2up.pdf (letzter Zugriff: 12.01.2013)
[FIRE-2006]lxr.mozilla.org:
„mozilla/dom/src/storage/nsDOMStorage.cpp“, Mozilla, siehe: http://lxr.mozilla.org/mozilla/source/dom/src/storage/nsDOMStorage.cpp (letzter Zugriff: 12.01.2013)
[FREE-2012]
freenetproject.org: „Freenet Frequently Asked
Questions“, siehe: https://freenetproject.org/faq.html (letzter Zugriff:
12.01.2013)
[GOLZ-2000]
Karl-Heinz Golzio: „Basiswissen Judentum“, Gütersloher Verlagshaus, 2000, 2. Auflage
[GOOG-2012]
developers.google.com: „Managing HTML5 Offline Storage“, siehe: https://developers.google.com/chrome/whitepapers/storage (letzter Zugriff: 12.01.2013)
[IDBS-2012]
N. Parashuram: „IndexedDBShim“, siehe: https://
github.com/axemclion/IndexedDBShim (letzter Zugriff: 12.01.2013)
[IETF-2011]
A. Barth, U. C. Berkeley: „HTTP State Management Mechanism“, IETF, April 2011, siehe: https://tools.ietf.org/html/
rfc6265 (letzter Zugriff: 12.01.2013)
[MAHL-SCHI-2007]
Peter Mahlmann,
„Peer-to-Peer-Netzwerke“, Springer, 2007
Christian
Schindelhauer:
57
[MAYM-MAZI-2002]
Petar Maymaounkov, David Mazières: „Kademlia: A Peer-to-peer Information System Based on the XOR Metric“, in:
Peter Druschel, Frans Kaashoek, Antony Rowstron, „Workshop Report
for IPTPS’02 1st International Workshop on Peer-to-Peer Systems 7–8
March 2002 — MIT Faculty Club, Cambridge, MA, USA“, Springer, 2002,
Seite 53-65; siehe auch: http://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf (letzter Zugriff: 12.01.2013)
[MBID-2012]
developer.mozilla.org: „Basic Concepts About
IndexedDB“, Mozilla Developer Network, 26. Dezember 2012, siehe:
https://developer.mozilla.org/en-US/docs/IndexedDB/Basic_Concepts_
Behind_IndexedDB (letzter Zugriff: 12.01.2013)
[MFAP-2012]
developer.mozilla.org: „File System API“, Mozilla Developer Network, 14. März 2012, siehe: https://developer.mozilla.org/en-US/docs/DOM/File_API/File_System_API (letzter Zugriff:
12.01.2013)
[MIDB-2013]
developer.mozilla.org: „IndexedDB“, Mozilla Developer Network, 4. Januar 2012, siehe: https://developer.mozilla.org/
en-US/docs/IndexedDB (letzter Zugriff: 12.01.2013)
[MINT-2011]
te 42 f., Heise
Stefan Mintert: „Fünf Viertel“, ix, Juni 2011, Sei-
[MSDN-2012]
msdn.microsoft.com: „Introduction to Web Storage (Internet Explorer)“, Microsoft, 26. Oktober 2012, siehe: http://
msdn.microsoft.com/en-us/library/cc197062(VS.85).aspx (letzter Zugriff: 12.01.2013)
[NELS-1965]
faculty.vassar.edu: „Ted nelson regarding “hyper-text“ 1965“, http://faculty.vassar.edu/mijoyce/Ted_sed.html (letzter Zugriff: 12.01.2013)
[NURS-PAUL-REYN-IZUR-2009]Nurzhan Nurseitov, Michael Paulson, Randall Reynolds, Clemente Izurieta: „Comparison of JSON and XML Data
Interchange Formats: A Case Study“, ISCA 22nd International Conference on Computer Applications in Industry and Engineering, CAINE
‘09, San Francisco, CA, November 2009, siehe: http://www.cs.montana.
edu/izurieta/pubs/caine2009.pdf (letzter Zugriff: 12.01.2013)
58
[OPER-2012]
Shwetank Dixit: „Web Storage: easier, more powerful client-side data storage“, Opera, 5. März 2012, siehe: http://dev.
opera.com/articles/view/web-storage/ (letzter Zugriff: 12.01.2013)
[PILG-2011]
Mark Pilgrim: „Dive Into HTML5“, 2011, siehe:
http://diveintohtml5.info/storage.html (letzter Zugriff 12.01.2013)
[ROWS-DRUS-2001]
Antony Rowstron, Peter Druschel: „Pastry:
Scalable, decentralized object location and routing for large-scale
peer-to-peer systems“, IFIP/ACM International Conference on Distributed Systems Platforms (Middleware), Heidelberg, Germany, Seite
329-350, November 2001; siehe auch: http://www.freepastry.org/PAST/
pastry.pdf (letzter Zugriff: 12.01.2013)
[STAT-2010]
Statista: „Anteil installierter Plug-ins in Browsern in Deutschland (Stand: Dezember 2010)“, Statista, 1. Dezember 2010, siehe: http://de.statista.com/statistik/daten/studie/36626/
umfrage/anteil-installierter-plug-ins-in-browsern/ (letzter Zugriff:
12.01.2013)
[STAT-2011]
Statista: „Anteil installierter Plug-ins in Browsern im Januar 2011“, Statista, 18. Januar 2011, siehe: http://de.statista.
com/statistik/daten/studie/152142/umfrage/anteil-installierter-plugins-in-browsern/ (letzter Zugriff: 12.01.2013)
[TNSF-2010]
TNS: „Digital Life“, TNS, Dezember 2010, siehe:
http://2010.tnsdigitallife.com/ (dargestellt im Flash-Objekt am Anfang
der Seite) (letzter Zugriff: 12.01.2013)
[UDEM-2012]
Udemy: „Code Wars: Ruby vs Python vs PHP
[Infographic]“, Udemy, 16. November 2012, siehe: http://www.udemy.
com/blog/modern-language-wars/ (letzter Zugriff: 16.01.2013)
[W3FA-2012]
Eric Uhrhane: „File API: Directories and System“, W3C, 17. April 2012, siehe: http://www.w3.org/TR/file-systemapi/ (letzter Zugriff: 12.01.2013)
[W3HI-2000]
www.w3.org: „A Little History of the World Wide
Web“, http://www.w3.org/History.html (letzter Zugriff: 12.01.2013)
[W3HT-1997]
W3C: „HTML 3.2 Reference Specification“, W3C,
14. Januar 1997, siehe: http://www.w3.org/TR/REC-html32-19970114
(letzter Zugriff: 12.01.2013)
59
[W3HT-2012]
Robin Berjon, Trevis Leithead, Erika Doyle Navara, Edward O’Connor, Silvia Pfeiffer: „HTML5“, W3C, 17. Dezember
2012, siehe: http://www.w3.org/TR/html5/ (letzter Zugriff 12.01.2013)
[W3ID-2012]
Nikunj Mehta, Jonas Sicking, Eliot Graff, Andrei
Popescu, Jeremy Orlow: „Indexed Database API“, W3C, 24. Mai 2012,
siehe: http://www.w3.org/TR/IndexedDB/ (letzter Zugriff: 12.01.2013)
[W3ST-2011]
Ian Hickson: „Web Storage“, W3C, 8. Dezember 2011, siehe: http://www.w3.org/TR/webstorage/ (letzter Zugriff:
12.01.2013)
[W3WD-2010]
Ian Hickson: „Web SQL Database“, W3C, 18. November 2010, siehe: http://www.w3.org/TR/webdatabase/ (letzter Zugriff: 12.01.2013)
[W3WR-2012]
Adam Bergkvist, Daniel C. Burnett, Cullen Jennings, Anant Narayanan: „WebRTC 1.0: Real-time Communication Between Browsers“, W3C, 21. August 2012, siehe: http://www.w3.org/TR/
webrtc/ (letzter Zugriff: 12.01.2013)
[WEBH-2013]
WebHits: „Web-Barometer“, WebHits, siehe:
http://www.webhits.de/deutsch/index.shtml?webstats.html (Zugriff
am 19.11.2012 und 09.01.2013)
[WHAT-2013]
WHATWG: „HTML“, WHATWG, siehe: http://
www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html (letzter Zugriff: 12.01.2013)
[WSDL-2001]
Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana: „Web Service Description Language
(WSDL) 1.1“, W3C, 15. März 2001, siehe: http://www.w3.org/TR/wsdl
(letzter Zugriff: 12.01.2013)
[WSOJ-2012]
wikipedia.org: „SOAPjr“, Wikipedia, 5. April
2012, siehe: https://en.wikipedia.org/wiki/SOAPjr (letzter Zugriff:
12.01.2013)
[XLAT-2010]
XLattice, „Kademlia: A Design Specification“,
XLattice, 13. Februar 2010, siehe: http://xlattice.sourceforge.net/components/protocol/kademlia/specs.pdf (letzter Zugriff: 12.01.2013)
60
II Darstellungsverzeichnis
II Darstellungsverzeichnis
Dar. 2.1 – Benötigte Verbindungen zum Aufbau einer
RTCPeerConnection [DUTT-2012]
10
Dar. 4.1 – Verteilung relevanter Browserplugins (auf Grundlage
von [STAT-2010], [STAT-2011], [WEBH-2013])
16
Dar. 5.1 – Netzwerkstruktur in PeerWeb
25
Dar. 5.2 – Durchschnittliche Freundesanzahl bei Facebook 2010
(auf Grundlage von [TNSF-2010])
27
Dar. 5.3 – Routing-Tabelle für Peer 1114C5 aus dem
Beispielnetzwerk (Dar. 5.1)
28
Dar. 5.4 – Routingalgorithmus in Pseudocode (nach [MAHLSCHI-2007] Seite 105, [ROWS-DRUS-2001] Kapitel 2.2)
30
Dar. 5.5 – Nachrichtenfluss bei Verbindungsaufbau zwischen Peers
32
Dar. 5.6 – Beispielnachricht
36
Dar. 6.1 – Übersicht Speichernutzung in PeerWeb
41
Dar. 6.2 – Nachrichtenaufkommen bei Änderung eines Dokuments
45
Dar. 6.3 – Nachrichtenfluss bei Anforderung eines Dokuments
47
61
III Abkürzungsverzeichnis
AJAX
Asynchronous JavaScript and XML
API
Application Programming Interface
CSS
Cascading Style Sheet
DB
Database
DOM
Document Object Model
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
ICE
Interactive Connectivity Establishment
ID
Identifikator
JSON
JavaScript Object Notation
NAT
Network Address Translation
p2p
Peer-to-Peer
REST
Representational State Transfer
RTC
Real Time Communication
SOAP
früher: Simple Object Access Protocol, heute: Eigenname
SQL
Structured Query Language
STUN
Session Traversal Utilities for NAT
TURN
Traversal Using Relays around NAT
URL
Uniform Resource Locator
W3C
World Wide Web Consortium
WHATWG Web Hypertext Application Technology Working Group
WSDL
Web Services Description Language
XML
Extensible Markup Language
62
IV Anhang
Anwendungsfalldiagramm
63
Klassendiagramm
64
Aktivitätsdiagramm „Einwahl“
65
weitere Anhänge
Dieser Bachelorarbeit liegt eine CD mit folgendem Inhalt bei:
•
•
•
•
•
•
/Grafiken — verwendete Grafiken
/Belege — Teile der im Literaturverzeichnis
angegebenen Quellen als PDF-Dokumente
/peerWeb — Git-Repository des Projektes
/peerWeb/Peer — Quelltext der Peersoftware
/peerWeb/SuperPeer — Quelltext des Superpeers
/jsdoc — generierte JavaScript Dokumentation
Installation
Die jeweils aktuelle Version von peerWeb wird ab dem 1.2.2013 unter http://peerweb.mar-mar.de erreichbar sein. Für die Verwendung von
peerWeb sollten die Browser Chrome 25 oder Firefox 18 (oder höher) benutzt werden. Soll die Seite auf dem eigenen System eingerichtet werden,
muss ein Webserver vorhanden sein und der Quelltext des Peers in das
entsprechende Verzeichnis kopiert werden. Anschließend brauch nur
wie gewohnt die Seite im Browser geöffnet werden.
Zudem kann ein eigener Superpeer zur Verfügung gestellt werden.
Hierfür ist eine aktuelle Ruby-Version (1.9.3) mit dem Gem em-websocket erforderlich. Das Gem wird über gem install em-websocket installiert. Um den Superpeer auszuführen, wechselt man in das Verzeichnis in dem die Datei des Superpeers liegt und gibt folgenden Befehl ein:
„ruby superpeer.rb --host <IP-Adresse> --port <Portnummer>“. IPAdresse und Portnummer müssen entsprechend angegeben werden.
Der Superpeer dient zur Zeit nur für die Weiterleitung von Nachrichten. So speichert er noch keine Dokumente, wodurch keine weitere Konfiguration nötig ist. Damit sich ein Peer zu dem Superpeer verbindet, reicht
ein Eintrag in der Datei „defaultHelpers.json“. Dieser muss jedoch vor dem
Start des Peers getätigt werden. Weiterhin stehen z.Z. nur Verbindungen
per Websocket zu dem Superpeer zur Verfügung.
66
V Eidesstattliche Erklärung
Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbst
angefertigt habe. Die aus fremden Quellen direkt oder indirekt übernommenen Gedanken sind als solche kenntlich gemacht. Dies gilt auch für
die in der Arbeit gelieferte Zeichnungen, Skizzen, bildliche Darstellungen und dergleichen.
Die Arbeit wurde bisher keiner Prüfungsbehörde vorgelegt und auch
noch nicht veröffentlicht.
Unterschrift Marten Schälicke
67