Qt Remote Objects

Konzepte zu Remote-Objekten

Qt Remote Objects (QtRO) ist ein für Qt entwickeltes Modul zur Interprozesskommunikation (IPC). Dieses Modul erweitert die bestehenden Funktionen von Qt, um den Informationsaustausch zwischen Prozessen oder Computern auf einfache Weise zu ermöglichen.

Eine der Schlüsselfunktionen von Qt, die diesen Informationsaustausch ermöglicht, ist die Unterscheidung zwischen der API eines Objekts (definiert durch seine Eigenschaften, Signale und Slots) und der Implementierung dieser API. Der Zweck von QtRO besteht darin, diese erwartete API bereitzustellen, selbst wenn sich das eigentliche „ QObject “ in einem anderen Prozess befindet. Ein Slot, der auf einer Kopie eines Objekts (dem „Replica“ in QtRO) aufgerufen wird, wird zur Bearbeitung an das eigentliche Objekt (die „Source“ in QtRO) weitergeleitet. Jedes „Replica“ erhält Aktualisierungen der „Source“, sei es in Form von Eigenschaftsänderungen oder von ausgesendeten Signalen.

Ein „Replica“ ist ein schlanker Proxy für das „Source“- Objekt, unterstützt jedoch dieselben Verbindungen und dasselbe Verhalten wie QObjects, wodurch es genauso verwendet werden kann wie jede andere von Qt bereitgestellte „ QObject “. Im Hintergrund übernimmt QtRO alles, was erforderlich ist, damit das „Replica“ wie seine „Source“ erscheint.

Beachten Sie, dass sich Remote-Objekte anders verhalten als herkömmliche RPC-Implementierungen (Remote Procedure Call), zum Beispiel:

• Bei RPC sendet der Client eine Anfrage und wartet auf die Antwort.
• Bei RPC sendet der Server nichts an den Client, es sei denn, es handelt sich um eine Antwort auf eine Anfrage.
• Häufig ist RPC so konzipiert, dass verschiedene Clients voneinander unabhängig sind: So können beispielsweise zwei Clients bei einem Kartendienst nach dem Weg fragen und unterschiedliche Ergebnisse erhalten.

Zwar ist es möglich, dieses RPC-ähnliche Verhalten in QtRO als „Sources“ ohne Eigenschaften und Slots mit Rückgabewerten zu implementieren, doch verbirgt QtRO die Tatsache, dass die Verarbeitung tatsächlich remote erfolgt. Man lässt sich von einem Knoten die Replica bereitstellen, anstatt sie selbst zu erstellen, nutzt möglicherweise die Statussignale (isReplicaValid()), interagiert dann aber mit dem Objekt wie mit jedem anderen auf „ QObject “ basierenden Typ.

Anwendungsfall: GPS

Betrachten wir einen Sensor wie beispielsweise einen GPS-Empfänger (Global Positioning System). In QtRO-Begriffen:

• Die „Source“ wäre der Prozess, der direkt mit der GPS-Hardware interagiert und Ihren aktuellen Standort ermittelt.
• Der Standort würde als „ QObject “-Eigenschaften bereitgestellt; die regelmäßigen Aktualisierungen des Standorts würden diese Eigenschaften aktualisieren und Signale bei Eigenschaftsänderungen ausgeben.
• Replikate würden in anderen Prozessen erstellt und würden Ihren aktuellen Standort stets kennen, bräuchten jedoch keinerlei Logik, um den Standort aus den Sensordaten zu berechnen.
• Das Anbinden an das Signal „Standort geändert“ auf der Replik würde wie erwartet funktionieren: Das von der „Source“ ausgesendete Signal würde die Signalausgabe auf jeder Replik auslösen.

Anwendungsfall: Zugriff auf einen Drucker

Stellen Sie sich einen Dienst vor, der den Zugriff auf einen Drucker ermöglicht. In QtRO-Begriffen ausgedrückt:

• Die „Source“ wäre der Prozess, der den Drucker direkt steuert.
• Die Tintenfüllstände und der Druckerstatus würden durch „ QObject “-Eigenschaften überwacht. Aktualisierungen dieser Eigenschaften würden Signale für Eigenschaftsänderungen auslösen.
• Die Schlüsselfunktion – die Möglichkeit, etwas zu drucken – muss an den Drucker zurückgegeben werden. Dies deckt sich übrigens mit dem Qt-Slot-Mechanismus, den QtRO nutzt, damit Replikate Aufrufe an die Quelle senden können. Tatsächlich gehen Eigenschaften und Signale von der Quelle zu den Replikaten; Slots gehen vom Replikat zur Quelle.
• Wenn ein Druckauftrag angenommen wird, ändert sich der Druckerstatus, was eine Änderung der Status-Eigenschaft auslöst. Dies wird dann an alle Replikate gemeldet.

Verwendung des Moduls

Die Verwendung eines Qt-Moduls erfordert die Verknüpfung mit der Modulbibliothek, entweder direkt oder über andere Abhängigkeiten. Mehrere Build-Tools bieten hierfür spezielle Unterstützung, darunter CMake und qmake.

Erstellen mit CMake

Verwenden Sie den Befehl „ find_package() “, um die benötigten Modulkomponenten im Paket „ Qt6 “ zu finden:

find_package(Qt6 REQUIRED COMPONENTS RemoteObjects)

Siehe auch die Übersicht „Erstellen mit CMake “.

Erstellen mit qmake

Um das Modul für die Erstellung mit qmake zu konfigurieren, fügen Sie das Modul als Wert der Variablen „ QT “ in der .pro-Datei des Projekts hinzu:

QT       += remoteobjects

Artikel und Anleitungen

• Erste Schritte mit Qt Remote Objects
• Nodes
• Quellen
• Replikate
• Registry
• Verwendung benutzerdefinierter Transporte
  • Externe QIODevices
  • Implementierung benutzerdefinierter Transport-Backends
• Compiler
• Interaktion mit Remote-Objekten
• Fehlerbehebung
• Protokollversionierung
• Beispiele
• Sicherheitshinweise

API-Referenz

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

Lizenzen

Qt Remote Objects ist unter kommerziellen Lizenzen von The Qt Company erhältlich. Darüber hinaus ist sie unter der GNU Lesser General Public License, Version 3, oder der GNU General Public License, Version 2, verfügbar. Weitere Informationen finden Sie unter „Qt-Lizenzierung “.