Skip to main content

check_discriminators

Function check_discriminators 

Source
fn check_discriminators(message: &ControlMessage) -> Result<(), CodecError>
Expand description

Refuse a message whose discriminator disagrees with the fields beside it.

A discriminator is a field that says which of the fields after it are on the wire. Where this codec holds the alternatives as an enum or an Option beside the discriminator, a value can say one thing in the discriminator and another in the body, and the two sides of the codec resolve that disagreement differently: the encoder writes whatever the body holds, and the decoder reads whatever the discriminator announces. The result is a message that does not survive its own round trip, and the encoder is the side that can still refuse it.

Draft-15 has exactly one such message, which is why this is shorter than the same check on draft-14. Section 9.16 gives FETCH a Fetch Type — “There are three types of Fetch messages… An endpoint that receives a Fetch Type other than 0x1, 0x2 or 0x3 MUST close the session with a PROTOCOL_VIOLATION” — and Section 9.16.3 puts the Standalone and Joining bodies in the message as alternatives that the type selects between.

The messages that carried the other discriminators on draft-14 no longer do. SUBSCRIBE’s Filter Type became the SUBSCRIPTION_FILTER parameter of Section 9.2.1.7, and SUBSCRIBE_OK’s Content Exists became the LARGEST_OBJECT parameter of Section 9.2.1.9; a parameter is present or it is absent, so neither leaves a discriminator to disagree with. Copying draft-14’s arms over unchanged would not compile, and adding fields to make them compile would invent a rule this draft does not have.

A mis-stated FETCH is the concrete case. A Standalone type beside a Joining body writes a request id and a start where the peer reads a Track Namespace and a Track Name, and the fetch that arrives names a track after two integers — or, more often, fails to parse, which at least is honest.