Hi,

Only the most recent client.setUserIdentity matters, setting a new one would replace the old one. If connected, a new ActivateSession would be done as per spec (with the new identity).

Preferably I would want like proof in the form of OPC UA Specification link (https://reference.opcfoundation.org/) that it is that truly possible in the first place (more than one Session per SecureChannel). Like with opc.https there is a “secure channel” that is shared with all Sessions, so the concept technically “exist” (though no-one should use opc.https unless no alternatives). In the opc.tcp world I believe I have never seen that there would be more than a single Session per SecureChannel.

In short, no way to do that with the SDK. In a bit longer way, technically it might be doable in the pure stack layer, but that is pretty useless for 99% of the stuff so the answer is pretty much a no. It is quite fundamental design of the SDK that UaClient opens the connection, makes securechannel (in opc.https this is just the tls connection) and then the session. So in short I’m not sure even when and how we would support this (assuming that it is allowed in the first place).

Regradless, that limitation is … odd and potentially dangerous. Best would be to recommend them to remove it (e.g. link to this post etc.). Or the very least I would be looking for a _very good reason_ to have to have a limitation like this. Also the limitation might be a bit different, but assuming it “as is” as you said, that would make a connection loss an unrecoverable scenario, which would be quite bad. Also, the securechannel must be renewed periodically (but this is done within the same connection).

A reconnect would try to do a new connection and a new securechannel, then try to activate the old Session via ActivateSession. IF the old connection+channel would not be removed by the server side, it could potentially prevent reconnecting within the timeout period of the channel (if only one channel per cert).

Also, that limitation would make it impossible to have a redundant client (as they most likely would share the certificate, at least in some scenarios).

P.S.
Also, the reverse connect functionality of OPC UA had some wording that clients might use more than a single session, so that might prevent even some normal clients to work, though I have not seen clients like this. In short, I’m not sure is it within OPC UA’s scope to limit how many SecureChannels a given application can open to a server.