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

[Phoenix]

Zitat von mjustin:

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. Damit können Prozesse Nachrichten austauschen, was sogar "transaktional" geht (d.h. wenn eine Reihe von Nachrichten empfangen wurde und der Empfänger kein "Acknowledge" sendet, sondern abstürzt, erhält er die Nachrichten nach dem Neustart noch einmal). http://msdn.microsoft.com/en-us/library/ms978430.aspx

Das ist aber mit Vorsicht zu genießen. Messages überleben in der Queue nicht ewig, und wenn sich in der MessageQueue nachrichten Aufstauen, und der Abnehmer sie nicht schnell genug verarbeitet (default liegt bei 10 Sekunden), kann es gut wird es passieren das einzelne Messages austimen und verschwinden.

[mjustin]

Zitat von Phoenix:

Zitat von mjustin:

Als Microsoft-spezifische Lösung nenne ich nur mal so MSMQ, Microsoft Message Queuing. ...

Messages überleben in der Queue nicht ewig

Das Timeout kann man nach Bedarf hochsetzen, solange ausreichend RAM vorhanden ist. Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren - so wie es andere (RabbitMQ, WebSphere) können.

[Der schöne Günther]

Zitat von mjustin:

Microsoft MSMQ ist vermutlich dann aus dem Rennen, wenn man den Server öfter mal neu booten muss, und keine Möglichkeit hat, die noch nicht zugestellten Messages zu persistieren

. Der Kunde stellt die lustigsten Dinge mit den Maschinen an, einfach Strom ziehen ist nichts ungewöhnliches. Daher...

Zitat von Morphie:

Aber ist das dann nicht ein allgemeines Problem der Ressourcenverwaltung / des Error-Handlings?

Wenn ich eine bestimmte Hardware per COM-Anschluss ansteuere und mein Programm dabei ein Fehler produziert, muss ich doch sicherstellen, dass der COM-Anschluss auch wieder freigegeben wird.

In der Theorie, ja. Allerdings muss (und möchte) ich auch davon ausgehen, dass es immer irgendwo eine Fehlermöglichkeit gibt, die das ganze Teil aufhängt oder komplett abstürzen lässt. Die Aufteilung in eigene Prozesse hilft da ungemein da Windows hier alles wieder freigibt.

[sh17]

Zitat von Der schöne Günther:

Der Kunde stellt die lustigsten Dinge mit den Maschinen an, einfach Strom ziehen ist nichts ungewöhnliches. Daher...

...ist das Handle wenigstens freigegeben.

[sh17]

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

[mjustin]

Zitat von sh17:

und die Instanz vom Message Bus kann im Kern der Anwendung liegen? Oder lieber separat?

Der Message Bus wird von einem eigenen Prozess bereitgestellt, damit ist er selbst in dem (allerdings unwahrscheinlichen Fall) erreichbar, dass der Anwendungskern komplett abgestürzt ist - und nur noch die Plugin-Prozesse laufen und man kann ihn bei Bedarf auch auf eine eigene (virtuelle) Maschine legen, an der nicht herumgefummelt wird.

[Der schöne Günther]

Faszinierendes Kochrezept.

Für meinen Zweck hatte hätte ich bislang eigentlich bewusst eine Punkt-zu-Punkt-Verbindung zwischen Kern und den Modulen angestrebt. Und zwar da

1. die Module in ihrer Natür sehr autark sind. Was ein einem passiert beinflusst i.d.R. die Tätigkeiten des anderen in keinster Weise, oder nur sehr indirekt
2. ich bewusst verhindern möchte, dass man sich in einem Modul mit Aufgabenbereichen eines eigentlich anderen befasst.

Der Grund für den zweiten Punkt ist folgender: Baut der Kunde an seiner Installation etwas um, möchte ich ihm nur eine neue Konfiguration des Moduls (oder ein anderes) liefern. Wenn ich jetzt noch andere Module habe, die in gewisser Weise von anderen Plug-Ins "abhängig" sind, komme ich in Teufels Küche...


Ich bin begeistert, wie lange sich so ein komplexes Thema hält.