Before they were decoded lazily, but that work as done many times over and over again, when they where ever logged in debug mode. This decodes these immediately and stores them in an `ArrayRangeSet`
Also moves the debug impl to the `ArrayRangeSet` making that print more easily
When adding items to this we generally don't want to worry about
checking if the value is already pending. Currently we keep adding to
the Vec with the same value in some situations, resulting in sending
the frame many times for the same path.
This avoids duplicate entries.
With this we no longer get compile errors in vscode because the fuzzing
code uses fns that are themselves gated with cfg(fuzzing).
We have to tell rust about the feature in Cargo.toml to avoid warnings.
When dropping oversized datagrams after an MTU change, notify
callers of `send_datagram_wait` that are waiting for
space in the send buffer.
Tracking issue: https://github.com/quinn-rs/quinn/issues/2456
Replace conditional compilation on the `hdr` parameter with a generic type bound `M: cmsg::MsgHdr<ControlMessage = libc::cmsghdr>`. This enables `decode_recv` to work with both `libc::msghdr` and `msghdr_x` message types.
Broken out of #2463 as suggested by @djc.
```
warning: called `unwrap` on `self.exit_probe_rtt_at` after checking its variant with `is_none`
--> quinn-proto/src/congestion/bbr/mod.rs:247:48
|
238 | if self.exit_probe_rtt_at.is_none() {
| ----------------------------------- help: try: `if let Some(<item>) = self.exit_probe_rtt_at`
...
247 | } else if is_round_start && now >= self.exit_probe_rtt_at.unwrap() {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_unwrap
= note: `#[warn(clippy::unnecessary_unwrap)]` on by default
```
## Description
@rklaehn noticed proptests failing in CI, and turns out those failures
are reproducible.
This PR adds the failure as a regression test in `proptest.rs` (It
exercises an interesting multipath case).
After some investigation, I found that the `ConnectionClose` frame seen
in the test doesn't round-trip encoding/decoding. I added a regression
test for that as well.
The actual bug was using `buf.write(0u64)` for encoding
`MaybeFrame::None` instead of `buf.write_var(0u64)`.
## Notes & open questions
Ideally, we have proptests for encoding/decoding datagrams.
I also found that `MaybeFrame::Unknown` would use the same incorrect
`buf.write` with a u64. We probably should make this situation better.
Perhaps we can use `VarInt` in the types in favor of `u64`?
## Description
Fix condition to generate PROTOCOL_VIOLATION. It was the wrong way
around, didn't match the comment above.
## Breaking Changes
None
## Notes & open questions
Note: this is the result of trying out claude code on quinn and telling
it to find an obvious bug.
## Description
<!-- A summary of what this pull request achieves and a rough list of
changes. -->
## Breaking Changes
<!-- Optional, if there are any breaking changes document them,
including how to migrate older code. -->
## Notes & open questions
<!-- Any notes, remarks or open questions you have to make about the PR.
-->
- do not request 100 bytes padding by default
- do not reseve space for the AEAD tag
- when using this make sure the datagram is started and has the
correct size
dignifiedquire