![]() |
[JAVA] Zugriff auf Daten im Speicher
Hallo, nachdem ich nach ein paar erfolglosen Versuchen mit Google nichts gefunden habe, wollte ich fragen ob jemand hier vielleicht weiß, wie man das Problem angehen kann: Ich möchte eine Datei in mein Programm einlesen, entsprechent bearbeiten und dann von außerhalb des Programms auf die Daten im Speicher zugreifen. Ich möchte das bearbeitete Element nicht als neue Datei abspeichern, sondern es soll verloren gehen wenn Java geschlossen wird, also im bestfall nur im Ram vorhanden sein. Falls mit Java nicht möglich gehen auch andere Programmiersprachen als empfehlung (Bestenfalls C / C++ / C#). Bedanke mich im vorraus für jeden Tipp!
|
Betriebssystem???
|
für die meisten OS gilt:
Zitat:
evntl. kannst du das per [Link nur für registrierte und freigeschaltete Mitglieder sichtbar. Jetzt registrieren...] realisieren. |
@Pillewutz: Windows XP. Wenn es mit komplett mit Java realisierbar ist, dürfte doch aber eine Portierung (im bestfall) keine schwierigkeiten bereiten ?
@urga: Danke für die Links, das Programme nicht in den Speicherbereich anderer Programme zugreifen sollen/dürfen war mir schon klar, aber der Link mit dem Shared Memory ist gut, danke dafür. |
Hmm Direkter Speicherzugriff ist in Java nicht möglich, evtl mit ein paar schalternin der JVM aber das bezweifele ich, kenne mich mit der JVM aber auch nicht so aus.
Was du suchst ist eine RAMDISK, diese musst du mit demBetriebssystem erstellen, ODER du speicherst deine Datei in einer Datenstruktur und führst jeden zugriff auf diese zurrück. |
Du könntest auch einfach mit temporären Dateien arbeiten, welche du danach einfach löschst.
|
Zitat:
|
@Thelvan: Natürlich könnte ich alles in temporären Dateien zwischenspeichern, aber auch wenn ich diese dann löschen lasse, kann ich mir ja nie sicher sein wann mein OS (in diesem Fall Windows) die Datei auch wirklich überschreibt. Und wie gesagt, ich würde die Datei ungern direkt auf der Festplatte speichern.
@dellmar: Genau genommen war Shared Memory die Antwort mit dem meisten Sinn, nur für Java halt wenig praktikabel. |
Zitat:
Wenn es Dir darum geht, dass die Daten nach dem Löschen nicht mehr wiederhergestellt werden können, wird's langsam knifflig. Windows könnte Dein Programm nämlich zwischendurch ausgelagert haben, dann liegt der komplette Speicherinhalt auf der Platte. Heisst, jetzt musst Du Dir zuerst mal Gedanken drüber machen, gegen welche Ausleseversuche Du dich schützen willst. Dann kannst Du Dich entscheiden, welche Technologien Du einsetzen kannst. |
@Epeos: Ich sehe keinen unterschied zwischen meiner Aussage und deinem ersten Absatz.
|
Ccursed,
shared memory macht nur sinn wenn 2 Prozesse ganz unkompliziert Daten miteinander austauschen sollen. sonst ist shared memory nicht so besonders. |
Hmm, mich würde interessieren, was genau Du machen willst. Soweit ich Dich verstanden habe, hast Du irgendwo eine Datei, die Du bearbeiten möchtest. Die Datei selbst möchtest Du löschen, aber die Änderung selbst möchtest Du von außerhalb bearbeiten?
Da stellt sich mir die Frage: Warum willst Du, dass ein Programm (auch ein Programm von Dir?) auf die Daten zugreifen kann? Kannst Du das nicht innerhalb der gleichen Anwendung machen? Die Sicherheit, die Du möchtest, ist so eine Sache: IPC ist ein sehr komplexes Thema, und wenn Du nicht aufpasst, kannst Du damit riesige Scheunentore für Angriffe öffnen. |
@Xalir Wirklich machen will ich damit nichts, ist eher ein Gedankenexperiment / wäre cool zu wissen.
Der genaue Ablauf sollte halt so aussehen: Ich habe eine Datei, sagen wir eine Textdatei mit Inhalt (egal was, hauptsache text), das Programm in dem die Datei geöffnet wird (Programm A), und das Programm das die bearbeiteten Dinge annimmt (Programm B). Ich öffne nun Prog. A und gebe ihm die Datei an, anschließend liest das Prog. A den Text aus und fängt an nach einem beliebigen Algorithmus den Text zu bearbeiten (nur eine Kopie, original soll erhalten bleiben), nach der Bearbeitung speichert es den bearbeiteten Text im Ram ab (sagen wir als String / Stringarray). Nun starten wir Prog. B, Prog. B überprüft ob Prog. A gerade ausgeführt wird, falls ja erfragt nun Prog. B bei Prog. A die Speicheradresse des Strings / Stringarrays und tut dann irgendwas damit, zum Beispiel eine Ausgabe (ja das könnte man auch direkt tun, aber es geht mir halt um die Datenübergabe). Beim schließen von Prog A soll der Speicher natürlich wieder freigegeben werden / überschrieben werden, beim schließen von Prog B soll der Text weiterhin im Ram bestehen. |
ja kann man machen, aber wiso so?
Mit java hast du threads, und dein Szenario hat keine Notwendigketi für IPC,zumal IPC und Java sowiso so eine Sache ist, da du auf das OS direkt zugreifen musst. Nimm lieber Threads, da haste dann auch einen gemeinsam nutzbaren Speicherbereich. mfg sirleo |
Zitat:
Meiner Meinung nach macht es bei Deinem Gedankenexperiment mehr Sinn, in Deinem Programm A eine Methode zu implementieren, die den gewünschten Inhalt an Programm B zurück liefert. Programm B ruft dann diese Methode auf und bekommt die Daten sauber von A übergeben. Dann hat A die Kontrolle über die Daten und du musst in A nicht sicher stellen, dass B daran herummanipuliert. |
So wie Du Dir das vorstellst, wird es (für Dich) nahezu unmöglich sein.
Aber: Du kannst öffentliche Schnittstellen bereitstellen, über die andere Programme auf Deine Funktionen zugreifen können. In .NET ist es möglich, die Zugriffe über signierte Assemblies zu steuern und zu verlangen, dass Programm B die gleiche Signierung wie Programm A hat, bevor es auf die Funktionen zugreifen darf. Wie es in anderen Sprachen wie Java ausschaut, kein Plan. Andere Möglichkeiten, die zum Teil auch genannt wurden. sind Shared Memory, Named Pipes, Anonymous Pipes. Auch wieder nur für .NET gibt es die WCF, die zwar hauptsächlich für verteilte Anwendung sinnvoll ist, aber die man auch für solche Spielereien missbrauchen kann. |
Datenaustausch zwischen zwei Programmen lässt sich doch relativ einfach über Sockets oder RPC (JSON bzw. XML) realisieren. Wobei RPC wohl schon genannt worden ist:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:15 Uhr. |
Powered by vBulletin® (Deutsch)
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.