Non-guarantees

The way a software library works is usually described in terms of what it *does*. Developers who use such library can depend on this expressed functionality. For example, a library can give a guarantee that a return value of certain method is a non-null array with elements that are all non-null.

There are, however, also things that are *not* guaranteed by the library. We call them non-guarantees. In general, anything that is not explicitly documented should be regarded as not guaranteed, from the perspective of the developer who uses the library. This contributes to the description of the library by stating what it *does not*.

It is useful to have a list of the (most important) non-guarantees as well, so that developers using the library do not make improper assumptions.

Some of the behavior that is not guaranteed may be implementation dependent and subject to change over the time. There are, however, some non-guarantees that are very intentional, inherent to the product design, and are not subject to change.

The list below attempts to identify the relevant non-guarantees for QuickOPC.

Grouping

• It is not guaranteed that target objects addressed in EasyXXClient method calls will end up in a single OPC call to the target OPC server.

• It is not guaranteed that if the same target object is addressed multiple times in an EasyXXClient method call, it will be addressed multiple times in the resulting OPC call(s). Such requests may (or may not) be merged together. Note that this also affects methods that change something in the target (such as Write-s), and addressing the same target object multiple items in one EasyXXClient method call therefore does not have a deterministic outcome in such situations.

Ordering

• It is not guaranteed that target objects addressed in EasyXXClient method calls will appear in the OPC call(s) to the target OPC server in the same order as on input.

• It is not guaranteed that notifications that are received from the target OPC server in one message will be issued in the order they appear in that message.

Timing

• If you call EasyXXClient.Method1 on time₁ and you then call EasyXXClient.Method2 on time₂, before EasyXXClient.Method1 returns, it is not guaranteed that the OPC operations for Method1 will be called before those for Method2.

• It is not guaranteed that the first notifications caused by the EasyXXClient.SubscribeXXXX method call will only come after this method has returned.

• It is not guaranteed that after the EasyXXClient.UnsubscribeXXXXX method returns, no notifications will come for the affected target objects.

Connections

• It is not guaranteed the same intermediary objects used for connection to the target OPC server will be used between two consecutive method calls on the EasyXXClient object. Intermediary objects are e.g. COM OPCServer and OPCGroup objects (in OPC Classic), or TCP connections (in OPC UA with opc.tcp protocol), or OPC UA sessions, subscriptions, monitored items etc. The library may use different intermediary objects for various reasons, including (but not limited to) server-side and network communication problems, but also client-side causes such as the automatic closing of unused connections after a period of inactivity.