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

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

[himitsu]

Das SSL schaltet sich nun in den transfer mit ein und ich vermute, daß der die Verschlüsselung nicht je Datenrichtung "einzeln" behandelt, womit du dann diese Komponente in beiden Threads verwendest, was bei einer nicht threadsicheren Komponente wieder Probleme bereitet.

[idontknow]

@himitsu:

Ein Client und ein Server pro Richtung ginge natürlich, im Server.onExecute dann wahrscheinlich so:

Delphi-Quellcode:

if AContext.Connection.IOHandler.Readable then begin
    AllesWasDaIst := AContext.Connection.IOHandler.AllData(TEncoding.Ansi);
    Parsen...
end;

um auch hier das blockierende Lesen zu Vermeiden, sonst habe ich wahrscheinlich dasselbe Problem, wenn der Server auf Daten wartet und ich den beenden möchte. Der Call von onExecute heißt ja nur, das Daten eingetroffen sind, aber nicht, das die gewünschte Menge an Daten ankam...

Wenn es nicht schöner geht, wäre das natürlich eine Lösung...

[mjustin]

Zitat von idontknow:

Der Call von onExecute heißt ja nur, das Daten eingetroffen sind, aber nicht, das die gewünschte Menge an Daten ankam...

Das ist nicht korrekt. Die OnExecute Methode des TIdTCPServers wird in einer Schleife aufgerufen, unabhängig davon ob Daten angekommen sind oder nicht. Ob Daten angekommen sind, muss man selber ermitteln.
Am Anfang der OnExecute kann man dazu die Funktionen InputBufferIsEmpty und CheckForDataOnSource aufrufen.
Im Beispiel wird, wenn CheckForDataOnSource innerhalb der angegebenen Zeit keine neuen Daten lesen konnte, der OnExecute Durchlauf verlassen:

Delphi-Quellcode:

var
  IO: TIdIOHandler;
begin
  IO := AContext.Connection.IOHandler;

  if IO.InputBufferIsEmpty then
  begin
    IO.CheckForDataOnSource(10);
    if IO.InputBufferIsEmpty then Exit;
  end;

  // Do stuff with IOHandler
  IO. ...

end;

Und anstatt einfach alles einzulesen was im InputBuffer steht, kann man genau die benötigte Anzahl Bytes einlesen oder bis zu einem Terminator, je nachdem wie das Protokoll es vorsieht. Wenn Indy nicht alle Daten einlesen kann weil sie noch nicht komplett angekommen sind, blockiert die Read... Methode (bis zum Timeout, wodurch der Server einen Verbindungsverlust erkennt und die Connection seinerseits schliesst).

[idontknow]

Vielen Dank an alle, die geholfen haben. Habe das Problem wie vorgeschlagen mit einem Timeout gelöst, funktioniert prima.