Qt D-Bus Présentation

D-Bus est un mécanisme de communication interprocessus (IPC) et d’appel de procédure à distance (RPC) initialement développé pour Linux afin de remplacer les solutions IPC existantes et concurrentes par un protocole unifié. Il a également été conçu pour permettre la communication entre les processus au niveau système (tels que les services d’impression et les pilotes matériels) et les processus utilisateur normaux.

Il utilise un protocole de transmission de messages binaires rapide, adapté à la communication au sein d’une même machine grâce à sa faible latence et à sa faible surcharge. Sa spécification est actuellement définie par le projet freedesktop.org et est accessible à tous.

La communication s’effectue généralement via une application serveur centrale appelée « bus » (d’où son nom), mais une communication directe d’application à application est également possible. Lorsqu’elles communiquent sur un bus, les applications peuvent interroger les autres applications et services disponibles, ainsi qu’en activer un à la demande.

Les bus

Les bus D-Bus sont utilisés lorsqu’une communication « plusieurs à plusieurs » est souhaitée. Pour ce faire, un serveur central est lancé avant que toute application puisse se connecter au bus. Ce serveur est chargé de garder la trace des applications connectées et d’acheminer correctement les messages de leur source à leur destination.

De plus, D-Bus définit deux bus bien connus, appelés le bus système et le bus de session. Ces bus sont particuliers dans la mesure où ils possèdent une sémantique bien définie : certains services sont destinés à se trouver sur l’un de ces bus, ou sur les deux.

Par exemple, une application souhaitant interroger la liste des périphériques matériels connectés à l’ordinateur communiquera probablement avec un service disponible sur le bus système, tandis que le service permettant d’ouvrir le navigateur web de l’utilisateur se trouvera probablement sur le bus de session.

Sur le bus système, on peut également s'attendre à trouver des restrictions concernant les services que chaque application est autorisée à proposer. Par conséquent, on peut être raisonnablement certain que si un certain service est présent, il est proposé par une application de confiance.

Concepts

Messages

Au niveau bas, les applications communiquent via D-Bus en s'échangeant des messages. Les messages servent à relayer les appels de procédure à distance ainsi que les réponses et les erreurs qui y sont associées. Lorsqu’ils sont utilisés sur un bus, les messages ont une destination, ce qui signifie qu’ils ne sont acheminés qu’aux parties concernées, évitant ainsi la congestion due à l’« essaimage » ou à la diffusion générale.

Un type particulier de message appelé « message de signal » (un concept basé sur le mécanisme des signaux et slots de Qt) n’a toutefois pas de destinataire prédéfini. Son objectif étant d’être utilisé dans un contexte « un-à-plusieurs », les messages de signal sont conçus pour fonctionner selon un mécanisme d’« opt-in ».

Le module Qt D-Bus encapsule entièrement le concept de bas niveau des messages dans une approche plus simple et orientée objet, familière aux développeurs Qt. Dans la plupart des cas, le développeur n’a pas à se soucier de l’envoi ou de la réception des messages.

Noms de services

Lorsqu’elles communiquent via un bus, les applications obtiennent ce qu’on appelle un « nom de service » : il s’agit de la manière dont cette application choisit d’être identifiée par les autres applications présentes sur le même bus. Les noms de service sont gérés par le démon D-Bus et servent à acheminer les messages d’une application à une autre. Les adresses IP et les noms d'hôtes constituent un concept analogue à celui des noms de service : un ordinateur possède généralement une adresse IP et peut être associé à un ou plusieurs noms d'hôtes, en fonction des services qu'il fournit au réseau.

En revanche, si aucun bus n’est utilisé, les noms de service ne le sont pas non plus. Si l’on fait à nouveau le parallèle avec un réseau informatique, cela équivaudrait à un réseau point à point : puisque le pair est connu, il n’est pas nécessaire d’utiliser des noms d’hôte pour le localiser ni de connaître son adresse IP.

Le format d’un nom de service D-Bus est en effet très similaire à celui d’un nom d’hôte : il s’agit d’une suite de lettres et de chiffres séparés par des points. La pratique courante consiste même à nommer son service en fonction du nom de domaine de l’organisation qui a défini ce service.

Par exemple, le service D-Bus est défini par freedesktop.org et est accessible sur le bus sous le nom de service :

org.freedesktop.DBus

Chemins d’accès aux objets

À l’instar des hôtes réseau, les applications fournissent des services spécifiques à d’autres applications en exportant des objets. Ces objets sont organisés hiérarchiquement, à l’image de la relation parent-enfant que possèdent les classes dérivées de QObject. Une différence réside toutefois dans l’existence du concept d’« objet racine », qui est le parent ultime de tous les objets.

Si l’on poursuit notre analogie avec les services Web, les chemins d’accès aux objets correspondent à la partie « chemin » d’une URL :

À l’instar de ces dernières, les chemins d’accès aux objets dans D-Bus sont formés à l’image des noms de chemins du système de fichiers : ce sont des étiquettes séparées par des barres obliques, chacune composée de lettres, de chiffres et du caractère de soulignement (« _ »). Elles doivent toujours commencer par une barre oblique et ne doivent pas se terminer par une.

Interfaces

Les interfaces s’apparentent aux classes abstraites en C++ et au mot-clé ` interface ` de Java ; elles définissent le « contrat » établi entre l’appelant et l’appelé. Autrement dit, elles définissent les noms des méthodes, des signaux et des propriétés disponibles, ainsi que le comportement attendu de chaque partie une fois la communication établie.

Qt utilise un mécanisme très similaire dans son système de plugins: les classes de base en C++ sont associées à un identifiant unique via la macro Q_DECLARE_INTERFACE().

Les noms d’interface Qt D-Bus sont, en effet, nommés d’une manière similaire à celle suggérée par le système de plugins Qt : un identifiant généralement construit à partir du nom de domaine de l’entité qui a défini cette interface.

Aide-mémoire

Pour faciliter la mémorisation des formats de nommage et de leurs finalités, le tableau suivant peut être utilisé :

Débogage

Lors du développement d’applications utilisant D-Bus, il est parfois utile de pouvoir consulter des informations sur les messages envoyés et reçus par chaque application via le bus.

Cette fonctionnalité peut être activée application par application en définissant la variable d’environnement ` QDBUS_DEBUG ` avant d’exécuter chaque application. Par exemple, on peut activer le débogage uniquement pour la voiture dans l’exemple « Voiture télécommandée via D-Bus » en exécutant le contrôleur et la voiture de la manière suivante :

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

Les informations relatives aux messages seront affichées sur la console à partir de laquelle l'application a été lancée.