Verpasste Telegramme (3)

[Melanie Hermann]

Vereinzelt werden immer noch Telegramme verpasst. (Bisher nur beim Debug-GC.)
Es muss überprüft werden warum Telegramme verpasst werden und was dagegen unternommen werden kann.

[Melanie Hermann]

Testaufbau: GC9300-Controller + 2x GC9300-Gateway (1x Debug)
Debuggerät verpasst ab und zu ein einzelnes Telegramm. Das Releasegerät empfängt alle Telegramme ohne Lücken. Das bedeutet, dass der Fehler 100%ig nicht am Sendealgorithmus liegt. Das Problem muss im Empfangsalgorithmus gesucht werden.

[Melanie Hermann]

Debug-GC mit Gateway-Applikation verpasst weiterhin ab und zu ein Telegramm...
Mit Wireshark wurden die UDP-Telegramm mitgeschnitten. Das Telegramm, das vom Gateway verpasst wurde, tauchte im Wireshark auf. Hiermit hat sich nochmals bestätigt, dass das Problem im Empfangsalgorithmus liegt.

[Melanie Hermann]

Möglichkeiten:

• Telegramme mit weiterem kleinen Index versehen und jedes Telegramm 2-3 mal senden. Gateway kann dann auswerten ob es ein Telegramm mit dem Hauptindex bereits empfangen hat. Wenn ja, kann es die weiteren Telegramme mit dem gleichen Hauptindex verwerfen. Wenn nein, kann es eines der zusätzlich gesendeten Telegramme verwenden.
• Controller merkt sich die letzten gesendeten Telegramm (z.B. die letzten 100 Stück). Wenn ein Gateway ein Telegramm verpasst schickt es ein Telegramm an den Controller. Und der Controller kann das gewünschte Telegramm noch ein weiteres mal schicken.
• Gesamte Kommunikation nicht über UDP, sondern über TCP laufen lassen. Hier gibt es dann Problem mit verpassten Telegrammen nicht, da hier eine beidseitige Kommunikation zwischen Controller und Gateway stattfindet. Nachteil ist, dass bei dieser Variante zwischen jedem Controller und jedem Gateway eine eigene Verbindung aufgebaut werden muss. Somit muss eine Konfiguration der Gateway-Adressen im Controller vorgesehen werden.

[Melanie Hermann]

Fazit:

• UDP ist zu unsicher. Deshalb wird auf TCP und Einzelverbindung umgestellt.

[Melanie Hermann]

Änderungen:

• mtx_tab.txt, items.txt:
  • Neues Matrixelement IPAddressGCProtCtrl
  • Neues Matrixelement GcProtConnectedGWs
• gcvars.cpp:
  • chk_IPAddressGCProtCtrl(): Neue Funktion. Stellt sicher, dass hier nicht die LAN1- oder LAN2-IP-Adresse vom eigenen Gerät eingegeben wird.
  • fkt_IPAddressGCProtCtrl(): Neue Funktion. Sorgt dafür, dass IP-Adr des GCProt-Controllers in GCProt neu gesetzt wird.
• GcApp.h, GcApp.cpp:
  • SetGCProtIPAdress(): Neue Funktion. Leitet neue GCProt-IP-Adr an CGCProt weiter.
  • TcpIpChanged(): GCProt wird neugestartet, wenn sich die IP-Adresse von LAN1 geändert hat. Wird benötigt, damit Controller sein Listensocket für GCProt mit der neuen IP-Adresse neu erstellt.
• GcProt.h, GcProt.cpp:
  • Neues Flag m_doReopen.
  • SetGCProtCtrlIPAdr(): Neue Funktion. Übernimmt neue IP-Adr und initiiert Neuöffnen der Schnittstelle.
  • AcceptIncomingConnections(): Anzahl der verbundenen GWs wird mit jedem accept hochgezählt.
  • ConnectionHandler(): Anzahl der verbundenen GWs wird mit jedem close heruntergezählt. Wenn der ConnectionHandler-Thread beendet wird, wird die Anzahl der verbundenen GWs auf Null gesetzt.
  • 'DoGCProt_Controller(): Erkennt nun auch Socket_Error bei sendto(). Dies bedeutet, dass der Client den Socket bereits geschlossen hat. Dies wird nur im Diagnose-Log notiert.
    Flag m_dorun wird in Endlosschleife berücksichtigt, damit der Thread beendet werden kann.
  • DoGCProt_Gateway(): Erkennt nun auch Socket_Error bei recvfrom(). Dies bedeutet, dass der Server den Socket bereits geschlossen hat. Dies wird nur im Diagnose-Log notiert. Dann wird auch m_sockIsConnected auf false gesetzt, damit versucht wird eine neue Verbindung aufzubauen.
    Alarm GCProt-Timeout wird immer wieder gesetzt. Damit er nicht auf Dauer manuell quittiert werden kann.
  • Komplette Kommunikation von UDP auf TCP (verbindungsorientiert) umgebaut

[Melanie Hermann]

Verhalten in verschiedenen Szenarien:

• Controller fällt aus (OK)
  • Verhalten Controller: Lässt nach Neustart neue Verbindung von Gateway zu.
  • Verhalten Gateway: Meldet GCProt Timeout und zeigt Status GC-Protokoll als NOK an. Wenn GCProt Timeout-Alarm manuell quittiert wird, kommt er immer wieder. Dies kann aber ~ 20 Sekunden dauern. Wenn Controller wieder da ist, wird Verbindung wieder hergestellt und GCProt Timeout-Alarm verschwindet.

• Gateway fällt aus (OK)
  • Verhalten Controller: Erkennt, evt. erst ein paar Sekunden später, dass Socket von Client geschlossen wurde. Lässt Neuverbindung von Gateway zu.
  • Verhalten Gateway: Verbindet sich nach Neustart neu.

• Verbindung wird getrennt (Kabel unterbrochen) (OK)
  • Verhalten Controller: Benötigt ~30 Sekunden bis erkannt wurde, dass Gateway weg ist. Nach dem das Kabel wieder eingesteckt wurde, wurde Neuverbindung sofort zugelassen.
  • Verhalten Gateway: Zeigt sofort GCProt Timeout an. Als Kabel wieder eingesteckt wurde, wurde Verbindung wieder hergestellt.

• Gateway bekommt neue LAN1-IP-Adresse (OK)
  • Verhalten Controller: Erkennt, dass Socket geschlossen wurde. Und lässt dann Neuverbindung zu.
  • Verhalten Gateway: Zeigt ganz kurz GCProt Timeout an und verbindet sich dann mit seiner neuen IP-Adresse.

• Gateway bekommt neue Ctrl-IP-Adresse (OK)
  • Verhalten Controller: Senden an Gateway schlägt logischerweise fehl (Diagnose-Log). Und dann wird erkannt, dass Client nicht mehr da ist und der Socket komplett geschlossen.
  • Verhalten Gateway: Meldet GCProt Timeout.

• Controller bekommt neue LAN1-IP-Adresse (OK)
  • Verhalten Controller: Controller merkt, dass Gateway nicht mehr da ist, schließt Socket auch von seiner Seite und öffnet anschließend einen neuen Listensocket mit der neuen IP-Adresse. Sobald die IP-Adr auch im Gateway geändert wurde, wird eine Neuverbindung vom Gateway zugelassen.
  • Verhalten Gateway: Nach Änderung der IP-Adr im Ctrl zeigt das Gateway GCProt Timeout an. Sobald die IP-Adr im Gateway angepasst wurde, wird die Verbindung zum Controller wieder hergestellt.

• Controller wird normal heruntergefahren (OK)
  • Verhalten Controller: Beendet sich. Nach Neustart wird Verbindung zu Gateway wieder hergestellt.
  • Verhalten Gateway: Meldet nach kurzer Zeit GCProt Timeout. Wenn Controller wieder kommt, wird Verbindung neu aufgebaut.

• Gateway wird normal heruntergefahren (OK)
  • Verhalten Controller: Erkennt, dass Socket von Client geschlossen wurde. Lässt Neuverbindung zu, wenn Gateway neugestartet wird.
  • Verhalten Gateway: Beendet sich. Nach Neustart wird Verbindung erneut hergestellt.

[Melanie Hermann]

TODO:
Muss nun getestet werden.
Siehe #75.