[Libwebsockets] Server stops reacting after some time
ofer at whitenblue.com
Tue May 10 09:02:18 CEST 2016
Sorry for lack of the data,
Here is more info: I'm working on windows 10, and the browser is chrome, and
I use version 1.7.3
I run the server in visual studio and see no exception.
message (64k~), and then stuck. No other indications.
I do see a lot of message "lws_rx_sm: doing draining flow" in the server
I do see the negotiation on extensions and permessage-deflate selected.
I did as you suggested and set info.extensions = NULL
And from the little I tested it seems to work (I get small messages back of
4k, and no draining flow in console).
1. Why is that ?
2. Currently I don't use SSL, but I will need to do. Can the issue return
when SSL enabled?
From: Andy Green [mailto:andy at warmcat.com]
Sent: Tuesday, May 10, 2016 9:29 AM
To: Ofer Chesler <ofer at whitenblue.com>; libwebsockets at ml.libwebsockets.org
Subject: Re: [Libwebsockets] Server stops reacting after some time
On 05/10/2016 02:17 PM, Andy Green wrote:
> On 05/10/2016 02:06 PM, Ofer Chesler wrote:
>> I'm writing a websocket server which interacts with the browser.
>> In the browser I garb audio (Web Audio API), sends it to the server,
>> which is doing some manipulations, and sends it back to the browser.
>> In the browser I work with 512 samples each time and 2 channels,
>> which means I send each time around 512 (samples) * 4 (each one is
>> float) * 2
>> (channels) = 4096 bytes
>> Assuming the audio have 44.1Khz sample rate, I need to send (and
>> receive) around 70 times a second.
> I see.
>> I wrote my server based on the test-server echo sample , and it
>> starts working, until at a certain point is suddenly stops. (the
>> browser tries to send more data but the server refuses to accept it).
>> Any idea what might be the issue, or how can I debug it?
> Well... there is almost no information to be able to guess the problem.
> 1) What version of lws is this? What platform?
> see what it thinks has happened.
> 3) On the server side, the first question would be 'has it crashed'?
> If it has crashed, maybe not with an abort, it can be interesting to
> run it under valgrind or gdb.
> 4) Enable cmake DEBUG mode cmake .. -DCMAKE_BUILD_TYPE=DEBUG and
> increase the logging using -d79 or so.
> 5) Find out what the server feels has happened... it feels the client
> connection closed? Who closed it? It's not closed? The server
> doesn't see any more RX? Or he can't do any more TX?
> 6) If permessage-deflate extension is negotiated, see if it's related
> to that by disabling it (info.extensions = NULL).
> 7) Likewise disable SSL if enabled
> 8) With no SSL or permessage-deflate, you can look for a clue by
> watching the network traffic directly with tcpdump (although browser
> ws payloads will be XORd, the header ws isn't) at the point it choked
9) Are you leaking something, like fd or sockets? If on Linux have a look
in /proc/<PID>/fd to get a feel for what he has open.
10) Leaking memory? On Linux watch it with top Shift-M to sort by memory
hogs and look at his process over time.
11) Remove complexity in the test by short-circuiting your audio processing
and just return him what he sent... problem is still coming?
12) Does the test server on the mirror test tab + run
libwebsockets-test-client -l localhost work well on your platform? He
should spam crazy amounts of circles on the canvas and reconnect every 10s
or so. This is also testing bulk data in both directions.
13) You should never try to send payload data outside the WRITABLE callback.
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets