I do not think there are any intervals "hidden". But the whole OPC UA communication is a complex issue - that's why you are using as toolkit and not programming it yourself - and there are many more aspects that have to with the reliability of the communication. For example, subscription-level keep-alive mechanism etc.

Ad 1. No. The keep-alive interval is set for all non-isolated EasyUAClient objects at once, using AdaptableParameters, and for each isolated EasyUAClient in its IsolatedParameters, but if you are using more servers on the same EasyUAClient, they all share the same keep interval.

Ad 2. You cannot currently obtain the effective keep-alive interval. As I wrote before, however, the server isn't actually "revising" it - that was my mistake, I confused it with other parameters. Normally, the effective keep-alive interval is the same number as you specify. There are some edge cases (which also depend on the server) in which it isn't. For example, in the current implementation, it cannot be shorter than 10 ms, and it cannot be longer than certain percentage of the session timeout as revised by the server. But this is implementation dependent, subject to change, and do not expect us to ever reveal all the related details.

Ad 3. See above - there is no "revised" keep-alive interval, so to speak. I think that in your case, as in 99% of cases anyway, the actual value used will be the one you specify. The client then tries to issue some request to the server at least every keep-alive interval, and uses the value twice as longer to detect when the server is not responding.

Ad 4. The recommendation is: Use Isolated == true only when you have to. Examples of such situations are:
a) For whatever reason, you need two or more sessions to the same server.
b) You need to set some parameters differently for certain servers.
c) You are writing a reusable software library, so you do not want to "share" the parameters and connections to servers etc. with other parts of the larger environment your library will live in and which may also use EasyXXClient objects for something else.

Best regards

Well, there is also KeepAliveIntervalDebug, if it's running under the debugger.

Besides that, changing the right one (or changing them both), should be enough. I have set them to 500 (ms), and I am notified of the disconnect in what I estimate to be not much more than 1 second, certainly less than 2 seconds. Tested with the ConnectivityExplorer application, and a connection to our public demo server.

Regards

First of all, I apologize for somewhat misleading you: The server does not revise the KeepAliveInterval. I have confused it with the keep-alive mechanism on the subscription level (which may also be of interest, but is a different thing altogether).

Second, by inspecting the code, I have found that the actual detection of keep-alive error you a value that is twice as much as KeepAliveInterval. So, with the default being 5000 ms, it comes to 10 seconds. This particular behavior is not in our code, it is in the OPC Foundation stack/SDK that we are using.

I am not sure which particular log entry you refer to as "timeout", but it can be something that does not directly cause a connection to be marked as being in failure.

Best regards

And warning #4 to the shorter keep-alive intervals, for completeness:
- They increase the load on the server, the network, and the client.

Regards

Regarding the "disconnection detection" part:

This is what KeepAliveInterval (opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ameters~KeepAliveInterval.html ) or KeepAliveIntervalDebug is for.

Default is 5000 (5 seconds), you can make it shorter to detect problems quicker.

But there are some warnings:
1. By doing so, you increase the possibility of "falsely positive" detections.
2. The value you specify is not final. It gets negotiated with the server, and the server has the final word (this must be so, for conformance with OPC UA specs). It may happen that the server will not go under certain limit.
3. There is no determinism ("hard real time") in OPC UA Client-Server specs, and neither it is in the Ethernet network nor in Windows. This can work in both ways: It may cause false positives (see #1), but also false negatives (the disconnection will be detected later than wished, because simply the Windows threads of your app won't get chance to run soon enough).

Best regards

Hello.

For the reconnection part (I understand this is the less important piece):

See the RetrialDelay property, opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...onParameters~RetrialDelay.html . Default is 10000 (10 seconds), you may make it shorter.

In order for this to work, you need to also consider that the reconnection does not happen immediately after this period elapses.Instead, the global component's "engine" checks all sessions in a periodic task, and initiates a reconnection of those that are due for reconnection. See opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...meters~ReconnectionPeriod.html . This can only be set once, before you start any OPC operations. Default is 5000 (5 seconds), so the total time to the (initiation of the) reconnection, in the default state, can be approximately 10-15 seconds.

I will reply to the part about disconnection detection timing in a separate post later. I need to verify something before I answer.

Best regards