Qt Remote Objects

Concepts relatifs aux objets distants

Qt Remote Objects (QtRO) est un module de communication interprocessus (IPC) développé pour Qt. Ce module étend les fonctionnalités existantes de Qt afin de permettre l'échange d'informations entre processus ou ordinateurs, en toute simplicité.

L'une des principales caractéristiques de Qt, qui permet cet échange d'informations, est la distinction entre l'API d'un objet (définie par ses propriétés, ses signaux et ses slots) et l'QObject de cette API. L'objectif de QtRO est de respecter cette API attendue, même si l' réelle se trouve dans un autre processus. Un slot appelé sur une copie d’un objet (la « réplique » dans QtRO) est transféré vers l’objet réel (la « source » dans QtRO) pour y être traité. Chaque réplique reçoit les mises à jour de la source, qu’il s’agisse de modifications de propriétés ou de signaux émis.

Un « Replica » est un proxy léger pour l’objet « Source », mais il prend en charge les mêmes connexions et le même comportement que les QObjects, ce qui le rend utilisable de la même manière que n’importe quelle autre QObject fournie par Qt. En arrière-plan, QtRO gère tout ce qui est nécessaire pour que le « Replica » se comporte comme sa « Source ».

Notez que les objets distants se comportent différemment des implémentations traditionnelles d’appels de procédure à distance (RPC), par exemple :

• En RPC, le client envoie une requête et attend la réponse.
• En RPC, le serveur n’envoie rien au client à moins que ce ne soit en réponse à une requête.
• Souvent, la conception du RPC est telle que les différents clients sont indépendants les uns des autres : par exemple, deux clients peuvent demander un itinéraire à un service de cartographie et obtenir des résultats différents.

Bien qu’il soit possible d’implémenter ce comportement de type RPC dans QtRO, à l’aide de Sources sans propriétés et de slots ayant des valeurs de retour, QtRO masque le fait que le traitement s’effectue réellement à distance. Vous laissez un nœud vous fournir la réplique au lieu de la créer vous-même, vous utilisez éventuellement les signaux d’état (isReplicaValid()), mais vous interagissez ensuite avec l’objet comme vous le feriez avec n’importe quel autre type basé sur « QObject ».

Cas d’utilisation : GPS

Prenons l’exemple d’un capteur tel qu’un récepteur GPS (Global Positioning System). En termes QtRO :

• La « Source » serait le processus qui interagit directement avec le matériel GPS et détermine votre position actuelle.
• La position serait exposée sous forme de propriétés d QObject; les mises à jour périodiques de la position mettraient à jour ces propriétés et émettraient des signaux de modification de propriété.
• Des répliques seraient créées dans d’autres processus et connaîtraient toujours votre position actuelle, sans pour autant avoir besoin de la logique permettant de calculer cette position à partir des données du capteur.
• La connexion au signal de changement de position sur la réplique fonctionnerait comme prévu : le signal émis par la source déclencherait l’émission du signal sur chaque réplique.

Cas d’utilisation : accès à une imprimante

Prenons l’exemple d’un service permettant d’accéder à une imprimante. En termes de QtRO :

• La source serait le processus contrôlant directement l’imprimante.
• Les niveaux d’encre et l’état de l’imprimante seraient surveillés par des propriétés d’ QObject. Les mises à jour de ces propriétés émettraient des signaux de modification de propriété.
• La fonctionnalité clé – la possibilité d’imprimer quelque chose – doit être transmise à l’imprimante. Cela correspond d’ailleurs au mécanisme des slots de Qt, que QtRO utilise pour permettre aux répliques d’effectuer des appels vers la source. En effet, les propriétés et les signaux vont de la source vers les répliques ; les slots vont de la réplique vers la source.
• Lorsqu’une demande d’impression est acceptée, l’état de l’imprimante change, ce qui déclenche une modification de la propriété « status ». Ce changement est ensuite signalé à tous les réplicas.

Utilisation du module

L’utilisation d’un module Qt nécessite une liaison avec la bibliothèque du module, soit directement, soit via d’autres dépendances. Plusieurs outils de compilation prennent cela en charge, notamment CMake et qmake.

Compilation avec CMake

Utilisez la commande ` find_package() ` pour localiser les composants du module nécessaires dans le paquet ` Qt6 ` :

find_package(Qt6 REQUIRED COMPONENTS RemoteObjects)

Voir également la présentation « Compilation avec CMake ».

Compilation avec qmake

Pour configurer le module en vue d'une compilation avec qmake, ajoutez le module en tant que valeur de la variable « QT » dans le fichier .pro du projet :

QT       += remoteobjects

Articles et guides

• Premiers pas avec Qt Remote Objects
• Nodes
• Sources
• Répliques
• Registre
• Utilisation de transports personnalisés
  • Périphériques QIO externes
  • Implémentation de backends de transport personnalisés
• Compilateur
• Interaction avec des objets distants
• Dépannage
• Gestion des versions du protocole
• Exemples
• Considérations relatives à la sécurité

Référence de l'API

• Qt Remote Objects C++ Classes
• Qt Remote Objects QML Types

Licences

Qt Remote Objects est disponible sous licence commerciale auprès de The Qt Company. Elle est également disponible sous licence GNU Lesser General Public License, version 3, ou GNU General Public License, version 2. Pour plus d'informations, consultez la page Licences Qt.