.exe zu .exe Kommunikation

[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.

[Codehunter]

Ich greife diesen Thread mal auf, weil mein Anliegen thematisch hier sehr gut rein passt. Folgendes Problem bei mir:

1. Es soll zwei Programme geben. Eine Hostanwendung und eine oder mehrere Instanzen einer Client-Anwendung. Beide von mir geschrieben.

2. Die Hostanwendung ist ein Systemdienst, der unter dem SYSTEM-Konto läuft.

3. Die Hostanwendung startet die Client-Anwendung(en) selbst, Art und Weise wie diese Prozesse erzeugt werden, da bin ich flexibel.

4. Die Client-Anwendung beackert externe Programme, die wiederum NICHT von mir sind und hin und wieder mal zu Instabilität neigen. Raucht so ein Programm unerwartet ab, bleibt meine Client-Anwendung u.U. in einem undefinierten Zustand stehen. Deshalb sollen die Client-Anwendungen eine (konfigurierbare) Lifetime haben. Innerhalb derer müssen sie sich sauber beenden (wird in Datenbank geloggt). Tun sie das nicht, sollen sie zuerst vom Host per IPC eine Anweisung zum Shutdown bekommen (wird seitens Hostanwendung ebenfalls geloggt). Reagieren sie darauf auch nicht, z.B. per Antwort-Message und Shutdown, soll die Hostanwendung den hängenden Client-Prozess hart terminieren.

Soweit so einfach. Die Kommunikation zwischen meinen beiden Anwendungen ist eher trivial, eine einfache Event-Signalisierung, die keine komplexen Daten übermitteln muss. Schlimmstenfalls ein paar DWords.

Der Kniff an der Sache ist, dass die Client-Instanzen ggf. unter abweichenden Benutzerkonten gestartet werden müssen. Das hat mit den wiederum von den Client-Instanzen genutzten externen Programmen zu tun, die aus Sicherheitsgründen nicht im Systemkonto laufen. Darum scheidet wohl alles aus, das auf Window-Handles basiert. Welche Art IPC würdet ihr empfehlen für dieses Szenario?

[Sherlock]

TCP/IP über localhost sollte gehen, da die Ports systemweit einmalig sind.

Server Dienst hat einen fixen Port und Clients melden sich dort an und quatschen munter drauf los.

Sherlock

[himitsu]

Nja, am "Einfachten" und oft gemacht sind TCP/IP-Verbindungen. (dafür gibt es massenhaft ProcedureCall-Frameworks, wenn du nichts selberbauen willst)

Named-Pipes gingen auch, kommen vom Protokol auf das Gleiche.
Oder ohne Name, wenn du irgendwie anders die Handles übergibst.

Memory-Mapped-Files (MMF), aber für's "schicken" von Befehlen nicht so praktisch.
Also nur MMF ist schlecht, da man dann Pollen müsste, oder über andere Wege (Messages/Events/...) über neue Daten informiert.

WindowsMessages gingen, aber da gibt es leider nur die eine WM_COPYDATA, welche auch Texte/Daten übertragen kann (wobei man bei Texten das auch über WM_SETTEXT an ein/mehrere "EDITS" schicken könnte) und dann muß du alles da rein machen, wenn du verschiedene Messages schicken willst, z.B. über ein Byte/Flag am Anfang der Daten.
Und bei den Messages mußt du aufpassen, dass sich die Beiden diese Messages überhaupt schicken dürfen. (kennst z.B. von Anwendung an Admin-Anwendung, wo standardmäßig nicht alles erlaubt ist)
Alternativ zu WM_COPYDATA, die Daten in MMF, GlobalMemory oder Files und das Handle in LPARAM/WPARAM.

[mjustin]

Hier ist ein Beispiel, in dem ein Indy TCP Server einem Client eine einfache Nachricht sendet. (Artikel Link)

Der Server-Code muss nur in der DoExecute-Methode angepasst werden und dort z.B. das nächste an den Client zu sendende Datenpaket erstellen. Da die Server-Klasse für jede Connection einen eigenen Thread verwendet, gilt der Code in der DoExecute Methode für die aktuelle Connection. DoExecute wird in einer Schleife ausgeführt bis die Verbindung getrennt wurde oder eine Exception auftritt.

Der Client-Code läuft in einem Thread um im Hintergrund auf neue Nachrichten des Servers zu warten. Der ReadLn Aufruf wartet, bis entweder eine Nachricht eintrifft, oder das Timeout erreicht ist, und wird dann wieder ausgeführt.

Delphi-Quellcode:

unit Unit1;
 
interface
 
uses
  IdCustomTCPServer, IdTCPClient, IdContext,
  SysUtils, Classes, Forms, StdCtrls, Controls;
 
type
  TMyPushClientThread = class(TThread)
  private
    TCPClient: TIdTCPClient;
    FLog: TStrings;
  public
    constructor Create(AHost: string; APort: Word; ALog: TStrings);
    destructor Destroy; override;
    procedure Execute; override;
  end;
 
  TMyPushServer = class (TIdCustomTCPServer)
  protected
    function DoExecute(AContext: TIdContext): Boolean; override;
  end;
 
  TServerPushExampleForm = class(TForm)
    MemoLog: TMemo;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    ExampleClient: TMyPushClientThread;
    ExampleServer: TMyPushServer;
  end;
 
var
  ServerPushExampleForm: TServerPushExampleForm;
 
implementation
 
uses
  IdGlobal;
 
{$R *.dfm}
 
procedure TServerPushExampleForm.FormCreate(Sender: TObject);
begin
  ExampleServer := TMyPushServer.Create;
  ExampleServer.DefaultPort := 8088;
  ExampleServer.Active := True;
 
  ExampleClient := TMyPushClientThread.Create('localhost', 8088, MemoLog.Lines);
end;
 
procedure TServerPushExampleForm.FormDestroy(Sender: TObject);
begin
  ExampleServer.Free;
  ExampleClient.Terminate;
  ExampleClient.WaitFor;
  ExampleClient.Free;
end;
 
{ TMyPushServer }
 
function TMyPushServer.DoExecute(AContext: TIdContext): Boolean;
begin
  Result := inherited;
 
  // simulate hard work
  Sleep(Random(3000));
 
  AContext.Connection.IOHandler.WriteLn(
    'Completed at ' + TimeToStr(Now), IndyTextEncoding_UTF8);
end;
 
{ TMyPushClientThread }
 
constructor TMyPushClientThread.Create(AHost: string; APort: Word; ALog: TStrings);
begin
  inherited Create(False);
 
  FLog := ALog;
 
  TCPClient := TIdTCPClient.Create;
  TCPClient.Host := AHost;
  TCPClient.Port := APort;
  TCPClient.ReadTimeout := 500;
end;
 
destructor TMyPushClientThread.Destroy;
begin
  TCPClient.Free;
  inherited;
end;
 
procedure TMyPushClientThread.Execute;
var
  S: string;
begin
  TCPClient.Connect;
 
  while not Terminated do
  begin
    S := TCPClient.IOHandler.ReadLn(IndyTextEncoding_UTF8);
 
    if not TCPClient.IOHandler.ReadLnTimedout then
    begin
      TThread.Queue(nil,
        procedure
        begin
          FLog.Append(S);
        end);
    end;
 
  end;
 
  TCPClient.Disconnect;
end;
 
end.