Sander van Harmelen

Please see #197 which is trying to add a full async client. Maybe that also solves this problem, or at least the fix can be added there easier without impacting...

Just FYI I'm actually working on a full async client. The first step for that is #146 but that still needs to be discussed to see if @locka99 is open...

The problem also exists without dropping the client when `session.reconnect_and_activate()` is called. That will drop and recreate the currently used TCP transport which also contains it's own runtime...

@ctron maybe you can checkout this branch: https://github.com/svanharmelen/opcua/tree/feature/async-client it's intended to become a full async-client. I did run and test it a little, but not enough yet to create a...

@locka99 very interested to know how you think about a PR like this. Are you open to adding something like this to the crate? The only downside I see is...

I don't think using `block_on` all over the place will result in a true async client that can be used with applications that are already build upon Tokio and already...

> I think there is a misunderstanding here. I was talking about having the old sync client api being implemented based on the new async one. This way existing code...

> If the former, then the api should probably just resemble the existing one with the functions being async. i.e. you just call it much the way it works now...

Just FYI regarding the length... I encountered at least one server that crashed because we send `-1`. I assume they maybe used a `uint` or something like that which caused...

Does OPC UA have a “real” keep-alive call? I don’t think so right? If not, would just renewing the token be the best approach?