<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 25, 2017 at 5:11 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On April 26, 2017 6:02:25 AM GMT+08:00, Brenton Rothchild <<a href="mailto:brentonr@dorm.org">brentonr@dorm.org</a>> wrote:<br>
>Hi,<br>
><br>
>I've tried looking for examples on this list or in documentation, but<br>
>so<br>
>far I cannot find a good answer to the following question:<br>
><br>
>Can someone give a good example (simple, single threaded) where the<br>
>client<br>
>sends a closing<br>
>reason to a WS server (any kind) with a reason using<br>
>lws_close_reason()?<br>
><br>
>I am finding that with v2.1.0 and v2.2.1, I get sporadic results where<br>
>sometimes callling lws_close_reason() and returning -1 from the<br>
>callback<br>
>will not actually send the close message payload and the socket is<br>
>never<br>
>closed (as viewed using tcpdump).<br>
><br>
>I'm fairly positive I'm simply not using the library correctly, and<br>
>would<br>
>very much appreciate a<br>
>concrete example where the client is closing the connection with a<br>
>close<br>
>reason.<br>
<br>
</span>Run libwebsockets-test-server, visit <a href="http://localhost:7681" rel="noreferrer" target="_blank">http://localhost:7681</a>, go to the 'close testing' tab and use the open and close buttons there.  The sources are in ./test-server.<br>
<br>
There are no guarantees the peer hasn't already closed the tcp connection, and it's legal for either side to close the connection with no warning at any time.<br>
<br>
If there's a gap in the close logic under some circumstances, you'll need to capture more info on how to reproduce.<br>
<br>
-Andy<br>
<br>
>Thanks!<br>
>-Brenton<br>
</blockquote></div><br></div><div class="gmail_extra">Andy, thanks for the reply.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I found the problem with my client. Although the documentation states returning -1 from the callback in any case will cause the connection to close,</div><div class="gmail_extra">I found I was hitting a case where the return value does not cause this action.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The source of this was in lws-plat-unix.c, function _lws_plat_service_tsi() when calling with reason LWS_CALLBACK_GET_THREAD_ID where</div><div class="gmail_extra">the return value is not treated as a possible error at that point.</div><div class="gmail_extra"><br></div><div class="gmail_extra">(This was contrary to the similar call to the callback with reason LWS_CALLBACK_GET_THREAD_ID in pollfd.c, function _lws_change_pollfd()</div><div class="gmail_extra">where a thread ID of -1 does in fact trigger closing the connection.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I adjusted my callback to return -1 when the reason value was any different value, and it worked great.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I assume again my fault is not using the library correctly as a whole, but this got me past my current issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks again for your help,</div><div class="gmail_extra">-Brenton</div><div class="gmail_extra"><br></div></div>