DIE PERFEKTE EINRICHTUNG DES EDONKEY-2000 SERVERS v16.38
Zum technischen eDonkey2000 Forum bei Parsimony
Impressum (nach §6 und §7 TDG)
Last Update: 25.Februar 2003 (Änderungen zur vorherigen Version sind jeweils ROT hervorgehoben!)
Diese Seite befindet sich stets 'Under Construction', ständige Aktualisierungen sind üblich! Bei Interesse darf auf diese Seite gern und ungefragt ein Link gesetzt werden. Eine Kopie dieser Seite auf dem eigenem Webspace anzubieten, ist schon wegen der häufigen Aktualisierungen kontraproduktiv und daher von mir auch nicht gestattet!
Einleitung
Warum soll ich einen eDonkey-Server betreiben???
Netzpiraten
Die rechtliche Seite
Das eDonkey 2000 System an sich
Benötigte Hardware eines eDonkey-Servers
Benötigte Netzanbindung
ServerClient
DynDNS
Neue Probleme
Und deren Lösung
Server-Betriebssystem
Installation des Servers unter Windows 2000 und XP
Installation des Servers unter Linux
Die Konfiguration der 'donkey.ini'
Serverbefehle
Fehlersuche
Automatisierung
Automatisierung unter Linux
Netzwerk-Optimierungen für den Serverbetrieb unter Linux
Automatisierung unter Windows 2000 und XP
Schlussendlich
Das eDonkey-2000 System besteht erst seit etwa 18 Monaten, aber schon weit über eine halbe Million User nutzen dieses System, und etwa 450.000 User sind ständig mit den Servern verbunden. Ich bedaure sehr, daß uns Berichte in Fachzeitschriften und Web-Publikationen nicht so recht weiter voranbringen, denn es mangelt ständig an Serverkapazitäten, um weitere User aufnehmen zu können. So erhalten viele neue User nur ein lapidares "Can´t connect to: 80.0.71.239", anstatt endlich unseren "Esel" nutzen zu können.
Um bisherigen Nutzern, die mit dem Esel zufrieden sind, den Weg zum eigenen eDonkey-Server etwas zu erleichtern, habe ich alle zum Serverbetrieb notwendigen Informationen in diesem Dokument zusammengestellt. Ich hoffe, ich habe nichts vergessen, was gerade DU unbedingt noch wissen wolltest.
Lasst Euch nicht vom Umfang dieser Anleitung abschrecken. Der Betrieb eines eDonkey-2000 Servers gestaltet sich weit einfacher, als es die Länge meiner Anleitung vermuten läßt. Vielmehr wird hier auf jede Einzelheit eingegangen, jedes Problem, das im Betrieb auftreten kann, wird hier - hoffentlich - genannt. Es sollten also keine Fragen offen bleiben. Beschrieben werden das System an sich, die Installation des Servers auf den verschiedenen Betriebssystemen, die Bedeutung der einzelnen Parameter der ini-Datei. Es schließen sich Abstimmungs-Tipps bezüglich Rechnerleistung, Bandbreite der Netzanbindung und maximal möglicher Leistung des Servers an.
So holt man den maximalen Nutzen für die User aus der Hardware, OHNE dafür unnötig Geld auszugeben.
Regelmäßig etwa alle einhundert Postings fragen Leute in unserem Forum:
'Was bringt es mir, einen eigenen Server zu betreiben???'
Ich habe keine Ahnung, was ich denen antworten soll, ehrlich nicht. Es gibt wirklich keine sachlichen Gründe, die - bei einer auf rein private Gewinnmaximierung ausgelegten Grundgesinnung - für den Betrieb eines eigenen eDonkey-Servers sprechen würden. Der eigene Download geht keinen Deut schneller, der eigene Upload erst recht nicht. Niemand zahlt Euch etwas für den Server, er verbraucht Strom, Netzkapazität, macht Lärm, kann nicht bei eBay verkauft werden und man muß ihn auch noch dauernd abstauben. Also wirklich... Eine Sache bliebe vielleicht noch: Im Connect-Text des Servers kann man die eigene Homepage, oder auch Hüfthalter und Einlegesohlen anpreisen. Wer also an dieser Stelle verwundert die Augenbrauen hochzieht und eher selten Hüfthalter trägt, der möge sich das weitere Studium dieser Anleitung ersparen und stattdessen lieber den Börsenkurs der Telekom-Aktie beobachten. Ein eD2k-Server ist aber definitiv nix für ihn.
Sollen doch andere...
Was motiviert die User, selbst eDonkey-Server zu betreiben? Wohl hauptsächlich die Suche nach Anerkennung in der Gemeinschaft und der Wunsch nach Stärkung der P2P Filesharing-Systeme, welche ja noch recht jung sind. Dann wären da sicher auch noch politische Motive (Urheberrecht/Patentrecht). Solche Beweggründe haben jedenfalls meine Entscheidung maßgeblich beeinflusst, den Little Red Corvette-Server bis heute in Betrieb zu halten. Man muß sich aber vor Augen halten, daß der Betrieb eines Servers für den Betreiber nicht ganz umsonst zu haben ist: Der Server-Rechner kann meist nicht mehr sinnvoll für andere Dinge genutzt werden, da die Systemlast recht hoch ist. Die meisten (in Deutschland) dürften wohl Ihre DSL Flatrate-Zugänge für den Server benutzen. Dann heißt es ggf., sich auch mal mit verringerter Bandbreite beim "Websurfen" zufriedenzugeben. Denn je nach Größe benötigt ein eDonkey-Server doch ein wenig Bandbreite. Da jedoch "der Esel", wie wir ihn liebevoll nennen, für viele schon zu einer Weltanschauung, ja fast schon zu einer Art von Religion geworden ist, scheuen wir keine Mühen und Kosten, um ihn zu unterstützen.
An dieser Stelle möchte ich es nicht versäumen, auf das Buch
hinweisen. Es beschreibt wirklich treffend die Zusammenhänge und das Zustandekommen der Netzkultur, sowie viele Phänomene wie P2P-Netzwerke, Cracker, Hacker (und ihre Ethik), Viren und was da drausen sonst noch so alles rumwuselt. Eine lohnende Lektüre. Am besten, Ihr kauft Euch das Buch ganz normal im Laden. Wer es sich wirklich nicht leisten kann - oder wer schon jetzt so neugierig ist, daß es es sofort online lesen möchte - der lädt es sich runter, liest es und kauft es sich dann. OK? Ich finde, eine gute Schreibe sollte unbedingt auch belohnt werden! Mein ganz persönlicher Dank geht an den Heise-Verlag in Hannover (c't, iX, TELEPOLIS), der auch dieses Buch verlegt hat. Diese fähigen Leute bringen wirklich nur das beste auf's Papier. Einen winzigen Auszug konnte ich mir trotz aller rechtlichen Bedenken aber nicht verkneifen:
Sie sind unsichtbar. Sie sind überall. Sie verändern die Welt.
So klängen die Werbeslogans, wäre die folgende Piratengeschichte für das
Kinopublikum produziert worden. Aber das einzige, was sich die Traumfabrikanten an
dieser Geschichte ausgesucht haben, ist der Titel: »Piraterie«, ein verstaubtes Zauberwort
aus Hollywoods Klamottenkiste, soll einem ungleichen Duell zu etwas mehr
Anschaulichkeit verhelfen. In der Rolle der Guten sehen sich in dieser Geschichte die
Vorstandsvorsitzenden, Pressesprecherinnen und Rechtsanwälte der »Copyright
Industries« - allen voran Plattenlabels, Filmstudios und Softwareschmieden. Die Rolle der
Bösen - mit dieser Besetzung hatten selbst die erfahrenen Studiobosse nicht gerechnet -
geht an das Publikum. Und der Plot scheint für die Unterhaltungsindustrie ein ziemlicher
Horrortrip zu sein....
Vielen stellt sich vielleicht die Frage, ob sie sich mit dem Betrieb eines eDonkey-Servers strafbar machen, oder sonst irgendwie verklagt werden könnten. Nicht nur "Napster" wurde von den Organisationen, die das Urheberrecht verteidigen, verklagt, und so in die Knie gezwungen.
Disclaimer: Es sei an dieser Stelle ganz klar gesagt, daß ich kein Jurist bin! Alles, was ich dazu sagen kann habe ich bisherigen Urteilen in Deutschland und den USA entnommen, sowie Erfahrungen anderer Serverbetreiber. Also bitte verklagt mich nicht, wenn sich doch einmal Ärger in welcher Form auch immer anbahnen sollte.
Bisher ist es so, daß der Betrieb eines Filesharing-Indexservers "eigentlich" nicht gegen bestehendes Recht verstößt. Da von den Servern keine urheberrechtlich geschützten Werke zum Download angeboten werden, erscheint das auch logisch. Spitzfindige Anwälte haben in den USA (im Verfahren gegen Napster) vor Gericht argumentiert, der Betrieb eines solchen Indexservers stelle eine "Beihilfe zum Urheberrechtsbruch" dar. Bekanntlich befindet man sich auf See und vor Gericht in Gottes Hand, der Ausgang eines Verfahrens in Deutschland wäre meiner Meinung nach völlig offen. Im Gegensatz zu Firmen wie Napster, die durch ihre zentrale Struktur rechtlich leicht angreifbar sind, werden die eDonkey-Server jedoch ausschließlich von vielen autonom agierenden, privaten Netzbürgern betrieben. Jeder einzelne von ihnen müßte ein einem einzelnen Verfahren vor Gericht gebracht werden. Keine verlockenden Aussichten für potentielle Kläger ;-)
Es ist allerdings schon vorgekommen, daß Internet Service Provider (ISP's) von Organisationen, die sich die Durchsetzung des Urheberrechtes auf ihre Fahne geschrieben haben, gebeten wurden, im konkreten Fall für Unterlassung zu sorgen. Der ISP schreibt seinen Kunden an und "verwarnt" ihn, demnächst keine ueheberrechtlich geschützen Werke mehr zum Download anzubieten. Sonst passiert nichts. Es handelte sich in diesen konkreten Fällen aber auch nicht um eDonkey Serverbetreiber, sondern um normale Teilnehmer von Napster, Gnutella oder eDonkey2000 und nicht um Serverbetreiber. Ich betreibe meinen eDonkey-Server nunmehr ununterbrochen seit März 2001 und habe bislang keinerlei Ärger bekommen. Nicht einmal mein ISP hat sich über den heftigen Traffic beschwert.
Das System selbst wurde konzipiert als ein Hybride, bestehend aus den besten Konzepten der NAPSTER- und GNUTELLA-Projekte, sowie eigener Ideen. Es soll die Vorteile der Systeme in sich vereinen, deren Nachteile jedoch vermeiden. Wenn man sich das Systemkonzept näher ansieht, wird man zweifellos zu dem Schluß kommen, daß dieses Ziel erreicht wurde. OK, kleinere Macken (z.B. umständliches IP-Adressen-Update beim Server nach der Neuzuweisung einer IP vom ISP, mangelnde DynDNS Fähigkeiten (DNS-Auflösung) oder die Server-IP-Bestimmung beim Client) bestehen noch. Aber bitte bedenkt, daß das eDonkey-System erst wenig älter als ein Jahr ist. Es stehen also noch größere Updates an.
Hier ist erkennbar, wer mit wem welche Informationen austauscht. Nicht eingezeichnet sind die Verbindungen der Server untereinander: Sie übermitteln untereinander in regelmäßigen Abständen die IP-Adressen aller ihnen bekannten Server. So verfügt auch ein gerade neu hinzugekommener Server sofort über eine Datenbank aller im System vorhandenen Server, wenn er bei mindestens einen Server angefragt hat. Datei- und Userdaten übermitteln die Server aber nicht untereinander. Die benötigte Bandbreite würde sonst jedes Maß sprengen.
Ein Client benötigt die IP-Adresse (und den Port, wenn nicht der Standardport 4661 vom Server benutzt wird) eines Servers, um sich mit ihm zu verbinden. Da die Serveradressen sich wegen der häufigen Nutzung von privaten Flatrates oft und regelmäßig verändern können, ist dies gleichzeitig die größte Schwachstelle im System. Es kann nämlich durchaus passieren, daß der Client keine gültige IP-Adresse eines Servers kennt. Ein Connect ist dann natürlich unmöglich. Inzwischen gibt es aber verschiedene Möglichkeiten, gültige Server-IP's zu ermitteln. Viele Serverbetreiber mit täglich wechselnder IP-Adresse haben sogenannte Redirektoren eingerichtet (DynIP/DynDNS/...), mit deren Hilfe sich aus einer unveränderlichen URL die dazugehörige IP-Adresse ermitteln läßt (z.B. "Little Red Corvette"-Server: "lrc.dyndns.org"). Bei einer DNS-Auflösung (z.B. mittels "ping lrc.dyndns.org") nennt der DNS-Server die z.Zt. gültige IP-Adresse (z.B. "217.5.78.72"). Sie kann nun direkt im Client eingetragen und der Server damit connectet werden. Auch gibt es Webseiten und Foren mit Links zu Server-Adresslisten wie z.B. Maurices Serverliste oder die offizielle Serverliste. Das wichtigste Ziel dieses auf den ersten Blick kompliziert anmutenden Verfahrens ist, das System möglichst unangreifbar zu machen. Es gibt nicht mehr den EINEN Serverbetreiber (wie bei NAPSTER), der das System am Leben erhält. JEDERMANN kann einen Server betreiben. Fällt ein Server aus, bleibt das System als ganzes trotzdem funktionsfähig. Es fehlt dann eben nur der eine Server. Zum anderen eröffnet dieses Verfahren die Möglichkeit, Server mit dynamisch zugewiesenen IP-Adressen einzusetzen. Kaum ein User besitzt eine Standleitung mit statischer, immer gleicher IP-Adresse. Den allermeisten wird jeweils beim Verbindungsaufbau von ihrem Internet Service Provider (ISP) eine für meist 24 Stunden gültige IP-Adresse zugewiesen. Der Sinn von ständigen Neuzuweisungen der IP-Adresse von Seiten des ISP ist (man ahnt es): Kostensenkung! Traffic kostet Geld, viel Traffic kostet teilweise sehr viel Geld. Wenn sich aber die IP-Adresse eines Internetzuganges alle 24 Stunden ändert, kann der Kunde keine Serverdienste anbieten, die möglicherweise ein hohes (und für den ISP teures) Datenvolumen mit sich bringen. Die Besucher des Server wüßten ja nicht, WELCHE IP-Adresse der Server z.Zt. gerade besitzt. Wie gut, daß es (teilweise sogar kostenlose) Dienste wie http://www.dyndns.org/ gibt, denn so läßt sich der 24 Stunden IP-Falle ein Schnäppchen schlagen...
Als Rechner kann jeder Rechner ab etwa Pentium 100 verwendet werden. Allerdings sollte er über mindestens 128MB-RAM verfügen, denn die Daten müssen für schnelle Suchergebnisse komplett im RAM zur Verfügung stehen. Es ist nicht möglich, eine Auslagerungsdatei auf Festplatte zu benutzen, da dies den Suchvorgang extrem verlangsamen würde. Um Rechner mit geringer Leistung wie den hier genannten Pentium 100 sinnvoll als Server nutzen zu können, ist es notwendig, die Zahl der gleichzeitig mit dem Server verbundenen Clients sinnvoll zu begrenzen. Meiner Erfahrung nach verträgt ein Pentium 100 unter Linux (als ressourcenschonenstes Betriebssystem) maximal 500 Clients mit dem normalen eD2k-Server (der Lugdunum-Server benötigt nur etwa 10% der bisherigen Rechenleistung und kann daher auch auf schwächeren Maschinen eingesetzt werden). Darüber hinaus kommt es zu Rechnerblockaden und Paketverlusten. Überlastungen sind unbedingt zu vermeiden, sonst ist der Nutzen für die Clients nicht mehr gegeben. Der Rechner "vergißt" IP-Adressen anderer Server (UDP-Paketverluste) und beantwortet Suchanfragen teilweise nicht mehr. Es gilt hier, durch Versuche die richtige Mischung zu finden zwischen Rechenleistung, RAM-Speichergröße und Netzzugangskapazität.
Benötigt werden der TCP-Port 4661 sowie der UDP-Port 4665 (wenn der originale Port in der donkey.ini nicht geändert wurde)!
Weshalb ich das so groß geschrieben habe? Das wird immer so gerne überlesen und hinterher wundert sich alle Welt, warum der Server nicht funktioniert. Falls die Netzverbindung über eine Firewall oder einen Router mit Umsetzung auf private IP-Adressen (Network Adress Translation, NAT, Masquerading) geleitet wird, müssen die benötigten Ports im Router freigegeben und auf die benutzte private IP-Adresse des Serverrechners "gemapt" werden. Der Router, welcher die Umsetzung vornimmt, muß also wissen, an welche private IP-Adresse er die genannten Ports "umleiten" muß. Eine allgemeine Anleitung kann aufgrund der Vielzahl der am Markt vorhandenen Systeme an dieser Stelle nicht gegeben werden. Dafür bitte die Anleitung des Routers, der Router-Software, bzw. der benutzten Firewall zu Rate ziehen. Ein Tip am Rande: Windows XP bringt eine Firewall mit, welche die Funktion des Servers nachhaltig vereitelt, wenn sie nur einfach eingeschaltet wird! Will man sie nutzen und gleichzeitig einen eD2k-Server betreiben, muß man die entsprechenden Ports natürlich öffnen. Zur Überprüfung, ob der Server zugang zum gewählten TCP-Port hat, ist dieser Link zur Weiterleitungsprüfung überaus nützlich. (Thx to TheDonkeyNetwork)
>>> 'Zone-Alarm' eignet sich NICHT, um darüber einen eD2k-Server laufen zu lassen, weil 'Zone-Alarm' anscheinend sehr viel Rechenzeit vertrödelt, was bei dem großen Datendurchsatz eines eD2k-Servs sogar einen 2GHz-Rechner in die Knie zwingt. Ein eD2k-Server kann mehr als 1.000 IP-Pakete pro Sekunde (!) verarbeiten, und das kann diese Software nicht mehr leisten. Ich möchte weder die Software noch ihre Entwickler in irgendeiner Weise schlechtmachen, aber weil mir Serverbetreiber schon oft von Problemen mit dieser Software berichteten, muß ich unbedingt von ihrer Benutzung beim Serverbetrieb abraten.
Router-Support (für den Client! Für den Server die zusätzlichen Ports eintragen!) findet man auf unseren neuen Seiten:
Router und NAT und Die Parsimony-Routerdatenbank
Oft wenden sich Leute an mich, die den Server ums Verrecken nicht zum Laufen bekommen. Als Grund stellt sich in fast jedem dieser Fälle (nach meist längerer Zeit des Rumstocherns) eine Firewall oder ein Router heraus, wo die zum Betrieb des Servers notwendigen Ports blockiert bzw. nicht durchgeleitet sind. Es liegt auf der Hand, daß ich die Vielzahl der am Markt befindlichen Router- und Firewall-Systeme nicht kennen kann. Für einen ersten Funktionstest des Servers sollte man die Firewall unbedingt deaktivieren, um unnötige Probleme möglichst auszuschließen. Wenn man sie dann später wieder einschaltet und der Server läuft nicht mehr, weiß man wenigstens WO man suchen muß und kann die notwendigen Konfigurationen daran vornehmen. DSL-Router müssen aber von Anfang an richtig konfiguriert sein, wenn sie mit NAT (Network Address Translation/Masquerading) arbeiten. Hierzu nochmals ein Hinweis:
Der Server benötigt zwei Ports: Einen TCP-Port (default: 4661) und einen UDP-Port (default: 4665). Wird der Server in einem LAN mit privaten IP-Adressen (NAT) betrieben, müssen also die beiden Ports an die betreffende private IP des Server-Rechners weitergeleitet werden, weil sie sonst im Router verworfen werden und den Server nicht erreichen können (der Router hat keine Verwendung für Daten auf diesen Ports und weiß ohne Eintragungen in der Forwardingliste nichts damit anzufangen: Er verwirft sie dann einfach). Wird die Einstellung des Ports in der donkey.ini des Servers geändert (port=xxxx), verändern sich stets beide Ports (also der TCP und der UDP-Port). Der UDP-Port liegt aber immer 4 Portnummern über dem TCP-Port.
Beispiele (donkey.ini): "port=2000": TCP:2000, UDP:2004
oder auch bei "port=3939": TCP:3939, UDP:3943
Dann hätten wir noch die internen Firewalls bei DSL-Routern. Dort stellt sich meist schon nach kurzer Zeit heraus, daß diese Systeme mit der Menge an IP-Paketen eines eD2k-Server grob überlastet sind. Es kosten einfach zuviel CPU-Leistung, jedes einzelne IP-Paket (zusätzlich zur normalen Auswertung im System) nochmals zu öffnen, den Inhalt zu analysieren und zu prüfen, ob auch wirklich keine Käfer drin rumkrabbeln. Hardware-Router zum an die Wand hängen, sind ab 500 Usern mit solcher Analyse am Ende. Dies ist die Antwort auf die Frage, weshalb manche Server nicht mal 500 User 'schaffen', obwohl sie doch auf Gigaherz-Hardware laufen... Da hilft nur die Abschaltung der internen Firewall im Router. Die Router-CPU wird entlastet und es läuft wieder.
Die Bandbreite der Netzverbindung lässt sich nicht generell beziffern. Abhängig von der Menge der mit dem Server connecteten Clients und der Beanspruchung durch Suchanfragen schwankt die benötigte Bandbreite recht erheblich. Es gilt hier also das gleiche, wie schon oben bei der benötigten Hardware beschrieben. Ein ISDN-Anschluss mit 64kbit Bandbreite sollte es aber schon sein und für etwa 400 Clients ausreichen. ADSL mit 128kbit Up- und 768kbit Down-Stream ist für bis zu 2.000 Clients gut. Man achte jedoch auf den Flaschenhals: Die Upload-Bandbreite von ADSL. ADSL krankt besonders unter Downloadproblemen, wenn der Upload voll ausgelastet ist. Jedes Datenpaket, welches in Download-Richtung den Weg in den Rechner findet, muß auch per Upload-Stream dem Absender als korrekt empfangen bestätigt werden. Ist der Upload-Stream aber überlastet, dauert diese Bestätigung sehr viel länger und die Gegenstelle stellt die Aussendung von Datenpaketen ein, bis die Bestätigung (endlich) eingetroffen ist. Hiergegen läßt sich leider nichts machen, außer man benutzt QoS (Quality of Service) im (Linux-) Router. Eine Beschreibung der ersten Versuche mit QoS auf einem Linux-Router findet sich z.Zt. etwa bei The-Donkey-Network
Hier noch ein Hinweis über die hohe Netzlast, die vermutlich von der massenweisen Verwendung des DonkeyBOTs ausgeht: Viele User benutzen den BOT, weil durch ihn stets alle Server-IPs im Client vorhanden sind. Was für den einzelnen User ein Vorteil sein mag, hat für das eD2k-Netz jedoch katastrophale Folgen: Wenn 50.000 Clients JEDEN Server regelmäßig mit UDP-Requests bombardieren, streckt auch die leistungsfähigste Netzanbindung irgendwann die Waffen. Sehr gut ließ sich der 'BOT-Effekt' am Tage der weltweiten BOT-Abschaltung feststellen (obwohl auch noch andere Effekte dabei eine Rolle spielten). Hier eine Statistik vom S.L.U.G. (inzwischen leider offline), einer ausgesprochen vielseitigen Serverliste mit vielen Statistiken, erstellt und betrieben von Jaroslav Macodiseas
Man erkennt deutlich, wie sich die Zahl der überlasteten Server plötzlich - abweichend vom bisherigen Muster - stark vermindert und die 'guten' Server deutlich zunehmen. Ungeklärt ist jedoch der starke Zuwachs an Servern allgemein an diesem Tag. Vermutlich hat die DonkeyBOT-Diskussion so hohe Wellen geschlagen, daß einige ehemalige Serverbetreiber ihre Server zu Testzwecken wieder online gestellt haben. Sichtbar wird dabei, wie empfindlich das eD2k-Netz auf kleine Tools - wenn sie massenhaft eingesetzt werden - reagiert und wie stark auch psychologische Effekte (Server-Zunahme) in unserem Netzwerk eine Rolle spielen können. ;-)
Ein erstaunliches Phänomen kann man erleben, wenn man einen längere Zeit laufenden eD2k-Server abschaltet. Es bleibt nämlich trotz abgeschalteten Servers ein reger Datenverkehr bestehen. Das liegt daran, das Euer Server immer noch in vielleicht 150.000 Clients eingetragen ist und nun - obwohl nicht mehr am Netz - regelmäßig von diesen Clients angesprochen wird. Es dauert ein paar Stunden, bis dieses Phänomen verschwindet. Alle Serverbetreiber mit dynamischer IP-Adresse trennen kurz die Verbindung zum ISP, erhalten so eine andere IP-Adresse und haben sofort Ruhe. Serverbetreiber mit
statischer (immer gleicher) IP-Adresse können das nicht und müssen noch ein paar Stunden (max. 3 Stunden, dann kommen nur noch vereinzelt Pakete) mit diesen ungebetenen Datenpaketen leben. Es ist also kein Angriff, sondern eine harmlose, systembedingte Erscheinung.
Rechts eine Darstellung des Traffics (Verkehr über die Datenleitung), der durch den Serverbetrieb entsteht. Hier muß man unterscheiden zwischen Traffic durch die auf dem Server eingebuchten Clients und Traffic, der durch UDP-Requests fremder (auf anderen Servern eingebuchte) Clients entsteht. Nur die Menge an Clients auf dem eigenen Server läßt sich durch passende Eintragung in der donkey.ini steuern. Da der eigene Server während seiner Betriebszeit mit ein und derselben IP-Adresse im gesamten Netzwerk immer "bekannter" wird, werden im Laufe der Zeit auch immer mehr externe Clients diesen Server per UDP-Request nach Quellen abfragen. Die Folge ist ein linearer Anstieg der Server-Netzlast, obwohl der Server "voll" ist, also keine weiteren Clients aufnimmt. Dieser Zustand immer weiter steigender Bekanntheit mit der Folge ständig ansteigender Netzbelastung hält genau so lange an, bis jeder Client im Netzwerk den Server kennt. Von da an steigt die Last nicht mehr weiter. Allerdings befinden sich z.Zt. rund 250.000 Clients im System, die über "normale" private Netzanbindungen wie T-DSL unmöglich alle von einem kleinen Server bedient werden können. Dieses Verhalten ist ein (leider unvermeidlicher) Designfehler des eDonkey-Systems. Man sagt, "das System skaliert nicht vernünftig". Damit ist gemeint, daß ab einer gewissen Usermenge partielle Überlastungen auftreten, die sich nicht kompensieren lassen - der entsprechende Server arbeitet unter Überlastbedingungen, die nur durch Abschaltung des Servers, bzw. eine neue Server-IP-Adresse wieder auf das normale Maß gemildert werden können. Durch einige Tricks und Kniffe lassen sich die negativen Effekte beim Serverbetrieb aber dennoch handhaben, allerdings muß man diese manuell einstellen. So hilft es z.B., den Serverrechner bei Überschreitung einer maximal zulässigen Netzbelastung zu stoppen, eine neue IP-Adresse zuzuweisen (neu connecten) und dadurch seine Bekanntheit wieder auf Null zu drücken. Sofort kehrt wieder Ruhe ein. Dieser Vorgang läßt sich durchaus auch automatisieren. Man wird feststellen, daß der Server tagsüber und besonders in den Abendstunden - wenn viele User Suchanfragen abschicken - sehr oft neu connectet, weil sich die Netzlast sehr schnell dem kritischen Punkt nähert. Des Nachts ist dies kaum der Fall, so daß Serverlaufzeiten am Stück von 0.00 bis 8.00 Uhr normal sind, während tagsüber teilweise jede Stunde neu connectet wird. Vorraussetzung für die Automatisierung des Neuconnects bei Überlast ist jedoch ein Linux-System, bei welchem sich eine solche Funktion sehr leicht einrichten läßt. Ich hoffe, in Kürze werden auch Lösungen für Win32-Server gefunden.
Bei Betrieb eines eDonkey-Servers bleibt dem Betreiber nur noch wenig Bandbreite, um selbst aus dem Esel Daten herunter zu laden. Insbesondere der Zwangsupload (Ratio) des Clients bringt Probleme mit sich, da über den Uploadstream einer T-DSL-Leitung nicht Server und Client gleichzeitg arbeiten können. Für diesen Zweck haben wir den ServerClient bereitgestellt. Dieser ermöglicht den vollen Download, ohne gleichzeitig den Upstream der Datenleitung zuzustopfen. Dieser Server-Client hat sich als sehr wirkungsvoll und leistungsstark im Download erwiesen. Die aktuellste Version ist nicht mehr verschlüsselt, weil sie selbst das Vorhandensein eines eDonkey-Servers im privaten Netz überprüft, ein Mißbrauch ist damit weitestgehend ausgeschlossen. Der Upload schaltet sich selbsttätig ab, wenn ein solcher Server mit einer gewissen Menge an Clients gefunden wird. Einzig die IP-Adresse und den Port des eigenen Servers muß man noch manuell angeben, damit der Server-Client ihn auch findet. Alles andere macht der neue Server-Clients automatisch.
Ein Link zum Download des jeweils aktuellsten eMule-ServerClients befindet sich links im Frame unseres Forums (damit ich nicht bei jeder Änderung beide Links aktualisieren muß, spare ich mir den Link an dieser Stelle). Dort einfach nach Server-Client suchen.
Große Verwirung scheint darüber zu herschen, um was es sich bei DynDNS handelt. Immer wieder halten Leute DynDNS für eine Methode, eine immer gleiche - also statische - IP-Adresse zu besitzen. Dies ist definitiv NICHT der Fall. Wenn Euer ISP (Internet Service Provider, T-Online o.ä.) die Verbindung alle 24 Stunden trennt und Euch beim Neuverbinden eine andere IP-Adresse zuweist (dynamic IP), lässt sich auch mit DynDNS weder die 24 stündige Trennung, noch die Zweisung einer anderen IP-Adresse verhindern. Alles, was ein DynDNS-Service vermag ist, einen immer gleichen Redirector zur Verfügung zu stellen, der auf die momentan gültige IP-Adresse zeigt. Für den Betrieb eines eD2k-Server bringt das aber herzlich wenig, weil der eD2k-Server keine DNS-Auflösung bietet. Für Leute, die einen HTML-Webserver von Zuhause aus über DSL betreiben ist das aber eine gute Sache, weil sich mit dem Redirector Webseiten direkt aufrufen lassen. Eben noch schnell die DNS-Auflösung erklärt: Daten werden beim TCP/IP-Protokoll über IP-Adressen geroutet. Das Internet arbeitet mit TCP/IP, dort ist es also genauso. Nun ist es sehr umständlich, im Webbrowser eine Seite mit http://193.99.144.71 aufzurufen. Kein Mensch merkt sich die IP-Adresse. Einfacher ist es mit sogenannten URLs (Uniform Resource Locator): Die IP-Adresse 193.99.144.71 gehört zur Webseite des Heise-Verlages (c't, iX, TELEPOLIS). Die URL dazu lautet: www.heise.de. Gibt man diese URL in den Webbrowser ein, wird zunächst eine Anfrage zum zuständigen DNS-Server (DomainNameSystem-Server) geleitet, der die zugehörige IP-Adresse zurückliefert. Erst damit ist der Aufruf einer Webseite möglich.
Ein Beispiel: Jemand betreibt einen Webserver über eine dynamische IP-Adresse. Er hat einen Account bei www.dyndns.org und der von ihm gewählte Redirector lautet (Beispiel!): meier.dyndns.org. Es ist nun möglich, seinen Webserver jederzeit über http://meier.dyndns.org zu erreichen. Das setzt natürlich vorraus, daß er seinen Account immer aktuell hält, also muß er nach jeden Wechsel seiner IP-Adresse DynDNS immer seine gerade aktuelle IP-Adresse mitteilen. Das läßt sich über ein Programm automatisieren, welches nach jeder Änderung der IP-Adresse den Account automatisch aktualisiert.
In letzter Zeit treten gehäuft Probleme bei Serverbetreibern durch extrem hohe Netzlast schon bei geringer Useranzahl auf dem Server auf. Das ist zum einen die Folge von 'wilden', also externen Software-Lösungen, um gewisse Schwächen des eD2k-Systems auszubügeln und zum anderen die Folge der starken Verbreitung unseres Systems. Häufig treten bei dezentralen P2P-Systemen Skalierungsprobleme auf, die ab einer gewissen Menge an Usern zu sehr hohen Datenströmen innerhalb des Netzes führen. Meinen Erfahrungen nach besteht die einzige Möglichkeit den entstehenden Servertraffic in Grenzen zu halten darin, nur eine sehr kleine Menge an Clients in der donkey.ini einzustellen (<=200). Damit nimmt man direkten Einfluss auf die Menge der Dateien, die der Server kennt (weniger Clients auf einem Server = weniger Dateien die er kennt = weniger Antworten, die der Server auf Suchanfragen fremder Clients von anderen Servern aussenden muß). Nicht möglich ist es, den von außen hereinkommenden Datendurchsatz von innen her zu begrenzen. Leider geht selbst eine ADSL-Verbindung schon nach ein paar Stunden beim Serverbetrieb mit 1.000 Clients in die Knie, obwohl 1.000 Clients an sich bei weitem noch keine zu hohe Last für ADSL darstellen. Dies ist eine Folge der zunehmenden Bekanntheit des eigenen Servers im eD2k-Netzwerk und der damit ansteigenden Menge von Extend-Search- und Global-Search-Requests der etwa 200.000 User. Einziges Mittel dem zu entgehen ist, sich eine andere IP-Adresse vom ISP zuweisen zu lassen, dann ist (erstmal wieder) schlagartig Ruhe. Wenn der Server aber wieder drei Stunden gelaufen ist, wiederholt sich das Spielchen von vorn. Dies ist eine direkte Folge der gestiegenden Nutzerzahlen des Donkeys. Zur Zeit arbeite ich an einem neuen Filesharing-System, welches deutlich besser skaliert und so viel mehr User aufnehmen kann. Etwa 10 Millionen Nutzer sollte das System verkraften können, wenn es zukunftsfähig bleiben soll. Näheres dazu unter
"The Next Generation" - Always one generation ahead...
* BOT-User fallen durch den Namenszusatz [file-finder.com] auf. So ist es dem Server leicht möglich, diese User zu erkennen und auf Wunsch auszuschließen. Standardmäßig ist die 'Bot-User müssen leider draußen bleiben!'-Option aktiviert.
* MLDonkeys (ein spezieller Open-Source-Client) fallen nicht so ohne weiteres auf, können das gesamte Netz allerdings auch stark belasten, indem sie mehrere Server gleichzeitig connecten. Damit eine solche Belastung möglichst vermieden wird, bietet der Lugdunum-Server seit Patchlevel 45 die Möglichkeit, MLDonkeys auszusperren.
* Auf Wunsch ist es ebenfalls möglich, die Menge an Dateien, die ein User anbieten kann, zu begrenzen. Dies macht durchaus Sinn, denn manche User geben (versehentlich?) ihre ganze Festplatte frei, was unsere Server durch den enormen Speicherbedarf zum straucheln bringt. Auch verringert sich so das zum Server zu übertragende Datenvolumen. Der Nachteil ist natürlich, das umfangreiche Softwaresammlungen nicht mehr auf dem Server angezeigt werden. Standardmässig werden zwei Limitierungen vorgegeben: Softlimit bei 120 Dateien/User, Hardlimit 5.000 Dateien/User. Beides lässt sich auch anders einstellen. Ich persönlich würde das Softlimit nicht so drastisch einschränken, sondern etwa 500 Dateien erlauben.
* Man kann Clients mit niedriger ID ausperren. Das sind all diejenigen Clients, die hinter einer Firewall oder einem Router mit NAT am Netz hängen und keine Portweiterleitung eingestellt haben. Sinn der Sache ist es, Serverbandbreite einzusparen. Diese User verursachen zusätzlichen (und unnützen?) Datenverkehr auf der Serverleitung, weil Downloadrequests von anderen Clients sie nicht direkt erreichen können. Daher muß ein Client, der etwas von Ihnen downloaden möchte, den Umweg über den Server antreten und der Server muß den Request dann weiterleiten. Dies verursacht logischerweise eine zusätzliche (unnötige?) Netzlast, die vermieden werden kann, wenn man solche Clients einfach aussperrt. Ob das gerecht ist oder ungerecht, muß jeder für sich und anhand seiner Prioritäten selbst entscheiden. Standardmäßig ist im Server diese Option aktiviert, er lässt also keine firewalled Clients connecten. Mein Server ist so eingestellt, das er auch firewalled Clients zuläßt.
* Desweiteren wurde die Suchroutine wirklich stark verbessert. Sie benötigt nur noch etwa 5% der bisherigen CPU-Leistung. Auch der Speicherverbrauch wurde u.a. durch die o.g. Maßnahmen verringert.
Meine bisherigen Tests mit diesem gepatchten Server verliefen 100% positiv, so daß ich vermutlich nur noch diesen Server betreiben werde.
Dieser Server liegt in einer sehr frühen Version nun auch als Win32-Applikation vor (allerdings blockt er bisher nur Low-ID-Clients).
Als Betriebssystem für einen eDonkey-Server kommen in erster Linie Linux, Windows 2000 und XP in Frage. Windows 9x oder Windows Me können nur sehr eingeschränkt verwendet werden, da íhre Architektur für die Serversoftware sehr ungeeignet ist. So ist z.B. der IP-Stack von Windows 9x/Me nicht für mehr als 100 gleichzeitige Verbindungen ausgelegt, außerdem reagieren diese Systeme zu langsam im Taskwechsel. Selbst mit Hochleistungsrechnern mit 500MHz und mehr ist es nicht möglich, mehr als 100 Clients zu versorgen. Der Server wird extrem langsam und instabil arbeiten. Auch ist die Speicherunterstützung unter Windows 9x/Me auf 512MB begrenzt. Das schlimmste aber passiert, wenn 100 User auf dem Server eingelogt sind: Es lassen sich nicht mal mehr Webseiten öffnen, weil die 100 maximal möglichen gleichzeitigen Verbindungen erschöpft sind. Zwar kann man einen Registry-Patch einspielen, aber der bringt mehr Dreckeffekte und Instabilitäten als Nutzen. So führt z.Zt. kein Weg an Linux, Windows 2000 oder XP vorbei. Da man den Rechner, auf dem der eDonkey-Server läuft, besser in Ruhe seine Arbeit machen lässt, kann recht vorteilhaft Linux Verwendung finden. Es ist klein, genügsam und wirklich das schnellste, was der Markt z.Zt. hergibt. Der mit Linux Unerfahrene wird an dieser Stelle vielleicht etwas entmutigt dreinschauen - ich möchte ihn aber auf jeden Fall ermuntern, sich einmal etwas mit Linux zu beschäftigen. Meiner Meinung nach gehört Linux absolut die Zukunft und da kann es doch nicht schaden, wenn man schon mal ein wenig damit hantiert hat. Tausende freundliche Linux-User auf der ganzen Welt helfen über das Internet mit Rat und Tat bei Installation, Betrieb und möglicherweise auftretenden Problemen. Falls man aber unbedingt auf Windows 2000 oder XP ausweichen möchte, kann man das natürlich tun. Der Server läuft dann in der Eingabeaufforderung. Die Leistung des eDonkey-Servers ist etwa 15% geringer als unter Linux. Auch benötigen Windows 2000 und XP erheblich mehr Speicher für sich selbst. Eine entsprechend größere Speicherbestückung ist dann also Pflicht.
Installation kann man es eigentlich nicht nennen. Das Archiv dserver38.zip (die Zahl kann sich bei einer neueren Version geändert haben), oder Lugdunums Anti-Low-ID-Server wird in ein beliebiges Verzeichniss entpackt. Es enthält zwei Dateien: Die "dserver.exe" und die "donkey.ini". Die "donkey.ini" wird wie weiter unten beschrieben angepaßt. Gestartet wird einfach mit Eingabe von "dserver.exe", Doppelklick im Explorer oder mit dem "ServerMaker". Inzwischen gibt es sehr leistungsfähige Lugdunum-Server für Windows. Download hier: http://lugdunum2k.free.fr/kiten.html
Herunterladen des Linux-Servers von http://www.ed2k-serverboard.de/diesel oder hier http://lugdunum2k.free.fr/kiten.html (inzwischen gibt es keine "nbuser"Datei mehr. Die Funktion wurde in die Serverdatei "eserver" integriert). Die entsprechenden Dateien herunterladen, mit "gzip -d Dateiname" entpacken und mit "chmod 755 Dateiname" ausführbar machen.
Der auf der 'offiziellen' Seite immer noch angebotene Linux-Server v.16.39 funktioniert übrigens nicht richtig, weil einige schwerwiegende Fehler enthalten sind. So stellt der Server die Aussendung von UDP-Antworten nach etwa 30 Minuten völlig ein und vergißt schon binnen kurzer Zeit die komplette Server-Liste. Absolut unbrauchbar. Diese Fehler wurden auch von Jed McCaleb (Entwickler) bestätigt, aber immer noch nicht beseitigt. Weshalb sich der Link immer noch dort befindet, ist mir ein Rätsel. Benutzt bitte nur den hier angebotenen Linux-v.16.38-Server oder die von Lugdunum gepachte Version.
Der Lugdunum-Server bietet seit Patchlevel 57 eine sehr interessante Funktionen, um "unsoziale" Clients zu erkennen und zu bekämpfen.
Smart Sources V3 nennt sich die neue Technik zum Erkennen von BOTs und "unsozial" modifizierten Clients.
Lugdunums Analysen auf ihren Test Servern (Lugdunum, Gruk, eD2k.ch, Link92 and fugitif) haben ergeben, daß 1% aller User modifizierte Clients benutzen, die eine sehr hohe Serverlast verursachen. Desweiteren benutzen viele User einen BOT oder MLDonkey, welche ebenfalls recht "unsozial" eingestellt sein können. Diese bekommen ohne Smart-Sources V3 allerdings 30% bis 50% aller vom Server herausgegebenen Quellen(Sourcen), was natürlich zu einer stark ungerechten Verteilung des Downloads führt. Mit der neuen Smart Sources V3-Technik werden sie erkannt und der Server sendet ihnen dann nur noch 1% der Quellen.
Die natürlich weiterhin erforderliche erforderliche "donkey.ini" wird wie weiter unten beschrieben mit einem Text-Editor (z.B. mit vi) erstellt und kommt dann ins gleiche Verzeichnis. Gestartet wird der Server dann im Verzeichnis des Servers (!) entweder per Hand mit "./dserver", oder - wenn gewünscht - über ein Skript.
Der ANTI-BOT-Server funktioniert ganz genauso wie der normale 38'er dserver. Er bietet jedoch weitergehende Optionen zur Konfiguration (werden mit dem nbuser-Tool durchgeführt!), die man jedoch nicht zwingend durchführen muß. Eine donkey.ini benötigt aber auch er in jedem Falle. Ohne weitergehende Konfiguration läßt der ANTI-BOT-Server weder BOT-User, noch User mit niedriger ID connecten, was zwar Server-Bandbreite sparen hilft (bei Usern mit niedriger ID werden Download-Requests anderer Clients über den Server initiiert, was einiges an Bandbreite kostet) , jedoch nicht unbedingt sehr sozial erscheint. Auch begrenzt die Voreinstellung dieses Servers die maximale Menge an Dateien, die ein einzelner User anbieten darf auf 120 Stück (Soft-Limit). Wenn User mit mehr Dateien im Share connecten, werden die überzähligen einfach nicht mit in die Datenbank des Servers aufgenommen. Ab 5.000 Dateien im Share eines Users wird der betreffende User vom Server ´gekickt´(Hard-Limit). Sinn der Sache ist es, das System von Müll zu befreien. Viele Leute scheinen ihre gesamte Windows-Platte freizugeben, was nur das gesamte System verstopft, sinnlos Server-Speicherplatz kostet und die CPU des Servers durch unnötig lange Suchvorgänge belastet. Mir erscheint eine Begrenzung auf 120 Dateien pro User jedoch zu niedrig und so habe ich bei mir das Soft-Limit auf 500 Dateien angehoben. Die Hard-Limit-Funktion habe ich jedoch auf 3.000 Dateien herabgesetzt, da mir der voreingestellte Wert wiederum zu hoch erschien. Jeder möge selbst entscheiden, was er einstellt.
Die Bedienung von ´nbuser´ ist recht einfach: Nachdem der Server gestartet wurde, können die Einstellungen vorgenommen werden. Auch kann man die Einstellungen im Gegensatz zur donkey.ini jederzeit im Betrieb des Servers ändern. Eingestellt wird so:
nbuser -l 1 (das soll "-L 1" heißen, aber kleingeschrieben!) Connect von Low-ID-Clients erlauben
nbuser -l 0 (wie oben "-L 0", aber bitte das L klein!) Connect von Low-ID-Clients verbieten (Defaulteinstellung)
nbuser -B 1 Connect von BOT-Clients erlauben
nbuser -B 0 Connect von BOT-Clients verbieten (Defaulteinstellung)
nbuser -Z 1 Connect von MLDonkeys erlauben
nbuser -Z 0 Connect von MLDonkeys verbieten (Defaulteinstellung)
nbuser -s 500 Das ´Soft-Limit´ an maximal erlaubten Dateien pro User einstellen. In diesem Beispiel auf 500. Alle überzähligen Dateien werden weggelassen
nbuser -S 360 Die Zeit zwischen den Server-Such-Intervallen in 10 Sekunden Schritten ("nbuser -S 360" bedeutet also 3600 Sekunden = 1 Stunde). Normalerweise sucht der Server jede Stunde einmal nach neuen Servern. Dafür werden alle bisherigen Server-IP's verworfen und ein neuer Suchintervall beginnt. Durch erhöhen des Zeitraumes lassen sich z.B. mehr Server beim Connect eines Clients übergeben, bei kürzeren Zeiten sind die Server-IP's aktueller.
nbuser -D 2000 Das ´Hard-Limit´ an Dateien einstellen, ab deren ein Client vom Server geworfen wird.
nbuser -m 500 Hier wird die Einstellung der donkey.ini für "maxClients=xxx" nachträglich überschrieben. Das geht sogar im laufendem Betrieb!
nbuser -C 32 Hier wird die Größe der Cacheline im L1-Cache eingestellt. Abhängig vom verwendeten Prozessor finden folgende Werte Verwendung:
16 Bytes bei i386 und i486, 32 Bytes bei Intel Pentium I, Celeron, Pentium II und Pentium III, 64 Bytes bei AMD Athlon und128 Bytes bei Intel Pentium IV.
nbuser -R 50 Defaultmäßig läßt der Server 20% Low-ID-Clients - gemessen an der momentanen Clients-Auslastung - connecten, wenn der Connect nicht mittels "nbuser -l 0" komplett verboten wurde. Das %-Verhältniss läßt sich durch "nbuser -R xxx" ändern. "nbuser -R 100" läßt alle Low-ID-Clients connecten, die einen Connect wünschen, bis die maximale Anzahl an Clients erreicht ist (also wie vorher, als es die -R-Funktion noch nicht gab)
Entweder muß man diese Eingaben in dem Verzeichnis durchführen, in dem ´nbuser´ liegt (dann aber bitte ./ voranstellen, also ./nbuser -B 1), oder man legt einfach einen symbolischen Link im Verzeichnis /sbin an. ( ln -s nbuser /PfadZurDatei )
Hier kommen wir zu des Pudels Kern: Sämtliche Konfigurationen am eDonkey-Server werden mittels Eintragungen in der donkey.ini-Datei vorgenommen. Der Server liest diese Datei einmal beim Start ein. Wenn Änderungen an der donkey.ini vorgenommen werden, wird der Server sie erst beim nächsten Start bemerken. Ich muß an dieser Stelle ganz dringend darauf hinweisen, daß Syntaxfehler (Schreibfehler) in der "donkey.ini" von der Serversoftware nicht toleriert werden. Der Server wird entweder die Bedeutung der einzelnen Befehle nicht verstehen und deshalb nicht funktionieren, oder er ignoriert die falsch geschriebenen Befehle (und alles, was dahinter steht!). Auch auf Groß-/Kleinschreibung ist peinlich genau zu achten! Alle freien Texteingaben wie Servername oder Beschreibung haben ohne Anführungstriche zu erfolgen.
Diese Zeichenfolge leitet die Befehlssequenz ein. Sie steht in eckigen Klammern. Bitte darauf achten, daß sich hinter der letzten Klammer "]" kein Leerzeichen mehr versteckt. Es würde den Server verwirren. Ggf. funktioniert er dann nicht. Alle Einträge sind als Beispiele zu verstehen!
Der Name des Servers, wie er im Client angezeigt werden soll. Hier können alle alphanumerischen Kombinationen von Zeichenketten angegeben werden.
Serverbeschreibung. Hier gilt das selbe wie bei "name=". Alles ist möglich.
Groß-/Kleinschreibung beachten! (Die IP-Adresse "217.74.93.105" ist nur ein Beispiel!)
Hier wird dem Server mitgeteilt, wie seine eigene öffentliche (!!!) IP-Adresse lautet. Beim Start des Servers zeigt dieser die IP-Adresse, mit der er arbeitet und die er an andere Server schickt, an. Unbedingt sicherstellen, daß die beim Start angezeigte IP-Adresse auch wirklich die eigene, öffentliche (!!) IP-Adresse ist. Hier werden absolut die meisten Fehler gemacht. An dieser Stelle können nur numerische IP-Adressen eingesetzt werden, alphanumerische Einträge wie "xyz.dyndns.org" funktionieren nicht, da der Server (noch) keine DNS-Auflösung bietet! Ich werde weiter unten noch auf Skripte eingehen, welche diesen Eintrag automatisieren, damit nicht bei jedem Start mit dynamischer IP-Adresse des Servers dieser Eintrag von Hand editiert werden muß.
Wird dieser Eintrag weggelassen, versucht der Server die IP selbst zu erkennen. Geht aber meist schief, daher: Beim Serverstart genau überprüfen!
Hier wird der (TCP-) Port eingetragen, über den der Server erreichbar sein soll. Normalerweise ist dies der Port 4661. Wenn 4661 gewünscht wird, kann der Eintrag entfallen. Falls dieser Port aus technischen Gründen nicht zur Verfügung steht, kann auch ein anderer Port benutzt werden. Dann wird dieser Eintrag entsprechend gesetzt. > Nach Möglichkeit den Port 4661 benutzten. Es kommt sonst nur zu Verwirrungen.
Falls das aus technischen Gründen nicht möglich sein sollte - zum Beispiel, wenn der Server zusammen mit einem Client über die selbe Leitung betrieben werden soll - bitte beachten:
Der Server benötigt zwei Ports: Einen für TCP, üblicherweise den 4661, und einen für UDP. Der UDP-Port liegt immer 4 Portnummern über dem TCP-Port. Wurde also als TCP-Port 4661 gewählt, liegt der UDP-Port dementsprechend auf 4665. Wenn man beim Server den Port ändert (z.B. "port=3939"), dann liegt der TCP-Port auf 3939 und der UDP-Port auf (3939 + 4) = 3943!
Falls der Server nicht direkt ans Netz angeschlossen ist, sondern über einen Router mit NAT (Masquerading) arbeiten soll, ist das zu beachten und es sind die entsprechenden Ports unbedingt in die Forwarding-Liste einzutragen, da der Server sonst nicht funktionieren kann.
"port=" ist ohne Eintrag defaultmäßig 4661 (und demzufolge ist der UDP-Port dann 4665)
Groß-/Kleinschreibung beachten! (Die IP-Adresse "217.74.93.105" ist nur ein Beispiel!)
"Seed" bedeutet "Saat", oder "Keimblatt" und meint die Server-IP eines anderen eDonkey-Servers. Der eigene Server muß sich beim Start im weltweiten eDonkey-System anmelden, damit er Teil des großen eDonkey-Netzwerkes wird. Beim Start des Servers wird daher der hier eingetragene eDonkey-Server connectet.
Zuerst übergibt der eigene Server dem "Seed-Server" seine IP-Adresse und Portnummer und wird dadurch im eDonkey-Netzwerk angemeldet. Danach übergibt ihm der Seed-Server alle (ihm bekannten) eDonkey-Server IP-Adressen. Der eigene Server trägt diese IP-Adressen daraufhin in seine Datenbank ein. Die Datenbank wird beim Beenden des Server-Programmes auf die Festplatte geschrieben und heißt "serverList.met". Beim nächsten Start wird der "seedIP"-Eintrag nicht mehr benötigt, weil der Server ja bereits eine Sammlung von Server-IP's in der serverList.met findet. Der Server im "seedIP="-Eintrag MUSS aber beim ersten Start gültig und vorhanden sein. Wenn sich kein aktiver eDonkey-Server unter dieser IP-Adresse meldet und auch ältere Einträge in der "serverList.met" nicht mehr aktuell sind, kann der Server keine Verbindung mit dem eDonkey-Netzwerk aufnehmen. Auch hier kann nur eine numerische IP-Adresse angegeben werden. Alphanumerische URL's wie "xyz.dyndns.org" funktionieren (noch) nicht! Am besten, man trägt hier den Server ein, mit dem man im Client gerade verbunden ist. Da weiß man wenigstens, daß er funktioniert...
Der "seedIP="-Eintrag kann nur weggelassen werden, wenn sich eine aktuelle "serverList.met" im gleichen Verzeichnis auf der Festplatte befindet. Wenn der eigene Server mal ein paar Tage offline war, kann es passieren, daß alle Server-IP's in der "serverList.met" nunmehr ungültig sind und er keine Verbindung mit dem eDonkey-Netzwerk aufnehmen kann. Dann bei einer Serverliste einen Seed-Server aussuchen. Es spielt keine Rolle, ob man einen Server mit statischer oder dynamischer IP-Adresse erwischt, denn die vom Seed-Server übergebene IP-Adressen Sammlung reicht allemal aus.
Groß-/Kleinschreibung beachten!
Sollte der "Seed-Server" einen anderen Port als den üblichen Port TCP:4661 benutzen, muß dieser hier angegeben werden. Über 90% aller Server benutzen Port 4661.
"seedPort" ist defaultmäßig 4661
Groß-/Kleinschreibung beachten!
Bedeutung: Beim Linux-Server kann statt einer Bildschirmausgaben auch eine Logdatei auf die Festplatte geschrieben werden. Dabei ist die Bildschirmausgabe aber abgeschaltet. Der Server wird in diesem Fall also keine Ausgaben mehr auf dem Bildschirm machen. Der Windows-Server scheint sich hier jedoch etwas anders zu verhalten, da er auch noch Bildschirmausgaben zulässt. Nix genaues kann ich dazu leider auch nicht sagen, da ich kaum Erfahrungen mit dem Windows-Server habe. "true" bedeutet "wahr", "false" bedeutet "unwahr". Eine typische binäre Beschreibung von Schaltzuständen wie "Ein" oder "Aus". Wenn statt Bildschirmausgabe die Logdatei gewünscht wird: "true", wenn nicht, dann: "false". Bitte nicht beides zusammen, sonst wird der arme Server verrückt oder explodiert ;-)
"logfile" ist ohne Eintrag defaultmäßig "false", also aus.
"Verbose" bedeutet "Wortreich" oder "Labertasche" und beschreibt den Sachverhalt schon ganz genau. Wer gerne jede fisselige Systemmeldung des Servers auf der Konsole mitlesen möchte, setzt "verbose=true". Normalerweise ist dieser "Geschwätzigkeitsmodus" aber eher störend, weil er die wichtigen Ausgaben zu schnell wegscrollen lässt.
Achtung, nicht wundern: Auch mit "verbose=false" gibt der Server hin und wieder Ausgaben wie: "ERROR: unknown type MetaTag::MakeTag() 72" aus. Man sollte sich nichts weiter dabei denken, er funktioniert trotzdem einwandfrei. Woran das liegt ist auch mir nicht bekannt. Also egal :-)
"verbose" ist ohne Eintrag defaultmäßig "false", also aus.
"Public" bedeutet "Öffentlichkeit, Publikum" und meint, ob der Server sich bei anderen Servern eintragen soll. Dies ist zur Funktion des eDonkey-Netzwerkes zwingend notwendig und muß daher unbedingt auf "true" stehen. Nur wenn "public=true" gesetzt ist, meldet sich der Server im Netzwerk an!
Achtung: "public" ist defaultmäßig "false"! Ohne Eintrag "public=true" wird der Server keinen anderen Server connecten!
Dieser Eintrag erklärt auch, weshalb ein neuer Server nirgends eingetragen werden muß. Er tut es selbst, wenn public=true gesetzt wird.
"Thread" heißt übersetzt "Faden" und entspricht in der Computersprache einem "Prozess-Faden". Multitaskingfähige Betriebssysteme wie Linux, Windows 2000 oder XP können mehreren Prozessen abwechselnd Ressourcen wie Speicher und Rechenzeit zuweisen. Das geht so schnell, daß es aus Sicht des Beobachters aussieht, als würden die Prozesse gleichzeitig ablaufen. Da normale PC's aber wie alle "Neumannschen Maschinen" Befehle immer seriell abarbeiten, scheint das wegen der hohen Arbeitsgeschwindigkeit nur so. Da bei einem Thread-Wechsel aber auch immer die Daten des alten Threads im Speicher gesichert werden müssen und die Daten des neuen Threads aus dem Cache oder gar Hauptspeicher (langsam) geladen werden müssen, kostet jeder Thread-Wechsel Zeit.
Zurück zum Server: Bei einem Server bis 1000 Clients würde ich unter Linux "threads=30" eintragen.
Ein eD2k-Server unter Windows benötigt erstaunlicherweise mehr Threads und kann schon einmal bis auf 50 hochgetrieben werden. Wichtig ist aber, die Menge an Threads in etwa mit der Menge an Clients und damit der Menge an Suchanfragen in der Balance zu halten. Ich empfehle für kleine Windows-Server bis 100 Clients 5 Threads, bis 500 Clients 20 Threads und bis 1.000 Clients 40 Threads.
Groß-/Kleinschreibung beachten!
Unter "Tabelle" versteht der Server die Datenbank bestehend aus Filenamen und Clients. Ohne jetzt näher auf den programmtechnischen Hintergrund eingehen zu wollen (schnelle Suchroutine): Hier MUSS eine Primzahl eingesetzt werden. Größe scheint egal zu sein. In der mitgelieferten "donkey.ini" steht "3089" und tasächlich: 3089 ist eine Primzahl. Ich habe verschiedene Primzahlen ausprobiert und keine Unterschiede bemerkt. Macht's wie ich: Schreibt "tableSize=3089" rein, selbst nachrechnen ist Zeitverschwendung.
Der Server funktioniert aber auch ohne "tableSize"-Eintrag.
Groß-/Kleinschreibung beachten!
Hier wird die Menge der Clients eingestellt, die gleichzeitig mit dem Server verbunden sein können. Wenn der "maxClients"-Wert erreicht wird, erscheint "Can`t connect to..." beim Connectversuch eines Clients.
Mit diesem Wert muß man etwas experimentieren. Wenn er zu niedrig ist, verschenkt man unnötig Ressourcen, wenn er zu hoch ist, treten Paketverluste auf und der Server antwortet extrem langsam bis gar nicht mehr auf Client-Requests. Außerdem wird die Ping-Zeit zu hoch, Suchanfragen gehen verloren, der Speicher wird auf Festplatte ausgelagert, und und und. Man sieht das sehr schön im Client-Serverfenster, wenn man mal die Pingzeiten der verschiedenen Server miteinander vergleicht. Auch muß man genügend Reserven für Spitzenzeiten berücksichtigen, wenn besonders viele leistungszehrende Requests kommen (z.B. am Wochenende, wenn die User gelangweilt an ihren Clients sitzen und alles mögliche ausprobieren, um schneller an ihre Daten zu kommen) und viele Dateien in der Indextabelle stehen - die Dateimenge wirkt direkt auf den erforderlichen RAM-Speicher. Sollte der Rechner gar anfangen zu "swapen", sollte also die Festplatte ständig rattern, muß dieser Wert unbedingt verringert werden. Natürlich muß die Netzanbindung auch leistungsfähig genug sein. Der "maxClients"-Wert sollte so eingestellt werden, daß durchschnittlich 50% CPU-Last nicht überschritten werden. Bei "type=key" kann man bis auf max. 60% gehen. Wenn man bei voll besetztem Server bemerkt, daß bei Eingabe von "vs" (view servers) die Server-IP's unterhalb von "working:" immer weniger werden, hat man bereits massive Paketverluste. Der Nutzen des Servers geht dann gegen Null. Den Clients werden nur noch wenige Server-IP's beim connect übermittelt, sie finden daraufhin kaum noch Dateien und die Suchfunktion dauert ewig.
In diesem Fall müßte man klären, ob der Rechner zu wenig Speicher, zu geringe CPU-Leistung, oder eine zu schwache Netzanbindung hat. Für alle drei Parameter gibt es geeignete Monitoring-Tools auch für die Linux-Bash (z.B. "TOP" für CPU- und Speicher-Auslastung, "IPTRAF" für die Netzlast) Kleiner Fingerzeig: Mein "Little Red Corvette"-Server läuft unter Linux auf einem AMD K6 III 400MHz (66MHz FSB, Intel TX) mit 256MB RAM und T-DSL (128/768kbit/s), .ini-Einstellung "type=key". Bei 1.000 Clients erreicht die CPU-Last 20 - 50% und der Speicher ist zu etwa 180MB ausgelastet (nur Bash, kein KDE o.ä.). Bei 1.300 Clients liegt die CPU-Last zwischen 40 und 100% und der Speicher ist mit etwa 230MB fast ausgelastet. 1.500 Clients lassen sich nicht mehr sicher versorgen, denn sowohl CPU-Last als auch Speicherauslastung liegen dann öfter bei 100%, der Rechner blockiert teilweise völlig, oder der Server beendet sich plötzlich. Glücklicherweise schafft auch T-DSL nicht mehr als 1.000 User, ohne daß der Upload-Stream "Verstopfungserscheinungen" zeigt. Ich habe "maxClients=1000" eingestellt und keine Probleme.
Groß-/Kleinschreibung beachten!
Hier kann auf die neue und schnellere Suchmethode des v.38'er Servers umgeschaltet werden, was man auch unbedingt tun sollte. Bei normaler Betriebsart und einer mittleren CPU-Auslastung von 50% treten immer wieder Lastspitzen auf, die den Rechner für mehrere Sekunden (oder Minuten) auf 100% Last treiben. Diese Lastspitzen führen zu den beschriebenen Paketverlusten! Das alles vermeidet man mit der Aktivierung der "type=key". Der "maxClients"-Wert kann nun so eingestellt werden, daß bei voll besetztem Server etwa 60% CPU-Last erreicht werden. Man wird feststellen, das die Lastspitzen jetzt seltener auftreten und wenn, dann nur noch kurz. Der "Little Red Corvette"-Server lief monatelang unter "type=substring" mit maximal 900 Usern. Mit "type=key" schafft er maximal 1300 User bei gleicher Hardware - leider ist mein T-DSL damit überfordert!
"type" ist ohne Eintrag defaultmäßig "key", also schnelle Betriebsart.
Dieser Wert entscheidet darüber, ob der Server unter Linux eine Konsole (Linux-Konsole oder Eingabeaufforderung) benötigt, oder nicht. Sinnvoll, wenn der Server automatisch gestartet werden soll und man den "screen"-Befehl nicht benutzen will oder kann. Wenn "console=true" eingetragen wurde, benötigt der Server zwingend eine Konsole, wenn "console=false" lautet, braucht er keine, kann aber auch keine Eingaben von der Tastatur entgegennehmen und keine Ausgaben auf dem Bildschirm ausgeben. Beides wird eigentlich nicht unbedingt benötigt, ich persönlich sehe ihm aber lieber bei der Arbeit zu und kontrolliere gern mal mit "vs" die ihm bekannten Server.
"console" ist defaultmäßig "true".
Groß-/Kleinschreibung beachten!
Hier wird festgelegt, daß keine früheren Client-Versionen als v.60 den Server connecten können. Es ist sinnvoll nach einem Update der Client-Software diesen Wert anzupassen. Möglichst keine Clientversionen unter Version 60 mehr auf den Server lassen, denn sie überlasten das gesamte eD2k-Netz sehr stark mit UDP-Requests. Dies macht sich zwar nicht direkt auf dem eigenen Server bemerkbar (dort suchen die eingebuchten Clients ja direkt), aber inderekt auf den anderen Servern unseres eD2k-Netzwerkes. Die alte v.56 belastet das gesamte Netz je nach Nutzung bis zu 20 mal so stark wie die aktuelle v.60/61. Das bedeutet, das ein Client der die v.56 benutzt die gleichen eD2k-Netz-Ressourcen verbraucht wie 20 Clients, welche die Version 60/61 nutzen...
Wenn kein "minVersion"-Eintrag, dann ist der Connect zulässig für alle Client-Versionen unterhalb "maxVersion".
Am 12. August 2002 habe ich mir die Statistiken mal näher angesehen und war erschrocken, das über 60% aller Server noch die Client-Version 56 erlauben. Wir brauchen uns über den viel zu hohen Bandbreitenverbrauch eines eD2k-Servers nicht zu wundern, wenn so viele 56' er noch zugelassen werden.
WICHTIG! Also bitte auf keinen Fall den Eintrag vergessen, oder auf geringere Versionen als 60 einstellen!!! WICHTIG!
Obwohl es durchaus offizielle Clients mit niedrigeren Versionnummern gibt (Linux, Mac OS), empfehle ich "minVersion=60" deshalb, weil diese Clients dadurch zusammen mit den zerstörerischen Uraltclients auf die verbleibenden Server ohne "minVersions"-Limit gedrängt werden. Dies hilft mit, die Uraltclients auszurotten.
Groß-/Kleinschreibung beachten!
Hier wird die maximale Versionsnummer festgelegt, die noch den Server connecten können. Vorsicht: Es sind immer noch uralte Testclients mit Versionsnummern wie 1149 (Betaversion der Version 49) in Umlauf. Am besten, man trägt hier die Versionsnummer des aktuellen Clients (60) oder eine fiktive 99 ein, dann verhindert man sicher, daß uralte Testclients sich einbuchen und unser gesamtes eD2k-Netz mit Suchanfragen überfluten. Clevere Sysops tragen eine Version oberhalb der jeweils aktuellsten ein, dann vergessen sie beim nächsten Client-Update nicht den Server anzupassen...
Wenn kein "maxVersion"-Eintrag, dann zulässig für alle Client-Versionen oberhalb "minVersion".
Einen Connect-Text wird man sicher auch einrichten wollen. Dabei gilt es einfach, die Ziffern fortlaufend durchzunummerieren. Man bedenke aber, daß dieser Text auch durch den Upload muß! Also möglichst keine Romane schreiben, sonst verliert man spürbar an nutzbarer Bandbreite. Bei einem Server mit 1000 Clients sind 5 bis 20 Connects pro Minute normal. Auch wenn der Server voll ist, disconnecten immer wieder einzelne Clients, neue Clients bauen eine Verbindung auf und bekommen den Connect-Text zugeschickt.
Hier kann man Chaträume einrichten. Ist allerdings heute nicht mehr nötig, weil der Chat aller Versionen oberhalb von V.56'er ausschließlich über IRC funktioniert. Nur der Vollständigkeit halber erwähnt.
[server]
name=Der Parsimony-Foren-Server
desc=Ein neuer eDonkey 2000 Server
thisIP=217.74.93.105
seedIP=65.2.43.64
maxClients=500
threads=20
tableSize=3089
minVersion=60
maxVersion=99
public=true
type=key
console=true
welcome[0]=Hallo Welt! Willkomen auf meinem Server.
welcome[1]=Bitte bietet nichts urheberrechtlich geschütztes auf diesem Server an.
welcome[2]=Die eDonkey-Server Anleitung: >>> http://www.ed2k-serverboard.de/diesel/edonkey/Serverbeschreibung.html
Wenn alle Einträge korrekt sind, wird die "donkey.ini" im Verzeichniss des Servers gespeichert und der Server kann gestartet werden. Netzverbindung zum Internet muß natürlich bestehen. Nach etwa 3 Sekunden kann man versuchsweise "vs" in der Serverkonsole eingeben. Der Server muß nun mit einem Stapel IP-Adressen antworten. Wenn UNTER dem Wort "working:" keine IP-Adressen stehen, hat der Server keine erhalten und es liegt ein Fehler vor, der gefunden und beseitigt werden muß.
vs - view known servers - IP-Adressen der dem Server bekannten eDonkey-Server anzeigen
vc - view clients - Anzeige aller connecteten Clients
g - get server stats - Anzeige der Menge an Datei-Indizies und Clients
vo - view optional settings - Anzeige der in der donkey.ini eingestellten Parameter: Port/Threads(workers)/MaxClients/erlaubte Client-Versionen
q - quit - Beenden des Servers. Dies kann eine Weile dauern, der Server muß sich erst komplett aus dem Netz abmelden
die folgenden Befehle wurden deaktiviert:
vf - view files - Anzeige aller über den Server angebotenen Dateien. Funktioniert nicht mehr, weil es sonst möglich wäre, sich Kenntnisse über illegal angebotene Dateien zu verschaffen. Die Kenntnis darüber hätte strafrechtliche Konsequenzen für den Serverbetreiber zur Folge. Der Befehl wurde daher deaktiviert.
ip # und d # - Da im Server keine Client-IDs mehr angezeigt werden, lassen sich auch diese beiden Befehle nicht mehr nutzen.
Meist läuft es nicht von Anfang an so, wie man es sich gedacht hat. Aber vielleicht wird das ja durch diese Anleitung in Zukunft besser. Wenn der Server mit VS auch nach mehr als 15 Sekunden keine anderen "working:" Server-IP's anzeigt, dann folgendes prüfen:
1. Stimmt die Syntax (Schreibweise) in der donkey.ini? Falls nicht: Korrigieren! Achtung bei Linux: Dateinamen müssen die korrekte Groß-/Kleinschreibung aufweisen. Im Gegensatz zu Windows unterscheidet Linux zwischen "donkey.ini" und "Donkey.ini"!
2. Stimmt die IP-Addresse, die beim Start des Servers angezeigt wird, mit der momentanen öffentlichen IP-Adresse angezeigten überein? Wenn nicht: Richtige IP-Adresse in der donkey.ini eintragen!
3. Ist unter der bei "seedIP=" eingetragenen IP-Adresse wirklich ein eDonkey-Server vorhanden? Mit dem Client ausprobieren, ob sich ein Server mit dieser IP-Adresse connecten lässt! Auch auf den Server-Port achten (wird unten links im Client angezeigt, wenn man den Server markiert) und ggf. abweichenden Port eintragen. Nur weil sich beim "ping"-Versuch unter einer IP-Adresse ein Host meldet, heißt das noch lange nicht, daß dort auch ein eD2k-Server läuft! Wenn trotz korrektem seedIP-Eintrag der Server sich nicht anmeldet (bei vs unterhalb des Wortes working keine, oder nur eine IP-Adresse), ist vielleicht der Seed-Server überlastet. Am besten eine aktuelle server.met aus dem Client ins Serververzeichnis kopieren, in serverList.met umbenennen und den Server neu starten. Ab sofort benutzt der Server alle funktionierenden Server aus der serverList.met als Seed-Server. Damit wird es in jedem Falle funktionieren. Wenn nicht > Punkt 4.
4. Liegt zwischen dem Server und dem Internet ein Router mit Network Address Translation (NAT/Masquerading) oder eine Firewall? Dann gilt hier das gleiche wie schon unter Router beschrieben. Die genannten Port müssen durchgeleitet werden! Dabei ist unbedingt das unter Ports geschriebene zu beachten, sonst weiß man ggf. nicht, welche Ports man in die Forwarding-Tabelle des Routers eintragen soll. Gerade die Konfiguration des Routers und/oder der Firewall machen erfahrungsgemäß bei der erstmaligen Installation des eD2k-Servers Probleme, weil doch schon etwas Wissen um Netzwerktechnik benötigt wird, um die Zusammenhänge zu verstehen und die notwendigen Konfigurationen richtig vorzunehmen. Ich empfehle www.netzwerk-router.de, eine wirklich kompetente Webseite, die sich mit der Technik von Routern und ihrer Konfiguration beschäftig. Das ICS (Internet-Connection-Sharing) von Windows XP benötigt keine weitere Einstellungen, das Modem wird quasi direkt durchgereicht, die benötigten Ports bereitgestellt. Allerdings ist die interne XP-Firewall natürlich korrekt zu konfigurieren, wenn sie aktiviert ist.
Eine nicht funktionierende oder falsch konfigurierte Weiterleitung der Ports im Router ist der am häufigsten auftretende Fehler!
5. Wenn unter Linux nicht mehr als 1015 Clients auf den Server passen, obwohl noch reichlich CPU- und Speicher-Ressourcen frei sind, hilft ein Filedescriptor-Befehl: "ulimit -n 32000". Damit sind über 10.000 Clients möglich - Wenn Rechner, Speicher und Netzverbindung (!) soviel leisten können...
Dieser Befehl kann nur als Root abgesetzt werden!
6. Wenn unter Windows 9x/Me nicht mehr als 100 User auf den Server kommen: Kein Wunder: Win9x/Me kann nicht mehr, das System ist als eD2k-Server ungeeignet!
7. Wenn sich unter Windows 9x/Me ab 100 verbundenen Usern keine Webseiten mehr öffnen lassen, sind die max. unter 9x/Me möglichen 100 gleichzeitigen Verbindungen erschöpft. Registry-Patch ausführen, anderes Betriebssystem benutzen, oder "maxClients"-Wert verringern...:-(
8. Wenn der (Win32-) Server beim Start sofort mit folgender Systemfehlermeldung abstüzt:
Prüfen, ob im Internet-Explorer ein Proxy-Server eingetragen ist. Der Server stürzt in diesem Fall sofort nach dem Start ab!
Lösung: Im IE unter 'Extras/Internetoptionen/Verbindungen/LAN-Einstellungen' über den Button 'Einstellungen' die Eintragung eines Proxy-Servers deaktivieren. Für dieses Problem gibt es leider keine andere Lösung.
9. "door couldn`t accept new socket" Der Server kann keine weiteren IP-Sockets mehr aufbauen. Unter Linux hilft ulimit -n 32000
10. "segmentation fault" (Speicherzugriffsfehler/Seitenfehler): Diese Fehlermeldung kann nur bei einem Betriebssystem mit Speicherschutz auftreten. D.h. jeder Prozess (laufendes Programm) bekommt einen bestimmten Speicherbereich zugewiesen. Versucht der Prozess auf Speicher zuzugreifen, der nicht ihm gehört, dann bricht das Betriebssystem den Prozess mit obiger Fehlermeldung ab. Zwei Ursachen sind möglich: Erstens kann das auszuführende Programm fehlerhaft sein (beim eD2k-Server recht unwahrscheinlich, da er ja schon tausendfach im Einsatz war), oder zweitens ein Hardwarefehler vorliegen (Überhitzung, Speicher defekt, falsche RAM-Timings im Rechner-BIOS). Empfehlung: Keine Übertaktung, probeweise langsamste Speicher-Timings im Rechner-BIOS einstellen, Kühlung verbessern.
11. "unknown msg from Connection: 29'' oder "ERROR: unknown type MetaTag::makeTag() 0" oder sowas ähnliches: Werden solche Meldungen in der Serverkonsole ausgegeben, hat es irgend ein Problem im Protokollbereich gegeben. Ich kann nicht im Detail sagen, was schiefgelaufen ist, jedoch spielt es meiner Erfahrung nach keine Rolle. Der Server wird brav weiterarbeiten. Einfach ignorieren.
Wer unter einem Internet-Zugang mit täglich wechselnder IP-Adresse leidet, wünscht sich schnell eine Automatisierung. Allerdings empfehle ich, erst den Server normal per donkey.ini zum laufen zu bringen und erst danach an die Automatisierung zu denken. Sonst lassen sich bei Fehlfunktionen die Ursachen nur schwer ermitteln!
1. Autodial: Wenn der ISP (InternetServiceProvider) die Leitung nach 24 Stunden kappt, muß der Rechner die Verbindung selbsttätig wieder herstellen.
2. IP-Erkennung: Da für die neue Verbindung auch fast immer eine neue IP-Adresse zugewiesen wurde, muß der "thisIP="-Eintrag in der donkey.ini angepasst werden. Außerdem muß der Server beendet und nach der Anpassung der "donkey.ini" neu gestartet werden. Ein ggf. vorhandener Redirektor-Account (DynDNS) kann dabei gleich mit aktualisiert werden, damit der Redirector immer auf die richtige IP-Adresse zeigt.
Wir "Linuxer" lieben ja Skripte und nichts liegt uns ferner, als einen komplizierten Akt der Serverkonfiguration mit einem grafischen Frontend zu versauen. Bleiben wir also treu und schauen uns das Skript für SuSE-Linux (getestet mit 7.0 und 7.3) an. Ob es auch unter anderen SuSE-Versionen läuft, oder gar unter völlig anderen Distributionen, wäre zu testen. Es dürften aber höchstens geringfügige Anpassungen notwendig sein.
Autodial und automatische Wiedereinwahl: Eine genaue Anleitung für alle SuSE-Distributionen liegt z.B. hier T-DSL ab SuSE 7.0, Konfiguration Unbedingt beachten, daß der Rechner die Verbindung nach Abbau durch den ISP automatisch wieder aufbaut, sonst hat das ganze natürlich keinen Sinn. Dazu ist (unter SuSE 7.3, andere Versionen oder Distributionen kenne ich leider nicht) in der Datei /etc/ppp/peers/pppoe ganz unten der Befehl "persist" anzuhängen. Gleichzeit darf der Befehl "idle" nicht in einem der Skripte stehen (meist in /etc/ppp/options), da sonst die Verbindung nach der eingestellten Leerlaufzeitzeit herunter gefahren wird. Am besten durch ein voransgestelltes "#" auskommentieren. Man kann als "Idle-Zeit" jedoch auch 0 angeben, das erfüllt denselben Zweck.
Automatisch den Server beenden, IP ermitteln, "donkey.ini" anpassen, Server neu starten und den Redirektor aktualisieren:
Das folgende Skript (so arbeitet es auf meinem Server) wird am Ende der /etc/ppp/ip-up einfach angehängt. Das Skript und die "donkey.ini" müssen natürlich an die jeweiligen Verhältnisse angepasst werden, ebenso die Aktualisierung des DynDNS-Redirektors und die Pfade.
Benötigte Programme:
SCREEN (SuSE Distribution oder FTP-Server) um den Server per Skript zu starten.
LINKS (SuSE-Distribution oder FTP-Server) um die öffentliche IP auszulesen, wenn der Serverrechner selbst mit einer privaten IPO-Adresse betrieben wird.
DDUP zum Update des DynDNS-Accounts.
Alles was hinter einer Raute # steht, wird nicht abgearbeitet, sondern steht nur zu Dokumentation im Skript
##################### START ###################
##################### Kill the old server ############
killall dserver &
sleep 15
killall -9 dserver
killall -9 screen
sleep 10
######## Öffentliche IP hinter Router ermitteln ###########
# Diese Zeile wird benötigt, wenn der Rechner nicht direkt am Netz angeschlossen ist, sondern mit einer Privaten IP-Adresse
# hinter einem Router arbeitet. Die öffentliche IP-Adresse wird dann mit dieser Zeile ermittelt. Dafür ist der Textbrowser 'links'
# nötig. 'lynx' wird es auch tun, dann muß natürlich VAR=`links... gegen VAR=`lynx... getauscht werden. Wenn der Rechner
# direkt am Netz hängt, wird diese Zeile nicht benötigt und kann weggelassen oder auskommentiert werden
VAR=`links -source http://netsurf.ccn.net/cgi-bin/user.pl?submit=Check | cut -d: -f3 | sed '1,2d' | sed '2,3d' | cut -d\< -f1 | sed 's/ //g'`
##################### Write the new donkey.ini ######
echo "[server]
name=Little Red Corvette
desc=Do you think about, running your own server? Just do it!
logFile=false
tableSize=3089
threads=20
type=key
console=true
maxClients=700
public=true
verbose=false
# thisIP=$4 # Bei direkter Netzverbindung diese Zeile verwenden
# thisIP=$VAR # Bei Verbindung über LAN (private IP) diese Zeile verwenden
minVersion=60
maxVersion=99
seedIP=217.55.114.161
welcome[0]=Hallo Esel-Freak! Dies ist Diesels ´Little Red Corvette´-Server
welcome[1]=AMD K6III-400, 192MB, Intel TX, GNU/Linux Kernel 2.4.10
welcome[2]=Schon mal daran gedacht selbst einen Server zu betreiben? Mach's einfach! Hilfe gibt's bei uns:
welcome[3]=Das TECHNISCHE eDonkey-Forum: http://www.ed2k-serverboard.de/diesel
welcome[4]=Greetz, Diesel (diesel@ruecker.homelinux.org)
" > /usr/donkey/donkey.ini
# Execute the server
sleep 5
screen -d -m dserver
nbuser -l 1 # Low-ID-User gestatten (0=verboten / 1=erlaubt)
nbuser -s 500 # Soft-Limit auf 500 setzen (und wird natürlich nur dann eingetragen, wenn ein solcher)
nbuser -D 2000 # Hard-Limit auf 2.000 setzen (Server auch Verwendung findet)
nbuser -B 0 # BOT-User verbieten (0=verboten / 1=erlaubt)
nbuser -Z 0 # MLDonkeys verbieten (0=verboten / 1=erlaubt)
echo "`date`: $4" >> /usr/donkey/ip.log
##################### Execute the DynDNS-Updater ############
ddup --host lrc.dyndns.org
##################### END ################################
Das war's im großen und ganzen schon. Wie zu erkennen ist, liegt der Server bei mir im Verzeichnis /usr/donkey/. Das bequemste ist, wenn man dem System einen Hinweis gibt, wo die Dateien dserver und nbuser zu finden sind. Dazu begibt man sich ins Verzeichnis /sbin und legt mit folgendem Befehl einen symbolischen Link an: ln -s dserver /usr/donkey Dieser Befehl sagt dem System, daß die Datei dserver im Verzeichnis /usr/donkey liegt. Von nun an kann man an jeder Stelle des Dateisystems auf dserver zugreifen, ohne den Pfad extra nochmals angeben zu müssen, denn das System weiß ja nun, wo die Datei liegt. Ebenso verfährt man mit nbuser.
Je nachdem, ob der Serverrechner direkt ans Internet mit seiner öffentlichen IP-Adresse angeschlossen ist, oder ob die Verbindung mittels privater IP-Adresse übers LAN läuft, muß die richtige Methode zur Ermittlung der öffentlichen IP-Adresse angewandt werden. Bei Direktanbindung befindet sich die öffentliche IP-Adresse in der Variablen $4, bei einer Verbindung übers LAN in der Variable VAR. Die jeweils zu verwendende Zeile muß daher vom # am Beginn der Zeile befreit werden, da das "#" ja bedeutet, das danach keine auszuführenden Befehle stehen, sondern nur Textbemerkungen, die nicht ausgeführt werden. Dank an Oliver für diese Idee.
Mit dem screen-Befehl hat es folgende Bewandnis: Der Server benötigt ein Terminal, um auf Tastatureingaben zu warten und Bildschirmausgaben machen zu können. Deshalb wird er mit screen -d -m dserver gestartet. Wenn der Server läuft, kann er in der Linux-Bash ganz einfach durch Eingabe von screen -r nach oben geholt werden. Sollte man nur via Telnet oder SSH Zugriff auf den Rechner haben und sich den eD2k-Server mittels screen -r auf den Bildschirm geholt haben, stellt sich die berechtigte Frage, wie man ihn wieder los wird, ohne den eD2k-Server zu beenden. Denn man kann ja keine Systemkommandos mehr ans Linux schicken, nur nach an den Server. Dazu muß eine zweite Verbindung zum Serverrechner hergestellt werden, wo der Befehl screen -d alle laufenden Screens in den Hintergrund schickt. Man kann nun einfach beide Verbindungen schließen, der Server läuft brav im Hintergrund weiter.
Der kann nun monatelang ohne Benutzereingriff laufen und wenn die Hardware einwandfrei ist, wird er das auch tun. Wenn die Verbindung vom ISP getrennt wird, stoppt das Skript den eDonkey-Server, ermittelt die neue IP, schreibt die komplette "donkey.ini" neu, startet den Server neu, setzt die korrekte Einstellung des Anti-Bot-Servers und updatet den DynDNS-Account. Feine Sache das. So soll es sein! Noch besser wäre es, wenn der Server auch noch Sonntag morgens frische Brötchen holen würde. Aber das verschieben wir auf die nächste Version...
# Netzwerk-Tuning
echo 5 > /proc/sys/net/ipv4/tcp_retries2
echo 1000 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout
echo 1 > /proc/sys/net/ipv4/tcp_abort_on_overflow
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 0 > /proc/sys/net/ipv4/tcp_sack
echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
echo 20000 > /proc/sys/net/ipv4/ip_conntrack_max
Diese Einstellungen laufen ab einem Linux-Kernel 2.4.
Es empfiehlt sich noch, die MTU (Maximum Transmission Unit) des Netzwerkdevices, welche den Datenaustausch mit dem Internet vornimmt, auf 576 Bytes zu begrenzen. Der Grund liegt im Chaos des Internet begründet: Zehntausende Internet-Router sind unterschiedlich eingestellt und wahrlich nicht jeder Router unterstützt die 1492 Bytes MTU der PPPoE Schnittstelle, mit der Folge, daß Datenpakete zeitaufwändig fragmentiert werden müssen. Zwar ergibt sich bei großen Datenmengen im Upload ein gewisser zusätzlicher Protokolloverhead, da z.B. 1 kbyte nicht mehr in ein einziges IP-Paket passen, es hat sich jedoch gezeigt, daß die Übertragung so schneller erfolgen kann. Das Device dürfte meist ppp0 lauten. Falls es bei Euch anders heißt, bitte entsprechend anpassen. Die Zeile wird unten an das Skript angehängt. Für diese Tipps danke ich Gaven (*hofknicks*).
ifconfig ppp0 mtu 576
Übrigens kann man ungebetene Clients, die eine gewisse Signatur im Nickname tragen auch ganz einfach mit iptables (2.4.x-Kernel) ausfiltern. Das sieht z.B. so aus:
iptables -A INPUT -p tcp --dport 4661 -m string --string file -j DROP
iptables -A INPUT -p tcp --dport 4661 -m string --string mldonkey -j DROP
Ausgefiltert werden im obigen Beispiel alle IP-Pakete, die "file" und/oder "mldonkey" im Nickname tragen (in der Befehlszeile ist natürlich keine Kursivschrift nötig!). Als Port des Servers wird im Beispiel der eD2k-Standardport 4661 benutzt. Bei abweichenden Ports bitte anpassen. Über iptables sind noch ganz andere Spielchen möglich, weiteres füge ich später noch hinzu... ;-) Für diesen Tipp Dank an Linuxholger (*kratzbuckel*).
Um bei Überschreitung einer kritischen Netzlast einen automatischen Neuconnect mit Zuweisung einer neuen IP-Adresse zu erreichen, braucht man unter (SuSE-) Linux nur die Datei /etc/ppp/options zu editieren: Der Wert für lcp-echo-failure wird auf 3 gesenkt. Dies hat einen automatischen Abbau der Verbindung zur Folgen, wenn drei aufeinander folgende Überprüfungen der Verbindung fehlschlagen. Sie werden ab einer kritischen Netzlast zwangsläufig fehlschlagen, nämlich genau dann, wenn die Paketverluste wegen Überlastung der Leitung zu hoch werden. Dann bricht Linux die Verbindung ab und connectet neu. Problem gelöst.
Analog zu dem unter Linux geschriebenen, folgt jetzt die grafische Lösung für die Windows-User: Unter Windows ist es dank der guten Arbeit von mailto:gabba@phreaker.net um einiges einfacher, eine Automatisierung zu erreichen. Es konfiguriert den Server 16.38 und verwaltet seinen Ablauf. Das Archiv sm100d22.zip fragt zunächst interaktiv die Daten für die donkey.ini-Datei ab (das hilft Syntax-Fehler zu vermeiden) und startet danach den Server. Es stellt fest, wenn die Verbindung unterbrochen wird, initiiert dann erneut eine Verbindung ins Internet und startet den Server mit der richtigen IP-Adresse neu. Ich glaube, das Programm ist so verständlich programmiert, das sich weitere Erklärungen dazu fast erübrigen. Das grundsätzliche trotzdem im Telegrammstil:
Das Archiv herunterladen, und in das Verzeichniss entpacken, in dem auch der eDonkey-Server mit der donkey.ini liegt. Dann ServerMaker100d1.exe starten. Es öffnet sich folgendes Fenster: (Äh, es kann sein, das sich das/die Fenster ein wenig geändert haben, da die Screenshots noch mit dem Vorgänger sm100d1.zip angefertigt wurden!)
Ich habe "via LAN(behind a router)" angehakt, weil mein Server im LAN hinter einem Router auf einem Rechner mit privater IP-Adresse (Schema: 192.168.0.1) läuft. Damit der ServerMaker die eigene (öffentliche!) IP-Adresse richtig ermitteln kann, muß hier jeweils das Häkchen richtig gesetzt werden. Meist wird das DSL-Modem (oder ISDN oder Analog...) direkt an dem Rechner angeschlossen sein, auf dem auch der Server läuft. Dann ist natürlich "Dial-Up (Modem, DSL)" anzuhaken. Die eigene IP-Adresse ist hier noch nicht einzugeben, dies wird der ServerMaker erst im nächsten Fenster (dann aber automatisch) erledigen.
Wenn man oben auf "Server-config" klickt, öffnet sich ein anderes Fenster, wo man die Daten für die donkey.ini-Datei eingeben kann.
Sehr gelungen: Der "detect IP"-Button (oben mitte). Damit lässt sich die eigene (öffentliche!) IP-Adresse absolut zweifelsfrei ermitteln. Die nun folgenden Einstellungen sind extrem wichtig:
1. Die IP-Adresse und Port Nummer des gewählten "Seed-Servers". Adresse eines vorhandenen eDonkey-Servers (Siehe weiter oben für genaue Erklärung).
2. "Public Server" MUSS angehakt sein, damit der Server sich in das weltweite eDonkey2000-System integriert.
3. "Enable console": Anhaken!
4. Hier wird auf die schnelle Suchroutine umgeschaltet. Sollte angehakt sein!
5. Meiner Erfahrung nach reichen 30 "Threads" unter Windows voll aus (entgegen dem Bild).
6. "Tablesize": 3089 ist eine Primzahl, kann direkt übernommen werden. Unnötig, selbst langwierige Berechnungen anzustellen...
7. "Allow min client version": Damit keine uralten und inkompatiblem Clients ins System kommen, begrenzt man die niedrigste Client-Version auf v.59 (Das im Bild noch die 57'er eingetragen ist, liegt nur daran, daß ich keine Zeit darauf verschwende, einen neuen, passenden Screenshot zu machen). Im Gegensatz zum Bild sollte auch unbedingt die 'Allow max client version' gesetzt werden, damit uralte Testclients nicht durch die Hintertür einer hohen Testclient-Versionsnummer (z.B. 1749 für 49'er Testclient) noch durchschlüpfen.
Also: 'Allow max client version' = 62 (Weil, z.Zt. haben wir die 61 als aktuelle Version und die 62 dürfte in Kürze eintrudeln. Dann sind wir gerüstet)
Desweiteren sind natürlich noch der Name des Servers und eine Kurzbeschreibung (Description) einzutragen, sowie der Connecttext. Nachdem alle nötigen Eintragungen erledigt wurden, oben links auf "Save" klicken und die donkey.ini wird geschrieben. Jetzt auf "Leave" (oben links) klicken und den Server mit "StartServer" im Mainfenster starten. Unten im Tray liegt übrigens das Symbol für den ServerMaker...
...womit das Programm brav im Hintergrund verschwindet und bei der Arbeit nicht mehr im Weg ist.
OK, das war jetzt wirklich nur eine rudimentäre Erklärung, aber es sollte ausreichen um den Anfang zu machen. Somit besteht jetzt also auch für Windows 2000 die einfache Möglichkeit der Server-Automatisierung.
Na, war doch nicht wirklich schwer, oder?
wünscht sich der Verfasser eine neue Sharing-Mentalität - soweit es so etwas überhaupt geben kann. Ein alter Mann sagte mir einmal, das geben seliger sei denn nehmen. Ob er damit unseren Esel vorher sah oder einfach nur meinte, daß das letzte Hemd keine Taschen hat - ich weiß es nicht. Schaut also nicht nur auf die Höhe des Downloads, sondern freut Euch auch, wenn Ihr anderen etwas geben könnt.
Sie werden es Euch gleichtun und nichts schuldig bleiben.
Desweiteren bedeutet für mich der Betrieb eines Servers auch Politik. Anteil zu haben am Kampf gegen überzogene Urheberrechts-Forderungen von Seiten der Content-Industrie, also Plattenfirmen, Filmstudios, Softwarefirmen, usw. Zwar habe ich vollstes Verständniss für die Bemühungen der Menschen, die Früchte ihrer Arbeit auch ernten zu können, ich sehe mich aber mit teilweise extrem überzogenen Forderungen nach Kopierverboten und Urheberrechtsabgaben konfrontiert. Stichwort "pay per use": Einmal hören, jedesmal dafür zahlen. DMR: "Digital Rights Management". Windows XP: Erst bezahlen, dann dauernd bei Microsoft rumbuckeln, ob sie mir vielleicht freundlichst einen "Aktivierungscode" zukommen lassen. Solche 'Tricks' sind meiner Meinung nach ganz mies, denn mir selbst ist es einmal passiert, daß ich eine Lizenz für ein Programm erworben hatte, und der Hersteller nach einem Jahr dann pleite war. Wer schaltet mir jetzt mein 'Handy-Connect' frei? Noch nicht mal verklagen kann ich sie, denn sie sind ja pleite. Super Sache das! OK, es steht wohl nicht zu befürchten, das Microsoft in Kürze schließen muß, aber dennoch: Weshalb erst ein Risiko eingehen? Auch und gerade bei großen Herstellern, die solche Dinge im Markt einführen.
Aber die fangen ja gerade erst an Geizkrägen wie mich, die sich weigern, jedes Jahr für viel Geld neue Office- und Betriebssystemversionen auszugeben, anständig zu erziehen. Und diese Erziehung zu neuen Geschäftsmodellen braucht es, weil sich mit altem Mist halt kein Geld machen lässt. Diese mangelhafte Investitionsbereitschaft der Massenkundschaft in neue Software ärgert die Produzenten. Und die gehen deshalb neue Wege: Wenn die Kunden nicht zum ständigen Update bereit sind, dann müssen sie halt dazu gezwungen werden. Und wie das geht, zeigt Microsoft mit Windows XP. Die erstmals eingeführte Zwangsregistrierung ist nur der erste kleine Schritt zum großen Finale, das von den Update-Terroristen im Höchsttempo angestrebt wird. Und wie dieses Finale aussehen wird, steht unmissverständlich fest: Die Zeit naht, in der Du keine Software mehr kaufen kannst. Eine Software kaufen und sie nutzen - das hat keine Zukunft mehr. Bald werden wir so weit sein, dass Software und Betriebssysteme nur noch im Abonnement gemietet werden können. Im Klartext heißt das: Wer einen PC mit Microsoft Windows betreiben will, der zahlt an Microsoft entweder jeden Monat die Abosumme X oder der Bildschirm bleibt schwarz. Alles wird sich so abspielen wie beim Pay-TV schon heute: Je mehr Programm- und Softwarevielfalt der Anwender braucht, desto mehr wird er dafür monatlich für Abokosten zahlen müssen. Zu wenig Kohle, alles zu abonnieren? Kein Problem. Die Quertreiber müssen dann eben in Kauf nehmen, dass die Textverarbeitung im Abstand von 10 Minuten für mindestens 5 Minuten durch Werbeeinblendungen unterbrochen wird - alles halt so, wie's auch heute schon beim »kostenlosen« Free-TV ist.
Demnächst steht uns TCPA/Palladium (Trusted Computing Platform Alliance) ins Haus. Das bedeutet, das unsere Computer sicherer werden. Aber nicht sicherer für uns Anwender, sondern sicherer für die Copyright-Industries. Die werden nämlich dafür sorgen, daß Ihr "Content" nur noch auf den Computern läuft, die dem Anwender unerlaubtes Kopieren definitiv verweigern. Ich nenne das mal die ständige totale Kontrolle der Urheberrechtsinhaber über ihre Inhalte, auch dann noch, wenn sie längst an die Kunden "verkauft" wurden. Das ist der absolut allergröste Coup, den wir Konsumenten jemals bezahlt haben werden. Womit wir dann wieder bei "pay per use" angekommen wären. Microsoft weiß über das Potential von TCPA und Palladium natürlich ganz genau Bescheid (die haben es ja entwickelt), behauptet aber öffentlich immer noch, das es sich nicht um eine neue Art von Kopierschutz handeln würde. Das entspricht natürlich nicht der Wahrheit, sie trauen sich nur nicht, den Kunden reinen Wein einzuschenken. Nichts anderes als die Gewährleistung der totalen Kontrolle über "Content" (also Musik, Filme, Programme) ist der eigentliche Sinn von TCPA/Palladium.
Freunde, so funktioniert das nicht!
Ein cleverer Hacker hat daher in den USA ein Patent auf die Verwendung von TCPA/Palladium als Kopierschutz angemeldet. Die Folge: Ist TCPA/Palladium tatsächlich ein Kopierschutz, muß das Patent zugelassen werden, obwohl Microsoft der Entwickler ist. Aber die wissen ja anscheind nichts von der Eignung als Kopierschutz von TCPA/Palladium, also können sie der Erteilung dieses Patentes schwerlich wiedersprechen. Wird TCPA/Palladium dann tatsächlich als Kopierschutz benutzt, werden die Redmonter Lizenzgebühren an den Hacker zahlen müssen... 
Schon immer wurde Musik kopiert und getauscht, ich erinnere mich natürlich, wie wir auf dem Schulhof gegenseitig Kassetten getauscht haben. Vor 30 Jahren gab es natürlich noch kein Internet, aber die Musikindustrie hatte ihre Schäflein bereits im trockenen, weil die GEMA einen Aufschlag auf den Verkaufspreis von Kassettenrecordern und Kassetten durchsetzen konnte. (Übrigens wurde ich von einem aufmerksamen eD2k-Serverbetreiber darauf hingewiesen, dass das Internet schon seit 1969 besteht, also doch schon 33 Jahre, wenn auch nicht in seiner jetzigen Form...) Man wollte schließlich mitverdienen. Gut, ist ja nicht wirklich etwas dagegen auszusetzen. Etwas anderes ist es, durch extrem restriktive Gesetze den Bürgern den Austausch von Inhalten (also Daten) generell zu verbieten und/oder massiv zu erschweren und dann trotzdem noch die Hand aufzuhalten. Dies stellt meiner Meinung nach einen Angriff auf die persönliche Freiheit jedes einzelnen Bürgers dar und dagegen zu kämpfen, erscheint mir als meine Pflicht. Schon mit Blick auf nachfolgende Generationen, die in einem Rechtssystem leben müssen, welches wir durch unser Handeln entscheidend mitbeinflussen können. Aber spätestens hier beginnt die Politik und da hat natürlich jeder Mensch ein Recht auf seine eigene Meinung, die ich selbstverständlich respektiere.
Ich wollte es nur mal gesagt haben ;-)
Wird fortgesetzt!
Greetz, Diesel
Zum technischen eDonkey 2000 Forum bei Parsimony
Eigentlich überflüssig dies hier noch zu schreiben, aber:
Die Nutzung der hier wiedergegeben Daten, Beschreibungen und Verfahrensweisen zu den hier aufgeführten Zwecken ist generell jedermann völlig kostenlos gestattet. Wenn jemand es schaft, durch die normale Nutzung meiner Webseiten zu Reichtum zu kommen, dann sei ihm dies herzlichst gegönnt. Allerdings wehre ich mich gegen den leider sehr oft praktizierten "Webseiten-Nep"! Das ungenehmigte Anbieten meiner Inhalte ist unzulässig, ganz besonders dann, wenn es zur Wertsteigerung oder zum gewerblichen "Klicks-sammeln" für Werbebanner auf fremden Webspace benutzt wird.
Selbstverständlich darf auf diese Webseite verlinkt werden, dazu bedarf es auch keiner weiteren Erlaubnis von mir.