Server: PublishResponse sent back on the wrong connection #359
Comments
|
I'm currently working on a rewrite of the server as well, like I did with the client, though there is a fair bit left until it's comparable to the current server implementation. It has a completely different approach to dealing with connections and subscriptions, and will definitely fix this. |
Open
This was referenced Aug 15, 2024
Closed
Merged
einarmo
added a commit
to einarmo/opcua
that referenced
this issue
Aug 15, 2024
# What and Why This is a rewrite of the server from scratch, with the primary goal of taking the server implementation from a limited, mostly embedded server, to a fully fledged, general purpose server SDK. The old way of using the server does still _more or less_ exist, see samples for the closest current approximation, but the server framework has changed drastically internally, and the new design opens the door for making far more complex and powerful OPC-UA servers. ## Goals Currently my PC uses about ~1% CPU in release mode running the demo server, which updates 1000 variables once a second. This isn't bad, but I want this SDK to be able to handle servers with _millions_ of nodes. In practice this means several things: - It must be possible to store nodes externally, in some database or other system. - Monitored items must be notification based. There is always going to be sampling somewhere, but in practice large OPC-UA servers are _always_ push based, the polling is usually deferred to underlying systems, which may or may not be OPC-UA based at all. - It must be possible to store different sets of nodes in different ways. If anyone wanting to write a more complex server needs to reimplement diagnostics and the core namespace, the SDK isn't particularly useful. We could hard code that, but it seems better to create an abstraction. ## High level changes First of all, there are some fundamental structural changes to better handle multiple clients and ensure compliance with the OPC-UA standard. Each TCP connection now runs in a tokio `task`, and most requests will actually spawn a `task` themselves. This is reasonably similar to how frameworks like `axum` handle web requests. Subscriptions and sessions are now stored centrally, which allows us to implement `TransferSubscriptions` and properly handle subscriptions outliving their session as they are supposed to in OPC-UA. I think technically you can run multiple sessions on a single connection now, though I have no way to test this at the moment. The web server is gone. It could have remained, but I think it deserves a rethink. It would be better (IMO), and deal with issues such as locka99#291, if we integrate with the `metrics` library, and optionally export some other metrics using some other generic interface. In general I think OPC-UA is plenty complicated enough without extending it with tangentially related features, though again this might be related to the shift I'm trying to create here from a specialized embedded server SDK, to a generic OPC-UA SDK. Events are greatly changed, and quite unfinished. I believe a solid event implementation requires not just more thought, but a proper derive macro to make implementing them tolerable. The old approach relied on storing events as nodes, which works, and has some advantages, but it's not particularly efficient, and required setting a number of actually superfluous values, i.e. setting the displayname of an event, which is a value that cannot be accessed, as I understand it. The new approach is just storing them as structs, `dyn Event`. ## Node managers The largest change is in how most services work. The server now contains a list of `NodeManager`s, an idea stolen from the .NET reference SDK, though I've gone further than they do there. Each node manager implements services for a collection of nodes, typically the nodes from one or more namespaces. When a request arrives we give each node manager the request items that belongs to it, so when we call `Read`, for example, a node manager will get the `ReadValueId`s where the `NodeManager` method `owns_node` returns `true`. There are some exceptions, notably the `view` services can often involve requests that cross node-manager boundaries. Even with this, the idea is that this complexity is hidden from the user. Implementing a node manager from scratch is challenging, see `node_manager/memory/diagnostics.rs` for an example of a node manager with very limited scope (but one where the visible nodes are dynamic!). To make it easier for users to develop their own servers, we provide them with a few partially implemented node managers that can be extended: - The `InMemoryNodeManager` deals with all non-value attributes, as well as `Browse`, and provides some convenient methods for setting values in the address space. Node managers based on this use the old `AddressSpace`. Each such node manager contains something implementing `InMemoryNodeManagerImpl`, which is a much more reasonable task to implement. See `tests/utils/node_manager.rs` for a very complete example, or `node_manager/memory/core.rs` for a more realistic example (this node manager implements the core namespace, which may also be interesting). - The `SimpleNodeManager` is an approximation of the old way to use the SDK. Nodes are added externally, and you can provide getters, setters, and method callbacks. These are no longer part of the address space. More node managers can absolutely be added if we find good abstractions, but these are solid enough to let us implement what we need for the time being. # Lost features Some features are lost, some forever, others until we get around to reimplementing them. I could have held off on this PR until they were all ready, but it's already large enough. - Diagnostics are almost entirely gone, though there is a sort of framework for them. In practice the whole thing needs a rethink, and it's an isolated enough task that it made sense to leave out for now. - Setting sampling interval to `-1` no longer works. I wanted to make everything work, but in typical OPC-UA fashion some features are just incredibly hard to properly implement in a performant way. I'm open for suggestions for implementing this in a good way, but it's such a niche feature that I felt it was fine to leave it out for now. - The web server, as mentioned above. - Auditing. Same reason as diagnostics, but also because events are so cumbersome at the moment. # General improvements Integration tests are moved into the library as cargo integration tests, and they are quite nice. I can run `cargo test` in about ~30 seconds, most of which is spent on some expensive crypto methods. There is a test harness that allows you to spin up a server using port `0`, meaning that you get dynamically assigned a port, which means we can run tests in parallel arbitrarily. This almost certainly fixes locka99#359, locka99#358, locka99#324, locka99#291, and locka99#281, and probably more. # Future work See `todo.md`, the loose ends mentioned in this PR description need to be tied up, and there is a whole lot of other stuff in that file that would be nice to do.
|
@einarmo , is there a branch where this is is fixed ? I tried your branches async-server and rewrite-master but the problem is still there. |
|
Are you sure? That really doesn't make sense, the server architecture in |
|
@einarmo I confirmat that it WORKS with the asycn-server branch. (apologies, I mess the branches) When can we expect to have a master branch with a working server ? I don't like to be dependent of a branch in a fork. |
|
There's only one maintainer for this repo, and he is often busy. There is a PR, #366, but I don't know what the status really is there. I'm going to keep working on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In spawn_subscriptions_task of TcpTransport, all sessions of the server are iterated, it should only process sessions attached to this secure channel (TcpTransport).
This is a major problem, because it ends up with PublishResponse send back to the wrong channel (which has not requested a publish request) and the channel which has sent a PubglishRequest receives nothing.
The text was updated successfully, but these errors were encountered: