Philipp Krüger
147892a1d1
## Description Please merge this after #710 Prior to this change, retransmissions of PATHS_BLOCKED and PATH_CIDS_BLOCKED frames would use "up to date" information for the known maximum remote path ID and CID queue expected next seq number respectively. This is weird, because these frames are informational and meant for debugging, and either we don't send them when they're not needed anymore (e.g. between originally trying to send them and retransmission the maximum remote path ID increased or the CID queue active seq number increased. In both of these cases we wouldn't actually be blocked anymore.), or we just retransmit them with with the "outdated" values that we sent them with on the first transmit. This PR decides to go for the latter. This provides the appropriate debugging information to the remote that we were out of path CIDs *at some point in time*, even if that is now obsolete. --- Apart from that this PR also fixes the fact that we never actually queued PATHS_BLOCKED frames in the first place... ## Breaking Changes None. ## Notes & open questions Arguably, we should not send any of these frames and I personally hate them, they haven't really helped me at all and only caused problems so far. The only good reason I can find to keep sending them is that the spec forces the server side to correctly *handle* them (and produce protocol violations if they're sent incorrectly), and without actually sending them, we would never exercise these code paths and not make sure that said server side checks are correct. (Yes I think that's just unnecessary busywork and wasted bytes/datagrams.) I've also added a test to check that we transmit & retransmit PATHS_BLOCKED frames. Unfortunately it's quite hard to check that the data that is actually sent is the same PATHS_BLOCKED frame as originally constructed. Instead I did a manual check by looking at the logs. Please trust me bro. ## Change checklist - [x] Self-review. - [x] Tests if relevant.
noq
General purpose implementation of the QUIC transport
protocol in pure
Rust. Noq is built as an async-friendly API in the noq crate on top
of a sans-io protocol library in noq-proto.
Noq started out as a fork of the excellent Quinn project. The main focus of development has been towards adding support for more QUIC (draft) extensions:
Features
- Easy to use futures-based async API.
- Client and server server functionality.
- 0-RTT and 0.5-RTT data support.
- Ordered and unordered stream reads.
- Custom and zero-length connection identifiers.
- Fully pluggable crypto API with a Rustls implementation using ring or aws-lc-rs provided by default for convenience.
- Broad platform support, including Linux, Windows, macOS, android, iOS and wasm.
Standards
The noq library aims to be correct implementation of various QUIC standards:
- Supports the core QUIC specifications:
- The standardised QUIC extensions:
- Draft extensions:
- qlog: Structured Logging for Network Protocols.
- QUIC Multipath.
- With experimental qlog support.
- QUIC Address Discovery (QAD).
- Using QUIC to traverse NATs (QNT).
Getting started
Examples at https://github.com/n0-computer/noq/blob/main/noq/examples
$ cargo run --example server ./
$ cargo run --example client https://localhost:4433/Cargo.toml
This launches an HTTP 0.9 server over the QUIC transport on the loopback address serving the current working directory, with the client fetching ./Cargo.toml. By default, the server generates a self-signed certificate and stores it to disk, where the client will automatically find and trust it.
License
Copyright 2025 The quinn developers Copyright 2025 N0, INC.
This project is licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.