AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

.exe zu .exe Kommunikation

Ein Thema von KodeZwerg · begonnen am 20. Apr 2018 · letzter Beitrag vom 16. Okt 2018
Antwort Antwort
Seite 3 von 4     123 4   
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.685 Beiträge
 
Delphi 11 Alexandria
 
#21

AW: .exe zu .exe Kommunikation

  Alt 20. Apr 2018, 12:21
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!
Gruß vom KodeZwerg
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.753 Beiträge
 
Delphi 11 Alexandria
 
#22

AW: .exe zu .exe Kommunikation

  Alt 20. Apr 2018, 15:46
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
Oliver
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Delphi-Laie

Registriert seit: 25. Nov 2005
1.474 Beiträge
 
Delphi 10.1 Berlin Starter
 
#23

AW: .exe zu .exe Kommunikation

  Alt 20. Apr 2018, 16:08
https://www.delphi-treff.de/tutorial...-mapped-files/
  Mit Zitat antworten Zitat
CCRDude

Registriert seit: 9. Jun 2011
675 Beiträge
 
FreePascal / Lazarus
 
#24

AW: .exe zu .exe Kommunikation

  Alt 20. Apr 2018, 16:53
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.
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.685 Beiträge
 
Delphi 11 Alexandria
 
#25

AW: .exe zu .exe Kommunikation

  Alt 20. Apr 2018, 18:01
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.
Gruß vom KodeZwerg
  Mit Zitat antworten Zitat
Solutor

Registriert seit: 24. Dez 2017
15 Beiträge
 
Delphi XE2 Enterprise
 
#26

AW: .exe zu .exe Kommunikation

  Alt 21. Apr 2018, 15:21
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.
  Mit Zitat antworten Zitat
günni0
(Gast)

n/a Beiträge
 
#27

AW: .exe zu .exe Kommunikation

  Alt 21. Apr 2018, 15:38
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.
  Mit Zitat antworten Zitat
Sailor

Registriert seit: 20. Jul 2008
Ort: Balaton
112 Beiträge
 
Delphi 2010 Professional
 
#28

AW: .exe zu .exe Kommunikation

  Alt 21. Apr 2018, 17:08
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.
  Mit Zitat antworten Zitat
günni0
(Gast)

n/a Beiträge
 
#29

AW: .exe zu .exe Kommunikation

  Alt 21. Apr 2018, 18:43
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.
  Mit Zitat antworten Zitat
Benutzerbild von KodeZwerg
KodeZwerg

Registriert seit: 1. Feb 2018
3.685 Beiträge
 
Delphi 11 Alexandria
 
#30

AW: .exe zu .exe Kommunikation

  Alt 21. Apr 2018, 20:50
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.
Gruß vom KodeZwerg

Geändert von KodeZwerg (21. Apr 2018 um 20:57 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:08 Uhr.
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