Schnellste Kommunikation zwischen 2 Prozessen

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