This allows QUIC_STREAM objects to be deleted when they are no longer
needed.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
We need to get acknowledgement notifications for our STOP_SENDING and
STREAM_RESET frames as this information is needed to know when we can
delete a QUIC_STREAM object.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
Also use accept queue popping by the application as the retirement
event, i.e., as the cue to increase the limit.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
Though the RXFC was designed for stream flow control, its logic
is generic enough to use to control MAX_STREAMS generation.
Control of when _we_ can open streams is already done in a bespoke
fashion and doesn't use a TXFC, however (see
ossl_quic_stream_map_update_state).
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
QUIC in single-stream mode could be used with a protocol where the
server writes first or the client writes first. This determines
whether the single stream would be client or server initiated,
which affects the stream ID allocated to the stream. We should support
both client-sends-first and server-sends-first application protocols.
Thus, defer default XSO creation until the point in time at which
we know whether a client-first or server-first application protocol
is being used. We do this by taking whether SSL_read() or SSL_write()
is called first as a cue.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
We switch to instantiating the QUIC_CHANNEL up front at QCSO
instantiation time. This creates the QUIC_STREAM_MAP early and makes it
easy for us to allocate streams prior to connection initiation. The role
(client or server) is determined at QCSO allocation time and cannot be
changed.
SSL_set_connect/accept_state() are still modelled but their usage must
be consistent with the chosen SSL_METHOD which dictates which role is
being used.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
In QUIC, we have an architectural need (in future, when we implement
0-RTT, etc.) to be able to create streams before we start connecting.
This requires we allocate a stream, including a stream ID, after
creating a QCSO but prior to connecting. However stream IDs are
dependent on whether the endpoint is in the client or server role,
therefore we must know whether we are going to be a client or server
before any pre-connection streams are created. Moreover, the originally
defined QUIC_client_method() and QUIC_server_method() functions heavily
implied the original plan was to have different SSL_METHODs for clients
and servers. Up until now we had been relying on
SSL_set_connect/accept_state() instead.
Solve these problems by basing client/server identity on whether
QUIC_server_method() is used (in future, when we support servers). This
ensures that once a QCSO is created its client/server identity are fixed
and cannot change, allowing pre-connection stream IDs, etc. to be
allocated.
Client/server uncertainty was the primary reason why QUIC_CHANNEL
creation was deferred until connection time up until now, so this
enables further refactoring to facilitate eager allocation of the
QUIC_CHANNEL at QCSO allocation time. This is important as allocating a
stream including its write buffers is hard without having the
QUIC_CHANNEL (which owns the QUIC_STREAM_MAP) in existence.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
We now refactor the interface between ssl_lib.c frontend functions and
the QUIC API Personality Layer so that the respective functions
comprising the interface use SSL object pointers rather than raw
QUIC_CONNECTION pointers. This is in preparation for stream support
since once streams are supported, calls to e.g. ossl_quic_write() may be
made on a QUIC_CONNECTION or a QUIC_XSO (that is, a stream object). Thus
we take a uniform approach across all functions comprising the interface
between the ssl_lib.c frontend and the QUIC API Personality Layer of
using SSL pointers always. This provides a uniform approach and
ensures that any function of the API personality layer can be easily
adapted to support being called on a stream object in the future.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
The QUIC_XSO (external stream object) is to a QUIC stream what a
QUIC_CONNECTION is to a QUIC connection. Both are SSL objects. The
QUIC_CONNECTION type is the internal representation of a QUIC connection
SSL object (QCSO) and the QUIC_XSO type is the internal representation
of a QUIC stream SSL object (QSSO) type. The name QUIC_XSO has been
chosen to be distinct from the existing QUIC_STREAM type which is our
existing internal stream type. QUIC_XSO is to a QUIC_STREAM what
QUIC_CONNECTION is to a QUIC_CHANNEL; in other words, QUIC_CONNECTION
and QUIC_XSO objects form part of the API personality layer, whereas
QUIC_CHANNEL and QUIC_STREAM objects form part of the QUIC core and are
distinct from the API personality layer.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
Uniform changes to all dispatch functions to use the new dispatch
functionality follows this commit. Separated into a core commit
and a commit containing the uniform pattern (monotonous) changes
for ease of review.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20765)
