Two level dispatchings are necessary for QUIC:
- Dispatching QUIC packets to connections
- Dispatching QUIC streams in a connection to something (perhaps to lightweight thread workers)
But the second dispatching is tough. As I described in Experience Report: Developing High Performance HTTP/2 Server in Haskell and Supporting HTTP/2, I mapped an HTTP/2 stream to a worker of lightweight thread. In this architecture, some other threads are involved to control workers.
Should I reinvent the similar architecture for QUIC? My brain got befuddled.
I finally reached a conclusion: my question was raised because my HTTP/2 server was hard-coded in Warp. If I can extract it as a generic library for HTTP/2 servers, I will be able to reuse it for HTTTP/3.
It took much time but the result is promising. The APIs is so beautiful and functional. This APIs even enable to calculate a checksum in a trailer for streaming response body.
I have already released the http2 library version 2.0.0 with
Network.HTTP2.Server module. Warp will switch from the original implementation to this server library soon.
The APIs are inspired by WAI but are independent from it. I hope that other HTTP engines can adopt the HTTP/2 server library easily.