OpenNap war ein freier Klon des Filesharingprogramms Napster. OpenNap bot die gleiche Grundfunktionalität wie damalige Napster-Server, dazu gehörte die Suche nach Dateien, Hoch- und Herunterladen von Dateien, Durchstöbern von Dateien eines anderen Benutzers und eine Chat-Funktion sowohl zwischen zwei einzelnen Benutzern als auch auf Basis von öffentlichen Räumen. Zudem war es möglich mehrere Server miteinander zu verbinden, um mehr Clients miteinander zu verlinken.
OpenNap war ein Kommandozeilenprogramm ohne graphische Benutzeroberfläche und ließ sich auf vielen POSIX-konformen Systemen einsetzen (z. B. Linux, Unix oder BSD). Auch Windows wurde unterstützt. Weil es sich um freie Software handelte, kann jeder einen Server aufsetzen. Seit Ende 2001 wird OpenNap allerdings nicht mehr entwickelt (s. Geschichte).
Neben den Grundfunktionen von Napster wurden auch neue hinzugefügt. So war es zum Beispiel möglich, nicht nur MP3-Dateien zu tauschen, sondern beliebige Dateitypen. Die Chatfunktionalität wurde derart erweitert, dass es für Chat-Räume (ähnlich wie bei IRC) Benutzer mit besonderen Rechten gab.
Trotz des in die Jahre gekommenen Konzepts erfreuten sich OpenNap und seine Abkömmlinge noch großer Beliebtheit. Eine Liste von aktiven Servern konnte lange Zeit bei Napigator abgerufen werden. Seit Ende April 2004 existiert dieser Service aber nicht mehr, weswegen zwei neue (von Privatpersonen betriebene) entstanden sind, gotnap.com und naplist.com was zwischenzeitlich wieder abgeschaltet wurde.
Das Projekt OpenNap wurde im Januar 2000 bei SourceForge von drscholl registriert. Das Napster-Protokoll wurde dabei durch Reverse Engineering ermittelt und veröffentlicht. Das ermöglichte, dass verschiedene Clients geschrieben werden konnten. Diese konnten auch am originalen Napster-Netz teilnehmen.
StreamCast Networks unterhielt während des OpenNap-Booms einige professionelle Server mit dem Namen MusicCity, die bis zu 20000 Benutzer verwalten konnten. Im April 2001 wurden diese aber vom Netz genommen und kurze Zeit darauf der Peer-to-Peer-Client Morpheus gestartet, der einige Zeit sehr populär war und ursprünglich das FastTrack-Netz benutzte.
Nachdem drscholl Probleme mit der RIAA bekommen hatte und die Server, die er für Testzwecke benutzt hatte, geschlossen wurden, resignierte er Ende 2001 und stellte die Entwicklung von OpenNap ein.
Die wichtigsten Clients (neben dem offiziellen Client) waren für Windows FileNavigator, AudioGnome und WinMX, für Linux TekNap, GNapster und Lopster, und auf Basis von Java XNap. Die meisten davon werden schon längere Zeit nicht mehr entwickelt. Die einzigen Clients, die davon noch entwickelt wurden, waren Lopster und XNap.
Nachfolgende Beschreibung gilt auch für das (nicht mehr existierende) originale Napster-Protokoll.
Das OpenNap Netzwerk besitzt eine klassische Sterntopologie. Es gibt einen zentralen Server, der alle Clients bedient. Eine Erweiterung davon ist, dass mehrere Server miteinander verbunden werden können, damit die Last auf verschiedene Rechner verteilt wird. Die Anfragen eines Clients werden dann zu den anderen Servern weitergeleitet und das Ergebnis zum Client zurückgeliefert.
Freigegebene Dateien werden auf dem Server indiziert. Das bedeutet, dass ein Client nach dem Einloggen eine Liste dieser Dateien zum Server sendet. Unterstützt werden dabei beliebige Dateitypen. Startet ein Benutzer eine Suche, so wird diese dem Server übergeben, der daraufhin seine aktuelle Datenbank zu Rate zieht. Die Ergebnisse werden dem Client samt IP-Adresse des besitzenden Benutzers übermittelt. Soll das Herunterladen gestartet werden, wird ein Teil des Handshakes über den Server abgewickelt und erst wenn das Herunterladen vom Besitzer der Datei erlaubt wird, wird eine direkte Verbindung zwischen den beteiligten Parteien hergestellt.
Einer der großen Nachteile von OpenNap ist, dass es keine Prüfsummen oder Hash-Werte für Dateien gibt (obwohl das Protokoll MD5-Summen vorsieht, was auch implementiert ist, aber es kam praktisch nie zum Einsatz). Die Folge ist, dass bei Dateiübertragungen Fehler auftreten können, die unbemerkt bleiben.
Abgebrochenes Herunterladen kann fortgesetzt werden (resume). Dies bedeutet automatisch, dass das gleichzeitige Laden einer Datei von mehreren Quellen möglich ist. Einer der Clients, der dies implementiert, ist Lopster.
Die Kommunikation zwischen Server und Client setzt auf TCP/IP auf und wird über Befehle abgewickelt, die aus einem binären Kopf und einem ASCII-Rumpf bestehen. Der Kopf beinhaltet zwei vorzeichenlose, ganzzahlige 16-bit Werte im Little-Endian-Format. Der erste Wert spezifiziert die Länge des Rumpfes und der zweite die Art des Befehls.
| Kopf | Rumpf | |
| Länge | ID | Argumente durch Leerzeichen getrennt |
| 16-bit | 16-bit | ASCII Daten der Länge wie im Kopf definiert |
Der Rumpf wird – abhängig von der Art des Befehls – als Anreihung von Argumenten, die durch Leerzeichen (0x32) getrennt werden, interpretiert. Argumente, die selbst ein Leerzeichen enthalten können (wie zum Beispiel Dateinamen) werden von Anführungsstrichen umschlossen.
Die Protokollspezifikation schränkt die Größe der freigegebenen Dateien nicht ein. Derzeit wird sie allerdings sowohl durch die Server- als auch Clientimplementierungen auf 32 bzw. 31 Bits (4 GiB bzw. 2 GiB) limitiert.
Eine relativ genaue Spezifikation des Protokolls findet man auf den Homepages der Serverimplementierungen.
Seit 2001 sind ein paar Server entstanden, die als Grundlage die letzte Version von OpenNap benutzen. Der bekannteste davon ist OpenNap-NG.[1] Die wichtigste Neuerung ist, dass die Kommunikation zwischen Server und Client komprimiert werden kann, um Bandbreite zu sparen und so mehr Clients zu bedienen.
Allerdings soll laut der opennap-ng.org Webseite der Code des SourceForge-Projekts auf einem drei Jahre alten Code basieren. Nach einem Disput trennte sich einer der Admins, um das Projekt unter eigenem Dach weiter zu führen, während das ursprüngliche Projekt seine Arbeit an altem Code weiter führt.
Beide Projekte konkurrieren um den Namen OpenNap-NG.
SlavaNap ist ein Server für das Betriebssystem Windows mit einer grafischen Oberfläche. Er besitzt im Grunde dieselbe Funktionalität wie OpenNap. SlavaNap wurde bis zur Version 2.3.0 unter der GNU General Public License entwickelt, ist mittlerweile aber Closed Source.
CleanNap ist eine plattformunabhängige Implementierung im Alpha-Stadium, deren Entwicklung im Juni 2004 wieder aufgenommen wurde. Laut Homepage wurde sie im Juli 2004 wieder eingestellt.