Discussion on connection retries

[jkissinger]

Are there plans for adding connection retries, or even existing functionality that I may have overlooked?

I have connection retries implemented at a high level, such as when first establishing the connection. However, low level retries (for example, if the session times out or the server disconnects unexpectedly) should probably be part of the client itself. One possibility I've considered is having a user defined error handler passed in when constructing the client and then all errors are first passed through that handler before being returned.

I'm new to Go and OPC UA so looking for any feedback or advice here.

[magiconair]

I'm not aware that this is on anybody's list right now but that could be interesting. Subscriptions could be tricky since they establish state on the server (monitored items).

For example, how would this work if you have an active subscription and the session times out or the connection gets interrupted. Would you expect the client to re-establish that subscription with all monitored items?

I think this is what the PubSub Service is trying to solve (including a robust failover).

[jkissinger]

Yeah, for our use case we're definitely expecting the client to reestablish the connection and request any missed publications to be republished, similar to how it's described here:

If communication breaks, the server can still record new notifications, assuming that it has got enough PublishRequests in advance from the client.

In case you have 5 subscriptions and PublishRequestFactor=10, the client will send 50 PublishRequests to the server. In case of a communication break the server can send 50 PublishResponses back to the client in a normal rate. Considering a PublishingInterval of 1 s, the server can send 10 notifications for each subscription, if their items are really changing. But if the break is longer than 10 s, the server will start losing data. Unless the monitored items have a QueueSize long enough to record more samples.

Once communication is restored, the client will first call Republish to get the missing samples: after that it can send more PublishRequests and the server can continue generating new PublishResponses.

I'm guessing from your response, that if this was added to an enhancement list it would be pretty low priority?

[magiconair]

I think you misread my response then. We should add robustness features to the client and/or the library but I am not aware anybody working on this right now and I think there are some edge cases to consider.

Contributions are more than welcome and we should focus first on adding what people need. So if you need this then I'm all for it.

I'll be dealing with the exact same problem in the coming weeks so this is probably a good time for a proposal.

[jkissinger]

That's great news. I would love to contribute personally, however we have limited resources and I'm told our priorities are elsewhere at the moment.

Regarding a proposal, I don't have any concrete design ideas at the moment. We can revisit it when the need arises. If you get to it before me, feel free to tag me and I'll add my thoughts as they pertain to our requirements.

[Lynckx]

@magiconair I am currently working on the robustness of my code and i am missing some key services regarding connection retries. I was wondering if Part 4 6.7 was planned any time soon.(https://reference.opcfoundation.org/Core/docs/Part4/6.7/)

[magiconair]

@Lynckx There is code in the client to detach and re-attach a secure channel from a connection. You can find an example in the crypto example (not very obvious, though)

https://github.com/gopcua/opcua/blob/master/examples/crypto/crypto.go#L80-L99

What I'm not sure of is what happens to the publish requests and the subscription. We might need some work on that end. @kung-foo has been working on a more advanced subscription mechanism and @alexbrdn has written the original subscription code. Maybe they can comment on what would be necessary to carry the subscription over to a new connection but on the same secure channel.

[magiconair]

Also, if you are working on the code additional contributions are more than welcome. The more specific the request is the likelier that someone picks it up.

[Lynckx]

Thanks for the example, i already looked into the crypto example but totally missed this, I was also already looking into a possible Reconnect Sequence but had to put it on pause. I will be able to continue after 1.5 weeks. Are there any plans for an automatic Reconnect Sequence in case of a unexpected connection loss in the future?

[magiconair]

Yeah, this is well hidden. I don't have any plans for adding this right now since I need to add registered reads first and we're double subscribing to handle network failures. Without PubSub there is no other way to avoid data-loss in case of network failure. For this I'm just reconnecting and if the number of nodes you need to register isn't big that might work for you as well.

If you PLC can handle the load you could just setup two go routines in the same app, setup the subscription but only run the loop in one of them.

[Lynckx]

I tried the example you provided but get the following error when trying to activate the session: The session id is not valid. StatusBadSessionIDInvalid (0x80250000).