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. QuickOPC hides most of the OPC’s stateful nature by providing a connection-less (stateless) interface for OPC tasks.
This transformation from a stateful to a stateless model is actually one of the biggest advantages you gain by incorporating QuickOPC. 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 QuickOPC 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).
QuickOPC automatically establishes 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 makes an OPC "read" from a specific target OPC server, and QuickOPC 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 using QuickOPC, 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, QuickOPC will keep trying reestablish the connection as long as you are subscribed.
QuickOPC keeps 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)
QuickOPC keeps 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.