Einzelnen Beitrag anzeigen

Arnulf

Registriert seit: 28. Okt 2004
Ort: Wien
271 Beiträge
 
#3

Re: welche ipc mit großen datenmengen aus injected .dll

  Alt 1. Apr 2008, 20:49
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
  Mit Zitat antworten Zitat