Pipe zu Windows Programm

[gonorthk]

Ich habe ein kleines Windowsprogramm, dass Daten zu und von einem USB-Gerät schickt und liest.
Ich würde gerne eine Art Pipe oder Message Queue zwischen diesem Programm und meinem Java-Programm einrichten, damit ich die gelesen Daten im Java-Programm zur Verfügung habe bzw. auch Daten aus dem Java-Programm (über das Windowsprogramm) an das USB-Gerät senden kann.
Gibt es eine Möglichkeit dies, außer über Textdateien, zu lösen?

 

[The_S]

JNI!?

 

[gonorthk]

Danke, das hört sich schon einmal gut an.

 

[tuxedo]

Socketverbindung wäre auch noch ne möglichkeit ... Wenn es um schnellen Datentransfer geht, bist du damit vermutlich auch schneller als mit JNI ...

Alternativ: JNA (http://jna.dev.java.net)

- Alex

 

[Guest]

Hmm, also Aufrufe an die API "DeviceIoControl" unter Windows sind mit den Bibliotheken wohl kaum zu realisieren...

 

[tuxedo]

Ist doch Teil von kernel32.dll? Oder hab ich da was verpasst? JNA kann soweit ich das bis jetzt selbst probiert hab, mt nahezu jeder beliebigen DLL sprechen ...

Und inbesondere mit den Windows-DLLs gibts da keine großen Probleme.

Und wenn nicht: Dann halt doch JNI, nur eben mit dem "Umweg" über einen selbstgeschrieben Wrapper in C/C++ ...

- Aex

 

[Murray]

Socketverbindung wäre auch noch ne möglichkeit ... Wenn es um schnellen Datentransfer geht, bist du damit vermutlich auch schneller als mit JNI ...

Wieso sollte es schneller sein, Daten über das Netzwerk zu verschicken, als sie innerhalb des gleichen Prozesses behalten?

 

[tuxedo]

localhost != Netzwerk ;-) Oder so ...

Wenn du viele Daten von C nach Java und umgekehrt schicken musst, sind viele Calls in der JVM von nöten. Wie und wo genau kann ich dir nicht sagen.
Musste in meinem Praxissemester bei Daimler einen Wrapper für einen Treiber basteln der als DLL vorlag. Der Treiber war für ein PC-Card CAN-Bus Interface.
Vor mir hat das schonmal jemand gemacht. Aber komplett mit JNI. Fazit: Wenn viel auf dem Bus los war (>10MB/sek), konnten die Daten nicht schnell genug gelesen werden. Nehme an das Lag an irgendwelchen Callback-Geschichten von C nach Java via JNI.

Ich hab das dann halb mit JNI und halb mit Sockets gelöst: Die DLL wurde via JNI angesteuert, aber die Daten kamen via Socket über localhost. Alles andere brachte nicht die gewünschte Performance.

Aber das war noch zu Java 1.5 Zeiten. Vielleicht ist das mittlerweile besser/schneller geworden.

- Alex

 

[Murray]

localhost != Netzwerk ;-) Oder so ...

Das Netzwerk wird zwar nicht verwendet, der IP-Stack aber schon - man verwendet also ein Subsystem, welches Pakete verwaltet, irgendwelche Headerinformationen ergänzt, die Reihenfolge der Pakete überwacht und, und, und...

 

[Murray]

Wenn du viele Daten von C nach Java und umgekehrt schicken musst, sind viele Calls in der JVM von nöten. Wie und wo genau kann ich dir nicht sagen.

Kühne Behauptung (und genausowenig wie Deine belegt): was auch immer an Overhead notwendig ist, um bei native Calls zwischen C und Java irgendwelche Typen hin- und herzuwandeln, wird auch bei der Verwendung von Sockets notwendig sein.
Dass es Implementierungen gibt, die JNI ineffizient verwenden, ist natürlich unbestritten - daraus sollte man aber nicht schließen, das JNI selbst irgendwie langsam wäre.

 

[tuxedo]

Ich sagte ja,

".. bist du damit vermutlich auch schneller als mit JNI ...".

Und

"Wie und wo genau kann ich dir nicht sagen."

Die Typwandlung brauch man so oder so klar. Mir hats mein Oberhaupt damals so versucht zu erklären, dass für die generelle Kommunikation zwischen C und Java mittels JNI mehr Calls in der JVM notwendig sind, was mehr Overhead erzeugt, als wenn ich via Sockets die JVM "öffne".

Ob da tatsächlich was dran ist, wie gesgat: Kein Plan. Hatte bisher nicht die Zeit dem weiter nachzugehen.

"Das Netzwerk wird zwar nicht verwendet, der IP-Stack aber schon - man verwendet also ein Subsystem, welches Pakete verwaltet, irgendwelche Headerinformationen ergänzt, die Reihenfolge der Pakete überwacht und, und, und..."

Dachte mir das sowas kommt. Mit dem "Oder so" war eher gemeint: "Da wird die Netzwerkkarte nicht involviert".

Gruß
Alex

 

[Murray]

IMir hats mein Oberhaupt damals so versucht zu erklären, dass für die generelle Kommunikation zwischen C und Java mittels JNI mehr Calls in der JVM notwendig sind, was mehr Overhead erzeugt, als wenn ich via Sockets die JVM "öffne".

Ob da tatsächlich was dran ist, wie gesgat: Kein Plan. Hatte bisher nicht die Zeit dem weiter nachzugehen.

Die Erklärung finde ich nicht so überzeugend, denn was passiert denn in der VM, wenn man Sockets verwendet? Letztendlich muss die VM doch auch Betriebssystemroutinen aufrufen, und das muss ja wohl per JNI passieren - insofern würde der hier postulierter Overhead bei der Verwendung von native Code doch ebenfalls zuschlagen (wenn es ihn denn überhaupt gibt).

 

[tuxedo]

Ein wenig gegoogelt und ich bin unter anderem auf das hier gestoßen (gibt noch mehr material dazu):

A JNI call is very slow, in the order of .5 to 1.0 microseconds, the equivalent of pages of linear Java code to do a simple method call. You would think there would be a tiny generated machine code thunk to bridge between Java and C. Not so — at least in any JVM I know of, Java branches to some general purpose code that interpretively constructs the C parameters. This code is not highly optimised. It seems Sun wants to strongly discourage you from using native methods just for speed. This means you don’t want to hop back and forth between Java and C, but rather to go to C, and stay there a decently long time before returning. This means that you can’t use C to speed up short operations, only long ones, because of the overhead tacked on in getting to C wipes out any savings.

Oder hier:

...
D_L_Kumar:
I did some performance experiments and found that JNI version is more than 10 times slower than that of Java.
I am making lot of calls from C++ to Java and data transfer also. Is this the reason that is causing slowness.
...
cowwoc:
In general, you want to reduce the number of times you cross the JNI boundary. Try invoking methods that return a lot of data at once, as opposed to say invoking a method once per byte read.
...
D_L_Kumar:
... Yeah it worked for me. ...

Für Megabyteweise eingehender Datentransfer der möglichst zeitnah auf der Java-Seite verfügbar sein soll, bzw. auch umgekehrt, Daten die von Java gesendet werden und auf C-Seite möglichst zeitnah verarbeitet/gesendet werden sollen, trifft der Ratschlag, lieber eine Socketverbindung zu benutzen, vermutlich doch zu.

Klar, man kann auch eine recht große Puffergröße wählen um die Anzahl an Calls von C nach Java und uzmgekehrt zu vermindern, aber gerade beim Filetransfer ist es Blödsinn riesige Puffergrößen einzustellen. Werte deutlich über 8k finde ich für ein System das schnell auf Daten reagieren muss, doch ziemlich viel.

In diesem Sinne, besser beides (JNI und Sockets) ausprobieren, und sich nicht darauf verlassen dass "JNI es schon regeln wird"...
In meinem Fall, wo wirklich locker mal 10MB/sek angefallen sind, war JNI allein in der Tat zu langsam.

Gruß
Alex

 

[tuxedo]

Die Erklärung finde ich nicht so überzeugend, denn was passiert denn in der VM, wenn man Sockets verwendet? Letztendlich muss die VM doch auch Betriebssystemroutinen aufrufen, und das muss ja wohl per JNI passieren - insofern würde der hier postulierter Overhead bei der Verwendung von native Code doch ebenfalls zuschlagen (wenn es ihn denn überhaupt gibt).

Ich bezweifle dass SUN alle nativen Calls selbst mit DER JNI-Technik abgedeckt hat. Denke die haben da eine etwas modifizierte, JNI ähnlich Technik eingesetzt, die nicht ganz so nach "Eierlegende Wollmilchsau" Schreit und deshalb etwas performanter ist, eben weil sie nicht ganz so offen und flexibel sein muss.
Beweisen kann ichs (noch) nicht ;-)

- Alex

 

[Murray]

Ich bezweifle dass SUN alle nativen Calls selbst mit DER JNI-Technik abgedeckt hat. Denke die haben da eine etwas modifizierte, JNI ähnlich Technik eingesetzt, die nicht ganz so nach "Eierlegende Wollmilchsau" Schreit und deshalb etwas performanter ist, eben weil sie nicht ganz so offen und flexibel sein muss.
Beweisen kann ichs (noch) nicht ;-)

Wenn Du da etwas finden solltest, würde mich das interessieren. Vorstellen kann ich mir das allerdings nur schwer - denn wie könnte der Übergang zwischen Bytecode und native Code anders passieren als per JNI?

 

[tuxedo]

Klar, wenn ich was finde berichte ich es natürlich.

Weswegen ich diese Vermutung aufgestellt habe:

JNI ist doch ein breit gefächertes Interface mit dem ich nahezu _alles_ machen kann. Und wie die Erfahrung zeigt, müssen Dinge, die nahezu _alles_ können, irgendwo abstriche machen. Und wie man aus den zwei Links die ich gepostet hab sieht, scheint das bei der Performance für viele kleine Calls passiert zu sein.

Damit die JVM, die vermutklich sehr viele nativen Calls macht (gerade beim Zeichnen, bei der Soundausgabe oder bei der Netzwerkkommunikation etc...) dieses "Problem" inne hat, denke ich dass ein etwas abgewandeltes JNI benutzen, das etwas performanter ist. Wie ich darauf komme?

Unter anderem deswegen

at least in any JVM I know of, Java branches to some general purpose code that interpretively constructs the C parameters. This code is not highly optimised.

Da die nativen Calls, die in der JVM schon drin sind und auch im "alltäglichen JVM Leben" benutzt werden, VORHER schon bekannt sind, denke ich, gabs da gute Möglichkeiten das zu optimieren und "fest einzubauen", statt alles nochmal zur Laufzeit zu interpretieren (bezogen auf "interpretively constructs the C parameters") wie es JNI, wie wir es kennen, macht.

- Alex

 

[Guest]

Also JNA unterstützt DeviceIoControl in den Paketen jna.jar und examples.jar leider nicht.