[Libwebsockets] how is partial write handled

"Andy Green (林安廸)" andy at warmcat.com
Fri Oct 18 01:38:14 CEST 2013

On 18/10/13 06:59, the mail apparently from LANGLOIS Olivier PIS -EXT
> Andy,
> I think that I understand a little bit better what happens.
> Remember when I said the way you describe SO_SNDBUF sounded more like
> I did remember that the library also disable Nagle with TCP_NODELAY.
> In a LAN, what this combination will do is make a TCP connection
> approximate a UDP socket in a LAN because RTT is very low. On the
> Internet with RTT > 200 ms and with an intensive bandwidth app (ie:
> video streaming on websockets:
> http://phoboslab.org/log/2013/09/html5-live-video-streaming-via-websockets
> ), we will get partial writes even with appropriate SO_SNDBUF and

I don't really like the stability of my explanations for this problem... 
the fact it keeps coming up and I'm having to use words like "belief" 
probably means something is wrong.  However it remains true I can't 
reproduce the issue with the current setup.

I started on a patch which will either handle truncated send internally 
using a malloc'd buffer for the missing part, and / or let the user code 
know accurately that less of his buffer was consumed than he sent.  I'll 
provide this on a test branch later... I can't reproduce the situation 
to test it.

>>> Can I use your library if I cannot predict ahead of time the
>>> length of my messages because their length is variable?
>> Yes... websockets itself defines fragments for that purpose.
> I have read the readme file describing fragments. My understanding
> was that this was supported for the receiving side. Does the library
> support fragments on the sending side as well?

Yes, have a look at the fraggle test app, it defines a test client and 
server that tests fragmentation reliability on both sides for lws by 
spamming random size messages made from a random number of fragments of 
random size between the client and server.

The code for that shows how to deal with fragments.


> ________________________________ CONFIDENTIALITY : This e-mail and
> any attachments are confidential and may be privileged. If you are
> not a named recipient, please notify the sender immediately and do
> not disclose the contents to another person, use it for any purpose
> or store or copy the information in any medium.

More information about the Libwebsockets mailing list