test(s2n-quic): show how to block clients on handshake confirmation #1766
Conversation
camshaft
force-pushed
the
camshaft/client-confirm-test
branch
from
3306d58
to
89bc81e
Compare
|
Any reason this can't go in |
| stream.send(vec![42; LEN].into()).await.unwrap(); | ||
| stream.finish().unwrap(); | ||
|
|
||
| let mut recv_len = 0; | ||
| while let Some(chunk) = stream.receive().await.unwrap() { | ||
| recv_len += chunk.len(); | ||
| } |
There was a problem hiding this comment.
i get the sending data but how are we receiving data? I dont see how the client is receiving data (where is the server sending data?)
There was a problem hiding this comment.
the default server implementation just echos back everything from the client.
| let mut stream = conn.open_bidirectional_stream().await.unwrap(); | ||
|
|
||
| stream.send(vec![42; LEN].into()).await.unwrap(); | ||
| stream.finish().unwrap(); |
There was a problem hiding this comment.
do we want flush here instead of finish for the happy case? or this does seem to be acting like echo so i guess receiving confirms we sent stuff?
There was a problem hiding this comment.
we don't really need to flush; that'll block the task until the server ACKs the whole thing. But we do need to call finish, which will tell the server that we're done sending. If we don't call finish here, the connection will hang /deadlock cause the client is waiting on receiving data from the server, which is still waiting receiving more data from the client.
It can; it just makes it a lot harder to test. I don't know if I anticipate this being used that much so IMO it's fine to stay as a test that we can point people to if needed. If it starts getting more demand, then we can move it. Thoughts? |
That's fine, but what makes it harder to test as an example? |
I believe the reason is that we cant really run an example in CI (launch a server and client and check for correct behavior). However, we can do that as part of the integration test. |
|
Yeah we don't currently have a good way to run examples as part of CI. We check that they build but I definitely wanted so automation around this test to show it working. |
Description of changes:
This change adds a test that shows an example of an event provider that blocks the client from opening any streams until the handshake is completely confirmed by the server.
When using mTLS, the client is technically allowed to start sending application data before the server has actually authenticated the client. For clients that want to wait before getting a confirmation of the server accepting the client's certificate, they can use the
ClientConfirmstruct as an event provider on theClient.Note that waiting for handshake confirmation will add another round trip to the handshake so keep that in mind when deciding if this functionality is useful.
This module includes 3 distinct tests to show the behavior:
mtls_happy_casecreates a successful connection and sends some datamtls_failure_no_waitshows the case when thewait_readyfunctionality is not used. The client opens a connection and stream, sends some data, only to find that the server rejected the client's certificate when trying to receive the response.mtls_failure_with_waitshows that when using thewait_readyfunctionality the client is unable to open a stream, as the task was blocked until the server either confirmed or rejected the connection attempt.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.