pub struct SubgroupObject {
pub object_id: VarInt,
pub extension_headers: Vec<u8>,
pub payload_length: VarInt,
pub object_status: Option<ObjectStatus>,
pub payload: Vec<u8>,
}Expand description
One object within a draft-21 subgroup stream. Object IDs are
delta-encoded; whether a per-object “properties” block (the draft-21
equivalent of extension headers) is present depends on the PROPERTIES
bit on the enclosing SubgroupHeader. Use SubgroupObjectReader
to encode/decode.
Fields§
§object_id: VarInt§extension_headers: Vec<u8>Raw properties bytes, excluding the byte-length prefix that precedes
them on the wire. Empty unless the subgroup header sets the
PROPERTIES bit, or when the block is present but zero-length.
Opaque: SubgroupObjectReader::write_object re-emits the prefix
and these bytes verbatim.
payload_length: VarInt§object_status: Option<ObjectStatus>The object’s status, carried on the wire only when payload_length is
zero. None with a zero payload_length is written as
ObjectStatus::Normal.
None is not “no status”: every Object has one. It means the status is
the one the encoding elides — ObjectStatus::Normal, the only row of
the Object Status registry (draft-21 Section 16.9) that permits the
payload such an object carries. Decoding a payload-bearing object leaves
this None for that reason; Self::status resolves it either way.
Typed rather than a raw code. The wire field is a varint with room for
any value, and draft-21 assigns three of them; the decoder refuses the
rest, and this type is that same refusal on the encode side — 0x1 and
0x2 cannot be named here, so SubgroupObjectReader::write_object
cannot emit a status this module’s own decoder would reject.
A status and a payload can be held here together, which the wire has no
way to express. That combination is what draft-21’s registry rules on:
SubgroupObjectReader::write_object accepts it when the status is
registered as permitting a payload and refuses it otherwise.
payload: Vec<u8>Implementations§
Source§impl SubgroupObject
impl SubgroupObject
Sourcepub fn status(&self) -> ObjectStatus
pub fn status(&self) -> ObjectStatus
The object’s status, with the one draft-21’s encoding elides filled in.
A subgroup object states its status only when its Object Payload Length
is zero. An object that carries bytes therefore has no status field, and
its status is ObjectStatus::Normal — the sole row of the Object
Status registry (draft-21 Section 16.9) permitting a payload, so the
only status such an object could have had.
Sourcepub fn permits_payload(&self) -> bool
pub fn permits_payload(&self) -> bool
Whether the Object Status registry permits this object a non-empty payload, per draft-21 Section 16.9.
Answered from the status alone. payload and payload_length are not
consulted: on a status that permits a payload they say only whether this
particular object took the offer, and on one that forbids a payload a
non-empty payload is the malformation this reports, not evidence about
the rule.
Sourcepub fn properties_permitted(&self) -> bool
pub fn properties_permitted(&self) -> bool
Whether this object’s status is allowed to carry the properties it has.
Draft-21 Section 11.1.3: “Any Object with status Normal can have properties (Section 8.4). If an endpoint receives properties on an Object with status that is not Normal, it MUST close the session with a PROTOCOL_VIOLATION.”
So this is false for exactly one shape: a non-empty properties block
on an object whose status is not ObjectStatus::Normal. An object
with no properties is fine at any status, and an object at Normal may
carry any properties.
Neither SubgroupObjectReader::read_object nor
SubgroupObjectReader::write_object applies this itself, which is a
deliberate contrast with the payload rule beside it. A status next to a
payload has no encoding — the two share a position on the wire — so the
writer refuses it as unrepresentable. Properties next to a status encode
fine; the frame is well formed and merely non-conforming, and a codec
that could not read or write it could not reproduce a capture containing
one. The rule addresses an endpoint receiving such an Object, so the
endpoint is where it is enforced, and this is what it asks.