TClientSocket - Disconnect prüfen

[Zacherl]

Hey,

kann ich mit meinem TClientSocket irgendwie prüfen, ob die Verbindung noch besteht OHNE irgendwelche PING PONG Daten zu verschicken? Das OnError Ereigniss kann ich nicht verwenden und wenn die Verbindung abbricht ist Socket.Connected immer noch true :?

Gruß Florian

[Muetze1]

Ich habe die Erfahrung gemacht, dass bei einem OnError die Socketverbindung eh nicht mehr brauchbar ist und rufe von daher im OnError Handler immer Socket.Close; auf und damit bekomme ich eigentlich immer ein ordentliches OnDisconnect für jeden Socket geliefert. Vielleicht hilft das schon bei deinem Problem...

[Zacherl]

Ich weiß nicht warum, aber das OnError Ereigniss wird nicht aufgerufen. Ich habe mittlerweile eine nonVCL Anwendung, welche mit GetMessage, TranslateMessage, etc eine Nachrichtenschleife erzeugt. Vorher erstelle ich nun nicht mehr in einem Thread mein ClientSocket und weise die Events zu. Allerdings kommt es zu sehr seltsamen Verhalten: Weder das OnRead noch das OnError Event werden aufgerufen. Vielleicht liegt es an meiner Funtkion, die ich direkt nach dem Erzeugen des Sockets aufrufe. Es handelt sich um eine Endlosschleife, die versucht das Socket zu verbinden und wenn dies passiert ist manuell das OnRead Event aufzurufen. Das Ganze ist irgendwie ziemlich komisch ..

[Muetze1]

Endlosschleife? Wie hast du denn beim Öffnen des Sockets angegeben wie du informiert werden möchstest? Windows Message, Callback, Eventtrigger?

[Zacherl]

Ich hab einfach das Event zugewiesen. TCPClient.OnError := OnClientError. OnClientRead habe ich ein meiner Anwendung deklariert. Kann da der Fahler liegen, dass es sich um eine Endlosschleife handelt? Diese Schleife soll eigentlich nur zum Verbinden des Sockets sein. Wenn eine Verbindung da ist, brauche ich sie nicht mehr. Momentan benutze ich sie nun zum manuellen Aufrufen des OnRead Events, welches auch nicht automatisch aufgerufen wird, wenn neue Daten vorhanden sind.

Also so gehts in etwa:
* ClientSocket createn
* Schleife: geht so lange durch, bis das Socket eine Verbindung hat
* Schleife: ändert dann die Funktion in periodisches Aufrufen des OnRead Ereignisses
* Nachrichtenschleife starten

Da denke ich ist das Problem, dass die Nachrichtenschleife dank der Endlosschleife nicht gestartet wird ..

[oki]

Hi,

ich hab die erfahrung gemacht, dass sich ein Client nicht immer abmeldet und auch keinen Error provoziert wenn er verschwindet. Prüfung auf Connected ergab true, obwohl kein Client mehr da war. also ping pong.


Gruß oki

[Zacherl]

Mh nee .. normal wird dann aber wenigstens das OnError Event ausgelöst .. inn VCL Anwendungen geht das auch wunderbar ..

[Muetze1]

Wieso baust du überhaupt eine Polling Abfrage? Der Socket ist per Default (ctNonBlocking) intern mit Threads versehen und sagt dir in so fern per Callback (sprich: Events) Bescheid, wenn eine Verbindung da ist. Wenn du in einer Schleife läufst, bekommt der Thread keine Zeit mehr zum Arbeiten. Rufst du in der Schleife auch mal Sleep() auf um dem Thread auch ein wenig Rechenzeit zu lassen?

Im allgemeinen würde ich es beim Event-Driven Modell lassen und nicht unbedingt auf das Polling umsteigen, da es generell zuviel unnütze Rechenzeit frisst.

[Zacherl]

Ja wollte ich so auch lieber machen. Ich hatte das Socket auf ctBlocking eingestellt, denn bei ctNonBlocking funktionierte schon das Verbinden nicht. Habe meinen ganzen Aufbau nun mal angepasst, sodass ich direkt nach Programmstart das Socket erzeuge, die Events zuweise und die Nachrichtenschleife starte. Die Events funktionieren nun auch soweit, wenn ich das Socket auch direkt verbinden lasse.

Aber wie kann ich nun in einer Schleife / in einem Thread versuchen lassen das Socket zu verbinden. Erst wenn die Verbindung zu stande kommt soll die Schleife / der Thread beendet werden. Threads haben immer dazu geführt, dass entweder die Events nicht mehr ausgeführt werden oder das Socket nie verbindet. Die Schleife hat das Problem, dass sie sich vor die Nachrichtenschleife drängt sozusagen und damit die Abarbeitung der Messages verhindert --> Events werden wieder nicht aufgerufen und Socket verbindet auch nicht.