[Client] Add watchdog for connection status

[schroeder-]

This adds a new task to pull the connection status, which will prevent a session timeout as of #977. Is also used in the next step to inform all subscriptions about a connection lose. Also add a hook to check if this task an _renew_channel_loop thrown a exception. See #974.

[ZuZuD]

I'm not sure not allowing the session to timeout is the right default approach here. The traditional way of keeping a session active is to create a subscription, thereafter you transparently rely on the protocol KeepAlive mechanism and the session isn't supposed to time out (see #585 for the related work and references on this).

If I understand this patch correctly, the problem you're trying to solve with it is to achieve the same behaviour but without a subscription. If that's indeed the case, then I don't think this corner case warrants increasing the complexity of our client's library.

[schroeder-]

I know that a subscription is the best way to keep a session alive. But we received some bug reports that didn't use subscriptions and had session timeouts. Because some servers limit the amount of subscriptions, I don't want to create a subscription just for session keep alive. Maybe we can make it optional just for people that don't want to use subscriptions?

[jmtatsch]

The traditional way of keeping a session active is to create a subscription, thereafter you transparently rely on the protocol KeepAlive mechanism and the session isn't supposed to time out (see #585 for the related work and references on this).

I know very little about opcua and its traditions but to subscribe to for example the servers clock is certainly the worst way to keep the session alive. Now I don't know the resolution of the clock but giving the client every nano second an unused timestamp to fetch is certainly keeping everyone and the line busy, certainly more then one request every 30s.

[oroulet]

From what I have seen a few years back, all clients where doing hard polling every seconds to keep session alive. I also kind of remember the spec advicing to do polling on server status node, but I could not find anything now when looking for it... So I do not have anything against having a task doing exactly that. Also the main advantage I see to the proposed approach is the possibility to offers to clients a simple and easily discoverable method like get_connection_status() than returns a connection status immediately, thus allowing all threads of a user application to check connection state instead of having implement some polling themselv.

[oroulet]

could also help with that kind of things btw: https://github.com/FreeOpcUa/python-opcua/issues/521

[ZuZuD]

I know that a subscription is the best way to keep a session alive. But we received some bug reports that didn't use subscriptions and had session timeouts. Because some servers limit the amount of subscriptions, I don't want to create a subscription just for session keep alive. Maybe we can make it optional just for people that don't want to use subscriptions?

That would seem odd to have server implementations where max_subscription < max_session. What I meant was that I believe for most of the use-cases we got, we could recommend the user to create a subscription (even an empty one) to work around this.

Also, there's a KeepAlive task already available with the HaClient which covers most of what's suggested here. If we want to go down this road, that would probably make sense to consolidate these efforts.

[oroulet]

Also, there's a KeepAlive task already available with the HaClient which covers most of what's suggested here. If we want to go down this road, that would probably make sense to consolidate these efforts.

I am rather sure the HD client is overkill for most applications, but some features from there could be backported. That keepalive task for example

[oroulet]

looks good for me. Has anyone any idea to even improve it?