As of the previous commit, RetryToken::decode fails only with the
Unusable variant, and validation only occurs in
IncomingToken::from_header, which uses InvalidRetryTokenError directly.
This allows us to remove ValidationError altogether.
Prior to this commit, a RetryToken encodes the client's address as if it
were a field, but rather than it actually being a field, it's threaded
in to encode, and validated in-place in decode. It's unclear to me why
this is. This commit makes the remote address simply a field of the
RetryToken struct.
Prior to this commit, decoding a socket addr from a RetryToken called
get_u8 and get_u16, which would have panicked if an encrypted token were
minted that terminated after that point. This replaces them with calls
that short-circuit, for consistency with other parts of the code there.
- Removes `#[doc(hidden)]`
- Adds hyperlink
- Demotes most of the doc comment to non-doc comment, as it seems more
like an internal note than something the user needs to see.
Moves more logic from Endpoint::handle_first_packet to the proto::token
module. Due to improved decoupling between modules, Token::from_bytes
and ValidationError can now be made private.
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".
Phoenix Kahlo