Vergleich aktueller Peer-to-Peer-Netzwerke

Vergleich aktueller
Peer-to-Peer-Netzwerke
Hauptseminar Sommersemester 2008
Fachgebiet Kommunikationsnetze
Name:
René Golembewski
Matrikel-Nr.:
Studiengang: Ingenieurinformatik
Betreuer:
Prof. Dr. Jochen Seitz
DI M. Hasan
Inhalt
Inhalt
1 Vorwort
2
2 Das Overlay-Netzwerk
3
3 Kommunikationsprotokolle und -verfahren
3.1 Network Address Translation (NAT) . . .
3.2 Firewalls . . . . . . . . . . . . . . . . . . .
3.3 NAT Traversal . . . . . . . . . . . . . . .
3.4 Late-Join Algorithmen . . . . . . . . . . .
3.4.1 Feste Adresse im Programmcode .
3.4.2 Dynamic DNS . . . . . . . . . . . .
3.4.3 Kontrolliertes Fluten . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
5
9
9
10
10
4 Sicherheit und Stabilität in P2P-Netzwerken
11
5 Einsatzmöglichkeiten
5.1 File-Sharing . . . . . . . .
5.2 Voice-over-IP . . . . . . .
5.3 Informationsaustausch . .
5.4 Peer-to-Peer in MMORPG
.
.
.
.
13
13
13
14
14
6 Technische Realisierungen
6.1 JXTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
17
7 Fazit
19
8 Erklärung
20
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1 Vorwort
1
Vorwort
Peer-to-Peer-Netzwerke spielen in der modernen Telekommunikation eine
große Rolle. Trotz ihres schlechten Rufes, welcher sie oft nur als Werkzeug der
Urheberrechtsverletzungen darstellt, sind sie die Grundlage vieler bedeutender Anwedungen. In diesem Hauptseminarbeitrag sollen aktuelle Technologien vorgestellt und in Bezug auf verschiedene Gesichtspunkte verglichen
werden. Dabei wird besonders auf P2P-Systeme ohne zentrale Instanz Wert
gelegt, die einer vollständigen Selbstorganisation unterliegen. Im Gegensatz
zu einigen zentralisierten Ansätzen, werden solche Netzwerke auch als “reine
Peer-to-Peer-Systeme” betitelt. Folgende Fragen sollen unter anderem in
dieser Arbeit kritisch analysiert und beantwortet werden:
• Wie wird die Kommunikation der Peers geregelt?
• Sind NAT und Firewalls ein Hindernis?
• Welche Late-Join Algorithmen gibt es?
• Wie wird Sicherheit gewährleistet?
• Sind die Systeme stabil?
• Wie wird die Anwendungsentwicklung unterstützt?
Um diese Ausarbeitung zu verstehen sollte der Leser über Grundkenntnisse
der Telematik verfügen. Insbesondere die Kommunikation im Internet über
Protokolle wie IP, UDP und TCP1 sollte bekannt sein, da P2P-Netzwerke
auf Anwedungsebene diesen Protokollstapel verwenden. Sie setzen als ein
sogenanntes “Overlay-Netzwerk” das Vorhandensein einer Kommunikationsinfrastruktur voraus.
1
Internet Protocol, User Datagram Protocol, Transmission Control Protocol
2
2 Das Overlay-Netzwerk
2
Das Overlay-Netzwerk
Overlay-Netze definieren eine logische Topologie auf der zugrunde liegenden
physikalischen Topologie. Knoten, die sich im Overlay-Netz befinden, werden
Peers genannt. Sie stellen in einem Peer-to-Peer Netz gleichberechtigte und
autonome Einheiten dar. Wenn im Overlay eine direkte logische Verbindung
zwischen zwei Peers besteht, dann entspricht diese im zugrunde liegenden
physikalischen Netzwerk auch mindestens einem Hop, im Normalfall aber
mehreren Hops. Es wird angenommen, dass sich ein Overlay-Netz über das
ganze Internet erstrecken kann, und nicht auf feste Bereiche begrenzt wird.
Ein Overlay-Netz kann nur einen Peer bis beliebig viele Peers enthalten.
Einzelne Peers können sich selbstständig in Gruppen organisieren, um gemeinsam Arbeit zu verrichten oder eingschränkte Dienste (Services) zu nutzen
oder zur Verfügung zu stellen. Peer-Gruppen werden durch eine GruppenID
identifiziert, ein Peer kann also Mitglied in mehreren Gruppen sein.
3
3 Kommunikationsprotokolle und -verfahren
3
Kommunikationsprotokolle und -verfahren
Das eigentliche Kernproblem von P2P-Netzwerken ist eine möglichst optimale und effiziente Kommunikation der beteiligten Peers zu erreichen. Obwohl die Internet-Service-Provider (ISPs) stetig mit höheren Verbindungsgeschwindigkeiten aufwarten, sind die derzeitigen Breitbandanschlüsse immernoch ein Flaschenhals im Vergleich zum Internet Backbone. Weiterhin ist
das Verhältnis von Upstream zu Downstream meistens asynchron und so steht zum Versenden von Daten nur eine viel kleinere Datenrate zur Verfügung
als zum Empfangen.
3.1
Network Address Translation (NAT)
Der aktuelle IPv4-Adressraum im Internet ist nahezu komplett vergeben oder
reserviert. Meistens macht es auch gar keinen Sinn, jedem Rechner in einem
Netzwerk eine globale IP Adresse zuzuweisen und somit ein direktes Routing
zu diesem zu ermöglichen. Zumal dieses System dann auch einem höheren
Sicherheitsrisiko ausgesetzt ist. Daher gibt es die Möglichkeit eine Networkbzw. Port-Address-Translation (NAPT)2 einzurichten. Aktuelle DSL-Router
Abbildung 1: NAPT Szenario
2
Network Address Port Translation, auch Hiding NAT oder Masquerading genannt
4
3 Kommunikationsprotokolle und -verfahren
arbeiten nach genau diesem Prinzip. Dabei wird ein lokales Intranet mit
einem reservierten Subnetz3 aufgebaut. Der Router nimmt dabei meistens
auch diverse andere Funktionen wie DHCP Server, Firewall oder DNS Proxy
wahr. Wenn nun beispielsweise ein Rechner aus dem lokalen Intranet eine Anfrage an einen Webserver stellt, so wird für diese Verbindung ein Eintrag in
der NAPT Tabelle des Routers gespeichert und die Antworten des Webservers
können so wieder an den Rechner geleitet werden, der diese Verbindung initiiert hat. Aus diesem Grund ist es nicht möglich eine Verbindung zu einem
lokalen Rechner von einer globalen Adresse, ohne vorherigen Verbindungskontext aufzubauen. Um dies zu ermöglichen gibt es die Funktion des Port Forwarding, wobei eingehende Pakete von einem bestimmten externen Port an
einen festgelegten Rechner des Intranets weitergeleitet werden. Externe und
interne Ports müssen nicht zwingend gleich sein. Dieses Szenario ist jedoch
für den Aufbau eines Peer-to-Peer Netzwerkes nicht optimal, da eingehende
Verbindungsanfragen schon am Router verworfen werden, sofern kein PortForwarding eingerichtet ist. Ein Algorithmus zur Kommunikation zwischen
Peers muss also mit diesem Problem umzugehen wissen.
3.2
Firewalls
Wenn im Zusammenhang mit Peer-to-Peer Netzwerken von Firewalls die
Rede ist, dann sind vorallem die Firewalls zu überwinden, die im Netzwerk4 auf der Route zum globalen Internet passiert werden. Diese Systeme
sind meistens Stateful-Inspection-Firewalls, welche für jede Verbindung einen
gewissen Kontext abspeichern. Ähnlich der NAPT, wird ein eingehendes
Paket nur an den Zielrechner weitergeleitet, wenn dieser vorher eine Datenübertragung initiiert hat und die Firewall eine Übertragung zu diesen Ports
zulässt. Der Teilnehmer in einem P2P-Netzwerk soll jedoch in seiner Funktion
sowohl einem Client als auch einem Server ähneln und auf Anfrage bestimmte
Daten ausliefern.
3.3
NAT Traversal
Unter dem Begriff NAT Traversal versteht man die Überbrückung einer
Verbindung durch ein NAT- bzw. Firewall-System. Es muss dem Client eines
Peer-to-Peer Systems folglich möglich sein, einen Verbindungskontext aus
einer NAT-Domäne heraus aufrecht zu erhalten, um jederzeit von außen
ansprechbar zu sein und Verbindungen annehmen zu können. Als Beispiel soll
3
4
Beispiel: 10.0.0.0/8 oder 192.168.0.0/16 (oder Teile dieser Netze)
Netzwerk-Firewalls im Gegensatz zu Host-Firewalls
5
3 Kommunikationsprotokolle und -verfahren
hier das STUN-Protokoll näher erläutert werden. Die Abkürzung STUN steht
dabei für “Simple Traversal of User Datagram Protocol through Network Address Translators”. Dieses Protokoll wird momentan von vielen Voice-over-IP
(VoIP) Providern verwendet, um eine ständige Erreichbarkeit der Teilnehmer
zu gewährleisten. Eine STUN-Sitzung wird zwischen zwei Kommunikationspartnern aufgebaut, wobei es einen STUN-Server und einen STUN-Client
gibt. Der Server soll ein erreichbarer Rechner im Internet sein, welcher dem
Client bekannt ist. Es werden sechs Fälle unterschieden, wie ein NAT oder
eine Firewall konfiguriert sind. Die Anwedung muss nun feststellen, welcher
Fall zutreffend ist.
1. Offenes Internet, kein NAT, eventuell unsymmetrische Stateful-Inspection
Firewall (Wenn ein Paket vom Client mit einem bestimmten Port gesendet
wurde, werden die Antwort-Pakete aller Quelladressen und Quellports
auf diesen Port als zulässig angesehen und passieren die Firewall)
2. Keine UDP-Konnektivität (Dies ist der schlechteste Fall, hier ist
kein NAT Traversal möglich)
3. Symmetrische UDP Firewall (Firewall blockt alle UDP Pakete,
die nicht vom Empfänger (Adresse:Port) des ausgehenden UDP Pakets
stammen)
4. Full-Cone-NAT (Wenn ein Paket vom Client gesendet wurde, werden
die Antwort-Pakete aller Quelladressen und Quellports auf diesen Port
als zulässig angesehen und werden angenommen)
5. Symmetrisches NAT (Anfragen an verschiedene Rechner werden
nach außen auf verschiedene IP Adressen gemappt)
6. Restriktives NAT (Anfragen an verschiedene Rechner werden auf
die gleich IP gemappt, nur Antwort-Pakete des Kontaktierten Rechners
werden angenommen)
7. Port-Restriktives NAT (wie Restriktives NAT, zusätzlich müssen
auch die Antwortpakete des Servers den gleichen Quellport aufweisen,
wie die Pakete des Clients bei der Anfrage an den Server)
Um eine genaue Auskunft darüber zu bekommen wurden drei Tests definiert,
die in einer bestimmten Reihenfolge nacheinander durchgeführt werden. Der
genaue Testablauf wird in der schematischen Grafik dargestellt.
6
3 Kommunikationsprotokolle und -verfahren
Test I Der Client sendet ein STUN Binding Request an den Server ohne
gesetzte Flags im CHANGE REQUEST Attribut und ohne das RESPONSE ADDRESS Attribut (Dies veranlasst den Server dazu, eine
Antwort an den Socket zu senden, woher das Paket ursprünglich kam)
Test II Der Client sendet ein STUN Binding Request mit den beiden gesetzten Flags “change IP” und “change port” des CHANGE REQUEST
Attributes
Test III Der Client sendet ein STUN Binding Request, bei dem nur das “change
port” Flag gesetzt ist
Der Client beginnt nun also mit dem ersten Test. Wenn bei diesem Test
keine Antwort zurück kommt, weiß der Client, dass keine UDP Konnektivität besteht. Die Prozedur kann somit abgebrochen werden. Wenn eine
Antwort generiert wird, dann muss das Attribut MAPPED ADDRESS5 untersucht werden. Wenn die gemappte Adresse der lokalen IP Adresse des
Clients entspricht, dann befindet sich dieser nicht in einer NAT-Domäne.
Nun wird Test II gestartet. Liefert dieser Test eine Antwort, dann weiß der
Client, das er sich im Szenario “offenes Internet” befindet. Falls nicht, gibt
es eine “Symmetrische UDP Firewall“ in seinem Netzwerk. Befindet sich der
Client nun aber in einer NAT-Umgebung (andere IP nach Test I), so wird
ebenfalls Test II ausgeführt. Liefert dieser Test eine Antwort, dann weiß der
Client, dass er sich in einem ”Full-Cone-NAT“ Netzwerk aufhält. Wenn jedoch keine Antwort erhalten wurde, wird Test I erneut ausgeführt, jedoch
mit der zweiten Zieladresse des STUN-Servers6 , die er dem Client in seiner
ersten Antwort im Attribut CHANGED ADDRESS mitgeliefert hat. Wenn
nun in der folgenden Antwort das Attribut MAPPED ADDRESS eine andere IP Adresse liefert als beim ersten Durchlauf des Test I, dann ist es
ein ”Symmetric NAT“ Szenario. Andernfalls kann es sich nur noch um ein
”Restriktives NAT“ oder ein ”Port-Restriktives NAT“ handeln. Aufschluss
darüber gibt Test III, wobei lediglich ein anderer Port am STUN Server benutzt wird um das Paket zu senden.
5
enthält den Quellsocket des Client-Pakets
Der STUN Server muss aufgrund dieser Tests über 2 Netzwerkinterfaces verfügen
und 2 verschiedene Portnummern verwenden, um unterschiedliche Kombinationen von IP
Adressen und Portnummern zu erzeugen
6
7
3 Kommunikationsprotokolle und -verfahren
Abbildung 2: “Discovery Process” beim STUN-Protokoll [4]
8
3 Kommunikationsprotokolle und -verfahren
Da der Client nach dieser Prozedur weiß in welcher Umgebung er sich
befindet, kann dies in die Konfiguration des P2P-Clients einfließen und es
wird eine ständige Erreichbarkeit gewährleistet. Um auch über einen längeren
Zeitraum konsistent zu bleiben wird diese Prozedur nach einiger Zeit wiederholt. Das hier vorgestellte Verfahren beruht auf dem STUN-Protokoll, welches in RFC3489 dokumentiert ist und auch als “UDP-Hole-Punching7 “ bezeichnet wird. In abgewandelten Implementierungen wird diese Lösung auch bei
vielen Peer-to-Peer Applikationen verwendet. Man erweitert jedoch meistens
die Funktionen und testet bei erfolgloser UDP-Kommunikation anschließend
auf TCP im Allgemeinen und bei sehr restriktiven Netzen auf TCP Verbindungen zu HTTP beziehungsweise HTTPS8 Ports. Dabei können dann beliebige
Systeme des Peer-to-Peer Netzes (meistens Supernodes) die Funktionalität
des STUN-Servers einnehmen und dem neuen Client den Zugang zum Netzwerk ermöglichen. Der Peer-to-Peer Traffic, welcher hier generiert wird,
sieht also von außen betrachtet wie ganz normales Websurfen aus. Die hier
beschriebene Methode des NAT Traversal ist eine nicht mehr wegzudenkende Methode in aktuellen Peer-to-Peer Implementierungen und deswegen
für das grundlegende Verständnis der Funktionsweise dieser Anwendungen
unerlässlich.
3.4
Late-Join Algorithmen
Um einem bestehenden Peer-to-Peer Netzwerk beizutreten gibt es verschiedene
Ansätze. In den meisten Fällen ist die Grundvoraussetzung das Finden eines
Peers, welcher bereits in diesem Netzwerk aktiv ist (”Bootstrapping“). Einige
Lösungen dieses Problems sollen im Folgenden dargestellt werden.
3.4.1
Feste Adresse im Programmcode
Hierbei werden eine IP Adresse und ein Port im Quelltext der Applikation
gespeichert und sind somit dauerhaft festgelegt und im ausführbaren Programm nicht mehr zu ändern. Der voreingestellte Server muss dann jedoch
immer erreichbar sein um ein Bootstrapping zu machen. Gleichzeitig stellt
diese Variante auch einen ”Single Point of Failure” dar und macht das ganze
System somit für “Denial-of-Service9 “ Attacken angreifbar.
7
Ausgehende UDP Pakete “schlagen” Löcher in die Firewalls um diese für eingehende
Verbindungen offen zu halten
8
TCP Ports 80 (HTTP) und 443 (HTTPS) sind die Standardports für Webserver
9
Ein Server wird mit Anfragen überlastet und bricht zusammen
9
3 Kommunikationsprotokolle und -verfahren
3.4.2
Dynamic DNS
Das Dynamische DNS10 bildet wie auch das klassische DNS, Domainnamen
auf IP Adressen ab. Dabei können beim DDNS auch die Einträge des Nameservers durch eine Web-Schnittstelle geändert werden. Wird nun ein Peer-toPeer Netzwerk initial aufgebaut, so tragen die ersten teilnehmenden Rechner
ihre eigene IP Adresse im DDNS System ein. Kontaktiert nun ein neuer Client
den DNS Server, so bekommt er damit die IP Adresse eines teilnehmenden
Peers und kann diesen kontaktieren. Stellt ein aktiver Peer fest, dass eine Anfrage an den Server keine gültige IP Adresse liefert trägt er sich selbst ein, um
die Funktion eines Zugangspunktes zum P2P-Netz zu übernehmen. Wurde
nun vom Client durch eine DNS Anfrage ein aktiver Peer gefunden, so kann
dieser für weitere Zugangsinformationen11 kontaktiert werden. Problematisch
ist dieser Ansatz aber offensichtlich, da DDNS Adressen auch geändert werden können, auch wenn sie noch gültig und erreichbar sind. Deswegen müssen
für dieses Verfahren mehrere DDNS Server zur Verfügung stehen um eine
Ausreichende Sicherheit zu gewährleisten.
3.4.3
Kontrolliertes Fluten
Existiert ein großes Overlay Netzwerk kann durch kontrolliertes Fluten ein
Peer gefunden werden. Da jedes Paket ein TTL-Feld12 im IP Header besitzt,
wird es nach einer gewissen Zeit im Netz an einem Router verworfen. Wird
dabei zufällig ein Peer angesprochen, der auf einem bestimmten Port lauscht,
dann wird dieser eine Antwort senden und die Suche war erfolgreich. Diese
gefluteten Pakete können jedoch an NAT und Firewalls scheitern und führen
bei üblichen Overlay Größen13 selten zum Erfolg. Eine weitere Möglichkeit
wäre IP-Multicasting mit steigender TTL zu verwenden. Da aber im Internet die Anzahl multicastfähiger Provider unter fünf Prozent liegt, ist diese
Lösung in IPv4-Netzwerken nicht erfolgversprechend.
10
Dynamisches Domain Name System
zum Beispiel aktuelle Liste aktiver Peers/Superpeers
12
Das Time-to-live Feld gibt an, wieviele IP Router das Paket passieren darf bevor es
verworfen wird
13
ca. 9,2 Millionen Peers bei Skype
11
10
4 Sicherheit und Stabilität in P2P-Netzwerken
4
Sicherheit und Stabilität in P2P-Netzwerken
Wenn man von Sicherheit in Peer-to-Peer Netzen spricht, dann muss man
dabei immer zwischen Netzsicherheit und Nutzersicherheit differenzieren. Die
Sicherheit und die Robustheit eines Netzes hängt maßgeblich von der Architektur und den Kommunikationsprotokollen ab. So ist zum Beispiel ein
Gnutella Netzwerk viel Resistenter gegen den Ausfall von Peers als andere
Netze mit festgelegten Topologien. Fallen bei einer linearen Datenstruktur
zu viele Peers aus, kann es sein dass das Netzwerk in einen inkonsistenten
Zustand gerät und nur durch einen hohen Aufwand wieder stabilisiert werden
kann. Ebenso können aber auch gezielte Angriffe gegen Peers oder gegen das
gesamte Netzwerk stattfinden. Eine Denial-of-Service Attacke wäre gegen
zentrale Authentifizierungsinstanzen denkbar, oder das gesamte Netzwerk
könnte durch ein dauerhaftes Fluten von Suchanfragen lahmgelegt werden.
Bei Problem dieser Art geht man folgendermaßen vor, um ein Peer-to-Peer
Netzwerk zu schützen:
• Suchtiefe und Menge der Suchanfragen begrenzen
• Vollständige Vermeidung zentraler Instanzen oder
• Peers mit Sonderfunktionen redundant konzipieren
• intelligente Überwachungssysteme, die Angreifer ausschließen
Da ein Peer-to-Peer Netzwerk meist als Overlay auf dem Internet aufsetzt,
bewegt man sich als Teilnehmer grundsätzlich in einem gefährlichen Umfeld,
welches für jedermann zugänglich ist und standardmäßig keine Sicherheiten bietet. Um eine gewisse Sicherheit des Benutzers eines P2P Netzes zu
gewährleisten müssen vorallem folgende Kriterien erfüllt sein:
• Vollständige Anonymität
• Verschlüsselte Datenübertragung
• Datenauthentizität
• Zugangskontrolle
• ständige Verfügbarkeit
Dem Teilnehmer muss jedoch immer bewusst sein, dass er sich in einem offenen Netz bewegt und unter Umständen auch Services oder Dateien zur
Verfügung stellt, die nicht immer genau zu dem vorgesehenen Zweck genutzt
11
4 Sicherheit und Stabilität in P2P-Netzwerken
werden. Aus diesem Grund ist es vorteilhaft nur einer bestimmten Menge vertrauenswürdiger Peers den Zugriff auf erweiterte Funktionalitäten zu ermöglichen.
Durch den Zusammenschluss zu einer Peergruppe ist es möglich, innerhalb
dieser Gruppe ein anderes Rechtemanagement zu benutzen und auch den
Zugang zur Gruppe selbst einzuschränken und zu kontrollieren. [3]
12
5 Einsatzmöglichkeiten
5
Einsatzmöglichkeiten
Wie auch das Internet, stellt ein Peer-to-Peer Netzwerk eine vollständige
Kommunikationsinfrastruktur auf Anwendungsebene zur Verfügung und kann
somit für verschiedenste Dienste und Aufgaben genutzt werden. Die flexiblen
Protokolle und Datenstrukturen machen die Overlay Netze robust gegen Angriffe und schaffen Dezentralisierung.
5.1
File-Sharing
Über kaum eine Sache wird mehr in den Medien diskutiert als die illegale
Nutzung der Filesharing-Funktionalität in Peer-to-Peer Netzen. Dabei muss
jedoch erwähnt werden, dass viele Projekte überhaupt erst durch Filesharing einer großen Nutzergemeinde zugänglich gemacht werden können. Als
Beispiel sollen hier einige Formen genannt werden:
• Verbreitung von kleinen Linux Distributionen
• Softwareprojekte ohne große Serverkapazitäten
• Publikation lizenzfreier Medien (Musik, Video)
Aufgrund hoher Kosten für Internet Traffic können sich vorallem kleine Projekte kaum etablieren, wenn sie zur Bereitstellung eines Downloads einen
eigenen Webserver mit beschränktem monatlichem Transfervolumen hätten.
Eine Publikation eines Links auf eine Datei in einem Peer-to-Peer Netzwerk
ist hingegen einfach und bringt einen guten Nebeneffekt mit sich. Je mehr
eine Datei im Netzwerk nachgefragt wird, umso größer ist die Zahl jener, die
diese Datei anbieten.
5.2
Voice-over-IP
Mit dem Aufkommen von Skype erlebte die VoIP-Telefonie eine starke Erhöhung
der Teilnehmerzahlen auf mittlerweile über 10 Millionen Nutzer weltweit,
allein im Skype-Netzwerk. Der dabei erzeugte Traffic ist viel zu groß um ihn
dauerhaft über feste Server zu schicken. Deshalb kommt für die großflächige
Abdeckung von VoIP Diensten auch ein Peer-to-Peer Ansatz zum tragen, bei
dem nur noch einzelne Kernfunktionen auf zentralen Servern laufen. Diese
Kernfunktionen sind zum Beispiel: Sicherheitsfunktionen, Zugangskontrolle,
Accounting und Messaging. Aktuell gibt es schon diverse Anbieter, die komplett auf Festnetztelefonie verzichten und ihren Kunden über gewisse QoS14
14
Quality of Service Funktionen, Priorisierung, Traffic Shaping
13
5 Einsatzmöglichkeiten
Funktionen im DSL-Zugangsrouter eine stabile VoIP-Umgebung anbieten.[2]
5.3
Informationsaustausch
Da es in der heutigen Zeit leider immernoch Länder auf dieser Welt gibt,
die sehr starke Restriktionen in Bezug auf freie Meinungsäußerung und Verbreitung von Informationen vorgeben, gibt es Bestrebungen einen Informationsaustausch auf der Basis von Peer-to-Peer Systemen aufzubauen. Einer
der bekanntesten Vertreter hierfür ist Freenet, entwickelt von Ian Clarke und
aktuell in Version 0.7 auch als Derivat ”Freenet-China“ im Einsatz. Dieses
Netzwerk ermöglicht die Bereitstellung von Inhalten ähnlich dem WWW,
wobei jeder Peer einen kleinen Speicherbereich seiner Festplatte für Freenet
reserviert und somit eine Serverfunktion wahrnimmt. Das beliebteste Mittel
der Kommunikation stellen sogenannte Freenet-Blogs ”Flogs“ dar.
5.4
Peer-to-Peer in MMORPG
Ähnlich erfolgreich wie die Telefonie über Skype ist beispielsweise das MMORPG15 Spiel ”World of Warcraft“. Nie zuvor gab es gleichzeitig mehr aktive Accounts
als bei diesem Spiel. Mit aktuell fast 11 Millionen Spielern16 erzeugt es ein
Höchstmaß an Serverkapazitäten und Verwaltungsaufwand. Dabei hat ein
einzelner Server zu Spitzenzeiten bis zu 2300 Clients zu verwalten. Um das
Prinzip der riesigen Serverfarmen zu optimieren soll auf der Basis von Peerto-Peer Kommunikation ein Ansatz entwickelt werden, um einen Großteil der
aufzuwendenden Ressourcen einzusparen. Spieler, die online direkt miteinander kommunizieren und agieren, sollen in einer Peergruppe zusammengefasst
werden und so eine direkte Kommunikation untereinander aufbauen können.
Die Server würden somit nur noch administrative Aufgaben übernehmen und
die Kosten sowie die Latenzzeiten können optimiert werden.
15
16
Massive Multiplayer Online Role Playing Game
10.7 Millionen, Tendenz steigend
14
6 Technische Realisierungen
6
Technische Realisierungen
6.1
JXTA
JXTA ist ein Framework zur Entwicklung von Peer-to-Peer basierten Anwendungen. Ziel ist es, eine Standardisierung zukünftiger Projekte in Bezug auf
einen Open Source Protokollstapel zu erreichen. Dabei muss der Programmierer sich nicht mehr mit grundlegenden Problemen von Peer-to-Peer Netzwerken auseinandersetzen, sondern bekommt eine festgelgte Schnittstelle17
zu den Funktionen einer verteilten Anwedung. Das JXTA Projekt obliegt seit
der Veröffentlichung im Jahre 2001 der Administration von SUN Microsystems und wird mittlerweile von einer großen industriellen und akademischen
Gemeinschaft weiterentwickelt. Die JXTA Protokolle sind der eigentliche
Kern des Frameworks. Dabei spielt es keine Rolle welche Infrastruktur werwendet wird.[1]
Abbildung 3: JXTA Architektur [1]
17
IETF Standardisierung wird angestrebt
15
6 Technische Realisierungen
6.2
Gnutella
Gnutella wurde im März 2000 von Justin Frankel als erste Beta Version
veröffentlicht und ist seitdem zu einem der populärsten Vertreter von Peerto-Peer Netzen aufgestiegen. Das Overlay Netzwerk unterliegt in keiner Weise
einer geordneten Struktur. Alle Peers sind gleichwertig und unterhalten einige
wenige Verbindungen zu Nachbarpeers. Eine Suche im Netzwerk wird über
kontrolliertes Fluten der Suchanfragen an die Nachbarknoten erreicht, wobei
es ein Time-to-live Attribut verhindert, dass das Netz mit Anfragen überlastet
wird. Ein Schnappschuss eines Gnutella Netzwerks ist in der folgenden Grafik
zu sehen. Ab November 2002 wurde dann eine Weiterentwicklung des Pro-
Abbildung 4: Snapshot Gnutella Netzwerk
tokolls unter dem Namen Gnutella2 von Michael Stokes bekannt gegeben. Die
gravierendste Änderung an der Architektur war die Einteilung aller Knoten
in Leaves (Blätter) und Hubs. Leaves unterhalten dabei nur eine oder wenige
Verbindungen zu Hubs und richten auch ihre Suchanfragen an diese. Hubs
haben Verbindungen zu Hunderten von Leaves und auch zu vielen anderen
Hubs. Wird nun eine Suchanfrage von einem Peer (Leaf) gemacht, so schaut
16
6 Technische Realisierungen
der Hub zuerst nach ob einer seiner eigenen Leaves das gesuchte Datum besitzt. Ist dies nicht der Fall reicht er die Suchanfrage weiter an andere Hubs.
Ein Hub verwaltet somit eine große Datenbank der Dateien, die seine Leaves
bereithalten. Dieses Prinzip der Netzwerkstruktur erhöht die Performanz des
Netzes und vermindert das aufkommende Datenvolumen um ein vielfaches,
da nicht mehr im Netzwerk geflutet werden muss.
6.3
Pastry
Pastry wurde von Antony Rowstron und Peter Druschel vom Microsoft Research Lab entwickelt. Im Vordergrund standen vorallem:
• Dezentralität
• Fehlertoleranz
• Skalierbarkeit
• Anpassung an das Underlay Netzwerk
Pastry nutzt wie auch einige andere Netzwerke die Datenstruktur der ”Verteilten Hash Tabellen18 ” zum Finden von Dateien. Dabei wird jeder Datei, sowie
jedem Peer ein eindeutiger Hashwert von 0 bis 2128 −1 zugeordnet. Es existiert
somit eine lineare Datenstruktur (ein Ring), der zu durchsuchen ist. Ein
Peer ist genau für die Dateien verantwortlich die zwischen ihm und seinem
Vorgänger auf dem Ring liegen. Bei einer Suche bildet ein Peer einfach den
Hashwert seiner zu suchenden Datei. Zuerst wird überprüft ob dieser Peer
selbst für diese Datei verantwortlich ist. Falls nicht reicht er seine Anfrage an
seine Nachbarn weiter, die näher am gesuchten Hashwert liegen. Eine Suchanfrage wird so automatisch durch das Netz propagiert, bis man einen Peer erreicht, dessen Hashwert größer ist als der, der gesuchten Datei. Wurde dieser
verantwortliche Peer gefunden kann er sich beim suchenden Peer melden
und ihm die Informationen zukommen lassen. Um einem Zerfall des Ringes
in zwei Teile vorzubeugen, kennt jeder Peer nicht nur seine Nachbarn, sondern besitzt auch noch sogenannte ”Finger-Zeiger“. Fallen nun unerwartet
mehrere Peers aus, so kann immernoch eine konsistente Suche auf dem Ring
gewährleistet werden. Um schnellere Suchanfragen zu erreichen, werden die
Finger-Zeiger auch verwendet um mit einer Anfrage näher an die gesuchte
Datei zu springen und nicht sequenziell auf dem Ring zu suchen. Betritt ein
neuer Peer das Netzwerk, so wird er in den Ring aufgenommen und anhand
seines Hashwertes positioniert. Verlässt ein Peer das Netz, übernimmt sein
18
Distributed Hash Tables (DHTs)
17
6 Technische Realisierungen
Abbildung 5: Suchanfrage in einer DHT Datenstruktur
direkter Nachfolger auf dem Ring die Aufgaben. Aufgrund dieser besonderen
Datenstruktur ist es möglich jede Datei in einem Netzwerk zu finden, auch
wenn sie nur ein einziges Mal vorhanden ist.[5]
18
7 Fazit
7
Fazit
Peer-to-Peer Netzwerke spielen auch in der heutigen Kommunikationswelt
eine große Rolle und sind im Hinblick auf ein stetig wachsendes Datenaufkommen im Internet eine gute Alternative zur klassischen Client-Server-Architektur.
Ob für Dateitransfer, Videostreaming oder Voice-over-IP-Telefonie - Die verschiedensten Formen und Protokollvarianten für den Aufbau eines Overlay Netzes ermöglichen eine freie Auswahl der optimalen zu Grunde liegenden Technologie. Für die Entwicklung verteilter Anwendungen stehen offene
Protokolle und Frameworks zur Verfügung, die es ermöglichen ohne großen
Aufwand eine Applikation auf einem Peer-to-Peer Protokollstapel zu entwickeln. Auch im Bereich der verteilten Datenhaltung (verteilte Dateisysteme)
kommen heutzutage Protokolle wie Pastry zum Einsatz, die sich aufgrund
von effizienten und stabilen Algorithmen als sehr gut skalierbar und performant erwiesen haben. So lässt sich also vermuten, dass in nächster Zeit
noch viel Forschungsarbeit in diesem Bereich geleistet wird, denn nicht nur
die Forschung, sondern auch die Wirtschaft zeigt großes Interesse an den
Ergebnissen dieser Arbeit.
19
8 Erklärung
8
Erklärung
Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der
angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß
aus veröffentlichten Quellen entnommen wurden, sind als solche kenntlich
gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise
im Rahmen einer oder anderer Prüfungen noch nicht vorgelegt worden.
Ilmenau, den 10. 07. 2008
Rene Golembewski
20
Literaturverzeichnis
Literaturverzeichnis
[1] Wikipedia: http://de.wikipedia.org/wiki/jxta.
[2] Salman A. Baset and Henning G. Schulzrinne. An Analysis of the Skype
Peer-to-Peer Internet Telephony Protocol. IEEE Magazine, Columbia
University, 2006.
[3] Peter Mahlmann. Peer-to-Peer Netzwerke. Springer, eXamen.press, 2007.
[4] RFC3489. STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs). IETF, 2003.
[5] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized
object location and routing for large-scale peer-to-peer systems. Microsoft
Research, 2001.
21