OPC (Client-Server model) is inherently stateful. For starters, connections to OPC servers are long-living entities with rich internal state, and other objects in OPC model such as OPC groups have internal state too. OPC Studio products hide most of the OPC’s stateful nature by providing a connection-less (stateless) interface for OPC tasks.
From an application perspective (such as with Excel Conenctor), or client developer perspective (when using OPC Data Client), this transformation from a stateful to a stateless model is actually one of the biggest advantages you gain by using products based on OPC Studio. There are several advantages to a stateless model from the perspective of your application. Here are the most important of them:
The internal state of OPC Data Client components (including e.g. the connections to OPC servers) outlives the lifetime of the individual instances of the main EasyDAClient, EasyAEClient or EasyUAClient object. You can therefore create an instance of this object as many times as you wish, without incurring performance penalty to OPC communications. This characteristic comes extremely handy in programming server-side Web applications and similar scenarios: You can implement your code on page level, and make OPC requests from the page code itself. The OPC connections will outlive the page round-trips (if this was not the case, the OPC server would become bogged down quickly).
Products based on OPC Studio automatically establish a connection to the target OPC server whenever it is needed. The connection is maintained at least for a duration of the operation requested. For example, if your code or application makes an OPC "read" from a specific target OPC server, and an underlying OPC Studio component is not yet connected to it, it will connect first. After the read operation is finished, the connection is kept open for certain time, called the "hold period". This allows subsequent operations to reuse the connection that is already open. If the connection is no longer necessary, it is automatically closed.
Any OPC subscription keeps the connection to the target OPC server open at least for the duration of the subscription. In addition, if you use subscribe in any of OPC Studio products, you declare a "standing" request to subscribe and stay subscribed, until you explicitly unsubscribe. If the connection breaks for any reason, or if it is not possible to connect at the time of the initial subscribe, OPC Studio components will keep trying reestablish the connection as long as you are subscribed.
Inside a process (more precisely, a .NET AppDomain, but in most cases that is equivalent to a process), OPC Studio components keep just one connection to each target OPC server, regardless of whether multiple requests for operations on that server came from just one client object, or multiple client objects. This way, your code does have to bother with efficiency concerns related to the fact that multiple connections from the same OPC client to the same OPC server are normally unnecessary and create a performance problem.
In some (relatively rare) cases you may want to disable the connection sharing. This can be achieved using Isolated Clients and Subscribers.
(This paragraph applies only to OPC UA)
OPC Studio components keep data related to a session in memory for some time after the session has been closed ("dormant session"). This allows faster reconnection later. The period for which the session data is kept in memory after the session is closed is configurable by the UASmartSessionParameters.DormancyPeriod property. The maximum count of sessions that can be kept in the dormant state is configurable in the UASmartEngineParameters.MaximumDormantSessions property.