ch->cc_method, ch->cc_data)) == NULL)
goto err;
-
if (!ossl_quic_stream_map_init(&ch->qsm, get_stream_limit, ch,
&ch->max_streams_bidi_rxfc,
&ch->max_streams_uni_rxfc,
* if transmission of application data is going in only one direction and
* nothing else is happening with the connection. However, since the peer
* cannot initiate a subsequent (spontaneous) TXKU until its prior
- * (spontaneous or solicited) TXKU has completed - meaning that that prior
+ * (spontaneous or solicited) TXKU has completed - meaning that prior
* TXKU's trigger packet (or subsequent packet) has been acknowledged, this
* can lead to very long times before a TXKU is considered 'completed'.
* Optimise this by forcing ACK generation after triggering TXKU.
{
return ossl_qrx_get_key_epoch(ch->qrx);
}
+
+int ossl_quic_channel_trigger_txku(QUIC_CHANNEL *ch)
+{
+ if (!txku_allowed(ch))
+ return 0;
+
+ ch->ku_locally_initiated = 1;
+ ch_trigger_txku(ch);
+ return 1;
+}
static void qrx_key_update_initiated(OSSL_QRX *qrx, QUIC_PN pn)
{
if (!ossl_qrl_enc_level_set_key_update(&qrx->el_set, QUIC_ENC_LEVEL_1RTT))
- /* Returns 0 if already in RXKU, so we don't call callback again. */
+ /* We are already in RXKU, so we don't call the callback again. */
return;
if (qrx->key_update_cb != NULL)