Indy TCPServer beenden mit toten Clients

[hsg]

Hallo zusammen,

ich kämpfe gerade mit einem TIdTCPServer(Indy10), der sich mit unseren PDAs übers WLan unterhält. Leider kommt es vor, dass der Mitarbeiter mit seinem PDA den Bereich des WLan verlässt oder der PDA aus anderen Gründen die Verbindung zum Netzwerk verliert.

Kommt der PDA wieder ins Netz, meldet er sich beim Server auf einem neuen Port an und gut ist. Im Server ist der PDA zweimal aufgelistet, macht aber keine Probleme. Wird der Server nun beendet, bekommen beide Client-Verbindungen die Abmeldung und der Server lässt sich dann sauber beenden.

Anders ist es allerdings, wenn der PDA beim Beenden des Servers nicht mehr erreichbar ist. Dann versucht der Server die Verbindung zu beenden, bleibt dabei aber hängen.

Beim Server ist die TerminateWaitTime gesetzt,
in den jeweiligen Connections die ConnectTimeout und die ReadTimeout.

Leider bekomme ich kein Disconnect vom Client, auch keine Exception im Server.

Was kann ich tun, damit der Server sauber beendet werden kann?

Gruß
Jörg

Umgebung: Server mit Indy10.1 in BDS 2006 geschrieben.

[mjustin]

Zitat:

Umgebung: Server mit Indy10.1 in BDS 2006 geschrieben.

Wie versucht der Server denn die Verbindung zu beenden - soll da noch etwas über den IOHandler (Socket) an den Client gesendet werden, und ist dabei ein Timeout angegeben?

p.s. das ist eine sehr alte Version, spricht etwas dagegen die aktuelle Version 10.5.8.(4768) zu testen?

[hsg]

Zitat von mjustin:

Wie versucht der Server denn die Verbindung zu beenden - soll da noch etwas über den IOHandler (Socket) an den Client gesendet werden, und ist dabei ein Timeout angegeben?

Der Server versucht etwas zu senden (IOHandler.Writeln('CLOSE_REQUEST@ ') Über diesen Punkt kommt er aber ohne Probleme hinweg.
Wie gebe ich ein TimeOut beim Schreiben an?
Hängen scheint er beim beenden des Threads.

Was mich irritiert ist die Tatsache, dass der tote Socket beim erreichen des Netzes ja erfolgreich geschlossen wird (wenn also zwei Socketverbindungen vorhanden sind und die zweite noch lebt. Nur wenn das Gerät überhaupt nicht mehr ansprechbar ist, begeht der Server Suizid.

Zitat von mjustin:

p.s. das ist eine sehr alte Version, spricht etwas dagegen die aktuelle Version 10.5.8.(4768) zu testen?

Werde ich Montag mal ausprobieren.

Gruß Jörg

[mjustin]

Zitat von hsg:

Der Server versucht etwas zu senden (IOHandler.Writeln('CLOSE_REQUEST@ ') Über diesen Punkt kommt er aber ohne Probleme hinweg.

Ok, das Senden an den Socket funktioniert - das ist normal, auch wenn die Gegenseite nicht zuhört.

und das:

Zitat:

Anders ist es allerdings, wenn der PDA beim Beenden des Servers nicht mehr erreichbar ist. Dann versucht der Server die Verbindung zu beenden, bleibt dabei aber hängen.

verstehe ich als ob nach dem obigen "Writeln" noch etwas vom Server gemacht wird, zum Beispiel auf die Antwort des Clients auf das 'CLOSE_REQUEST@' zu warten. Und das kann natürlich nicht mehr erfolgreich sein wenn der Client nicht da ist. In diesem Fall sollte der Server die dann auftretende Exception (vermutlich ReadTimeOut) eventuell nicht mehr behandeln und Indy automatisch den Thread beenden lassen, wenn ich mich richtig erinnere.

Beim IOHandler.Read kann ein TimeOut direkt als Parameter angegeben werden. Der Default ist relativ lange, was wie ein Hänger aussehen kann.

(Send-Timeouts sind plattformspezifisch, nicht als Parameter oder Properties, konfigurierbar und hier anscheinend nicht das Problem)

Hope this helps,

[hsg]

Zitat von mjustin:

Zitat:

Anders ist es allerdings, wenn der PDA beim Beenden des Servers nicht mehr erreichbar ist. Dann versucht der Server die Verbindung zu beenden, bleibt dabei aber hängen.

klingen als ob nach dem obigen "Writeln" noch etwas vom Server gemacht wird, zum Beispiel auf die Antwort des Clients auf das 'CLOSE_REQUEST@' zu warten. Und das kann natürlich nicht mehr erfolgreich sein wenn der Client nicht da ist. In diesem Fall sollte der Server die dann auftretende Exception (vermutlich ReadTimeOut) eventuell nicht mehr behandeln und Indy automatisch den Thread beenden lassen, wenn ich mich richtig erinnere.

Der ReadTimeOut ist gesetzt (300 sek. habe aber den Server eine viertel Stunde in Ruhe gelassen, er hing immer noch
Die Clients schließen auf die Aufforderung nur die Sockets. Es wird nichts gesendet.
Exception wird ja auch keine geworfen. Zu keinem Zeitpunkt.

Zitat von mjustin:

Beim IOHandler.Read kann ein TimeOut direkt als Parameter angegeben werden. Der Default ist relativ lange, was wie ein Hänger aussehen kann.

(Send-Timeouts sind plattformspezifisch, nicht als Parameter oder Properties, konfigurierbar und hier anscheinend nicht das Problem)

Hope this helps,

Einzig allein in der OnExecute-Routine wird der Inputbuffer ausgelesen

Delphi-Quellcode:

  if AContext.Connection.IOHandler.InputBufferIsEmpty then
     begin
       SleepEx(10, True);
       Exit;
     end;

  oAnswer                    := TStringList.Create();

  try
    bTest                    := True;
    cMess                    := Trim(AContext.Connection.IOHandler.InputBufferAsString());
    //cMess                     := Trim(AContext.Connection.IOHandler.ReadLn());

    if cMess = '' then
       begin
         Exit;
       end;
...

es wird also explizit vorher nachgesehen, ob etwas im Puffer steht. Auch kommt er beim Beenden nicht an diese Stelle. Kann somit leider ausgeschlossen werden

[mjustin]

Zitat von hsg:

Exception wird ja auch keine geworfen. Zu keinem Zeitpunkt.

Werden Exceptions eventuell so behandelt, dass Indy sie nicht bemerkt? Indy verwendet einige (selbstdefinierte) Exceptions wie EIdConnClosedGracefully zur Steuerung:

Zitat:

You need to get rid of your exception handling, or at least re-raise any EIdException-derived exceptions you catch. You are blocking Indy's internal notifications from being dispatched and processed correctly.

(https://forums.embarcadero.com/messa...ssageID=257582)

[sx2008]

Wenn eine TCP-Verbindung physisch getrennt wird, kann das keiner der beteiligten Partner erkennen ohne dass Daten gesendet werden.
Nur wer Daten sendet, kann erkennen dass die Verbindung unterbrochen ist.
Dazu gibt es in vielen Protokollen einen NOP-Befehl (NO-Operation, Befehl der nichts tut).
Man kann aber auch ein Datenpaket der Länge 0 senden, wobei das aber nicht so zuverlässig wie ein NOP-Befehl ist.

[mjustin]

Zitat von sx2008:

Wenn eine TCP-Verbindung physisch getrennt wird, kann das keiner der beteiligten Partner erkennen ohne dass Daten gesendet werden.

Die Verbindung wird, wenn ich es soweit richtig verstanden habe, serverseitig zuerst logisch beendet durch senden (IOHandler.Writeln('CLOSE_REQUEST@ '), und bei dieser Operation hängt Indy noch nicht. Indy beendet den Server aber danach nicht, so dass die Anwendung nicht terminiert.

[mjustin]

Zitat von hsg:

Der Server versucht etwas zu senden (IOHandler.Writeln('CLOSE_REQUEST@ ') Über diesen Punkt kommt er aber ohne Probleme hinweg.

Folgt nach dem

Delphi-Quellcode:

IOHandler.Writeln('CLOSE_REQUEST@ ')

noch ein sauberes Beenden der Verbindung? (Schliessen des Sockets)

Delphi-Quellcode:

AContext.Connection.Disconnect

Wenn das Protokoll geändert werden kann, wäre ein Heartbeat-Verfahren eventuell eine Verbesserung, damit der Server verloren gegangene Verbindungen schneller erkennt und abräumt.

Update:

unter http://www.delphipraxis.net/157267-i...er-thread.html

werden noch diese Zeilen regelmäßig im Server OnExecute ausgeführt:

Delphi-Quellcode:

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

[himitsu]

Ich hatte soeiein Problem beim DataSnap bemerkt, welches intern auch Indy-TCP nutzt (versteckt hinter den benutzen DBConnections).

Wenn die Connection z.B. durch ein Netzwerkproblem getrennt wurde oder teilweise auch wenn Clientanwendungen abgestürzt sind, dann wurden die Connections nicht odnungsgemäß getrennt.
Der Server denkt dann die Clients seien noch vorhanden und beim Runterfahren sendet er dann allen "bekannten" Clients eine "ich bin dann mal Weg"-Nachricht, damit sie ihrerseits die Verbindung ordentlich trennen können. (ja, auch Clients können eventuell hängen, wenn der Server weg ist)

Wobei er dann einfach hängen bleibt, wenn er auf soeinen toten Client trifft.


Leider läßt sich dagegen nichts machen. (wir haben alles Mögliche versucht)




Zum Teil ist das auch ein Problem von Windows, denn dieses schließt die Ports nicht, wenn die Connection abreißt, womit Indy (im Server oder auch im Client) nicht darüber informiert wird, daß die Connection eigentlich weg ist.

Standardmäßg sendet Windows keine NOPs (oder sowas), über die "aktiven" Ports. Es gibt zwar soeine Funktion, welche aber eigentlich nie aktiv ist, oder die Zeit war nur ewig hoch eingestellt. (nicht ganz sicher ... müßte nochmal nachsehn)
Es testet also selbstständig keine Portverbindungen, womit es Windows oftmals erst nach 24 Stunden auffällt und so lange die Verbindung angeblich noch besteht.