"Andy Green (林安廸)"
andy at warmcat.com
Wed Apr 10 07:20:39 CEST 2013
On 10/04/13 13:09, the mail apparently from Gregory Junker included:
> I've only been paying vague attention to the list and commit logs, so my
> apologies if this has already been addressed.
> I need to expand the user receive buffer to A LOT more than 4096. For
> instance, 8 or 16 MB would be good for us.
> Why? I know that WebSockets gets most of its use in the JSON and XML
> world, but I am pushing geometry data to WebGL clients (which is why
> WebSockets and not straight TCP/IP sockets), and am also using LWS for
> the C++ clients as well.
> Right now the buffering of 4K at a time for a 13MB texture is killing
> the app performance, and I need to be able to send this out in one (or
> two) shot(s). The problem I see in my version of the code (old at this
> point) is that MAX_USER_RX_BUFFER is used to create a stack allocation,
> so it's probably not going to work so well simply to change
> MAX_USER_RX_BUFFER to 16*1024*1024.
> Has there been any changes in the current code (either stable or HEAD)
> that would make this easier, or are there any other suggestions that
> might work well for this?
Yeah it became configurable per-protocol in the protocol struct.
However to send large things, you need to also take care about the FIN
and CONTINUATION management stuff (you can see examples of how to do it
in the sources for the fraggle test app).
More information about the Libwebsockets