Lines Matching +full:in +full:- +full:application

4 In thread assisted mode, we create a background thread to ensure that periodic
5 QUIC processing is handled in a timely fashion regardless of whether an
6 application is frequently calling (or blocked in) SSL API I/O functions.
12 per-connection mutex for the duration of any public API call which we forward to
15 the locking to every single public HL-related API call.
22     /* application mutates x */
31 - **1. Application-controlled explicit locking.**
34   An application performing a single HL API call, or a sequence of related HL
36   application is not required to take the lock prior to connection
41   application side, although since most HL API calls made by an application
46   Pro: Most “robust” solution in terms of HL evolution.
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
59     except servicing the crypto stream, or any other events we may define in
62   - This is rather hacky but should work adequately. When using TLS 1.3
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
74       handshake completion (which would in itself be highly unusual), we simply
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
95   by specially implementing synchronised forwarders, but doing this in the
101   we don't implement for thread assisted post-handshake QUIC, we would