[Libwebsockets] problems with big dynamic content

Andy Green andy at warmcat.com
Fri Jun 22 07:10:44 CEST 2018



On June 22, 2018 12:57:34 PM GMT+08:00, Per Bothner <per at bothner.com> wrote:
>On 06/21/2018 08:38 PM, Andy Green wrote:
>> 
>> 
>> On 06/22/2018 09:41 AM, Andy Green wrote:
>> 
>>>> Both of these messages are from domterm, not the lws library.
>>>
>>> To speed things up I will try to reproduce it... I just need to open
>it in your pattern with default build options, is it?
>
>FWIW I have various changes I haven't checked in.  The triggering issue
>is this issue:
>
>https://github.com/PerBothner/DomTerm/issues/43
>
>(Electron 2.0.2 takes a long time opening subsequent windows,
>at least started up with a fresh electron command.  So I've been
>trying to get things working with the same electron command -
>but then we run into the problem currently being discussed.)
>
>I'll can try to check in at least those changes I'm reasonably sure
>about - though if you can reproduce the problem that may be less
>important.

I don't think it's going to be relevant to whatever the root cause is.

>> I can reproduce it, but as you say lws doesn't feel anyone trying to
>touch it when the attempt after the delay is made.
>> 
>> What seems to be happening is the client doesn't understand that lws
>timed out and closed the connections and tries to still use the dead
>sockets
>> 
>> tcp      314      0 127.0.0.1:38015         127.0.0.1:54696
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54736
>CLOSE_WAIT
>> tcp      315      0 127.0.0.1:38015         127.0.0.1:54706
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54726
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54728
>CLOSE_WAIT
>> tcp      312      0 127.0.0.1:38015         127.0.0.1:54700
>CLOSE_WAIT
>> tcp      315      0 127.0.0.1:38015         127.0.0.1:54704
>CLOSE_WAIT
>> tcp      310      0 127.0.0.1:38015         127.0.0.1:54698
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54730
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54732
>CLOSE_WAIT
>> tcp        1      0 127.0.0.1:38015         127.0.0.1:54734
>CLOSE_WAIT
>> tcp      313      0 127.0.0.1:38015         127.0.0.1:54702
>CLOSE_WAIT
>> 
>> Looking with tcpdump -ilo, if I close the "waiting..." window,
>immediately the lws part receives a bunch of new connections on his
>listen socket.
>> 
>> Clearly, the client socket received the FIN from when lws timed to
>sockets out, because the socket in shown as in CLOSE_WAIT... it means
>one peer closed it with FIN but the other peer has not responded and
>close()'d the socket on his side.
>> 
>> If the client is chrome, I dunno why that should do that.  It
>certainly knows if lws closes a socket normally.
>
>The failure happens with --firefox as well.  Also --electron (with my
>un-checked-in
>fixes to re-use the Electron application). Also both --chrome and
>--chrome-app (chrome in -app mode).
>Also, regardless whether the new terminal is started using the menu,
>with C-S-N (which is hijacked
>in a regular browser but works in --electron or --chrome-app
>front-ends), or with the bin/domterm command.

Are you forking or vforking after the lws connection was established?  Maybe what happens is the fork duplicates the accepted socket fd in the child and that makes trouble?

-Andy



More information about the Libwebsockets mailing list