Ich entwickle einen Server in C #, der nur einen Client akzeptieren kann und ich muss wissen, wann dieser Client getrennt wird, um weitere Verbindungsanforderungen annehmen zu können.
Ich benutze einen ersten Socket, der ständig Verbindungsanfragen mit Socket.BeginAccept abhört und Clients annimmt oder ablehnt. Wenn ein Client akzeptiert wird, wird der neue Socket, der von Socket.EndAccept zurückgegeben wird, für die Kommunikation zwischen Client und Server verwendet. Dann wartet der Server auf Befehle vom Client mit Socket.Begin/EndReceive und sendet Antworten. Der Server verwendet ein Telnet-ähnliches Protokoll, was bedeutet, dass jeder Befehl und jede Zeile der Antwort mit \r\n enden muss.
Um festzustellen, ob der Client getrennt wurde, habe ich einen Timer installiert, der alle 500ms eine leere Nachricht (" \r\n ") an den Client sendet. Wenn der Client nicht verbunden ist, wird vom Socket eine Ausnahme ausgelöst. Diese Ausnahme wird vom Server abgefangen, der die aktuelle Sitzung schließt und eine neue Verbindung annimmt. Diese Lösung ist robust, impliziert jedoch unnötigen Verkehr über das Netzwerk und muss vom Client korrekt gehandhabt werden, der Dummy-Nachrichten filtern muss, bevor eine tatsächliche Antwort erhalten wird.
Ich habe versucht, einen leeren Puffer ( Socket.Send(new byte[1], 0, 0) ) zu senden, aber es scheint, dass das nicht in Richtung Server- & gt; -Client funktioniert.
Eine andere Lösung könnte darin bestehen, den Fall zu behandeln, in dem Socket.EndReceive 0 Byte zurückgibt. Es funktioniert gut für den Fall einer Unterbrechung, die während "Leerlauf" -Zeit auftritt. Wenn der Client die Verbindung jedoch während einer Nachrichtenübertragung trennt, sieht der Server sie nicht immer und wartet unbegrenzt.
Ich habe bereits mehrere Threads und Fragen zu diesem Problem gesehen, aber ich habe noch nie eine gute Lösung gesehen.
Meine Frage ist also: Was ist der beste Weg, um eine Unterbrechung in .Net zu erkennen?
Die einzige andere Option ist, wenn es TCP ist, dass TCP immer wieder einen Keep-Alive sendet, der immer noch abfragt, wie das, was Sie gerade tun, aber auf der TCP-Schicht behandelt wird, so dass Ihr Protokoll nicht funktioniert. Ich muss es wissen.
Es gibt jedoch keinen Weg um die Abfrage herum, denn ohne etwas an den anderen Client zu senden und eine Antwort zu erhalten, haben Sie keine Möglichkeit zu wissen, ob es immer noch verbunden ist oder nicht.
Keep Alive kann auch bei der Kommunikation durch stateful packet inspection wie Standard-NAPT erforderlich sein, um zu vermeiden, dass der Remote-Server die Sitzung aufgrund von Inaktivität abbricht.
Sie können die folgende Methode verwenden, um zu ermitteln, ob ein Client noch verbunden ist. Das
%Vor%Dies answer ist zum Testen von Socket, so habe ich mein Code-Snippet bekommen.
Haben Sie die Kontrolle über den Kunden? Wenn ja, können Sie nicht einfach den Client ein spezielles Paket an den Server senden sagen, dass es trennt, und dann trennen Sie den Socket?
Versuchen Sie, den Fall zu erkennen, dass der Client tatsächlich die Verbindung getrennt hat (entweder Socket.Shutdown () oder Socket.Close ()) oder ob der Client für eine sehr lange Zeit im Leerlauf ist und daher sein muss ausgeworfen?
Lassen Sie den Client in jedem Fall eine periodische Nachricht (genau wie Sie) an den Server senden. Der Server kann den letzten Herzschlag verfolgen, und wenn der Client mehr als 3 Herzschläge vermisst, können Sie den Client trennen. Ja, es beinhaltet zusätzliche Daten, aber das ist nicht so schlimm im großen Schema der Dinge. Wenn Sie es so einstellen, dass es den Herzschlag zu einem guten Zeitpunkt sendet, so dass Sie den Vorteil erhalten, zu wissen, ob der Client lebt und nicht zu lange zwischen Herzschlägen geht, könnten Sie ein sehr gutes System haben.
>Tags und Links .net sockets tcp disconnect