Seminarvortrag Peer-to-Peer Filesharing Systems

Transcription

Seminarvortrag Peer-to-Peer Filesharing Systems
Seminarvortrag
Peer-to-Peer Filesharing Systems
Thomas Puppe
Universität Konstanz
14. Juni 2003
Zusammenfassung
Wir stellen exemplarisch die Funktionsweise verschiedener populärer
Peer-to-Peer Filesharing Systeme vor und zeigen die dahinterliegenden
Motive.
1
Vorgeschichte
Im Jahr 1995 wurde vom Fraunhofer Institut der MPEG Audio Layer 3 Algorithmus (MP3) veröffentlicht. Es ermöglicht die Komprimierung von Audiodaten auf
bis zu ein Zehntel ohne große Qualitätsverluste. Ursprünglich für die Tonspur
von Videodaten gedacht wurde es bald dazu verwendet, Musik zu komprimieren und zu tauschen. Das war dank verbesserter Bandbreiten jetzt auch über
das Netz möglich. Es entstanden Server für den freier Up- und Download von
MP3-Dateien (z.B. via FTP). Die meisten Musikstücke waren jedoch urheberrechtlich geschützt, d.h. nur Privatkopie war erlaubt, freies Verteilen dagegen
verboten. Somit ergab sich zu der begrenzten Kapazität der Server noch ein
zweites Problem, die offensichtliche Illegalität. Je größer solche Server wurden,
umso auffälliger wurden sie und die Wahrscheinlichkeit wuchs, daß sie gesperrt
wurden.
Alternativ dazu entwickelten sich Peer-to-Peer (P2P) Filesharing Systeme:
Eine größere Anzahl von Nutzern (Peers) stellt mittels einer ClientSoftware Speicherplatz zur Verfügung zu gegenseitigem Upload und
Download.
Vorteil ist eine bei entsprechender Nutzerzahl praktisch unbegrenzte Kapazität
und die rechtliche Seite: Nur die Nutzer verstoßen unmittelbar gegen das Urheberrecht, doch deren Vergehen sind vergleichsweise wenig gravierend und über
das Internet schwer nachzuweisen.
1
Abbildung 1: Napster [1]
2
Die erste P2P-Generation
Napster und Gnutella waren die ersten wirklich populären P2P-Systeme und
verhalfen der Idee zum Durchbruch. Dabei sind beide im wesentlichen Punkt
unterschiedlich. Das Napster-Protokoll sieht einen zentralen Server vor, Gnutella
dagegen ist völlig dezentral.
2.1
Napster
Beim Napster-Protokoll (Abbildung 1) loggt sich jeder Nutzer in einen zentralen
Server ein und sendet eine Liste seiner freigegebenen MP3-Dateien. Der Server
liefert auf eine Suchanfrage eine begrenzte Anzahl von Treffern und stellt, wenn
gewünscht, Downloadverbindungen zwischen den Nutzern her. Wie bei den meisten anderen P2P-Systemen auch wird zum Suchen String-Matching und für den
Download TCP verwendet [1].
Das Napster-Protokoll und die Client-Software Napster wurde Anfang 1999 von
einem 19-jährigen Studenten aus den USA ausschließlich für Windows programmiert. Es war einfach zu bedienen und erfuhr ein rasantes Nutzerwachstum. Am
Schluß, im April 2001, waren durchschnittlich immer 1,5 Millionen gleichzeitig
online. Damit war es das einzige P2P-System in dieser Größenordnung. Ob sich
Napster eines Vergehens schuldig machte, war anfangs noch unklar. Aber als
es immer erfolgreicher wurde, mußte die Musikindustrie handeln. Napster, jetzt
eine Firma, wurde in den USA wegen Beihilfe zu Urheberrechtsverletzungen
angeklagt. Anfang 2001 kam es zur Verurteilung zu Schadensersatzzahlungen
und zu Installation von Dateifiltern. Während es inzwischen auf den meisten
Ländern verboten ist, Computerviren zu programmieren, war hier nicht das
Napster-Protokoll oder die Client-Software ausschlaggebend. Sondern es war
der laufende Betrieb des eigenen Servers, sozusagen eine Dienstleistung zum
2
Abbildung 2: Gnutella [1]
Verstoß gegen das Urheberrecht. Der Musikkonzern Bertelsmann kaufte dann
im April 2001 das verschuldete Napster und stellte Anfang Juli den Betrieb ein
[3]. Ein kostenpflichtiger Musikdienst war geplant. Doch es kam zu Verzögerungen wieder wegen juristischer Probleme. Als sich andere kostenlose P2P-Systeme
etabliert hatten, wurde das Vorhaben verworfen.
Auch andere napsterähnliche Systeme gaben auf in Anbetracht der juristischen
Lage bzw. weil ihnen einfach die zentralen Server gesperrt werden.
2.2
Gnutella
Bei Gnutella hat jeder Nutzer einige Nachbarn. Eine Suchanfragen wird an
alle Nachbarn gesendet. Diese antworten und leiten die Anfrage an alle ihre
Nachbarn weiter. Das gleiche machen jetzt auch alle Nachbarn der Nachbarn
usw. Dabei hat jede Anfrage eine Time-To-Live, eine Anzahl von Stationen, die
durchgelaufen werden (siehe Abbildung 2).
Um sich im Netzwerk anzumelden, wird eine lokal gespeicherte Liste von Nachbarn angepingt. Die aktiven Nachbarn antworten und leiten das Ping an ihre
Nachbarn weiter. Das gleiche machen jetzt auch alle Nachbarn der Nachbarn
usw. Dabei hat jedes Ping ebenfalls eine Time-To-Live. Bisher nicht bekannte
Nutzer werden in die Liste der Nachbarn aufgenommen.
Es kann jede Art von Daten getauscht werden [1].
Das Gnutella-Protokoll war öffentlich und die Client-Software ein OpenSourceProjekt. Das System entstand kurz nachdem Napster enstanden war. Es konnte
sich aber nie richtig gegen andere P2P-Systeme durchsetzen, es war nicht skalierbar. System und Bedienung waren vergleichsweise kompliziert. Das ständig
vorhandene Grundrauschen“ durch Anfragen und Pings schreckte Nutzer mit
”
geringer Bandbreite ab. Ein weiteres Problem war es, als neuer Nutzer überhaupt Nachbarn zu finden. Zudem gab es oft mehrere, voneinander unabhäni3
ge Gnutella-Netzwerke, so daß die gesamte freigegebene Datenmenge nicht für
alle zugänglich war. Allerdings konnte es juristisch nicht angegriffen werden
aufgrund der dezentralen Struktur. Nach dem Napster-Aus verbesserten andere Gruppen, wie z.B. LimeWire, das Gnutella-Protokoll und brachten eigene
Software-Clients heraus. Damit hatten sie mehr Erfolg und deshalb wurde dann
die Client-Software Gnutella auch nicht mehr weiterentwickelt.
Zur Größenordnung: Im Mai 2001 konnten dann im größten Gnutella-Netzwerk
(50.000 Knoten) von jedem beliebigen Knoten aus 95 Prozent aller anderen in
7 Schritten erreicht werden [2].
3
Ideenwettlauf nach dem Napster-Aus
Mit dem Napster-Aus konnten abrupt Millionen von Nutzern nicht mehr Musik
tauschen. Es gab kein Auffangbecken, kein zweites System, zu dem sie sofort
wechseln konnten. Gnutella, damals die Nummer zwei, war jedenfalls aus den
genannten Gründen für die meisten keine wirkliche Alternative.
Für die Programmierer, die neue P2P-Systeme etablieren wollten, gab es zwar
ein großes Nutzerpotential, aber keine Unterstützung durch Geldgeber. So konnte Erfolg nur an der Qualität des Systems liegen und dies führte zu einem Ideenwettlauf.
3.1
Erkenntnisse
Aus dem Ende Napsters mußte man die Lehre ziehen, daß Systeme mit zentralem Server zu leicht angreifbar sind. Ein Ausfall des Servers aus technischen
Gründen würde ebenfalls das gesamte System lahmlegen. Deshalb sollte die
Entwicklung dezentraler Systeme forciert werden, bei denen sich nebenbei auch
Latenzzeiten verringern würden.
Über den Nutzen von Netzwerken gibt es folgenden elementaren Satz:
Satz von Metcalfe: Der Nutzen eines Netzwerks wächst im Quadrat wie die
Anzahl seiner Nutzer [4].
Beweis: Wir nehmen an, das Netzwerk ist ungerichtet und zusammenhängend
und jeder der k Knoten habe den gleichen Nutzen, nämlich 1. Dann hat ein
einzelner Knoten von den anderen den Nutzen k − 1 und das Netzwerk den
Gesamtnutzen k(k − 1).
2
Demnach sollte bei der Programmierung neuer P2P-Systeme versucht werden,
die Anzahl der Nutzer erhöhen, z.B. mittels eines guten File-Angebots oder einer
komfortablen Client-Software, implementiert für möglichst viele Computersyste4
Abbildung 3: Server-Client-Struktur in Napster [1]
me. Da es sich hier um dynamische Netzwerke handelt, sollten die Nutzer auch
länger online gehalten werden.
Doch bringt jeder Teilnehmer dem P2P-System den gleichen Nutzen? Wissenschaftlichen Arbeiten über P2P-Filesharing mit Napster und Gnutella beantworten dies eindeutig mit Nein. Wir werden uns in unserer Argumentation auf
Daten aus [1] beschränken, diese Daten wurden aber in anderen Arbeiten (wie
[2]) bestätigt.
Zuerst einmal gab es große Unterschiede der Teilnehmer in ihrer freigegebenen
Datenmenge, es stellten bei im Mai 2001 Napster 7 Prozent genausoviel Daten
bereit wie der ganze Rest zusammen. In Abbildung 3 sieht man das Downloadverhalten in Abhängigkeit der Bandbreite bei Napster. Dort mußten die Nutzer
bei der Installation der Client-Software die Art ihres Internetzugangs angeben.
In der vorliegenden Messung (wieder Mai 2001) hatte die Hälfte Dual ISDN,
Cable oder DSL. 6 Prozent hatten T1 oder T3, was ähnlich schnelle Zugänge
sind. Die Nutzer von Analogmodems oder ISDN, zum Teil wesentlich langsamer,
kamen auf 22 Prozent, ebenso die, die Unknown angaben. Wie man sieht, verzeichneten die schnelleren Zugänge deutlich mehr Upload als Download. Haben
diese noch lange Onlinezeiten in den P2P-Systemen, spricht man von Teilnehmern mit Server-ähnlicher Charakteristik.
Diejenigen, die als Internetzugang Modem, ISDN oder Unkown angaben, waren
dagegen die Profiteure, sie hatten deutlich mehr Download als Upload. Eine einfache Erklärung dafür ist, daß man sich beim Download eher für Teilnehmer mit
5
Abbildung 4: Links: Gnutella-Graph Februar 2001; Mitte: 30 Prozent der Knoten
wurden zufällig entfernt; Rechts: Die 4 Prozent mit den höchsten Graden wurden
entfernt. [1]
großer Bandbreite entscheidet. Zudem sind die langsamen Internetverbindungen
über Analogmodem auch noch asymmetrisch, d.h. die Download-Bandbreite ist
größer als die Upload-Bandbreite. Aber vielen dieser Nutzer mangelte es wohl
auch einfach an Kooperation. Es liegt wohl in der menschliche Natur, sich in
einem anonymen Raum lieber etwas zu nehmen als zu geben. So ergaben andere
Messungen, daß 30 Prozent der Modem und ISDN - Nutzer deutlich schnellere
Internetverbindungen hatten als angegeben, um vermutlich andere vom Download bei ihnen abzuschrecken. Genauso wirkungsvoll war es, wie 22 Prozent aller
Unknown anzugeben. Zum Vergleich: Nur 5 Prozent gaben dagegen irrtümlich
deutlich schnellere Internetverbindungen an, als sie hatten. Es ist also unwahrscheinlich, daß so viele nicht über ihren Zugang Bescheid wußten. Treffen jetzt
mangelnde Kooperation, kurze Onlinezeiten und wenig freigegebene Daten zusammen, spricht man von Client-ähnlichem Verhalten.
Auch bei Gnutella konnte man eine Server-Client-Struktur in der Nutzerschaft
feststellen. Dabei hatten die Nutzer mit der Server-Charakteristik in dem dezentralen Netzwerk besonders hohe Knotengrade. Empirische Untersuchungen
(siehe Abbildung 4) ergaben, daß es trotz Ausfalls vieler zufälliger Nutzer noch
zusammenhängend und funktionsfähig blieb. Beim Ausfallen vieler Nutzer mit
Server-ähnlichem Charakter zerfiel das Netzwerk in eine große Menge kleiner
Komponenten mit geringem Nutzen für den Einzelnen. Die Ausfallsicherheit
des dezentralen Gnutella hing also von den Nutzern mit dem Server-Profil ab.
Wäre die Nutzerschaft bzgl. ihrer Server-Client-Struktur heterogener gewesen,
so wäre auch die Ausfallsicherheit besser gewesen.
Neue P2P-Systeme sollten sich also auf die Server-Client-Struktur der Nutzer
einstellen, aber trotzdem Anreize für eine bessere Kooperation schaffen.
6
3.2
Innovationen der Nachfolger
Ob sich die Programmierer der neuen P2P-Systeme wirklich an den Ergebnissen
der Wissenschaft orientierten, ist natürlich fraglich. Die folgenden Trends und
Innovationen wurden aber fast von allen erfolgreicheren Systemen übernommen
und stehen durchaus im Einklang mit den obigen Motiven.
• Es werden fast ausschließlich dezentrale Protokolle entwickelt, die auch
nach dem Wegfall vieler Nutzer mit Server-ähnlichem Charakter funktionieren.
• Anders als bei Napster können neben MP3-Dateien auch alle anderen
Daten getauscht werden, z.B. Filme, Bilder, Software. . . Das erhöht das
Dateiangebot.
• Es werden Versionen der Client-Software für Windows, Unix/Linux, Mac
usw. entwickelt. Dadurch erhält man mehr potenzielle Nutzer.
• Oft ist das Anschauen der Filme, Anhören der Musik und Chat mittels
der Client-Software möglich. Das verlängert die Onlinezeit.
• Abgebrochene Downloads können wieder aufgenommen werden und gleichzeitiges Downloaden von verschiedenen Quellen ist möglich. Das erhöht
den Komfort.
• Die Bandbreite der Nutzer wird automatisch erkannt und dementsprechend werden sie am Traffic der Systemfunktionen beteiligt. Man erhält
wiederum mehr potenzielle Nutzer (mit geringer Bandbreite) und fördert
die Kooperation (keine falschen Angaben mehr möglich).
4
Die heutige P2P-Generation
Nachfolgend werden wir zwei heute populäre P2P-Protokolle vorstellen, die diese Innovationen übernommen oder sogar eingeführt haben. Sie sind in ihrer
Funktionsweise und der dahinterstehenden Intention Gegenpole, alle übrigen
populäreren Protokolle stehen irgendwo dazwischen.
4.1
FastTrack (KaZaA)
Die Client-Software des FastTrack-Protokolls macht eine größere Anzahl von
Nutzern mit besonders guter Bandbreite und Rechnerkapazität zu sogenannten
Supernodes“. Die Supernodes übernehmen unbemerkt die Serverfunktion: An”
dere Nutzer loggen sich bei ihnen ein. Bei einem Suchauftrag durchsucht der
Supernode zuerst die eigenen Nutzer und leitet den Auftrag dann an andere
7
Abbildung 5: FastTrack (KaZaA)
Supernodes weiter. Auch hier gibt es eine Treffer-Grenze. Downloadverbindungen werden hergestellt (Abbildung 5). Melden sich Supernodes ab, übernehmen andere deren Funktion, das Netzwerk fällt nicht auseinander. Es gibt ein
Ranking-System, bei dem das Upload-Download-Verhältnis bewertet wird, damit die Nutzer sich kooperativ verhalten. Die Client-Software ist ähnlich einfach
zu bedienen wie Napster, es gibt allerdings keine Versionen für Unix/Linux bzw.
Mac, nur für Windows [5].
Es sind also keine Server nötig. Sitz der für das Protokoll und die Client-Software
KaZaA Media Desktop (KMD) verantwortlichen Firma war ursprünglich die
Niederlande. Dort wurde der Rechtsstreits mit der Musikindustrie gewonnen,
Prozesse in der USA stehen aber evtl. noch aus. Ende 2001 wurden die selben
Nutzerzahlen erreicht wie mit Napster am Schluß, jetzt mehr als doppelt so
viele und mehr als alle anderen aktuellen P2P-Systeme. Das Protokoll ist nichtöffentlich, die lizensierte Client-Software KMD und Grokster enthält Werbung
und Spyware, d.h. Programme, die das Verhalten des Nutzers aufzeichnen und
weitermelden. Die nicht autorisierte Client-Software KaZaA Lite ist davon frei
und wird zum Ärger der FastTrack-Betreiber von vielen vorgezogen. Ein Weiterbestehen nur mit KaZaA Lite scheint evtl. möglich [6].
Hinter dem FastTrack-Protokoll stehen finanzielle Interessen. Wahrscheinlich
existiert deshalb keine Client-Software für Unix/Linux und Mac, weil dort die
Einnahmequelle Spyware schwer zu implementieren wäre. Andererseits hat sich
das System aber schon in einem Rechtsstreit behauptet, es ist komfortabel und
das Angebot sehr gut.
4.2
MFTP (Edonkey)
Bei dem MFTP-Protokoll existieren eine größere Anzahl dezentraler Server. Der
Nutzer loggt sich bei einem ihm bekannten Server ein. Bei einem Suchauftrag
8
Abbildung 6: MFTP (Edonkey)
durchsucht der Server die eigenen Nutzer und kann auch auf die anderen Server des Netzwerkes zugreifen. Downloadverbindungen werden hergestellt (Abbildung 6). Software zum Serverbetrieb ist öffentlich erhältlich. Die Server wechseln
ständig. Aktuelle Serverlisten findet man im Internet bzw. bekommt man beim
Einloggen [7]. Die Client-Software (Edonkey, Emule, ...) und die Serversoftware
sind OpenSource-Projekte, das Protokoll ist öffentlich. Somit ist das ganze System juristisch schwer angreifbar.
MFTP bedeutet Multisource File Transfer Protocol, es kann gleichzeitig von
mehreren Quellen heruntergeladen werden und die Wiederaufnahme von Downloads ist ebenfalls möglich. Dafür wird jedem Nutzer und jeder Datei ein Hashwert errechnet. Zusätzlich zum String-Matching ist das System ist damit in
der Lage, direkt nach einem Hashwert zu suchen. Es können so alle Kopien
einer bestimmten Datei ausfindig gemacht werden. Das ist besonders wichtig
bei größeren Dateien wie Filmen, an denen man mehrere Stunden läd. Ebenso
können sich alle Nutzer untereinander eindeutig identifizieren und treffen [7].
Allerdings ist die Bedienung nicht ganz so einfach wie z.B. bei KaZaA Lite.
Auch die Nutzerzahl ist deutlich kleiner als im FastTrack-Netzwerk.
Das MFTP-Protokoll ist mittlerweile sehr populär, kommt aber an die Nutzerzahlen von z.B. FastTrack (KaZaA) nicht heran. Es wird vor allem für Filme
verwendet, ist eine Art Nischenprodukt. Das hat aber auch Vorteile: Man kann
sich an die speziellen Wünsche der Klientel anpassen und bleibt unauffälliger.
Mit den ständig wechselnden Servern und der OpenSource-Charakteristik hat
man einen anderen Weg gefunden, juristischer Probleme aus dem Weg zu gehen.
9
5
Zusammenfassung und Ausblick
Es gibt natürlich noch einige weitere populäre P2P-Systeme, meist mit ähnlicher Funktionsweise. Wie FastTrack (KaZaA) versuchen z.B. WinMX und das
modifizierte Gnutella möglichst viele Nutzer anzusprechen, wobei Gnutella jetzt
so etwas ähnliches wie Supernodes vorsieht. Genauso wie MFTP (Edonkey) die
Filmnische besetzt hält, hat sich Soulseek auf elektronische Musik spezialisiert.
Mittlerweile ist Datentausch auch über Chatprotokolle wie ICQ möglich. Andere P2P-Ansätze wie Overnet, Freenet oder Directconnect kommen bis jetzt
nicht über den Versuchsstatus hinaus, müßten dafür jetzt aber auch andere verdrängen.
Die Praxis hat also die Funktionalität der P2P-Systeme auch für große Nutzerzahlen gezeigt. Dabei hat sich erwiesen, daß nichtkommerzielle, dezentrale Systeme die größte Stabilität gegen äußere Einflüsse besitzen. Man könnte durchaus
P2P-Systeme für den legale Anwendungen einsetzen wie z.B. das Vernetzen von
Bibliotheken elekronischer Publikationen.
Literatur
[1]
S. Saroiu, P.K. Gummadi and S.D. Gribble: A Measurement Study
of Peer-to-Peer File Sharing Systems. Technical Report UW-CSE01-06-02.
[2]
M. Ripeanu, I. Foster: Mapping the Gnutella Network: Macroscopic Properties of Large-Scale Peer-to-Peer Systems. P. Druschel, F.
Kaashoek, and A. Rowstron (Eds.): IPTPS 2002, LNCS 2429, pp.8593, 2002. Springer-Verlag Berlin Heidelberg 2002.
[3]
www.wikipedia.org
[4]
Bo Leuf: Peer to Peer - Collaboration and Sharing over the Internet.
ISBN 0-201-76732-5. Addison-Wesley 2002.
[5]
www.kazaa.com
[6]
www.kazaalite.com
[7]
www.edonkey2000.com
10