Hello.

Oh, I see, you were scared by the word "asynchronous", which perhaps needs more qualification from my side.

Do not worry, both scenarios you described are guaranteed to work the way you want them to work. This is because although all subscription-related operations on a EasyXXClient may run asynchronously, subscription-related operations on the same EasyXXClient instance never run in parallel, and although they are executed in a queued manner, the order is preserved - i.e. they execute in a sequence in which they have been called.

I will make a note to check the documentation and if the above is not explained there, then improve it in the next version.

Best regards

Hello.

(Note: The PubSub category used to post this isn’t really appropriate. PubSub is an OPC UA communication model different from Client-Server - which is what your post is about, Client-Server. Due to technical problem I currently cannot move the topic elsewhere, though).

1.

All methods that have something to do with subscriptions (subscribe, unsubscribe, change subscription) work asynchronously. This annotation was missing from some methods/method overloads, thank you for pointing it out; we will fix the documentation in the next version. There are no fully synchronous versions of these.

What the EasyUAClient component really understands and performs are the methods defined on the IEasyUAClient interface. The extension methods in EasyUAClientExtension and EasyUAClientExtension2 just manipulate the input arguments (and sometimes the results) to either make it look that there are multiple overloads of the methods available on the interface, or provide functionality tailored at data access or alarms&conditions - but again, simply by having code to properly construct the arguments for the "true" methods IEasyUAClient interface. All in all, this allows the developer to write shorter code by choosing the proper method (or extension method)&overload, but it does not change the execution model - the extension methods behave the same, in this respect.

The code in the examples that waits after unsubscribe is not strictly necessary. Is it there just to 1) show the developer how it works, and 2) if there are events or callbacks hooked, it prevents notifications (that may still be coming) from spoiling the output when the user is already doing something else at that point. We could, for example, unhook the event, to prevent the unwanted notifications from arriving.

There is currently no way for your code to know that the items have been fully unsubscribed. I would like to know the use case, i.e. why do you think you need that.

The code that does the communication is *not* in the EasyUAClient. There is a shared "engine" object that actually performs the operations for all EasyUAClient-s in the background. It is therefore possible to dispose of the EasyUAClient safely. Doing so triggers UnsusbcribeAllMonitoredItems (asynchrously, again), which can then be performed even after the EasyUAClient object is disposed. Sothis is not a problem. The real problem can happen when the whole process wants to shut down while there are operations pending - that is a complicated issue, which we also try to handle but it still has some rough edges.

2.

Yes. Being subscribed from your code denotes a permanent intent to become and stay subscribed. So, it does not even have to succeed the first time (the method won't return any error - but there will be error notification). There are automatic reconnects in place to fulfill that goal. The number of retries is not limited. You will receive at least one error notification when things go wrong. Usually there are more of these as the reconnections keep failing. You will start receiving calid data when it reconnects.

Useful links:

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...tml#Connection%20handling.html

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...onParameters~RetrialDelay.html

Best regards