locka99
Simple-server failed to parse config
When running the simple-server sample code, I get the following error:
2022-01-09 18:08:18.062 - ERROR - opcua_core::config - Cannot deserialize configuration from ../server.conf
By inspecting the source code, I noticed the following line
https://github.com/locka99/opcua/blob/0.8.1/core/src/config.rs#L42
This line reads the config from a YAML file and not from a config file as the one provided in the samples.
rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active rustc version is `rustc 1.57.0 (f1edd0429 2021-11-29)
Library version: 0.8.1
@lsabi I drafted an integration test, which launches the simple-server example and verifies it succeeds parsing its config and binding a port. Is your problem still present in master? Or is this Issue just old?
Thanks for the tests.
Now, when I run it (on Ubuntu 24.04), I get the error below
opcua/samples/simple-server$ cargo run
2024-07-06 11:30:09.096 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
2024-07-06 11:30:10.103 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
2024-07-06 11:30:11.106 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
2024-07-06 11:30:12.110 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
2024-07-06 11:30:13.117 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
2024-07-06 11:30:14.121 ERROR opcua::client::transport::tcp Could not connect to host 127.0.0.1:4840, Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }
Indeed, that's been confusing me at first as well. The connection that can't be established is not that of a client to the configured server at port 4855, but that to the configured discovery server at 4840 to which the server itself intends to connect. Leaving that configpart out did not appear to be a valid option.
Anyway, what you are seeing is a working client, which is warning in a pretty expressive manner. Maybe we could tone that done a little.
Anyway, just firing up a server and a client in separate terminals might confirm that.
@AiyionPrime sorry for the late reply, the notification got lost.
Anyways, I confirm that with a separate client, it returns
Created a subscription with id = 1
Data change from server:
Item "ns=2;s=v1", Value = Int32(3)
Data change from server:
Item "ns=2;s=v2", Value = Boolean(false)
Data change from server:
Item "ns=2;s=v3", Value = String(UAString { value: Some("Hello World times 1") })
Data change from server:
Item "ns=2;s=v4", Value = Double(0.40002913723726474)
which is indeed correct.
Nevertheless, the error above is still returned from the server, which is confusing and misleading. Furthermore I believe it should be a stand-alone program, that does not require external inputs nor concurrent programs to run.
A warning could be added to the documentation for the simple-server, warning about the strange output.
But discovery servers are a part of the normal OPC UA ecosystem. I agree the error message should be better. But I personally don't see any harm in trying to reach an LDS to register. But those are only my two cents.
I'm not doubting whether it's part or not of the OPC UA ecosystem.
Yes, the error is very misleading and a note regarding the discovery server should be properly indicated in the README.md for the example.
Since it's a simple server that should be used as a showcase, it should be minimal and not require other services that are not necessary for it to work. But that's my thought, though.