Opened 11 years ago
Closed 11 years ago
#91 closed Aufgabe (fixed)
Verpasste Telegramme (3)
| Reported by: | Melanie Hermann | Owned by: | Melanie Hermann |
|---|---|---|---|
| Priority: | kurzfristig | Milestone: | |
| Component: | Gesamtsystem | Version: | |
| Severity: | Aufgabe | Keywords: | |
| Cc: |
Description
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.
Change History (11)
comment:1 by , 11 years ago
| Priority: | kurzfristig → mittelfristig |
|---|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
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.
comment:4 by , 11 years ago
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.
comment:5 by , 11 years ago
| Priority: | mittelfristig → kurzfristig |
|---|
comment:6 by , 11 years ago
Fazit:
- UDP ist zu unsicher. Deshalb wird auf TCP und Einzelverbindung umgestellt.
comment:7 by , 11 years ago
Ä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
comment:9 by , 11 years ago
Verhalten in verschiedenen Szenarien:
- Controller fällt aus
- Verhalten Controller:
- Verhalten Gateway:
- Gateway fällt aus
- Verhalten Controller:
- Verhalten Gateway:
- Verbindung wird getrennt (Kabel unterbrochen)
- Verhalten Controller:
- Verhalten Gateway:
- Gateway bekommt neue LAN1-IP-Adresse
- Verhalten Controller:
- Verhalten Gateway:
- Gateway bekommt neue Ctrl-IP-Adresse
- Verhalten Controller:
- Verhalten Gateway:
- Controller bekommt neue LAN1-IP-Adresse
- Verhalten Controller:
- Verhalten Gateway:
- Verbindung stabil, aber Controller sendet keine Daten:
- Verhalten Controller:
- Verhalten Gateway:
- Controller wird normal heruntergefahren:
- Verhalten Controller:
- Verhalten Gateway:
- Controller wird normal heruntergefahren:
- Verhalten Controller:
- Verhalten Gateway:
comment:11 by , 11 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
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.