[Libwebsockets] Limits on libwebsocket_write sizes?
"Andy Green (林安廸)"
andy at warmcat.com
Sun Sep 22 01:23:52 CEST 2013
On 22/09/13 02:17, the mail apparently from Michael Ihde included:
> I'm using libwebsocket in a project and with both the HEAD and the 1.22
> tag I've seen various problems when I make a write call and the buffer
> exceeds a certain size.
> Sometimes I get messages like "[1379778593:9959] ERR: Unable to spill
> ext 29572 vs 16384", and sometimes I get segmentation faults.
> My buffer includes the proper pre-padding and post-padding. Simply
> making my buffer smaller the problems go away.
> I'm assuming none of this is expected, so I'm planning on trying to find
> and fix the bug. But I thought it might be useful to check with other
> users first.
If I understood what's going on in your case, it is expected.
There's a distance between the state on the socket where it signals it
can send more atomically (ie, there is buffer space available kernelside
to take the data), and some open-ended commitment to take any amount of
When the websocket connection is made, we tell the socket to only signal
us for send when there's enough space to send
wsi->protocol.rx_buffer_size on the connection.
By default, that's 4096 (if you leave rx_buffer_size at 0). The
kernel's at liberty to have a larger buffer.
In your example the kernel had 16384 space but a extension wanted to
send 29572 atomically, it couldn't and lws doesn't have a way to recover
Actually websockets has arrangements for sending any size message in
fragments. The reason you're getting problems is likely because you're
trying to send things in one lump.
Take a look at the fraggle test and and README.coding for examples of
how to break larger messages into fragments at websocket layer (they
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets