<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style='font-family: Arial,Helvetica,sans-serif'>
<p> </p>
<p> </p>
<div> </div>
<p>Em 18/08/2014 08:25, Andy Green escreveu:</p>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<pre>On 18 August 2014 19:06:42 GMT+08:00, <a href="mailto:nil100@ig.com.br">nil100@ig.com.br</a>wrote:</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Em 17/08/2014 21:56, Andy Green escreveu:
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">On 18 August 2014 07:34:47 GMT+08:00, <a href="mailto:nil100@ig.com.brwrote:">nil100@ig.com.brwrote:</a>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Hello everybody, I'm using the library and in my case I want to</blockquote>
</blockquote>
handle truncated send myself but I ran into a situation. Linux's send function is returning -2 which in turn is causing libwebsockets to disregard my wish to handle truncated sends and consequently causes an assert failure later on.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">I'm not sure what your plan is for dealing with it in user code. I'm usually sending a large amount of data at a time and so I want to</blockquote>
know when the pipe chokes and how many truncated sends it takes to completely send my whole chunk.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Everything is happening in file output.c at line 130 which is the</blockquote>
</blockquote>
return from linux's native send (I'm not using SSL so lws_ssl_capable_write is actually lws_ssl_capable_write_no_ssl). Now when this returns LWS_SSL_CAPABLE_MORE_SERVICE (value -2) then the value of variable "n"
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">So looking at the code, the actual send() didn't send anything just</blockquote>
came back with -EAGAIN or similar. Then that function translates that to a generic "I didn't send anything because I would have blocked" enum return you mentioned.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">is set to 0 which causes the condition at line 172 (n &&</blockquote>
</blockquote>
wsi->u.ws.clean_buffer) to be false and continue execution as if
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Yes I see.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">libwebsockets was handling truncates and consequent calls to fail</blockquote>
</blockquote>
assertion at line 112.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">I don't see why it fails that assertion though, did you understand</blockquote>
why during your debugging? Not having sent anything and buffer the whole thing should have been okay.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">So here the code enters the condition at line 107-110 because</blockquote>
wsi->truncated_send_len && buf > (wsi->truncated_send_malloc + wsi->truncated_send_len + wsi->truncated_send_offset). Now, the library was not handling truncated sends in the first place (I configured it not to)but it erroneously started handling after send returned an error</blockquote>
<pre>I dunno what this "configured it not to" thing is.  I don't see anything like that in the code (maybe I missed it).</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">and since I don't expect the library to do that I call libwebsocket_write again which makes the library believe I'm trying to send new data when in fact I'm sending the rest of the data too.</blockquote>
<pre>Yes -- that's exactly what's happening.

So if you were OK with the lws buffering (for sake of argument) you just need to open your sending loop up to the service loop.

Because the service loop is the only guy who can regulate flushing the partial buffer without blocking.

Actually if you want to handle it, you have the same issue.  If you just sit there spamming you will also block, which makes your code only useful for one connection or one socket fd at a time.</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">I'm a new libwebsockets user and wasn't sure how to proceed in</blockquote>
</blockquote>
getting this fixed.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">There seems to be two separate issues here, one is you don't want it</blockquote>
to buffer things if nothing got sent, and the other is you get an assert firing when it does.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Correct. I don't want it to buffer things and the assert is firing</blockquote>
because the library started handling things without me wanting it to.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">If you remove the n && from line 172 it might do something towards</blockquote>
what you want. But I am not sure if that leaves whatever blew the assert just waiting to blow the assert another time.
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">What blew the assert was wsi->truncated_send_len not being 0 when it</blockquote>
should have been. Sorry for the bad formatting. My webmail is crap.</blockquote>
<pre>Yeah it's pretty broken but it's fine as a text mode reply actually so no worries.

I think it's maybe a bit more complicated than you are thinking.

1) What's actually sent on the wire may include protocol prepending for websocket.  That's tricky to account for but not impossible.  So the stuff at the send() is a different length than what you sent in your user callback.

2) If there's an extension like compression, which is commonly negotiated by browsers, what gets sent on the wire - to the send() - is totally unrelated in size or content to what you are sending from your user code.

If you heard he managed to send 1KByte of the compressed version, that's completely worthless information to you because you don't know how big the remainder of the compressed version is or what it was, from the user code with the uncompressed buffer.

These reasons are why we ended up with in-lws transparent buffering, because especially the second one has no real solution otherwise.

-Andy</pre>
<blockquote type="cite" style="padding-left:5px; border-left:#1010ff 2px solid; margin-left:5px">Cheers, Nilson N. da Silva</blockquote>
</blockquote>
<p> </p>
<p>Yes... I understand that there's more to sending over websockets than just wiring to a socket and for that libwebsockets is very good (ofc it's more than just websockets and thanks for creating it BTW).</p>
<p>So what I originally intended to do was something like the following:</p>
<p>int m = 0;<br /> size_t len = mybuffer_length;<br /> unsigned char *msg = mybuffer + LWS_SEND_BUFFER_PRE_PADDING;<br /> do {<br />    int l = len - m;<br />    unsigned char *p = msg + m;<br />    m += libwebsocket_write(wsi, p, l, LWS_WRITE_TEXT);<br />    /*<br />        do something so that I know send was truncated and tell me<br />        how many iterations it took to complete the whole chunk<br />        and how much was sent on each<br />    */<br />} while(m < len);</p>
<p>Now with the help Roger's comment if I have "if (lws_send_pipe_choked(wsi)) continue;" inside this loop I get rid of the assertion failure, but it seems libwebsockets is still handling partials (I can see it the lib's logs).</p>
<p>Thank you guys for the discussion.</p>
<p>Cheers,</p>
<p>Nilson N. da Silva</p>
</body></html>