Nach meinem Halbwissen sind die grundlegenden IPC Mechanismen - Shared Memory - Mailboxen - Pipes - Fifos - Netzwerk Sockets
Und unter Unix auch Unix Domain Sockets.
Aber das sind alles nur Transportschichten, quasi Bytestreams (mit der Ausnahme Shared Memory, das ist ein Byteblock).
Wenn in diesem Kontext über IPC gesprochen wird, geht es um eine Schicht höher, also Definitions einer Nachrichtensemantik, Routing, Ordering, etc.
Diese Dinge machem dass jeweilige IPC dann interessanter, weil zwischen den Kommunikationspartner mehr gemeinsame Annahme usw. existieren.
Wenn jetzt ein "Bussystem" auf höherer Ebene (höher als Transport) implementiert werden soll, dann kann ich das für mich nur gebrauchen, wenn es wieder auf allen gängigen Betriebssystemen funktioniert.
Oft muss man bei diesen Betrachtungen dann halt leider irgendwo die Kompromisslinie ziehen, weil eben Betriebsystem auf den niedrigen Schichten teilweise eben sehr unterschiedlich sind.
Zum Beispiel ist D-Bus auf allen Unix ähnlichen System praktisch in vollem Funktionsumfang verfügbar, aber Windows hat halt leider keine Local Sockets.
Man könnte das dort dann statt wie derzeit TCP Socket wohl auch über Named Pipes implementieren, aber gewisse Features sind vielleicht trotzdem nicht möglich (bei Unix Domain Sockets kann man User/Group/Rechte des Gegenüber abfragen, File Handles verschicken, etc).
Bei Bus1 wird man diese Kompromissschwelle wohl sehr niedrig ansetzen, d.h. möglichst optimal auf die Möglichkeiten von Linux orientiert.
Edit: eine Applikation kann natürlich, je nachdem wieviel sie von diesen Features braucht, eventuell ihrerseits eine Abstraktion verwenden, die dann auf diversen Plattformen dann mit dem jeweiligen Mid-Level IPC umgesetzt werden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Aug 2016 um 13:45.
Aber das sind alles nur Transportschichten, quasi Bytestreams (mit der Ausnahme Shared Memory, das ist ein Byteblock).
Wenn in diesem Kontext über IPC gesprochen wird, geht es um eine Schicht höher, also Definitions einer Nachrichtensemantik, Routing, Ordering, etc.
Diese Dinge machem dass jeweilige IPC dann interessanter, weil zwischen den Kommunikationspartner mehr gemeinsame Annahme usw. existieren.
Oft muss man bei diesen Betrachtungen dann halt leider irgendwo die Kompromisslinie ziehen, weil eben Betriebsystem auf den niedrigen Schichten teilweise eben sehr unterschiedlich sind.
Zum Beispiel ist D-Bus auf allen Unix ähnlichen System praktisch in vollem Funktionsumfang verfügbar, aber Windows hat halt leider keine Local Sockets.
Man könnte das dort dann statt wie derzeit TCP Socket wohl auch über Named Pipes implementieren, aber gewisse Features sind vielleicht trotzdem nicht möglich (bei Unix Domain Sockets kann man User/Group/Rechte des Gegenüber abfragen, File Handles verschicken, etc).
Bei Bus1 wird man diese Kompromissschwelle wohl sehr niedrig ansetzen, d.h. möglichst optimal auf die Möglichkeiten von Linux orientiert.
Edit: eine Applikation kann natürlich, je nachdem wieviel sie von diesen Features braucht, eventuell ihrerseits eine Abstraktion verwenden, die dann auf diversen Plattformen dann mit dem jeweiligen Mid-Level IPC umgesetzt werden.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 22. Aug 2016 um 13:45.