QRemoteObjectHostBase Class

Dokumentation der Mitgliedsfunktionen

void QRemoteObjectHostBase::addHostSideConnection(QIODevice *ioDevice)

Um QRemoteObjectHost::enableRemoting() Quellobjekte über externe QIODevices zu übertragen, benötigt Qt Remote Objects Zugriff auf den Kommunikationskanal ( QIODevice) zwischen den jeweiligen Knoten. Es ist der Aufruf addHostSideConnection(), der dies auf der Quellenseite ermöglicht, wobei die ioDevice als Eingabe dient. Jeder enableRemoting()-Aufruf funktioniert auch ohne den Aufruf von addHostSideConnection, aber der Knoten ist nicht in der Lage, die Quellobjekte freizugeben, ohne die Verbindung zum Replikationsknoten zu erhalten. Bevor Sie diese Funktion aufrufen, 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 remoteObject nicht registriert ist, und gibt true zurück, wenn der Fernzugriff für das Quellobjekt erfolgreich deaktiviert wurde.

Siehe auch enableRemoting().

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

Diese Funktionsüberladung ermöglicht einem Host-Knoten den Fernzugriff auf QObject object mit einer bestimmten (und zur Kompilierungszeit geprüften) Schnittstelle. Client-Knoten, die mit dem Knoten verbunden sind, der dieses Objekt hostet, können Replikate dieser Quelle erhalten.

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 der Satz von Signalen/Slots/Eigenschaften, die durch die Datei TimeModel.rep definiert sind. Bei der Kompilierung wird geprüft, ob die Eingabe QObject die angeforderte API bereitstellen kann, andernfalls wird sie nicht kompiliert. Dadurch kann eine Teilmenge der Schnittstelle von object offengelegt werden, und es sind die von Signal/Slot-Verbindungen unterstützten Konvertierungen möglich.

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

Siehe auch disableRemoting().

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

Ermöglicht es einem Host-Knoten, dynamisch Fernzugriff auf die QObject object zu gewähren. Client-Knoten, die mit dem Knoten verbunden sind, der dieses Objekt hostet, können Replikate dieser Quelle erhalten.

Das optionale name definiert den Nachschlage-Namen, unter dem QObject mit QRemoteObjectNode::acquire() abgerufen werden kann. Wenn nicht explizit gesetzt, wird der in QCLASSINFO_REMOTEOBJECT_TYPE angegebene Name verwendet. Wenn kein solches Makro für QObject definiert wurde, wird QObject::objectName() verwendet.

Gibt false zurück, wenn der aktuelle Knoten ein Client-Knoten ist, oder wenn QObject bereits für das Remoting registriert ist, und true, wenn das Remoting 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 von QAbstractItemModel abgeleiteten Typ). Dies ist nützlich, wenn Sie ein Modell und die HMI für das Modell in verschiedenen Prozessen haben wollen.

Die drei erforderlichen Parameter sind model selbst, name, mit dem das Modell nachgeschlagen werden soll, und roles, das auf der Replica-Seite angezeigt werden soll. Wenn Sie die Auswahl zwischen Quelle und Replikat synchronisieren wollen, kann der optionale Parameter selectionModel verwendet werden. Dies wird nur bei der Verwendung einer einzigen Replik empfohlen.

Hinter den Kulissen stapelt Qt Remote Objects data()-Lookups und holt Daten vor, wenn möglich, um die Modellinteraktion so reaktionsschnell wie möglich zu gestalten.

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

Siehe auch disableRemoting().

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

Weiterleitung von Remote-Objekten aus einem anderen Netzwerk

Die Proxy-Funktionalität ist nützlich, wenn Sie Quellobjekte über mehrere Netzwerke hinweg gemeinsam nutzen wollen. Zum Beispiel, wenn Sie ein eingebettetes Ziel haben, das nur Zielverbindungen verwendet (wie lokal) und Sie einige dieser Objekte extern verfügbar machen wollen.

Ein konkretes Beispiel: Sie haben eine Reihe von Prozessen, die auf Ihrer Zielhardware über eine Registry miteinander kommunizieren, wobei die Registry unter "local:registry" liegt und separate Prozesse einen Knoten unter "local:MyHost" verwenden, der Quellobjekte enthält. Wenn Sie auf diese Objekte zugreifen wollen, aber über tcp, können 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 erstellen Sie 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>();

Dieser würde (intern) einen Knoten in proxyNode erstellen, der (wiederum intern/automatisch) eine Verbindung zur bereitgestellten Registry herstellt (angegeben durch den Parameter registryUrl, in diesem Beispiel "local:registry"). Immer wenn local:registry das Signal remoteObjectAdded ausgibt, wird QRemoteObjectSourceLocation an den filter übergeben, der dem Proxy-Aufruf übergeben wird. Wenn diese Methode "true" zurückgibt (der Standardfilter gibt einfach "true" ohne jegliche Filterung zurück), wird das Objekt vom internen Knoten erworben() und enableRemoting() (sobald die Replik initialisiert ist) auf proxyNode aufgerufen.

Wenn ein hostUrl angegeben wird (was erforderlich ist, um reverseProxy zu aktivieren, aber ansonsten nicht benötigt wird), wird der interne Knoten ein QRemoteObjectHost Knoten sein, der mit der angegebenen Adresse konfiguriert ist. Wenn kein hostUrl angegeben wird, ist der interne Knoten ein QRemoteObjectNode (nicht HostNode).

Gibt true zurück, wenn das Objekt vom internen Knoten erworben wurde.

Siehe auch reverseProxy().

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

Leitet entfernte Objekte an ein anderes Netz weiter.

Mit der Funktion reverseProxy() kann die Funktionalität von proxy() erweitert werden, so dass die Proxy-Funktionalität in der "umgekehrten" Richtung gespiegelt wird. Diese sind unterschiedlich, da die Knotenkommunikation nicht symmetrisch ist, eine Seite ruft enableRemoting() mit einem Quellobjekt auf, die andere Seite ruft acquire() auf, um ein Replikat zu erhalten. Die Verwendung von proxy() ermöglicht es Ihnen, Objekte auf einem Zielgerät aus der Ferne über acquire zu "beobachten", aber es erlaubt nicht, Quellobjekte außerhalb des Zielgeräts aus dem lokalen:* Netzwerk des Geräts zu erhalten. An dieser Stelle kommt reverseProxy() ins Spiel. Wenn ein proxyNode auf diese Weise 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 wird ein anderer Knoten erstellt:

// 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 proxy()-Funktionalität es erlaubt, Quellobjekte in einem anderen Netzwerk zu erwerben(), erlaubt reverseProxy() es, Quellobjekte in ein ansonsten unzugängliches Netzwerk zu "schieben".

Bei Erfolg wird true zurückgegeben, andernfalls false.

Siehe auch proxy().

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

Reimplements: QRemoteObjectNode::setName(const QString &name).

Ähnlich wie QObject::setObjectName() (das diese Methode aufruft), aber diese Version wendet die name auch auf interne Klassen an, die in einigen der Debugging-Ausgaben verwendet werden.