Skip to main content

bidi_streams_carry_requests

Function bidi_streams_carry_requests 

Source
const fn bidi_streams_carry_requests(draft: DraftVersion) -> bool
Expand description

Whether this draft puts requests on bidirectional streams of their own, so that a bidirectional stream beyond the control stream is a stream this proxy has to forward.

True on drafts 16 through 20; false on 07 through 15.

§Why this is not control_plane_is_unidirectional

Because draft-16 answers the two questions differently, and it is the only draft that does. Its control plane is one client-initiated bidirectional stream, exactly as on 07 through 15. Draft-16 Section 3.3: “The first stream opened is a client-initiated bidirectional control stream where the endpoints exchange Setup messages (Section 9.3), followed by other messages defined in Section 9.” The same section then adds a second use: “This specification only specifies two uses of bidirectional streams, the control stream, which begins with CLIENT_SETUP, and SUBSCRIBE_NAMESPACE. Bidirectional streams MUST NOT begin with any other message type unless negotiated.”

Draft-16 Section 6.1 says who opens one: “The subscriber sends SUBSCRIBE_NAMESPACE on a new bidirectional stream and the publisher MUST send a single REQUEST_OK or REQUEST_ERROR as the first message on the bidirectional stream in response”. Either endpoint of a session can be that subscriber, so the streams arrive in both directions and each direction needs an accept loop of its own.

Drafts 07 through 15 have no second use to forward: none of them puts any message on a bidirectional stream other than the control stream. Drafts 17 through 20 moved the control plane off bidirectional streams entirely, so there every bidirectional stream is a request stream and the first one is no different from the rest.

§Why the initial draft is enough to decide it

Because this question is asked before any SETUP has been read, and the answer cannot change once it is. Draft-16 has an ALPN of its own, so a session that begins as draft-16 is draft-16; the one cohort where the initial draft is a guess refined by the SETUP peek is moq-00, which spans drafts 07 to 14 and answers false for every member. There is no refinement that could turn this answer over.

§What the proxy does with one

Forwards it, and nothing more. Draft-16 withdraws a namespace subscription by ending its stream. Draft-16 Section 6.1: “A SUBSCRIBE_NAMESPACE can be cancelled by closing the stream with either a FIN or RESET_STREAM” — both are already mirrored onto the far side by the pipes, because they are what a forwarded stream ending looks like. Which of the two arrived is the endpoints’ business; this proxy holds neither end’s request state and must not start reading a cancellation into one.

§Why the match is exhaustive

Because false here means “this draft has no bidirectional stream worth accepting”, and a draft that answered it by omission would have the proxy simply never open the accept loop: request streams would be left hanging on both sides, with no error anywhere to say the proxy had declined to forward them. This boundary is one draft off control_plane_is_unidirectional’s and has to be read separately, which is the whole reason the two functions exist.