Qt D-Bus Übersicht

D-Bus ist ein Mechanismus für die Interprozesskommunikation (IPC) und den Remote Procedure Call (RPC), der ursprünglich für Linux entwickelt wurde, um bestehende und konkurrierende IPC-Lösungen durch ein einheitliches Protokoll zu ersetzen. Er wurde außerdem konzipiert, um die Kommunikation zwischen Prozessen auf Systemebene (wie Drucker- und Hardwaretreiberdiensten) und normalen Benutzerprozessen zu ermöglichen.

Es nutzt ein schnelles, binäres Protokoll zur Nachrichtenübermittlung, das sich aufgrund seiner geringen Latenz und seines geringen Overheads für die Kommunikation auf ein und demselben Rechner eignet. Seine Spezifikation wird derzeit vom freedesktop.org -Projekt definiert und steht allen Beteiligten zur Verfügung.

Die Kommunikation erfolgt im Allgemeinen über eine zentrale Serveranwendung, die als „Bus“ bezeichnet wird (daher der Name), aber auch eine direkte Kommunikation von Anwendung zu Anwendung ist möglich. Bei der Kommunikation über einen Bus können Anwendungen abfragen, welche anderen Anwendungen und Dienste verfügbar sind, und diese bei Bedarf aktivieren.

Die Busse

D-Bus-Busse kommen zum Einsatz, wenn eine Viele-zu-Viele-Kommunikation gewünscht ist. Um dies zu erreichen, wird ein zentraler Server gestartet, bevor sich eine Anwendung mit dem Bus verbinden kann. Dieser Server ist dafür zuständig, den Überblick über die verbundenen Anwendungen zu behalten und Nachrichten ordnungsgemäß von ihrer Quelle zu ihrem Ziel weiterzuleiten.

Darüber hinaus definiert D-Bus zwei bekannte Busse, den sogenannten Systembus und den Sitzungsbus. Diese Busse sind insofern besonders, als sie über eine genau definierte Semantik verfügen: Bestimmte Dienste sind so definiert, dass sie auf einem oder beiden dieser Busse zu finden sind.

Beispielsweise wird eine Anwendung, die die Liste der an den Computer angeschlossenen Hardwaregeräte abfragen möchte, wahrscheinlich mit einem auf dem Systembus verfügbaren Dienst kommunizieren, während der Dienst, der das Öffnen des Webbrowsers des Benutzers ermöglicht, wahrscheinlich auf dem Sitzungsbus zu finden ist.

Auf dem Systembus gibt es zudem Einschränkungen hinsichtlich der Dienste, die eine einzelne Anwendung anbieten darf. Daher kann man mit hinreichender Sicherheit davon ausgehen, dass ein vorhandener Dienst von einer vertrauenswürdigen Anwendung bereitgestellt wird.

Konzepte

Nachrichten

Auf der unteren Ebene kommunizieren Anwendungen über D-Bus, indem sie sich gegenseitig Nachrichten senden. Nachrichten dienen dazu, die Remote-Prozeduraufrufe sowie die damit verbundenen Antworten und Fehler weiterzuleiten. Bei der Verwendung über einen Bus haben Nachrichten ein Ziel, was bedeutet, dass sie nur an die betroffenen Parteien weitergeleitet werden, wodurch eine Überlastung durch „Swarming“ oder Rundsendungen vermieden wird.

Eine spezielle Art von Nachricht, die als „Signalnachricht“ bezeichnet wird (ein Konzept, das auf dem Signals-and-Slots-Mechanismus von Qt basiert), hat jedoch kein vordefiniertes Ziel. Da sie für den Einsatz in einem Eins-zu-Viele-Kontext vorgesehen ist, sind Signalnachrichten so konzipiert, dass sie über einen „Opt-in“-Mechanismus funktionieren.

Das Modul „ Qt D-Bus “ kapseln das Low-Level-Konzept von Nachrichten vollständig in einen einfacheren, objektorientierten Ansatz, der Qt-Entwicklern vertraut ist. In den meisten Fällen muss sich der Entwickler keine Gedanken über das Senden oder Empfangen von Nachrichten machen.

Dienstnamen

Bei der Kommunikation über einen Bus erhalten Anwendungen einen sogenannten „Dienstnamen“: Damit legt die Anwendung fest, wie sie von anderen Anwendungen auf demselben Bus erkannt werden soll. Die Dienstnamen werden vom D-Bus-Bus-Daemon verwaltet und dienen dazu, Nachrichten von einer Anwendung zur anderen weiterzuleiten. Ein analoges Konzept zu Dienstnamen sind IP-Adressen und Hostnamen: Ein Computer verfügt normalerweise über eine IP-Adresse und kann je nach den Diensten, die er dem Netzwerk bereitstellt, mit einem oder mehreren Hostnamen verknüpft sein.

Wird hingegen kein Bus verwendet, kommen auch keine Dienstnamen zum Einsatz. Vergleicht man dies erneut mit einem Computernetzwerk, entspräche dies einem Punkt-zu-Punkt-Netzwerk: Da der Peer bekannt ist, besteht keine Notwendigkeit, Hostnamen zu verwenden, um ihn oder seine IP-Adresse zu finden.

Das Format eines D-Bus-Dienstnamens ähnelt tatsächlich stark einem Hostnamen: Es handelt sich um eine durch Punkte getrennte Folge aus Buchstaben und Ziffern. Es ist sogar gängige Praxis, den Dienstnamen nach dem Domainnamen der Organisation zu benennen, die diesen Dienst definiert hat.

Beispielsweise wird der D-Bus-Dienst unter freedesktop.org definiert und ist auf dem Bus unter folgendem Dienstnamen zu finden:

org.freedesktop.DBus

Objektpfade

Ähnlich wie Netzwerk-Hosts stellen Anwendungen anderen Anwendungen bestimmte Dienste zur Verfügung, indem sie Objekte exportieren. Diese Objekte sind hierarchisch organisiert, ähnlich wie die Eltern-Kind-Beziehung, die von QObject abgeleitete Klassen aufweisen. Ein Unterschied besteht jedoch darin, dass es das Konzept des „Root-Objekts“ gibt, das für alle Objekte das oberste übergeordnete Objekt darstellt.

Wenn wir unsere Analogie zu Webdiensten fortsetzen, entsprechen Objektpfade dem Pfadteil einer URL:

Genau wie diese werden Objektpfade in D-Bus ähnlich wie Pfadnamen im Dateisystem gebildet: Es handelt sich um durch Schrägstriche getrennte Bezeichnungen, die jeweils aus Buchstaben, Ziffern und dem Unterstrich („_“) bestehen. Sie müssen immer mit einem Schrägstrich beginnen und dürfen nicht mit einem enden.

Schnittstellen

Schnittstellen ähneln abstrakten Klassen in C++ und dem Schlüsselwort „ interface “ in Java und legen den „Vertrag“ fest, der zwischen Aufrufer und Aufgerufenem geschlossen wird. Das heißt, sie legen die Namen der verfügbaren Methoden, Signale und Eigenschaften sowie das Verhalten fest, das von beiden Seiten erwartet wird, sobald die Kommunikation hergestellt ist.

Qt verwendet in seinem Plugin-System einen sehr ähnlichen Mechanismus: Basisklassen in C++ werden über das Makro ` Q_DECLARE_INTERFACE()` mit einer eindeutigen Kennung verknüpft.

Die Namen von D-Bus-Schnittstellen werden tatsächlich in einer Weise vergeben, die dem vom Qt-Plugin-System vorgeschlagenen Schema ähnelt: Ein Bezeichner, der in der Regel aus dem Domänennamen der Entität gebildet wird, die diese Schnittstelle definiert hat.

Übersicht

Um sich die Namensformate und deren Zweck besser einprägen zu können, kann die folgende Tabelle herangezogen werden:

Fehlerbehebung

Bei der Entwicklung von Anwendungen, die D-Bus nutzen, ist es manchmal hilfreich, Informationen über die Nachrichten einsehen zu können, die von den einzelnen Anwendungen über den Bus gesendet und empfangen werden.

Diese Funktion kann für jede Anwendung einzeln aktiviert werden, indem vor dem Start der jeweiligen Anwendung die Umgebungsvariable ` QDBUS_DEBUG ` gesetzt wird. So können wir beispielsweise das Debugging nur für das Auto im Beispiel „D-Bus Remote Controlled Car“ aktivieren, indem wir den Controller und das Auto wie folgt ausführen:

examples/dbus/remotecontrolledcar/controller/controller &
QDBUS_DEBUG=1 examples/dbus/remotecontrolledcar/car/car &

Informationen zu den Nachrichten werden in die Konsole geschrieben, von der aus die Anwendung gestartet wurde.