add frame types
transport parameter encoding and decoding - to my best understanding
fix typo
add some utility functions
add initial observed address frames
add frame encoding and decoding
adjust stats
minimal debugging for received observed addr
simplify setting extension in transport parameter
rework frame structure and send observed addr frames with path challenge ones
tweak example to start testing
fix encoding, send with handshake
clippy
fix docs
reject observed addr frames when not negotiated
replace request_id with seq_no according to new spec
replace code point for transport parameter
replace code point for frames
remove sending observed address frame in handshake in server side
treat as probing frame in payload processing
ack is already managed by is_ack_eliciting
send with path_response as well
add frame to retransmits and ignore old frames
send observed addr at least once per path
fmt
reword comment
remove trailing whites
keep observed address reports per path
remove addressed TODO
small improvement in readability
add retransmission with fresh info
retransmit just once
fix should send logic
add observed addr event
surface the info
restore trace level of frames
some extra logs
rename roles and var
improve error msg
assuming the default as disabled is ok, remove comment
use safe arithmetic with varints for the seq_no
move transport param code to method instead of From impl
fix example, finally
remove excesive log
add helper fn
carry old report into new path
generate notification only on changed values
downgrade log
add sending test
add resumption test on the acceptance case
add resumption test on the rejection case
spelling
actual spelling and undo debug change
dumb lints
some spelling and formatting
add retransmission test
make a bit more readable
update hexas
make naming consistent, add test
check docs for consistency
This commit adds a new --connection-limit option to the server example
to illustrate how a user could implement a limit to the number of
connections open at a time with the new "incoming" API and
Endpoint::open_connections method rather than with the now-removed
concurrent_connections ServerConfig parameter.
This commit adds a new --block option to the server example to
illustate in a simplified way the general structure one would use to
implement IP address blocking with the new accept/reject/retry API.
For example:
cargo run --example server ./ --listen 127.0.0.1:4433 --stateless-retry --block 127.0.0.1:8065
cargo run --example client https://127.0.0.1:4433/Cargo.toml --host localhost --bind 127.0.0.1:8065
One thing to note is that that example places the reject condition
before the retry condition. This expends slightly less effort rejecting
connections, but does create a blocked IP address oracle for an attacker
who can do address spoofing.
This commit removes use_retry from the server config and provides a
public API for the user to manually accept/refuse/retry incoming
connections before a handshake begins, and inspect properties such as
an incoming connection's remote address and whether that address is
validated when doing so.
In quinn-proto, Incoming is made public, as well as Endpoint's accept/
refuse/retry methods which operate on it. The
DatagramEvent::NewConnection event is modified to return an incoming
but not yet accepted connection.
In quinn, awaiting Endpoint::accept now yields a new
quinn::Incoming type, rather than quinn::Connecting. The new
quinn::Incoming type has all the methods its quinn_proto equivalent has,
as well as an accept method to (fallibly) transition it into a
Connecting, and also refuse, retry, and ignore methods.
Furthermore, quinn::Incoming implements IntoFuture with the output type
Result<Connection, ConnectionError>>, which is the same as the Future
output type of Connecting. This lets server code which was
straightforwardly awaiting the result of quinn::Endpoint::accept work
with little to no modification.
The test accept_after_close was removed because the functionality it
was testing for no longer exists.
For most setters this was just a case of changing the signature to take
a `VarInt`.
`max_idle_timeout` was a bit more involved in order to maintain a usable
conversion from `Duration`. The internal representation was changed from
`Duration` from `VarInt`, and an `IdleTimeout` newtype was introduced
for the setter signature. `IdleTimeout` contains a `VarInt`-encoded
millisecond value, and has a fallible conversion from `Duration`. The
use of a newtype is preferable to a direct `Duration` -> `VarInt`
encoding since there could be other `VarInt`-encoded values in future
that use a different resolution than milliseconds.
These changes allow callers to avoid the type-level possibility of error
if they have a `VarInt` (or a value that can be converted infallibly
into one). Fallible conversion from `VarInt` is still convenient with
`TryInto`, and callers can handle the conversion errors without the
indirection of `ConfigError`.
Closes#1176.
BREAKING CHANGE: The `max_concurrent_bidi_streams`,
`max_concurrent_uni_streams`, `stream_receive_window`, and
`receive_window` methods on `TransportConfig` now take `VarInt`
arguments and return `&mut Self`. `TransportConfig::max_idle_timeout`
now takes an `IdleTimeout` argument and returns `&mut Self`.
Previously, we limited the number of streams that could be opened by
the peer but not `accept`ed by the application. However, to guarantee
bounded resource use, applications will typically want to limit the
number of streams they process concurrently. While this could
be *approximately* implemented at the application layer by controlling
calls to accept, that approach has a significant drawback: If streams
are slow to process, the worst-case per-stream latency observed by a
peer who opens the maximum number of streams can be arbitrarily bad,
because streams may be opened above the limit the local application is
willing to process. Reducing the number of unaccepted streams
tolerated can reduce the proportion of streams affected, but reducing
it too low will increase the number of round trips required to open
any given number of streams, increasing average latency significantly.
As a side benefit, this reduces the effort needed for applications to
limit concurrency to a fixed quantity, which is expected to be the
overwhelmingly common case. Should a use case for dynamic concurrency
limits arise, we can expose a setter.
Use vectors instead of boxed slices
The conversion from Vec<u8> into Box<[u8]> is not always for free.
It will call `Vec::into_boxed_slice`, which will call `shrink_to_fit`.
https://github.com/rust-lang/rust/blob/28f03ac4c08fc7ec62428d0b914e1510ce7ee2cb/library/alloc/src/vec.rs#L689
If the `Vec` isn't fully utilized before, this will cause a reallocation
and a copy of all data. This might currently happen with every
outgoing packet.
This change simply keeps things as `Vec<u8>`, which works just fine since
the IO layer can deal with it.
dignifiedquire