# mehrere Programme miteinander kommunizieren lassen



## Dariusum (28. Sep 2007)

Hallo,
 ich habe mein Programm auf mehrere Teilprogramme aufgeteilt da ich dessen teilaufgaben potentiell auf verschiedenen Rechnern machen möchte. Da die Teile viel miteinander kommunizieren müssen habe ich sie mittels TCP verbunden. Da ichd as Programm auch komplett auf einer Maschiene laufen lassen möchte würde ich gerne noch eine 2. Verbindungsart haben. 
Ich weiss das man sich in c einfach ein Stück Arbeitspeicher geben lassen kann auf das dann die verscheidenen Programme zugreifen können. Sowas in der Richtung würde mir vorschweben hat jemand ne Ahnung wie ich sowas implementiert kriege?


----------



## AlArenal (28. Sep 2007)

Gar nicht, weil du in Java keinen direkten Zugriff auf den Speicher hast und jede Anwendung in ihrer eigenen VM läuft.

Was versprichst du dir am Ende davon?


----------



## Wildcard (28. Sep 2007)

gar nicht.


----------



## Dariusum (28. Sep 2007)

das meine Kommunikation schneller wird
dachte daran über ein file die prozesse miteinander kommunizieren zu lassen so lange das im Arbeitspeciher gehalten wird müsste das ganze ziemlich schnell ablaufen vorallem da mir ja potentiell eine schreibrichtung reichen würde(man nehme 2 files) ist nur die frage wie dasnn die performance aussieht.


----------



## Dariusum (28. Sep 2007)

AlArenal hat gesagt.:
			
		

> Gar nicht, weil du in Java keinen direkten Zugriff auf den Speicher hast und jede Anwendung in ihrer eigenen VM läuft.
> 
> Was versprichst du dir am Ende davon?



durch den c befehl wird das "Stück Speicher" in den jeweiligen Adressraum reingebildet also wäre eine ähnliche Arbeitsweise auch für java denkbar. Muss ja net geneu dieser Befehl sein nur performanter als tcp


----------



## AlArenal (28. Sep 2007)

Dariusum hat gesagt.:
			
		

> das meine Kommunikation schneller wird
> dachte daran über ein file die prozesse miteinander kommunizieren zu lassen so lange das im Arbeitspeciher gehalten wird müsste das ganze ziemlich schnell ablaufen vorallem da mir ja potentiell eine schreibrichtung reichen würde(man nehme 2 files) ist nur die frage wie dasnn die performance aussieht.



So lange du nichst feststellen kannst, dass die Kommunikation derzeit ein signifikanter Bottleneck ist, macht eine Optimierung auf blauen Dunst auch wenig Sinn. Sollte die Kommunikation das Problem sein, ist dein Design suboptimal, weil die einzelnen Anwendungen nicht autark genug arbeiten können.

If it ain't broke, don't fix it.


----------



## Dariusum (28. Sep 2007)

ist eine Pipes and Filters Architektur und meine Kommunikation ist mein Flaschenhals


----------



## AlArenal (28. Sep 2007)

Dann sollte das Ziel sein das gesamte System so zu entwerfen, dass die Kommunikation zwischen getrennten Komponenten auf ein Minimum beschränkt werden kann. Ggf. muss dazu die Aufteilung komplett überdacht werden.

Alles andere würde m.E. am Grundproblem vorbei gehen.


----------



## Dariusum (29. Sep 2007)

Das Programm hat generell ein relativ hohes datenaufkommen wesahlb eine umstruckturierung die Kommunikationsmenge nicht reduzieren würde. Und das das Programm in mehrere aufgeteilt wird hat zum einen den Grund der skalierbarkeit und zum anderen den Grund der Sicherheit


----------



## byte (29. Sep 2007)

Dariusum hat gesagt.:
			
		

> Und das das Programm in mehrere aufgeteilt wird hat zum einen den Grund der skalierbarkeit und zum anderen den Grund der Sicherheit


Aber wenn jetzt die Datenübertragung der Flaschenhals ist, solltest Du drüber nachdenken, ob sich die Skalierbarkeit wirklich verbessert hat. Und ob die Sicherheit gewährleistet ist, wenn Du die Daten unverschlüsselt überträgst, ist auch anzuzweifeln.

Du könntest UDP nutzen. Das ist zumindest schneller als TCP. Hat jedoch auch andere Nachteile und ist für große Datenmengen nicht wirklich empfehlenswert.


----------



## Murray (29. Sep 2007)

Wenn alle Programmteile auf einem Rechner laufen: lass sie doch in einer VM laufen; dann kann die Kommunikation über direkte Calls passieren.


----------



## Dariusum (1. Okt 2007)

Das Problem ist das der Aufbau so sien soll das das Programm auf mehrere Rechner aufgeteilt werden kann . Um die Teile dann zu Verbinden ist natürlich TCP das Mittel der Wahl da UDP für einen beständigen Datenstrom nicht konzipiert ist. Diese Aufteilung auch bei eienr nichtverteilten Variante beizubehalten hat den Vorteil das ich wenn ich das Programm doch vertilen möchte einfach nur den entsprechenden Programmteil abschießen und woanders wieder starten muss und anmelden bei den anderen Teilen natürlich. Desweiteren ist durch die starke Trennung gewährleistet das evtl Programmierfehler nur lokal zum tragen kommen und nicht das komplette Programm töten können. Über den Vorschlag von Murray muss ich mich erstmal belesen, hört sich aber interessant an.


----------



## tuxedo (1. Okt 2007)

Du kannst IMHO getrost auf eine Localhost-Verbindung setzen. AFAIK wird so eine Verbindung mehr oder weniger direkt über den Arbeitsspeicher gemapped (genau weiß ich es nicht, aber ich hab sowas "gehört"). Zumindest lassen sich da unheimlich viel Daten drüber schaufeln. 

Ich hab vor etwa 2 Jahren ein System entwickeln müssen das möglichst eine Treiber-DLL an Java anbindet. Diese DLL hat eine CAN-Bus-Karte (Can-Bus kommt unter anderem in größeren BMW, Mercedes, Audio ... zum Einsatz) bedient und Daten zwischen PC und CAN-Bus transferiert. Da JNI für die Datenübertragung zwischen C und Java zu langsam war hab ich auf eine localhost Socketverbindung zurückgegriffen. Eine andere Möglichkeits gabs für mich auch gar nicht. Jedenfalls hab ich die für CAN-Bus nötige Performance damit rausholen können. 

Kannst ja mal ein Test-Tool schreiben und Daten via localhost verschiffen um zu sehen ob's schnell genug für dich ist. 

- Alex


----------

