Indy 10.6.5040 TCPServer Serverschliessen und Client Verbindungen trennen

[Aviator]

Gibt es hier mittlerweile eine funktionierende Lösung für Indy 10? Ich stehe nämlich genau vor dem gleichen Problem. Meine OnExecute Methode des Servers ist noch vollkommen leer, da ich erst im Aufbau des Servers bin. Sobald alle Clients von selbst disconnecten, wird auch die Anwendung sauber geschlossen.

Wenn ich die Möglichkeit habe, jedem Client vorher eine Quit Befehl zu senden, wie sx2008 es auch bereits erwähnt hat, dann werde ich das natürlich machen. Mir geht es allerdings vorangig um den Fall, dass ich den Server ohne den Quit Befehl beenden muss (warum auch immer).

Wäre für eine funktionierende Lösung sehr dankbar.

[CocoPops]

Gemeinde.

Und ich habe ebenfalls genau dasselbe Problem oder fast.

Mein Client verbindet sich zum Server und der Server wird aus irgendwelchen Gründen unsauber beendet.
Die Verbindungen zu den verbundenen Clients wird also nicht korrekt beendet.

Selbst mit ReadTimeout hängt sich das Programm auf und befindet sich in einer Endlosschleife OBWOHL eine AV geworfen werden müsste:

Delphi-Quellcode:

 while not Terminated do
  begin
   Sleep(5000);

   IdTCPClient.ReadTimeout := 2000;
   IdTCPClient.IOHandler.ReadTimeout := 2000;

   if IdTCPClient.Connected then
    begin
     try
      s := IdTCPClient.IOHandler.ReadLn;
     except
      on E: Exception do
       WriteLn(PChar(E.ToString));
      
      break;
     end;
    end
   else
    begin
     break;
    end;
  end;

[mjustin]

Wie oft wird nach dem Verbindungsverlust denn

WriteLn(PChar(E.ToString));

ausgeführt, endlos oder nur einmal?

[CocoPops]

Hallo mjustin.

Es gibt keinen Verbindungsabbruch denn das Programm bleibt bei s := IdTCPClient.IOHandler.ReadLn; einfach stehen
und es wird niemals ine AV ausgegeben.

Ich glaube das ist, und das schon seit vielen Jahren, noch immer ein Bug.

[mjustin]

Auf "Connected" zu prüfen ist nicht sinnvoll: diese Funktion gibt immer True zurück, wenn im Inputpuffer noch Daten stehen.

Eine AV (Access Violation) muss nicht geworfen werden, sondern eine (Unterklasse von) IdException.

IdTCPClient.IOHandler.ReadTimeout zu setzen ist nicht notwendig, da IdTCPClient.ReadTimeout das schon macht.

Und das Sleep(5000) könnte man auch weglassen, und stattdessen ReadLn mit einem Timeout-Parameter aufrufen: http://stackoverflow.com/questions/1...n-with-timeout

[CocoPops]

Kann es auch sein, dass ein ProcessMessages in einem Thread nicht ganz so toll ankommt? Denn ich habe zufällig eines gefunden. Ich habe es entfernt und nun funktioniert das Timeout SCHEINBAR.

[mjustin]

Zitat von CocoPops:

Kann es auch sein, dass ein ProcessMessages in einem Thread nicht ganz so toll ankommt? Denn ich habe zufällig eines gefunden. Ich habe es entfernt und nun funktioniert das Timeout SCHEINBAR.

Ja, ProcessMessages ist eine bekannte "Deadlockquelle".