Wege zum Datenaustausch zwischen zwei Programmen
-
Hallo,
ich versuche gerade eine Übersicht über die verschiedenen Wege zur Kommunikation zwischen zwei Programmen zu schreiben. Leider ist das alles SEHR viel zu lesen.Die wichtigsten Punkte sind:
- Shared memory
Schnell
- socket
Auführung auf fremdem Rechner
- pipe
named pipes, unnamed pipes machen keinen Sinn .. denke ich. Möglicherweise auch über Netzwerk.
- PVM
nur zur Vollständigkeit. Stehen keine freien Rechner in der Ecke!Die Anwendbarkeit der einzelnen Verfahren habe ich bereits beschrieben. Was ansteht ist die Praxis.
Wie lange dauert es für jemand, der sich noch nicht mit Interprocess-Communication beschäftigt hat, eine Schnittstelle nach diesen Prinzipien aufzubauen? Er sollte aber bereits fortgeschrittene Programmierkenntnisse besitzen. (C++, Windows)
Wie hoch ist der Aufwand für eine Synchronisierung des Datenaustausches. Das ganze soll für ein Simulationsprogramm sein, welches immer zwei Schritte wiederholt. (Simulate - Validate) In diesen Schritten soll der Datenaustausch stattfinden.
Das sind die offenen Fragen, für deren Antwort ich aber die einzelnen Verfahren ganz durcharbeiten muss. Wenn sich jemand bereits damit beschäftigt hat, würde mir das viel Zeit sparen.
-
Du hast
- Windows Messages
- Dateien/Datenbanken
- COM /COM+
vergessen.Grundsätzlich hängt viel vom Datenvolumen ab.
-
Stimmt, danke.
Dateien habe ich tatsächlich vergessen. Hatte ich aber auf meiner Liste stehen.
COM/COM+ ist die Einbettung von OLE Objekten in die eigene Anwendung. Wie schnell ist die Kommunikation?
Windows Messages ist ein langsameres Verfahren, welches über Zustände des System informieren soll?Das Datenvolumen ist in diesem Fall recht klein. Es werden 12 Werte berechnet, die als Randbedingungen an ein FEM Simulator geschickt werden soll. Dieser berechnet anhand einer zeitdiskreten Simulation die aktuelle Temperaturverteilung im physikalischen Modell.
Es werden also kleine Datenmengen verschickt, der Datenaustausch muss dabei aber sehr schnell sein.
-
- COM zwischen Projekt richtet sich klar nach der Datenmenge. Bei so kleinen Objekten ist COM hinreichend schnell. Wenn es um eine DLL im Prozess geht ist COM sehr schnell.
- Windows Nachrichten wie z.B. WM_COPYDATA zu verwenden ist nicht langsam. Eher schnell. Oft schneller als Pipes bei geringen Datenmengen. Wenn der Rteurnwert in ein LPARAM passt dann ist es extrem einfach WM_COPYDATA zu verwenden und den 4byte retrunwert zu Zweckentfremden. Sonst als Antwort wieder WM_COPYDATA zurück. Das ganze setzt aber eine Message-Loop voraus.
- Shared Memory mit ein paar Syn Objekten geht natürlich auch.Die Frage ist ob z.B. die Daten auflaufen dürfen. Oder ob jede Anfrage sofort synchron beantwortet werden muss.
-
Eine synchrone Abarbeitung ist aufgrund der zeitdiskreten Berechnung unumgänglich. Wartezeiten größer als die Berechnungszeit sind nicht sinnvoll.
Für das Zusatzmodul muss ich mehr Zeit für die korrekte Berechnung verwenden als für eine optimale Kommunikation. Deshalb kann ich nicht mehrere Verfahren ausprobieren.
Deshalb denke ich zur Zeit an Shared Memory.
-
Shared Mem in einer DLL. Ist schnell und einfach umzusetzen.
Sync. muss aber betachtet werden.
-
Der aufrufende Prozess ist eine DLL. Das mit shared Memory habe ich schon ausprobiert, hat aber nicht wirklich funktioniert. Bei meiner Suche im Internet, habe ich zwar einige Beispiele gefunden. Darunter vorbereitete Klassen. Aber in keiner Quelle stand ausführlich etwas über Methoden zur Synchronisierung UND schnelle Ausführung.
-
Aber wenn alles in einem Prozess ist, dann ist es doch wurscht. Dann brauchst Du gar keinen IPC!
-
Der aufrufende Prozess ist eine DLL, der PDE Solver ist ein extra Programm(MFC,exe).
Ablauf ist folgender:
1. elektrisches Netzwerk wird berechnet
2. elektrische Leistung geht als Parameter an den PDE Solver
3. Berechnung des Gittermodell für den nächsten Zeitschritt
4. Temperatur von definiertem Punkt im Gittermodell geht zurück ans elektrische Netzwerk.
5. Interpolation der Kennlinien für das elektrische Netzwerk mit neuer Temperatur
weiter bei 1.
-
Ein Prozess kann keine DLL sein!?!
Beschreibe doch mal alles so dass man auch verstehen kann wer nu genau mit wem kommunizieren soll -- was läuft auf welchem Rechner, in welchem Prozess, in welchem Thread?
Und wer wird von wem wann und warum aufgerufen?
