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

Add async way to read early data from TLSAcceptor #73

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tahmid-23
Copy link

Enables reading early data server-side in an async way, separate from the normal reading method.

Please give any suggestions 🙂

Copy link
Member

@cpu cpu left a comment

Choose a reason for hiding this comment

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

Thanks for the PR. I think you have some CI failures to fixup.

I haven't done a review pass yet, just wanted to leave one comment up-front.

Cargo.toml Outdated Show resolved Hide resolved
@tahmid-23 tahmid-23 force-pushed the main branch 2 times, most recently from 9a37712 to 2565c62 Compare May 22, 2024 00:15
@djc djc requested a review from quininer May 22, 2024 08:45
quininer
quininer previously approved these changes May 22, 2024
Copy link
Member

@quininer quininer left a comment

Choose a reason for hiding this comment

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

LGTM

}

if stream.session.is_handshaking() {
return Poll::Pending;
Copy link
Member

Choose a reason for hiding this comment

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

Should we return pending here? or should I handshake? I'm worried about a hang due to missing wake.

Copy link
Author

Choose a reason for hiding this comment

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

I don't think there would be a missing wake? since handshake is done once the client sends it's finished, and this code depends on read. I'm not fully sure though.

but now that I think about it, the test code doesn't cover this. since I do acceptor.accept(&mut sock).await, the handshake already finishes, so reading the early data "async" effectively did nothing.
should I change some of the server stream logic to use the early data state (kind of like client)? acceptor.accept would no longer wait for the handshake to complete, and writing/reading would need to wait on the handshake to complete.
if I do that, then maybe it would make sense to further the handshake here?

Copy link
Member

Choose a reason for hiding this comment

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

If we got Pending from stream.read_io() it's fine to return Pending here, can is_handshaking() return true after read_io() has yielded Ok(0)?

@quininer quininer dismissed their stale review May 22, 2024 11:48

pending issue

let mut stream =
Stream::new(&mut this.io, &mut this.session).set_eof(!this.state.readable());

match &this.state {
Copy link
Member

Choose a reason for hiding this comment

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

Nit: would be nice to restructure this code more like this:

match &this.state {
    TlsState::Stream | TlsState::WriteShutdown => {}
    TlsState::ReadShutdown | TlsState::FullyShutdown => return Poll::Ready(Ok(())),
    s => unreachable!("server TLS can not hit this state: {:?}", s),
}

let mut stream = stream.as_mut_pin();
..

Comment on lines +120 to +132
while !stream.eof && stream.session.wants_read() {
match stream.read_io(cx) {
Poll::Ready(Ok(0)) => {
break;
}
Poll::Ready(Ok(_)) => (),
Poll::Pending => {
break;
}
Poll::Ready(Err(err)) => return Poll::Ready(Err(err)),
}
}
}
Copy link
Member

Choose a reason for hiding this comment

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

This code looks it's duplicated from somewhere else. Can we abstract over it instead? If not, why not?

Copy link
Author

Choose a reason for hiding this comment

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

some of the branches update different variables, I don't really know how to extract it

tests/early-data.rs Show resolved Hide resolved
async fn send(
config: Arc<ClientConfig>,
addr: SocketAddr,
data: &[u8],
vectored: bool,
) -> io::Result<(TlsStream<TcpStream>, Vec<u8>)> {
) -> io::Result<(client::TlsStream<TcpStream>, Vec<u8>)> {
Copy link
Member

Choose a reason for hiding this comment

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

This change seems unrelated? If so, prefer to avoid it.

Copy link
Author

Choose a reason for hiding this comment

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

I gave a more qualified name because I use server::TlsStream as well. should I still revert it?

let mut stream_wrapper = TlsStreamEarlyWrapper { inner: stream };
stream_wrapper.read_to_end(&mut buf).await.unwrap();
let mut stream = stream_wrapper.inner;
stream.write_all(b"EARLY:").await.unwrap();
Copy link
Member

Choose a reason for hiding this comment

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

Should there be a test that explicitly tests for being able to read actual data off of the early data stream?

Copy link
Author

Choose a reason for hiding this comment

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

I don't follow. This is already reading the early data?

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.

4 participants