pub struct Fetch {
pub request_id: VarInt,
pub track_namespace: TrackNamespace,
pub track_name: Vec<u8>,
pub parameters: Vec<KeyValuePair>,
}Expand description
FETCH (0x16), rebuilt in draft-20 (Section 9.11, Figure 16).
FETCH Message {
Type (vi64) = 0x16,
Length (16),
Request ID (vi64),
Track Namespace (..),
Track Name Length (vi64),
Track Name (..),
Number of Parameters (vi64),
Parameters (..) ...
}§What went, and why draft-19’s shape cannot be ported
Draft-19’s FETCH opened with a Fetch Type that chose between a Standalone
Fetch — a namespace, a name and an inline Start Location / End Location
pair — and a Joining Fetch of two varints. Draft-20 deleted the field, both
structures, the Fetch Type registry and the whole joining mechanism, and
promoted the namespace and the name to fields of FETCH itself, in the
positions they hold inside draft-19’s Standalone Fetch. What is left is
byte-identical to Subscribe apart from the type code.
The range travels in the LOCATION_FILTER parameter (Section 9.20.9): “If
omitted from FETCH or SUBSCRIBE, the fetch or subscription is unfiltered.”
Draft-22 places no restriction on which Location Filter Type a FETCH may
carry, so every type decodes here, Relative Start (0x01) and Next Object
(0x05) included.
§INVALID_RANGE and a start past Largest Object
Section 3.2: “If no Objects have been published for the track or Start
Location is greater than the Largest Object (Section 3.1.4) the publisher
MUST return FETCH_ERROR with error code INVALID_RANGE.” A Relative Start of
StartGroup = 0 resolves to the Next Group, and a Next Object filter to the
object after Largest Object; both are by construction greater than Largest
Object, so read literally the rule rejects every such FETCH, and the text
carves out nothing. Nothing here can apply either reading: the test needs
Largest Object, which is track state rather than anything in this frame, so
the decision belongs to the endpoint. It is recorded here because this is
where the filter arrives.
The codepoint did not change. A draft-19 decoder fed one of these reads
the Number of Track Namespace Fields count as a Fetch Type and
mis-parses without complaint; there is no in-band version signal to catch
it. That is why draft-22 has a FETCH decoder of its own rather than sharing
draft-19’s.
Fields§
§request_id: VarInt§track_namespace: TrackNamespace§track_name: Vec<u8>§parameters: Vec<KeyValuePair>