Qt D-Bus Überblick

D-Bus ist ein Inter-Process Communication (IPC) und Remote Procedure Calling (RPC) Mechanismus, der ursprünglich für Linux entwickelt wurde, um bestehende und konkurrierende IPC-Lösungen durch ein einheitliches Protokoll zu ersetzen. Er wurde auch entwickelt, um die Kommunikation zwischen Prozessen auf Systemebene (z. B. Drucker- und Hardwaretreiberdienste) und normalen Benutzerprozessen zu ermöglichen.

Es verwendet ein schnelles, binäres Message-Passing-Protokoll, das aufgrund seiner geringen Latenzzeit und seines geringen Overheads für die Kommunikation zwischen denselben Maschinen geeignet ist. Seine Spezifikation wird derzeit vom Projekt freedesktop.org definiert und ist für alle Beteiligten verfügbar.

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

Die Busse

D-Bus-Busse werden eingesetzt, wenn eine Many-to-Many-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 für die Verfolgung der angeschlossenen Anwendungen und für die ordnungsgemäße Weiterleitung der Nachrichten von ihrer Quelle zu ihrem Ziel verantwortlich.

Darüber hinaus definiert D-Bus zwei bekannte Busse, den Systembus und den Sitzungsbus. Diese Busse sind insofern etwas Besonderes, als sie eine wohldefinierte Semantik haben: Einige Dienste sind so definiert, dass sie in einem oder beiden dieser Busse zu finden sind.

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

Auf dem Systembus sind auch Beschränkungen für die Dienste zu erwarten, die jede Anwendung anbieten darf. Daher können Sie einigermaßen sicher sein, dass ein bestimmter Dienst von einer vertrauenswürdigen Anwendung angeboten wird, wenn er vorhanden ist.

Konzepte

Nachrichten

Auf einer niedrigen Ebene kommunizieren Anwendungen über D-Bus, indem sie sich gegenseitig Nachrichten schicken. Nachrichten werden verwendet, um die Remote-Prozeduraufrufe sowie die damit verbundenen Antworten und Fehler weiterzuleiten. Wenn sie über einen Bus verwendet werden, haben Nachrichten ein Ziel, was bedeutet, dass sie nur an die interessierten Parteien weitergeleitet werden, um eine Überlastung durch "Schwärmen" oder Broadcasting zu vermeiden.

Eine spezielle Art von Nachrichten, die so genannte "Signalnachricht" (ein Konzept, das auf dem Qt-Mechanismus "Signale und Slots" basiert), hat jedoch kein vordefiniertes Ziel. Da ihr Zweck darin besteht, in einem One-to-many-Kontext verwendet zu werden, sind Signalnachrichten so konzipiert, dass sie über einen "Opt-in"-Mechanismus funktionieren.

Das Modul Qt D-Bus kapselt das Low-Level-Konzept von Nachrichten vollständig in einen einfacheren, objektorientierten Ansatz, der den Qt-Entwicklern vertraut ist. In den meisten Fällen muss sich der Entwickler nicht um das Senden oder Empfangen von Nachrichten kümmern.

Service-Namen

Wenn Anwendungen über einen Bus kommunizieren, erhalten sie einen so genannten "Service-Namen": Das ist die Art und Weise, wie diese Anwendung von anderen Anwendungen am selben Bus erkannt werden möchte. Die Servicenamen werden vom D-Bus-Busdämon vermittelt und dienen dazu, Nachrichten von einer Anwendung zur anderen weiterzuleiten. Ein analoges Konzept zu den Dienstnamen sind IP-Adressen und Hostnamen: Ein Computer hat normalerweise eine IP-Adresse und kann einen oder mehrere Hostnamen haben, die mit ihm verbunden sind, je nach den Diensten, die er dem Netz zur Verfügung stellt.

Wird hingegen kein Bus verwendet, werden auch keine Dienstnamen verwendet. Vergleicht man dies wiederum mit einem Computernetz, so entspricht dies einem Punkt-zu-Punkt-Netz: Da die Gegenstelle bekannt ist, ist es nicht erforderlich, Hostnamen zu verwenden, um sie oder ihre IP-Adresse zu finden.

Das Format eines D-Bus-Dienstnamens ist dem eines Hostnamens sehr ähnlich: Es handelt sich um eine durch Punkte getrennte Folge von Buchstaben und Ziffern. Es ist sogar üblich, den Namen Ihres Dienstes nach dem Domänennamen der Organisation zu benennen, die diesen Dienst definiert hat.

Der D-Bus-Dienst wird zum Beispiel von freedesktop.org definiert und ist auf dem Bus unter dem Dienstnamen zu finden:

org.freedesktop.DBus

Objektpfade

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 besitzen. Ein Unterschied besteht jedoch darin, dass es das Konzept des "Root-Objekts" gibt, das alle Objekte als ultimativen Elternteil haben.

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

Wie diese werden Objektpfade in D-Bus ähnlich wie Pfadnamen im Dateisystem gebildet: Sie sind 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 Schrägstrich enden.

Schnittstellen

Schnittstellen ähneln den abstrakten Klassen in C++ und dem Java-Schlüsselwort interface und deklarieren den "Vertrag", der zwischen Aufrufer und Empfänger geschlossen wird. Das heißt, sie legen die Namen der Methoden, Signale und Eigenschaften fest, die verfügbar sind, sowie das Verhalten, das von beiden Seiten erwartet wird, wenn die Kommunikation hergestellt ist.

Qt verwendet einen sehr ähnlichen Mechanismus in seinem Plugin-System: Basisklassen in C++ werden durch das Makro Q_DECLARE_INTERFACE() mit einem eindeutigen Bezeichner verbunden.

D-Bus-Schnittstellennamen werden in der Tat ähnlich benannt, wie es das Qt-Plugin-System vorschlägt: ein Bezeichner, der normalerweise aus dem Domänennamen der Entität gebildet wird, die diese Schnittstelle definiert hat.

Spickzettel

Um sich die Benennungsformate und ihre Zwecke leichter zu merken, kann die folgende Tabelle verwendet werden:

Fehlersuche

Bei der Entwicklung von Anwendungen, die den D-Bus verwenden, ist es manchmal nützlich, Informationen über die Nachrichten zu sehen, die von den einzelnen Anwendungen über den Bus gesendet und empfangen werden.

Diese Funktion kann für jede Anwendung aktiviert werden, indem die Umgebungsvariable QDBUS_DEBUG gesetzt wird, bevor jede Anwendung ausgeführt wird. Zum Beispiel können wir das Debugging nur für das Auto im Beispiel des ferngesteuerten D-Bus-Autos aktivieren, indem wir den Controller und das Auto auf folgende Weise ausführen:

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

Die Informationen über die Meldungen werden in die Konsole geschrieben, von der aus die Anwendung gestartet wurde.