# Java C++ Interprozess Kommunikation



## hagbard23 (1. Apr 2009)

Hallo zusammen,

Ich suche nach einer Möglichkeit, grosse Datenmengen sehr schnell sowohl zwischen 2 Java Prozessen alsauch zwischen einem Java und einem C++ Prozess zu tauschen. Wie mir scheint gint es keine gute Lib die so etwas out of the box kann.
Ich habe die Tage mit Sockets aller Art experimentiert, das ist schlicht zu lahm. Was wohl gehen könnte 
und schnell genug ist sind per jni gemappte shared memory blöcke. Das ist dann natürlich Platformabhängig.
Gibt es da einen einfachen Weg. Wohl eher nicht?
Fällt euch was ein?


----------



## Stefan S. (1. Apr 2009)

C++ ist eigentlich bereits plattformabhängig, naja zumindest solange man sich nicht strikt an ANSI C++ hält und frei kompilieren will.

Zu IPC hilft dir vielleicht

Inter Process Communication

und

CodeProject: Using Memory Mapped Files and JNI to communicate between Java and C++ programs. Free source code and programming help

weiter.


----------



## tuxedo (2. Apr 2009)

Soweit ich das währens meines Praxissemesters bemessen konnte, ist die Kommunikation zwischen Java und [allem anderen] via Socket-über-Localhost schon super schnell.

Hab da Megabyteweise Daten hin und her geschaufelt, so dass das Nadelöhr letztendlich doch wieder die Festplatte selbst war. 

Vielleicht war dein Socket-Code einfach nur ineffizient?


----------



## hagbard23 (2. Apr 2009)

hmmm....

hast du da vli noch ein beispiel...ich muß so 400 mb in ein paar sec rumschaufeln. Ich habe DataInputStreams benutzt.


----------



## tuxedo (2. Apr 2009)

Wo kommen denn die 400MB her? Liegen die schon im Speicher oder musst du die erst von der Platte/Datenbank/... lesen?

Die Daten ich ich damals zu schaufeln hatte waren CAN-Bus Nachrichten. Für die CAN-Bus-Karte hatte ich nur ein C-DLL, welche ich mit JNI auf Java gemapped habe. Für die Datenübertragung an sich (über JNI ging nur die Konfiguration/Steuerung) hab ich "nackige" Input/Output Streams benutzt. Data*Streams sollten aber ähnlich/genauso effizient sein.

Ich hatte hauptsächlich roh-bytes und ein paar Integer, Short und Longs die in so einer CAN-Message war. D.h. ich musste nix umständlich konvertieren, waren alles einfache byte-Operationen.

Auf Java Seite hatte ich einen Empfangsthread mit einem Ringpuffer. Auf C Seite ebenfalls. Ein weiterer Thread hat sich dann Daten aus dem Ringpuffer geholt und sie zur verarbeitung weitergereicht.
Gesendet hab ich synchron, ohne extra Thread (das hätte man dann ja noch außerhalb meiner API entkoppeln können).

Beispielcode hab ich leider keinen. Ist aber auch nicht weiter von nöten: Die Kommunikationslogik war absolut auf ein Minimum beschränkt (sollte einfach zu warten sein). 

Welche Transferraten hast du denn so erreicht? Und wo könnten bei dir noch Flaschenhälse sein (Datenbanken, Dateisysteme, ...)??

- Alex


----------



## hagbard23 (2. Apr 2009)

die daten liegen im speicher und bstehen hauptsächlich aus doubles/ integers und sollen einem anderen Prozess im selbem Speicher senden. Mit java standard rmi habe ich so 10mb pro sek. Das ist bis jetzt tatsächlich schneller als alle meine socket experimente.


----------



## tuxedo (2. Apr 2009)

Oha. Deine Integer/Doubles werden zwar durch den RMI Marshaller nicht sonderlich aufwendig serialisiert (einfach direkt in bytes gewandelt, so wie es auch der DataoutputStream macht), aber das sollte dennoch mit eigenen Sockets schneller gehen. Denn schließlich fällt der ganze Reflection-Kram dann weg ...

Ein Tipp: Schalte den Nagle-Algorithmus aus. Befehl weiß ich auswendig grad nicht mehr. Google einfach mal nach "nagle socket java". Das bringt dich dann erstmal näher an die RMI Implementierung ran.


----------



## hagbard23 (2. Apr 2009)

hab ich schon gemacht...


----------

