Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(s2n-quic-core): add stream state enums #2132

Merged
merged 1 commit into from
Mar 8, 2024
Merged

Conversation

camshaft
Copy link
Contributor

@camshaft camshaft commented Feb 16, 2024

Description of changes:

This change adds a state enum for both Send and Receive. These enums make it easy to ensure only valid state transitions are taken in the actual usage of the code. It also includes some tracing to show when these transitions take place for easy debugging.

Call-outs:

I will switch the current stream implementations to use these state enums as a separate PR.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@camshaft camshaft marked this pull request as ready for review February 19, 2024 18:47
Comment on lines +51 to +57
is!(Recv, is_receiving);
is!(SizeKnown, is_size_known);
is!(DataRecvd, is_data_received);
is!(DataRead, is_data_read);
is!(ResetRecvd, is_reset_received);
is!(ResetRead, is_reset_read);
is!(DataRead | ResetRead, is_terminal);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems like something that would be useful at some point to implement as a derive macro on the Enum

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah possibly. I'm sure there's one that already exists. The question is it worth the dependency 😄


pub type Result<T> = core::result::Result<(), Error<T>>;

macro_rules! transition {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be in a non-stream specific module? it could be used for some of the BBR enums that have state transitions

Comment on lines +38 to +41
pub enum Error<T> {
NoOp { current: T },
InvalidTransition { current: T, target: T },
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so the state transitions for streams would be influenced by the peer, so you'd need to return an error and close the connection (versus just panicking in a debug assertion). This is different than in BBR for example where if a an invalid state transition it was a software bug and we can just panic. So maybe not directly useable by BBR as is, but maybe somewhere else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah most likely could be used elsewhere, including BBR where we just have a variant that does debug_assertion instead of return an error.

One nice pattern about returning an error though is you don't have to check the state before transitioning. So something like

fn on_packet_sent(&mut self, packet: &[u8], is_fin: bool) {
    // ignore if we're already in this state, just make sure we transition from Ready to Send
    let _ = self.state.on_send();

    if is_fin && self.state.on_send_fin().is_ok() {
        println!("first transmission of fin bit");
    }
}

Copy link
Contributor

@WesleyRosenblum WesleyRosenblum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can move the macro to a different module later if needed

@camshaft camshaft merged commit d0c9f76 into main Mar 8, 2024
120 checks passed
@camshaft camshaft deleted the camshaft/stream-state branch March 8, 2024 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants