Indy TCPClient Connection Status

[Delphi-Narr]

Hallo,
ich hatte vor einiger Zeit ein Client-Server-Konstrukt gebastelt, mit dem mehrere Rechner Systeminformationen (CPU, RAM etc) an einen Server schicken.
Die Clients sind alle Windows Rechner, der Server wurde jetzt auf Linux umgestellt, sodass ich den Server mit Lazarus auf Linux kompiliert habe.
Zu Testzwecken ist der Server erstmal nur eine Konsolenanwendung und noch kein Dienst oder ähnliches.

Der Server erstellt einen Indy10 TCP-Server und geht dann in eine "Endlosschleife", in welcher er wartet.

Delphi-Quellcode:

procedure TMyServer.DoRun;
begin
  Init();
  while (not Terminated) do
  begin
    if KeyPressed then
      if ReadKey = ^C then
      begin
           Log('Shutting down...');
           Terminate;
      end;
    Sleep(2);
  end;
  Terminate;
end;

Die Initialisierung klappt auch wunderbar, der Server ist bereit, Verbindungen entgegenzunehmen.
Der "alte" Windows Client kann sich auch zum Server verbinden und Daten übertragen. Nach ca. 1-2 Sekunden stellt er jedoch immer eine neue Verbindung zum Server her.
Dies ist laut Client auch vorgesehen, wenn er keine aktive Verbindung feststellt:

Delphi-Quellcode:

if (TCPClient.Connected) then
   //Irgendwas sinnvolles
else
   //Reconnect

Nur stellt er in einer TimerLoop anscheinend jedesmal fest, dass TCPClient.Connected = false ist.

Im Server wird die TCPServerDisconnect anscheinend nicht aufgerufen, der Server kriegt den Disconnect nicht mit.

Woran könnte das liegen?

Viele Grüße!

[himitsu]

Zitat:

Konsolenanwendung ...

Wenn die komponenten mit Messages arbeiten, dann mußt du auch Messages verarbeiten (die VCL macht das konstruktionsbegingt automaisch), sonst kann da schnell einiges nicht (richtig) funktionieren.



PS: Bei Verbindungsabbrüchen kann es sein, daß Connected noch lange True liefert.
Der einzige sichere Weg eine Verbindung zu prüfen, ist etwas zu senden und auf die Antwort zu warten.
(Connected=False ist dagegen natürlich immer Disconnected)

[Delphi-Narr]

Ah, ja das hatte ich mir schon gedacht. Unter Lazarus habe ich das ganze aber nicht hinbekommen, da alles, was ich dazu gefunden habe auf Windows Bibliotheken basiert.
Ich müsste also in der Loop die Messages manuell abfragen, wie könnte das unter Linux denn gehen?

Wenn connected noch true liefert, schickt der Client die Daten an den Server und erhält eine Bestätigung. Aber selbst, wenn die Daten verloren gehen und erst nach 10 Sekunden neu geschickt würden, wenn der Client mitbekommen hat, dass die Verbindung tot ist, wäre kein Problem (An der Hardware-Konfiguration ändert sich ja nicht so viel )

Alle 30 Sekunden tauschen Server und Client auch unabhängig voneinander Keep-Alive-Meldungen aus und trennen die Verbindung, wenn die nicht ankommen.

[mjustin]

Zitat von Delphi-Narr:

Ich müsste also in der Loop die Messages manuell abfragen, wie könnte das unter Linux denn gehen?

Indy verwendet keine Windows Messages - daher war ist es leichter auf andere Betriebssystem portierbar. Der Fehler muss also woanders liegen.

Ich würde mal einen Client auf dem gleichen Linux System laufen lassen um zu testen, ob er sich auch ständig neu verbindet.

Und auch mit netstat mal schauen ob und wielange der Serverport geöffnet ist.

[Delphi-Narr]

Der Client ist in diesem Fall nicht Linux kompatibel und lässt sich auch nicht so leicht portieren...

Laut nmap mit watch ist der Port die ganze Zeit offen. Ich denke, dass der Client die "connected"-Abfrage immer zu false auswertet... Eine Disconnect Fehlermeldung kommt nicht, nur alle paar Sekunden die Verbunden-Meldung.

[mjustin]

Zitat von Delphi-Narr:

Ich denke, dass der Client die "connected"-Abfrage immer zu false auswertet

Was ein Argument dafür ist, sie wegzulassen

In meinen Indy-basierten Clients benutze ich heart-beat Nachrichten um den Verbindungsstatus zu prüfen. Ob die Verbindung noch besteht läßt sich dadurch prüfen, dass man versucht Daten zu empfangen (IOHandler.Readxxx) oder zu senden (IOHandler.Writexxx). Falls dann eine Exception auftritt, verwirft der Client die Verbindung, und versucht sie wiederherzustellen, am sichersten indem auch eine neue Instanz der TIdTCPClient Klasse erzeugt wird.