Zitat:
Theoretisch kann man mit einer Instanz der TidTCPClient Komponente zwar gleichzeitig senden und empfangen (lt.
Indy Entwickler Remy Lebau kann man über einen Thread IOHandler.Read und aus einem anderen IOHandler.Write aufrufen).
Hm. Genau das mache ich ja. Wenn das laut Remy geht, dann sollte doch mein Testprogramm kein Problem darstellen. Solange ich das (reale) Programm nicht beende, kann ich stundenlang mit dem Server Daten austauschen, das Problem entsteht wirklich erst dann, wenn ich disconnecte, und eben auch nur, wenn SSL im Spiel ist. Ich meine mich zu erinnern, daß ich ohne SSL den Fehler auch reproduzieren kann, wenn ich nach dem Disconnect und dem erfolgreichen Abbruch des Read ein weiteres Mal TCPClient.Read.. aufrufe.
Zitat:
Für den Anfang würde ich zwei Threads verwenden, die jeweils ihre eigene Instanz der Komponente enthalten. Dann ist es nicht mehr möglich, dass sie sich gegenseitig stören.
Das Grundproblem bliebe aber: Das das blockierende Read abschmiert, wenn die zugrundeliegende Verbindung (zwangsläufig aus einem anderen Thread heraus) disconnected wird. Was für mich bedeuten würde, das ich entweder das Programm nicht beenden kann, solange der Thread auf Daten vom Server wartet oder das ich pollen muss, was ich nicht sehr elegant finde und was die Prozessorlast in die Höhe treibt... Hmm. In der Realität wird es so sein, daß ich mehrere (1 ~ vielleicht 20) Services auf einer Maschine habe, die auf Daten warten...