Mongoose not always reading all data in TLS buffer #2792
-
Hi, Thanks! Mongoose version: 7.14 release Log ending from working transfer:
Log ending from failed transfer:
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 5 replies
-
You are exhausting the receive buffer, hence MG_MAX_RECV_SIZE |
Beta Was this translation helpful? Give feedback.
-
Thanks for your reply. I was under the impression that we handle the data we get by consuming the c->recv on MV_EV_READ. The buffer that runs out is in c->rtls. Could this be related to #2668? |
Beta Was this translation helpful? Give feedback.
-
No, 2668 is a different claim. Your issue seems to be the same as the one I linked to. |
Beta Was this translation helpful? Give feedback.
-
I have now logged what seems to happen when it starts to fail.
As you can see mongoose starts reading more data from the socket than it's decrypting and passing to the callback for consumption. |
Beta Was this translation helpful? Give feedback.
-
Yes, throttling the socket reads would work:
Also, increasing the c->recv would also work in my case:
A third way which would also make it work is the already rejected suggestion by @tubular-rheostat in #2668. |
Beta Was this translation helpful? Give feedback.
-
Something like this maybe, it will throttle reads from the socket as long as there is decrypted data available for processing.
|
Beta Was this translation helpful? Give feedback.
-
This is same as above but more integrated. It de-couples the MG_IO_SIZE from TLS record size and makes sure to fill c->recv similar to non TLS connections making them look and behave the same from the callback point of view. Also c->rtls is used very lightly compared to reaching MG_MAX_RECV_SIZE before. Now it will be c->recv generating OOM just like it would on non TLS connections. Please let me know if you are interested at all. Thanks
|
Beta Was this translation helpful? Give feedback.
AFAI'm concerned, and based on prior resolution of corner cases, and the fact that Mongoose not only runs over sockets nor OSs, no, we are not interested in your modifications. AFAI'm concerned, the answer is the one given and the fix to your issue is the one provided, coincident with what can be read in our docs.
Thank you.