What is Publish request in OPC UA?

Glossary · Subscriptions

Publish request

Publish is the long-poll service that carries notifications from server to client. The client keeps several Publish requests outstanding on the session, and the server answers one whenever any subscription has data or a keep-alive is due. With no outstanding Publish there is no delivery, however well the subscriptions are configured.

The pipeline and its depth

Publish requests are not per subscription: they are a shared pool on the session, and the server picks which subscription to answer using subscription Priority. Keep roughly one outstanding request per subscription plus a small margin. Too few and delivery stalls behind slow cycles; too many and the server pushes back with BadTooManyPublishRequests, which is the server explicitly asking you to reduce the pool.

Sequence numbers, acknowledgements and Republish

Each NotificationMessage carries a sequence number. The client acknowledges received numbers in its next Publish request, and the server retains unacknowledged messages so they can be recovered with Republish. That is how a client closes a gap after a reconnect: compare the AvailableSequenceNumbers in the Publish response against what it has processed, and Republish the difference before resuming.

Back-off behaviour differs between servers

The .NET reference stack reduces its outstanding Publish count gradually when a server returns BadTooManyPublishRequests, but that gradual behaviour is not tolerated by every server - some treat repeated offences harshly. A hard client-side cap on outstanding requests is often the safer configuration, particularly against embedded and PLC servers with small limits.

Example

What a Publish response carries

PublishResponse
  SubscriptionId            4
  AvailableSequenceNumbers  [ 118, 119, 120 ]     <- retained for Republish
  MoreNotifications         false
  NotificationMessage
    SequenceNumber  120
    PublishTime     2026-09-07T08:14:02.031Z
    NotificationData [ DataChangeNotification { MonitoredItems: [ ... ] } ]

Empty NotificationData with a sequence number = the subscription keep-alive.
Next PublishRequest carries SubscriptionAcknowledgements for 118, 119, 120.

The mistake people make: A client that stops issuing Publish requests - a blocked callback thread, a single-threaded event loop stuck in user code, a paused debugger - looks exactly like a dead client to the server. After LifetimeCount publishing cycles the server deletes the subscription, and the next call returns BadSubscriptionIdInvalid on a connection that never dropped.

Defined in: Part 4 - Services, Publish and Republish; subscription Priority governs which subscription is served first.

Related concepts

Subscription KeepAliveCount Lifetime count Publishing interval Keep-alive TransferSubscriptions Session

Status codes you will meet

BadTooManyPublishRequests BadNoSubscription BadSubscriptionIdInvalid BadTimeout

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.