Negotiate publishing interval

[derula]

Context

When creating a new subscription, the client sends a requested publishing interval to the server. The server then replies with the actual, negotiated publishing interval. Currently, this value is discarded and cannot be accessed when using create_subscription.

There has recently be a change where the requested max keep-alive count is calculated automatically based on the requested publishing interval. This is a welcome change and better than a constant default, However, it leads to some problems, discussed below.

Current problems

1. Calculated max keep-alive count is based on the requested publishing interval rather than the negotiated one.
2. The negotiated values are, as far as I can tell, discarded and not even accessible after create_subscription.
3. If a publishing interval of 0 is requested, calculating the max keep-alive count causes a division-by-zero error.

Discussion

According to OPC UA spec, a requested publishing interval of 0 is a request to negotiate the lowest possible publishing interval. It also includes some SHOULD requirements about what value should be chosen for max keep-alive count based on the session timeout and publishing interval. This means that the max keep-alive count can only really be derived from the negotiated publishing interval rather than the requested one.

Possible solution

Instead of calculating the max keep-alive count right away, the client could do the following:

1. Create the subscription in an inactive state
2. Calculate the max keep-alive count based on the negotiated publishing interval
3. Modify the subscription with the new max keep-alive count

If this is too complex to include in the default logic, at least the negotiated publishing interval should be saved somewhere in the subscription object, so that this behavior can be implemented on the application side.

Alternative fix

At the very least, a fix for the division-by-zero error should be provided. I'm not sure how to do this in a useful way without tackling the above logic, though. As a quick fix, I changed my code to manually create the CreateSubscriptionParameters to restore the behavior from before the max keep-alive count calculation was added. But obviously, that gets rid of the benefits from the new logic.

Conclusion

There are two separate issues here: the inability to properly negotiate the subscription details, and a division-by-zero bug when trying to use a feature documented in the OPC UA spec. Adding a more sophisticated logic for negotiating the subscription terms could arguably probably be useful. Otherwise, the API could at least be changed to allow implementing such negotiation logic. In lieu of both, at the very least the division-by-zero error should be fixed. If the latter is the chosen solution, I can create an issue for it.

[ZuZuD]

The ZeroDivisionError was fixed by #491

This would indeed be nice to base the RequestedMaxKeepAliveCount on the RevisedPublishingInterval rather than the RequestedPublishingInterval, this is what's missing from the library to do so:

• Retrieve the RevisedPublishingInterval from the create_subscription server response.
• Add subscription attribute/method to get the revised value.
• Client method to modify an existing subscription.

The datastructure already exists, @derula this looks doable if you want to give it a try ;)

[derula]

Nice, I might actually at some point, just not sure how soon. Thanks for giving it a look!

[derula]

If I'm not mistaken, this feature has been implemented in the meantime? I just wanted to express my appreciation and apologize that I didn't give it a try. It has been a bit of a low priority issue for me for a while, so I didn't get to it.