Referenzarchitektur TCP-Messaging gesucht

Hallo zusammen,
danke schon mal für eure Antworten. Ich bin nicht gleich dazu gekommen, weiterzumachen bzw. zu antworten. Aber jetzt....

@ Sebastian:
Dein Tipp mit den zwei Servern war vermutlich die Lösung, abschließend will ich das aber noch nicht beantworten.

@ Jörg:
Die "vielen vielen Listener" waren nur EIN Versuch unter diversen Varianten, quasi aus Verzweiflung


@ all:

Ich habe es jetzt ein wenig anders aufgebaut. Das "Komfort-VI" "TCP Listen.vi" ist rausgeflogen. Dieses soll eigentlich dafür sorgen, schon aktive Listener (+ zugewiesenem Port) intern zu puffern (bzw. in einer Art Mini-"Datenbank" zu cachen), und damit verhindern, dass bei nicht zustande gekommerer Connection ein neuer Listener aufgemacht und der alte verworfen würde. Irgenwie hat das nicht geklappt, evtl. aufgrund der zeitlich asynchronen Anfragen.

Ich verwende jetzt zwei verschiedene Ports, je einen für STATUS-Abfragen und einen für CMD-Anweisungen an meinen Messrechner. Beide Listener werden initial mit "TCP Create Listener.vi" erzeugt und dann wird immer auf eine Anfrage gewartet, siehe folgendes Bild:
   
Am Ende der Kommunikation wird die Connection einfach geschlossen. (Mit "netstat" kann man sehen, dass die geschlossenen Verbindungen vom Betriebssystem noch eine kleine Weile im "wait"-Zustand gehalten werden, und irgendwann verschwinden.)

Seither läuft die ganze Sache eigenlich problemlos, hin und wieder muss der Leitrechner ein Retry aufgrund fehlender Antwort machen...aber das ist ein Fehler, der quasi nicht aufzuspüren ist, weil er nicht zu reproduzieren und extrem selten ist. Wir konnten nicht soooo viel testen, im Dauerbetrieb muss man mal schauen. Bisher haben wir pro Tag vielleicht maximal zehn komplette Durchläufe (mit je ca. 12 Minuten Gesamt-Testzeit) gemacht, und da ist der Retry 1-2 mal aufgetaucht.

Mal abwarten...

Vielen Dank noch mal für euren Support!

LG
Achim