Referenzarchitektur TCP-Messaging gesucht

(24.10.2019 17:41 )Achim schrieb:  Folgender Anwendungsfall:
- Eine LabVIEW-Anwendung und ein separater (Leit-) Rechner sollen Daten austauschen
- Der Leitrechner hat einen Testsequenzer inkl. DB-Kommunikation laufen, implementiert mit C#
- Der Leitrechner sendet an die LabVIEW-Anwendung (die auf einem Embedded-Win 10-PXI-Controller läuft) diverse Kommandos, mit denen Messaufgaben (Strom, Spannung, DIO, etc.) an einem angeschlossenen Prüfling angestoßen werden.
- Die LV-Anwendung erfasst die Daten und hält diese, und "irgendwann" fragt der Leitrechner die Ergebnisse ab.
- Der Leitrechner fragt außerdem zyklisch den aktuellen Status der PXI-Messmaschine ab (z.B. "Schutzhaube geschlossen", "Kontaktierung gesteckt", etc.)

Wir haben zwischen Leitrechner und PXI-Chassis eine Ethernet/TCP-Verbindung aufgebaut, ein passendes Kommunikationsprotokoll haben wir uns selber ausgedacht und implementiert.

Prinzipiell funktioniert die Kommunikation auch, allerdings haben wir immer wieder SEHR lange Antwortzeiten bzw. kann immer wieder die Kommunikation nicht aufgebaut werden, nach einem Retry funktioniert das dann. Ab und zu setzt die Kommunikation auch komplett aus, dann hilft es nur noch, die LV-Anwendung zu schließen und neu zu starten.

Leider habe ich bisher noch nirgends ein "Referenzbeispiel" gefunden, welches den korrekten Aufbau einer solchen Kommunikation veranschaulicht. Die LV-Beispiele, z.B. "Simple TCP", zeigen im Prinzip immer den Aufbau eine persistenten Verbindung zwischen zwei LV-VIs auf einem gemeinsamen Rechner, auf dem "ich" die Partner sozusagen beide "in der Hand" habe und irgendwie auf Fehler reagieren kann.

Nach meiner Kenntnis ist es aber "in echt", d.h. z.B. bei Internet-Verbindungen so, dass irgendwo ein Server steht, der auf ankommende Anfragen reagiert und eine Verbindung mit einem Client aufbaut. Dann werden "kurz" Daten ausgetauscht und die Verbindung wird (zur Schonung von Resourcen) wieder geschlossen.

Genau das haben wir auch versucht, das angehängte Bild zeigt einen Ausschnitt aus unserer Anwendung
- Wir haben einen (zu unsererer eigentlichen Anwendung) parallelen asynchronen Prozess
- In diesem Prozess sind wir der Server und lauschen wir auf Anfragen ("TCP Listen"), und wenn eine Connection zustande kommt, lesen wir (aktuell) 10 Bytes
- Diese werden verarbeitet und eine Antwort wird zurückgeschickt (ACK, OK, ERR, etc., ggf. mit zugehörigen Daten)
- Danach schließen wir die Connection (erst mal) nicht, weil man ja nicht weiß, wann die Gegenstelle (Leitrechner = Client)

Moin Achim,

eine fertige Architektur habe ich aktuell nicht zur Hand, habe aber mit den TCP-VIs bislang keine so schlechten Erfahrungen gemacht.

Was mir aber bei Deinem Posting auffällt: Du baust prozessbezogen zu bestimmten Zeitpunkten Verbindungen auf Deinen LV-Server auf, um Messbefehle zu senden. Zusätzlich werden periodisch Status-Daten abgefragt. Ich vermute, dass hierin schon der Grund für die von Dir erlebten Hänger steckt: Euer Server ist nur darauf angelegt, *eine* Verbindung zu handhaben. Wenn gleichzeitig nun eine zweite Anfrage kommt, läuft diese in einen Timeout, weil der Server die zusätzliche Verbindung nicht annehmen kann.

Schau Dir dazu mal https://labviewcoder.com/2017/07/10/an-a...n-labview/ an -- da wird für jede Anfrage ein neuer Handler gestartet. Dieser könnte dann über andere Kommunikationsmechanismen je nach Befehl bzw. Anfrage Deine Messungen konfigurieren oder Statusdaten auslesen und zurückschicken.

Zum Thema 'Verbindung Schließen': Wenn keine hohen Übertragungsraten ein Offenhalten der Verbindung sinnvoll werden lässt, würde ich ebenfalls nach jedem Kommunikationsende die Verbindung terminieren. Mit den asynchronen Handlern von oben wäre das einfach so, dass nach Beantworten der Client-Anfrage der Handler die Verbindung (und dann sich selbst) beendet und so aus dem Speicher wirft.

HTH,
Sebastian