[Libwebsockets] Server stops reacting after some time
andy at warmcat.com
Tue May 10 08:29:05 CEST 2016
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