Ids, handles, ...

[wim]

Dear Unified Automation,

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.

Subscriptions:

• 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.

Monitored items:

• 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

[Support Team]

Dear Wim,

Here are our answers to your question(s). In general your summary is right. There is nothing wrong with it.

Sessions:

Depending on the used protocol, the SessionId can be security relevant and should not be visible outside the applications. Therefore the SessionId is not exposed on the API to make sure it is not exposed on the client side in a GUI by mistake. It is just an internal server created handle for communicating between server and client (SDK). Since the Session context is managed by the UaSession object, the handle is not needed outside this object.

Yes on clientConnectionId. It is a client (SDK user) defined handle to identify the session in the callback if the same callback object is used for more than one session. The clientConnectionId is just a pass through for the SDK and all requirements for this handle are defined by your application logic. The clientConnectionId is never exchanged with the server.

Yes on TransactionId. SDK does not care, it is just provided with the callback that is called when a trasaction is completed. The TransactionId is not exchanged with the server. It is just stored with the transaction object in the client SDK.


Subscriptions:

Yes on SubscriptionId. The difference to the SessionId is that it is needed to transfer the subscription to another session at that it is not security relevant.

Yes on clientSubscriptionHandle. Like clientConnectionId it is a client (SDK user) defined handle. The same description applies.

Yes on TransactionId. Identical to Session, just bound to the subscription callback interface.



Monitored items:

Yes on MonitoredItemId. Server defined handle.

Yes on ClientHandle. Like clientConnectionId and clientSubscriptionHandle it is a client (SDK user) defined handle. If you assign unique monitored item ClientHandles across subscriptions, you do not need to check the clientSubscriptionHandle in data change or event callbacks. In this case the clientSubscriptionHandle handle is only relevant for subscription status change callbacks.


The strategy for callback handling depends on your application requirements:

(1) Central handling
If you want to have one central callback handler, you can handle all callbacks through one callback object, even all session and subscription callbacks. In this case you must assign unique clientConnectionId and clientSubscriptionHandles

(2) Decentral handling
If you have session and subscription related management objects in your application layer code, it may make sense to implement the callbacks directly there to avoid dispatching that would be necessary in the central handler

Best Regards,
Unified Automation Support Team

[wim]

Great, thank you so much for your extensive and speedy answer!
It's a very interesting summary, thanks a lot.

Best regards,

Wim