Hmm, das Mulie läuft bei mir noch immer mit festen Ports. Bislang getestete Implementationen (Emulespana?) machten beim IP-Wechsel / Zwangstrennung kruke. Bei Azureus und µtorrent hatte ich nie Probleme mit UPNP am Sinus 154 Basic 3.
Beim Feedback Offi / Xman / Morph -> geht, geht nicht, ist es wohl auch wichtig zu posten welcher Router angesprochen wird. Solange den Programmierern nicht bekannt ist, welche Routereigenarten den Griff zu UPNP zum Würfelspiel machen, werden sie auch keine Lösung finden, die mit 99% der existierenden Router arbeitet. Genau DIE ist aber wichtig, zumindest für Leute, die öfter mal die Mod wechseln. Die universell funktionierende Lösung muß im Offi landen, egal, wer sie programmiert hat. Nur dann kommt auch der Ober DAU in den Genuß der High ID und des offenen Server UDP Ports.
Wozu sollte ich die Portweiterleitung auf Automatik umstellen, solange die Automatik nur mit wenigen Mods funktioniert?
Wie soll ein Programmierer seinen Code optimieren, wenn er nur gemeldet bekommt: "... funktioniert bei mir nicht ... " . Funktioniert mit .... , funktioniert nicht mit .... , Low ID immer, Low ID nach Neueinwahl, Hänger beim Schließen des eMule (frühe eMuleespana Implementation), das sind die Dinge, die die Leute, die es testen, hier posten sollten.
Eine saubere Implementation im Offi fände ich super, da ich damit beim Schließen des eMule automatisch auch die Portweiterleitung im Router beenden würde, obwohl es wahrscheinlich egal ist, ob da noch Pakete weitergeleitet werden, da ja der Pc hinter dem Router, wenn das Mulie nicht läuft, die Ports als geschlossen zurückmeldet.
Nur, wie soll ich mir erklären, warum das bei Bittorrent Klienten und anderen Applikationen schon längst läuft, während beim eMule noch immer dran gebastelt wird?
greetz
... Cat ...