Du reagierst in deiner Client Thread Methode auf solche ungewollten Trennungen. Dh. im Fall von
Indy fängst du diese Exceptions ab und startest nach einem Test ob die Verbindung wiederherstellbar ist entweder einen neuen Client Thread oder setzt den aktuellen fort.
Dein Problem ist im Grunde ein Sessionbasiertes Problem, vollkommen losgelöst von den Client Thread Methoden. Du solltest also die Threadmethode eines "Clients" als eine
TCP/
IP Connection betrachten und NICHT als ein CLIENT !!
Ein Client ist ein Benutzer/Software und damit eine Session. Eine Session kann mehrere Verbindungen aufbauen, auf mehreren Ports zur verschiedenen IPs etc.pp. Du musst also einen eigenen Überbau (zb. Objekte) schaffen in denen die übergreifenden Variablen/Staties etc.pp. verwaltet werden. In dieser Client-Session werden dann auch die verschiednenen Clientthreads zu einzelnen Verbindungen abgespaltet.
Eine solche Session ist es auch die ein keepalive sendet, also dein besagtes NOOP. Das ist aber im Grunde überflüssig da das Socket Konzept von vornherein es vorsieht das der Programmierer eines Sockets darüber informiert wird das die Verbindung unterbrochen wurde.
Ergo: dein eigentliches Problem ist ein konzeptionelles oder ein Verständnisproblem was ein CLIENT im Sinne INDYs ist und was ein CLIENT in deinem Sinne darstellt.
Du kannst also ein Client als Session Objekt programmieren und dazu viele verschiedene TidTCPClient handler Methoden. Diese Methoden, bzw. threadbasierte Connections können je nach deren Aufgabe ganz differenziert auf eine Funktion zugeschnitten sein. Zb. spaltet die Client Session auf Befehl des Servers eine spezielle TcipClient Methode ab die dann einen Dateidownload durchführt. Eine andere Conection dient wie zb. beim
FTP als Kommandokanal.
Es gibt nun ein statisches und ein lebendes Session Management. Statisch bedeutet: Client baut zum Server Verbindung auf, fragt par Daten ab und danach trennt er die Verbindung. Ideales Beispiel für zb. eine Daten Synchronisation, ein Installationstool etc.pp.
Oder es gibt lebendige Sessions. Diese leben die ganze Zeit lang wie es der Benutzer wünscht. Er verbindet einmalig zu einem Server und trennt auch manuell zu einem späteren Zeitpunkt. Die ganze Zeit dazwischen lebt die Session aber es werden je nach Aktion neue Connections aufgebaut, Daten übertragen und diese Connections wieder geschlossen.
Alles andere macht keinen Sinn. Also die
INDY TcipClient Connections für so ein Session basiertes System zu benutzen ist unsinnig und kostet Zeit und Resourcen. Ich meine damit das man in EINE TcipClient Methode ALLES was eine Session können muß reinprogrammieren möchte, das geht nicht.
Eine
TCP/
IP Connection sollte immer "linear sequientiell" aufgebaut sein. Connection erzeugen und öffnen, danach auf Daten warten oder senden, und danach sofort wieder terminieren. Das ist es wie ich es handhabe und damit habe ich die besten Erfahrungen gemacht. Fehler wie "Verbindungsaufbau weil der Server nicht erreichbar ist" werden damit schon im vorhinein beim Connecten eines TCPIPClients abgefangen und nicht innerhalb einer Thread Methode.
Denn bei jeder lebendigen Session tritt das Problem für den Programmierer auf die Daten und Aktion Threadübergreifen synchronisieren zu müssen. Das ist ein schwieriges Problem besonders im Hinblick darauf das die
VCL dazwischen hängt, das
GUI auch nch gefüttert werden muß und wir als Programmierer NIE wissen können was nun threadsafe oder unsafe ist (also synchronisert werden muß).
Gruß Hagen