Make DTLS fragment stay within MTU size range #1156
Conversation
| // don't want to send a Close Alert to the peer, so just don't call | ||
| // SendPendingOutgoingDTLSData(). | ||
| // NOTE: We need to reset the SSL instance so we need to "shutdown" it, but we | ||
| // don't want to send a Close Alert to the peer. However this is gonna happen. |
There was a problem hiding this comment.
If this is shown to be a problem, perhaps I can write a failing test verifying the behavior. Then do some work to try to avoid sending the Close Alert and pass the test.
There was a problem hiding this comment.
Sure, could you do it once this PR is merged and try that in flatbuffers branch?
NOTE: the problem I see is that we DO WANT to send DTLS Close Alert in most of the cases, and there is just one case in which we do not want to send it (this one). So no idea this can be done. Even if we set a this->allowOutgoingDtlsCloseAlert = true flag before that scenario and set it to false immediately after ignoring such a DTLS Close Alert, the problem is that this is driven by a OpenSSL callback that probably runs asynchronously.
…se it causes a memory leak - Fixes #1340 - Reopents #1100 ### Details As perfectly documented in issue #1340, there is a leak due to the usage of `BIO_set_callback_ex()` whose fix is unclear and, anyway, I'm pretty sure that the usage of that OpenSSL utility makes the performance worse. As a workaround for issue #1100 (which now must be reopened), in order to avoid "DTLS fragment exceeds MTU size if the certificate is large", users should not pass a big DTLS certificate to mediasoup.
…se it causes a memory leak (#1342)
Details
BIO_set_callback_excallback as other projects as done.WebRtcTransport.cppinOnDtlsTransportSendData()method: