This Service is used for two purposes. First, it is used to acknowledge the receipt of NotificationMessages for one or more Subscriptions. Second, it is used to request the Server to return a NotificationMessage or a keep-alive Message. Since Publish requests are not directed to a specific Subscription, they may be used by any Subscription. 126.96.36.199 describes the use of the Publish Service.
Client strategies for issuing Publish requests may vary depending on the networking delays between the Client and the Server. In many cases, the Client may wish to issue a Publish request immediately after creating a Subscription, and thereafter, immediately after receiving a Publish response.
In other cases, especially in high latency networks, the Client may wish to pipeline Publish requests to ensure cyclic reporting from the Server. Pipelining involves sending more than one Publish request for each Subscription before receiving a response. For example, if the network introduces a delay between the Client and the Server of 5 seconds and the publishing interval for a Subscription is one second, then the Client will have to issue Publish requests every second instead of waiting for a response to be received before sending the next request.
A Server should limit the number of active Publish requests to avoid an infinite number since it is expected that the Publish requests are queued in the Server. But a Server shall accept more queued Publish requests than created Subscriptions. It is expected that a Server supports several Publish requests per Subscription. When a Server receives a new Publish request that exceeds its limit it shall de-queue the oldest Publish request and return a response with the result set to Bad_TooManyPublishRequests. If a Client receives this Service result for a Publish request it shall not issue another Publish request before one of its outstanding Publish requests is returned from the Server.
Clients can limit the size of Publish responses with the maxNotificationsPerPublish parameter passed to the CreateSubscription Service. However, this could still result in a message that is too large for the Client or Server to process. In this situation, the Client will find that either the SecureChannel goes into a fault state and needs to be re-established or the Publish response returns an error and calling the Republish Service also returns an error. If either situation occurs then the Client will have to 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 CreateMonitoredItems or the last ModifyMonitoredItems Service is applied to the Monitored Items and is used as the diagnostic information settings when sending Notifications in the Publish response.
Table 95 defines the parameters for the Service.
Table 95 – Publish Service Parameters
|requestHeader||RequestHeader||Common request parameters (see 7.28 for RequestHeader definition).|
|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.|
|subscriptionId||IntegerId||The Server assigned identifier for a Subscription (see 7.14 for IntegerId definition).|
|sequenceNumber||Counter||The sequence number being acknowledged (see 7.5 for Counter definition). The Server may delete the Message with this sequence number from its retransmission queue.|
|responseHeader||ResponseHeader||Common response parameters (see 7.29 for ResponseHeader definition).|
|subscriptionId||IntegerId||The Server-assigned identifier for the Subscription for which Notifications are being returned (see 7.14 for IntegerId definition). The value 0 is used to indicate that there were no Subscriptions defined for which a response could be sent.|
|Counter||A list of sequence number ranges that identify unacknowledged NotificationMessages that are available for retransmission from the Subscription’s retransmission queue. This list is prepared after processing the acknowledgements in the request (see 7.5 for Counter definition).|
|moreNotifications||Boolean||A Boolean parameter with the following values:
TRUE the number of Notifications that were ready to be sent could not be sent in a single response.
FALSE all Notifications that were ready are included in the response.
|notificationMessage||Notification Message||The NotificationMessage that contains the list of Notifications. The NotificationMessage parameter type is specified in 7.21.|
|results ||StatusCode||List of results for the acknowledgements (see 7.34 for StatusCode definition). The size and order of the list matches the size and order of the subscriptionAcknowledgements request parameter.|
|diagnosticInfos ||DiagnosticInfo||List of diagnostic information for the acknowledgements (see 7.8 for DiagnosticInfo definition). The size and order of the list matches the size and order of the subscriptionAcknowledgements request 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 96 – Publish Service Result Codes
|Bad_TooManyPublishRequests||The Server has reached the maximum number of queued Publish requests.|
|Bad_NoSubscription||There is no Subscription available for this session.|
Table 97 – Publish Operation Level Result Codes
|Bad_SubscriptionIdInvalid||See Table 177 for the description of this result code.|
|Bad_SequenceNumberUnknown||The sequence number is unknown to the Server.|