.exe zu .exe Kommunikation

[KodeZwerg]

Ich werde heute noch zum Piraten so oft wie ich schon "ahhhhrg" schrie )
PERFEKTER TIPP *KUSSI BUSSI*
Den werde ich exakt wie beschrieben umsetzen, dann sind seperate Units Null Problemo.

Vielen Dank @NG!

[Sherlock]

TCP hat einen entscheidenden Nachteil: Es ist nicht unmittelbar Terminalserver tauglich. Da die Applikationen einen definierten Serverport aufmachen müssen, geht das pro Maschine nur ein Mal. Man kann das im Terminalserver wohl konfigurieren, daß der gleiche Port mehrfach vergeben werden kann, aber daran muß man denken. Hab ich vor 15 Jahren alles mal durchmachen müssen, und bin am Ende für IPC bei COM gelandet...was richtig Geil lief, aber "because of popular demand" dann doch einen Schritt zurück zu WMCOPYDATA gegangen.

Sherlock

[Delphi-Laie]

https://www.delphi-treff.de/tutorial...-mapped-files/

[CCRDude]

Zitat von Sherlock:

TCP hat einen entscheidenden Nachteil: Es ist nicht unmittelbar Terminalserver tauglich. Da die Applikationen einen definierten Serverport aufmachen müssen,

Warum nur einmal? Es gibt doch 2^16 Ports, minus des reservierten Bereichs?

Das ist auch nur wieder eine Frage des Anwendungsfalles. Bei mir ist das z.B. ein systembezogener Systemdienst - damit ist es eben gerade direkt Terminalserver-tauglich, weil es, egal wie viele Sessions, nur einen "Server" gibt

Generell ist das mit den Ports natürlich immer ein Problem (nicht nur, wenn man über Sessions verteilt), deswegen suche ich z.B. einen freien Port innerhalb eines bestimmten Bereichs und speichere den in der Registry, damit die Client-Software-Teile das finden können.

[KodeZwerg]

Für TCP nehme ich gerade lediglich exemplarisch localhost, im Endprodukt muss jeder Wissen was er für welchen Zweck braucht, falls überhaupt
Vielleicht bastel ich auf die schnelle noch Adress+Port edit rein, mal sehen.

[Solutor]

Ich bevorzuge Memory maped Files:

Beispiel:
Wir haben eine SPS deren IO's über mit einem DELPHI Programm mit einr Active X Komponente gelesen und geschrieben werden.
Dieses Programm ist die Schnittstelle zu diesem Typ SPS.

Wir haben ein "Labor - Analysengerät" das über eine PC-Software des Herstellers kontrolliert werden muss.
Ein Delphi Programm kontrolliert dieses Programm über seine Fenster-und Control Handles.
Dieses DELPHI-Programm ist die Schnittstelle zu dieser Software.
fremde Software zu vergewaltigen ist unsere Spezialität.

Wir haben dann eine Handvoll weiterer Programme die jedes für sich die Daten von diesen Programmen einsammelt, verarbeitet und Bewertet.
Jedes der Programme hat eine andere Aufgabe. Alle Aufgaben müssen aber aufeinander abgestimmt werden.
Diese Programme tauschen untereinander einzelne Messdaten und Statusdaten aus und reagieren entsprechend.
Ein zentrales Masterprogramm regelt den Gesamtablauf und greift je nach Status ein.
Ein Bedienprogramm ist in der lage einzelne der Programme zu bedienen und Werte abzufragen.

Es ist insgesamt ein sehr umfangreiches Projekt, doch dies über viele einzelne Programme zu regeln, hatte den Vorteil,
dass sich bei Änderung eines Bestandteils der Aufgaben oder Hardware, nur das betreffende Programm angefasst werden muss.

Hier agieren viele Programme miteinander, tauschen Daten aus und das mehrmals pro Sekunde.
Wir haben die unterschiedlichsten Mechanismen ausprobiert, daruter Messages, Echte Dateien auf einer Memorydisk, IP-Kommunikation und sind am Ende bei den Memory Mapped Files geblieben, da diese sich am langzeitstabilsten erwiesen haben.

[günni0]

Eine Art Performancetest sowie die Möglichkeit zur Angabe der Datengrößen die man schicken möchte in deiner Demo wäre sicher von Vorteil.

[Sailor]

Warum benutzt Ihr nicht COM? Das ist doch genau dafür gedacht. Einen Server, einen oder mehrere Clients mit Eventsink für Kommunikation in beiden Richtungen: Delphi bietet alles an Komponenten, was man dazu braucht. Eine komfortable und sehr gut funktionierende Lösung.

[günni0]

Und wenn Programm.exe schon offen ist, man nochmal Programm.exe startet und nur die Parameter von der zweiten an die erste Instanz geben will? Da finde ich COM,TCP und sowas etwas übertrieben.

[KodeZwerg]

Ich (der TE) hatte dieses Problem, ich wollte das ein Hauptprogramm arbeitet und ein anderes Programm nur zuhört wie weit das Hauptprogramm mit Arbeit ist bzw an welcher Stelle es sich gerade befindet, ähnlich einem Debug nur viel simpler und keine Möglichkeit da einzugreifen, also kein "Chat-Programm" wo Nachricht hin und her geht sondern Einbahnstrasse.
Das Thema IPC war für mich bis dato neu sonst hätte ich garantiert weder einen Thread erstellt noch Thread-Titel so doof benannt, nun wurden mir diese und jene Varianten genannt also beschloss ich kurzerhand eine kleine Demo zu kreieren die einem alles was hier besprochen war enthält.
In der DP findet man massig Beispiele wenn man weiß wonach man suchen muss, ich wusste es vorher halt nicht.
Server-Seitig steht mein Konstrukt mit allen Features wie beim Bild weiter oben, Client-Seitig ist es (noch) komplizierter aber ich komme Stückchenweise voran.
Teilweise beissen sich die verschiedenen Typen wenn Sie gleichzeitig laufen (Client).
Bevor ich Schrottcode veröffentliche, Teste ich so gut ich kann alles was mir einfällt aus.
Client zeigt mehr Info's an als die eigentlich gesandten Daten, ich glaub ich mache es mir mit dem auch einfacher indem ich den die gleiche Auswahlbox verpasse anstelle permanent nach allen Varianten aktiv zu Suchen.
Spätestens in einer Woche sollte ich mit mir selbst Zufrieden sein so das ich Code freigebe.

edit
Client und Server kann man nur einmal starten, Reihenfolge ist egal.
Server sendet nur wenn Client zuhört.
Client gibt Zeit für Dauer an, deswegen Möglichkeit ein Bild zu senden/empfangen als example für Binär Daten.