Sehr seltsame Trennungen mit TCP Sockets

Kurz gesagt: Der Server ruft :: send () erfolgreich auf, aber die Daten gehen nicht auf dem Kabel aus. Der Client sendet seinen Quit-Befehl nach einigen Sekunden, weil er nichts empfängt und dieser Befehl vom Server korrekt empfangen wird.

Im Detail: Der Server sendet jeden 1/10 Sekunden einen Befehl an seine Clients und einen Herzschlag pro Sekunde. Die Clients geben nur eine Bestätigung für den Herzschlag zurück. Wir haben die Server-Anwendung modifiziert, um jeden gesendeten und empfangenen Befehl zu protokollieren, und wir haben den Verkehr des PCs mit Wireshark aufgezeichnet. Wir können jeden protokollierten Befehl mit einem TCP-Paket abgleichen, bis das Problem auftritt. Das Problem betrifft jeweils nur einen Client. Die Daten fließen weiterhin normal mit den anderen Clients. Die Verbindung funktioniert in der Regel einige Minuten, bevor Sie in Schwierigkeiten geraten. Die Verbindung sollte von dem Moment an funktionieren, in dem der Client bootet, bis er geschlossen wird (dh Tage).

Wenn das Problem auftritt, enthält die Protokolldatei die erwarteten Befehle, aber der Wireshark-Dump enthält nichts. Das Bild unten zeigt den Verkehr mit einem Kunden. Die rote Linie ist, wenn der Verkehr anhält, aber der Server weiterhin erfolgreich :: send () aufruft. Nach ca. 4 sec. bricht das Client-Timeout ab und es schließt die Verbindung. Es sendet einen Beendigungsbefehl und der Server empfängt es normal.

Was mich noch mehr verwirrt ist, dass das Paket, das den Befehl quit enthält, nicht mit einem TCP-ACK-Paket bestätigt wird. Es ist so, als wäre die TCP-Verbindung auf der Senderseite vollständig gestaut. Die Neuübertragung ist ein Effekt dieses Staus, aber selbst das TCP-SYN, um eine neue Verbindung herzustellen, wird nicht korrekt verarbeitet und erhält kein einfaches TCP-ACK.

Nach ungefähr 30 Sekunden verschwindet das Problem und das SYN-Paket wird schließlich akzeptiert und die Kommunikation wird mit der neuen Verbindung fortgesetzt.

Dies wurde auf verschiedenen Windows-Versionen getestet. Während der Tests wurde eine Remotedesktopsitzung verwendet, und die Verbindung wurde nie durch dasselbe Problem getrennt. Es bleibt stundenlang ohne Probleme verbunden. Wenn der Client eine drahtlose Brücke passiert, tritt das Problem häufiger auf. Wir haben Wireshark auf beiden Seiten des drahtlosen Endpunkts verwendet und wir sehen keine erneute Übertragung oder Paketverlust, der eine höhere Unterbrechungsrate erklären kann.

Wenn viele Clients an dieselbe Bridge angeschlossen sind, schlagen sie nicht gleichzeitig fehl. Nur eins nach dem anderen. Funkstörungen scheinen also keine Erklärung zu sein. Wir können einige Übertragungen in der Wireshark-Deponie sehen, aber die Kommunikation wird wie gewohnt fortgesetzt und es findet keine erneute Übertragung statt, bevor das Problem auftritt. Ein Zugangspunkt ist mit dem Schalter des Servers verbunden. Der Client-PC und der Server-PC verwenden keine drahtlose Netzwerkkarte.

Lange Zeit haben wir die gelegentliche Unterbrechung durch das Netzwerk verhindert, aber immer mehr Installationen sind drahtlos und die Unterbrechungen sind jetzt so häufig, dass sie den Benutzern Probleme bereiten.

Wir haben es mit und ohne aktivierte Windows Firewall versucht. Wir haben die Port-Ausnahme hinzugefügt, auch wenn die Firewall deaktiviert ist. Weder der Client noch der Server verfügen über einen Antivirus.