-
Notifications
You must be signed in to change notification settings - Fork 87
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
Handshake controller for QUIC #419
Handshake controller for QUIC #419
Conversation
7ab04ec
to
374c314
Compare
The design with handshake-controller limits the impact on client/server code quite well. However the exposed API: type ServerController = ServerControl -> IO ServerStatus
type ClientController = ClientControl -> IO ClientStatus replicates a state machine in I'd rather try removing the stateful computations going through the API, i.e.
The tricky part is the server flight concatenating both Initial and Handshake content together. It must be possible to send the composite flight with an API similar to: send :: [(Level, ByteString)] -> IO ()
recv :: Level -> IO ByteString |
Removing the state in QUIC is a good idea.
Does this mean that a new type of backend should be introduced? |
Ah, you don't intend to introduce a new type of backend. Just making use of To depend on the |
Never mind. In this approach, So, |
For now I will try some experiments in a consolidated repository: |
Thanks. I should concentrate on QPACK and HTTP/3 now. Please remind me when ready. |
I implemented a large part of the callback approach but found a blocking point. Do you think the more general reordering based on packet encryption level could be added to the Receiver? (or it's already there but I didn't see it) |
Hmm... maybe the reordering is there (with |
I understand why the blocking happens. But I don't understand what you are asking.
The big problem for me was that RTT1 packets are received before handshake messages to generate RTT1 keys are received. There is no way to decrypt the RTT1 packets. As workaround, I put
|
What about this?
For instance, if |
Also, I'm OK with separating encryption level into RX and TX. This would enable that 1RTT packets can be sent while preventing received 1RTT packets from processing before receiving Finished. |
Please give a look at:
I modified |
If you remove |
Thank you, I try this. For me the issue was not necessarily the use of If Actually I see this is all well explained in section 5.7. |
Yup. I hope so. |
I pushed a version for review. All changes on the combined project: Same commits but for Same commits but for |
a2e831e
to
512da57
Compare
I have rebased this branch onto Most part looks good. However, since your change converts QUIC
|
This is not relating to this PR but QUIC now does not allow compatible mode. This means that Client Hello must includ 0-byte session id. To make the work to fix two issues above easier, I would like to merge this PR anyway. |
I pushed a workaround for version negotiation to |
OK good the workaround is possible. For the 0-byte session id I think it would be good to introduce a QUIC mode. |
As discussed in #392, I have implemented QUIC APIs based on threads. This does not change
Client.hs
andServer.hs
a lot. QUIC APIs are provided inNetwork.TLS.QUIC
. So,Network.TLS
remains the same.I joined 16th QUIC interop and am now confident the quality of this code: https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg
@ocheron I don't expect that this PR will be merged quickly. But I would like to get feedback if any.