Asyncsockets und „stille“ Unterbrechungen

Question

Ich habe Kakaoasyncsocket als Client mit AsyncSocket für einen Windows .NET -Server verwendet. Ich codiere Nachrichten mit Protokollbuffern. Zusammen machen diese eine großartige Reihe von Werkzeugen.

In letzter Zeit habe ich jedoch festgestellt, dass, wenn ich den Client längere Zeit - viele Stunden -, wenn ich versuche, eine Anfrage für Daten zu stellen, mit dem Server in Verbindung zu bringen, die Nachricht zugesandt, aber nie auf dem Server ankommt. Ich nenne dies eine "stille" Trennung, weil ich die übliche Trennung nicht erhalte, die ich tun würde, wenn es ein Netzwerkproblem gäbe.

Ich bearbeite die folgenden Methoden, um zu debuggen, aber keiner von ihnen wird angerufen:

- (NSTimeInterval)onSocket:(AsyncSocket *)sock
  shouldTimeoutReadWithTag:(long)tag
                   elapsed:(NSTimeInterval)elapsed
                 bytesDone:(CFIndex)length {

- (void)onSocket:(AsyncSocket *)sock willDisconnectWithError:(NSError *)err

- (void)onSocketDidDisconnect:(AsyncSocket *)sock

Ohne eine Benachrichtigung finde ich das schwierig zu debuggen. Der Server zeigt in ähnlicher Weise keine Unterbrechungen an.

Würde mich jemand in eine Richtung verweisen, wie er dies weiter analysieren kann?

Danke vielmals.

Answer 1

Wenn Sie wissen möchten, dass Ihre Kunden und Server miteinander verbunden sind, müssen Sie einen Herzschlag oder "Keepalive" haben, dh eine Nachricht auf Anwendungsebene, die im Grunde genommen ausgetauscht wird "Sind Sie da"/"Ja".

Dies gilt heutzutage insbesondere, da viele Router stillschweigend im Leerlauf -TCP -Verbindungen fallen. Dafür war TCP nicht konzipiert, aber es ist eine Tatsache des Lebens.

TCP hat die Option, den Herzschlag für den Verbindungsschicht mit So_keepalive zu senden, aber historisch gab es ein Argument darüber, ob dies angemessen war. Die Designer waren der Ansicht, dass es falsch war, eine Steckdose aufgrund eines vorübergehenden Intermediate -Netzwerkproblems fallen zu lassen. Wenn in diesem Zeitraum tatsächlich keine Daten gesendet wurden, gab es keinen Grund, die Verbindung fallen zu lassen. Andere waren der Meinung, dass es wichtig war, zu wissen, ob die Verbindung gut war, für und für sich wichtig war. Was wäre, wenn Sie Daten erwarten würden, aber nicht angekommen wäre? Woudl willst du nicht wissen?

Letztendlich hängt es von der Anwendung ab. Wenn "keine neuen Informationen" eine Behauptung von Tatsachen darstellt, die für Ihre Anwendung wichtig ist (z. "Keine" Verbindung stillgelegt ". Das bedeutet eine explizite Nachricht.

Wie oft sollten Sie es senden?

Das hängt von einem Gleichgewicht der Dinge ab. 1a) Wie oft erhalten Sie normalerweise Updates? 1b) Welche Latenz ist akzeptabel/normal (z. B. wenn dies Teil eines Prozesses ist, dauern andere Schritte typischerweise Stunden, dann können 5-10 Minuten akzeptabel sein). 2a) Batterie und 2b) Datenverbrauch aufgrund des Herzschlags. Ich vermute, dass die Auswirkung auf Batterie/Strom von entscheidender Bedeutung ist, aber all dies muss sorgfältig und ausgewogen betrachtet werden.

Sie könnten doch immer doch die Deckung verlieren (Tunnel usw.). Ich würde den Herzschlag nur dann ausführen, wenn Sie nach etwas zwischen 0,5 und dem 5 -fachen des durchschnittlichen Update -Intervalls keine Aktualisierungen hätten. Wenn Sie also 2 Updates pro Minute erwarten, führen Sie Herzschläge aus, wenn Sie 15 Sekunden lang bis 3 Minuten im Leerlauf sind - beurteilen Sie, was am besten ist. Vorausgesetzt, der Benutzer befindet sich in der App "Live" und "schaltet es aus", wenn es fertig ist, ist die Akkulaufzeit kein solches Problem, da er es ohnehin benutzt. Die Akkulaufzeit ist wirklich ein Problem, wenn Sie das Gerät aufwachen, um die Updates zu verarbeiten.