Reconnection and data recovery

A reconnect that succeeds is not the same as a recovery that loses nothing. What survives a broken connection is decided by three server-side clocks, and by how long the outage lasted against them.

What the client does on its own

What stays with your application:

• Reconnecting at all when auto-retry is off — a call on a broken client throws ConnectionException — and the backoff between attempts.
• Acknowledging notifications: the acknowledgements you pass to publish().
• transferSubscriptions() when you ended up with a new session.
• republish() of the availableSequenceNumbers.
• Recreating subscriptions and monitored items.
• Checking the Overflow bit and reading the missing interval from history.
• Storing the session state and the subscription ids across a restart (suspend(), getSessionState()).

The three clocks

Every one of them is negotiated: the server revises what you request. Read the revised values back — they are returned by createSubscription() and createMonitoredItems() — and size your recovery budget on those.

Scenario 1 — short outage: the session survives

Within the session timeout, reconnect() opens a new secure channel and reactivates the same session with ActivateSession (on by default, see ClientBuilder::setReactivateSession()). Subscriptions, monitored items, sequence numbers and the server's retransmission queue are untouched: there is nothing to transfer and nothing to rebuild.

try {
    $publish = $client->publish($acknowledgements);
} catch (ConnectionException) {
    $client->reconnect();   // same session, same subscriptions

    // The first publish after the reconnect lists what the server still holds.
    $publish = $client->publish();
    foreach ($publish->availableSequenceNumbers as $sequenceNumber) {
        $message = $client->republish($subscriptionId, $sequenceNumber);
        handleNotifications($message['notifications']);
    }
}

The reconnect dispatches ClientReconnecting, and SessionReactivated when the session came back. Calling transferSubscriptions() here is pointless: the subscription is already yours and the server answers BadNothingToDo.

Scenario 2 — the session is gone, the subscription is not

Past the session timeout — or when the server refuses the activation, or when a new process starts without the saved session — the client creates a new session. The old subscriptions are orphaned but still alive until their lifetime expires, and transferSubscriptions() takes them back.

$results = $client->transferSubscriptions([$subscriptionId], sendInitialValues: false);

if (($results[0]->statusCode & 0x80000000) === 0) {
    // The subscription is ours again, with its queue and its sequence numbers.
    foreach ($results[0]->availableSequenceNumbers as $sequenceNumber) {
        $message = $client->republish($subscriptionId, $sequenceNumber);
        handleNotifications($message['notifications']);
    }
} else {
    // Nothing to take back: see scenario 3.
}

Two preconditions are easy to miss:

• You need the subscription ids. Store them where they survive a process restart, together with the sequence numbers you acknowledged.
• The new session needs the right to take them. Against UA-.NETStandard an anonymous session is refused with BadUserAccessDenied; an authenticated one works.

A notification the server has already dropped from its retransmission queue fails republish() with BadMessageNotAvailable. That interval is a real gap: recover it as in scenario 3.

Scenario 3 — nothing survived

Past the subscription lifetime, after a server restart, or when the transfer is refused, there is no server-side state left. Create the subscription and the monitored items again, and treat the interval as missing data:

$subscription = $client->createSubscription(publishingInterval: 1000.0);
$results      = $client->createMonitoredItems($subscription->subscriptionId, $items);

// The gap runs from the last value you stored to now.
$values = $client->historyReadRaw($nodeId, $lastStoredTimestamp, new DateTimeImmutable());

1. 01

   Measure the gap.

   Its start is the source timestamp of the last value you stored, not the moment the connection broke.

2. 02

   Fill it from the server history

   with historyReadRaw(), for the nodes the server historizes. The reads follow continuation points, so a long interval comes back complete.

3. 03

   What the server did not historize stays missing.

   The client returns what the server holds and nothing more: for a node without history, the interval between the last stored value and the new subscription cannot be read back.

Restarting the process

A restart is scenario 1 or 2 depending on how long it takes. To land in scenario 1, save the session before stopping and resume it on start:

// Before stopping: close the channel, keep the session alive on the server.
$state = $client->suspend();
file_put_contents($path, json_encode($state), LOCK_EX);

// On start: reactivate it, within the session timeout.
$client = ClientBuilder::create()
    ->resumeSession(SessionState::fromArray(json_decode(file_get_contents($path), true)))
    ->connect('opc.tcp://plc.local:4840');

The limit that survives everything: the queue

Even when session and subscription both survive, the server only kept revisedQueueSize values per monitored item. Beyond that the oldest are discarded and the next DataValue carries the Overflow info bit:

foreach ($publish->notifications as $notification) {
    if ($notification instanceof DataChangeNotification && $notification->dataValue->isOverflow()) {
        // The server dropped values for this item: backfill that node from history.
    }
}

Without that check a recovery looks perfect and is not: the values are gone, and nothing else reports it.

What to read next

• Recipes · Recovering from disconnection — the same three scenarios wired into a worker loop, with backoff.
• Operations · Subscriptions — publish, acknowledgements and republish in detail.
• Operations · History reads — reading back the interval you missed.