welche ipc mit großen datenmengen aus injected .dll

[Arnulf]

Hi
Ich bin dabei alten code etwas zu erneuern.
Ich hab eine .dll die ich in ein spiel lade um mir screenshots zu holen.
Bisher hab ich das gleich als .jpg gespeichert und dann von meine Programm geladen und per tcp verschickt.
Jetzt würde ich aber lieber ipc verwenden, weil der umweg über files unnötig ist und eigentlich nur zeit kostet.

Ich suche also rat welche ipc sich für bitmaps in der größe 2 - 4 mb am bessten eignen würde.
Geschwindigkeit ist hier ausschlaggebend, weil das spiel ja mit wenig unterbrechungen weiter laufen soll.

Ich muss meinem programm also eine nachricht schicken ( copydata, windowsmessage )bzw. auf daten warten ( named pipe ).
Fraglich ist auch ob ich wenn ich das bitmap aus dem framebuffer kopiert habe einen thread starten sollte um die ipc zu installieren und das spiel inzwischen weiter laufen lasse.

Ich bin also momentan unschlüssig was sich hier am bessten eigenen würde.
lg
Arnulf

[wido]

Ich hab aus gegebenem Anlass mal ein paar "Performance Messungen" durchgeführt vor einiger Zeit in Puncto IPC Methoden. Dabei hab ich Pipes, RPC und Shared Memory verglichen.

Die schnellste Methode ist definitiv Shared Memory, allerdings ist das Problem, daß Du selbst für die Synchronisierung zuständig bist. Solange Du nur einen Prozess hast, der den Shared Memory liest und nur einen der darin schreibt, ist das Ganze relativ einfach. Sobald es mehrere werden, wirds aber schnell komplexer und man produziert relativ leicht Dead Locks.

Nicht ganz so schnell, aber immer noch sehr gute Performance, bieten Named Pipes. Vorteil ist, daß Du rudimentäres "Session Management" hast, Du Dich nicht selbst um jeden Scheiß kümmern musst und man dein Problem wahrscheinlich in ca. 10 - 20 Zeilen Code lösen könnte.

RPC ist mit Abstand das langsamste. Allerdings erhälst Du komfort pur. Du musst keine Datenstrukturen parsen oder ähnliches. Übernimmt alles RPC für Dich. Hochleistung erreichst Du allerdings eher nicht.

Von WM_COPYDATA würde ich abraten. Bei Windows 9x wurden bei mir regelmäßig Messages "verschluckt". Abgesehen davon kannst Du halt nur mit Hilfe von Fenstern kommunizieren, die sich in der selben Session befinden. Eine Möglichkeit mit Services zu reden ohne die Systemsicherheit zu gefährden, existiert z.B. nicht.

TCP/IP wäre noch eine Möglichkeit, allerdings gibts da dann regelmäßig Probleme mit Firewalls.

Im Endeffekt solltest Du schauen was Du möchtest. Wenn Du nur einen Client hast und das sicher auch immer nur ein Client sein wird, dann nutz Shared Memory. Bei mehreren Clients gibts dort dann allerdings schnell mal Kopfweh. Wenn Dir minimale Performanceeinbussen allerdings nichts aus machen, nimm Named Pipes. Ist bei weitem angenehmer, allerdings nur auf NT basierenden Systemen.

Multi Threading wäre übrigens definitiv anzuraten - egal welche IPC Methode Du dann letztlich implementierst.

[Arnulf]

Naja ich hab heute wm_copydata implementiert
shared memory hab ich mal unter linux gemacht - war eigentlich ganz komfortabel solange man semaphoren verwendet - unter windows muss ich mir das wohl mal anschauen.
named pipes hab ich ebenfalls unter linux erfahrung - windows war mir erstmal schleierhaft wie das da implementiert ist.

rpc und tcp oder ähnliche dinge egal in welchen netzwerk layer schließe ich erstmal aus das ist deffinitiv zu langsam und den stress mit den firewalls kann ich mir vorstellen.

wm_copydata ist sehr einfach zu machen und funktioniert eigentlich recht gut. mit sendmessage sollte eigentlich nichts verloren gehen - aber wer weiß schon was in den tiefen von windows so ab geht.

ad. thread
ich habs probiert - bin gescheitert - das gibt ganz schlimme abstürze, vor allem kann ich einfach nicht wirklich sicherstellen, dass ich alle recourcen wieder freigeben kann die ich mit pointer and den thread übergeben..... viele probleme ...

Bisher funktioniert das so:
Client injiziert eine .dll in ein Spiel.
die .dll hookt dort wglSwapBuffer und schickt einmal in der sekunde ( gettickcount ) einen screenshot
an den client über wm_copydata.

Der Screenshot wird über glReadPixel und dem entsprechenden Bitmap header in einen memory stream copiert und dieser dann über wm_copydata verschickt.

jetzt zu meinem Ziel:
Mein client injiziert eine .dll in ein spiel.
die .dll hookt dort wglSwapBuffer und soll jetzt auf anweisungen warten.
Wenn mein Client der .dll bescheid gibt, soll diese einen Screenshot machen und den an den client übertragen.


wenn ich jetzt shared memory verwende, was soll ich dann für einen speicherbereich reservieren?
von der bitmap weiß ich die größe und die ist immer gleich (withxheight)
sollte allerdings der spieler die auflösung ändern dann könnte es sein, dass ich den shared memory zu klein dimensioniert habe.
Shared memory allerdings hätte den vorteil, dass ich direkt von glReadPixel in den puffer schreiben könnte und nicht noch einen stream erzeugen müsste.

mit einer pipe könnte ich eine read und write pipe installieren und ordentlich kommunizieren..

ich denke pipe oder shared memory - sind wohl doch besser.
nur was eben?

lg
Arnulf

[Arnulf]

ich hab es jetzt mit shared memory implementiert und es funktioniert perfekt.

momentan schicke ich eine windows message an mein programm wenn das bild fertig ist.
ein richtiges syncronisieren ist das noch nicht, ich überleg noch über die besste methode.
(mutex, event oder ähnliches )

jedenfalls eindeutig shared memory für sowas.

lg
Arnulf