IdTCPServer hängt beim Schließen mit verbundenen Clients

[s.h.a.r.k]

hallo miteinander,

zuvor gleich mal gesagt: ich habe schon mal einen thread zu diesem thema eröffnet gehabt, werde in diesem aber nicht weiter fortfahren, da dieser schon recht alt ist und mein problem nicht löst.

zu meinem problem nun: ich habe eine anwendung für den server und einen für den client. beim server habe ich mir die funktion eingebaut, dass man einen client "kicken" kann, eben ein force-disconnect vom server aus. ich will hierbei ausdrücklich dem client keine nachricht zukommen lassen, dass dieser selbst disconnected, da dieser die nachricht evtl. ja nicht erhalten kann oder nicht verarbeitet, da dieser hängt. diese habe ich wie folgt realisiert:

Delphi-Quellcode:

aContext.Connection.Disconnect();

wenn dieser code ausgeführt wurde, dann ist der client wirklich disconnected, allerdings ist es wohl auch so, dass die folgende fehlermeldung kommt, die ich nicht verstehe. ich hoffe, ihr könnt mir hier weiter helfen.

Code:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt tcp_server.exe ist eine Exception der Klasse EIdNotConnected mit der Meldung 'Not Connected' aufgetreten.
---------------------------
Anhalten   Fortsetzen   Hilfe  
---------------------------

dies war an sich nur das vorgeplänkel, da das eigentliche problem auftritt, wenn ich den server schließen will. da ich mich nicht auf die nachricht und das selbstständige disconncet der clients verlassen will, will ich eben jeden client vom server kicken und diesen dann schließen. dies liegt daran, dass der server sich beim versuch alle yarns zu terminieren (ich habe alleine schon mal keine ahnung was yarns sind :wall: ) aufhängt. dies passiert aber eben nur, wenn mindestens ein client verbunden ist. ich verwende den folgenden code bisher, der allerdings keine abhilfe schafft und den server toll einfrieren lässt, eben in einer endlosschleife beim versuch die yarns zu terminieren - soweit habe ich das problem schon verfolgen können.

Delphi-Quellcode:

// in der FClientList stehen alle Clients
// vom Typ TIdContext, die ich manuel
// beim OnConnect speichere
for i := FClientList.Count - 1 downto 0 do
  TIdContext(FClientList[i]).Connection.Disconnect();
 
// TCP-Server deaktivieren
FTCPServer.Active := False;

ich hoffe, es findet sich jemand, der dieses problem auch hat(te) und eine lösung findet ;)

mit freudlichen grüßen
pfäffle armin

[s.h.a.r.k]

*push* kann mir hierbei wirklich keiner helfen!? :pale:

[DataCool]

Hi,

ich versteh nicht warum Du Dich nicht auf die Methoden von Indy selber berufst/verlässt.

Den Server auf Active false zu setzen, sollte reichen um alle noch verbundenen Clients zu trennen.

Wenn Du aber schon mit einem eigenen Protokoll arbeitetest,
dann sollte es doch möglich sein, denn Clients eine Nachricht zu schicken, das dieser sich dann disconnected.
Ja, Du hast geschrieben das Du diese Möglichkeit nicht möchtest, weil der Client ja im Nirvana hängen könnte ....
Aber stell Dir mal vor an Deinen Server hängen 500 Clients und anstatt das sich 499 sauber abmelden und
nur der eine der sich aufgehängt hat "gekickt" wird.
Willst Du gleich alle 500 "kicken" ?!

Ich empfehle Kommando an die Clients, das diese sich sauber abmelden.
Wer nicht nach 5 Sekunden disconnected ist wird "gekickt".

Um solche Probleme aber im Keim zu ersticken empfehle ich Dir:
- Client und Server senden jeweils in regelmässigen Abständen ein "NOOP" oder ähnliches um den Status der Leitung zu prüfen
- Zu jedem Client Informationen zu speichern unter anderem auch den Zeitpunkt der letzten "Aktion"(Empfangen/Senden)
- im Intervall X die Liste der Clients prüfen und Clients mit zu alter "LastAction" mit einem speziellen Abfrage-Kommando prüfen
kommt keine Antwort auf dieses Kommando, dann und nur dann wird die Verbindung "hart" vom Server getrennt.
- Beim runterfahren des Servers, vorher alle Clients benachrichtigen, so das sich diese im Zeitraum X selber sauber abmelden können,
nur restliche Clients durch Indy selber "kicken" lassen.

Früher unter Indy9 hatte ich auch ab und an den Fall das ich mich speziell um den ein oder anderen Client kümmern mußte,
aber jetzt mit Indy10(10.2.3 Snapshot) reichen oben genannte Massnahmen um einen sauberen Ablauf zu gewährleisten.

Bei mir laufen in drei verschiedenen Serveranwendung zwischen 100 und 999 Clients mit oben genannter Technik sauber.

Gruß Data

[s.h.a.r.k]

hallo,

danke erst mal für deine antwort!

Zitat:

ich versteh nicht warum Du Dich nicht auf die Methoden von Indy selber berufst/verlässt.

was genau meinst du damit!?

Zitat:

- Beim runterfahren des Servers, vorher alle Clients benachrichtigen, so das sich diese im Zeitraum X selber sauber abmelden können,
nur restliche Clients durch Indy selber "kicken" lassen.

die idee ist nicht schlecht, das stimmt, nur ist es so, dass wenn mindestens ein client mit dem server verbunden ist, ich server.active auf false setze, sich die anwendung aufhängt. die stelle, wo dies passiert habe ich auch schon gefunden. dies hat mit den "yarns" zu tun (methode: terminateAllYarns). ich weiß nicht, warum es das tut, aber somit friert das server-programm eben ein. daher bin ich auf die idee gekommen, jeden client vor einem server.active := false zu disconnecten, da wenn kein client mit dem server verbunden ist, das alles wunderbar klappt.

ich hoffe, dass mein problem jetzt etwas besser zu verstehen ist.

mit freundlichen grüßen
der hai

[DataCool]

Hi,

kann es sein Du Du bei Deinem Server einen Scheduler verwendest ?
Wenn ja schmeiß denn raus, damit hatte ich auch schon mal ähnliche Probleme.

Welche Version der Indy10er verwendest Du gerade ?

Gruß Data

[s.h.a.r.k]

ich verwende die aktuelle version: 10.2.3 - habe ich mir letztens runtergeladen und installiert, da ich schon dachte, dass es daran liegen könnte.

scheduler? ich denke nicht, muss aber nochmal nachschauen. sitze grad am internetrechner und nicht an meinem arbeitsrechner. aber pauschal hätte ich gesagt, dass ich einen TIdTCPServer, eine TIdAntiFreeze und einen TIdIOHandlerStack benutze.

ich muss mal schauen, ob ich nicht eine kleine demo präsentieren kann, dann kannst du dir vielleicht den quellcode anschauen, falls du lustig bist. muss nur den code passend aus meinen bisherigen projekt exportieren.