[Libwebsockets] [libwebsockets] max frame size / rx buffer send limitation (#89)
"Andy Green (林安廸)"
andy at warmcat.com
Sun Mar 23 05:09:25 CET 2014
On 23/03/14 11:40, the mail apparently from "Andy Green (林安廸)" included:
> On 23/03/14 11:33, the mail apparently from gaby64 included:
>> you missed my edit:
>> it still wont send with SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER set
>> stuck with SSL_ERROR_WANT_WRITE
> Yes github didn't send an email for your edit.
>> i dont understand the websocket implementation enough to figure out
>> how to fix this,
>> i assumed the implementation should handle message fragmentation for
>> atomic messages of any size.
> Message fragmentation is something else, see the fraggle test app for
> how to do it. That will make this problem go away.
> But we have already seen many people are not able to cope with the idea
> of explicit message fragmentation at websocket layer, they just want
> "fire and forget" for any size buffer.
> What we have with the malloc truncation handling is OK for them, except
> as you found for this SSL quirk.
> WANT_WRITE should be okay, we have been through this a long time ago and
> it is correctly handled normally now.
> Let me continue with what I had in mind and I'll also keep an eye out
> for WANT_WRITE trouble.
Please try what I just pushed.
- keeps the truncation buffer... if you needed it once on a connection
you probably need it again. It reallocates if needed to grow and frees
at the close. If your user code is good and doesn't need it, you don't
pay the price of the mallocs.
- use SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER on client and server SSL
- fix SSL_WANT_* there to use the truncation buffer to get retry
semantics by going around the service loop again nicely (it will also
work OK for multiple SSL_WANT_* attempts)
>> Reply to this email directly or view it on GitHub:
More information about the Libwebsockets