Handle async reads from remote devices

[jomag]

I could use some guidance on how to handle reads from remote devices in a non-blocking manner. I'm quite inexperienced with OPC-UA in general, so it's possible I'm approaching this completely wrong. Here's what I'm trying to do:

I have a number of devices connected to the OPC-UA service I'm building. Typically, the devices are connected via MODBUS/TCP or MODBUS/RTU. The goal is to provide a unified way for OPC-UA clients to read registers from these devices without having to know or care about the underlying protocols.

What I'm unsure about is how to perform these reads without blocking the service:

I would like to fetch values directly from the device at the time the OPC-UA request is made by the client. In my experimental version, I use add_read_callback to return some random value. However, add_read_callback does not seem to support async callbacks which would be necessary in order to not block while doing the fetch. One idea would be to maintain a cache and refresh it by sending a read-request to the remote device in a background process whenever an OPC-UA client issues a read. However, this would mean that the first request cannot return a value, and subsequent requests would return values that may already be outdated.

Another alternative would be to keep a list of "hot" registers and continuously refresh them in the background. However, this approach is more complex and still has the same issues: the first request (which tags the register as "hot") will not have any value, and subsequent requests may be outdated. It can also result in a lot of unnecessary fetches when no clients are actually reading the data.

I haven't started looking into subscriptions or monitoring yet.

Could you provide some hints how this is typically implemented? This seems like a very common use case, so I'm a bit surprised that I haven't found a straightforward way to handle it.

[einarmo]

Hi, you've run into one of the many limitations of the SimpleNodeManager specifically. The simple node manager is a basic, specialized implementation that is supposed to be used for really simple servers. What you want is probably the InMemoryNodeManager, which lets you implement more of the interface yourself.

See advanced_server.md and the node-managers sample. If you look at metadata.rs in the node-managers sample, you'll see that it implements read_values, which is an async method.

In really general terms, what you want to do is have an implementation of the NodeManager trait. InMemoryNodeManager and SimpleNodeManager are just handy specializations that let you do a little less work, but with some assumptions. For the SimpleNodeManager these assumptions include that everything is sync, or updates are local and always known. For InMemoryNodeManager, it is that the address space can be stored in memory. If you implement the NodeManager trait directly, you can even avoid these, generating the address space dynamically.

[jomag]

Ok, thanks! I'll try that!