Häufig gestellte Fragen (FAQ)

GUI = Graphical User Interface ("Graphische Benutzer Schnittstelle", zwischen Benutzer und Computer)
Auf deutsch: Fenster, Buttons, alles bunt etc. (statt rein textbasierter Aus- und Eingabe).

'Der Core' ist das eigentliche edonkey Programm, das alles im Hintergrund erledigt, also z.B. eine Verbindung zu den Servern aufbaut, die Suche ausfuehrt, Sachen runterlaedt, Sachen hochlaedt, etc. (die direkte Übersetzung von core ist "Kern", was die Sache ziemlich gut trifft).

Allgemein gesagt, ist der 'Core' nix anderes als der gewöhnliche Linux Command-Line-Client. Wird er aber mit einer speziellen Option (nämlich '-') gestartet, ist er nicht mehr der gewöhnliche Command-Line-Client, sondern hört auf einem speziellen Admin-Port (den man mit dem Command-Line-Client mittels des 'aport'-Kommandos setzen kann (Standard: 4663) nach einer GUI, die ihm sagt, was er tun soll.

Normalerweise wird der 'Core' mit der GUI gestartet. Sollte das aus irgendeinem Grund nicht gehen, oder man will dies manuell machen, muß man den Core auf eine ganz bestimmte Weise starten, damit er von der GUI aus kontrolliert werden kann: './donkey - !' oder './donkey_s - !' (abhängig vom verwendeten Binärprogramm). Das Ausrufezeichen ist nicht wirklich notwendig, aber es vermeidet Schwierigkeiten beim Schließen des Core durch die GUI.

Der Core macht einfach die ganze Arbeit. Man braucht eine Benutzerschnittstelle, um dem Core zu sagen, was er machen soll (wie z.B. zu Server verbinden, Suchen, Sachen herunterladen). Der Core besitzt eine ziemlich einfache textbasierte Schnittstelle (=Command-Line-Client), über die man ihm sagen kann, was er tun soll. Das geht über Kommandos wie 'c' für "Verbinden (englisch connect)" und 'd 1' für "Lade Suchergebnis Nummer 1 herunter (englisch: download search result number 1)". Die meisten Menschen finden das äußerst unbequem und nutzen das ein Fesnter mit Listen und Schaltflächen zum Anklicken. Die 'GUI' ist ein separates Programm, das sich mittels einer TCP- Verbindung mit dem Core verbindet und ihm sagt, was er tun soll. Genauso sendet der Core der GUI Nachrichten, wenn etwas passiert (z.B. wenn ein Download fertig ist), damit die GUI dies dem Benutzer darstellen kann.

Die GUI und der Core sind zwei komplett verschiedene Programme unter Linux. Sie kommunizieren miteinander über eine Internet-Verbindung (TCP) und jeder sagt dem anderen, was er gerade tut. Unter Windows sind die GUI und der Core in einem einzigen Programm untergebracht, wobei der Core dem Benutzer verborgen bleibt.

Falls noch nicht geschehen, packt man als erstes das Archiv mit den GUI-Dateien aus. Auf der Kommando-Zeile gibt man 'tar xzf linux_gui_alpha.tgz' (oder wie das Archiv auch immer gerade heißen mag) ein. Das Archiv hat entweder die Endung '.tgz' oder '.tar.gz', wobei ersteres eine Kurzschreibweise für letzteres ist.

Achtung: Man sollte das GUI nicht auf einer Windows-VFAT-Partition auspacken, es sei denn, man weiß was man tut. Windows-Partitionen werden unter Linux oft so gemountet, daß Programme, die darauf liegen nicht ausgeführt werden können. Wenn man die Archive irgendwo in seinem Home-Verzeichnis oder so auspackt, braucht man sich um die Zugriffsrechte keine Sorgen zu machen. Das temp- und das incoming-Verzeichnis von eDonkey kann man dann auf eine Windows-Partition legen, vorausgesetzt man hat Lese- und Schreibrechte darauf.

Bevor man die GUI benutzen kann, muß man einen Admin-Benutzer inklusive Passwort einrichten. Aus Sicherheitsgründen geschieht dies manuell, was man allerdings nur einmal machen muß.

Dazu ruft man das Programm 'edonkey', das dem GUI-Archiv beiliegt, auf der Kommandozeile [1] auf, und gibt folgendes ein: 'pass benutzername passwort' (gefolgt von einem ENTER). "benutzername" und "passwort" sind hier Platzhalter, man muß also einen eigenen Benutzernamen mit Passwort ausdenken. Anschließend gibt man 'q' ENTER und 'y' ENTER ein. Dadurch wird der Core geschlossen und die Einstellungen abgespeichert.

Danach startet man die GUI (ed2k_gui) entweder durch Anklicken des Dateinamens in einem File-Manager oder durch Aufrufen in der Kommandozeile. Klickt man 'spawn local donkey' an, wird ein edonkey2000-Core auf der gleichen Maschine wie die der GUI gestartet. Man kann sich auch an einen Core, der auf einem anderen Rechner läuft verbinden. Dieser muß allerdings manuell mit der Option '-' gestartet werden, damit er auf eine GUI-Verbindung hört (und am besten gibt man noch ein '!' als Kommandozeilen-Option mit, um sicherzustellen, daß der Core auch sauber durch die GUI beendet werden kann).

[1] Wie man den Kommandozeilen-Client manuell (ohne Zugriff durch die GUI) startet: Auf einer Konsole (oder in einem X-Window-Fenster wie xterm), gibt man './donkey_s' oder './donkey' ein (jenachdem ob man das statisch oder das dynamisch gelinkte Programm benutzt). NOTA BENE: Wenn man verschiedene edonkey-Programm-Versionen gleichzeitig auf seinem Rechner hat, muß man diejenige von der Kommandozeile aus benutzen, die mit der GUI kommt (d.h. man wechselt zunächst in das passende Verzeichnis mit 'cd /home/heinz/meinverzeichnis' {Beispiel!}).

Als erstes brauchst Du irgendwo einen laufenden edonkey Core. Normalerweise läuft er auf dem gleichen Rechner wie die GUI. Über den Schaltflächen sollte eine Statusmeldung sein, die aussagt, ob ein edonkey Core lokal läuft oder nicht. Wenn nicht (was üblicherweise der Fall ist), drücke auf 'spawn local donkey' um den edonkey2000 Core zu starten. Die Statusmeldung sollte sich jetzt ändern. Wenn nicht, muß man den Core manuell wie in Frage 2 beschrieben starten. Bitte schickt alle Probleme, die ihr damit habt, an mich, inklusive was ich gemacht habt, welche Werte im 'connect-to'-Dialog zu sehen sind und den vollen Pfad zur GUI und dem edonkey Core. Die Mail darf ruhig auch in deutsch sein.

Als zweites, vorausgesetzt der Core läuft korrekt, gibt man den Admin-Benutzer und dessen Passwort in die entsprechenden Felder im 'connect to'-Dialog an und klickt auf 'connect'. Jetzt sollte der 'connect to'-Dialog verschwinden und die GUI mit dem Core verbunden sein. Falls dies nicht der Fall ist, kann es eines der folgenden Probleme sein (bitte überprüft auch die Status-Zeile im GUI-Hauptfenster nach Meldungen):

(a)Du willst Dich mit dem falschen Computer ('host') verbinden. Normalerweile ist das 'localhost'.

(b)Du willst Dich auf dem falschen Port mit Deinem Computer verbinden. Der GUI-port kann mittels 'aport' im Core geändert werden, sollte auf standardmäßig auf 4663 stehen.

(c)Es ist kein Admin-Benutzer und/oder dessen Passwort mit dem Core gesetzt worden (s. Frage 4).

(d)Dein Username/Passwort sind falsch (starte den Core und gib 'vo' ein, um die entsprechenden Einstellungen zu sehen).

(e)Der 'connect to'-Dialog verschwindet, aber es scheint nichts zu passieren. Meistens findet man im Optionen-Dialog 'pleasewait' als nickname: dies geschieht, wenn man sich auf den falschen Port des Cores verbindet, nämlich auf den Port, den der Core als _Daten_-Port nutzt. Starte den Core und gib 'vo' ein, um zu sehen, was der Admin-Port ist. Stelle nun sicher, daß der 'admin port' ein anderer als der 'door port' (=Daten-Port) ist. Im Zweifelsfall, gib 'netstat -l' in einer Konsole oder Shell ein, und überprüfe, auf welchen Ports der donkey hört. Es sollte einer der beiden sein.

(f)Wenn Du mit der GUI einen Core auf einem anderen Rechner kontrollieren willst, könnte es sein, daß eine Firewall zwischen Dir und dem anderen Rechner sitzt, und alle TCP-Verbindungen auf dem Admin-Port blockt. In diesem Fall muß man die Firewall-Einstellungen überprüfen und diese Verbindungen erlauben (lassen), oder einen anderen Port als Admin-Port nehmen.

Als Drittes bist Du mit dem Core verbunden und auf der Optionen-Seite steht nix von 'pleasewait' als nickname. Dies ist ein sehr gutes Zeichen, was bedeutet, daß die GUI und der Core miteinander reden können. Jetzt solltest Du alles machen können, was Du willst: Gehe zur Server-Seite und verbinde Dich zunächst mit einem Server. Dann kannst Du suchen und Sachen downloaden. Wenn Du mit Rechts-Klick einen Listen-Eintrag anklickst, siehst Du alle jetzt möglichen Aktionen. Aber vergiß nicht zu sharen!

Überprüfe im Optionen-Dialog, ob 'pleasewait' als Nickname eingetragen ist. Wenn ja, schau bei Frage 5e oben nach. Wenn nein, weiß ich auch nicht, was schief läuft. Bitte schicke mir eine Mail.

Weil Deine GUI-Version zu alt ist? :)
Alle GUI-Versionen nach dem 21.4.2002 können die Fortschritts-Balken anzeigen, allerdings nur in Verbindung mit einem Core, der "gaps" kann.

Das macht er nicht. Oder nur sehr wenig. Wenn sich die Versionen unterscheiden, dann ist der Core, der mit der GUI kommt neuer und hat wahrscheinlich einige neue Funktionen, die die GUI braucht, die aber noch nicht in der letzten offiziellen Version vorhan den sind.

Weil es einfacher ist und die Download-Datei kleiner macht. Weiterhin kann jeder, der das dynamisch gelinkte Programm ausführen kann, auch das statisch gelinkte ausführen, aber nicht umgekehrt. So einfach ist das.

Einige Leute finden das dynamisch gelinkte Programm 'donkey' schneller als das statisch gelinkte 'donkey_s'. Meiner Meinung nach ist das praktisch Humbug, nicht nur aus theoretischen Überlegungen heraus, sondern auch auf Basis einiger Laufzeit-Tests, die ich gemacht habe. Jeder, der mich vom Gegenteil überzeugen will, ist eingeladen, mir reproduzierbare Laufzeit-Tests und -Ergebnisse zuzuschicken (aber bitte erst ab Pentium). :)

In 'gui_options' stehen einfach alle _GUI_-Einstellungen (wie z.B. die letzte GUI-Fenster-Größe, die Größe der Spalten in den verschiedenen Tabellen, Deine GUI-Optionen wie 'shutdown Core on exit'/'confirm cancel' usw.). Nebenbei steht auch Dein Standard-Username/Passwort drin, mit dem Du Dich an den Core verbindest. Daher sollte dieses Files nur für den User les- und schreibbar sein, der die GUI benutzt und für sonst niemanden (dies kann man mit dem 'chmod'-Kommando machen).

In dieser Datei steht eine Liste von Namen von edonkey2000-Servern, die keine statische (=fixe) IP-Adresse haben. Beim Start der GUI wird diese Datei (1 Hostname je Zeile) von ihr gelesen und die Hostnamen zur aktuellen IP-Adresse aufgelöst. Diese Server werden von der edonkey2000-Serverliste entfernt, wenn die GUI den Core herunterfährt.

Ab Version 0.2 der GUI sind Filter rudimentär implementiert. Dazu legt man im Verzeichnis ~/.ed2k_gui/ eine Datei names gui_lookuplist mit je einem Wort pro Zeile an. Nun werden Suchergebnisse, die ein Wort aus dieser Datei ganz enthalten, herausgefiltert. Beginnt ein Wort mit einem '*', werden auch Suchergebnisse gefiltert, die das Wort als Substring enthalten. Es wird nicht zwischen Groß- und Kleinschreibung unterschieden.

Beispiel:
south
*germ

Im allgemeinen werden sie das nicht tun. Es hängt aber davon ab, wie der Core gestartet wurde. Wenn er manuell von einem xterm innerhalb X-Windows gestartet wurde, wird er wahrscheinlich aufhören, wenn X abstürzt oder heruntergefahren wird. Gewöhnlich wird der Core weiter downloaden bis er explizit von der GUI (oder beim Verlassen der GUI, wenn 'always shutdown Core on exit' markiert ist) oder von der Kommandozeile aus gestoppt oder der Computer heruntergefahren wird. Manchmal stürzt der Core auch von ganz alleine ab ;).

Dies passiert wenn die Verbindung zwischen dem Core und der GUI unterbrochen wird, was meistens auf einen abgestürzten Core, oder - falls der Core auf einem anderen Rechner läuft - oder eine unterbrochene Netzwerkverbindung zurückzuführen ist.

Dafür gibt es eine ganze Reihe von Gründen.

Erstens ist einer der Vorteile von Linux gegenüber Windows, daß man unter Linux eine Wahl hat, was man als X-Window-System, X-Window-Manager, Desktop-System, usw. bevorzugt. Möglicherweise ist für Dic h KDE einfach das Beste (und, ja, ich nutze auch KDE), für andere aber nicht. Nun war mein Ziel, etwas zu produzieren, das auf möglichst vielen Installationen läuft, und da war das GTK+-Toolkit der kleinste gemeinsame Nenner, wenn man direkte XLib-Programmierung vermeiden wollte. Es wird nahezu auf jedem X-Window-System installiert, KDE nicht. (Wie war wieder das Argument des Liberalen? Etwas hat Wert weil es jemand wählt, ... ;) )

Zweitens wollte ich etwas schreiben, das mehr oder minder einfach auf andere Systeme (Windows, BeOS, Mac OS X) und Architekturen portiert werden kann. Qt gibt es für eine ganze Reihe von Plattformen, aber im Moment muß man eventuelle Lizenz-Probleme auf Nicht-Linux-System in Betracht ziehen.

Drittens weiß ich ziemlich wenig von C++, und ich schrieb das Programm während meinen letzten Uni-Examen. Ich merkte, daß ich eher etwas Brauchbares herausbringen konnte, wenn ich es in C schrieb, als zunächst C++ zu lernen. So einfach ist das!

Die GUI is mittlerweile open source und unter der GNU Public License (GPL) lizenziert. Die GUI homepage ist http://ed2k-gtk-gui.sourceforge.net

werden von der GUI nicht richtig dargestellt? Symptom: Wenn eine Zeichenkette mit internationalen Zeichen dargestellt werden soll, wird die Zeichenkette an der Stelle, wo das internationale Zeichen sein sollte, abgeschnitten.

Dieser Fall kann bei in der SDB SuSe knowledge database nachgelesen werden.

Ja, das geht, aber die beiden GUIs müssen in verschiedenen Verzeichnissen (z.B. /home/joe/ed2k_gui1/ und /home/joe/ed2k_gui2) sein. Warum man das tun muß? Weil die GUI in regelmäßigen Abständen ihre Einstellungen abspeichert (in gui_options), die Up- und Download-Statistiken (nach gui_uploadstats) und wahrscheinlich die Ausgabe des Status-Fensters (nach gui_statuslog). Natürlich kannst Du die GUI aus einem Verzeichnis heraus zweimal starten, dann würden aber beide periodisch ihre Werte sichern und damit die des jeweils anderen überschreiben. Das macht natürlich nichts, wenn es Dir egal ist, ob Deine Einstellungen gesichert werden oder das Statuslog verwirrend und unübersichtlich ist. Wie auch immer, es ist besser die beiden GUIs aus verschiedenen Verzeichnissen heraus zu starten.

Update: Alle GUI-Versionen nach dem 21.4.2002 speichern die Konfigurationsdateien im Verzeichnis ~/.ed2k_gui. Möchte man nun zwei GUIs gleichzeitig laufen lassen, muß man eine davon mit der Option '-n' auf der Kommandozeile starten, damit sie separate Konfigurationsdateien verwendet, also z.B. 'ed2k_linux_gui -n 2'. Mehr Informationen gibt's dazu auf GUI-Home-Page.

Oder: Was passiert, wenn ich schon eine GUI laufen habe, die einen Core kontrolliert, und mein WG-Kollege eine weitere GUI auf seinem Rechner startet, die sich an den gleichen Core (z.B. auf einem Router) verbinden will?

Das funktioniert nicht. Nur eine Person kann zur gleichen Zeit einen Core kontrollieren. Wenn Deine GUI mit dem Core verbunden ist und jemand anderes versucht das ebenfalls, schickt ihm der Core eine Nachricht 'Another control attempt'.

Sie sind ziemlich unverläßlich. Sie gibt es für die gelangweilten, die neugierigen und die Kontroll-Freaks ;)
Aber ein paar Dinge sollte man über sie wissen:

Erstens werden sie von der GUI selbst erzeugt, mit anderen Worten: wenn man die GUI schließt und den Core laufen läßt, wird der Core weiterhin up- und downloaden. Diese Up- und Downloads werden aber bei der Statistik nicht berücksichtigt! Nur Up- und Downloads, die während einer GUI-Verbindung stattfinden, werden mit in die Statistik genommen.

Zweitens sind es Schätzungen. Wie das funktioniert? Der Core verschickt periodisch die aktuellen Up- und Download-Geschwindigkeiten für alle Up-/Downloads. Momentan empfängt die GUI alle 3 Sekunden Geschwindigkeitswerte. Jetzt geht die GUI folgendermaßen: sie empfängt z.B. den Wert 25 kB/s, dann nimmt sie dies als Durchschnitt (was es aber nicht ist!) für die letzten drei Sekunden und meldet, wir hätten 75 kB in 3 Sekunden übertragen.

Dies ist eine sehr grobe, aber auch sehr einfache Art der Schätzunge. Sie sollte für normale Up- und Download-Geschwindigkeiten ausreichend sein, also für 95% der Leute. In internen LAN mit Geschwindigkeiten bis 750kB/s und höher funktioniert sie aber nicht so gut. Kurzgesagt: je höher die Geschwindigkeiten, und damit kürzeren Downloadzeiten, desto ungenauer wird sie.

Ergänzung: Was will die ul/size ratio mir sagen?

Ehrlich gesagt, ich weiß es nicht. Ich denke, es verhält sich wie folgt:
Was sagt uns 'amount uploaded' (= hochgeladene Menge)? Wie beliebt eine Datei im Vergleich zu anderen ist, richtig? (Es gibt einige Annahmen über 'equal average chances' und 'equal average slot sizes' für alle Leute, die ein File wollen, aber ich denke, daß diese über einen langen Zeitraum als richtig angenommen werden können). Nehmen wir weiterhin an, daß wir uploaden, um andere Menschen 'glücklich' zu machen (eher glücklicher, aber wen juckt's). Wenn wir dann, um Plattenplatz zu schaffen, eine Datei aus dem Share entfernen müssen, schauen wir auf die Upload-Statistiken und entfernen die am wenigsten gefragten. Aber:dies würde unsere Absicht (die gute Laune anderer zu erhöhen) nur dann erfüllen, wenn die Annahme, daß die gute Laune mit dem übertragenen Volumen steigt, richtig ist (zumindest wird diese Annahme impliziert).
Jetzt kann jemand natürlich einen ganz anderen Standpunkt einnehmen, und sagen, daß die gute Laune anderer nicht von der übertragenen Menge, sondern von der Anzahl kompletter Einträge abhängt (mit andereren Worten: der Grenznutzen je übertragenem MB sinkt mit der Dateigröße). Eine einzige Folge von "Meine 14 Tage mit einem Austauschprogramm in Paris - ein Tagebuch" wird die die gute Laune anderer daher genau so viel steigern wie "Die Erkundigung des Louvre", das 10-Mal größer als eine Tagebuch-Episode ist.
Wenn wir danach gehen, ist der ul/size-Faktor der Indikator, den wir nehmen sollten.

Hat jemand noch andere gewagte Interpretationen? ;)

Zunächst sei angemerkt, daß das ganze statistische Zeugs vollkommen unglaubwürdig, fehlerhaft und experimentell ist. Wenn Du mitbekommst, daß dort was Verrücktes passiert, dann gib mir Bescheid, aber sei nicht überrascht.

Nehmen wir die Zeile: 'Total upload: ~17.63G in 11.5 days (~1565.3M/day) - actual: ~220.2kB/s, uploading 8.4% of the time (23.3h)' - was bedeutet das (vorausgesetzt es ist schon gelaufen)?

Es bedeutet, daß die GUI seit dem letzten Rücksetzen der Statistiken 11,5 Tage zurück dem Core beim Upload von 17 GB zugeschaut hat. Wenn der Core im Hintergrund ohne verbundene GUI läuft, lädt er zwar weiterhin hoch, die GUI bekommt das aber nicht mit und kann dies deshalb auch nicht mit in die Berechnungen mit einbeziehen. Die 11,5 Tage sind der Zeitraum, seitdem die Statistiken das letzte Mal zurückgesetz wurden. Es heißt nicht, daß der Core oder die GUI seit 11,5 Tagen laufen. Wenn man die Statistiken zurücksetzt, zwei Wochen in Urlaub geht, beim Zurückkommen wieder die GUI mit dem Core startet, zeigt sie '0 GB in 14 days' an, obwohl der Rechner während dieser Zeit ausgeschaltet war.

Nun, die '23.3h' sollte die Zeit sein, seit der die GUI mit dem Core verbunden ist, und sie mitbekommen hat, daß der Core hochlädt (total upload speed> 0kB/s). 23,3 Stunden sind 8,4% von 11,5 Tagen. Und eine 'actual speed' von 220.2kB/s bedeutet, daß die durchschnittliche Geschwindigkeit um die 220kB/s ist, wobei da nur die Zeiten mit reingehen, in denen tatsächlich hochgeladen wurde.

Wenn man Kommandos dort eingibt, öffnet die GUI eine Shell via system() und führt die eingegeben Kommando(s) aus. Dabei exportiert die GUI 2 Umgebungsvariablen: $ED2K_FN hält den Dateinamen des grade fertiggestellten Files und $ED2K_IN beinhaltet den Pfad zum Incoming-Verzeichnis. Die GUI verknüpft diese Exports in der Form 'export ED2K_FN="filename" && export ED2K_IN="/mnt/daten/incoming" && [hier steht dein kommando]'.

Was man mit dieser Funktion anstellt, liegt ganz bei einem selbst. Grundsätzlich kann man damit alles machen ;) Aber bitte denkt daran, daß diese Funktion experimentell ist, und wenn ihr also nicht ganz genau wißt, was ihr grade macht und was das Schlimmste ist, was Eurem System passieren kann, wenn etwas schief geht, damm laßt es bitte bleiben. Auftretende Fehler schickt ihr mir bitte per e-Mail.

Ein einfaches Beispiel: Ich habe bei in 'exec on complete' den folgenden Eintrag:
echo -e "$ED2K_FN\n~.\n" | mail -s "Download complete, dude" tim
Dieser schickt mir nach jedem fertiggestellten Download eine e-Mail auf meinem lokalen System. Wenn das Mail-System richtig aufgesetzt ist, kann man auch externe Adressen wie z.B. dude@wakeup.com verwenden. Es kann auch sein, daß man 'procmail' oder 'sendmail' anstatt 'mail' nutzen will (oder auch muß). Wenn jemand weitere coole, anspruchsvolle Beispiele kennt, der lasse es mich bitte wissen :-)

Noch ein Beispiel:
echo "$ED2K_FN ist fertig!" | smbclient -M JOHANNA schickt eine Pop-Up_Nachricht an den Client names JOHANNA (\\JOHANNA) im internen Netzwerk in der Windows Netzwerk-Nachbarschaft.

Wie ihr wahrscheinlich wißt, ist es unter Windows möglich, einen Server einfach durch Anklicken eines 'ed2k://|server|9.8.7.6|4661|'-Links hinzuzufügen, und einen Download ohne Suchen durch Anklicken eines ed2k://|file|Drunk Baby Animation.avi|630116|3490b0765c3467f9e3c5ebcdfc33d251|-Links zu starten.

Was braucht man, ed2k-Links unter Linux zum Laufen zu bringen? Man braucht eine GUI, die mit ed2k-Links umgehen kann (z.B. die Linux-C-GUI - im Moment jede Entwicklungsversion ab dem 16. Dezember 2001), und einen Core, der das Starten von Downloads aus ed2k-Links unterstützt (momentan z.B. die speziellen Core-Versionen, die in meinen Beiträgen im Forum verlinkt sind, und auch auf der GUI-Home-Page zu finden sind). Im Moment kann man ed2k-Links nur pber die GUI (oder den phpdonkey) benutzen, aber nicht mit dem Command-Line-Client selbst. [Anmerkung des Übersetzers: die v59 des Cores kennt das Kommando 'dllink', was diese Funktion implementiert.]

Mit den neuesten GUI-Entwickler-Versionen (> 17.12.2001) sollte man in Lage sein, einfach durch Drag'n'drop einen ed2k-Link aus dem Browser in die GUI zu ziehen. Je nach GUI-Optionen wird der Download entweder sofort gestartet oder der Such-Ergebnis-Liste hinzugefügt.

Wie funktioniert das? Die GUI hört von einer benamten FIFO-Pipe '/tmp/.ed2k_gui_socket' (das ist wie eine Datei auf dem lokalen Dateisystem) und man selbst oder andere Programme könne einzelne ed2k-Links oder auch ganze ed2k-Linklisten in diese Pipe geschoben werden. Auf der Kommandozeile geht das einfach mit 'echo "ed2k://|file|somefile|size|hash|"> /tmp/.ed2k_gui_socket' oder 'cat linklist.html> /tmp/.ed2k_gui_socket'. Es werden Server- und Dateilinks akzeptiert. Anhängig von den aktuellen Einstellungen, erscheinen die Links entweder auf der Such-Ergebnis-Liste oder werden gleich heruntegeladen.

Und nun das bunte Zeugs:Koen Bailleul hat einen ed2k://-Protokoll-kioslave für KDE2 geschrieben. Das bedeutet, daß man im Konqueror auf ein ed2k-Link klickt und dieser automatisch wie unter Windows an die GUI weitergegeben wird. Zur Zeit (16. Dezember) ist der kioslave noch nicht erhältlich, da es immer noch ein paar Installationsprobleme gibt, die in Ordnung gebracht werden müssen, aber es lohnt sich, die GUI-Home-Page regelmäßig deswegen zu besuchen.

Drag'n'drop sollte mit Galeon gehen.

Falls Dir Drag'n'drop nicht gefällt, gehe ins GNOME-Kontroll-Centern und wähle "URL Handlers" in der "Document Handlers"-Kategorie aus. Dann gib "ed2k" (ohne Gänsefüßchen) in das Feld links von "handler" und als handler

sh -c 'echo $0>/tmp/.ed2k_gui_socket' "%s"

(Vielen Dank an Friedrich Delgado Friedrichs für diesen Hinweis. Anmerkung: Was passiert, wenn die GUI nicht läuft und damit die Pipe nicht existiert? Vielleicht sollte man vorher einen 'Test' machen?)

Hier gibt's eine anspruchsvollere Version um GNOME-Applikationen ed2k-link-Handling beizubringen.
(Vielen Dank an Veit Wahlich)

Alles ist möglich. Tatsache ist, daß es sehr schwer ist, passende Vergleiche zu machen. Selbst wenn alle Einstellungen exakt die gleichen sind, werden die meisten edonkey-Benutzer wahrscheinlich zustimmen, daß die Download-Geschwindigkeit eine Funktion von praktisch Allem sein kann, d.h. sie kann kann vollkommen zufällig sein. Vielle icht hast Du grade eine gute Zeit mit Deinem Windows-Client und eine schlechte mit Deinem Linux-Client erwischt. Ich habe "Leute, holt Euch den Linux-Client, der ist viel schneller" mindestens genauso so oft wie das Gegenteil gehört.

Tatsächlich ist auch der Code, der das Downloaden, Uploaden und die Quellensuche macht, exakt der Gleiche sowohl im Windows- als auch im Linux-Client sind. Es ist ein und derselbe Source-Code! Das Problem ist, daß der Source-Code ständig weiterentwickelt wird, daß mit ihm herumgespielt wird und daß Änderungen hinzukommen und andere wieder weggenommen werden. Auch wenn der Linux-Client die gleiche Versions-Nummer wie der Windows-Client hat, wurden beide nicht zur selben Zeit compiliert, so daß die aktuelle Implementierung zwischen dem v58-Linux- und dem v58-Windows-Client etwas verschieden sein können. Hinzukommt, daß es i.allg. noch ein paar verschiedene 'inoffizielle' Linux-ClientVersionen gibt, die auch zu verschiedenen Zeitpunkten übersetzt wurden. Man muß diese halt ausprobieren, und die Version nehmen, die bei einem am besten funktioniert (wenn da nicht das Problem wäre, daß in neueren Versionen Fehler behoben wurden oder neue Features hinzugekommen sind ;).

Ich kenne den Grund dafür nicht, aber ein Yast-Upgrade (oder Yast-update, wie auch immer es heißt) löst das Problem.

Der Grund dafür könnte sein, daß neuere Versionen (v59, eventuell auch v58) ein anderes pref.met-Format haben und daher die alten v57-Einstellungen nicht richtig lesen können. Das bedeutet, daß Du vielleicht Deinen GUI-Admin-Benutzer mit Passwort, den aport, das Incoming- und das Temp-Verzeichnis und die anderen Optionen nochmal manuell mit dem Command-Line-Client setzen mußt. Danach sollte eigentlich alles wieder prima funktionieren.

(28-96) ... Noch nichts hier :)

Schicke bitte eine e-Mail (auch in deutsch) an tim@edonkey2000.com mit einer kurzen Problem-Beschreibung und sovielen Details wie möglich.

Bitte denk daran, daß nicht alle Probleme von der GUI kommen. Einige kommen vom Core (z.B. "I can't connect to any servers"), andere von einem nicht korrekt aufgesetzten System oder Fehlern in den Systemkomponenten (Bibliotheken, Kernel, usw.).

Bitte postet einen Fehlerreport im sourceforge bug-tracking system mit so vielen Details wie mö&glich. Wenn Du einen sourceforge account hast, dann log Dich bitte ein, damit ich Dich erreichen kann, falls ich weiter Details brauche.

Schick mir eine e-Mail. Positives Feedback macht mich immer glücklich :)

Ausserdem habe ich jetzt eine amazon.co.uk Wunschliste und eine amazon.de Wunschliste für den Fall, daß Du mir für die Millionen Stunden harter Arbeit an der GUI und am core eine kleine (oder große) Aufmerksamkeit zukommen lassen möchtest :)

ed2k-gtk-gui project home page - ed2k-tools - scentric