Qt D-Bus Vue d'ensemble

D-Bus est un mécanisme de communication interprocessus (IPC) et d'appel de procédure à distance (RPC) développé à l'origine 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 de niveau système (tels que les services d'imprimante et de pilote de matériel) et les processus utilisateur normaux.

Il utilise un protocole binaire rapide de passage de messages, qui convient à la communication entre machines identiques en raison de sa faible latence et de son faible encombrement. Sa spécification est actuellement définie par le projet freedesktop.org et est disponible pour toutes les parties.

En général, la communication se fait par l'intermédiaire d'un serveur central appelé "bus" (d'où son nom), mais la communication directe entre applications est également possible. Lorsqu'elles communiquent sur un bus, les applications peuvent demander quels sont les autres applications et services disponibles, et en activer un à la demande.

Les bus

Les bus D-Bus sont utilisés lorsqu'une communication de plusieurs à plusieurs est souhaitée. Pour ce faire, un serveur central est lancé avant qu'une application puisse se connecter au bus. Ce serveur est chargé de suivre les applications connectées et d'acheminer correctement les messages de leur source à leur destination.

En outre, D-Bus définit deux bus bien connus, appelés bus système et bus de session. Ces bus sont particuliers en ce sens qu'ils ont une sémantique bien définie : certains services sont définis pour être trouvés dans l'un ou l'autre de ces bus, ou dans les deux.

Par exemple, une application souhaitant interroger la liste des périphériques 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, vous pouvez également vous attendre à trouver des restrictions sur les services que chaque application est autorisée à offrir. Par conséquent, vous pouvez être raisonnablement certain que si un certain service est présent, il est offert par une application de confiance.

Concepts

Messages

Au niveau le plus bas, les applications communiquent sur D-Bus en s'envoyant des messages. Les messages sont utilisés pour 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 sont acheminés uniquement vers les parties intéressées, évitant ainsi la congestion due à l'"essaimage" ou à la diffusion.

Un type spécial de message appelé "message de signal" (un concept basé sur le mécanisme de signaux et d'emplacements de Qt), cependant, n'a pas de destination prédéfinie. Étant donné qu'ils sont destinés à être utilisés dans un contexte un-à-plusieurs, les messages de signal sont conçus pour fonctionner par le biais d'un mécanisme "opt-in".

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

Noms de service

Lorsqu'elles communiquent sur un bus, les applications obtiennent ce que l'on appelle un "nom de service" : c'est la façon dont cette application choisit d'être connue par les autres applications sur le même bus. Les noms de service sont gérés par le démon de bus D-Bus et sont utilisés pour acheminer les messages d'une application à l'autre. Un concept analogue aux noms de service est celui des adresses IP et des noms d'hôte : un ordinateur a normalement une adresse IP et peut être associé à un ou plusieurs noms d'hôte, en fonction des services qu'il fournit au réseau.

En revanche, si un bus n'est pas utilisé, les noms de service ne le sont pas non plus. Si nous comparons cela à un réseau informatique, cela équivaudrait à un réseau point à point : puisque l'homologue est connu, il n'est pas nécessaire d'utiliser des noms d'hôte pour le trouver ou trouver son adresse IP.

Le format d'un nom de service D-Bus est en fait très similaire à celui d'un nom d'hôte : il s'agit d'une séquence de lettres et de chiffres séparés par des points. La pratique courante consiste même à nommer le nom de votre 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 peut être trouvé sur le bus sous le nom du service :

org.freedesktop.DBus

Chemins d'accès aux objets

Comme les hôtes du réseau, les applications fournissent des services spécifiques à d'autres applications en exportant des objets. Ces objets sont organisés de manière hiérarchique, un peu comme la relation parent-enfant que les classes dérivées de QObject possèdent. La différence réside toutefois dans l'existence du concept d'"objet racine", dont tous les objets sont les parents ultimes.

Si nous poursuivons notre analogie avec les services Web, les chemins d'accès aux objets sont équivalents à la partie chemin d'accès d'une URL :

Comme eux, les chemins d'accès aux objets dans D-Bus sont formés comme des noms de chemin sur le système de fichiers : ce sont des étiquettes séparées par des barres obliques, chacune étant composée de lettres, de chiffres et du caractère de soulignement ("_"). Ils doivent toujours commencer par une barre oblique et ne doivent pas se terminer par une barre oblique.

Interfaces

Les interfaces sont similaires aux classes abstraites de C++ et au mot-clé interface de Java et déclarent le "contrat" établi entre l'appelant et l'appelé. En d'autres termes, elles définissent les noms des méthodes, des signaux et des propriétés disponibles, ainsi que le comportement attendu de part et d'autre lorsque la communication est é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 au moyen de la macro Q_DECLARE_INTERFACE().

Les noms d'interface de Qt-Bus sont, en fait, nommés d'une manière similaire à celle suggérée par le système de plugin de 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 dénomination et de leurs objectifs, 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 sur le bus par chaque application.

Cette fonctionnalité peut être activée pour chaque application en définissant la variable d'environnement QDBUS_DEBUG avant d'exécuter chaque application. Par exemple, nous pouvons activer le débogage uniquement pour la voiture dans l'exemple de la voiture télécommandée 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 écrites dans la console à partir de laquelle l'application a été lancée.