Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

Zitat:
….positiv formuliert, ….paar Sachen umbauen musst.

Ja, das hast Du gut gemacht :-)

Ich hatte schon Helm und Sicherheitsgurte angelegt in der Annahme großer Umbrüche.
Habe alle Hoffnung fahren lassen, und mich dem Schicksal ergeben, mit dem Lied auf den Lippen „Nun fahr denn hin du schöne Welt“

Aber wie ich sehe komme ich noch mal davon.

Das was Du da entwirfst sieht gut aus und ist diskussionslos gekauft.
Die individuelle Kommunikation zwischen PC-Komponenten wäre damit auch in besten Händen.

Das Konzept smarter Clients mit Fernsteuerfähigkeiten in Modularere Bauweise sehe ich da nicht gefährdet.
Die Frage des lokalen Ereignis Manager oder Vereinstifter also das was MARV originär sein sollte müssen wir dann noch betrachten.
Das meint:
Was der Server, der ja naturbedingt sehr gut im Bilde ist lieber mit erledigen sollte.
Ob es sinnvoller ist das der Server die Schäfchen hütet und/oder auch startet und beendet.
Ist klar das ich MARV mag, aber wenn was anderes besser fürs Projekt ist wird das Bessere genommen.

Zehn mal Umschreiben habe ich ja fürs Erste versprochen ;-)

Netter Gruß

Eine Frage steht für mich noch im Raum:

Wieweit tangiert die Sache jetzt die Internetfähigkeit.
Callback und Handles hören sich nicht sehr transportfähig an.
Einmal könnte ich mir ja eine Browserbasierte Sache vorstellen.
Aber zum anderen Die Standard Clients als Verein auf einem Entfernten Rechner hinter einer Firewall.
Die einfach über…. ???????? kommunizieren.
Was mein Ideal wäre.
Oder sehe ich da was falsch?

Netter Gruß

However, konzeptionell soll sich ja eigentlich nichts ändern, ausser, daß aus den zwei Programmen MARV.EXE und RN_SERVER.EXE eines wird.
Denn sonst kommunizieren die sich blöde.

MARV verhält sich wie ein weibliches Wildschwein im Frühjahr: ("S-a-u" hat er zensiert)
Er wirft seine Ferkel hinten raus (SHELL) und wartet, daß die bei den Zitzen (connect Port 42) wieder auftauchen.

(Nicht alles, was hinkt, ist ein Vergleich)

Vielleicht gliedern wir aber die COM Port geschichte dafür aus und machen eine Client-Kategorie "Remote-Adapter" , die dann auch für anderer Remote-Geschichten herhalten kann (HTTP, SOAP, blabla)

Auch das wär dann etwas geradliniger.

Egal, step by step. Ich bau mal wieder an der DLL um und liefere ein Template.

Also, Meerschwein is angesagt.

Da ist ein IP_DLL drinnen, wie gehabt, mit ein paar Kleinigkeiten dazu.
Er kann, je nach Button, Server spielen oder Client, wie vorher.

Pikanterie: er kann auch beides gleichzeitig machen, (natürlich erst define und dann connect, logo)


Darüber hinaus noch naturbelassen, guck einfach mal rein.

Ja, habe schon reingeguckt.
Mein Gehirn hatte aber heute keine rechte Lust.
Darum bin ich mit ihm übereingekommen, dass ich das erst Morgen verstehe.

Weiter haben wir uns geeinigt die Zeit nicht zu vertrödeln, obwohl wir beide sehr müde wahren.
Darum haben wir erstmal was gemacht was relativ einfach ist und Arbeitserleichterung für die Zukunft verspricht.

Ich habe jetzt mal die Ecke an der ich arbeite zusammengestellt.

In den Programmtexten beider Projekte kannst Du sehen wie ich Dein Template einbaue.
Falls es Dir so zusagt würde ich das in diesem Stil fürs erste beibehalten wollen.
Das kann sich ändern wenn wir das möglicherweise in Klassen oder Module packen.
Bis dahin wäre es für mich zum Testen und Verwenden eine enorme Erleichterung.
Also bitte wohlwollend prüfen.
Ich habe die IP_DLL schon so zurechtgemacht das Du sie zum Weiterarbeiten nehmen könntest.
Das ist jetzt eine Option, wenn Du was anderes bereit stellst bau ich das natürlich auch ein.

Netter Gruß

Jetzt noch der Rest.
Alles mit einem mal wollte er nicht.

Netter Gruß

Bin zwar immer noch müde.
Habe aber jetzt mal die Sache ausprobiert.
Das ist ja noch mehr als ich glaubte zu brauchen.
Da bin ich ja hocherfreut über das Spielzeug.
Da muss ich erstmal richtig nachdenken was man damit alles anstellen kann :-)
Hmm…. Denk sinnnier……
Ich werde als nächstes mal sehen, dass ich das irgendwie anwende.

Netter Gruß aus den Research and Destroy Center

Short Doku I:
Beim Portdefinieren zeigt die bei "define" erzeugte "IpDef"-Referenz sozusagen auf das "Mother-Port". Ausser eventuell wieder wegschmeissen ("stop listening") kann man damit eigentlich nicht machen.

Wenn sich nun ein Client an das Port connected, wird "callback" gerufen mit dem Status=2. (Der Client kriegt da grad sein "ok" auf den Connect)
Auch damit kann man in unserem Fall nicht viel machen, da ja noch keine Message empfangen wurde.

Wenn nun der Client die erste Message wegschickt, sollte sie ja zumindest seine PID enthalten, und jetzt sollte (oder kann) der Server erst wirklich aktiv werden.
Aber da ist der Status nichtmehr = 2, sondern wieder normales "ok" (=0)

Rein technisch müßte sich ein Server diese IpRef nicht extra merken, er kriegt ja jedesmal in der Callbackroutine diesen Wert wieder mit.
Er kann auch so darauf normal senden (antworten) oder ggf. "disconnecten"


(Wird fortgesetzt)

Doku II:
Stimmen wir mal die Situation beim Starten der einzelnen Applikationen:
Es gibt eine Startliste mit Prozess/Programm Namen. wobei sie auch mehrfach gestartet werden sollen.
z.B. Eintrag "GUI e.V" Starten = 2 x
Der "SHELL" Befehl gibt ja die PID des erzeugten Prozesses zurück.
d.h. die PID des GUI e.V weiß MARV schon durch das Starten.

Jeder erzeugte GUI e.V Prozess connected sich nun mindestens einmal, möglicherweise aber auch mehrfach an das von MARV definierte Port (42)

Bei Marv taucht nun eine neue IpRef auf, die MARV ja dem richtigen Prozess zuordnen muß
Daher muß in der ersten Message von GUI e.V die PID enthalten sein. Die kann er nun bei den durch "SHELL" erzeugten Einträgen suchen und die IpRef dazu hängen.

Bei jeder weiteren Message des GUI e.V wird MARV nun die IpRef suchen (und finden), d.h. er weiß sofort, von wem die Message kommt.

Dabei sollte eine Struktur entstehen, wie im Bild angedeutet.

Sind wir soweit d'accord ?

Doku:
Ja soweit alles klar.
Ich habe noch nicht so viele mit Zeigern gearbeitet. Aber kein Problem.
Zitat:
und die IpRef dazu hängen…
das wäre jetzt ein Integer die ich im Nachrichtenstring mitschicke?

Allgemeines:
Wir wollten ja auch mal sehen ob davon nicht einige Richtung RN-Server wandert. Weil der ja besser im Bilde ist.
Und MARV eine eher Inhaltliche Rolle übernimmt die mehr mit Projekt spezifischen Fragen zu tun hat als mit Administrativen.

Und was Unterhaltsames zum Wochenende:
Rückblick von mir auf damals schwierige Zeiten:

Frr ms d Pro se krz Vrn ver dm s af d dls kl Mnt d Pgzil vllstg a d Bls sn knt.
Ht sn d Bls z Gl gr gwd



Frühr mstn die Proger ser kurz Varinamn verwndn dam sie auf dn dmls kln Monit die Progzeile vollstg auf dem Bildsch sen knten.
Hte sin die Bildsch zm Glck größer gewrden



Früher mussten die Programmierer sehr kurze Variablennamen verwenden damit sie auf den damals kleinen Monitoren die Programmzeile vollständig auf dem Bildschirm sehen konnten.
Heute sind die Bildschirme zum Glück größer geworden.


80 Zeichen pro Zeile war einmal das Limit.
Hut ab vor den alten Herren.

N G

Ntr Grs

Netter Gruß