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.
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 für ihn unbefriedigende Verfügbarkeit von Musikdateien wuchs in Fanning der Wunsch nach einem Programm, dass die vornehmlich als mp3-Dateien verfügbare digitale Musik 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, seinem Spitznamen im IRC. Unterstützt wurde er über dem IRC von w00w00, die ihm 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 programmiert bis 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ötzlich angestiegene Bekanntheit 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, der zwischen den anbietenden und suchenden Klienten vermittelt. Erst nach Erhalt von Suchergebnissen vom Napster-Server kann der Musikdownload starten.
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 auch 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-Server-Kommunikation
Besitzt das lokal installierte Napster-Programm keine Registrierungsdaten, so werden diese beim ersten Starten des Programms vom Nutzer verlangt, um dann die Nachricht 6 new user login mit dem Inhalt <nick> <pass> <port> "<client-info>" <speed> <email-address> an den Server zu senden. Zuvor wird überprüft mit 7 nick check <nick>, ob der Nutzername gültig ist und entweder mit 8 nickname not registered, 9 nickname already registered, oder 10 (0x0a) invalid nickname quittiert. Beim späteren login mittels 2 login mit dem Inhalt <nick> <pass> <port> "<client-info>" <speed> wird nur die e-mail-Adresse weggelassen. <speed> ist eine Kodierung von 0 bis 10 für die unterschiedlichen Verbindungsgeschwindigkeiten von 14,4kbit/s-Modem bis T3 oder größer bzw. unbekannt. "<client-info>" enthält die Versionsnummer vom installierten Napster. Eine erfolgreiche Anmeldung am Server wird durch die Nachricht 3 login ack und der bei der Registrierung angegebenen E-mail-Adresse dem Klienten mitgeteilt. Nach der Anmeldung übermittelt der Klient eine Liste der lokal verfügbaren Dateien an den Server: 100 (0x64) client notification of shared file mit dem Inhalt "<filename>" <md5> <size> <bitrate> <frequency> , zum Beispiel "beispiel band - beispiel song.mp3" a92870e0d41bc8a698cf2f0a1ddfeac6 1234567 128 44100 83.
Client-Client-Kommunikation
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.
Firewalled Downloading
Wie oben beschrieben, wenn der entfernte Klient in der 204 (0xcc) get ack als Data Port den Wert 0 erhält, so bedeutet dies, dass der anbietende Klient hinter einer Firewall sich befindet und diese keine eingehenden Verbindungen zuläßt. Nun muss an den Server die Nachricht 500 (0x1f4) alternate download request mit <nick> "<filename>" gesendet werden, damit der hochladende Klient die Datei an den Empfänger pusht, indem der Server ihn mit der Nachricht 501 (0x1f5) alternate download ack mit dem Inhalt <nick> <ip> <port> "<filename>" <md5> <speed>, identisch zum normalen Download-Ack 204, damit beauftragt. Der Anbieter startet nun den den Aufbau der TCP-Verbindung zu IP:Port, erhalten mit der 501-Nachricht. Der Downloader bestätigt mit dem dem ASCII-Zeichen '1'. Nun sendet der Uploader den String 'SEND' in einem Paket, gefolgt von <mynick> "<filename>" <size>, der vom Downloader entweder mit einem Byte-Offset in ASCII-Ziffern, bei dem der Transfer starten soll, wobei 0 der Anfang einer Datei darstellt, oder eine Fehlermeldung wie "Invalid Request" erwidert wird. Beide senden an den Server 218 (0xda) downloading file/219 (0xdb)download complete-Nachrichten bzw. 220 (0xdc)uploading file/221 (0xdd)upload complete
Client-Client-Browsing
Ab Version 2.0 Beta 8 unterstützte Napster das sogenannte Client-Client-Browsing, womit Nutzer das Angebot von Musikdateien eines anderen Nutzers durchstöbern konnten. Mit der Nachricht 640 <nick> an den Server sendet der Server 640 <requester> an den Empfänger <nick>. Bewilligt <nick> den Browse-Request, sendet dieser 641 <requestor> und erhält vom Server die Antwort 641 <nick> <ip> <port> Falls ein Fehler auftritt oder keine Einwilligung besteht wird vom Server an den Anfragenden ein 642 direct browse error mit dem Inhalt <nick> "message" verschickt. Sonst wird eine TCP-Verbindung zu IP:Port aufgebaut, und der Anfragende muss mit einem ASCII-Zeichen "1" bestätigen, gefolgt von dem String GETLIST. Der Uploader antwortet mit <nick> und einem Zeilenumbruchzeichen (\n), gefolgt von einer Liste von 100 (0x64) client notification of shared file mit dem Inhalt "<filename>" <md5> <size> <bitrate> <frequency>
Open Napster
Copyright
Quellen
OpenNap.Sourceforge
Janko Röttgers: "Mix, Burn & R.I.P", ISBN: 3936931089