A publisher sends PUBLISH_STATE_NOTIFY on a subscription's bidirectional stream to notify the subscriber that the state of the subscription has changed for a reason other than a subscriber sent REQUEST_UPDATE. Unlike REQUEST_UPDATE (Section 10.9), it is a unilateral notification: the receiver does not respond with REQUEST_OK or REQUEST_ERROR, and the message is not subject to the MAX_REQUEST_UPDATES limit (Section 10.3.1.7).
PUBLISH_STATE_NOTIFY applies only to subscriptions, and is sent only by
the publisher. An endpoint that receives a PUBLISH_STATE_NOTIFY for any
other request type, or from the subscriber, MUST close the session with a
PROTOCOL_VIOLATION.
A PUBLISH_STATE_NOTIFY carries the parameters whose values have changed. If a parameter is not present, its value is unchanged. The semantics of each parameter, including whether it may appear in PUBLISH_STATE_NOTIFY, are defined by the parameter.
A publisher MUST NOT use PUBLISH_STATE_NOTIFY to change the value of a subscriber controlled subscription parameter unless the subscriber requested the change.
The publisher MUST include the LARGEST_OBJECT parameter (Section 10.2.17), if known, in PUBLISH_STATE_NOTIFY so the subscriber can determine the point in the Track at which the change took effect.
This message is informative and no action is required by the recipient.
The format of PUBLISH_STATE_NOTIFY is as follows:
PUBLISH_STATE_NOTIFY Message {
Type (vi64) = 0x22,
Length (16),
Number of Parameters (vi64),
Parameters (..) ...
}
-
Parameters: The parameters are defined in Section 10.2.