opcua
opcua copied to clipboard
locka99
Issues re interoperability with common OPCUA clients
I have used multiple OPCUA clients to aid in the development of a server application utilizing this library.
I have been able to connect all of the clients I have tested to the OPCUA server
These include: Unified Automation UaExpert: Link Matrikon OPC UA Explorer: Link Prosys OPC UA Browser: Link
Each client seems to require tweaking on the OPCUA server side in order to connect successfully
e.g. a configured server.conf file
I think I recall UAExpert not requiring as much/any tweaking, but I'm not certain.
As far as I can tell, this comes down to the limits advertised/supported by the OPCUA server being incompatible with the aforementioned OPCUA clients. At least for the most part
Some clients seemingly have issues connecting due to the configuration of the Discovery endpoint on the server side, etc.
While I have been able to determine what configurations work and produce relevant sample server.conf configurations for the aforementioned client applications, it feels a bit restrictive to have an OPCUA server instance that only works with a limited set of clients.
It would be nice if the server could be made more flexible with the limitations so that it can support connections from a range of client application.
Perhaps this is not entirely uncommon in the context of the OPCUA ecosystem, but I figured I'd open an issue it is something that can be resolved, as it seems like a pretty big pain point to me.
Are you connecting with encrypted connections or not? Best to try None/None first to see if the issues are around certs before anything else. Clients and servers might be set up to reject certs, e.g. trust_client_certs set to false in the server will reject a client cert it doesn't recognize to its pki/rejected folder as a precaution. If you know your server is safe for anonymous clients, you can set that to true.
For other limits/settings if there are particular things that cause issue, can you list them here?
Yes, I have been using None/None only so far, really
I took another stab at diagnosing and here are my findings
UAExpert
Potentially related default settings:
Stack.Serializer_MaxAlloc: 16777216
Stack.Serializer_MaxArrayLength: 65536
Stack.Serializer_MaxByteStringLength: 16646145
Stack.Serializer_MaxMessageSize: 16777216
Stack.Serializer_MaxStringLength: 16646145
Stack.TcpConnection_DefaultChunkSize: 65536
Stack.TcpListener_ClientThreadsEnabled: false
Stack.TcpListener_DefaultChunkSize: 65536
Stack.TcpTransport_MaxChunkCount: 5000
Stack.TcpTransport_MaxMessageLength: 16777216
Without any changes to default limits: UAExpert connects successfully Prosys fails to connect
The size of the message chunk 86680 exceeds the size of the destination buffer 66559
After changing send/receive buffer to 131,072 per this comment: Prosys connects successfully UAExpert fails to connect
After updating UAExpert settings:
Stack.Serializer_MaxArrayLengthStack.TcpConnection_DefaultChunkSizeStack.TcpListener_DefaultChunkSize
65,536 -> 131,072
Prosys and UAExpert connect successfully
Update
After poking UAExpert a bit more, I have found that this setting is all that needed to be changed
Stack.TcpConnection_DefaultChunkSize: 65,536 -> 131,072
Conclusion
It seems like the default settings are okay for a number of client applications But—assuming default server settings from the library—there are also client applications that need to be reconfigured in order to connect successfully.
It seems like, in this case, the easiest solution is to simply increase the related limits on UAExpert
I realize that, to an extent, this is somewhat unavoidable That being said, I do worry about that approach for a few reasons
The error messages in applications such as UAExpert are... at times, not very helpful For example, the messages related to the above issues:
16:35:54.404 | General | | [uastack] OpcUa_TcpConnection_SocketCallback: Handler returned error 0x80AC0000!
16:35:54.404 | General | | [uastack] OpcUa_SecureConnection_OnNotify: Connect event: ERROR 0x80AC0000!
16:35:54.404 | General | | [uastack] OpcUa_SecureConnection_OnNotify: Connect event: Notifying owner! 0x80AC0000
16:35:54.418 | Server Node | localhost@localhost | Could not connect to server: BadConnectionRejected
Additionally, I worry that customers might try to use clients that don't provide advanced configuration
For example, Prosys works now that I increased some of the limits, but it does not allow configuration to the same level as UAExpert So there might be issues there if changes are needed on the client side
If such changes end up being required, but the customer requires the usage of an application such as Prosys, we might be limited to responding with something like: "Sorry, too bad"
I have no idea if more "adaptive" limits are practical, but that's the first thing that comes to mind for me Or maybe I am misunderstanding the implementation, and they already do function that way
But, in short, I wonder if it might make sense to provide an option like:
max_receive_buffer_size
Whereas we currently have e.g. receive_buffer_size
Anyway, I think I'm going to take aforementioned "client might require configuration" for the time being and see how that goes
Are you connecting with encrypted connections or not? Best to try None/None first to see if the issues are around certs before anything else. Clients and servers might be set up to reject certs, e.g. trust_client_certs set to false in the server will reject a client cert it doesn't recognize to its pki/rejected folder as a precaution. If you know your server is safe for anonymous clients, you can set that to true.
For other limits/settings if there are particular things that cause issue, can you list them here?
hi, recently i used this project to construct a opcua server, with the test, i found some problem and i resolved them, i want to participate this project,look forward to your reply
