Ein Server, mehrere Clients, geht das?

' schrieb:Kannst du mir ein Beispiel deines Pub/Subs geben? Ich persönlich finde dieses Pattern sehr interessant und werde wahrscheinlich alle meine mittlere und große Projekte damit machen. Insbesondere weil alles zentral abläuft alles sehr übersichtlich ist und deshalb gut debugfähig.

was sind Pub/Subs? <blond guck>

damit ich dir die VIs zeigen kann müsste ich die aus den Projekten rausziehen, aber da ist eine NDA drauf => keine gute Idee und "veröffentlichbar" nachprogrammieren .... hmmm ... keeene zeit, keene lust

aber ich versuchs mal zu erklären:

in meinem Server VI gibts mehr oder weniger 2 parallele Schleifen.
Die eine wartet ständig auf eine eingehende Verbindung, nimmt diese an und startet dynamisch - wenn was reingekommen ist - ein reentrantes VI, das nenn ich mal "Client VI". Die zweite Schleife im Server ist eine queued state machine, die quasi "die Arbeit verrichtet".

Jedes Client VI erzeugt bei seinem Start eine eigene Queue und hat eine "mini Statemachine". Damit das Client VI möglichst klein ist und wenig Ressourcen benötigt, besteht das VI mehr oder weniger nur aus ein paar Queue und TCP funktionen.

Der "Trick" dabei ist, die "Arbeit" vom Server verrichten zu lassen, und das Senden und Empfangen über TCP durch die "Client VIs". Das ist wichtig, damit sich verschiedene Clients nicht gegenseitig blocken können, z.B. wenn der Versand von Daten bei einer Anfrage an den Server mal was länger dauert oder so.

Wenn das Client VI eine Anfrage vom Client empfängt, dann wird diese geparst und in die Queue der StateMachine des MainVIs geschoben. Neben dem Befehl und den Daten bekommt das MainVI noch die Queue Referenz von der Q des jeweiligen Client VIs, wo nach dem Abarbeiten die "Antwort des Servers" reingeschoben wird. Das Client VI kümmert sich dann wieder darum, dass die Daten verschickt werden.

Ein paar Erfahrungen, die ich dabei gesammelt habe:
Es ist sinnvoll im Client VI eine Art Timeout zu implementieren, z.B. max. Lebensdauer des VIs - wenn keine Datenübertragung stattfindet - von 10 minuten => das hält den Speicher frei
Ich hab eine "ClientID" eingeführt, das war im Prinzip einfach eine Old Style Global, die bei jedem Start eines Clients VIs hochgezählt wurde. Die ID hab ich bei der Übergabe der Anfrage an die MainQ mitgeschickt, das ist ganz praktisch beim Debuggen, dann weiß man gleich, von welchem Client das stammt
die TCP/IP kommunikation hab ich nach dem Prinzip: vorweg 4 Byte, danach die Daten aufgebaut, wie im Example findert. Das ist die einfachste Methode dem Server mitzuteilen, wieviel Daten man denn nun tatsächlich schickt.
Für die Server-Anfragen (="Befehle") hab ich einen Cluster aufgebaut, aus einem Enum, und einem String, in den ich die Daten flatte ...