The sender of a request (SUBSCRIBE, PUBLISH, FETCH, PUBLISH_NAMESPACE, SUBSCRIBE_NAMESPACE) can later send a REQUEST_UPDATE on the same bidi stream as the request to modify it. A subscriber can also send REQUEST_UPDATE to modify parameters of a subscription established with PUBLISH.
The receiver of a REQUEST_UPDATE MUST respond with exactly one REQUEST_OK or REQUEST_ERROR message indicating if the update was successful.
If a parameter previously set on the request is not present in
REQUEST_UPDATE, its value remains unchanged.
There is no mechanism to remove a parameter from a request.
The format of REQUEST_UPDATE is as follows:
REQUEST_UPDATE Message {
Type (vi64) = 0x2,
Length (16),
Request ID (vi64),
Required Request ID Delta (vi64),
Number of Parameters (vi64),
Parameters (..) ...
}
-
Request ID: See Section 9.1.
-
Required Request ID Delta: See Section 9.2.
-
Parameters: The parameters are defined in Section 9.3.
9.10.1. Updating Subscriptions
When a subscriber decreases the Start Location of the Subscription Filter (see Section 5.1.2), the Start Location can be smaller than the Track's Largest Location, similar to a new Subscription. FETCH can be used to retrieve any necessary Objects smaller than the current Largest Location.
When a subscriber increases the End Location, the Largest Object at the publisher might already be larger than the previous End Location. This will create a gap in the subscription. The REQUEST_OK in response to the REQUEST_UPDATE will include the LARGEST_OBJECT parameter, and the subscriber can issue a FETCH to retrieve the omitted Objects, if any.
When a subscriber narrows their subscription (increase the Start Location and/or decrease the End Group), it might still receive Objects outside the new range if the publisher sent them before the update was processed.
When a subscription
update is unsuccessful, the publisher MUST also terminate the subscription with
PUBLISH_DONE with error code UPDATE_FAILED.