This reverts the change that tries to avoid sending a PING frame if
there are user datagrams to send. The problem is that the user
dataram might not fit in the probe that will be sent.
It is possible to do this better, but the quick thing is to accept the
extra ping frame, the space wasted because of this is rather minimal.
And if a user was sending user datagrams at just the right MTU size it
is unlikely they would fit in the next packet anyway since typically
the probe packet will end up with a smaller size-limit compared to the
MTU.
This caused rare flakes in at least
single_ack_eliciting_packet_triggers_ack_after_delay by classifying a
the connection as active for longer than expected.
This was the only case where `Instant::now()` is used in quinn-proto or quinn-udp for anything other than tests or rate-limiting logging. Making this change to keep these two crates more IO-agnostic.
On MacOS < 14, with `fast-apple-datapath` feature, calls to
`libc::CMSG_NXTHDR` might continuously return empty (i.e. all zero)
`libc::cmsghdr` instead of a null pointer. This results in a busy loop
in `decode_recv`:
``` rust
let cmsg_iter = unsafe { cmsg::Iter::new(hdr) };
for cmsg in cmsg_iter {
match (cmsg.cmsg_level, cmsg.cmsg_type) {
```
https://github.com/quinn-rs/quinn/blob/b4378bb39dab4b58a1e6a3fea4fff9f87033dab6/quinn-udp/src/unix.rs#L685C1-L687C50
This commit fixes the above, returning a `null_mut()` pointer on an
empty `libc::cmsgdhr`, thus terminating the `cmsg_iter`.
See also https://github.com/mozilla/neqo/pull/2427 for details.
Configures the default clients and servers in proto tests to be able to
utilize NEW_TOKEN frames. This involves creating simple implementations
of token-related traits internal to the test module. These
implementations are essentially the most boring possible implementation
that is able to actually utilize tokens. They would not be suitable for
use in real applications because their memory usage is unbounded.
When we first added tests::util::IncomingConnectionBehavior, we opted to
use an enum instead of a callback because it seemed cleaner. However,
the number of variants have grown, and adding integration tests for
validation tokens from NEW_TOKEN frames threatens to make this logic
even more complicated. Moreover, there is another advantage to callbacks
we have not been exploiting: a stateful FnMut can assert that incoming
connection handling within a test follows a certain expected sequence
of Incoming properties.
As such, this commit replaces TestEndpoint.incoming_connection_behavior
with a handle_incoming callback, and modifies an existing test to
exploit this functionality to test more things than it was previously.
When a client receives a token from a NEW_TOKEN frame, it submits it to
a TokenStore object for storage. When an endpoint connects to a server,
it queries the TokenStore object for a token applicable to the server
name, and uses it if one is retrieved.
As of this commit, the only provided implementation of TokenStore is
NoneTokenStore, which is equivalent to the lack of a token store, and is
the default.
When a path becomes validated, the server may send the client NEW_TOKEN
frames. These may cause an Incoming to be validated.
- Adds TokenPayload::Validation variant
- Adds relevant configuration to ServerConfig
- Adds `TokenLog` object to server to mitigate token reuse
As of this commit, the only provided implementation of TokenLog is
NoneTokenLog, which is equivalent to the lack of a token log, and is the
default.
As of this commit, it only has a single variant, which is Retry.
However, the next commit will add an additional variant. In addition
to pure refactors, a discriminant byte is used when encoding.
The ability for the server to process tokens from NEW_TOKEN frames will
create the possibility of Incoming which are validated, but may still be
retried. This commit creates an API for that. This means that rather
than Incoming.remote_address_validated being tied to retry_src_cid, it
is tied to a new `validated: bool` of `IncomingToken`.
Currently, this field is initialized to true iff retry_src_cid is some.
However, subsequent commits will introduce the possibility for
divergence.
Previously, retry tokens were encrypted using the retry src cid as the
key derivation input. This has been described by a reputable individual
as "cheeky" (who, coincidentially, wrote that code in the first place).
More importantly, this presents obstacles to using NEW_TOKEN frames.
With this commit, tokens carry a random 128-bit value, which is used to
derive the key for encrypting the rest of the token.
Moves all the fields of Token to a new RetryTokenPayload struct, and
makes Token have a single `payload: RetryTokenPayload` field. This may
seem strange at first, but it sets up for the next commit, which adds
an additional field to Token.
kota-yata