Inter-Prozess-Kommunikation, was gibt es für Möglichkeiten?

[Carl Rosenberger]

Hallo,

meine Frage ist im Titel eigentlich schon gestellt.

Ich kenne folgende Möglichkeiten, mit der sich zwei
separat gestartetet Java Prozesse unterhalten können:

(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher

Übersehe ich da was?

Für (3) brauche ich JNI, oder?

Viele Grüße,
Carl

[Christian Poecher]

Post by Carl Rosenberger
(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher

RMI und Object Request Broker wie CORBA, ferner Agententechnologie und
Webservices.

In einem Buch habe ich sogar davon gelesen das Java Mail API zur
Application Integration zu verwenden, aber das ist wohl nur sinnvoll in
sehr restriktiven Umgebungen mit bestehenden Anwendungen.

RMI oder (1) ist wahrscheinlich das Sinnvollste, hängt aber wohl von der
Anwendung ab.

chris

[Marco Lange]

Hi!

Post by Carl Rosenberger
meine Frage ist im Titel eigentlich schon gestellt.
Ich kenne folgende Möglichkeiten, mit der sich zwei
(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher
Übersehe ich da was?

Neben dem schon vorgeschlagenen RMI würde evtl. noch JMS in Betracht
ziehen für die asynchrone Kommunikation. Desweiteren könnte man glaube
ich über eine Art Kombination aus (2) und (3) nachdenken, nämlich Memory
Mapping. Keine Ahnung, ob das funktioniert, und wie performant das ist.

Post by Carl Rosenberger
Für (3) brauche ich JNI, oder?

Für reinen Shared Memory denke ich ja. Bei google hab ich was über JDSM
(Java Distributed Shared memory) gefunden, weiß nicht, ob das was für
Dich ist.

Viele Grüße,
Marco

[Carl Rosenberger]

Post by Marco Lange

Post by Carl Rosenberger
(1) eine lokale Socket-Verbindung über einen Port

Neben dem schon vorgeschlagenen RMI würde evtl. noch JMS in Betracht
ziehen für die asynchrone Kommunikation.

JMS und RMI operieren doch auch ausschließlich über normale
Sockets, oder?


Viele Grüße,
Carl

[Marco Lange]

Hi!

Post by Carl Rosenberger

Post by Marco Lange
Neben dem schon vorgeschlagenen RMI würde evtl. noch JMS in Betracht
ziehen für die asynchrone Kommunikation.

JMS und RMI operieren doch auch ausschließlich über normale
Sockets, oder?

Ok, ich hatte Deine Frage eher so verstanden, wie Du IPC machen kannst.
JMS und RMI arbeiten natürlich über Sockets, entweder direkt oder über
HTTP-Tunnel oder sowas. Wenn Du aber meintest, welche generelle
Verfahren es gibt, dann hast Du recht. JMS und RMI sind halt
Abstraktionsschichten.

Abgesehen von Sockets gibt es auch noch Pipes und zmd. unter Unix die
Unix-Sockets, wobei das im Prinzip auch Pipes sind.

Viele Grüße,
Marco

[Cybernd]

Post by Carl Rosenberger
(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher

Hmm eventuell JMS?

cybi

[Carl Rosenberger]

Post by Carl Rosenberger
Ich kenne folgende Möglichkeiten, mit der sich zwei
(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher
Übersehe ich da was?

Der Vollständigkeit halber, auch wenn es mir nicht die
Bohne weiter hilft:

(4) Den einen Prozess aus dem anderen mit Runtime.exec()
starten und System.in und System.out verwenden.


Viele Grüße,
Carl

[Marco Lange]

Hi!

Post by Carl Rosenberger
Der Vollständigkeit halber, auch wenn es mir nicht die

Schreib' doch mal, was Du genau willst. Vielleicht fallen dann auch die
Antworten detailierter aus.

Viele Grüße,
Marco

[Carl Rosenberger]

Post by Marco Lange
Schreib' doch mal, was Du genau willst. Vielleicht fallen dann auch die
Antworten detailierter aus.

(1) Ich habe zwei Java-Prozesse auf einer Maschine gestartet.

(2) Diese sollen sich miteinander unterhalten.

(3) Ein Teil der Nachrichten ist synchron, ein Teil asynchron.

(4) Performance ist kritisch.

(5) Wenn möglich sollen keine Ports nach aussen hin geöffnet sein.


Zu (1):
Um die optimale Geschwindigkeit zu erreichen, läuft idealerweise
alles in einer VM, dann geht die Kommunikation einfach im RAM
innerhalb der VM.

Allerdings ist es durchaus möglich, daß viel Server und viele
Clients (oder Peers, wenn man so will) gleichzeitig auf einer Maschine
laufen sollen. Da trägt es durchaus zur Stabilität bei, wenn man
sie einzeln runter und wieder hoch fahren kann. Dann muß man kein
Thread-Pooling machen und man muß sich auch nicht mit Memory-Leaks
rum ärgern, die es bei getrennten Sockets manchmal zu geben scheint.


Zu (5):
Das sollte eigentlich eine harte oder weiche Firewall perfekt regeln
können aber der Kunde will partout eine Lösung von mir haben. Well.
Ich habe ihm vorgeschlagen, daß die Sockets einfach keine Verbindung
von außen zulassen.


Viele Grüße,
Carl

[Wolfgang Zitzelsberger]

Post by Carl Rosenberger
Das sollte eigentlich eine harte oder weiche Firewall perfekt regeln
können aber der Kunde will partout eine Lösung von mir haben. Well.
Ich habe ihm vorgeschlagen, daß die Sockets einfach keine Verbindung
von außen zulassen.

BTW: Habe mir auch schon gewünscht für den Server eine definierte
IP-Addresse angeben zu können (z.B. 127.0.0.1).

Schöne Grüße,
Wolfgang

[Marco Lange]

Hi!

Post by Wolfgang Zitzelsberger
BTW: Habe mir auch schon gewünscht für den Server eine definierte
IP-Addresse angeben zu können (z.B. 127.0.0.1).

Funktioniert denn

ServerSocket(int,int,InetAddress)

nicht?

Viele Grüße,
Marco

[Wolfgang Zitzelsberger]

Post by Marco Lange
Funktioniert denn
ServerSocket(int,int,InetAddress)
nicht?

Schon, die Anmerkung bezog sich auf db4o.

Schöne Grüße,
Wolfgang

[Marco Lange]

Hi!

Post by Carl Rosenberger
(1) Ich habe zwei Java-Prozesse auf einer Maschine gestartet.
Um die optimale Geschwindigkeit zu erreichen, läuft idealerweise
alles in einer VM, dann geht die Kommunikation einfach im RAM
innerhalb der VM.
Allerdings ist es durchaus möglich, daß viel Server und viele
Clients (oder Peers, wenn man so will) gleichzeitig auf einer Maschine
laufen sollen. Da trägt es durchaus zur Stabilität bei, wenn man
sie einzeln runter und wieder hoch fahren kann. Dann muß man kein
Thread-Pooling machen und man muß sich auch nicht mit Memory-Leaks
rum ärgern, die es bei getrennten Sockets manchmal zu geben scheint.

Wie startet man denn mehrere Prozesse innerhalb einer VM? Einfach in
verschiedenen Threads die entsprechenden Main-Methoden aufrufen?

Post by Carl Rosenberger
(2) Diese sollen sich miteinander unterhalten.
(3) Ein Teil der Nachrichten ist synchron, ein Teil asynchron.
(4) Performance ist kritisch.
(5) Wenn möglich sollen keine Ports nach aussen hin geöffnet sein.
Das sollte eigentlich eine harte oder weiche Firewall perfekt regeln
können aber der Kunde will partout eine Lösung von mir haben. Well.
Ich habe ihm vorgeschlagen, daß die Sockets einfach keine Verbindung
von außen zulassen.

Ja genau, man kann Sockets ja an das "lo"-Interface (also 127.0.0.1) binden.

Ich denke, Sockets sind bei diesen Bedingungen einfach die beste Lösung,
da hinreichend schnell, asynchrone Nachrichten kannst Du ja durch ein
eigenes Message-Dispatching auf beiden Seiten der Kommunikation realisieren.

Viele Grüße,
Marco

[Michael Borgwardt]

Post by Marco Lange

Post by Carl Rosenberger
Allerdings ist es durchaus möglich, daß viel Server und viele
Clients (oder Peers, wenn man so will) gleichzeitig auf einer Maschine
laufen sollen. Da trägt es durchaus zur Stabilität bei, wenn man
sie einzeln runter und wieder hoch fahren kann. Dann muß man kein
Thread-Pooling machen und man muß sich auch nicht mit Memory-Leaks
rum ärgern, die es bei getrennten Sockets manchmal zu geben scheint.

Wie startet man denn mehrere Prozesse innerhalb einer VM?

Überhaupt nicht. Das ist unmöglich, man braucht für jeden Prozeß eine
eigene JVM.

Ich finde Carls Argumente auch nicht überzeugend. Thread-Pooling ist
keine Hexerei, und von Memory Leaks bei Sockets habe ich noch nie was
gehört. Vermutlich meint er, daß man vergessen kann, Sockets zu schließen,
und daß die dazugehören Ressourcen dann erst freigegeben werden, wenn
die Garbage Collection läuft (also evtl. deutlich später).

Es gibt jede Menge Web- und App-Server die in Java geschrieben und
stabil sind. Also können derartige Probleme nicht unvermeidlich sein.

[Carl Rosenberger]

Post by Marco Lange
Wie startet man denn mehrere Prozesse innerhalb einer VM? Einfach in
verschiedenen Threads die entsprechenden Main-Methoden aufrufen?

Wenn die Applikation dafür designed ist (bei mir), geht das, ja.

Wenn nicht, kann es Probleme mit statischen Feldern geben. In diesem
Fall hat man unter Umständen die Möglichkeit, durch die Verwendung
mehrerer unabhängiger ClassLoader zu tricksen.

Post by Marco Lange

Post by Carl Rosenberger
Das sollte eigentlich eine harte oder weiche Firewall perfekt regeln
können aber der Kunde will partout eine Lösung von mir haben. Well.
Ich habe ihm vorgeschlagen, daß die Sockets einfach keine Verbindung
von außen zulassen.

Ja genau, man kann Sockets ja an das "lo"-Interface (also 127.0.0.1) binden.

Zum Beispiel.

Post by Marco Lange
Ich denke, Sockets sind bei diesen Bedingungen einfach die beste Lösung,
da hinreichend schnell, asynchrone Nachrichten kannst Du ja durch ein
eigenes Message-Dispatching auf beiden Seiten der Kommunikation realisieren.

So ist das ja auch schon alles gebaut und fertig.

Da es ohnehin wiederum andere Kunden gibt, die die Kommunikation über
MOM (Message Oriented Middleware, zum Beispiel IBM MQ) umleiten wollen,
ist es wohl am besten, die Kommunikationsschicht pluggable zu bauen,
dann kann sich jeder sein eigenes Pfeifchen (pipe) drehen, der will.

Danke!


Viele Grüße,
Carl

[Carl Rosenberger]

Post by Carl Rosenberger

Post by Marco Lange
Wie startet man denn mehrere Prozesse innerhalb einer VM? Einfach in
verschiedenen Threads die entsprechenden Main-Methoden aufrufen?

Wenn die Applikation dafür designed ist (bei mir), geht das, ja.

Michael hat die Terminologie korrigiert, natürlich hat er Recht.

Im Rahmen meiner Applikation geht "Prozess" aber halbwegs durch:
Ein Server wäre ein einzelner "Prozess", ein Client auch.


Viele Grüße,
Carl

[Michael Schuerig]

Post by Carl Rosenberger
(3) gemeinsam genutzer Speicher
Übersehe ich da was?
Für (3) brauche ich JNI, oder?

Vielleicht tut es auch schon java.nio.* Ich habe damit noch nicht
gearbeitet, aber offensichtlich ist es damit möglich, Dateien in den
virtuellen Speicher abzubilden (sprich memory mapped files). Ob die
Speicherbereiche allerdings zwischen Prozessen geteilt werden können,
scheint nicht ganz klar zu sein. Siehe

http://forum.java.sun.com/thread.jsp?thread=551950&forum=54&message=2699675

Michael

[Bernd 'Nexos' Dutkowski]

Post by Carl Rosenberger
meine Frage ist im Titel eigentlich schon gestellt.
Ich kenne folgende Möglichkeiten, mit der sich zwei
(1) eine lokale Socket-Verbindung über einen Port
(2) gemeinsam verwendete Dateien
(3) gemeinsam genutzer Speicher
Übersehe ich da was?

Dazu gibt es noch:

* Message-Queues
* (Named) Pipes
* MPI und Freunde

Da Deine Frage eh in Richtung DBs gerichtet ist, kann ich Dir fuer
lokalen Datenaustausch Message-Queues und fuer Datenaustausch innerhalb
eines Clusters MPI und Freunde nahelegen. Zumindest wuerde ich das so
machen ("tm").

bernd

[Carl Rosenberger]

Post by Bernd 'Nexos' Dutkowski
* Message-Queues

Damit meinst Du JMS ?

Post by Bernd 'Nexos' Dutkowski
* (Named) Pipes

Das ist Unix-spezifisch?

Das heißt ich brauche auch eine Bibliothek, die ich
über JNI anspreche?

Post by Bernd 'Nexos' Dutkowski
* MPI und Freunde

Mit MPI habe ich mich noch nie beschäftigt.
Da brauche ich wohl erstmal eine MPI-Implementation.

Post by Bernd 'Nexos' Dutkowski
Da Deine Frage eh in Richtung DBs gerichtet ist, kann ich Dir fuer
lokalen Datenaustausch Message-Queues und fuer Datenaustausch innerhalb
eines Clusters MPI und Freunde nahelegen. Zumindest wuerde ich das so
machen ("tm").

Ich will keinen Zoo von Fremdprogrammen, ich will kein JNI und ich
brauche eine Plattform-kompatible Lösung, die ich auch von .NET aus
verwenden kann.

Ich war vor meinem Posting der Meinung, daß Socket-Verbindungen da
der einzige Weg sind, ich würde das nur gerne verifiziert haben.


Vielen Dank!

Viele Grüße,
Carl

[Michael Borgwardt]

Post by Carl Rosenberger

Post by Bernd 'Nexos' Dutkowski
* (Named) Pipes

Das ist Unix-spezifisch?

Ja.

Post by Carl Rosenberger
Das heißt ich brauche auch eine Bibliothek, die ich
über JNI anspreche?

Nein. Eine named Pipe ist im Grunde nichts anderes als eine
Datei, die wie eine FIFO-Queue funktioniert. Man kann also mit
den ganz normalen java.io-Mechanismen drauf zugreifen
(Naja, RandomAccessFile dürfte nicht klappen).

[Carl Rosenberger]

Post by Michael Borgwardt
Nein. Eine named Pipe ist im Grunde nichts anderes als eine
Datei, die wie eine FIFO-Queue funktioniert. Man kann also mit
den ganz normalen java.io-Mechanismen drauf zugreifen
(Naja, RandomAccessFile dürfte nicht klappen).

Was klappt dann ?

Hier habe ich einen Vorschlag gefunden:
http://www.jguru.com/faq/view.jsp?EID=464749

Das finde ich nicht so toll.


Carl

[Michael Borgwardt]

Post by Carl Rosenberger

Post by Michael Borgwardt
Nein. Eine named Pipe ist im Grunde nichts anderes als eine
Datei, die wie eine FIFO-Queue funktioniert. Man kann also mit
den ganz normalen java.io-Mechanismen drauf zugreifen
(Naja, RandomAccessFile dürfte nicht klappen).

Was klappt dann ?

Alles andere, also sämtliche Filebasierten Stream- und Reader-Klassen.

Post by Carl Rosenberger
http://www.jguru.com/faq/view.jsp?EID=464749
Das finde ich nicht so toll.

Du hast den mittleren Punkt übersehen, bzw. den Rest nicht verstanden.

Eine named Pipe ist für Java einfach eine Datei, in die es schreiben kann, und
aus der es lesen kann. Und das was zuerst reingeschrieben wird, wird auch zuerst
gelesen.

Nur für das Betriebssystem ist es was anderes, deswegen braucht man ein spezielles
Kommando um so ein Ding zu erzeugen, und das wird von Java natürlich nicht
unterstützt. Und es werden die geschriebenen Daten nur gepuffert, nicht aber
wirklich auf die Platte geschrieben, deswegen kann man nicht darin hin- und
herspringen wie RandomAccessFile es ermöglichen würde.

Daß der Standardinput und -output von Prozessen unter Unix ebenfalls über solche
Pipes implementiert ist (die dann aber keinen Namen haben und nach außen nicht
sichtbar sind) ist hier gar nicht von Belang.

[Stefan Matthias Aust]

Post by Carl Rosenberger

Post by Bernd 'Nexos' Dutkowski
* (Named) Pipes

Das ist Unix-spezifisch?

Nein. Neuere Windows-Versionen können das auch. Siehe etwa
http://www-106.ibm.com/developerworks/linux/library/l-rt4/?open&t=grl,l=252,p=pipes

Post by Carl Rosenberger
Das heißt ich brauche auch eine Bibliothek, die ich
über JNI anspreche?

Ja. Öffnen und Nutzen geht wie mit anderen Dateien, nicht aber das
Anlegen oder Löschen. Trotzdem ist auf einem Rechner wohl effizienter
als TCP/IP-basierte Sockets.

Post by Carl Rosenberger
Ich will keinen Zoo von Fremdprogrammen, ich will kein JNI und ich
brauche eine Plattform-kompatible Lösung, die ich auch von .NET aus
verwenden kann.

Was du in Java per JNI kannst, sollte in .NET mit P/Invoke gehen :)
Wahrscheinlich kannst du aber per .NET unter Windows direkt mit den
Named Pipes arbeiten. Siehe
http://www.codeguru.com/Csharp/Csharp/cs_misc/sampleprograms/article.php/c7259/


bye

[Bernd 'Nexos' Dutkowski]

Post by Carl Rosenberger

Post by Bernd 'Nexos' Dutkowski
* Message-Queues

Damit meinst Du JMS ?

Nein, auch Unix-IPC (hab ich auch erst vor nem Jahr kennengelernt) dazu
gibt es sicher schon fertige Java-Adapter.

bernd