About the client-side of the Cpp SDK, I'm a bit confused by all the ids and handles that can be used. Could you please confirm if the following assumptions are correct (sorry for the many items, but a simple true or false would already be very helpful):
Sessions:
- A SessionId (as assigned by the server) is not made available by the SDK API to the user, so as a user I shouldn't store it / worry about it since I'll never need it.
- A clientConnectionId (as assigned by the user) should be unique per UaSessionCallback instance. So if each session I create has it's own UaSessionCallback instance, I can leave the clientConnectionId 0.
- Suppose I use one UaSessionCallback instance for all my sessions, and I create a session to server A, then close it, and then create a new session to server B. I suppose it's safe to reuse the same clientConnectionId for both sessions?
- A TransactionId (as assigned by the user) on the UaSession level has the same constraints as a clientConnectionId, i.e. unique per UaSessionCallback instance.
- A SubscriptionId (as assigned by the server) is made available by the SDK API to the user (via UaSubscription:: subscriptionId()), because a user must be able to use it to transfer subscriptions from one session to another.
- A clientSubscriptionHandle (as assigned by the user) should be unique per UaSubscriptionCallback instance. So if I create one UaSubscriptionCallback instance per session, I can start to increment the clientSubscriptionHandle from 0, for each session.
(Theoretically that would mean each session could contain up to 2**32 subscriptions). - A TransactionId (as assigned by the user) on the UaSubscription level has the same constraints as a clientSubscriptionHandle, i.e. unique per UaSubscriptionCallback instance.
- A MonitoredItemId (as assigned by the server) is made available by the SDK API to the user (via the UaMonitoredItemCreateResults output argument), because a user must use it to modify/delete/... specific monitored items.
- A ClientHandle (as assigned by the user) should be unique per UaSubscriptionCallback instance. So if create one UaSubscriptionCallback instance per session, I can start to increment the ClientHandle from 0, for each session.
In order to create a nearly unlimited (in theory at least) generic client, does it make sense to:
- create one UaSessionCallback instance for all my sessions (theoretically allowing 2**32 sessions)
- create one UaSubscriptionCallback instance per session (theoretically allowing 2**32 monitored items per session, 2**32 simultaneous asynchronous transactions per session, and 2**32 subscriptions per session).
Or are there other constrains (such as the internally used RequestHandle?) that theoretically limit a client to, for instance, 2**32 monitored items for the whole client? So that it's better to only use one UaSubscriptionCallback instance for the whole client?
Thank you very much,
Wim