After a Clientestablishes a connection to a Serverand creates a Subscription, the Clientmonitors the connection status. Figure 36shows the steps to connect a Clientto a Serverand the general logic for reconnect handling. Not all possible error scenarios are covered.
The preferred mechanism for a Clientto monitor the connection status is through the keep-alive of the Subscription. A Clientshould subscribe for the State Variablein the ServerStatusto detect shutdown or other failure states. If no Subscriptionis created or the Serverdoes not support Subscriptions, the connection can be monitored by periodically reading the State Variable.
When a Clientloses the connection to the Server, the goal is to reconnect without losing information. To do this the Clientshall re-establish the connection by creating a new SecureChanneland activating the Sessionwith the Service ActivateSession. This assigns the new SecureChannelto the existing Sessionand allows the Clientto reuse the Sessionand Subscriptionsin the Server. To re-establish the SecureChanneland activate the Session, the Clientshall use the same security policy, application instance certificate and the same user credential used to create the original SecureChannel. This will result in the Clientreceiving data and event Notificationswithout losing information provided the queues in the MonitoredItems do not overflow.
The Clientshall only create a new Sessionif ActivateSessionfails. TransferSubscriptionsis used to transfer the Subscriptionto the new Session. If TransferSubscriptionsfails, the Clientneeds to create a new Subscription.
After re-establishing the connection the Clientshall call Republishin a loop, starting with the next expected sequence number and incrementing the sequence number until the Serverreturns the status Bad_MessageNotAvailable. After receiving this status, the Clientshall start sending Publishrequests with the normal Publishhandling. This sequence ensures that the lost NotificationMessagesqueued in the Serverare not overwritten by new Publishresponses.
If the Clientdetects missing sequence numbers in the Publishand is not able to get the lostNotificationMessagesthrough Republish, the Clientshould use the Method ResendDataor should read the values of all data MonitoredItemsto make sure the Clienthas the latest values for all MonitoredItems.
The Server Objectprovides a Method ResendDatathat initiates resending of all data monitored items in a Subscription. This Methodis defined in OPC 10000-5. If this Methodis called, subsequent Publishresponses shall contain the current values of all data MonitoredItemsin the Subscriptionwhere the MonitoringModeis set to Reporting. If a value is queued for a data MonitoredItem, the next value in the queue is sent in the Publishresponse. If no value is queued for a data MonitoredItem, the last value sent is repeated in the Publishresponse. The Servershall verify that the Methodis called within the Sessioncontext of the Sessionthat owns the Subscription.
Re-establishing the connection by creating a new SecureChannelmay be rejected, because of a new Server Application Instance Certificateor other security errors. OpenSecureChannelreturns Bad_CertificateInvalid in the case of a new Server Application Instance Certificate. In case of security failures, the Clientshall use the GetEndpoints Serviceto fetch the most up to date security information from the Server.
If the Client Application Instance Certificateis updated, the Clientmust create a new Sessionsince the Sessiondoes not allow a update of the Client Application Instance Certificate. The Clientshall try to transfer existing Subscriptionsto the new Session. Transfer subscription must be accepted by a Servereven for Anonymoususer if the Clientdoes not change i.e. the ApplicationUriof the Clientdoes not change and a secure connection is used.
OPC 10000-6defines a reverse connect mechanism where the Serverinitiates the logical connection. All subsequent steps like creating a SecureChannelare initiated by the Client. In this scenario the Clientis only able to initiate a reconnect if the Serverinitiates a new logical connection after a connection interruption. The Clientside reconnect handling described in Figure 36applies also to the reverse connect case. A Serveris not able to actively check the connection status; therefore the Servershall initiate a new connection in a configurable interval, even if a connection to the Clientis established. This ensures that an initiated connection is available for the reconnect handling in addition to other scenarios where the Clientneeds more than one connection.