Windows (Service) Hooking

[WindowsHook]

Guten Morgen,

bevor ich meine eigentliche Frage stelle möchte ich folgendes anmerken :

Bei meiner Frage handelt es sich eigentlich eher um die mögliche Machbarkeit als um einen produktiven Einsatz.

Zur Frage selbst :

Es gibt verschiedene Tools mit denen es möglich ist Java-Programme als Windows-Service laufen zu lassen. Soweit ist das auch kein Problem. Meine Frage bezieht sich jetzt auf die Kommunikation mit diesen.

Überlegung :

Der Service soll beim Start mit JNI einen "Hook-Point" erstellen. Also einen Punkt in den sich später eine weitere DLL "einhooken" kann. Zusätzlich soll dieser "Hook-Point" dann eine bi-direktionale Callback-Kommunikation ermöglichen, also das ich aus einer "Kontroll-Anwendung" Daten an den Service schicken kann und von diesem auch wieder Daten erhalte oder umgekehrt. Dabei soll das ganze a-synchron laufen und wenn möglich direkt mit Java-Objekten.

Problem :

Ich "spreche" leider kein C mit dem es realisierbar wäre.

Ich habe mich bereits soweit erkundigt das ich weis das es zwei "Teilnehmer" geben muss : der eine ist der Service selbst der einen "Hook-Point" anbietet, der andere ist die "Kontroll-Anwendung" die sich dort "einhookt" und so den Service steuern kann.

Das man sowas eigentlich nicht mit Java macht ist mir bewusst, aber ich sagte ja das es mir hier eher um die Machbarkeit als um einen sinnvollen Einsatz geht.


Nun daher meine Frage an die C-Profis : wie müsste sowas implementiert werden das es auch mit JNI funktioniert ? Auch bitte ich, wenn möglich, um lauffähigen Beispiel-Code den man anpassen kann da ich wie gesagt keine Ahnung von C habe.

Der Sinn dahinter soll lediglich sein eine Kommunikation zwischen zwei von einander unabhängigen Java-Programmen in getrennten VM-Instanzen auf Java-Objekt-Ebene zu ermöglichen ohne auf Dinge wie "Sockets" zurückgreifen zu müssen.

Ich hoffe das jemand meine Idee versteht und umsetzen kann. Wenn irgendwelche Informationen fehlen oder etwas unklar ist versuche ich es natürlich noch mal genauer zu erklären.

 

[Gast2]

Der Sinn dahinter soll lediglich sein eine Kommunikation zwischen zwei von einander unabhängigen Java-Programmen in getrennten VM-Instanzen auf Java-Objekt-Ebene zu ermöglichen ohne auf Dinge wie "Sockets" zurückgreifen zu müssen.

gibt es einen Grund dir die Finger mit JNI und C zu brechen und nicht Sockets zu nehmen, außer weil du "Angst" vor Sockets hast?

 

[KSG9|sebastian]

Wenn du Sockets nicht magst dann nimm RMI, fahr nen Embedded-Jetty hoch und nimm Spring Remoting oder nimm eine Datei zur "Kommunikation" oder (...viele andere Möglichkeiten...).

Wenn du absolut kein C kannst wirst du mit Beispielcode auch nix anfangen..denn der wird zu 80% in C sein da der Java-Teil an sich ja nichts macht.

 

[WindowsHook]

Hallo,
erstmal danke für die Antworten.

zu "mogel"

Nein, eigentlich gibt es keinen "sinnvollen" Grund auf sowas einfaches wie eine Socket-Verbindung zu verzichten, und "Angst" habe ich auch nicht davor. Mir geht es hier lediglich darum ob es möglich wäre, gleich welchen Aufwand sich man machen würde (wobei ich glaube das "gebrochene Finger" schon gut andeuten in welch irrsinnige Richtung das wohl geht).


zu "KSG9|sebastian"

Also die Kommunikation über eine Datei scheidet aus (auch wenn in meinem Fall dank Java7 und NIO.2 machbar). Auch mal eben einen RMI-Server zu starten dürfte wohl was den Resourcen-Verbrauch angeht bei dieser Sache nicht gerechtfertigt sein.
Zum "überhaupt kein C" : ist vielleicht nicht ganz richtig ausgedrückt. Über elementare Grundlagen verfüge ich schon, zumindest reicht es dafür um C-Code halbwegs zu verstehen und teilweise sogar dafür einiges nach Java zu portieren (Beispiel : ich habe die in RFC4648 verlinkte C99-Implementierung von Base64 erfolgreich auf Java portiert). In so fern dürfte es auch dafür reichen zumindest im groben zu verstehen wie es funktionieren würde. Und zur Not gibt es ja immer noch Google und API-Docs.


Ich versuche es vielleicht noch mal an einem sehr einfachen Schema zu erklären :

Service > start > über JNI einen "Hook-Point" bereitstellen > normaler Betrieb
(zufälliger Zeitpunkt)
Start einer weiteren Anwendung > laden der "Hook-Lib" > "einhooken" in den vom Service gestellten "Hook-Point" > a-synchroner bi-direktionaler Datenaustausch

Mir ist bewusst dass das Ganze eher wenig bis gar keinen Sinn hat, aber wie erwähnt geht es mir hier lediglich um die Machbarkeit.
Außerdem die Frage : wie würde man so etwas "best practice" im produktiven Einsatz gestallten ? Würde man hier wirklich mit Sockets und RMI arbeiten ?

 

[Gast2]

Moin,

also wenn es nur um das "ich will wissen wie es geht" geht, dann vergiss erstmal Java. Mach Dich erstmal schlau wie man das normaler weise löst. Also die Kommunikation zwischen 2 Programmen. Dazu wirst Du aber ein anderes Forum suchen dürfen. Hier wird es dir wahrscheinlich keiner sagen können.

Wenn Du das Problem mit der DLL gelöst hast, kannst Du Dich um den JNI Kram kümmern.

hand, mogel

 

[WindowsHook]

Hallo,

ich bedanke mich erstmal für die gegebenen Antworten. Ich denke das ich wohl erstmal keine andere Wahl haben werde als ein entsprechendes Forum aufzusuchen und mir zur Not einige Kenntnisse anzueigenen.

Ich hoffe, das falls ich es soweit schaffe eine Kommunikation irgendwie zu bewerkstelligen, das mir dann auf dessen Basis jemand bei der Implementierung von JNI helfen kann.

Ich werde dieses Thema dann zum entsprechenden Zeitpunkt noch einmal aufsuchen.

 

[WindowsHook]

Ich grabe dieses Thema doch noch mal aus.

Ich habe mitlerweile herausgefunden das es bei DLL's sowas wie "sharing" gibt.
Wenn man das mal auf Java überträgt sähe das wie folgt aus :

Eine Klasse mit einem static field. Die Funktionsweise kennen wir alle : der Inhalt bleibt über alle Instanzen innerhalb der VM gleich. Ändert man ihn in einer Instanz so wird er auch in allen anderen geändert. Das "sharing" in DLL's geht sogar noch eine Nummer weiter : stellt euch vor das diese Änderung nicht nur innerhalb einer VM abläuft sondern über die Grenzen einer VM hinweg auch in anderen.

Daraus folgt meine Überlegung :

Wenn man mit JNI arbeitet und über eine DLL mit diesem "sharing" zwei verschiedene VM's kombinieren will müsste man in diesem speziellen Speicherbereich eigentlich nur 4 Pointer anlegen : je zwei für das JNI-Env was die VM selbst repräsentiert und dann noch zwei jObject-pointer für die jeweilige Instanz der Klasse in den beiden VM. Natürlich könnte man die weg lassen und in Java dann mit "static" arbeiten, aber das will ich nicht.

Laut Wikipedia sieht eine native JNI-Methode so aus :

JNIEXPORT void JNICALL Java_ClassName_MethodName
   (JNIEnv *env, jobject obj)
 {
     /*Implement Native Method Here*/
 }

Definiert man diese Methode nun zwei mal, also einmal für den Service und einmal für den Controller, so müsste es doch möglich sein im shared-memory diese zu speichern und dann jeweils von der anderen VM darauf zu zugreifen.

Nun gibt es dabei aber einige Probleme :

1) Laut MSDN müssen alle Variablen in der "sharing"-Deklaration bereits initialisiert werden. Kann man hier "NULL" oder "0" für die Pointer verwenden oder muss man dafür erstmal "pseudo-Objekte" nutzen die dann später überschrieben werden ?

2) Laut Wikipedia muss eine native-Methode sich erstmal in den aktuellen Thread von "JNI-Env" einklinken damit der call gültig ist. Am schluss soll man sich von diesem auch wieder lösen um es sauber aufzuräumen. Wie würde man das nun umsetzen ?

Ich werde mal versuchen mit Hilfe von Google und dem was ich dort finde mir zumindest theroetisch mal etwas zusammen zu klicken. Ich hoffe das jemand der Ahnung von JNI hat mir dann hilft das ganze funktionsfähig zu bekommen.

 

[WindowsHook]

Ich habe noch eine wichtige Information an alle C- und JNI-Freaks die das hier (hoffentlich) verfolgen :

Laut einem Thread auf StackOverflow ist es wohl doch nicht ganz so einfach wie ich es dachte. Grund hierfür ist das man eben nicht so einfach Pointer in den "shared memory" einer DLL packen kann. Als Erklärung wurde genannt das die eine Instanz nichts mit der virtuellen Adresse der anderen Instanz anfangen kann. Eine wohl noch sehr simple Lösung soll es wohl sein zur Compile-Time einen Daten-Buffer im "shared memory" zu deklarieren und diesen dann vermutlich mit ein paar weiteren Status-Flags regelmäßig zu pollen (was man mit diesem Data-Buffer machen soll wurde so leider nicht erwähnt).

Das ganze klingt dann an sich aber immer noch halbwegs machbar. Immerhin müsste man ja beide VMs immer in mindestens einem non-deamon-Thread halten a ansonsten die VM terminiert. Und ob man nun diesen sinnlos mit Thread.sleep() einfach nur vergeudet oder dann doch noch sinnvoll für ein polling nutzt würde zumindest das Problem lösen wie man die VM vom terminieren abhält.

Allerdings kommt mir dazu wieder eine Java-spezifische frage in Kopf : sowohl der Lese- als auch der Schreibzugriff müssten mit dem Poll-Thread synchronisiert werden. Sicher könnte man dafür einfach 4 Flags nehmen : ServiceRead, ServiceWrite, ControllerRead, ControllerWrite, aber trotzdem muss doch gewährleistet sein das wenn der Service z.B. gerade am Lesen ist nicht einfach a-synchron ein anderer Thread schreiben kann. Genau so umgekehrt : das Lesen müsste solange blockiert werden bis der schreibende Thread es freigibt. Ich denke das man hier zumindest in Java-termen ein Beispiel finden könnte.

Ich werde weiter dran bleiben und Google weiter nach Informationen absuchen. Hoffentlich ergibt sich mal irgendwann etwas.

 

[WindowsHook]

Ich bin gerade auf folgendes gestoßen : http://www.codeproject.com/Articles/2460/Using-Memory-Mapped-Files-and-JNI-to-communicate-b
Ich hab mir das Sample mal geladen und es geht schon in die Richtung die ich möchte. Kleinere Mankos sind noch das es so wie man es laden kann nur in eine Richtung läuft und auch nur direkt x86-DLLs beiliegen.
Ich denke jedoch das ich mit Hilfe des Codes in der Lage sein sollte es so zu modifizieren das ich es bi-direktional mit Java-Objekten verwenden kann anstatt mit Strings, denn beides lässt sich ja in ein Byte-Array zerlegen und so speichern.

Werde das ergebnis dann hier posten.