* store paths in a slice, not a map
No functional change expected.
* save the timestamp of the last received packet for a path
* evict old paths
* reduce the path timeout to 5s
* Update comment styles
1. Use doc links (the square brackets around identifiers) to make
clickable links on pkg.go.dev (https://go.dev/doc/comment#doclinks)
2. Indent lists so that they are rendered properly -- at which point go
fmt updates the bullet character to a dash
(https://go.dev/doc/comment#lists)
3. Add a couple missing punctuation marks
These all will improve the experience of browsing the quic-go docs on
pkg.go.dev.
* ignore SA1019 for the ConnectionTracingID
* ci: exclude ConnectionTracing(ID, Key) from staticlint in http3
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
* give the kernel some time to free the socket
* remove problematic assertion
The listen function is started in a Goroutine, hence we
can’t be sure it’s already started.
The previous logic allowed for setting different ALPN
values depending on the QUIC version in use. This was
needed to set the draft ALPN value before publication of
the RFC.
New PATH_CHALLENGES are sent for as long as the call to
Path.Probe is active. The first retransmission is sent after 200ms,
with an exponential backoff afterwards.
Several proxy tests timed out because it got stuck in the packet read
loop after all tests have run. Avoid this by running the `conn.Close()`
Cleanup call from `newUPDConnLocalhost` before the timeout handler.
Update CI to run these tests.
Fixes: 3e87ea3f50 ("proxy: add function to simulate NAT rebinding (#4922)")
Relates to: #5009
* make it possible to pack path probes with multiple frames
* simplify function signature of pathManager.HandlePacket
* simplify connection short header packet handling logic
No functional change expected.
* make server send PATH_RESPONSEs on the same path
This makes sure that we’re actually testing for return routability.
A reordered PATH_CHALLENGE (or one sent on a slower path)
should still trigger a PATH_RESPONSE. The RFC only forbids
switching the path unless the non-probing packet has the
highest packet number received so far.
When receiving a ClientHello for a 0-RTT connection, this allows us to derive both 0-RTT and Handshake keys at the same time. The previous logic used to inadvertently discard previously undecryptable packets (e.g. reordered 0-RTT packets).
