Android API level < 26 does not support the `libc::IP_TOS` control message.
`sendmsg` calls with `libc::IP_TOS` return `libc::EINVAL`.
https://github.com/quinn-rs/quinn/pull/1516 added a fallback, not setting
`libc::IP_TOS` on consecutive calls to `sendmsg` after a failure with
`libc::EINVAL`. The current datagram would be dropped. Consecutive datagrams
passed to `sendmsg` would succeed as they would be sent without `libc::IP_TOS`
through the fallback.
Instead of dropping the first datagram on `libc::EINVAL`, this commit adds a
retry for it without `libc::IP_TOS`.
This is e.g. relevant for Neqo. When establishing a QUIC connection, dropping
the first datagram [delays connection establishment by
100ms](https://github.com/mozilla/neqo/blob/3001a3a56f2274eaafaa956fb394f0817f526ae7/neqo-transport/src/rtt.rs#L28).
With the retry introduced in this commit, delay due to unsupported
`libc::IP_TOS` should be negligeable.
Closes https://github.com/quinn-rs/quinn/pull/1975.
No need to `return Ok(())` early, given the final `return Ok(())` at the end of
the function. Makes it consistent with other `send` implementations. Makes it
consistent with early returns being errors only.
- Adds trait TimeSource
- Adds default implementation StdSystemTime
- Adds ServerConfigParameter time_source: Arc<dyn TimeSource>
- Replaces all SystemTime::now calls in proto with TimeSource.now calls
(there were 2)
This is a backwards-compatible change.
There is a should_panic test which depends on a debug assertion to
panic. This commit makes the test enabled only when debug assertions
are enabled. This fixes `cargo test --release`.
RFC 9000 presents some unfortunate complications to naming things. It
introduces a concept of a "token" that may cause a connection to be
validated early. In some ways, these tokens must be treated discretely
differently based on whether they originated from a NEW_TOKEN frame or
a Retry packet. It also introduces an unrelated concept of a "stateless
reset token".
If our code and documentation were to constantly use phrases like "token
originating from NEW_TOKEN frame," that would be extremely cumbersome.
Moreover, it would risk feeling like leaking spec internals to the user.
As such, this commit tries to move things towards the following naming
convention:
- A token from a NEW_TOKEN frame is called a "validation token", or
"address validation token", although the shorter form should be used
most often.
- A token from a Retry packet is called a "retry token".
We should avoid saying "stateless retry token" because this phrase is
not used at all in RFC 9000 and is confusingly similar to "stateless
reset token". This commit changes public usages of that phrase.
- In the generic case of either, we call it a "token".
- We still call a stateless reset token a "reset token" or "stateless
reset token".
It turned out currently the `coding` mod is already public, simply hidden from the docs.
It seems to be the minimal change to allow using this functionality for `VarInt` is to document it and not hide it.
Fixes#1277
On Windows on ARM with Windows Subsystem for Linux (WSL) `WSA_RECVMSG` does not
return the segment size of coalesced UDP datagrams. See
https://github.com/quinn-rs/quinn/issues/2041 for details.
While lacking a fix for the root cause, don't enable URO, i.e. don't coalesce
UDP datagrams on Windows on ARM.
With https://github.com/quinn-rs/quinn/pull/2017, the concrete `send`
implementations per platform are supposed to propagate `io::Error`s. Those
errors are then eiter logged and dropped in `UdpSocketState::send` or further
propagated in `UdpSocketState::try_send`.
The `fast_apple` `send` implementation added in
https://github.com/quinn-rs/quinn/pull/1993 does not follow this pattern.
This commit adjusts the `fast_apple` implementation accordingly.
It is common to set up automated error reporting based on `ERROR` and
potentially also `WARN` logs. Whilst GSO being unsupported is certainly
something worthwhile logging, the `ERROR` log level seems a bit
excessive and leads to unactionable errors reports.
The system can still operate with `max_gso_segments == 1`. As such, this
codepath "merely" indicates a state change in the system but not a fatal
error. As such, logging this on INFO level seems more appropriate.
Floris Bruynooghe