pub struct FetchGaps(Box<FetchGapTracker>);Expand description
The Prior Group ID Gap and Prior Object ID Gap conditions of draft-17 Section 11.7 and draft-17 Section 11.8 that one fetch stream shows.
PriorGaps::from_properties refuses what one Object shows. Across the
stream this refuses “A Group contains more than one Object with different
values for Prior Group ID Gap” for the Objects of one Group, and “An
endpoint receives an Object with a Group ID within a previously communicated
gap” and its Prior Object ID Gap twin, for the Group and the Object before
on the stream. It does not refuse “An endpoint receives an Object with a
Prior Group ID Gap covering an Object it previously received” or its Prior
Object ID Gap twin: draft-17 Section 2.1 says of an Object known to exist,
“From this state, it can transition to not existing, but not vice versa”, so
whether such a gap makes the Track malformed is ambiguous.
draft-17 Section 9.14.3: “Within each group, objects are sent in Object ID
order; subgroup ID is not used for ordering.”
FetchObjectReader::read_object_header applies it to each Object it reads.
End of Range indicators are not Objects; the caller passes Objects only.
Tuple Fields§
§0: Box<FetchGapTracker>Implementations§
Source§impl FetchGaps
impl FetchGaps
Sourcepub fn check(
&mut self,
group_id: u64,
object_id: u64,
property_block: &[u8],
) -> Result<PriorGaps, CodecError>
pub fn check( &mut self, group_id: u64, object_id: u64, property_block: &[u8], ) -> Result<PriorGaps, CodecError>
Check the next Object on the stream, from its resolved Group ID and
Object ID and its property block, refusing a gap condition with
CodecError::MalformedTrack and a block that does not parse as
crate::object_properties::parse_object_properties does. Records the
Object only when it passes.