The nix version on the workspace is actually lower, so I downgraded the
version used by apps too.
Only other incompatible thing was url, but that just require a slight
change in how addresses are resolved.
Currently the max active CIDs limit controls both the number of active
CIDs as well as the number of active paths, so while during rebinding
tests the CIDs don't change, we are still prevented from creating new
paths because of the limit, causing the interop rebinding tests to fail.
Previously, the quiche-server HTTP/3 poll() loop would preference writing HTTP
response headers for all received requests ahead of any other data. Once
completed, no attempt to use remaining stream capacity was made. This had the
effect of deferring writing HTTP response content until the next time the read
loop was triggered. Especially noticeable when the path had a high RTT.
This change forces an attempt to write on any writable response streams
immediately after all response headers have been flushed.
In the 0-RTT test there are more than 2 requests, and we are supposed to
only run the first one in 1-RTT and the remaining ones in the resumed
0-RTT connection.
Motivation:
Some of the methods used *source_cid* and *destination_cid* in the name while most others uses *scid* and *dcid*. Naming of methods should be consistent to make it easier to discover things.
Modifications:
Rename methods for consistent naming
Result:
Cleanup of public API
One notable change is that functions like `setsockopt()` now require
`AsFd` instead of the raw fd, but mio doesn't implement that, so we need
to convert fds explicitly.
An HTTP/3 datagram is a series of fields carried in a QUIC DATAGRAM frame
payload. In draft 00, draft 11 and RFC 9297 there is a single field,
which is a variable-length integer.
Previously, the h3 module provided support functions that were a thin shim over
quiche's transport-layer datagram methods, which helped with the variable-length
encoding of the first field in the HTTP/3 datagram. However, in the meantime we
spun out the Octets crate, which allows applications to easily handle varints
themselves. Furthermore, changes in specifications like CONNECT-UDP mean that
applications are probably required to do additional processing of varint fields
that might exist after the first field. At this stage, the h3 datagram API
provides minimal utility and in the worst case is confusing for applications
that would use it for different purposes.
This change removes quiche::h3::send_dgram() and quiche::h3::recv_dgram()
functions. Instead applications are now responsible for serialization /
deserialization of HTTP/3 datagrams, with the recommendation being that they use
the Octets crate. This is demonstrated by related changes to the apps.
Since the Octets crate does not provide a C API itself, helper function have
been added to quiche's C API to support varint handling.
Previously, as soon as a server received a request, it would try to emit
headers and body during the same cycle. When then body was too large to
send (e.g., due to congestion window) the response would be queued up
for later rounds of writing. This initial send always happened
regardless of a stream's selected priority.
The later rounds of writing explicitly use a writable iterator to step
through the streams. When switching to an iterator that better supports
priority scheduling, streams that are queued are more likely to respect
the selected priority.
With this change, we no longer attempt to write body immediately.
Instead, it is added to the dispatch queue that will be drained in
accordance with the writable iterator.
.
SiDuck was an early attempt to promote interop of QUIC datagrams.
In the meantime, both QUIC datagrams and HTTP datagrams have been
published as RFCs. Furthermore, UDP and IP proxying use cases have
acheived good interop in the wider community.
This change removes SiDuck from the apps.
There are occaisons where the quiche-server will get blocked from
sending response headers. We already cater for this in the application
and store the request headers or body in order to retry once the
stream is reported as writable.
However, in the case of blocked headers, the response priority was
not stored and when the stream was unblocked, quiche-server did not
try to send_response_with_priority(). Together this meant that
responses that were blocked when attempting to send headers would
revert to a default priority.
With this change, we store the original priority that was intended
and make sure to use it on each retry attempt.
When creating a new h3:Connection, quiche attempts to open
unidirectional streams. We care about the control stream
being opened and will return an Error if that can't happen.
In the case where the control stream failure occurred due to
stream ID limits, quiche returns a StreamLimit error to
indicate that.
In the case where the control stream failure occured due to
flow control being too small to send SETTINGS, we would
return a generic Error:Done, which is potentially confusing.
With this change, failures due to flow control are
more clearly marked as InternalError, since this is an implementation
choice. Trace logging has also been added to help better
communicate the control flow through quiche.
To mirror these changes, applications have been updated
with clearer error handling.
Fixes#1249
When GSO can be enabled (on a supported linux platform),
now quiche-server sends multiple packets using sendmsg()
with GSO.
For non-supported platforms, it should work same as before.
Instead of returning stats for all paths from the `stats()` method, add
a new method specific to path stats. This also allows us to return an
iterator for the path stats list, rather than have to collect the
iterator into a `Vec` (thus avoiding an allocation and also having to
iterate over all paths).
With this change, add support for three new quiche app CLI options that
control HTTP/3 settings parameter values.
When these options are not provided, the applications will omit sending
the HTTP/3 settings, which by RFC 9114 means that the peer will use the
default values.
When the `--max-field-section-size` option is provided, the setting is
sent with that value.
quiche does not support dynamic QPACK. If the
`--qpack-max-table-capacity` or `--qpack-blocked-streams` options are
provided, their values are clamped to 0 before being sent in a setting.
