<div dir="ltr"><div class="gmail_extra">Hello Andy,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Until July 7th, I haven't yet any blocage but looking just a bit in lws code, I saw that in case context is destroyed by mistake (I don't see why) it could reach to infinite loop as it returns 1 instead of -1 in lws-plat-unix.c:</div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="" style="white-space:pre">  </span>if (!context || !context->vhost_list)<br><span class="" style="white-space:pre">                </span>return 1;</blockquote>
<div class="gmail_extra">Best regards,</div><div class="gmail_extra">Thomas</div><div class="gmail_extra"><br></div><br><div class="gmail_quote">2016-07-07 12:33 GMT+02:00 Thomas Spitz <span dir="ltr"><<a href="mailto:thomas.spitz@hestia-france.com" target="_blank">thomas.spitz@hestia-france.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Hello Andy,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Can you get these CLOSE_WAIT connections using the test apps?  I try to<br></span><span style="font-size:12.8px">make it happen here both with lwsws + libuv and the poll() test server<br></span><span style="font-size:12.8px">+ client + browser, but he always closes cleanly.  TIME_WAIT is<br></span><span style="font-size:12.8px">expected and clears up after 60 also as expected (the connection is<br></span><span style="font-size:12.8px">gone).</span></blockquote></span><div class="gmail_extra">Even with  my app, it is very hard to make it happens (once it took months and most of the time weeks...). I supposed it is due to special phone / tab app usage but I can't reproduce the problem by myself. </div><div class="gmail_extra">It occured twice on an embedded device opened to the web to every one. I am going to put further log info on this embeded device opened to the web and expect to see further info...</div><span class=""><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Is it that this symptom with the spinning creates the conditions where<br></span><span style="font-size:12.8px">the CLOSE_WAIT appears?</span></blockquote></span><div class="gmail_extra"><span style="font-size:12.8px">I think so. I also have ESTABLISHED connections whereas nobody is connected anymore...</span></div><div class="gmail_extra"><br></div><div class="gmail_extra">I will let you know at the next spinning blocage...</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best regards,</div><div class="gmail_extra">Thomas</div><div><div class="h5"><div class="gmail_extra"><br></div><div class="gmail_quote">2016-07-07 2:19 GMT+02:00 Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On Wed, 2016-07-06 at 18:22 +0200, Thomas Spitz wrote:<br>
> > No, by default tcp doesn't randomly send things.  You can use "tcp<br>
> > keepalives" to make it randomly send things at specified intervals<br>
> > as probes for a dead link.  Otherwise if you're not sending<br>
> > anything either at application layer it can go on forever believing<br>
> > it's just idle.  (In ssl case that might do its own housekeeping on<br>
> > the link, I'm not sure of the conditions.)<br>
> > This is talking about situations where the physical link disappears<br>
> > without notification, eg phone runs out of battery.  Just closing<br>
> > the connection with the link still valid should be nice and clean.<br>
<br>
> In fact the server send the time to each client every minute (so this<br>
> is a kind of keep alive). On the client side, if it doesn't receive a<br>
> messsage before 1min and 5s then it closes the connection as well. Do<br>
> the server has to do something in case it sends the new time to a<br>
> "dead connection" (I thought TCP would close the connection for<br>
> me...)?<br>
<br>
</span>If you're periodically tring to pass traffic, that should allow you to<br>
know if anything has gone wrong.  Closing the connection in LWS should<br>
be enough then.<br>
<span><br>
> > >I also made a test program that progressively increase the number<br>
> > of<br>
> > >simultenous client connections and all connections are stopped<br>
> > (after 1<br>
> > >minute of TIME_WAIT in some case)<br>
> ><br>
> > TIME_WAIT is okay.<br>
> ><br>
> > CLOSE_WAIT isn't okay.  I'll check this out tomorrow.<br>
<br>
</span>Can you get these CLOSE_WAIT connections using the test apps?  I try to<br>
make it happen here both with lwsws + libuv and the poll() test server<br>
+ client + browser, but he always closes cleanly.  TIME_WAIT is<br>
expected and clears up after 60 also as expected (the connection is<br>
gone).<br>
<br>
Please try the test apps for this from your side.<br>
<br>
Is it that this symptom with the spinning creates the conditions where<br>
the CLOSE_WAIT appears?<br>
<br>
It's very helpful if you can reduce this to something both of us can<br>
reproduce with the test apps, perhaps with a little patch to align with<br>
what your code does.<br>
<span><font color="#888888"><br>
-Andy<br>
<br>
<br>
</font></span></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div></div>