Function esp_idf_svc::hal::sys::mbedtls_ssl_conf_renegotiation_enforced

pub unsafe extern "C" fn mbedtls_ssl_conf_renegotiation_enforced(
    conf: *mut mbedtls_ssl_config,
    max_records: i32,
)

\brief Enforce renegotiation requests. (Default: enforced, max_records = 16)

            When we request a renegotiation, the peer can comply or
            ignore the request. This function allows us to decide
            whether to enforce our renegotiation requests by closing
            the connection if the peer doesn't comply.

            However, records could already be in transit from the peer
            when the request is emitted. In order to increase
            reliability, we can accept a number of records before the
            expected handshake records.

            The optimal value is highly dependent on the specific usage
            scenario.

\note With DTLS and server-initiated renegotiation, the HelloRequest is retransmitted every time mbedtls_ssl_read() times out or receives Application Data, until: - max_records records have beens seen, if it is >= 0, or - the number of retransmits that would happen during an actual handshake has been reached. Please remember the request might be lost a few times if you consider setting max_records to a really low value.

\warning On client, the grace period can only happen during mbedtls_ssl_read(), as opposed to mbedtls_ssl_write() and mbedtls_ssl_renegotiate() which always behave as if max_record was 0. The reason is, if we receive application data from the server, we need a place to write it, which only happens during mbedtls_ssl_read().

\param conf SSL configuration \param max_records Use MBEDTLS_SSL_RENEGOTIATION_NOT_ENFORCED if you don’t want to enforce renegotiation, or a non-negative value to enforce it but allow for a grace period of max_records records.