Kommunikation zwischen Programmen?

[Arokh]

Ich habe mir mal was überlegt: es wäre ja in vielen Fällen ganz praktisch, wenn man zwei oder mehr Programme hätte, die untereinander Daten austauschen könnten. Beispiel: Ein Programm A läßt eine wissenschaftliche Simulation laufen und sendet die Ergebnisdaten fortwährend an ein Programm B, das die Daten in Echtzeit visualisiert. Der Vorteil gegenüber der Lösung, daß beides von einem einzigen Programm erledigt wird: man kann Programm verändern, ohne daß Programm B neu kompiliert werden muß. Programm A muß halt nur eine festgelegte Schnittstellenspezifikation einhalten.

Die Frage ist jetzt: gibt es eine solche Datenaustausch-Schnittstelle zwischen Programmen? Da ich annehme, daß wenn ja, diese hochgradig betriebssystemspezifisch sein wird, bezieht sich meine Frage erst einmal nur auf Windows.

Es gibt da ja die Zwischenablage, die tatsächlich von allen Programmen gemeinsam genutzt wird, allerdings bezweifle ich, daß die für den von mir angedachten Zweck konzipiert ist. Die naheliegende Lösung, daß A die Daten dort immer reinschreibt und B von dort ausliest, würde die Zwischenablage für andere Programm blockieren, wäre als nicht sehr elegant. Außerdem würde es für A an einer Möglichkeit fehlen, B das Vorliegen neuer Daten mitzuteilen.

Eine weitere mir bekannte Lösung wäre mit Sockets: z.B. B tritt als Server auf und A als Client. Immer wenn B einen Datensatz fertiggezeichnet hat, wartet es auf neue Daten von A, und A sendet den nächsten Datensatz, sobald es ihn fertigberechnet hat. Stelle sich allerdings die Frage, ob Sockets hierfür leistungsstark genug sind.

Dann wäre da noch dieses DDE (Dynamischer Datenaustausch), das soweit ich gehört habe auch was mit Datentransfer zwischen Programmen zu tun haben soll. Da weiß ich allerdings zu wenig drüber...

[Gast]

WM_COPY_DATA kopiert beliebige daten

[Gast]

Eine gemeinsame Datenbank wäre auch möglich. Oder eine Anwendung mit verschiedenen Threads. Ich würde es allerdings auch als Client/Server realisieren.

[Nasenbaer]

Unter Linux (ohne weiteres auch unter Windows machbar) ist es ja oftmals üblich die Daten per Netzwerk auszutauschen. Wenigstens ein Loopback-Interface ist immer vorhanden wodurch man auch gleich mehrere Fliegen mit einer Klappe schlägt.
Zum einen müssen dann beide Progamme nicht auf dem gleichen Rechner laufen, was bei Simulationen ja auch manchmal auf leistungsfähige Server aufgelagert werden könnte. Zum anderen ist es ohne größere Probleme portierbar, weil das Prinzip für Netzwerkverkehr wohl recht einheitlich sein sollte. Und du wirst zur Netzwerkkomminikation wohl auch recht viel Tutorials u.ä. im Netz finden. :)

[Gnafoo]

Unter Linux ist sowas doch recht häufig der Fall. Meist über Unix Sockets oder Pipes (wobei Pipes eigentlich meist nur in einer Richtung benutzt werden). Man denke da nur an Frontends für Paketsysteme, diverse Scripts die in allen möglichen (und unmöglichen) Befehlen Programme per Pipes hintereinanderschalten etc.

Aber auch unter Windows gibt es doch einige Programme: viele Virenscanner, Defragmentierungsprogramme etc. haben ja einen Hintergrundservice, der durch das Frontend-Programm gesteuert wird. Da werden wohl meistens Sockets benutzt (ich denke mal das ist recht Performant, wenn die Kommunikation auf dem lokalen Rechner geschieht). Wenn mich nicht alles täuscht kann man aber auch die Eingabe und Ausgabe eines Programmes umleiten und auf diese Weise Daten austauschen. Das setzt aber iirc voraus, dass das eine Programm das andere startet.

[MadMan2k]

Unter Linux: D-Bus

[Gast]

Die Frage ist jetzt: gibt es eine solche Datenaustausch-Schnittstelle zwischen Programmen?Ja, MPI. Damit kannst du Strings, Integer, Floats etc. zwischen mehreren Prozessen austauschen.
Da ich annehme, daß wenn ja, diese hochgradig betriebssystemspezifisch sein wird, bezieht sich meine Frage erst einmal nur auf Windows.MPI Implementierungen gibt's mittlerweile auch für Windows.

[tokugawa]

Ich habe mir mal was überlegt: es wäre ja in vielen Fällen ganz praktisch, wenn man zwei oder mehr Programme hätte, die untereinander Daten austauschen könnten. Beispiel: Ein Programm A läßt eine wissenschaftliche Simulation laufen und sendet die Ergebnisdaten fortwährend an ein Programm B, das die Daten in Echtzeit visualisiert. Der Vorteil gegenüber der Lösung, daß beides von einem einzigen Programm erledigt wird: man kann Programm verändern, ohne daß Programm B neu kompiliert werden muß. Programm A muß halt nur eine festgelegte Schnittstellenspezifikation einhalten.

Die Frage ist jetzt: gibt es eine solche Datenaustausch-Schnittstelle zwischen Programmen? Da ich annehme, daß wenn ja, diese hochgradig betriebssystemspezifisch sein wird, bezieht sich meine Frage erst einmal nur auf Windows.

Es gibt da ja die Zwischenablage, die tatsächlich von allen Programmen gemeinsam genutzt wird, allerdings bezweifle ich, daß die für den von mir angedachten Zweck konzipiert ist. Die naheliegende Lösung, daß A die Daten dort immer reinschreibt und B von dort ausliest, würde die Zwischenablage für andere Programm blockieren, wäre als nicht sehr elegant. Außerdem würde es für A an einer Möglichkeit fehlen, B das Vorliegen neuer Daten mitzuteilen.

Eine weitere mir bekannte Lösung wäre mit Sockets: z.B. B tritt als Server auf und A als Client. Immer wenn B einen Datensatz fertiggezeichnet hat, wartet es auf neue Daten von A, und A sendet den nächsten Datensatz, sobald es ihn fertigberechnet hat. Stelle sich allerdings die Frage, ob Sockets hierfür leistungsstark genug sind.

Dann wäre da noch dieses DDE (Dynamischer Datenaustausch), das soweit ich gehört habe auch was mit Datentransfer zwischen Programmen zu tun haben soll. Da weiß ich allerdings zu wenig drüber...

Generische Interprozeß-Kommunikation hat so gut wie jedes moderne Betriebssystem (Named Pipes, Shared Memory, usw.), also auch UNIX und Windows. Darüber hinaus bietet Windows noch OLE und das ältere DDE. Mittels DDE kann man z.B. WinAMP steuern. Mittels OLE kann man in einer Anwendung ein Objekt einer anderen Anwendungen einbetten (etwa in Word eine Excel-Tabelle), und mittels "In-Place-Editing" lässt sich dann in der Zielanwendung mit der Oberfläche der Quellanwendung arbeiten (z.B. bei der Excel-Tabelle in Word kann man dann wie in Excel arbeiten, befindet sich aber immer noch im OLE-Host, also Word).

Mittels COM/DCOM lässt sich da auch einiges anstellen. Im Prinzip ist ganz Windows darauf aufgebaut, dass verschiedene "Programme" (exakter: Prozesse) miteinander kommunizieren.

[Arokh]

Eine gemeinsame Datenbank wäre auch möglich. du meinst in Form einer Datei? Das wäre ja ein völlig unnötiger Flaschenhals: Programm müßte auf die Festplatte schreiben und B von dort lesen.

Oder eine Anwendung mit verschiedenen Threads. das würde ja gar keinen Sinn machen. Es ging ja darum, die beiden unterschiedlichen Funktionalitäten in zwei unterschiedliche Anwendungen zu packen, um beide unabhängig voneinander compilieren zu können.

Was aber tatsächlich als single-application Lösung ginge, wäre eine der beiden Funktionalitäten als DLL zu realisieren, die dann von der anderen geladen wird.

[Shink]

Remote Procedure Calls bzw. Remote Method Invocation ist wohl ein sehr grundlegender, performanter, nicht allzu komplizierter Weg - darauf baut z.B. auch M$'s DCOM auf.

Dann gibts noch die Geschichten von wegen Corba, COM etc.

[Gast]

du meinst in Form einer Datei? Das wäre ja ein völlig unnötiger Flaschenhals: Programm müßte auf die Festplatte schreiben und B von dort lesen.Naja, aus der AussageBeispiel: Ein Programm A läßt eine wissenschaftliche Simulation laufen und sendet die Ergebnisdaten fortwährend an ein Programm B, das die Daten in Echtzeit visualisiert.kann man ja nicht schließen, wie schnell die Daten ankommen. Ich habe hier z. B. eine Serveranwendung laufen, die Maschinendaten einsammelt und sie in eine Datenbank schreibt. Die Clients können diese nun in Echtzeit, aber auch vergangene Daten, problemlos darstellen. Da höchstens 10 Einträge pro Minute gemacht werden, ist hier die Datenbank sicher kein Flaschenhals. Außerdem läuft die Serveranwendung auf einem eigenen Rechner.

[Gast]

Ja, MPI. Damit kannst du Strings, Integer, Floats etc. zwischen mehreren Prozessen austauschen.
MPI Implementierungen gibt's mittlerweile auch für Windows.
MPI ist AFAIK für Parallelprogrammieren entwickelt worden, Multiprozessor/Multicomputer und so. Klar da muss man auch kommunizieren, aber ich denke die ursprüngliche Intention war eine andere.

[Arokh]

Wie wäre es eigentlich mit SendMessage? Programm A, das die Daten sendet, holt sich mit FindWindow() einen Handle hWndB auf das Programmfenster von B (das muß ja definitiv ein Fenster haben, es sollen ja grafische Ausgabe machen), und sendet einen Pointer auf die Daten an dieses Fenster:

// in Prog A
HWND hWndB = FindWindow(/*Fensterklassenname von Prog B*/);
WPARAM wParam = (WPARAM) pData /*Pointer auf Daten*/;
LPARAM lParam;
SendMessage(hWndB, wParam, lParam);

lParam könnte dann noch genutzt werden, um Zusatzinformationen, z.B. die Größe der Daten, mizuübermitteln.

[Legolas]

Wie wäre es eigentlich mit SendMessage? Programm A, das die Daten sendet, holt sich mit FindWindow() einen Handle hWndB auf das Programmfenster von B (das muß ja definitiv ein Fenster haben, es sollen ja grafische Ausgabe machen), und sendet einen Pointer auf die Daten an dieses Fenster:

// in Prog A
HWND hWndB = FindWindow(/*Fensterklassenname von Prog B*/);
WPARAM wParam = (WPARAM) pData /*Pointer auf Daten*/;
LPARAM lParam;
SendMessage(hWndB, wParam, lParam);

lParam könnte dann noch genutzt werden, um Zusatzinformationen, z.B. die Größe der Daten, mizuübermitteln.
Wenn du Daten zwischen 2 Prozessen austauschen willst, musst du bedenken, daß die Prozesse im allgemeinen getrennte Adressräume haben. D.h. du musst entweder mit Shared Memory arbeiten, oder du musst die Daten vom einen in den anderen Adressraum kopieren.

[Arokh]

Wenn du Daten zwischen 2 Prozessen austauschen willst, musst du bedenken, daß die Prozesse im allgemeinen getrennte Adressräume haben. D.h. du musst entweder mit Shared Memory arbeiten, oder du musst die Daten vom einen in den anderen Adressraum kopieren.hm, ja, der Gedanke ist mir inzwischen auch schon gekommen: der Pointer in Programm A ist ja eine Adresse im virtuellen Addressraum von A, in B wäre er dann einer auf eine Adresse im Adressraum von B. Da aber der Zusammenhang zwischen virtueller und physikalischer Speicheradresse vermutlich von Prozeß zu Prozeß unterschiedlich sein wird, dürfte der Pointer in Programm B gar nicht auf etwas sinnvolles zeigen, also komplett unbrauchbar sein...