Delphi-PRAXiS
Seite 3 von 4     123 4      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi .exe zu .exe Kommunikation (https://www.delphipraxis.net/196064-exe-zu-exe-kommunikation.html)

KodeZwerg 20. Apr 2018 11:21

AW: .exe zu .exe Kommunikation
 
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 20. Apr 2018 14:46

AW: .exe zu .exe Kommunikation
 
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 20. Apr 2018 15:08

AW: .exe zu .exe Kommunikation
 
https://www.delphi-treff.de/tutorial...-mapped-files/

CCRDude 20. Apr 2018 15:53

AW: .exe zu .exe Kommunikation
 
Zitat:

Zitat von Sherlock (Beitrag 1400009)
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 20. Apr 2018 17:01

AW: .exe zu .exe Kommunikation
 
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 21. Apr 2018 14:21

AW: .exe zu .exe Kommunikation
 
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.
:twisted: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 21. Apr 2018 14:38

AW: .exe zu .exe Kommunikation
 
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 21. Apr 2018 16:08

AW: .exe zu .exe Kommunikation
 
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 21. Apr 2018 17:43

AW: .exe zu .exe Kommunikation
 
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 21. Apr 2018 19:50

AW: .exe zu .exe Kommunikation
 
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.


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:51 Uhr.
Seite 3 von 4     123 4      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz