Lines Matching +full:background +full:- +full:layer

4 In thread assisted mode, we create a background thread to ensure that periodic
8 Part of the QUIC state comprises the TLS handshake layer. However, synchronising
11 At first glance, one could synchronise handshake layer public APIs by locking a
12 per-connection mutex for the duration of any public API call which we forward to
13 the handshake layer. Since we forward a very large number of APIs to the
14 handshake layer, this would require a very large number of code changes to add
15 the locking to every single public HL-related API call.
31 - **1. Application-controlled explicit locking.**
50 - **2. Handshake layer always belongs to the application thread.**
52   In this model, the handshake layer “belongs” to the application thread
55   - `SSL_tick()` (or another I/O function) called by the application fully
58   - The assist thread performs a reduced tick operation which does everything
60     future which would be processed by the handshake layer.
62   - This is rather hacky but should work adequately. When using TLS 1.3
63     as the handshake layer, the only thing we actually need to worry about
66     post-handshake messages used by TLS 1.3 aren't relevant to QUIC TLS:
68     - Post-handshake authentication is not allowed;
70     - Key update uses a separate, QUIC-specific method;
72     - TLS alerts are signalled via `CONNECTION_CLOSE` frames rather than the TLS
85 - **3. Handshake layer belongs to the assist thread after connection begins.**
87   In this model, the application may make handshake layer calls freely prior to
94   connection. We could selectively enable some important post-handshake HL calls
101   we don't implement for thread assisted post-handshake QUIC, we would