This Serviceis used for two purposes. First, it is used to acknowledge the receipt of NotificationMessagesfor one or more Subscriptions. Second, it is used to request the Serverto return a NotificationMessageor a keep-alive Message. Since Publishrequests are not directed to a specific Subscription, they may be used by any Subscription. the use of the Publish Service.

Clientstrategies for issuing Publishrequests may vary depending on the networking delays between the Clientand the Server. In many cases, the Clientmay wish to issue a Publishrequest immediately after creating a Subscription, and thereafter, immediately after receiving a Publishresponse.

In other cases, especially in high latency networks, the Clientmay wish to pipeline Publishrequests to ensure cyclic reporting from the Server. Pipelining involves sending more than one Publishrequest for each Subscriptionbefore receiving a response. For example, if the network introduces a delay between the Clientand the Serverof 5 seconds and the publishing interval for a Subscriptionis one second, then the Clientshall issue Publishrequests every second instead of waiting for a response to be received before sending the next request.

A Servershould limit the number of active Publishrequests to avoid an infinite number since it is expected that the Publishrequests are queued in the Server. But a Servershall accept more queued Publishrequests than created Subscriptions. It is expected that a Serversupports several Publishrequests per Subscription. When a Serverreceives a new Publishrequest that exceeds its limit it shall de-queue the oldest Publishrequest and return a response with the result set to Bad_TooManyPublishRequests. If a Clientreceives this Serviceresult for a Publishrequest it shall not issue another Publishrequest before one of its outstanding Publishrequests is returned from the Server.

Clientscan limit the size of Publishresponses with the maxNotificationsPerPublishparameter passed to the CreateSubscription Service. However, this could still result in a message that is too large for the Clientor Serverto process. In this situation, the Clientwill find that either the SecureChannelgoes into a fault state and needs to be re-established or the Publishresponse returns an error and calling the Republish Servicealso returns an error. If either situation occurs then the Clientwill shall adjust its message processing limits or the parameters for the Subscription and/or MonitoredItems.

The return diagnostic info setting in the request header of the CreateMonitoredItemsor the last ModifyMonitoredItems Serviceis applied to the Monitored Itemsand is used as the diagnostic information settings when sending Notifications in the Publishresponse.

Table 95defines the parameters for the Service.

Table 95– Publish Service Parameters







Common request parameters (see 7.33for RequestHeaderdefinition).


Acknowledgements []

Subscription Acknowledgement

The list of acknowledgements for one or more Subscriptions. This list may contain multiple acknowledgements for the same Subscription(multiple entries with the same subscriptionId). This structure is defined in-line with the following indented items.



The Serverassigned identifier for a Subscription(see 7.19for IntegerIddefinition).



The sequence number being acknowledged (see 7.8for Counterdefinition). The Servermay delete the Messagewith this sequence number from its retransmission queue.




Common response parameters (see 7.34for ResponseHeaderdefinition).



The Server-assigned identifier for the Subscriptionfor which Notificationsare being returned (see 7.19for IntegerIddefinition). The value 0 is used to indicate that there were no Subscriptionsdefined for which a response could be sent.


Numbers []


A list of sequence number ranges that identify unacknowledged NotificationMessagesthat are available for retransmission from the Subscription’s retransmission queue including the sequence number of this response if it is not a keep-alive Message. This list is prepared after processing the acknowledgements in the request (see 7.8for Counterdefinition).

The list shall be empty if the Serverdoes not support the retransmission queue. If the list is empty, the Clientshould not acknowledge sequence numbers.

This information is for diagnostic purpose and Clientsshould log differences to the expected sequence numbers.



A Booleanparameter with the following values:

TRUEthe number of Notificationsthat were ready to be sent could not be sent in a single response.

FALSEall Notificationsthat were ready are included in the response.


Notification Message

The NotificationMessagethat contains the list of Notifications. The NotificationMessageparameter type is specified in 7.26.

results []


List of results for the acknowledgements (see 7.39for StatusCodedefinition). The size and order of the list matches the size and order of the subscriptionAcknowledgementsrequest parameter.

diagnosticInfos []


List of diagnostic information for the acknowledgements (see 7.12for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionAcknowledgementsrequest parameter. This list is empty if diagnostics information was not requested in the request header or if no diagnostic information was encountered in processing of the request.

Table 96defines the Serviceresults specific to this Service. Common StatusCodesare defined in Table 182.

Table 96– Publish Service Result Codes

Symbolic Id



The Serverhas reached the maximum number of queued Publishrequests.


There is no Subscriptionavailable for this session.

Table 97defines values for the resultsparameter that are specific to this Service. Common StatusCodesare defined in Table 183.

Table 97– Publish Operation Level Result Codes

Symbolic Id



See Table 182for the description of this result code.


The sequence number is unknown to the Server.


The Server does not support retransmission queue and acknowledgement of sequence numbers is not available.