Skip to content
Start free evaluation

Subscriptions and the publish cycle

To learn about every change of a value, use a subscription instead of repeated Reads. The server samples the value and sends only the changes, grouped into notifications. Part 4 defines the MonitoredItem service set in section 5.12 and the Subscription service set in section 5.13.

A subscription delivers notifications for a session. Its main parameters:

Parameter Meaning
publishingInterval How often the server sends collected notifications, in milliseconds
maxKeepAliveCount When nothing changes for this many intervals, the server sends an empty keep-alive message.
lifetimeCount When the client sends no Publish request for this many intervals, the server deletes the subscription. Must be at least three times the keep-alive count.
maxNotificationsPerPublish Maximum number of notifications in one message
publishingEnabled Whether notifications are sent

A monitored item is what a subscription watches: a node and an attribute (the Value attribute for data, the EventNotifier attribute for events).

Parameter Meaning
samplingInterval How often the server checks the value, in milliseconds
queueSize How many notifications to keep until the next publish
discardOldest Whether to drop the oldest notification when the queue is full
filter A DataChangeFilter, EventFilter or similar
clientHandle A number chosen by the client; it comes back with every notification so you can tell items apart.
monitoringMode Disabled, Sampling or Reporting

The server can revise the intervals and sizes you request. The revised values in the response are the ones in effect.

Notifications arrive as responses to Publish requests that the client sends ahead of time. The server holds the Publish requests and answers one each time a publishing interval produces notifications.

Client Server
| CreateSubscription (publishingInterval) --> |
| CreateMonitoredItems (node, sampling) ----> | samples at samplingInterval,
| Publish ----------------------------------> | queues changed values
| Publish ----------------------------------> |
| <---- PublishResponse: seq 1, DataChangeNotification
| Publish (acknowledge seq 1) --------------> |
| <---- PublishResponse: seq 2, notifications
| ... no changes for keepAlive x interval ...
| <---- PublishResponse: keep-alive (no notifications)
  • Each NotificationMessage carries a sequence number. A keep-alive message only announces the next sequence number; it doesn’t use one.
  • The client acknowledges received sequence numbers in its next Publish request. The server keeps unacknowledged messages for retransmission.
  • If a sequence number is missing, the client asks for that message again with Republish.
  • If the client stops sending Publish requests, the subscription expires after lifetimeCount intervals.

Notification data comes in three kinds: DataChangeNotification for value changes, EventNotificationList for events and StatusChangeNotification for changes of the subscription’s state.

SDK. The client builds CreateSubscription (i=787), CreateMonitoredItems (i=751) and Publish (i=826) requests in UA Binary and sends them with pdcomm_opcua_client_begin; the in-memory server handles these services. The examples’ ua_binary.h doesn’t encode them, so use a complete UA Binary encoder. A Publish response can take up to a publishing or keep-alive interval to arrive, so set the connection timeout (timeout_ms) longer than that.

Simulator. The subscribe action creates one subscription per session and adds a monitored item per node, with these settings:

Item Value
Publishing interval interval_ms (50 to 10000 ms, default 250 ms). Three intervals must be shorter than the client timeout.
Keep-alive count, lifetime count 3, 30
Sampling interval Same as the publishing interval
Queue size 10, discarding the oldest
Notification store Up to 1000 (limits.notification_queue); beyond that the oldest are dropped and dropped grows.

The publish action sends a Publish request and waits for its response, which arrives within one keep-alive period at most. Missing sequence numbers are recovered with Republish; numbers that can’t be recovered are reported as "kind":"gap" entries. Try it in the subscriptions tutorial.

Events, alarms and conditions shows how the same subscription delivers events.