Hi,
Zitat von
Svenkan:
Socket-Fehler # 10054
Die Verbindung wurde von Peer zurückgesetzt.
Gut. Wir nehmen mal an, der Socket wurde von der Serverseite getrennt. Dies bedeutet z.B. ein Connection-Timeout wegen zu langer Inaktivität.
Du solltest
Indy mal auf einen aktuelleren Stand bringen, 9 ist schon arg alt. Die neueren, z.B. 10.2.3 haben hier viele Designverbesserungen und Bugfixes.
Das Problem ist aber grundsätzlich, daß hier eine Verbindung nach dem Socket-Fehler #10054 nicht mehr hergestellt werden kann.
Zitat von
Svenkan:
Dein Lösungsvorschlag ist gerade völlig neu für mich, klingt aber vielversprechend. Könntest du mir dazu genaueres sagen?
Na klar, wobei Grundlagenwissen über Timer, Threads und Events nötig ist.
Der Ablauf ist grob z.B. folgender:
- TTimer auf dem Form (Intervall z.B. auf 5000 msec, aktiviert)
- Timer prüft, ob er gerade ausgeführt wird, um Mehrfachausführung zu verhindern
- Timer prüft, ob ein Verbindungsversuch mit den Zugangsdaten zu diesem Server gerade läuft (z.B. per Hash der Daten und einer TObjectList), damit er den Server nicht unnötig mehrfach "belästigt" - dies führt ja auch manchmal zu Firewall Rejects
- Timer erzeugt dann ggf. ein ThreadJob für einen WorkerThread (such mal hier im Forum, da gibt es eine einfache Komponente und Beispiele für, heißt csWorkerThread). Aber bitte nicht 500 Threads gleichzeitig
- Im Workerthread erzeugst Du ein lokales Threadobjekt von TIdFTP, TIdHTTP, TIdSSLOpenSSLSocketHandler oder watt-auch-immer
- Der Thread gibt über synchronized Callbacks (bzw. bei csWorkerThread mit OnThreadException und OnThreadFinished meine ich) seine Results zurück an irgendeinen Callbackhandler bzw. Methodenprozedur
Das ganze programmiertechnisch umzusetzen ist relativ einfach - aber tricky. Du mußt schon die Thematik verstanden haben.
In einfachen Worten: Du erzeugst lokale
Indy-Objektinstanzen pro Thread und gibst diese am Threadende frei. So hast Du immer saubere, jungfräuliche Objektinstanzen.
Das erhöht die Stabilität schon ungemein.
Gruß Assertor