Wie man einen TCP/IP-Socket zuverlässig mit AT-Befehlen löscht und wieder verbindet

Question

Ich habe ein Problem, das ich fast gelöst habe, bin aber am "letzten Bein" festgefahren. Ich habe jetzt seit ein paar Tagen daran gearbeitet, und obwohl ich Durchbrüche hatte, fühle ich mich bin immer noch ein Weg aus einer praktikablen Lösung - aufgrund einiger toter Flecken.

Ich habe eine eingebettete, mobile Firmware-Anwendung (die ich nicht direkt bearbeiten kann), die Probleme hat Verbindung zu unserem Server über TCP/IP/UMTS/GSM. Die Firmware verwendet AT-Befehle nur zum Initiieren und steuern die Verbindung über ein Modem. Die ursprüngliche Version unseres Produkts war in der Produktion seit etwa 10 Jahren, aber eine "neue" Version der Hardware ist mit zeitweiligen Problemen.

Es gibt viele Variablen, aber ich habe alle außer einem ausgeschlossen: der Modem-Chip.

• Wir haben neue Versionen der Firmware mit verschiedenen Änderungen, aber umfangreichen A/B Tests haben gezeigt, alle Firmware das gleiche Problem erlebt, so habe ich es ausgeschlossen.
• Wir haben einen alten VB6-Server mit Winsock. Ich habe vor kurzem eine einfachere Node.js Version geschrieben, die das gleiche Problem auch fast identisch (erstaunlich) zeigt.
• Wir verwenden verschiedene Telco: Optus, Vodafone, Telstra. Wieder scheinen sie für das Problem irrelevant zu sein.
• Wir verwenden direkte Telcos oder Reseller mit einem eigenen privaten Netzwerk (APN). Wieder erwies sich als irrelevant.
• Wir haben verschiedene Hosting/Netzwerk-Installationen, aber wieder habe ich viele Konfigurationen getestet einschließlich unserer Unternehmensnetzwerk, Produktion Hosting, AWS dev EC2s und sie alle ziemlich genau das gleiche.
• Wir haben auch automatisierte Tests mit emulierten/mock-Versionen der Hardware/Firmware , die die verschiedenen Server und Netzwerke gezeigt hat scheint alles gut und ähnlich zu funktionieren.
• Die letzte Variante, die signifikante - tatsächlich absolute - Differenz zeigt, ist zwischen dem Telit UC864 Modem und dem HE910. Das ehemalige, ältere Modem funktioniert einwandfrei, aber das neuere HE910 erfährt das Problem immer. Ich habe alle möglichen Permutationen getestet, und das Problem folgt dem HE910.

Natürlich habe ich gelesen, endlos die Telit-Dokumentation (speziell „Easy IP“ und den AT-Befehl und Software-Referenzen), kann aber nicht viel beworbenen Unterschied zwischen den beiden Produkten sehen. Der HE910 ist in einem physischen Paket von Glynn, aber ich glaube nicht, dass sein Verhalten beeinflusst.

Das Problem:

Unsere Firmware-Anwendung auf einer bestimmten Port/Adresse an unseren Server verbindet. Der Server initiiert ein ausgehendes Anwendungsprotokoll, auf das die Firmware antworten muss. (So ​​wirklich die Firmware ist der "Server", aber das ist egal.) Es ist sehr leicht und einfach, in der Größenordnung von 10s Bytes pro Befehl/Antwort.

Das Problem tritt auf, wenn die Firmware aufgrund eines Ereignisses eine Verbindung zu einer vorhandenen Socket-Verbindung herstellt.Die Firmware folgt immer dem gleichen Prozess: teardown, configure, verbinden - unabhängig davon, ob es eine bestehende Verbindung gibt (dies ist wegen der Vagheit von "connected" auf TCP und 3G, ist es am besten, entweder "versuchen, Daten zu senden" oder erneut verbinden, um eine Verbindung herzustellen). Wie gesagt, ich kann dieses Verhalten in der F/W nicht ändern.

Die Verbindungsschritte sind:

1. a) Sockel Teardown AT # SH b) Warten 1s
2. Konfigurieren der PDP-Kontext AT + CGDCONT
3. Konfigurieren von TCP/IP-Stack: AT # SCFG
4. aktivieren Sie den PDP-Kontext: AT # SGACT
5. Connect TCP/IP mit dem Server: AT # SD

(Sie könnten fragen, warum die Konfigurationsschritte 2,3,4 durchgeführt werden, jede Verbindung: weil sie über unser Anwendungsprotokoll aktualisiert werden können. Aber normalerweise sind die Einstellungen konstant.)

Das Problem, das uns begegnet, ist manchmal die Geräte verbinden, aber nicht kommunizieren können. Die Verbindungen scheinen "festgefahren" - manchmal kommen ein paar Bytes durch, manchmal ein ganzer Befehls/Antwort-Zyklus, aber oft gar nichts. Beim Verbindungsaufbau sind etwa 10 Befehle normalerweise , und wenn sie ausfallen, trennt der Server die Verbindung.

Was ich bisher gefunden:

ich ein Protokoll-Analysator verwendet haben, um festzustellen, was falsch läuft: es ist, weil das TCP FIN Prozess des SH AT # wird mit dem TCP-SYN-Handshake der nächsten überlappende Verbindung initiiert mit dem AT # SD. Dies scheint auf verspätete finale FIN-ACK-Pakete zurückzuführen zu sein, die spät ankommen - nachdem die nächste Verbindung initiiert wurde.

In der Spur unter Sie Rahmen 8799 kommt zu spät, als ACK zu 8788 sehen können, aber es kommt out-of-Sequenz in der Mitte des nächsten SYN-ACK-Handshake!

Danach ist das Modem grundsätzlich "kaputt". Alle nachfolgenden Verbindungen erfahren Payload-Paketverlust, mit vielen ReTransmits und beide Seiten senden ihre Payload-Pakete, als ob sie die Payload ACKs nicht erhalten.

Nach Schritt 1. (AT # SH) gibt es eine 1 Sekunde Pause in der F/W. Wir haben dies aufgrund der Probleme bei der ersten Installation des HE910 hinzugefügt (Ich weiß, es ist ein Kludge, aber es war mehr , um die Datenbank-Latenz in unserem Server-Status als für TCP/IP aufzunehmen). Es scheint jedoch diese 1s Verzögerung hat nicht einmal Auswirkungen auf den TPC-Verkehr, wie Sie aus der Spur unten sehen können. Der ATSH "verursacht" Frame 8786 bei 17: 16: 51,585, und der ATSD "verursacht" das SYN bei Frame 8792 bei 17: 16: 51,595, aber es sind nur 10ms zwischen ihnen. Ich habe die Firmware untersucht und kann bestätigen, die 1s Verzögerung Code sieht richtig aus, und die Firmware im Terminal zu beobachten - es ist eine 1 Sekunde Verzögerung zwischen dem Debug-Ausgang dieser Schritte - aber TCP erzählt eine andere Geschichte.

Ich kann AT-Befehl in der Firmware, in einer begrenzten Art und Weise senden - nur eine alle fünf Sekunden Befehl, die offensichtlich manuelle Tests zu schön langsam skews.Wenn ich +++, AT # SH während Verbindung A, dann trigger das Verbindungsereignis senden, wird das Gerät erfolgreich verbinden. Das ist faszinierend, da Schritt 1 der Verbindung sowieso eine AT # SH durchführt. So kann ich eines von zwei Dingen schließen: Entweder müssen wir eine AT # SH "früher" (d. H. warten länger vor der Verbindung mit AT # SD) senden, oder senden Sie zwei von ihnen (weniger wahrscheinlich).

Ich verstehe, dass dies ein Bereich der häufigsten Probleme in Anwendungen ist. Sogar in der Wikipedia-Seite auf TCP/IP erwähnt es die Risiken von Anwendungen brechen das OSI-Modell und fallen Foul des TCP Teardown Handshake, wenn für die Anwendung Sitzung Sitzung beendet verwendet. Ich würde gerne ein schönes "Auf Wiedersehen" zu unserem unserer Anwendung Protokoll hinzufügen, aber das ist keine praktikable Option auf mittlere Sicht ... Ich möchte unsere beiden Modems TCP-Stacks ausgerichtet bekommen.

Der Server öffnet einen neuen Socket für die eingehende Verbindung, auf der gleichen IP/Port Kombination. Der Knoten und der VB erstellen beide eine neue Socket-Ressource von einem hörenden übergeordneten Port, also bin ich ziemlich sicher, dass am Serverende nichts "wiederverwendet" wird (es war ein Verdacht). Leider habe ich eingeschränkte Sicht in den TCP-Stack des Modems, nur mit AT # SI und SO , die grundlegende und scheinbar nicht-Echtzeit-Informationen geben. z.B. Wenn der Socket auf dem Server-Ende geschlossen ist, zeigt AT # SO immer noch die IP/Port lokal auf dem Modem, wie es der FIN teardown nicht erhalten hat.

Bei einem Neustart kann das Gerät erfolgreich viermal "neu verbinden", bis der "Jam" passiert. Dies ist seltsam zuverlässig für 4 + -1 Verbindungen. Es kann auch zurückgesetzt werden durch einige Stunden warten. Es fühlt sich also so an, als wäre das Modem nervös. (Nochmals, ich hatte den Verdacht, dass unser Telco unsere Verbindungen "limitierte", aber Cross-Telco-Tests sind einfach zu ähnlich. Und in der Produktion haben wir Tausende von diesen Geräten und nur einer von ihnen kann dieses Verhalten auslösen statistisch nicht wahrscheinlich, dass sie konnte „Bekanntmachung“ vier Verbindungen innerhalb der Hunderte von anderen?)

das letzte Stück des Verhaltens ist, wenn die Verbindung „eingeklemmt“ ist, dh Daten nicht sendet, empfängt der Server eine RST (ECONNRESET in Knoten , nur ein Fehler in VB) nach 30-60s. (Nur wenn wir unsere schnellere Verbindungsauflösung auf Anwendungsebene deaktivieren, so ging dies für lange Zeit unbemerkt ). Nach diesem Reset zeigt AT # SO immer noch als verbunden (mit einer IP), so wieder zuerst fühlte ich, dass es einige 3G/AP/Gateway die Verbindung in der Mitte, aber nicht sagen dem Client. Aber aufgrund der Konsistenz des Problems über Telcos und Netzwerke, ich jetzt finden dies schwer zu glauben, und nur denke, die Antworten sind nicht "auf dem neuesten Stand" mit der Realität.

Dieses typische TCP-Trace zeigt (meine Interpretation so weit, die nicht richtig sein könnte)

• Anschluss A, Syn/Ack OK
• Unsere App-Protokoll startet und beendet am Rahmen 8197 17.16: 01
• dann ein Ereignis eintritt, die eine weitere Verbindung B
• Erster Schritt 1. versucht, Teardown einleitet, Frame 8786 startet das FIN-Handshake
• Die Teardown erhält 8788 17.16.51 umrahmen.58
• Dann wird die nächste Verbindung B beginnt am Rahmen 8792 17: 16: 51.59
• Das geht in Ordnung, bis mit dem letzten Fin Ack von Verbindung A bei Frame 8799 unterbrochen (vielleicht ist dies ignoriert?)
• Die Anwendung Protokoll versucht, wieder zu beginnen, aber die ersten 13 Byte Meldung nicht ACKed erhalten und wird oft ...
• Unser Server sendet den ersten Befehl, eine Verdoppelung der Puffergröße im Rahmen 8978
• Unser Server Timeout neu übertragen und löscht die Verbindung und sendet eine Fin bei 9016

Trace

Frame TIME    REL TIME SOURCE   DEST SEQ ACK  FLAGS  WINDOW PAYLOAD BYTES  

8003 17:15:55.9409634 703.7329764 CLIENT_IP SERVER_IP 0 0 (0x0) ......S. 65000 0 Flags=......S., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432024, Ack=0, Win=65000 () = 65000 vb6.exe 
8004 17:15:55.9410316 0.0000682 SERVER_IP CLIENT_IP 0 1  ...A..S. 8192 0 Flags=...A..S., SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387462, Ack=316432025, Win=8192 (Scale factor not supported) = 8192 vb6.exe 
8016 17:15:58.5707216 2.6296900 CLIENT_IP SERVER_IP 1 1  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432025, Ack=319387463, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8037 17:15:58.8632583 0.2925367 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 Flags=...AP..., SrcPort=50008, DstPort=17790, PayloadLen=13, Seq=319387463 - 319387476, Ack=316432025, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8039 17:15:59.0105830 0.1473247 CLIENT_IP SERVER_IP 1 14  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432025, Ack=319387476, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8041 17:15:59.1006112 0.0900282 CLIENT_IP SERVER_IP 1 - 7 14 ...AP... 65000 6 Flags=...AP..., SrcPort=17790, DstPort=50008, PayloadLen=6, Seq=316432025 - 316432031, Ack=319387476, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8068 17:15:59.2997681 0.1991569 SERVER_IP CLIENT_IP 14 7  ...A.... 64994 0 Flags=...A...., SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387476, Ack=316432031, Win=64994 (scale factor 0x0) = 64994 vb6.exe 
8071 17:15:59.3590861 0.0593180 SERVER_IP CLIENT_IP 14 - 19 7 ...AP... 64994 5 Flags=...AP..., SrcPort=50008, DstPort=17790, PayloadLen=5, Seq=319387476 - 319387481, Ack=316432031, Win=64994 (scale factor 0x0) = 64994 vb6.exe 
8076 17:15:59.5106103 0.1515242 CLIENT_IP SERVER_IP 7 19  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432031, Ack=319387481, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8078 17:15:59.6005478 0.0899375 CLIENT_IP SERVER_IP 7 - 28 19 ...AP... 65000 21 Flags=...AP..., SrcPort=17790, DstPort=50008, PayloadLen=21, Seq=316432031 - 316432052, Ack=319387481, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8100 17:15:59.7989459 0.1983981 SERVER_IP CLIENT_IP 19 28  ...A.... 64973 0 Flags=...A...., SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387481, Ack=316432052, Win=64973 (scale factor 0x0) = 64973 vb6.exe 
8110 17:15:59.9164691 0.1175232 SERVER_IP CLIENT_IP 19 - 37 28 ...AP... 64973 18 Flags=...AP..., SrcPort=50008, DstPort=17790, PayloadLen=18, Seq=319387481 - 319387499, Ack=316432052, Win=64973 (scale factor 0x0) = 64973 vb6.exe 
8114 17:16:00.0005725 0.0841034 CLIENT_IP SERVER_IP 28 37  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432052, Ack=319387499, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8120 17:16:00.2005077 0.1999352 CLIENT_IP SERVER_IP 28 - 34 37 ...AP... 65000 6 Flags=...AP..., SrcPort=17790, DstPort=50008, PayloadLen=6, Seq=316432052 - 316432058, Ack=319387499, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8127 17:16:00.2509607 0.0504530 SERVER_IP CLIENT_IP 37 - 42 34 ...AP... 64967 5 Flags=...AP..., SrcPort=50008, DstPort=17790, PayloadLen=5, Seq=319387499 - 319387504, Ack=316432058, Win=64967 (scale factor 0x0) = 64967 vb6.exe 
8131 17:16:00.5004721 0.2495114 CLIENT_IP SERVER_IP 34 42  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432058, Ack=319387504, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8132 17:16:00.5004721 0.0000000 CLIENT_IP SERVER_IP 34 - 43 42 ...AP... 65000 9 Flags=...AP..., SrcPort=17790, DstPort=50008, PayloadLen=9, Seq=316432058 - 316432067, Ack=319387504, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8160 17:16:00.6603237 0.1598516 SERVER_IP CLIENT_IP 42 - 49 43 ...AP... 64958 7 Flags=...AP..., SrcPort=50008, DstPort=17790, PayloadLen=7, Seq=319387504 - 319387511, Ack=316432067, Win=64958 (scale factor 0x0) = 64958 vb6.exe 
8162 17:16:00.7505392 0.0902155 CLIENT_IP SERVER_IP 43 49  ...A.... 65000 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432067, Ack=319387511, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8168 17:16:00.9005226 0.1499834 CLIENT_IP SERVER_IP 43 - 55 49 ...AP... 65000 12 Flags=...AP..., SrcPort=17790, DstPort=50008, PayloadLen=12, Seq=316432067 - 316432079, Ack=319387511, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8197 17:16:01.1093181 0.2087955 SERVER_IP CLIENT_IP 49 55  ...A.... 64946 0 Flags=...A...., SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387511, Ack=316432079, Win=64946 (scale factor 0x0) = 64946 vb6.exe 
8786 17:16:51.5853712 50.4760531 CLIENT_IP SERVER_IP 55 49  ...A...F 65000 0 Flags=...A...F, SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432079, Ack=319387511, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8787 17:16:51.5854172 0.0000460 SERVER_IP CLIENT_IP 49 56  ...A.... 64946 0 Flags=...A...., SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387511, Ack=316432080, Win=64946 (scale factor 0x0) = 64946 vb6.exe 
8788 17:16:51.5860033 0.0005861 SERVER_IP CLIENT_IP 49 56  ...A...F 64946 0 Flags=...A...F, SrcPort=50008, DstPort=17790, PayloadLen=0, Seq=319387511, Ack=316432080, Win=64946 (scale factor 0x0) = 64946 vb6.exe 
8792 17:16:51.5954781 0.0094748 CLIENT_IP SERVER_IP 0 0 (0x0) ......S. 65000 0 Flags=......S., SrcPort=39522, DstPort=50008, PayloadLen=0, Seq=1817440308, Ack=0, Win=65000 () = 65000 vb6.exe 
8793 17:16:51.5955252 0.0000471 SERVER_IP CLIENT_IP 0 1  ...A..S. 8192 0 Flags=...A..S., SrcPort=50008, DstPort=39522, PayloadLen=0, Seq=4287314964, Ack=1817440309, Win=8192 (Scale factor not supported) = 8192 vb6.exe 
8799 17:16:51.7152606 0.1197354 CLIENT_IP SERVER_IP 56 50  ...A.... 64999 0 Flags=...A...., SrcPort=17790, DstPort=50008, PayloadLen=0, Seq=316432080, Ack=319387512, Win=64999 (scale factor 0x0) = 64999 vb6.exe 
8801 17:16:51.7351969 0.0199363 CLIENT_IP SERVER_IP 1 1  ...A.... 65000 0 Flags=...A...., SrcPort=39522, DstPort=50008, PayloadLen=0, Seq=1817440309, Ack=4287314965, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8821 17:16:52.0333514 0.2981545 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8846 17:16:52.4579548 0.4246034 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8855 17:16:53.3003681 0.8424133 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8875 17:16:54.9852348 1.6848667 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8890 17:16:56.6729734 1.6877386 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8909 17:16:58.3734032 1.7004298 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8921 17:17:01.7429692 3.3695660 SERVER_IP CLIENT_IP 1 - 14 1 ...AP... 65000 13 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=13, Seq=4287314965 - 4287314978, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
8978 17:17:08.4665817 6.7236125 SERVER_IP CLIENT_IP 1 - 27 1 ...AP... 65000 26 [ReTransmit #8821]Flags=...AP..., SrcPort=50008, DstPort=39522, PayloadLen=26, Seq=4287314965 - 4287314991, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 
9016 17:17:12.2738575 3.8072758 SERVER_IP CLIENT_IP 27 1  ...A...F 65000 0 Flags=...A...F, SrcPort=50008, DstPort=39522, PayloadLen=0, Seq=4287314991, Ack=1817440309, Win=65000 (scale factor 0x0) = 65000 vb6.exe 

Beobachtungen (mit begrenztem TCP Wissen)

• All Daten und Fin-Pakete haben ihre Ack-Bit gesetzt - was für mich ungewöhnlich aussieht.
• Der Fin Handshake ist ein Vier-Wege, aber sieht aus wie der Server versucht eine Drei-Wege-, einschließlich einer Fin in der Ack des Clients Fin. Vielleicht ist dies aufgrund der oben genannten, aber vielleicht verursacht dies ein Problem, wo das Modem eine vier-Wege-Teardown tut, aber der Server versucht, eine Drei-Wege-Teardown zu tun? Aber es sendet auch einen eigenständigen Ack.
• Ich verstehe nicht, wie die ReTransmit so schnell passiert? Frame 8846 17: 16: 52,45 wird nur 420ms nach dem Original gesendet. Sicher ist das nicht lang genug, um ein ACK Timeout zu erhalten? Vermisse ich vielleicht einen zugrunde liegenden IP-Fehler Antwortpaket, weil ich nur TCP-Ebene verfolgen? Sonst wie wusste er wieder zu übertragen?

Also endlich - meine Frage.

Wie kann ich, rein mit AT-Befehlen, zuverlässig eine TCP/IP-Socket-Teardown und etablieren eine neue Verbindung auf einem neuen Sockel mit dem gleichen Port/IP ohne Chance auf eine verzögerte Teardown Pakete außerhalb der Reihenfolge ankommen .

Oder genauer gesagt, wie kann ich das HE910-Modem so machen, wie die UC864 recht erfolgreich tut.

Answer 1

Um meine eigene Frage zu beantworten, habe ich es geschafft, dies zu lösen, aber nicht unbedingt die zugrunde liegende Frage zu beantworten.

Ich habe es geschafft, eine 2s Verzögerung zu der Firmware hinzugefügt (ersetzt die 1s Verzögerung beschrieben) zwischen teardown und re-connect, da es eine einfache Änderung war.

Das behebt das Verhalten vollständig und ermöglichte mir eine weitere Analyse des Timings über 20 erneute Verbindungen.

Es stellt sich heraus, dass das HE-910-Modem einen periodischen Zyklus von zwei Netzwerklatenzpegeln aufweist. Es wechselt alle paar Minuten in 900ms und 1.200ms ab. Dies bedeutet, dass die ersten paar Verbindungen (die ich alle 30s machen kann) mit einer 1s Verzögerung im Code gelingen werden, aber wenn es zu der 1,2s Verzögerung kommt, verschütten die FIN-ACK Pakete in die nächste Verbindung.

Dieser Graph zeigt den „Abstand“ in der Zeit zwischen der FIN/ACK-Sequenz und dem nächsten SYN/ACK-Handshake, wenn es eine Verzögerung zwischen dem 2s ATSH Befehl und dem Befehl ATSD ist. Es hat eindeutig eine periodische Variation, die es gelegentlich über den Rand der 1s Pause bringt.

So stellt sich heraus, dass meine vorherige Kludis von 1s Verzögerung war nur arbeiten. Längere Tests vor einem Jahr hätten dies gezeigt.

Während also die 2s-Verzögerung nur ein längerer Kludn ist, scheint es genug Spielraum zu geben, um sicher zu sein. Ich mache ein weiteres Benchmarking, um zu sehen, ob wir jemals eine 2s-Latenz riskieren könnten.

Es ist möglich, dass dies die "Delayed ACK" -Funktion einiger TCP/IP-Stacks ist, aber 1.2s scheint extrem lang. Das Modem verfügt nicht über einen Befehl zum Steuern der Option TCP_NODELAY, so dass ich es nicht testen kann.

Es scheint auch der Befehl AT # SH ist asynchron, in dem das OK zurückgegeben wird, bevor die Teardown startet sogar. Andernfalls würde das anfängliche FIN immer um 1s oder 2s versetzt sein, während in der obigen Grafik sowohl FIN als auch ACK um 0,8 ms plus die Zeit dazwischen verzögert sind.

Ich werde auch die UC864 mit der 2s Firmware benchmarken, um die gleiche Grafik zu erhalten, die mehr Licht auf die zugrunde liegende Ursache werfen sollte.