Kommunikation zwischen zwei Delphiprogrammen

[rwb]

Liebe Freunde,

heute bitte ich Euch um allgemeine Hinweise, Tips und Ratschläge um folgende, für mich ganz neue, Aufgabenstellung zu lösen.
Ich möchte ein Delphiprogramm (mit Delphi Professional 10.4.2) schreiben, dass eine GUI hat, aber dennoch etwas für mich erledigt, wenn ich es unter W8.1 verkleinere, es also in der Taskleiste landet.
Ein zweites Programm soll einige Parameter an das Erste schicken können. Dort wird etwas berechnet und dann das Ergebniss an das zweite Programm zurückgeschickt. (compute server?)
Mit welchen Standartkomponenten kann ich das erreichen? Wenn es irgendwie ginge, würde ich gerne Mechanismen des Betriebssystems umgehen und die Programme sozusagen direkt miteinander kommunizieren lassen.

An folgende Lösungen habe ich schon gedacht.

A) Das zweite Programm ruft das Erste direkt auf (startet es) und übergibt dabei die Parameter. Dann wird das Ergebniss über die Zwischenablage zurückgegeben. Das ist leider langsam und braucht die Zwischenablage.
B) Ich lasse ein drittes Programm mit einer Datenbank laufen, auf das die ersten beiden Programme auch Zugriff haben. Wenn ich die Datenbank im RAM laufen lasse ist das sogar recht schnell aber es ist mit mehr Aufwand verbunden.

Welche elegantere Lösungen gibt es?

Herzlichen Dank im voraus.

RWB

[KodeZwerg]

Im allgemeinen verwendet man IPC (Inter Process Communication) dafür.
Da Du schreibst "ohne Mechanismen des Betriebssystems" auskommen zu wollen wird dir wohl nichts was IPC betrifft zusagen.

[rwb]

Hallo KodeZwerg,
ersteinmal danke für die Antwort. Auch wenn ich Vorlieben habe, hier also das Betriebssystem zu umgehen, kann es ja sein, dass das der einzige Weg ist. Ich bin daher offen für alle Vorschläge.
Gibt es Komponenten für IPC? Wie geht man das praktisch an?

[TurboMagic]

Dazu kurz zwei Stichworte:
Named Pipe
Sockets, entweder TCP oder UDP

Für letzteres entweder Indy nehmen, ist aber synchron oder
ICS (siehe Tools/GetIt), das wäre nicht blockierend asynchron.

Grüße
TurboMagic

[Bernhard Geyer]

Zitat:

hier also das Betriebssystem zu umgehen

Ein "umgehen" des Betriebssystem ist hier nicht möglich.
Du kannst hier nur versuchen einen Weg zu finden, welcher z.B. nicht nur unter Windows verfügbar ist, sondern auch auf Linux gehen würde.

[dummzeuch]

Die einfachste und in der Regel idiotensichere Möglichkeit, Daten von einem Programm an ein anderes zu übergeben, ist via Dateien.

Beispiel: Es gibt ein Verzeichnis A mit Eingabedateien und Verzeichnis B mit Ausgabedateien.
Programm 1 schreibt seine Daten, die berechnet werden sollen, in Verzeichnis A, Programm 2 wartet darauf, dass in Verzeichnis A Dateien angelegt werden, liest sie, verarbeitet sie und schreibt das Ergebnis in Verzeichnis B. Programm 1 wartet darauf, dass seine Ergebnisse in Verzeichnis B erscheinen und liest sie dann aus.

Das ist sicherlich nicht die schnellste, eleganteste und sicherste Lösung, aber es lässt sich wunderbar debuggen und testen. Ach ja, und es funktioniert auch auf einem Share im Netzwerk.

Man darf sich nur nicht von irgendwem erwischen lassen, dass man so eine simple Lösung verwendet statt irgendeines "Frameworks" oder einer Datenbank (wobei die schon Old School sind) oder eines "Microservices".

[Mavarik]

Die einfachste Lösung wäre doch per http...

Die eine App mach einen http oder REST Server auf... Die andere kann dann einfach per JSON die Anfrage senden und so auch die Antwort erhalten.

Mavarik

PS.: Also im Prinzip das, was TurboMagic schon geschrieben hat, nur einen Layer mehr.

[TurboMagic]

Auch das sollte mit ICS gehen oder vermutlich auch mit Indy, wenn es blockieren darf.

[Rolf Frei]

Ich nutze hierfür Namend Pipes. Dafür gibt es eine Freeware Komponente, die das Ganze sehr einfach machen. Diese Freeware Komponente habe ich dir mal angehängt. Ich nutze dies schon sehr lange zum Steuern eines Windwosdienstes über ein Trayicon Programm.

[rwb]

Ich bin begeistert, herzlichen Dank an alle.
Jetzt werde ich ersteinmal alle Vorschläge überdenken und habe dann bestimmt weitere Fragen.
Ich wünsche allen ein tolles bzw besinnliches Wochenende.

RWB

[rwb]

Hallo,
Ihre Lösung gefällt mir, ich könnte eine Textdate mit den Daten auf jeweils einer Zeile anlegen. Die Datei hätte mehrere Zeilen. Damit wäre auch eine Batchverarbeitung möglich. Dabei geht es mir dann auch nicht um Schnelligkeit.
Aber hier liegt der Haken:
>Programm 1 schreibt seine Daten, die berechnet werden sollen, in Verzeichnis A, Programm 2 wartet darauf, dass in Verzeichnis A Dateien angelegt werden,
Es ist das warten von Programm 2, also die Überwachung eines Verzeichnisses. Ich habe einen ziemlichen Teil des Sonntags damit verbracht dafür eine praktikable Lösung zu suchen. Hier in der Delphi-Praxis gibt es eine ganze Reihe von Beiträgen zu diesem Thema. Aber sie sind ziemlich alt mit Verweisen auf Webseiten die nicht mehr existieren mit anderen gebrochenen Links und Beiträgen die Probleme aufzeigen aber keine Lösung.
In der JCVL gibt es die Komponenten JvChangeNotify und TJvFolderMonitor. Leider brach die Installation der JXVL mit einem Fehler ab.
Hiermit komme ich also zur Zeit auch nicht weiter. Es gibt eine Watch_it.exe die Verzeichnisse überwacht und Aktionen auslöst. Ich brauch aber eine Unit oder Komponente die ich einbinden kann.
Wie haben Sie das gelöst?

>Man darf sich nur nicht von irgendwem erwischen lassen, dass man so eine simple Lösung verwendet statt irgendeines "Frameworks" oder einer Datenbank (wobei die >schon Old School sind) oder eines "Microservices".
Da habe ich keine Angst :-D
Mit besten Grüßen
RWB

[KodeZwerg]

Zitat:

Zitat von rwb (Beitrag 1515417)

Hallo KodeZwerg,
ersteinmal danke für die Antwort. Auch wenn ich Vorlieben habe, hier also das Betriebssystem zu umgehen, kann es ja sein, dass das der einzige Weg ist. Ich bin daher offen für alle Vorschläge.
Gibt es Komponenten für IPC? Wie geht man das praktisch an?

Komponenten oder irgendwelche speziellen units werden bei meiner Variante nicht verwendet.
WM_COPYDATA wird benutzt um was von Programm A zu Programm B zu senden.
Funktioniert bei mir immer tadellos, habe eine kleine Demo dazu angehangen.

Viel spaß beim testen.

[TurboMagic]

Zitat:

Zitat von rwb (Beitrag 1515543)

Hallo,
Ihre Lösung gefällt mir, ich könnte eine Textdate mit den Daten auf jeweils einer Zeile anlegen. Die Datei hätte mehrere Zeilen. Damit wäre auch eine Batchverarbeitung möglich. Dabei geht es mir dann auch nicht um Schnelligkeit.
Aber hier liegt der Haken:
>Programm 1 schreibt seine Daten, die berechnet werden sollen, in Verzeichnis A, Programm 2 wartet darauf, dass in Verzeichnis A Dateien angelegt werden,
Es ist das warten von Programm 2, also die Überwachung eines Verzeichnisses. Ich habe einen ziemlichen Teil des Sonntags damit verbracht dafür eine praktikable Lösung zu suchen. Hier in der Delphi-Praxis gibt es eine ganze Reihe von Beiträgen zu diesem Thema. Aber sie sind ziemlich alt mit Verweisen auf Webseiten die nicht mehr existieren mit anderen gebrochenen Links und Beiträgen die Probleme aufzeigen aber keine Lösung.
In der JCVL gibt es die Komponenten JvChangeNotify und TJvFolderMonitor. Leider brach die Installation der JXVL mit einem Fehler ab.
Hiermit komme ich also zur Zeit auch nicht weiter. Es gibt eine Watch_it.exe die Verzeichnisse überwacht und Aktionen auslöst. Ich brauch aber eine Unit oder Komponente die ich einbinden kann.
Wie haben Sie das gelöst?

>Man darf sich nur nicht von irgendwem erwischen lassen, dass man so eine simple Lösung verwendet statt irgendeines "Frameworks" oder einer Datenbank (wobei die >schon Old School sind) oder eines "Microservices".
Da habe ich keine Angst :-D
Mit besten Grüßen
RWB

Ja, in der JVCL gibt's was. Das nutzt intern m.W. irgendwelche Windows APIs, du könntest das also von deren Quellcode abgucken.
Aber: bei einer fehlgeschlagenen JVCL Installation werden wir dir da nur weiterhelfen können, wenn du uns die Fehlermeldung nennst. Wir haben leider keine Glaskugeln...
Hast du zuerst die JCL installiert?
Wie bist du zur Installation vorgegangen? Via Tools/GetIt Packagemnager?

[mytbo]

Zitat:

Zitat von rwb (Beitrag 1515543)

>Man darf sich nur nicht von irgendwem erwischen lassen, dass man so eine simple Lösung verwendet statt irgendeines "Frameworks" oder einer Datenbank (wobei die >schon Old School sind) oder eines "Microservices".
Da habe ich keine Angst :-D

Wenn du keine schnelle Reaktionszeit benötigst, merke dir das letzte Änderungsdatum der Datei und dann polle darauf. Dafür reicht ein Timer. Ja, ich würde einen Microservice schreiben, weil das in mORMot auch nicht viel mehr Arbeit ist, als FileAgeToDateTime aufzurufen. Irgendwann kommt immer einer auf die Idee und die Berechnungen sollen NNO 100km querab stattfinden. Bei SOA hätte nur der Admin Arbeit.

Bis bald...
Thomas

[rwb]

Moin

>Hast du zuerst die JCL installiert?
>Wie bist du zur Installation vorgegangen? Via Tools/GetIt Packagemnager?
Ja, genau Tools/GetIt Packagemaneger, glücklicherweise hatte ich direct einen Screenshot gemacht. Ist angehängt.
Danach habe ich mir heruntergeladen:
JVCL349CompleteJCL27-Build5676.zip https://sourceforge.net/projects/jvcl/ und
https://github.com/project-jedi/jvcl jvcl-master.zip
aber damit komme ich nicht klar.

[rwb]

Korrektur,
inzwischen konnte ich die jvcl von der jvcl-master.zip installieren.

[rwb]

>Viel spaß beim testen.

Danke KodeZwerg,
den Spaß hatte ich. Hat auf Anhieb funktioniert. Den Code sehe ich mir morgen an.

[KodeZwerg]

Zitat:

Zitat von rwb (Beitrag 1515586)

>Viel spaß beim testen.

Danke KodeZwerg,
den Spaß hatte ich. Hat auf Anhieb funktioniert. Den Code sehe ich mir morgen an.

Gern geschehen :thumb:

[dummzeuch]

Zitat:

Zitat von rwb (Beitrag 1515543)

Hallo,
>Programm 1 schreibt seine Daten, die berechnet werden sollen, in Verzeichnis A, Programm 2 wartet darauf, dass in Verzeichnis A Dateien angelegt werden,
Es ist das warten von Programm 2, also die Überwachung eines Verzeichnisses. Ich habe einen ziemlichen Teil des Sonntags damit verbracht dafür eine praktikable Lösung zu suchen.
...
Wie haben Sie das gelöst?

Gar nicht. Ich benutze diese Lösung nicht selbst, sie ist mir nur spontan eingefallen.

Es gibt dafür aber die WinAPI Funktionen FindFirstChangeNotification / FindNextChangeNotification, die ich z.B. in dzEditorLineendsFix verwende, um die Font-Datei, die Delphi 2007 erzeugt, jedesmal wieder in ein anderes Verzeichnis zu verschieben.

Der Code läuft in einem Hintergrundthread und sieht so aus:

Delphi-Quellcode:

procedure Tf_EditorLineEndsFix.ExecuteInThread(_Sender: TObject);
var
  Err: DWORD;
  NotifyHandle: THandle;
  Res: DWORD;
begin
  try
    CheckForFile;
    NotifyHandle := FindFirstChangeNotification(PChar(TFileSystem.GetTempPath), false,
      FILE_NOTIFY_CHANGE_FILE_NAME);
    if NotifyHandle = INVALID_HANDLE_VALUE then begin
      Err := GetLastError;
      RaiseLastOsErrorEx(Err, _('Error %1:s (%0:d)'));
    end;
    try
      while not TThread.CheckTerminated do begin
        Res := WaitForSingleObject(NotifyHandle, 100);
        if res = WAIT_OBJECT_0 then begin
          CheckForFile;
          if not FindNextChangeNotification(NotifyHandle) then begin
            Err := GetLastError;
            RaiseLastOsErrorEx(Err, _('Error %1:s (%0:d)'));
          end;
        end else if res = WAIT_TIMEOUT then begin
          // stay in the loop
        end else
          raise Exception.CreateFmt(_('WaitForSingleObject failed with error code %d.'), [res]);
      end;
    finally
      FindCloseChangeNotification(NotifyHandle);
    end;
  except
    on e: Exception do begin
      doWriteToLog(e.Message);
    end;
  end;
end;

Im Prinzip könntest Du diesen Code nutzen, müsstest nur in CheckForFile die Verarbeitung vornehmen. Und natürlich in FindFirstNotification statt TFileSystem.GetTempPath das korrekte Verzeichnis übergeben.

Und nicht vergessen: Der Code sollte in einem Hintergrund-Thread laufen, sonst blockiert er das UI.

[rwalper]

Ein kleiner Hinweis noch zum Mechanismus mit den Dateien, denn damit hatte ich vor längerem zu tun.

Ich habe (kleine) Auftrags-Dateien erzeugt, der Server hat die gelesen, diese Dateien gelöscht und Antwort-Dateien erzeugt, die dann wiederun der Client gelesen und gelöscht hat.
Im lokalen Dateisystem funktioniert so etwas sehr gut und auch stabil.

Auf Netzlaufwerken sollte man allerdings vorsichtig sein. Seit der Einführung des SMB2-Protokoll gab es massive Probleme (das Zurückschalten auf SMB1 ist aus Sicherheitsgründen nicht zu empfehlen).
Bei sehr vielen Dateioperationen auf den Windows-Freigaben kann es sehr lange dauern, bis die Änderungen für den Client sichtbar sind, egal ob im Windows-Explorer oder den FindChangeNotifications, teilweise waren das 10 Sekunden!
Im Endeffekt haben wir den Dateimechanismus durch http ersetzt und seit dem keine Probleme.

[rwb]

Danke, ich bastele jetzt mit den verschiedenen Ansätzen rum, und wenn was dabei rauskommt melde ich mich.
Danke noch mal an Alle für Ihre Beiträge.
RWB

[mjustin]

Zitat:

Zitat von dummzeuch (Beitrag 1515602)

Es gibt dafür aber die WinAPI Funktionen FindFirstChangeNotification / FindNextChangeNotification, die ich z.B. in dzEditorLineendsFix verwende, um die Font-Datei, die Delphi 2007 erzeugt, jedesmal wieder in ein anderes Verzeichnis zu verschieben.

Der Code läuft in einem Hintergrundthread und sieht so aus:
...
Und nicht vergessen: Der Code sollte in einem Hintergrund-Thread laufen, sonst blockiert er das UI.

Diese API habe ich einer Netzwerkumgebung zum Überwachen eines EDI (Incoming) Verzeichnis auch einmal eingesetzt.
Solange die Anwendung kontinuierlich läuft, und das Netzwerkverzeichnis erreichbar ist, funktioniert es auch prima. Doch nach einer Netzwerkstörung, wegen der das Programm den Incoming-Ordner vorübergehend nicht sieht, oder einem Neustart des Programms, liegen eventuell Dateien im Incoming-Ordner, die zwischenzeitlich eingetroffen sind.
Daher muss man beim Start des Programms dann zusätzlich noch einmal einen normalen Directory-Scan durchführen. So gesehen hat man dann zwei Schleifen für ein und dieselbe Aufgabe.

Zur Kommunikation zwischen zwei Prozessen würde ich entweder das klassische Suchen im Dateisystem (Findxxx) verwenden, oder eine andere Methode für IPC. Client-Server basierte Lösungen jedoch nur mit einem zentralen Server. Nicht auf jedem Rechner im lokalen Netz möchte die IT "wilde" HTTP- oder sonstige offene Server-Ports sehen :)

[Michael II]

Zitat:

Zitat von Rolf Frei (Beitrag 1515433)

Ich nutze hierfür Namend Pipes. Dafür gibt es eine Freeware Komponente, die das Ganze sehr einfach machen. Diese Freeware Komponente habe ich dir mal angehängt. Ich nutze dies schon sehr lange zum Steuern eines Windwosdienstes über ein Trayicon Programm.

Funktioniert super - besten Dank!

Problem:
Es kann bei TPipeServer beim Beenden der Verbindung (Active := false) ein Speicherleck entstehen:
Soweit ich sehe passiert es, wenn ein TPipeClient Disconnect aufruft und TPipeServer "gleichzeitig" mittels Write diesem Client Daten D übermittelt und dann Active := false setzt.
In der Methode TPipeServer.Write wird via AllocPipeWrite für D Speicher reserviert. DisposePipeWrite wird aber für diesen Speicher dann nicht aufgerufen => Leck.
(EurekaLog 7.11.0.1)

Lösung:
Code der Komponente anpassen.

Workaround (Lösung wäre schöner ;-)):
Bei 1-1 Verbindung: TPipeServer schliesst die Verbindung.
Bei 1-n Verbindungen: Flusskontrolle einbauen.

[rwb]

Moin Michael II,
wie benutze ich denn jetzt das Ganze?
Mein Programm(e) ist in der IDE, ich lade die beiden Dateien, nehme sie in die USES auf und dann?
Ratlos,
RWB

[Michael II]

Hoi rwb,
falls du noch nie eine eigene Komponente erstellt hast, dann tu's mal - es macht Spass.
Zur Pipe: Wähle in deinem Delphi das Menu Komponente > Komponente installieren und füge RFNamedPipes.pas hinzu.
In RFNamedPipes.pas gibt's eine Procedure Register RegisterComponents('Win32', [TPipeServer, TPipeClient]);
Nach der Installation der Komponente findest du deshalb in der IDE in der Palette unter Win32 neu TPipeServer und TPipeClient.

Du hast zwei Apps 1 und 2, welche via Pipe kommunizieren sollen?
Knall auf 1 TPipeServer und auf 2 TPipeClient.
Setze die Eigenschaft PipeName in 1 und 2 auf den gleichen Wert.
Setze die Eigenschaft Active von TPipeServer auf true. TPipeServer wartet nun auf Verbindungsanfragen. TPipeClient kann mittels Connect verbinden.
Mit Write übermittelst du Daten. Auf der Gegenseite greifst du die empfangenen Daten im OnMessage ab.
Verbindung abbrechen:
Client seitig: Disconnet.
Server seitig: Active := false setzen (es gibt auch eine protected Methode, welche dich vielleicht interessiert, wenn du mehrere Clients hast und zu einem bestimmten Client die Verbindung kappen willst - schau in den Code)

Ich hoffe das hilft.

[rwb]

Hervorragend Danke

[Neumann]

Was ist mit dem App-Tethering? Das sollte doch auch funktionieren. Habe bisher wenig Erfahrung damit, nur mal ein Übungsbeispiel (Bild mit Handy fotografieren und dann zum Desktop schicken) das geht einwandfrei.

Oder gibt es damit Probleme die ich nicht kenne?

[Uwe Raabe]

Zitat:

Zitat von Neumann (Beitrag 1517426)

Was ist mit dem App-Tethering?

Das hätte ich auch in den Ring geworfen, insbesondere da es ja quasi zu den Bordmitteln von Delphi gehört. Leider war ich zum Zeitpunkt der Fragestellung nicht voll einsatzfähig und mittlerweile hat sich das ja schon sehr weit in eine andere Richtung entwickelt.

[Michael II]

Zitat:

Zitat von Uwe Raabe (Beitrag 1517427)

Zitat:

Zitat von Neumann (Beitrag 1517426)

Was ist mit dem App-Tethering?

Das hätte ich auch in den Ring geworfen, insbesondere da es ja quasi zu den Bordmitteln von Delphi gehört. Leider war ich zum Zeitpunkt der Fragestellung nicht voll einsatzfähig und mittlerweile hat sich das ja schon sehr weit in eine andere Richtung entwickelt.

Und ich würde wie TM (#4) tcp und dazu ICS Overbyte nutzen. Wenn ich die Tethering Infos richtig verstehe, dann kann das Ding für eine lokale Verbindung unter Windows auch "nur" IP - und da ich ICS voll vertraue und gleichzeitig sehe welchen Klotz sich Delphi mit Indy angelacht hat, bin ich vorsichtig mit einer Delphi eigenen Lösung. Aber das Ding ist natürlich sicher echt cool, wenn man gleich oder vielleicht später mal nicht nur lokal miteinander reden will.

Ich habe hier nur reingeschrieben wegen dem Leck in #9. Ich nutze die Pipe (#9) als Alternative zur einer tcp Verbindung. Da es NutzerInnen meiner App immer wieder gelingt mittels Firewall die Verbindung zu kappen ist ein zweiter Weg ganz gut.

[Uwe Raabe]

Die Wahl einer Lösung hängt natürlich auch immer vom persönlichen Geschmack ab. Das macht eine Lösung aber nicht zwingend zu einer besseren oder schlechteren.

[Michael II]

Zitat:

Zitat von Rolf Frei (Beitrag 1515433)

Ich nutze hierfür Namend Pipes. Dafür gibt es eine Freeware Komponente, die das Ganze sehr einfach machen. Diese Freeware Komponente habe ich dir mal angehängt. Ich nutze dies schon sehr lange zum Steuern eines Windwosdienstes über ein Trayicon Programm.

Der verlinkte Code ist für Win32. Hat jemand diese beiden Files mal für Win64 übersetzt?

(Ich nutze diese Komponenten für die Kommunikation zwischen zwei Apps auf dem gleichen Gerät. Früher habe ich tcp via ICS verwendet; da gab's halt immer wieder Menschen, welche ihre Firewall o.ä. nicht bedienen konnten und sich aussperrten. => Der Support ist in diesem Bereich von mehreren Stunden pro Jahr auf 0 gefallen.)

[superflexible]

Hi,
hier ist meine aktuelle 32+64-Bit-Version mit noch weiteren Verbesserungen und einem Beispiel-Programm.

Man kann das Programm mehrmals starten, um zu sehen, dass sich mehrere Clients mit demselben Server verbinden können.

https://github.com/superflexible/NamedPipesForDelphi

Ich habe eine ähnliche Unit auch für macOS/Linux, die mit Sockets arbeitet. Bei Interesse bitte nachfragen.

[Michael II]

Herzlichen Dank für die rasche Hilfe an diesem "Sturm und Schneeregen Sonntag".

Eingebaut - Funktioniert 1A :-D

[softtouch]

Ich mache das seit Jahren mit allen möglichen Delphi Versionen mit Cromis IPC.

[Rolf Frei]

Zitat:

Zitat von superflexible (Beitrag 1529566)

Hi,
hier ist meine aktuelle 32+64-Bit-Version mit noch weiteren Verbesserungen und einem Beispiel-Programm.

Man kann das Programm mehrmals starten, um zu sehen, dass sich mehrere Clients mit demselben Server verbinden können.

https://github.com/superflexible/NamedPipesForDelphi

Ich habe eine ähnliche Unit auch für macOS/Linux, die mit Sockets arbeitet. Bei Interesse bitte nachfragen.

Habe mir das mal angeschaut, haben da aber ein Problem mit deiner verbesserten Version. Sie nutzt die Forms Unit, was eine Anwendung ohne Form (Console oder Web-Application) massiv aufbläst. Siehst du du eine Möglichkeit die Abhängigkeit von Forms.pas aufzuheben? Ich vermute dafür war vorher die Unit RFNamedPipesObjInst.pas zuständig. Da deine Verison deutlich besser aussieht als meine alte, würde ich diese auch gerne nutzen, aber solange da die Forms Unit benutzt wird, ist das leider ein NoGo für mich.