C++ Based OPC UA Client/Server/PubSub SDK  1.7.2.493

Overview

The UaSession class represents a connection between the Client application and a single server. A process can create many Session objects connected to different Servers. The Session object is responsible for monitoring the connection with the Server and attempting to reconnect if there are any errors. The application can receive notifications of changes to the connection status through the callback UaSessionCallback::connectionStatusChanged.

A UaSession object is thread-safe.

Connection handling and reconnect

The connect call establishes and maintains a Session with a Server.

After a successful connect, the connection is monitored by the SDK by using the Read service reading the status variable on the Server. The Read cycle time (nWatchdogTime) and the timeout for the Read (nWatchdogTimeout) can be configured through the class SessionConnectInfo used as input parameter to connect. The application can receive notifications of changes to the connection status through the callback UaSessionCallback::connectionStatusChanged. All reconnect handling is done by the SDK. The only case where the application may need additional handling is the case where it was necessary to create a new Session in the Server during the reconnect. This is indicated by the status ServerStatus::NewSessionCreated. In this case all registered nodes need to be re-registered and the namespace table should be read again.

If the initial connect fails, the SDK can be forced to retry connect if the flag SessionConnectInfo::bRetryInitialConnect is set.

Reverse Connect

The OPC UA Reverse Connect functionality is provided through the two UaSession connect settings SessionConnectInfo::bIsReverseConnect and SessionConnectInfo::sClientEndpointUrl. The client endpoint URL specifies the address the server uses to establish the TCP/IP connection from server to client. The port specified in the URL must be open in the firewall.

The reverse connect is only possible through the asynchronous connect with UaSession::beginConnect since the connection establishment may take a while.

The server discovery for the Reverse Connect functionality is done through UaDiscovery::startReverseDiscovery and the callback UaReverseDiscoveryCallback.

Discovery (UaDiscovery::startReverseDiscovery) and connection establishment (UaSession::beginConnect) only works together in the same process since both actions require that the client process opens a port and this is limited to one process.

In one process, UaSession and UaDiscovery share the port for one client endpoint URL. Incoming reverse TCP/IP connections are first used for outstanding connection establishments started with UaSession::beginConnect. If no connect is outstanding, the incoming reverse TCP/IP connections are used for discovery.

Handles and Ids

SessionId

The SessionId is an internal server created handle for communicating between server and client (SDK). Depending on the used protocol, the SessionId can be security relevant and should not be visible outside the client or server application. 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. Since the Session context is managed by the UaSession object, the handle is not needed outside this object.

ClientConnectionId

The clientConnectionId 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 the application logic. The clientConnectionId is never exchanged with the Server.

TransactionId

The transactionId is a client (SDK user) defined handle to identify the results of an asynchronous service invocation in the callback. It is a parameter to all asynchronous beginXXX service calls. The transactionId is just a pass through for the SDK and all requirements for this handle are defined by the application logic. The transactionId is never exchanged with the server. It is just stored with the transaction object in the Client SDK.