TCPClient+SSL, Blockierendes Read -> Disconnect -> AV

[himitsu]

Zitat:

Da das Lesen schon in einem eigenen Thread läuft, wird der Hauptthread (sofern keine "Synchronize"-Fehler gemacht werden) nicht blockiert.

Ja, aber wenn man die Zugriffe absichern würde, dann würde die CriticalSection den anderen Thread blockieren.

Und wenn das Lesen nicht mehr blockierend ist, dann könnte man es auch in den anderen Thread verschieben, wo die TCP-Komponente erstell/verwaltet wird, und könnte sich so dann die Synchronisierung sparen.


Man kann auch in beide Richtungen einen Server-Client aufmachen, dann brauchst du nicht zu pollen, da der "Server" im Client dann via Empfangsereignis reagiert.

Oder man verwendet etwas "ausgewachsenere" Transportkomponenten, welche z.B. eine Callbackfunktion zum Client bieten, so daß der Server direkt senden kann und im Client dann ein Empfangsereignis auslöst, ohne daß der Client ständig abfragen muß.

[idontknow]

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...

[samso]

Der Schlüssel zum Erfolg ist, dass man sicherstellt, dass mit dem ReadThread tatsächlich nur gelesen wird und mit dem WriteThread nur geschrieben wird. Das wiederum ist mit Indy nicht so trivial, weil die diversen Methoden verdecken, was tatsächlich geschieht. Während des Verbindungsaufbau/Abbau darf nur einer der Threads auf den Client zugreifen. Das ist hier nicht der Fall, denn Du unterbrichst die Verbindung, während der ReadThread versucht zu lesen.

Mein Vorschlag: Du baust beim ReadThread einen Timeout von z.B. 20ms [IOHandler.Readable(20)] ein. Du wartest also nicht unendlich lange auf Daten, sondern halt nur kurze Zeit. Nach Ablaufen des Timeouts, prüfst Du ob der Thread terminiert wurde. Wenn er nicht terminiert wurde, darfst Du nochmal versuchen zu lesen usw.
Das regelmäßige Aufwachen des Threads wegen des Timeouts führt zu keiner nennenswerten CPU-Belastung. Für den Verbindungsabbau terminierst Du den ReadThread. Dann wartest Du bis er tatsächlich beendet wurde. Erst jetzt löst Du Disconnect aus.