Indy TCPClient Connection Status

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

[Delphi-Narr]

Ja das werde ich wohl tun
Heartbeats werden auch verschickt, nur nicht so oft. Das werde ich dann mal anpassen.
Komisch, dass das bei Windows-"interner" Kommunikation die Abfrage das richtige Resultat lieferte.

[Delphi-Narr]

Habe hierzu nochmal eine Frage:
Ich habe jetzt den Heartbeat eingebaut, der Client schickt in einem Intervall die Heartbeats und der Server antwortet.
In der ContextClass des Servers werden die MacAdresse und der Zeitpunkt des letzten Heartbeats des Clients gespeichert. In festen Intervallen räumt der Server dann auf, d.h. er durchläuft die Liste der verbundenen Clients und alle, die zu lange keinen Heartbeat mehr hatten, werden disconnected - zumindest in der Theorie.
Der Client erkennt inzwischen korrekt, ob er keine Verbindung mehr hat, der Server vom Prinzip her auch.

Delphi-Quellcode:

procedure TMyServer.HeartbeatCheck();
var
    ContextList:TList;
    Context:TIdContext;
    i:integer;
begin
    ContextList := TCPServer.Contexts.LockList;
    try
       for i := 0 to ContextList.Count-1 do
           begin
                Context := TIdContext(ContextList.Items[i]);
                if (IncSecond(TClientIdentifier(Context).Heartbeat, CLIENTTIMEOUT) < Now) and (TClientIdentifier(Context).Heartbeat <> 0) then
                   begin
                        Log('Client '+TClientIdentifier(Context).Mac+' timed out', ltE);
                        TIdContext(ContextList.items[i]).Connection.IOHandler.close;
                        TIdContext(ContextList.items[i]).Connection.Disconnect();
                   end;
           end;
     finally
        TCPServer.Contexts.UnlockList;
     end;
end;

Wenn ein Client die Verbindung verliert, wird das entsprechend geloggt, doch in JEDEM Durchlauf wird er erneut als timed out erkannt - dabei sollte er ja eigentlich aus der Liste gelöscht werden?!
Und auch wenn der Client die Verbindung wieder aufnimmt und Heartbeats schickt, wird er dennoch wieder getrennt.
Im OnDisconnect des Servers wird eigentlich ebenfalls geloggt, dass ein bestimmter Client die Verbindung getrennt hat - dies wird in der Heartbeat Methode aber offenbar gar nicht ausgelöst. Vielleicht ist es ja nur ein ganz einfacher blöder Fehler

Viele Grüße!

[mjustin]

Zitat von Delphi-Narr:

In festen Intervallen räumt der Server dann auf, d.h. er durchläuft die Liste der verbundenen Clients und alle, die zu lange keinen Heartbeat mehr hatten, werden disconnected - zumindest in der Theorie.

Auf Anhieb kann ich keinen Fehler erkennen. Frage: funktioniert es unter Windows, aber unter Linux nicht? Oder auf beiden System nicht?

Als Alternative würde ich noch erwägen die Heartbeat-Prüfung nicht als Schleife über alle Context Objekte zu realisieren sondern innerhalb der OnExecute - Loop. Damit spart man sich das LockList, da man in OnExecute den zu prüfenden Context threadsicher untersuchen kann. (Auf diese Idee hat mich ein Beitrag von Remy Lebeau gebracht: http://stackoverflow.com/a/1534800/80901).

In der OnExecute Loop kann man dann einfach eine (Indy-) Exception auslösen wenn der aktuelle Kontext zu lange kein Heartbeat-Signal mehr vom Client sah.

Ausgehend von diesem Codeschnipsel (http://stackoverflow.com/a/14180366/80901):

Delphi-Quellcode:

procedure TMainForm.IdTCPServerExecute(AContext: TIdContext);
var
  ...
begin
  ...

  if AContext.Connection.IOHandler.InputBufferIsEmpty then
  begin
    if not AContext.Connection.IOHandler.CheckForDataOnSource(100) then
    begin
      AContext.Connection.IOHandler.CheckForDisconnect;
      Exit;
    end;
  end;

  TCliContext(AContext).ProccessMsg;
  TCliContext(AContext).Activity_time := Now();
end;

... würde man nach dem CheckForDataOnSource auch die Activity_time prüfen und - falls sie "zu alt" ist - eine TIdException auslösen anstatt die Methode mit Exit zu verlassen. Durch die Exception erfährt der Server, dass er den Context freigeben und die Verbindung trennen soll.