Qt Remote Objects Nodes▲
In a QtRO network, information is passed between processes via QRemoteObjectNodes ("nodes"). This peer-to-peer functionality uses a small number of distinct packets passing the necessary data between nodes.
Each process that participates in the network instantiates a Node-based type, such as QRemoteObjectNode, QRemoteObjectHost, or QRemoteObjectRegistryHost. The host types of Nodes provide additional functionality. Both QRemoteObjectHost and QRemoteObjectRegistryHost support the enableRemoting() and the corresponding disableRemoting() methods, which are the key methods to expose source objects to the network. To use the Registry functionality, you need to have a QRemoteObjectRegistryHost on the network. Then, all other nodes can pass the RegistryHost's URL to the Node's registryAddress constructor parameter, or pass the URL to the setRegistryUrl() method.
Since QtRO is a peer-to-peer network, to acquire() a valid Replica, the replica's node needs to be connected to the node that hosts its Source. A host node is a node that allows other nodes to connect to it, which is accomplished by giving hosts unique addresses. This address is provided to the QRemoteObjectHost constructor or set by the setHostUrl method. The node from which a replica is requested must establish the connection to the host node, to initialize the replica and keep it up to date.
Connecting Nodes using QtRO URLs▲
Host Nodes use custom URLs to simplify connections. Currently, QtRO supports two types of connections:
-
A TCP connection using the standard TCP/IP protocol - supports connections between devices as well as between processes on the same device.
-
A local connection - supports connections between processes on the same device. This type of connection can have less overhead, depending on the underlying Operating System features.
For local connections, you must use a unique name. For TCP connections, you must provide a unique address and port number combination.
Currently, QtRO does not include a zeroconf facility. Therefore, all processes or devices must know beforehand, how to connect to each other. A QRemoteObjectRegistry can be used to simplify the connection process for a network with multiple Host Nodes.
The table below summarizes the connection types available:
|
URL |
Notes |
|---|---|
|
("local:service") |
Uses (internally) {QLocalServer}/{QLocalSocket} classes to communicate between nodes. |
|
("tcp://192.168.1.1:9999") |
Uses (internally) {QTcpServer}/{QTcpSocket} classes to communicate between nodes. |
|
("qnx:service") |
QNX OS only. Uses a custom (named) channel for native communication between nodes. |
|
("localabstract:service") |
Since 6.2. Linux/Android OSes only. Uses an abstract namespace for Unix domain sockets. This allows QLocalSocket behavior to work on non-writable devices. |
Nodes have a few enableRemoting() methods that are used to share objects on the network. However, if the node is not a host node, an error is returned.
Other processes or devices that want to interact with a shared object can use one of the node's acquire() methods, to instantiate a replica.