Search code examples
javaopc-uamilo

How can an OpcUa client get info about server configuration? Like max-pending-publish-requests etc

My MILO OpcUa client was working fine, until I reached certain amount of subscriptions - 10. Then it started receiving Bad_TooManyPublishRequests. I resolved the issue by setting OpcUaClientConfigBuilder#setMaxPendingPublishRequests = 10; as suggested by this answer, and it is working fine again.

But how should I know beforehand, that the server is only able to handle 10 pending publish requests?

After connecting to sever, I can read some server information. As ServerState, CurrentTime, or ServerProductName as it is shown in ReadExample#readServerStateAndTime. But how can I get servers MaxPendingPublishRequests, MinSamplingInterval settings etc?

Also what is the relation between Subscription and MonitoredItem? I used one MonitoredItem per Subscription, which seems to be bad approach now. If you want to monitor hundreds of Nodes, should they be in one Subscription, or divided in more Subscriptions? Should they be grouped by publishingInterval, or what is the right logic to group them?

Edits are welcome, thank you.

Solution

  • I will split up your question and provide answers to you.

    But how can I get servers MaxPendingPublishRequests, MinSamplingInterval settings etc?

    To read the value of MinSupportedSamplingRate, you can make use of the Attribute Read services of OPC UA. The nodeId of MinSupportedSamplingRate node is ns=0;i=2272. Using the attribute read service, you can read the value attribute to get the minimum supported sampling interval of the server. If you are using a GUI client, you can browse through the server address space to find its value. It is present under Root->Object->Server->ServerCapabilities->MinSupportedSamplingRate

    “Also what is the relation between Subscription and MonitoredItem?”

    Subscriptions are used to report notifications to the client. Subscriptions have a set of MonitoredItems assigned to them by the Client. MonitoredItems generate Notifications that are to be reported to the Client by the Subscription

    “If you want to monitor hundreds of Nodes, should they be in one Subscription, or divided in more Subscriptions?”

    One subscription is enough to monitor hundreds of Nodes (or even more). It depends on your use case.

    Should they be grouped by publishingInterval, or what is the right logic to group them?

    The publishing interval of a Subscription defines the cyclic rate at which the Subscription executes. Each time it executes, it attempts to send a NotificationMessage to the Client. NotificationMessages contain Notifications that have not yet been reported to Client.

    If in case, the subscription is created with a publishing interval of 1ms, then every 1ms the server sends a notification message, which can either be

    1. a data change notification if any value changes has occurred or
    2. an empty notification response if there are no value changes (only if keep alive interval is elapsed)

    It is not necessary that the nodes must be grouped by publishing interval parameter.

    Here are some other open source implementations that you might be interested in trying out:

    If you are looking for more hands-on information, you can also check out these resources: