Modularer (evtl. verteilter) Programmaufbau - Welche Art von IPC ist die richtige?

[BUG]

Zitat von mjustin:

RPC ist erst mal nur ein Kommunikationsmodel (Remote Procedure Calls sind Request/Response Kommunikation).

Streng ausgelegt bedeutet RPC, das sich verteilte Aufrufe wie lokale Prozeduraufrufe verhalten.
Das ist vermutlich auch die Abstraktion, die du für dein Plugin-System anstreben willst.

Woran du denken solltest: Kommunikation über Pipes/Sockets erfordert, dass du dir selbst selbst Gedanken über
Nachrichtenformate, mögliche Verklemmungen, usw. machen musst. Das bekommst du bei DCOM (oder anderen verteilten Objektmodellen) geschenkt.

Ein gutes RPC-System kann man nicht mal so eben aus ein paar Sockets/Pipes basteln.
Ob dich das interessiert, hängt aber auch davon ab, wie kompliziert die kompliziert die Zusammenarbeit deiner Komponenten/Plugins ist.

[Der schöne Günther]

Zitat von BUG:

Das ist vermutlich auch die Abstraktion, die du für dein Plugin-System anstreben willst.

Eigentlich schon. Sockets und Pipes sind im Endeffekt ja zunächst Datenaustauschverfahren zwischen Prozessen. Im Endeffekt will ich ja nicht wirklich Daten austauschen, ich möchte Methoden aufrufen. Vom Konzept her wäre RPC schon deutlich näher an dem, was ich eigentlich will.

Ich wühle mich weiterhin durch die wilde Welt der verschiedenen RPC-Modelle. Ehrlich gesagt ohne wirkliches Ziel.

Ich bin weiterhin unschlüssig: Kann man allgemein sagen, wie sehr man sich auf die ganze RPC-Geschichte überhaupt noch verlassen kann, wenn der Rechner mal beispielsweise einmal hart abstürzt und auf den letzten Wiederherstellungspuntk gesetzt wird? Oder der Kunde selbst (bzw. durch einen Drittanbieter) zusätzliche Software und Dienste auf der Maschine laufen lassen will (ohne das abzusprechen)?

[Phoenix]

Zitat von Der schöne Günther:

Ich bin weiterhin unschlüssig: Kann man allgemein sagen, wie sehr man sich auf die ganze RPC-Geschichte überhaupt noch verlassen kann, wenn der Rechner mal beispielsweise einmal hart abstürzt und auf den letzten Wiederherstellungspuntk gesetzt wird? Oder der Kunde selbst (bzw. durch einen Drittanbieter) zusätzliche Software und Dienste auf der Maschine laufen lassen will (ohne das abzusprechen)?

Der erste Fall ist in der Regel eher unproblematisch.
Der zweite kann zu einem Problem werden, wenn z.B ein vom Kunden installierter Dienst einen Port verwendet, der vom eigenen System verwendet werden soll, und dann auch noch früher hochfährt. Oder wenn die 'fremde' Software sehr Speicherintensiv ist und das System in Memory Pressure bringt, so daß die eigenen Dienste permanent geswapped werden. Oder oder oder...

[sh17]

Schau Dir mal RemObjects SDK an, falls Du nicht alles selbst machen möchtest. Da kannst Du zwischen den verschiedenen Transportschichten wechseln, falls es doch mal die Rechnergrenze verlässt. Quasi schon ein besseres RPC. Ich prinzip bin auch gerade an der gleichen Aufgabe wie Du. Eingebettete Prozesse und Kommunikation zwischen ihnen.

[Der schöne Günther]

Ja, das gab es auch schon: Kommunikation über Named Pipes, auf der Kundenmaschine lief allerdings noch Kontakt mit einem SQL Server, ebenfalls über Pipes. Windows hat dann die ältesten Pipes immer rausgekickt und nichts ging mehr

Bei RPC allgemein habe ich noch die Furcht, dass hier zu viel schiefgehen kann, wenn jemand am Rechner herumspielt - Einfach hinfahren und wieder gradebiegen ist keine Option

RemObjects sehe ich mir mal an - Hier im Forum schon hundert mal gehört, keine Ahnung, was es eigentlich ist...

[taveuni]

Zitat von Der schöne Günther:

RemObjects sehe ich mir mal an - Hier im Forum schon hundert mal gehört, keine Ahnung, was es eigentlich ist...

Dann wird es Zeit. Sehr komfortable Möglichkeit Methoden mit Strukturen via IPC zu benutzen. Und dies lokal, LAN, sowie Programmiersprachenübergreifend (und somit auch Plattformübergreifend).

[Der schöne Günther]

Ich kann leider nicht mehr tun, als mich durch Webseitenbeschreibungen und eventuell vorhandene Demo-Versionen zu wühlen. Gibt es so etwas wie ein Buch zu der ganzen RemObjects-Geschichte? Spontan hätte ich nämlich gesagt, dass es anscheinend eher um Services geht, die parallel von mehreren Clients angesprochen werden, das will ich ja nicht wirklich.

Außerdem binde ich mich damit dann auf ewig an RemObjects, oder? Würde ich nur mit Sockets/Pipes ein paar Daten hin- und herschaufeln, muss ich mir keine Sorgen machen, sollte ein Drittanbieter über Nacht dichtmachen...