Schnellste Kommunikation zwischen 2 Prozessen

[Arakis]

Hallo,
ich wüsste gerne was die absolut schnellste Kommunikations zwischen 2 Prozessen auf einem Computer ist. Da meine Anwendung irgendwann mehr als 2 GB Arbeitsspeicher benötigen wird, Windows einem Prozess aber nur 2 Gigabyte(oder 3 mit einem Trick) zuweisen kann, versuche ich dass zu umgehen in dem mehrere Prozesse meine Daten bereitstellen. Es werden sehr, sehr viele Lese-/Schreibvorgänge gemacht, jedoch immer mit kleinen Datenmengen. (Um genau zu sein, die Get-/Set-Properties meiner Klassen greifen z.Z. immer genau auf den gemeinsamen Datenbestand zu).

Nun denn, wemm es Interessiert, noch ein paar weitere Informationen: In Wirklichkeit nutze ich .NET(zwar net Delphi als Syntax, aber das ist ja egal). In einem globalem DataSet lade ich alle wichtigen Tabellen der SQL-Datenbank. Über Wrapper-Klassen, die viel Get-/Set-Properties haben, greife ich auf die Daten in "Echtzeit" zu. Zukünftig sollen diese Get-/Set-Properties auf den Datenbestand eines anderen Prozesses zugreifen, mit maximaler Geschwindigkeit, da dies sehr häufig passieren wird.

Ein Problem dürfte z.B. sein dass .NET managed Code ist.

Wer jetzt mit .NET Remoting kommt, den schlag ich


Oder kann das zukünftige 64-Bit-Framework mehr als 2 GigaByte verwalten, dann brauch ich ja gar nix zu ändern
Ein 64-Bit-Server für meine Anwendung aufzutreiben ist nämlich prinzipiell kein Problem

Wem es interessiert was für eine "Anwendung" gemeint ist, der kann hier selber nachschauen:
Ein Onlinespiel " StarTrek: The New Empire "
http://stne.net

[xeron]

wow... was ist denn das 4 ein monsterprog.... mehr als 2 gb ram...

[ims]

frag doch mal bei den entwicklern von ogame nach. wenn du glück hast erfährst du wie sie es gelöst haben. die haben bestimmt viel mehr traffic als du


gruss, dave

[Arakis]

Die Nehmen PHP. Jeder Seiten-Aufruf läuft in einer seperaten php.exe hab, die per Script-Sprache auf die Daten einer zentralen SQL-Datenbank zugreifen. Unschön, da die Daten nicht wirklich "shared" sind sondern sondern Alle Objektinstanzen haben so gesehen eine Kopie des Datensatzes bei eine Abfrage. Bei meiner Anwendung aber zeigen alle Objekinstanzen der selben Objekt-Identität auf den _selben_ Datenbestand. Dadurch wird z.B. cheaten oder provizieren von Fehlern wegen lahmer DB nahezu unmöglich. Und jeden Datensatz zu "locken" wäre bei einem MMOG(Massen Multiplayer Online Game) ein wenig krank. Außerdem braucht meine Anwendung die Performance, da in STNE ein "bisschen" mehr Daten benötigt zum visualisieren einer Seite oder ausführen einer komplexeren Aktion, STNE ist gerenell viel komplexer als ogame. OGame ist ein Zahlenschiebespiel, mehr nicht

[Chewie]

Ich weiß jetzt nicht, welche Möglichkeiten unter .NET alle zur Verfügung stehen, aber ich denke, Memory Mapped Files sind die schnellste Möglichkeit. Dabei wird einfach ein Teil des Kernelspeichers alloziert, auf den dann in anderen Prozessen zugegriffen werden kann. Bei dieser Lösung musst du halt das meiste selber machen, da es keine Benachrichtigungs-Möglichkeiten o.ä. bietet. Es ist einfach nur shared memory. Zumindest war das bei der Win32API so.

[stoxx]

Memory Mapped Files werden wohl wirklich die schnellste Lösung sein !
in diesem Buch ist auch ein nettes Beispiel dazu drin

http://www.amazon.de/exec/obidos/ASI...259671-2452055

(nicht zu verwechseln mit Deberenz )

[Chewie]

Zitat von stoxx:

Memory Mapped Files werden wohl wirklich die schnellste Lösung sein !

Warum nicht?

[Treffnix]

Zitat von Chewie:

Zitat von stoxx:

Memory Mapped Files werden wohl wirklich die schnellste Lösung sein !

Warum nicht?

Wieso "warum nicht?"? stoxx stimmt dir doch zu.

[Chewie]

Ups, ich hab da ein nicht gelesen

[stoxx]

Da es eigentlich nicht soooo kompliziert ist, hänge ich das Beispiel einfach mal dran.
Ich hoffe, die Autoren haben nix dagegen

Das Beispiel ist mit Synchronisation.
Die Daten werden übrigens deswegen in einer Schleife in das Array of Char geschrieben. Da so gezeigt werden soll, was passiert, wenn das ganze nicht synchronisiert ist.
(Auch allgemein, wenn Threads nicht synchronisiert sind)
(es sind noch mehr beispiele auf der CD, wo man dann sieht, was passiert, wenn unsyncrhonisiert ohne Critical Sections arbeitet)