Enum AnyControlMessage

Source

pub enum AnyControlMessage {
Show 15 variants
    Draft07(ControlMessage),
    Draft08(ControlMessage),
    Draft09(ControlMessage),
    Draft10(ControlMessage),
    Draft11(ControlMessage),
    Draft12(ControlMessage),
    Draft13(ControlMessage),
    Draft14(ControlMessage),
    Draft15(ControlMessage),
    Draft16(ControlMessage),
    Draft17(ControlMessage),
    Draft18(ControlMessage),
    Draft19(ControlMessage),
    Draft20(ControlMessage),
    Draft21(ControlMessage),
}

Expand description

A control message from any enabled draft.

Variants§

§

Implementations§

Source §

impl AnyControlMessage

Source

pub fn decode( version: DraftVersion, buf: &mut impl Buf, ) -> Result<Self, CodecError>

Decode from wire using the specified draft version.

Source

pub fn encode(&self, buf: &mut impl BufMut) -> Result<(), CodecError>

Encode to wire using the appropriate draft’s format.

Source

pub fn draft(&self) -> DraftVersion

Returns the draft version this value belongs to.

Source §

impl AnyControlMessage

Source

pub fn is_setup(&self) -> bool

Returns true if this is a CLIENT_SETUP or SERVER_SETUP message.

Drafts 07 through 16 carry the two as separate messages and drafts 17 and later fold them into one SETUP, so the question has two spellings and one answer.

There is no answer for a draft this build left out, because there is no question: a draft with no feature has no variant on AnyControlMessage, so no value naming it can reach the match.

Source

pub fn fields(&self) -> FieldMap

This message’s fields, named as its own draft names them.

The keys are the draft’s field names in snake_case and the order is the order the draft defines, so two drafts that spell one concept differently each keep their own spelling and nothing has to agree on a vocabulary none of them uses. A reader that has never heard of a message can still show it.

Optional fields the message did not carry are absent from the map. A field that was not sent and a field carrying zero are different, and only omission can say which happened.

No answer for a draft this build left out, for the reason Self::is_setup gives: such a draft has no variant here, so nothing can arrive asking. Of the three accessors that shape protects, this is the one where the alternative would hurt most — an empty FieldMap renders as a message that carried no fields, which is exactly how a message with none renders, so a draft the match had not met would reach a reader as data rather than as an error.

Source

fn message_type(&self) -> (u64, &'static str)

This message’s wire type ID and the name its own draft gives it.

One match rather than two accessors’ worth, because the two halves come from the same MessageType and a build where they could disagree is one nobody should be able to write.

Source

pub fn message_type_id(&self) -> u64

This message’s control message type ID, as its own draft assigns it.

The ids are reused rather than retired across the drafts — 0x07 is ANNOUNCE_OK through draft-13, PUBLISH_NAMESPACE_OK on draft-14 and REQUEST_OK from draft-15 on — so this number means nothing without draft beside it. message_type_name is the one that has already combined them.

Source

pub fn message_type_name(&self) -> &'static str

The name this message’s own draft gives its type, in the corpus’s snake_case spelling — subscribe, publish_namespace, request_error.

The same string message_type_name answers for this message’s draft and id, and the same one that draft’s codec/messages/*.json vectors carry, so a message named here reads the same way as one named from a trace.

Never None: the free function has to allow for an id no draft assigns and for a draft this build left out, and a decoded message can be neither.

Source

pub fn fetch_group_order(&self) -> Option<(u64, AnyFetchGroupOrder)>

The Request ID and Group Order of a FETCH, on the drafts where the FETCH settles the order by itself.

A fetch response’s Objects arrive in the order the request asked for. Draft-19 Section 10.12.3: “The publisher responding to a FETCH is responsible for delivering all available Objects in the requested range in the requested order (see Section 10.2.8).” Draft-19 Section 10.2.8 carries the order itself, as the GROUP_ORDER parameter, and states what its absence means: “If omitted from FETCH, the receiver uses Ascending (0x1).” So on those drafts one message answers the question outright, whether or not it carries the parameter, and that is what this returns.

The answer matters most on drafts 18 and 19, whose fetch Objects write a Group ID as a difference from the Object before and leave the order to decide its sign — see AnyFetchObjectReader::new. Drafts 15, 16 and 17 state the same rule about the same parameter and their fetch streams resolve without it, so this answers for them too rather than for the two that happen to need it.

§What answers `None`

Any message that is not a FETCH, and every FETCH on drafts 07-14. Those drafts carry Group Order as a field of the FETCH rather than as a parameter, and its value 0x0 means the subscriber expressed no preference — which leaves the order to the publisher, who states it in the FETCH_OK. That is a two-message negotiation, and a function handed one message cannot answer it. Answering Ascending there would be a guess wearing the same return type as a fact.

Also None for a GROUP_ORDER value that is neither Ascending (0x1) nor Descending (0x2), which drafts 15-21 make a session-closing PROTOCOL_VIOLATION and this crate’s decoder refuses before building a message. Defensive, and deliberately not the Ascending default: an out-of-range value is not an omitted one.

Not None — not anything — for a draft this build left out, for the reason Self::is_setup gives: such a draft has no variant here, so nothing can arrive asking.