Napster

Napster war eine zentral verwaltete Musiktauschbörse, die als erste Killer-Applikation P2P-Technologien verwendet. Das Projekt wurde 2001 nach einer erfolgreichen Unterlassungsklage wegen Verletzung des Copyrights eingestellt. Zentral verwaltet werden die von den Benutzern übermittelten vorhandenen Namen von MP3-Dateien sowie die Suchanfragen. Der Dateiaustausch funktioniert direkt zwischen den Benutzern (peer to peer). Durch die zentrale Verwaltung konnten schnell Ergebnisse zu einer Suchanfrage geliefert werden, während der direkte Transfer zwischen den Clients nicht die zentralen Server belastet. Die graphische Benutzerschnittstelle, die es selbst für Computerlaien einfach macht, sich an der Tauschbörse zu beteiligen und die irc-ähnliche Chatintegration, mit deren Hilfe die Nutzer untereinander Empfehlungen für Musikstücke gaben, bildeten weitere Gründe für den damaligen Erfolg.

Napster Screenshot v2.0 Beta 10

Geschichte

Im Herbst 1998 begann der damals 18-jährige Shawn Fanning sein Studium in Informatik an der Bostoner Universität. Dank der vorhandenen Breitbandanbindung ins Internet verbrachte er einen Großteil der Zeit im Studentenwohnheim auf der Suche nach digitalisierter Musik und Gleichgesinnten, die er in der Hackergruppe w00w00 fand, mit der er über den IRC kommunizierte. Durch die unbefriedigende Verfügbarkeit von Musikdateien wuchs in Fanning der Wunsch nach einem Programm, dass die vornehmlich mp3-Dateien direkt zwischen suchenden und anbietenden Nutzern des Internets vermittelt. Im Januar 1999 arbeitete er bereits an seinem persönlichen "Hello World" - er nannte es Napster, seinen Spitznamen im IRC. Unterstützt wurde er über dem IRC mit w00w00, die bei der Programmierung zur Seite standen. Nach nur einem Semester beendete er sein Studium und gründete im Mai 1999 mit seinem voraus schauendem Onkel, der zu jenem Zeitpunkt ein Internet-Schach-Portal betrieb, die Firma Napster Inc. Als im Juni 1999 die erste Beta-Version von Fanning auf seiner Webseite veröffentlicht wurde, luden in nur wenigen Tagen bereits tausende von Enthusiasten die Software herunter. Diese Nutzer erzeugten eine Last auf dem Server, die dieser nicht lang standhielt. Die Firma stellte nun Mitarbeiter ein, unter anderem Jordan Ritter, der sich um die Server-Architektur kümmern sollte und Fanning stellte im September 1999 Version 2 von Napster ins Netz. Es kamen erste Beschwerden von Universitäten, die einen massiven Anstieg an Breitbandverkehr feststellen mussten und dies auf Napster zurückführten. Der Umzug der Firma nach Kalifornien folgte im Oktober. Der plötzliche Bekanntheitsanstieg ließ auch die RIAA (Recording Industry Association of America) auf den Plan treten: Sie forderte im November 1999 zum ersten Mal, den Tauschhandel zu unterbinden. Allerdings konnte niemand bei Napster sich vorstellen, dass sie angreifbar wären, da sie Napster, ähnlich wie mp3.lycos.com, als Suchmaschine für Musik sahen.

Architektur

Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen zentralen Server benötigt.

Client-Server

Alle in diesem Netz partizipierenden Klienten schicken beim Starten eine Hashliste der lokal freigegebenen Dateien an den Server server.napster.com, der somit einen umfassenden zentralen temporären Suchindex aufbauen kann. Das Hashen geschieht mittels MD5 der ersten ca. 300,000bytes ab dem FrameSync im mp3. Für die Client-Server-Kommunikation wird TCP eingesetzt, typischerweise auf den Ports 8888 und 7777. Jede Nachricht hat die Form

<length><type>,

wobei <length> und <type> jeweils 2 byte lang sind, in little-endian kodiert. Der Wert <length> gibt die Länge von an, <type> definiert den Typ der Nachricht. Die Zeichen „<>“ dienen nur der besseren Veranschaulichung, die einzelnen Abschnitte werden duch Leerzeichen (ASCII 32) getrennt. Für die einzelnen Typen von Nachrichten möchte ich auf die offene Spezifikation von drscholl verweisen, die vom 7.April 2001 datiert ist. Da es nie eine Offenlegung des Protokolls gab, war man auf die Analyse des Protokolls während der Nutzung angewiesen.

Client-Client

Der eigentliche Dateitransfer findet zwischen den Klienten selbst statt, dafür gibt es vier Transfermodi: Upload, Download, Firewalled Upload und Firewalled Download. Im Normalfall stellt der Client, der die Datei herunterladen möchte, mit dem bereitstellenden Client zum dortigen data-port eine Verbindung her. Sollte der Sender hinter einer Firewall sein, so muß er die Datei an den Empfänger „pushen“. Unabhängig vom Modus wird aber zunächst an den Server eine Suchanfrage gerichtet, entweder mittels Nachrichtentyp „200 (0xc8) client search request“ oder „211 (0xd3) browse a user's files“. Die daraufhin erhaltene Liste enthält eine Liste von Dateien und Informationen über den Client, der diese bereitstellt. Um einen Download anzustoßen, wird ein „203 (0xcb) download request“ an den Server gesandt, um mit einem „204 (0xcc) download ack“ die IP, den Port, den Dateinamen, die MD5-Checksumme und die Verbindungsgeschwindigkeit zu liefern. Sollte die Portnummer 0 sein, so befindet sich der Client, von dem geladen werden soll, hinter einer Firewall und man muss nach senden eines „500 (0x1f4) alternate download request“ auf die eingehende Verbindung warten. Wenn keine Firewall die Übertragung behindert, wird eine Verbindung zum Klienten mittels des übergebenen IP/Port-Paares etabliert. Der entfernte Client sendet nun einen einzigen ASCII-Char '1' (ASCII 49). Daraufhin sendet man den String „Get“ in einem einzigen Paket, gefolgt von <mynick> "<filename>" <offset>. Offset bedeutet, das man den download eines zuvor begonnenen, aber abgebrochenen Stückes fortsetzen kann. Als letztes erhält man entweder eine Fehlernachricht mit „Invalid Request“ oder „File Not Shared“ oder der Transfer beginnt, mit der Nennung der Dateigröße, gefolgt von dem Datenstrom der eigentlichen Datei.