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 Client- Software 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 OpenSource- Projekt. 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äni- 3

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). 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 Computersyste- 4

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: Andere 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-CSE- 01-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.85-93, 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