QRemoteObjectHostBase Class

Dokumentation der Mitgliedsfunktionen

void QRemoteObjectHostBase::addHostSideConnection(QIODevice *ioDevice)

Um Source-Objekte über externe QIODevices mit ` QRemoteObjectHost::enableRemoting()` zu übertragen, benötigt ` Qt Remote Objects ` Zugriff auf den Kommunikationskanal (ein ` QIODevice`) zwischen den jeweiligen Knoten. Dies wird auf der Source-Seite durch den Aufruf von `addHostSideConnection()` ermöglicht, der ` ioDevice ` als Eingabe verwendet. Jeder Aufruf von ` enableRemoting()` funktioniert zwar auch ohne den Aufruf von `addHostSideConnection`, aber der Knoten kann die Quellobjekte nicht freigeben, ohne dass ihm die Verbindung zum Replikat-Knoten bereitgestellt wird. Vor dem Aufruf dieser Funktion müssen Sie ` setHostUrl()` mit einer eindeutigen URL und ` AllowExternalRegistration` aufrufen.

Siehe auch addClientSideConnection.

[invokable] bool QRemoteObjectHostBase::disableRemoting(QObject *remoteObject)

Deaktiviert den Fernzugriff für das „ QObject “ remoteObject. Gibt „ false “ zurück, wenn der aktuelle Knoten ein Client-Knoten ist oder wenn das „ remoteObject “ nicht registriert ist, und gibt „ true “ zurück, wenn der Fernzugriff für das „Source“-Objekt erfolgreich deaktiviert wurde.

Siehe auch enableRemoting().

template <template <typename> typename ApiDefinition, typename ObjectType> bool QRemoteObjectHostBase::enableRemoting(ObjectType *object)

Diese Template-Funktionsüberladung ermöglicht es einem Host-Knoten, Fernzugriff auf eine „ QObject “ ( object ) mit einer festgelegten (und zur Kompilierungszeit überprüften) Schnittstelle bereitzustellen. Client-Knoten, die mit dem Knoten verbunden sind, auf dem dieses Objekt gehostet wird, können Replikate dieser Quelle abrufen.

Dies lässt sich am besten anhand eines Beispiels veranschaulichen:

#include "rep_TimeModel_source.h"
MinuteTimer timer;
hostNode.enableRemoting<MinuteTimerSourceAPI>(&timer);

Hier ist die `MinuteTimerSourceAPI` die „ ApiDefinition “, die die Menge der durch die Datei `TimeModel.rep` definierten Signale, Slots und Eigenschaften darstellt. Es werden Kompilierungszeitprüfungen durchgeführt, um sicherzustellen, dass die Eingabe-„ QObject “ die angeforderte API bereitstellen kann; andernfalls schlägt die Kompilierung fehl. Dies ermöglicht es, eine Teilmenge der Schnittstelle von „ object “ bereitzustellen, und legt fest, welche Arten von Konvertierungen bei Signal-/Slot-Verbindungen unterstützt werden.

Gibt „ false “ zurück, wenn der aktuelle Knoten ein Client-Knoten ist oder wenn der „ QObject “ bereits für die Remote-Nutzung registriert ist, und „ true “, wenn die Remote-Nutzung für den „ QObject “ erfolgreich aktiviert wurde.

Siehe auch disableRemoting().

[invokable] bool QRemoteObjectHostBase::enableRemoting(QObject *object, const QString &name = QString())

Ermöglicht einem Host-Knoten, dynamisch Fernzugriff auf die Quelle „ QObject “ object bereitzustellen. Client-Knoten, die mit dem Knoten verbunden sind, auf dem dieses Objekt gehostet wird, können Replikate dieser Quelle abrufen.

Das optionale „ name “ definiert den Suchnamen, unter dem die „ QObject “ mithilfe von „ QRemoteObjectNode::acquire()“ abgerufen werden kann. Wird dieser nicht explizit festgelegt, wird der in „QCLASSINFO_REMOTEOBJECT_TYPE“ angegebene Name verwendet. Wurde für „ QObject “ kein solches Makro definiert, wird „ QObject::objectName()“ verwendet.

Gibt „ false “ zurück, wenn der aktuelle Knoten ein Client-Knoten ist oder wenn das „ QObject “ bereits für die Remote-Verwendung registriert ist, und „ true “, wenn die Remote-Funktion für das dynamische „ QObject “ erfolgreich aktiviert wurde.

Siehe auch disableRemoting().

bool QRemoteObjectHostBase::enableRemoting(QAbstractItemModel *model, const QString &name, const QList<int> roles, QItemSelectionModel *selectionModel = nullptr)

Diese Überladung von `enableRemoting()` ist spezifisch für ` QAbstractItemModel `-Typen (oder jeden Typ, der von ` QAbstractItemModel` abgeleitet ist). Dies ist nützlich, wenn Sie das Modell und die HMI für das Modell in unterschiedlichen Prozessen haben möchten.

Die drei erforderlichen Parameter sind das „ model “ selbst, das „ name “, über das das Modell gesucht werden soll, und das „ roles “, das auf der Replica-Seite verfügbar gemacht werden soll. Wenn Sie die Auswahl zwischen Source und Replica synchronisieren möchten, können Sie den optionalen Parameter „ selectionModel “ verwenden. Dies wird nur empfohlen, wenn Sie eine einzelne Replica verwenden.

Im Hintergrund fasst „ Qt Remote Objects “ die „data()“-Abfragen zu Batches zusammen und ruft Daten nach Möglichkeit vorab ab, um die Interaktion mit dem Modell so reaktionsschnell wie möglich zu gestalten.

Gibt ` false ` zurück, wenn der aktuelle Knoten ein Client-Knoten ist oder wenn die ` QObject ` bereits für die Remote-Nutzung registriert ist, und ` true `, wenn die Remote-Nutzung für die ` QAbstractItemModel` erfolgreich aktiviert wurde.

Siehe auch disableRemoting().

bool QRemoteObjectHostBase::proxy(const QUrl &registryUrl, const QUrl &hostUrl = {}, QRemoteObjectHostBase::RemoteObjectNameFilter filter = [](QStringView, QStringView) {return true; })

Remote-Objekte aus einem anderen Netzwerk weiterleiten

Die Proxy-Funktionalität ist nützlich, wenn Sie Quellobjekte über mehrere Netzwerke hinweg gemeinsam nutzen möchten. Beispielsweise, wenn Sie ein eingebettetes Zielsystem haben, das ausschließlich zielseitige Verbindungen (wie „local“) verwendet, und Sie einige dieser Objekte extern verfügbar machen möchten.

Ein konkretes Beispiel: Angenommen, Sie haben eine Reihe von Prozessen, die auf Ihrer Zielhardware über eine Registry miteinander kommunizieren, wobei sich die Registry unter „local:registry“ befindet und separate Prozesse einen Knoten unter „local:MyHost“ nutzen, der Quellobjekte enthält. Wenn Sie auf diese Objekte zugreifen möchten, jedoch über TCP, könnten Sie einen neuen „proxyNode“ wie folgt erstellen:

// myInternalHost is a node only visible on the device...
QRemoteObjectHost myInternalHost("local:MyHost");
myInternalHost.enableRemoting<SomeObject>(&someObject);

// Regular host node, listening on port 12123, so visible to other
// devices
QRemoteObjectHost proxyNode("tcp://localhost:12123");

// Enable proxying objects from nodes on the local machine's internal
// QtRO bus
proxyNode.proxy("local:registry");

Und von einem anderen Gerät aus erstellst du einen weiteren Knoten:

// NB: localhost resolves to a different ip address than proxyNode
QRemoteObjectHost nodeOnRemoteDevice("tcp://localhost:23234");

// Connect to the target's proxyNode directly, or use a tcp registry...
nodeOnRemoteDevice.connectToNode("tcp://<target device>:12123");

// Because of the proxy, we can get the object over tcp/ip port 12123,
// even though we can't connect directly to "local:MyHost"
SomeObject *so = nodeOnRemoteDevice.acquire<SomeObject>();

Dadurch würde (intern) ein Knoten in `proxyNode` erstellt, der sich (ebenfalls intern/automatisch) mit der angegebenen Registrierung verbindet (angegeben durch den Parameter ` registryUrl `, in diesem Beispiel „local:registry“). Immer wenn „local:registry“ das Signal „ remoteObjectAdded “ aussendet, wird „ QRemoteObjectSourceLocation “ an die im Proxy-Aufruf angegebene Methode „ filter “ übergeben. Wenn diese Methode „true“ zurückgibt (der Standardfilter gibt ohne jegliche Filterung einfach „true“ zurück), wird das Objekt über „acquire()“ vom internen Knoten abgerufen und „ enableRemoting()“ (sobald die Replik initialisiert ist) auf „proxyNode“ aufgerufen.

Wird ein „ hostUrl “ angegeben (was zur Aktivierung von „ reverseProxy “ erforderlich ist, ansonsten jedoch nicht benötigt wird), handelt es sich bei dem internen Knoten um einen „ QRemoteObjectHost “-Knoten, der mit der angegebenen Adresse konfiguriert ist. Wird kein „ hostUrl “ angegeben, handelt es sich bei dem internen Knoten um einen „ QRemoteObjectNode “ (nicht um einen „HostNode“).

Gibt „ true “ zurück, wenn das Objekt vom internen Knoten abgerufen wurde.

Siehe auch „ reverseProxy()“.

bool QRemoteObjectHostBase::reverseProxy(QRemoteObjectHostBase::RemoteObjectNameFilter filter = [](QStringView, QStringView) {return true; })

Leitet Remote-Objekte an ein anderes Netzwerk weiter.

Die Funktion `reverseProxy()` ermöglicht eine Erweiterung der Funktionalität von ` proxy()`, wodurch die Proxy-Funktionalität gewissermaßen in „umgekehrter“ Richtung gespiegelt wird. Diese unterscheiden sich voneinander, da die Kommunikation zwischen den Knoten nicht symmetrisch ist: Eine Seite ruft ` enableRemoting()` mit einem `Source` -Objekt auf, die andere Seite ruft ` acquire()` auf, um eine Replik zu erhalten. Mit ` proxy()` können Sie Objekte auf einem Zielgerät per `acquire` aus der Ferne „beobachten“, es ist jedoch nicht möglich, Source-Objekte außerhalb des Ziels aus dem lokalen `local:*`-Netzwerk des Geräts abzurufen. Hier kommt `reverseProxy()` ins Spiel. Wenn ein `proxyNode` wie folgt erstellt wird:

// myInternalHost is a node only visible on the device...
QRemoteObjectHost myInternalHost("local:MyHost", "local:registry");

// RegistryHost node, listening on port 12123, so visible to other
// devices.  The node must be a RegistryHost, so the Sources on
// the "outside" network can be forwarded to the inner network.
QRemoteObjectRegistryHost proxyNode("tcp://0.0.0.0:12123");

// Enable proxying objects from nodes on the local machine's internal
// QtRO bus.  Note the hostUrl parameter is now needed.
proxyNode.proxy("local:registry", "local:fromProxy");
proxyNode.reverseProxy();

Und von einem anderen Gerät aus erstellen Sie einen weiteren Knoten:

// Listen on a local port, and connect to "proxyNode" as the registry.
// NB: localhost resolves to a different ip address than proxyNode
QRemoteObjectHost nodeOnRemoteDevice("tcp://localhost:23234",
                                     "tcp://<target device>:12123");

// Because of the reverseProxy, we can expose objects on this device
// and they will make their way to proxyNode...
nodeOnRemoteDevice.enableRemoting<OtherObject>(&otherObject);

// Acquire() can now see the objects on other devices through proxyNode,
// due to the reverseProxy call.
OtherObject *oo = myInternalHost.acquire<OtherObject>();

Während die Funktion „ proxy()“ das Abrufen von Quell objekten aus einem anderen Netzwerk ermöglicht, erlaubt „reverseProxy()“, Quell objekte in ein ansonsten unzugängliches Netzwerk zu „pushen“.

Gibt bei Erfolg „ true “ zurück, andernfalls „ false “.

Siehe auch proxy().

[override virtual] void QRemoteObjectHostBase::setName(const QString &name)

Implementiert: ` QRemoteObjectNode::setName(const QString &name)`.

Ähnlich wie QObject::setObjectName() (das von dieser Methode aufgerufen wird), wendet diese Version die „ name “ jedoch auch auf interne Klassen an, die in einigen Debugging-Ausgaben verwendet werden.