<div dir="ltr"><div class="gmail_default" style="font-size:small">I have done this on my side.</div><div class="gmail_default" style="font-size:small">The client sends "I want go close", the server responds "Ok" and knows that client is going away.</div><div class="gmail_default" style="font-size:small">I request a WRITE to it and when I get lws notification, I return -1 which kills the connection.</div><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 21, 2019 at 9:20 AM Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 5/21/19 2:17 PM, Mateusz Stępień wrote:<br>
> On 5/21/19 2:51 PM, Andy Green wrote:<br>
>  > There's also this api<br>
>  ><br>
>  > <br>
> <a href="https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-timeout-timer.h#n79-105" rel="noreferrer" target="_blank">https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-timeout-timer.h#n79-105</a> <br>
> <br>
> <br>
> That function would probably help, when I could get to the point that <br>
> Close message is already sent and I'm waiting for ACK from the server.<br>
> <br>
>> You can never guarantee you can either send the close frame at all or <br>
>> when you can send it.<br>
> <br>
> That can be said about every packet going out from the client. However <br>
> the issue is not about flaky connection or sth like that. It is that <br>
> that I cannot send Close message like I can send any other one. Right <br>
<br>
ws close frame is handled by lws internally, yes.<br>
<br>
> now if I want to close the connection with a close message and a chosen <br>
> reason, I need to wait for the CLIENT_RECEIVE callback and because I <br>
<br>
No... you just need to let know lws you want to close that wsi... the <br>
api I linked to will allow you to do that from any callback.<br>
<br>
> cannot force it, I am at the mercy of server, which can send another <br>
> message in 5 seconds, or in 20 minutes, or never. Please note, that I'm <br>
> talking about time between setting "completed" flag and receiving <br>
> CLIENT_RECEIVE callback.<br>
> <br>
>> If it can be sent within a timeout period of a few seconds, it will be <br>
>> sent.  But anything can crash or run out of battery or lose connection <br>
>> at any time without ceremony.  So you shouldn't assume this can be <br>
>> made a certainty... CLOSE callback to learn the socket closed is much <br>
>> more certain.<br>
> <br>
> I'm sorry, but I don't see the relevance to my issue. At the CLOSE <br>
> callback there's nothing I can do to send the Close message.<br>
<br>
You seem to be setting flags and stuff like you're going to rely on it. <br>
It spells it out in RFC6455, you can't rely on the CLOSE frames coming.<br>
<br>
-Andy<br>
_______________________________________________<br>
Libwebsockets mailing list<br>
<a href="mailto:Libwebsockets@ml.libwebsockets.org" target="_blank">Libwebsockets@ml.libwebsockets.org</a><br>
<a href="https://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">https://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
</blockquote></div>