Napster - Revision history

Dneumann: /* Client-Server-Kommunikation */

2006-03-02T16:25:30Z

Client-Server-Kommunikation

← Older revision		Revision as of 16:25, 2 March 2006
Line 15:		Line 15:
	Für die Client-Server-Kommunikation wird TCP eingesetzt, typischerweise auf den Ports 8888 und 7777. Jede Nachricht hat die Form ''<length><type><data>'',wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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.		Für die Client-Server-Kommunikation wird TCP eingesetzt, typischerweise auf den Ports 8888 und 7777. Jede Nachricht hat die Form ''<length><type><data>'',wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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 ==		== 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> <time>'', zum Beispiel ''"beispiel band - beispiel song.mp3" a92870e0d41bc8a698cf2f0a1ddfeac6 1234567 128 44100 83''.		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> <time>'', zum Beispiel ''"beispiel band - beispiel song.mp3" a92870e0d41bc8a698cf2f0a1ddfeac6 1234567 128 44100 83''.
	<br>		<br>

Dneumann: /* Architektur */

2006-03-02T16:23:59Z

Architektur

← Older revision		Revision as of 16:23, 2 March 2006
Line 11:		Line 11:
	=Architektur=		=Architektur=
	Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Server-Kommunikation zentralen Server] benötigt, der zwischen den anbietenden und suchenden Klienten vermittelt. Erst nach Erhalt von Suchergebnissen vom Napster-Server kann der [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Client-Kommunikation Musikdownload] starten.<br>		Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Server-Kommunikation zentralen Server] benötigt, der zwischen den anbietenden und suchenden Klienten vermittelt. Erst nach Erhalt von Suchergebnissen vom Napster-Server kann der [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Client-Kommunikation Musikdownload] starten.<br>
	[[Image:Napster_hierarchie.gif\|Napsters Architektur]]		[[Image:Napster_hierarchie.gif\|Napsters Architektur]] <br>
⚫	== Client-Server-Kommunikation ==
	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.		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><data>'',wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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.
	Für die Client-Server-Kommunikation wird TCP eingesetzt, typischerweise auf den Ports 8888 und 7777. Jede Nachricht hat die Form<br>
		⚫	== Client-Server-Kommunikation ==
	<center>''<length><type><data>'',</center>
			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> <time>'', zum Beispiel ''"beispiel band - beispiel song.mp3" a92870e0d41bc8a698cf2f0a1ddfeac6 1234567 128 44100 83''.
⚫	wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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.
	<br>		<br>

	== Client-Client-Kommunikation ==		== 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“.		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“.

Dneumann: /* Client-Client-Browsing */

2006-03-02T15:44:53Z

Client-Client-Browsing

← Older revision		Revision as of 15:44, 2 March 2006
Line 29:		Line 29:
	=== Client-Client-Browsing ===		=== 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> <time>, und einem Zeilenumbuch als Trennungszeichen. Am Ende der Liste wird ein weiterer Zeilenumbruch eingefügt und die Verbindung beendet. Dies ist das gleiche Vorgehen wie bei der Anmeldung nach dem Login am Server zum Bekanntmachen der zum Sharen verfügbaren lokalen Dateien.<br>		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> <time>, und einem Zeilenumbuch als Trennungszeichen. Am Ende der Liste wird ein weiterer Zeilenumbruch eingefügt und die Verbindung beendet. Dies ist das gleiche Vorgehen wie bei der Anmeldung nach dem Login am Server zum Bekanntmachen der zum Sharen verfügbaren lokalen Dateien.<br>
	Sollte der Uploader hinter einer Firewall sich befinden, muss die Datei an den anfragenden Klienten ''gepusht'' werden, also eine ausgehende TCP-Verbindung etabliert werden mit dem String ''SENDLIST'' als einzigen Unterschied zu obigem Vorgehen.		Sollte der Uploader hinter einer Firewall sich befinden, muss die Datei an den anfragenden Klienten ''gepusht'' werden, also eine ausgehende TCP-Verbindung etabliert werden mit dem String ''SENDLIST'' anstatt ''GETLIST'' als einzigen Unterschied zu obigem Vorgehen.

	=Open Napster=		=Open Napster=

Dneumann: /* Client-Client-Browsing */

2006-03-02T15:40:38Z

Client-Client-Browsing

← Older revision		Revision as of 15:40, 2 March 2006
Line 28:		Line 28:

	=== Client-Client-Browsing ===		=== 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> <time>, und einem Zeilenumbuch als Trennungszeichen. Am Ende der Liste wird ein weiterer Zeilenumbruch eingefügt und die Verbindung beendet. Dies ist das gleiche Vorgehen wie bei der Anmeldung nach dem Login am Server zum Bekanntmachen der zum Sharen verfügbaren lokalen Dateien.<br>
			Sollte der Uploader hinter einer Firewall sich befinden, muss die Datei an den anfragenden Klienten ''gepusht'' werden, also eine ausgehende TCP-Verbindung etabliert werden mit dem String ''SENDLIST'' als einzigen Unterschied zu obigem Vorgehen.

	=Open Napster=		=Open Napster=

Dneumann: /* Firewalled Downloading */

2006-03-02T15:12:58Z

Firewalled Downloading

← Older revision		Revision as of 15:12, 2 March 2006
Line 25:		Line 25:

	=== Firewalled Downloading ===		=== Firewalled Downloading ===
	Wie oben beschrieben, wenn der entfernte Klient in der ''204 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 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 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-~~Verbundung~~ 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 downloading file/219 download complete''-Nachrichten bzw. ''220 uploading file/221 upload complete''		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 ===		=== Client-Client-Browsing ===

Dneumann: /* Firewalled Downloading */

2006-03-02T15:10:30Z

Firewalled Downloading

← Older revision		Revision as of 15:10, 2 March 2006
Line 25:		Line 25:

	=== Firewalled Downloading ===		=== Firewalled Downloading ===
			Wie oben beschrieben, wenn der entfernte Klient in der ''204 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 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 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-Verbundung 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 downloading file/219 download complete''-Nachrichten bzw. ''220 uploading file/221 upload complete''

	=== Client-Client-Browsing ===		=== Client-Client-Browsing ===

Dneumann: /* Architektur */

2006-03-02T14:40:40Z

Architektur

← Older revision		Revision as of 14:40, 2 March 2006
Line 10:		Line 10:

	=Architektur=		=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.<br>		Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Server-Kommunikation zentralen Server] benötigt, der zwischen den anbietenden und suchenden Klienten vermittelt. Erst nach Erhalt von Suchergebnissen vom Napster-Server kann der [http://sarwiki.informatik.hu-berlin.de/Napster#Client-Client-Kommunikation Musikdownload] starten.<br>
	[[Image:Napster_hierarchie.gif\|Napsters Architektur]]		[[Image:Napster_hierarchie.gif\|Napsters Architektur]]
	== Client-Server-Kommunikation ==		== Client-Server-Kommunikation ==

Dneumann: /* Architektur */

2006-03-02T14:33:34Z

Architektur

← Older revision		Revision as of 14:33, 2 March 2006
Line 10:		Line 10:

	=Architektur=		=Architektur=
	Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen zentralen Server benötigt. <br>		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.<br>
	[[Image:Napster_hierarchie.gif\|Napsters Architektur]]		[[Image:Napster_hierarchie.gif\|Napsters Architektur]]
	== Client-Server ==		== Client-Server-Kommunikation ==
	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.		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<br>		Für die Client-Server-Kommunikation wird TCP eingesetzt, typischerweise auf den Ports 8888 und 7777. Jede Nachricht hat die Form<br>
Line 18:		Line 18:
	wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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.		wobei ''<length>'' und ''<type>'' jeweils 2 byte lang sind, in little-endian kodiert. Der Wert ''<length>'' gibt die Länge von ''<data>'' 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 [http://opennap.sourceforge.net/napster.txt 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.
	<br>		<br>
	== Client-Client ==		== 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“.		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“''.		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“''.

Dneumann: /* Geschichte */

2006-03-02T14:27:45Z

Geschichte

← Older revision		Revision as of 14:27, 2 March 2006
Line 7:		Line 7:
	=Geschichte=		=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.		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=		=Architektur=

Dneumann: /* Architektur */

2006-03-02T14:20:35Z

Architektur

← Older revision		Revision as of 14:20, 2 March 2006
Line 10:		Line 10:

	=Architektur=		=Architektur=
	Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen zentralen Server benötigt.		Napster ist eine Tauschbörse der ersten Generation, die zum Auffinden von Dateien des Typs mp3 einen zentralen Server benötigt. <br>
			[[Image:Napster_hierarchie.gif\|Napsters Architektur]]
	== Client-Server ==		== 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.		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.