JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #1  
Old 05.06.2010, 00:55
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default Wieso bremst JD mit Absicht Reconnects mit externem oder gar keinem IP Check aus?

Selbst wenn man es mit eigener Batchfile lösen möchte, wird man einfach per "JD Zwang" aus gebremst.

Interner Check -> 8Sek für den kompletten Reconnect
Externen Check -> 23Sek!
Ohne Check -> 35 Sek!


Wieso darf man den Zeitabstand der externen IP Überprüfung nicht unter 10 Sekunden drücken?

Wieso darf man die Wartezeit bis zur IP Überprüfung nicht unter 5 Sekunden stellen und wieso wird "Auf neue IP Warten" auf min 30Sekunden festgelegt?

Es ist dem User somit nicht erlaubt die Werte an seine Konfiguration anzupassen und man wird quasi dazu gegängelt den internen IP Check zu nutzen, denn nur dann läuft es schnell.

Einen Sinn dahinter kann ich irgendwie nicht wirklich erkennen und ich würde mich freuen wenn ihr das beim nächsten Update überarbeitet, so das der User einstellen kann, was er für richtig hält.

Loggt ihr die IPs der "Reconnecter" eigentlich?

Last edited by Jiaz; 18.08.2010 at 13:29.
Reply With Quote
  #2  
Old 05.06.2010, 03:05
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Wenn wir schon am Fragen sind - wo lädt der JD beim Installieren die JRE herunter? Die Version ist nämlich "alt" und hat bekannte Sicherheitslücken.

Und wie kann man den Log leeren?

Last edited by buggsy; 05.06.2010 at 07:03.
Reply With Quote
  #3  
Old 11.06.2010, 04:41
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Mich würde das auch mal interessieren!
Reply With Quote
  #4  
Old 11.06.2010, 16:38
eisbaer's Avatar
eisbaer eisbaer is offline
Ehrenmitglied
 
Join Date: Mar 2009
Posts: 3,588
Default

Quote:
Und wie kann man den Log leeren?
in dem man den JD schliesst.
was heisst alt?
ich besorg mir java immer zuerst, bevor ich mir ein
java programm installiere.
vermutlich wird eine alte version genommen, weil
viele benutzer probleme haben, mit der neuesten java + JD
Reply With Quote
  #5  
Old 11.06.2010, 16:45
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Bei mir wird der Log nach schließen nicht geleert. Vorführeffekt, nun scheints zu klappen.

Das JRE, welches installiert wird, zaubert in _alle_ Browser ne Sicherheitslücke für nen driveby Angriff. Das ist "ein wenig" ähm unpassend.
Daher auch die Frage von wo diese alte JRE (17) gezogen wird.

Bleibt noch die Frage mit dem reconnect. Das nervt nämlich tierisch, da ich per batch vor/nach dem reconnect noch andere Tasks ausführen lasse und dank der dämlichen "Zeitzwänge" im JD der Reconnect nun ewig dauert.
Reply With Quote
  #6  
Old 13.06.2010, 15:44
deinemudder
Guest
 
Posts: n/a
Default

der ip check is für die meisten leute völlig nutzlos.

ich hatte hier auf jeden fall schon mal so lange rumgenervt bis eine möglichkeit eingebaut wurde den ip check abzuschalten.

das wurde dann aber irgendwann wieder rausgenommen, warum auch immer.

schliesse mich deiner ansicht auf jeden fall an. insbesondere der "timeout" mit min 30 sec nervt wie ein 2tes arschloch.
Reply With Quote
  #7  
Old 17.06.2010, 01:23
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Ein zweites A.l. wäre sinnvoller ...:whistling:

Kommt einem fast wie eine Gängelung zum Haus eigenen IP Check vor, wobei sich natürlich die Frage stellt, was das Team von Jdownloader davon hat. Werden die Reconnect IPs geloggt?

Ist doch alles intransparent gehalten. Der Spaß wird ja auch mit externem IP Check ausgebremst, was schlicht weg überflüssig ist, wie ein Kropf!
Reply With Quote
  #8  
Old 17.06.2010, 09:07
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 61,796
Default

Wenn ich das schon wieder lese...also mal von vorne:

1.) Auf IP-Warten:
Das ist keine MINIMUM, sondern eine MAXIMALE ZEIT die jd wartet, bis es feststellt, das der Reconnect fehlgeschlagen ist. diese zeit kann auch 100 sekunden sein und dennoch wird der reconnect nach >=5 sekunden erkannt und weiter gehts. Fazit: je nachdem wie lange der reconnect dauert sollte dieser wert höher sein, ein minimum von 30 sekunden tut nicht weh
2.) Ohne Check: jd macht hierbei keinerlei ip check mehr und wartet deshalb die komplett eingestellte zeit ab. dies haben wir so gemacht da es letztendlich keinerlei möglichkeit mehr gibt rauszufinden ob der reconnect wirklich korrekt eingestellt ist. falsch eingestellter reconnect und sehr kleine wartezeit = super ddos
3.) Zeit zur erste IP Check: nachdem das recnnect file ausgeführt wurde, wird diese initial wartezeit gewartet und dann mit dem ipcheck alle 5 sekunden durchgeführt. alle 5 sekunden weil das ein guter wert ist und die ipcheck server auch überleben sollen (nicht ohne grund müssten wir von anfangs dyndns, über freie ipchecks letztendlich 3 eigene ipcheck server aufstellen!)
4.) Settings-download&connection-advanced- disable ip check: voila--alle ip checks deaktiviert, genau das was man will!?
5.) willst du eigene ipcheck nutzen, dann schalte einfach *use balanced ip check* ab..und dann kannst selbst nen server angeben. niemand ist gezwungen unsre ip check server zu nehmen.
6.) externer ip check = user hat autoreconnect abgeschalten. jd wartet nun zb 60 mins..warum sollte er diese 60 mins warten, wenn in der zwischenzeit evtl ein zwangsreconnect oder sonstiger durchgeführt wurde , dafür der externe reconnect!

mfg
jiaz
__________________
JD-Dev & Server-Admin
Reply With Quote
  #9  
Old 17.06.2010, 09:09
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 61,796
Default

Quote:
Originally Posted by deinemudder View Post
der ip check is für die meisten leute völlig nutzlos.

schliesse mich deiner ansicht auf jeden fall an. insbesondere der "timeout" mit min 30 sec nervt wie ein 2tes arschloch.
1.) wenn die leute den autoreconnect nicht aktiviert haben, bekommen sie vom ipcheck gar nix mit , wo dann das problem?
2.) timeout von 30 sekunden tut nicht weh. und wenn der timeout erreicht ist, ist da ein zeichen von falsch eingestelltem reconnect
__________________
JD-Dev & Server-Admin
Reply With Quote
  #10  
Old 17.06.2010, 09:10
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 61,796
Default

da ich nicht weiss was deine batch file macht ,kann ich wenig zur zeit unterschied sagen
__________________
JD-Dev & Server-Admin
Reply With Quote
  #11  
Old 17.06.2010, 19:29
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Selten soviel Ignoranz in einem Post gesehen und dann noch als solved markieren.

30 Sekunden tun nicht weh? Sie nerven tierisch und sind technisch absolut überflüssig. Es ist eine reine Gängelung durch euch.

Zu 2:

DDoS auf wen den bitte? Den eigenen Router? Und das hat euch nun inwiefern zu interessieren? Bei anderen OHK Tools stellt das seit zig Jahren kein Problem dar! Haltet ihr eure User für zu blöd um zu testen wie niedrig die Zeit sein darf und schreibt es Ihnen daher einfach vor? Scheinbar ...

Zu 3:

Ein guter Wert ist es sicherlich nicht. Es ist nur einer, der wahrscheinlich überall funktioniert und dem User jegliche Freiheit zur Optimierung nimmt!

Der externe IP Check ist ja sogar auf 10 Sekunden festgelegt - Anpassung durch den User, wenn er z.B. nen eigenen Dienst betreibt, mal wieder nicht erlaubt.


Zu 4:

Siehe Post 1 dieses Threads.


Aber noch einmal, klar verständlich:

Interner Check -> 8Sek für den kompletten Reconnect
Externen Check -> 23Sek!
Ohne Check -> 35 Sek!

Bei gleicher Batchfile / Reconnect Methode über UPnP. Nun erkläre mir bitte den technischen Grund dafür und wieso du dich so verdammt stur stellst, das als "nervig" zu akzeptieren.

Ich hätte gerne einen reconnect in 8 Sekunden ohne IP Check und wenn ich die Zeiten selbst festlegen dürfte, wäre das auch absolut kein Problem. Bei anderen OHK Tools ist das seit Jahren die Regeln.
Wenn ein Router mal etwas länger brauchte, löste man das einfach mit einem "ping IP -n X" oder mittels sleep.

Es ist schön das man es bei euch Programm intern lösen kann, aber verdammt traurig das jeder der etwas eigenes nutzen möchte von euch ausgebremst wird um bis zu 437%! Aber stimmt, ist ja nicht viel ...

Bei euch darf man den reconnect einfach nicht an die persönlichen Bedürfnisse anpassen und wird GEZWUNGEN einen kacklahmen reconnect zu akzeptieren, sofern man nicht eure IP Check Server nutzen möchte!

Das ist es, was hier kritisiert wird. Das Thema einfach als "solved" zu markieren, zeigt ja, wie ihr drauf seid.:outch:
Reply With Quote
  #12  
Old 17.06.2010, 19:29
deinemudder
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by Jiaz View Post
1.) wenn die leute den autoreconnect nicht aktiviert haben, bekommen sie vom ipcheck gar nix mit , wo dann das problem?
2.) timeout von 30 sekunden tut nicht weh. und wenn der timeout erreicht ist, ist da ein zeichen von falsch eingestelltem reconnect

Hi Jiaz... alles frisch?

hab da mal ne frage:

Quote:
Originally Posted by Jiaz View Post
2.) Ohne Check: jd macht hierbei keinerlei ip check mehr und wartet deshalb die komplett eingestellte zeit ab. dies haben wir so gemacht da es letztendlich keinerlei möglichkeit mehr gibt rauszufinden ob der reconnect wirklich korrekt eingestellt ist. falsch eingestellter reconnect und sehr kleine wartezeit = super ddos
wenn ich korrekt informiert bin ist die möglichkeit dies herauszufinden die antwort der seite des filehosters selbst.
z.b. bei netload, wenn die wartezeit länger als 19 sec ist (bzw. eine andere seite als die 19sec seite angezeigt wird) dann wird automatisch ein reconnect gemacht. oder habe ich da was falsch verstanden?

dehalb ist es auch sinnvoll die ip prüfung abzustellen, weil wie oft bekommt man denn in germany bei provider x die selbe ip nacheinander...? meine erfahrung, ehr selten.

nehmen wir an es ist trotzdem der fall, dann würde netload sagen: "digger du kommst hier nisch rein!" und ein reconnect würde ausgeführt werden UND dies alles ohne das jd irgendwas von der ip mitbekommt.
hab ich das richtig verstanden oder peil ich hier was garnicht?

anmerkung:

Quote:
Originally Posted by Jiaz View Post
2.) timeout von 30 sekunden tut nicht weh. und wenn der timeout erreicht ist, ist da ein zeichen von falsch eingestelltem reconnect
ich füge mich natürlich deiner 30sec entscheidung da diese entscheidung dir gebührt. weh tut sie trotzdem!

Quote:
Originally Posted by Jiaz View Post
Das ist keine MINIMUM, sondern eine MAXIMALE ZEIT die jd wartet, bis es feststellt, das der Reconnect fehlgeschlagen ist. diese zeit kann auch 100 sekunden sein und dennoch wird der reconnect nach >=5 sekunden erkannt und weiter gehts. Fazit: je nachdem wie lange der reconnect dauert sollte dieser wert höher sein, ein minimum von 30 sekunden tut nicht weh
die nummer mit minimum und maximum is ne tellerandproblematik. stellen wir uns einfach vor ich bin auf der anderen seite der mauer.

für einen funzenden reconnect is das natürlich ein MAXIMUM, keine frage.

für einen vergrüzten reconnect ist das jedoch durchaus ein MINIMUM.

bei mir ist es so das der reconnect ständig vergrüzt OBWOHL ich ihn korrekt eingestellt habe. dafür kann jd NICHTS (um das mal ganz klar zu sagen).

recons vergrüzen bei mir vermutlich weil ich doppelte einwahl benutze und mein HVT tagsüber recht hohe last hat. meine pppoe besteht dann zwar (verbindung hergestellt), allerdings "nur auf dem papier". ein http verbindung kann nicht aufgebaut werden. (über die umstände die zu diesem phänomen führen werd ich mich jetzt mal nich auskotzen).

ich würde vom JD team niemals verlange den JD für völlig abnorme randgruppenkonfigurationen wie meine anzupassen, der punkt ist das buggsy (ich spreche jetzt einfach mal für uns beide) und ich nicht rumnerven weil wir hier nix raffen oder dussel sind sondern weil wir genau diese DDOS option haben wollen.

ich habe kein problem mit dem jd, oder meinem reconnect, ich habe ein problem mit meinem provider welches ich durch das anpassen dieser option entschärfen könnte. nicht mehr und nicht weniger.

wenn du mir (uns) diese DDOS WAFFE nicht in die hand geben möchtest weil du angst hast das ich meinen provider damit erschiesse... so sei es.

für manche ist das maximum ebend ein minimum.


edit: uiuiuiuiuiui buggsy da warste wohl schneller ruhig blut brauner!

Last edited by deinemudder; 17.06.2010 at 19:32.
Reply With Quote
  #13  
Old 17.06.2010, 19:37
coalado's Avatar
coalado coalado is offline
JD Manager
 
Join Date: Feb 2009
Posts: 1,981
Default Hallo

Hi.

Ich brauche das Thema hier nur zu überfliegen, und weiß schon dass ich mir den ganzen Mist den ihr euch hier gegenseitig an den Kopf werft nicht durchlesen werde.

Ich weiß dass Jiaz sich gerne mal etwas zu kompliziert ausdrückt. Das ist kein Grund für euch unfreundlich zu werden.

Vielleicht wäre mal einer von euch so nett und fasst eure Fragen und Probleme kurz zusammen. Dann werd ich schauen was ich tun kann...

PS.: Ich werde hier ganz sachlich bleiben. Aber der nächste beleidigende Kommentar kriegt einen Bann. Also reißt euch bitte auch etwas zusammen.
Grüße, Coa
__________________

Last edited by coalado; 17.06.2010 at 19:39.
Reply With Quote
  #14  
Old 17.06.2010, 19:44
deinemudder
Guest
 
Posts: n/a
Default

hi coalado... alles gut?

ich beleidige nie jemanden. aber soweit hast du sicher nicht gelesen, verstehe ich auch.

kurz, was ich möchte sind die 30sec reduzieren.

warum ich das möchte steht in meinem post.

bis denne erstmal...
Reply With Quote
  #15  
Old 17.06.2010, 20:09
coalado's Avatar
coalado coalado is offline
JD Manager
 
Join Date: Feb 2009
Posts: 1,981
Default

Warum schränken wir unsere Nutzer so ein?
Tatsächlich ist es so, dass wir (bzw unsere User) schon einige Hoster down bekommen haben wegen zu vielen Requests. (Wie das passieren könnte erklär ich gerne im Chat, weil das hier nichts zur Sache tut) .
Wichtig ist nur: Wir müssen tatsächlich sehr aufpassen was wir da tun, sonst gibt es Ärger.

Um einen IP Wechsel festzustellen zu können, machen wir deshalb IP Checks über eigens dafür geschriebene Lighty Plugins. Das entlastet die Hoster. Die Grenzen für die Einstellungen müssen so gewählt sein, dass das Ergebnis selbst im schlimmsten Falle nicht gefährlich für irgendwelche Dienste wird.


IP Check abschalten:
Schaltet man den IP Check ab, (Was in der Nightly tatsächlich nicht mehr geht...keine Angst..ist nur ein bug), wälzt man das validieren des Reconnects auf den Hoster ab. Wenn das ein paar User machen, ist das kein Problem. Wenn es viele machen, dann schon. Deshalb gibt es in diesem Fall den 30(35) Sekunden Timeout. Für Nutzer die einen Reconnect haben der immer geht, ist das tatsächlich scheiße.

Wie können wir den IP-Check über unserer Server umgehen, und trotzdem schnell sein?

1. Fake IP check
In den Netzwerkoptionen, kann man einen den IP Check von unseren Servern auf irgendeinen anderen umschalten. (Balanced IP check aus). Man könnte dort einen eigenen Dienst eintragen der immer eine Fake IP zurückgibt, oder einen richtigen IP Check eures Vertrauens verwenden.

2. Unser IP Check System umstellen.
Tatsächlich weiß der Hoster immer noch am besten ob die neue IP was taugt. So könnten wir den Hoster einen erfolgreichen wechsel validieren lassen. (ohne Wartezeit). Falls das fehlschlägt muss erneut ein Reconnect (jetzt mit Wartezeit) gemacht werden. Der erste "Hoster-ip-check" ist dann instant, und erst bei Fehlschlägen summiert sich die Wartezeit auf.
Das würde in den meisten fällen eine möglichst kurze Wartezeit ermöglichen, und dennoch DDOS ähnliche Zustände vermeiden.

Das ganze wäre aber mit einiger Arbeit am Reconnect und PluginControlling verbunden. Das können wir frühstens zum nächsten Kern Update einbauen.


Was haltet ihr davon? Bessere Ideen?
__________________
Reply With Quote
  #16  
Old 17.06.2010, 23:41
deinemudder
Guest
 
Posts: n/a
Default

schön zu sehen wenn andere über die selben sachen nachdenken...

*freu*

tatsächlich glaube ich das aus der sache "reconnect" nur noch wenig rauszuholen ist.

wenn man sich den gesamtkontext der thematik mit seiner auswirkung auch auf 3te vor augen hält stellt man schnell fest das die aktuelle vorgehensweise wenig raum für optimierung lässt, will man das gesamtsystem nicht beschädigen.

hätte ich nicht diesen spezifischen bug würde ich zu der idealgruppe der pppoe reconnect user (recon <= 5sec) gehören.

was mir nicht ganz klargeworden ist in deinem posting ist folgender teil:

wo ist der unterschied zwischen:

Quote:
Originally Posted by coalado View Post

Warum schränken wir unsere Nutzer so ein?
Tatsächlich ist es so, dass wir (bzw unsere User) schon einige Hoster down bekommen haben wegen zu vielen Requests.
...
und

Quote:
Originally Posted by coalado View Post

...
2. Unser IP Check System umstellen.
...
So könnten wir den Hoster einen erfolgreichen wechsel validieren lassen. (ohne Wartezeit). Falls das fehlschlägt muss erneut ein Reconnect (jetzt mit

Wartezeit) gemacht werden. Der erste "Hoster-ip-check" ist dann instant [anm muddi: ????], und erst bei Fehlschlägen summiert sich die Wartezeit auf.
Das würde in den meisten fällen eine möglichst kurze Wartezeit ermöglichen, und dennoch DDOS ähnliche Zustände vermeiden.
...
?

ist diese vorgehensweise im punkt "2." nicht genau die die es zu vermeiden gilt?

oder habe ich den unterschied nicht verstanden?

warum ist option A ddos und option B nicht?

ich bin jederzeit bereit hier sämtliche verhaltensdiagramme des reconnect aufzuzeichnen (wie sie sich in meinem jd darstellen) und oute mich an dieser stelle als jemand der seinen reconnect krankhaft genau verfolgt (lächerlich genau geradezu).

letztlich läuft es immer darauf hinaus das der schutz des systems (der schutz der seite) priorität hat. wenn das system beschädigt wird ist die software nutzlos weil es irgendwann kein system mehr gibt.

vor diesem hintergrund ist es insbesondere fraglich ob man diese option (optionen) zugänglich macht. macht man sie einem zugänglich macht man sie allen zugänglich.

mein funktionierender pppoe reconnect mit ip check dauert weniger als 6sec. davon sind 5sec wartezeit im script um das statistische auftreten meines bugs zu minimieren. dh. ein "idealer reconnect" würde bei mir weniger als eine sekunde dauern (ich empfinde das nicht als luxus aber ich glaube ich nehme das blos nicht wahr).

um auf mein problem nochmal kurz zurückzukommen...

da bei einem vergrüzten ip check meine ip nicht "messbar" ist, ist für mich "pppoe reconnect mit ip check" das selbe wie "pppoe reconnect ohne ip check", 30sec langen.

durch das drehen an den "30sec" würde ich mich quasi an den "idealen reconnect" "herancheaten".

die wahrscheinlichkeit das ich die seite damit mehr unter last setzen würde ist sehr gering da die wahrscheinlichkeit die gleiche ip zu bekommen sehr gering ist und ich somit die seite nicht "zur entscheidung zwinge" (die last).

realistisch betrachtet steigert sich die last der seite natürlich (an dieser stelle ist das glaube ich kein lineares problem mehr) in relation zum herabsetzen der 30sec (bei der masse der user).

große anbieter sind hier sicherlich auch weniger betroffen als kleine.

eine system zur kompensation durch differenzierung der hoster würde hier unendlich komplex werden. selbst mir als anwender ist klar das dass kein zu beherrschender ansatz wäre.


fazit:

am funktionierenden pppoe reconnect mit ip check ist meiner meinung nach nichts zu optimieren. so oder so muss ich die ip checken lassen um sicherzustellen ob sie sich unterscheidet und so oder so muss ich die seite feststellen lassen ob die ip jemand anderes im "kritischen zeitfenster" schon mal hatte.

für leute deren pppoe reconnect einwandfrei läuft (mit höherer latenz) ist die 30sec option eine gefährliche waffe.


ich denke im zweifel: SCHÜTZ DAS SYSTEM.

als anwender mit einhergehender "will ich haben mentalität" frage ich mich ob es nicht möglich wäre bei deaktiviertem ip check die zeit von 30sec auf 5sec minimieren zu können.

habe ich eine optimierung übersehen/falsch verstanden?
Reply With Quote
  #17  
Old 18.06.2010, 02:04
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Hallo coalado,

mir geht es um folgendes - Beispiel:

Nehmen wir z.B. eine x beliebige Fritzbox, die man über UPnP (per Netcat) reconnect und zugleich noch Trillkey nutzen möchte, um Trillian ab/anzumelden, damit keine Nachrichten verloren gehen.

Also ganz simpel:

Code:
"C:\Program Files\TrillKey\trillkey.exe" disconnect
type data.box | nc -w 1 fritz.box 49000 >nul
"C:\Program Files\TrillKey\trillkey.exe" reconnect
Bei ner FB braucht man nicht einmal eine Wartezeit zwischen dis/reconnect, da die Box das sehr flott erledigt. Bei einem W700V sieht das wieder anders aus (~6-8sec).

Das Problem ist nun, dass das bei Jdownloader die reconnect Dauer auf 35 Sekunden hoch drückt, da die kompletten Mindestwerte abgewartet werden, bevor ein Verbindungsversuch zum Hoster statt findet.

Die von dir angesprochene Problematik mit den Hosteranfragen sollte doch nur auftreten, wenn der User einen falschen reconnect einstellt und das am Fließband (ohne Pause dazwischen) läuft oder sehe ich das falsch? Bei anderen Tools habe ich bisher noch nicht von Problemen gehört.:confused:

Also quasi Script / keine neue IP / Anfrage an Hoster / Script / keine neue IP / Anfrage an Hoster ...

Mit korrekten reconnect script würde es doch wie folgt laufen:

Reconnect - Leitung kurz tot, anfragen laufen ins Leere bzw. nur an den Router - Leitung wieder da & DL wird aufgenommen

Dauerhafte Anfragen also nur bei fehlerhaften reconnect seitens des Users - wie wäre es also mit einer Art Experteneinstellung im JD, die man erst freischalten müsste? Man könnte das ganze ja etwas verstecken und deutlich auf die Problematik hinweisen. Die meisten User würden das eh nicht antasten, da diese sicherlich den internen IP Check nutzen wollen und werden.

Oder aber man könnte die Option erst nach vorherigem erfolgreichem Test des reconnects mit IP Check freischalten.

Ich benötige schlicht weg keinen IP Check und möchte eine eigene Batchfile nutzen, was aktuell nur mir starken Einschränkungen möglich ist - leider.

Wenn ich nun die Wartezeiten selbst aktiv beeinflussen könnte, sei es nun selbst per Batch oder über die im JD gebotenen Optionen, könnte ich auch mit Batch einen reconnec in wenigen Sekunden erledigen, trotz einiger weiterer Aufgaben im Script.

Ich empfinde es nun einmal als sehr störend, wenn das aufgrund von Beschränkungen nicht möglich ist. Wäre der Zeitaufschlag nun gering, also nur wenige Sekunden höher, wäre das zu verschmerzen, aber wenn der reconnect dann mehr als 4x so lange dauert ...


@deinemudder:

Der Tag heute war nicht meiner, daher wohl die etwas rabiate Art. Aber beleidigend war hier nach wie vor niemand.

Last edited by buggsy; 18.06.2010 at 02:07.
Reply With Quote
  #18  
Old 18.06.2010, 09:51
coalado's Avatar
coalado coalado is offline
JD Manager
 
Join Date: Feb 2009
Posts: 1,981
Default

@buggsy:
Der unterschied von uns zu anderen Loadern ist, dass wir ungleich mehr user haben. Wenn davon nur ein Bruchteil dieses "reconnect-failed->hoster->reconnect->failed->hoster" spiel machen, dann haben vor allem die großen Hoster ein dickes Problem.

Experteneinstellungen sind leider nicht gut, weil ich aus Erfahrung sagen kann, dass sich viel zu viele Leute für Experten halten die keine sind ;-P

Möglich wäre das setzen dieser Option über die Kommandozeile. Da kann man davon ausgehen dass es niemand zufällig macht, weil die Option in den Settings so gut klingt ;-P

Zu den 5 Sekunden die du ansprichst:
Das ist jetzt kein Hoster Schutz, sondern ein Schutz unseres eigenen IP Check Systems. Ich denke dass wir da ganz stabil laufen und diese 5 Sekunden runternehmen können.

@deinemudder:

Probleme gibt es, wenn der user einen nicht funktionierenden Reconnect nutzt, und IP check abschaltet.
Dann geht das rc->hoster->rc->hoster->rc->hoster ..usw.

Hier gibt es die 30 sekunden die da schlimmeres verhindern
rc->30sekunden->hoster->rc->30sekunden >hoster ..usw

Meine Idee war es diese wartezeit zu staffeln. Dann läuft es im schlimmsten Falle so:

rc->0sec->hoster->rc->15sec->hoster->rc->30sec->hoster->rc->45sec->hoster usw.
__________________
Reply With Quote
  #19  
Old 18.06.2010, 18:20
deinemudder
Guest
 
Posts: n/a
Default

Quote:
Originally Posted by coalado View Post
...
@deinemudder:

Probleme gibt es, wenn der user einen nicht funktionierenden Reconnect nutzt, und IP check abschaltet.
Dann geht das rc->hoster->rc->hoster->rc->hoster ..usw.

Hier gibt es die 30 sekunden die da schlimmeres verhindern
rc->30sekunden->hoster->rc->30sekunden >hoster ..usw

Meine Idee war es diese wartezeit zu staffeln. Dann läuft es im schlimmsten Falle so:

rc->0sec->hoster->rc->15sec->hoster->rc->30sec->hoster->rc->45sec->hoster usw.
joa, find ich ne absolut geile maßnahme.

ich wäre natürlich ehr für: rc 0 rc 5 rc 10 rc 15 rc 20 rc 25 rc 30 rc 30 rc 30...

ich bin auf jeden fall für jede änderung dankbar die das recon system effizienter gestaltet weil das automatisch meinen bug minimiert.

letztlich is das hier heueln auf hohem niveau weil ich zu 70% - 80% der zeit einen reconnect habe der schneller sein dürfte als der von min 80% aller JD user.

bei genauerer betrachtung wäre es vermutlich sogar sinnvoller (für mich allemal) sowas hier zu machen:

rc 0 rc 0 rc 0 rc 15 rc 30 rc 30 rc 30...

zumal es sicherlich auch sinnvoll wäre ein definiertes MAXIMUM für reconnects (Max Repeats) zu erzwingen WENN der ip check disabled ist!

"rc 0 rc 0 rc 0" löst MEIN problem zu ca. 98%, ein MAXIMUM für reconns bei disabled ip check löst DEIN problem zu ebenfalls ca. 98%!

sagen wir du legst ein MAXIMUM für 20 oder 30 reconns fest (durch den user nicht zu justieren) dann lässt sich die maximale flood anhand der userbase von jd sowie in relation geschätzten falsch konfigurierten reconnects recht gut abschätzen.

anhand dieses modells wäre ein sinnvolles MAXIMUM dann festlegbar und der schutz der hoster gewährleistet.

meinungen?

edit:

bei erreichtem MAXIMUM der reconns ohne ip check bietet sich natürlich sowas an wie: "eh du affe, krich mal dein reconnect in griff!".

alternativ könnte ich mir auch vorstellen nach erreichen des MAXIMUMS ein aktivieren des ip check zu erzwingen um den hoster zu schützen während die downloads gleichzeitig nicht völlig abgebrochen werden.

Last edited by deinemudder; 18.06.2010 at 18:27.
Reply With Quote
  #20  
Old 18.06.2010, 23:57
buggsy buggsy is offline
BugMeNot Account
 
Join Date: Mar 2009
Location: everywhere/nowhere
Posts: 1,095
Default

Anpassung über Kommandozeile fände ich super. Die Leute die es wirklich brauchen, würden es in der Hilfe bzw. hier im Forum dann finden und die, die nicht wissen was sie tun, würden es nicht nutzen.

Wäre klasse wenn man die Beschränkungen darüber aufheben könnte!

Vielleicht auch eine Kombination aus beidem. Staffeln für normale User, die trotzdem optimieren wollen und per Kommandozeile komplett deaktivieren, für die Leute, die wissen was sie tun (wollen). Das wäre eine gesunde Mischung aus Schutzsystem, manuellen Einstellungsmöglichkeiten von Werk und vollständiger Kontrolle für "Experten".

Danke im Übrigen das du auch für solch kleine Probleme ein offenes Ohr hast.

@deinmudder:

Ja, das ist wirklich meckern auf hohem Niveau, aber was man gewohnt ist, will man nicht mehr missen, nicht wahr? *g*

Wenn man selbständig optimieren könnte, könnte man den kompletten reconnect mit 2-3 extra Aufgaben auf 1-3 Sekunden drücken (je nach Router natürlich).

Das ist schon ein gewaltiger Unterschied zu den aktuellen 35 Sekunden.

Last edited by buggsy; 19.06.2010 at 00:01.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 09:18.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.