QRemoteObjectNodes (let's shorten the name to Node for now) are what enables the passing of information between processes. All of the QtRO functionality is enabled by a small number of distinct packets passing the necessary data between nodes.
Each process that participates in QtRO's IPC will instantiate a Node-based type (QRemoteObjectNode, QRemoteObjectHost, or QRemoteObjectRegistryHost). The latter 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. In order to use the Registry functionality, there should be one QRemoteObjectRegistryHost on the network. All other nodes can then pass the RegistryHost's URL to the Node's registryAddress constructor parameter, or pass the URL to the setRegistryUrl() method.
QtRO works as a peer-to-peer network. That is, in order to acquire() a valid Replica, the Replica node needs a connection 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 (the address is provided to the QRemoteObjectHost constructor or set by the setHostUrl method). The node that a Replica is requested from must establish the connection to the host node in order to initialize the Replica and keep it up to date.
Host Nodes use custom URLs to simplify connections. While the list will likely be extended, QtRO currently 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. The 2nd option is a "local" connection - which can have less overhead, depending on the underlying OS features - but does not support connectivity between devices.
When using a local connection, a unique name must be used. For tcp connections, a unique address and port number combination much be used.
There is currently no zeroconf facility included in QtRO. All processes or devices must therefore know beforehand how to connect to each other. A QRemoteObjectRegistry (see below) can be used to simplify the connection process for a network with multiple Host Nodes.
Connection types are summarized in the following table.
URL | Host Node | Connecting Node |
---|---|---|
QUrl("local:replica") | QLocalServer("replica") | QLocalSocket("replica") |
QUrl("tcp://192.168.1.1:9999") | QTcpServer("192.168.1.1",9999) | QTcpSocket("192.168.1.1",9999) |
Nodes have a couple of enableRemoting() methods that are used to share objects on the network (this will produce an error if the Node is not a Host Node however). Other processes/devices that want to interact with a shared object use one of the node's acquire() methods to instantiate a replica.
As part of the free Business evaluation, we offer a free welcome call for companies, to talk about your requirements, and how the Felgo SDK & Services can help you. Just sign up and schedule your call.
Sign up now to start your free Business evaluation: