Instead, it takes `max_pto: Duration`, which would otherwise be computed deep inside of it.
Unfortunately, this means we're pre-computing the value, and we also need to expose `close_pto` in `Connection`.
I'll experiment with this for now, but we'll see if this worsens performance.
The first packet on a new PathId could be a key update. Handle this
correctly: The expected packet number of the key update packet is 0 in
this case.
This changes the expected packet number when expanding the packet
number as well: Formerly we always expected packet 1 on a new PathId,
while strictly we would be expecting packet 0. This makes no
measurable difference though, since both values would be encoded in
the same way anyway so the expansion was still doing the right thing.
Ported from https://github.com/quinn-rs/quinn/pull/2436
* Remove `instant_saturating_sub` fn in favor of `Instant::saturating_duration_since`
* Avoid underflow panic in packet loss `Instant` calculations
* nat traversal requires multipath
* allow crate access, not ideal, but unavoidable
* satisfty MSRV limits
* pub all the way to the top
* update wasm-bindgen-test
* add nat_traversal field to TransportParameters
* add nat traversal's concurrency limit field to TransportConfig
* add nat_traversal TransportParameterId
* make field private to prevent zero values, reject 0 always
* enforce 0-rrt data matches
* calculate this connection's mtu as the minimum across all paths
* add TODO to check buffer reserving
* improve docs
* apply clippy fixes
* more docs tweaks
* second perspective on TODO
* spelling
* address TODO: reserving is already done in poll_transmit with the appropiate sizes
* remove obsolete dead code annotation
* add missing docs for coding and encoding path related frames
* make `RetireConnectionId` max size into consts
* make `NewConnectionId` max size into consts
* remove unwraps comming from n0 members in frame.rs
* Fix remote addresses in paths
- Remove quinn_proto::Connection::remote_address. You should use
path_remote_address now.
- Change quinn::Connection::remote_address to return *any* remote
address from any of the open paths.
- Fix opening paths on IPv4 addresses, when the endpoint supports
IPv6.
When the endpoint supports IPv6 it uses IPv4-mapped IPv6 addresses
for IPv4 remotes. This is enforced when establishing a connection,
and quinn-udp automatically does this for incoming datagrams.
However when opening a path we should do the same mapping.
Otherwise we will end up with an IPv4 remote address in the PathData
and incoming datagrams will come from an IPv6 address and be
dropped.
* fix tests
When building packets in GSO batches the batch is terminated if too
many padding bytes would be needed to continue this batch. This was
chosen fairly arbitrarily to be 16 bytes.
However when you have multipath enabled and allow a half-decent number
of simulatneous paths to be opened, you have to issue 5 *
initial_max_path_id PATH_NEW_CONNECTION_ID frames. This quickly
spills over into multiple datagrams, especially since this happens
early in the connection when the PMTU has not yet been discovered.
CIDs however, are 32 bytes by default. So if such a frame does no
longer fit in a datagram you would easily need more than 16 bytes of
padding. And in that case the GSO batch would break. Even though all
you're doing is sending a series of datagrams full of CIDs.
So tweaking this number to 32 allows us to build these packes without
breaking the GSO batch.
* Fix WeakConnection::upgrade
It created a ConnectionRef that did not increment the manually-tracked
reference count inside the Arc<ConnectionInner>. This triggered the
ConnectionRef's Drop impl to actually drop the connection.
This works around this by using the fact that the ConnectionRef's
Clone impl does know how to manipulate the reference count in a way
that works together with the ConnectionRef's Drop. I think this is
preferred over manipulating the ref_count directly in the
WeakConnectionHandle since that code is closer by.
* Nicer implementation
The previous logic does not work: the client has the path validated
immediately, even before any packet is sent.
Now we need to have received an authenticated handshake packet before
we stop allowing migration. This exposes us to a little more off-path
attacking, but in terms of processing all the earlier packets: only
the correct server can generate an authenticated handshake packet IIUC.
Philipp Krüger