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 :lol:


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

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... :roteyes:

[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 :mrgreen:

[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:

Zitat von stoxx

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

Warum nicht?

[Treffnix]

Zitat:

Zitat von Chewie

Zitat:

Zitat von stoxx

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

Warum nicht?

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

[Chewie]

Ups, ich hab da ein nicht gelesen :oops:

[stoxx]

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

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)

[Arakis]

*hm*
Also ich glaub nicht dass ich damit glüchlich wäre den Speicher selber zu verwalten. Also ich stelle mir schon vor eine "Funktion" im anderen Prozess aufzurufen. Sie erwartet einfach Datentypen und gibt auch nur einfache Datentypen zurück(string, bool, "ne zahl vom typ xy"). Ich frage halt nur weil einige meinen COM z.b. sei total lahm. Oder per Messages sei eventuell Problematisch wenn die Queue überfüllt ist(??) oder ob das Messagesystem überhaupt dafür gedacht ist so viele kleine Minnianfrage pro Sekunde zu verwalten.

Denn ich verwende ja Objekte des Microsoft Framework's, der auf den Speicher habe ich keinen Zugriff.

Aber kann denn das zukünftige 64-Bit-Framwork auf einem 64-Bit-Betriebsystem(+passender Prozessor) einem(!) Prozess mehr als 2 GB zuweisen? Damit wären alle Probleme beseitigt.

[stoxx]

siehe Beispiel :-)
Ich glaub, das erfüllt genau Deinen Zweck , den Du willst !

[Arakis]

Okay, Prinzip verstanden aber in erster Linie nicht mein Ziel den Speicher manuell zu verwalten.

Ich verwende das Objekt System.Data.DataSet, dies speichert, löscht, ändert, stellt mir die Daten bereit. Es macht Indizierungen, hat Suchfunktionen etc. Auf den physikalischen Speicher hat nicht mal dieses Objekt zugriff, sondern das ist ja das .NET Framework. Ich kann also nur Funktionen aufrufen. Mit geht es um die schnellste Möglichkeit eine Funktion in einem anderen Prozess aufzurufen und ggf. einen kleinen Wert zurück zu bekommen.

Möglich wäre das über Net-sockets, oder COM oder Messages, so viel ist mir bekannt. Aber ich habe keine Erfahrung welches die schnellste Möglichkeit ist und für .NET überhautp verwendbar ist.

[Arakis]

Ich habe mich erkundigt, Raw-Sockets und Namedpipes sollen wohl die schnellste Möglichkeit darstellen.

[sakura]

Zitat:

Zitat von Arakis

Ich habe mich erkundigt, Raw-Sockets und Namedpipes sollen wohl die schnellste Möglichkeit darstellen.

Zu Named [dp]Pipe*[/dp]s findest Du hier im Forum über die Suche ein paar Komponenten und Beispiele von mir.

...:cat:...

[Arakis]

Was ist denn schneller, Namedpipes oder Mailslots?

Ein paar Hintergründe:
Alle wichtigen Tabellen der Datenbank in in einem .NET-Dataset geladen. Für jede
Tabelle habe ich eine "Wrapper-Klasse" die als privates Member die DataRow
hat und mir die Spaltenwerte per Get/Set-Properties verwaltet.
Ich möchte zukünftig das ganze DataSet in einem seperaten Prozess haben.
Dabei sollen die Get-/Set-Properties in Echtzeit auf die Daten im anderen
Prozess zugreifen(Nur einfache Wertetypen, ohne Strukturen). Daher die
benötigte ernorme Gewschindigkeit, denn selbst wenn die Abfrage "nur" eine
Millisekunde benötigen würde, so wäre das schon extrem langsam! *g*

Falls sich jemand wundert warum ich ein .NET-Problem hier in einem Delphi-Forum stelle:
1. Hier sind schlaue Köpfchen, das ist mir seit langem bekannt
2. für .NET gibt es ja nun auch Delphi-Syntax
3. In .NET-Foren denken alle viel zu "Frameworkorientiert", machen es sich mega einfach. Also so ne XML-Serialisierung mit .NET-Remoting, klasse Performance(selbst wenn Binary-Formatierung mit tcp-Channel) :lol:
3. In .NET kann man Win32-API einbinden

[Arakis]

Okay, und mal erkundigt sich weiter.

- Wenn der Prozess auf einem anderen Computer im LAN oder gar WAN ist, dann kommt TCP/IP in Frage.
- Generell sind Namedpipes im LAN langsamer als TCP/IP und im WAN sogar noch mehr.
- Lokal jedoch sind sie extrem schnell, da sie im Kernel laufen und Memory mapped files nutzen.

Richtig verstanden? :gruebel:

Quelle: http://groups.google.de/groups?q=%22named+pipes%22&hl=de&lr=lang_de|lang_e n&ie=UTF-8&oe=UTF-8&newwindow=1&selm=ejNuLPVtCHA.2176%40TK2MSFTNGP12 &rnum=33

[Arakis]

Ach wie niedlich, hier ist eine Übersetzung:

http://groups.google.de/groups?q=%22named+pipes%22&hl=de&lr=lang_de|lang_e n&ie=UTF-8&oe=UTF-8&newwindow=1&selm=utL7OC%24bAHA.1316%40tkmsftngp0 2&rnum=45

:mrgreen: