Handling of StatusBadSessionNotActivated

[bitomaxsp]

While dealing with non quite stable PLCs I noticed that sometimes in response to any request PLC can answer with StatusBadSessionNotActivated. After quite a lot of debugging, reading the standard and the code, I figured, that library doesn't have a bug with sessions activation. But @magiconair brought my attention to the fact the Client has public API to control different aspects of session creation: CreateSessionWithContext and ActivateSessionWithContext. Yes, this makes library extremely robust, but on the other hand, it probably make sense then to add StatusBadSessionNotActivated handling to that switch (https://github.com/gopcua/opcua/blob/main/client.go#L297) and do restoreSession action.

The other option, probably more cleaner, will be to make session API private, since then Client will correctly handle session as is it now.

This issue is to discuss preferred approach going forward.

[bitomaxsp]

@kung-foo

[magiconair]

Is there any use-case where clients would need to create/activate sessions manually? This is all handled in the client and the client also has the monitor loop without nothing really works. We will break the API with v0.5 anyway so we could do this then.

[magiconair]

There is the crypto example which uses ActivateSession and DeactivateSession to move a session between client connections. It feels a bit contrived but maybe there is the use-case that you connect on one address, establish the session, and then move that session to another connection.

https://github.com/gopcua/opcua/blob/v0.3.15/examples/crypto/crypto.go#L82-L97