|author||bnc <email@example.com>||Wed Mar 15 07:45:06 2023 -0700|
|committer||Copybara-Service <firstname.lastname@example.org>||Wed Mar 15 07:46:26 2023 -0700|
Disable batched write in QuicWriteBlockedList. As a reminder, HTTP/3 streams have two priority-related parameters received from the clien in PRIORITY_UPDATE frames: urgency (int) and incremental (bool). Writes can be continuous or round-robin. With continuous writes, if data is written on a given stream, writing contiues as long as there is data for that stream. Round-robin writes can be batched or not. If batched, writing on a stream can continue if less than 16 kB of data has been written continuously on that stream. If not batched, other streams with same urgency get a turn after a single write. In any case, the size of a single write is not limited by QuicWriteBlockedList. This applies to streams with the same urgency value. Streams always yield to streams with higher priority (lower urgency value). Incremental streams are always written round-robin. If --gfe2_reloadable_flag_quic_priority_respect_incremental is false, non-incremental streams are also written round-robin. If it is true, they are written continuously. This was introduced in cl/511587715. This CL introduces --gfe2_reloadable_flag_quic_disable_batch_write. If false, round-robin writes are batched. If true, they are not batched. This applies to incremental streams, and if --gfe2_reloadable_flag_quic_priority_respect_incremental is false, then to non-incremental streams as well. An additional optimization is to prioritize the non-incremental stream with the last write over incremental streams even if there was a write on the incremental stream in the meanwhile (due to the non-incremental stream not having data to write). While this sounds unfair (in the sense that incremental streams may be starved), this is no worse than incremental streams being blocked by a non-incremental stream that can provide write data continuously. The rationale is that data on a non-incremental stream is useless for the client until all of it is received, so once some of it was sent, send all of it. (Note that incremental streams do not immediately yield to other non-incremental streams that have started writing, only to the most recent one. They get at least one turn to write their own data.) Protected by FLAGS_quic_reloadable_flag_quic_disable_batch_write. PiperOrigin-RevId: 516822305
QUICHE stands for QUIC, Http, Etc. It is Google‘s production-ready implementation of QUIC, HTTP/2, HTTP/3, and related protocols and tools. It powers Google’s servers, Chromium, Envoy, and other projects. It is actively developed and maintained.
There are two public QUICHE repositories. Either one may be used by embedders, as they are automatically kept in sync:
To embed QUICHE in your project, platform APIs need to be implemented and build files need to be created. Note that it is on the QUICHE team's roadmap to include default implementation for all platform APIs and to open-source build files. In the meanwhile, take a look at open source embedders like Chromium and Envoy to get started:
To contribute to QUICHE, follow instructions at CONTRIBUTING.md.
QUICHE is only supported on little-endian platforms.