Indy 10.6.5040 TCPServer Serverschliessen und Client Verbindungen trennen

[mjustin]

Zitat von Cyberaxx:

Delphi-Quellcode:

procedure TStringServerForm.IdTCPServer1Execute(AContext: TIdContext);
var
  LLine: String;
  ID: Integer;
begin
  if IdTCPServer1.Active then
  begin
    //TIdNotify.NotifyMethod( ShowStartServerdMessage );
    //LLine := AContext.Connection.IOHandler.ReadLn(TIdTextEncoding.Default);
    ID := Integer(AContext.Connection.Socket);
    LLine := AContext.Connection.IOHandler.ReadLn();
    Memo1.Lines.Add(Format('[%.10d]: %s', [ID, LLine]));
    AContext.Connection.IOHandler.WriteLn('OK');
    //TIdNotify.NotifyMethod( StopStartServerdMessage );
  end;

  AContext.Connection.IOHandler.CheckForDisconnect(False, True);
  AContext.Connection.CheckForGracefulDisconnect(False);
end;

Die Execute Methode wird innerhalb eines Serverthreads ausgeführt, daher sind direkte Zugriffe auf VCL Komponenten nicht sauber, da diese nicht threadsicher sind. Anstatt direkt auf Memo1 zuzugreifen kann zum Beispiel mit TThread.Queue das Logging in Memo1 threadsicher erfolgen.

Das "if IdTCPServer1.Active" then ist nicht erforderlich, da der Server den Eventhandler nicht mehr aufrufen wird wenn Active := False ist.

[Cyberaxx]

Das ist alles schon klar. Es handelt sich hier ja nur um eine Testanwendung und es ist auch nur ein Client verbunden.

Ich wollte halt alles mögliche ausprobieren was ich beim Suchen gefunden habe. Dennoch wird damit das eigentliche Problem ja nicht gelöst.
Das letzte war einfach nur im OnClose der Form Active auf False zu setzen und das Programm hing.

Derzeit ist es so das die Fehlermeldungen nur innerhalb der IDE auftauchen. Starte ich das Programm ohne IDE läuft es wunderbar.
Später ist es in einer Konsolenanwendung auf Linux und da wird auch nichts angezeigt sondern nur intern ausgewertet. Wie gesagt ich hatte so etwas schon mit den Sockets programmiert. Stammt alles noch vom Bin-Protokoll von Hagen glaub ich wars.

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