We have looked deeper into this. Sadly, we are not going to implement this change. The reasons are below.

#1. The underlying software we are using (.NET stack&SDK from OPC Foundation) does not offer a way to hook into the places where the necessary message processing is done. Similarly to what you see in QuickOPC API, it is only capable of giving us information when the keep-alive mechanism fails - but not when it succeeds. In theory we (or somebody) could change the SDK and make a pull request, but that's not the business we are in.

#2: there are also some design issues with it. I They have to do with how the keep-alive mechanism works and how that could be "projected" into QuickOPC API. In short, the way it would behave would be - in some cases - quite unexpected (and ineffective). I could go into details, but given #1, it is irrelevant at this time.

The second point is not a total show stopper, but the first is.
I'd also like to note that the fact that it is not just "us", who has designed the library in such way , reinforces my feeling that doing this is somehow not right.

Best regards

Thank you for explanation.

We introduce new features or API changes only in new versions, not in updated builds of the same version (that is reserved for bug fixes). We should be releasing a new version (2019.1) in the 2nd half of September, and it is too late to put this in. We already know very well (and have parts finished) what will go into the subsequent version, which may be out towards end of 2019 or in the beginning of 2020. So, after 2019.1 is released, we can review the plan for the subsequent version and consider this one change to be added (= this decision is to be made probably in early October).

I cannot foresee whether we will include it or not. It needs to be prioritized with other things, and also assessed in terms of feasibility, and "design fit". Specifically, there is an design concept in QuickOPC which says that the physical aspects of the communication should stay hidden from the normal user (the commonly used interfaces). Violating this concept might be dangerous because it opens the door for further similar changes. But I am not saying either way yet.

Best regards

Hello,
do not worry, these are all valid and very good questions.

1. Is there a max value for subscription inactivity?
No.

2. Is it possible for 1 of the subscriptions to disconnect or "go bad" while the other subscriptions remain active and functioning as normal?
It is not that common, but it can happen. QuickOPC hides the existence of subscriptions in the API. Instead, each monitored item is treated individually, and if there is a problem related to a subscription, all monitored items that exist on that subscription receive an error.

3. Is there a way to determine when the last keep-alive was received from the server for a given subscription?
No in QuickOPC. But there is a negative indication – if the keep-alives are not as they should, you will receive an error notification. See below.

4. Once a subscription has been created, is there any status available on the subscription that can be obtained? Like when the last time a message was received or when the last week-alive was received?
In QuickOPC, the status of the subscription is delivered to you by the change notification. The current status equals the last status received (i.e. whether the Exception property in the event arguments was null or not). A status change to a success is indicated by a new data coming in with Exception == null. A status change to a failure is indicated by a notification with Exception != null. So even though you cannot “obtain” the status, you always *know* the status.

You probably feel uncomfortable relying on the state is delivered to you like this. You may think “ there can be bug in the component, and we would not know about the failure”. That’s right. But the reasoning should go as follows: Either you do trust the component for giving you the right status, or you don’t.

If you trust the component, just use the above described approach and you are all set.

If you do not trust the component, and want to obtain some “certainty” about whether the subscription truly works, you need to find some other way. But having a way to obtain the status by a method call to the component itself, or reading the keep-alive time from the component, wouldn’t give you a certainty either. There can be a bug causing these indications to misbehave as well. So if you do not trust the component for status delivery, you need to subscribe to some item that is guaranteed to change values on the server. Alternatively, at least in some scenarios, you can change the filter (on one or more monitored items) so that data is not delivered not just when the value or status change, but also when its timestamp changes. If the server is periodically getting new data, you will be receiving it every time, even if the value itself has not changed. Obviously this results in (much) more data being transferred.

The bottom line is, no matter whether you “trust” the component or not, there is no need for other methods to obtain the status or keep-alive time: The current design should be sufficient.

Best regards