Websocket freezes - LmacRxBlk:1

[amiravni]

Hi,

So I've been using your code for quite sometime and found it very nice.
However, I've encountered a "timing" problem: When I try to send data from the ESP8266 but its "receiving buffer" is still not empty, the code sometime stuck and stop working, solved only with reset.

Don't know if it is my fault for using it wrong or if not what is the best way to fix it - But at least in my case I wrote a small patch which solved the issue (I'm not the best coder).

On WebSocketServer.cpp, on the "WebSocketsServer::sendTXT" function I've added just before the "sendFrame" function this code:

if(client->tcp.available() > 0) {
    DEBUG_WEBSOCKETS("[WS-Server][%d][handleHeader] SEND: Buffer is not empty, cancelling respond");
    return;
}

which cancels the sending in case the buffer is not empty.

If I'm not the first one reporting this issue please let me know if there's a better solution.

Thanks,
Amir

[Links2004]

i never had this kind of problem,
the RX and TX buffer are independent from each other on the ESP.

can you please add

Serial.setDebugOutput(true);

and enable the DEBUG_WEBSOCKETS.
and then post the log here when it happens.

[amiravni]

Yes I thought the same on the RX/TX issue.
So I deleted my patch and enabled the debugging.
In this test I'm basically sending some strings with values ("x410","x420"...."x450") many times very fast and the ESP8266 sending back the the string "red changed". Now when I looked at it again - it "freezes" and then after a second it kept writing the log stating that the websocket disconnected.

When I add my patch I still get some of the received data, less frequent of course...

Here's the last part of the log:

[WS][2][handleWebsocket] free: x420
[WS][2][handleWebsocket] ------- read massage frame -------
:rd 2, 50, 0

:rdi 10, 2

[WS][2][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0  opCode: 1
[WS][2][handleWebsocket] mask: 1 payloadLen: 4
:rd 4, 50, 2

:rdi 8, 4

:rd 4, 50, 6

:rdi 4, 4

:c 4, 10, 50

[WS][2][handleWebsocket] text: x420
420
[WS][2][sendFrame] ------- send massage frame -------
[WS][2][sendFrame] fin: 1 opCode: 1 mask: 0 length: 4 headerToPayload: 0
[WS][2][sendFrame] text: red changed
:wr !_pcb

:wr !_pcb

[WS][2][handleWebsocket] free: x420
[WS][2][handleWebsocket] ------- read massage frame -------
:rd 2, 40, 0

:rdi 10, 2

[WS][2][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0  opCode: 1
[WS][2][handleWebsocket] mask: 1 payloadLen: 4
:rd 4, 40, 2

:rdi 8, 4

:r
:wr !_pcb

d 4, 40, 6

:rdi 4, 4

:c 4, 10, 40

[WS][2][handleWebsocket] text: x430
430
[WS][2][sendFramrd 2, 30, 0

:rdi 10, 2

e] ------- send massage frame -------
[WS][2][sendFrame] fin: 1 opCode: 1 mask: 0 length: 4 headerToPayload: 0
[WS][2][sendFrame] text: red changed
:wr !_pcb
[WS][2][handleWebsocket] free: x430
[WS][2][handleWebsocket] ------- read massage frame -------
:[WS][2][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0  opCode: 1
[WS][2][handleWebsocket] mask: 1 payloadLen: 4
:rd 4, 30, 2

:rdi wr !_pcb

:wr !_pcb

8, 4

:rd 4, 30, 6

:rdi 4, 4

:c 4, 10, 30

[WS][2][handleWebsocket] text: x430
430
[WS][2]rd 2, 20, 0

:rdi 10, 2

[sendFrame] ------- send massage frame -------
[WS][2][sendFrame] fin: 1 opCode: 1 mask: 0 length: 4 headerToPayload: 0
[WS][2][sendFrame] text: red changed
:[WS][2][handleWebsocket] free: x430
[WS][2][handleWebsocket] ------- read massage frame -------
:[WS][2][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0  opCode: 1
[WS][2][handleWebsocket] mask: 1 payloadLen: 4
:rd 4, 20, 2

:rdi wr !_pcb

:wr !_pcb

8, 4

:rd 4, 20, 6

:rdi 4, 4

:c 4, 10, 20

[WS][2][handleWebsocket] text: x430
430
[WS][2]rd 2, 10, 0

:rdi 10, 2

[sendFrame] ------- send massage frame -------
[WS][2][sendFrame] fin: 1 opCode: 1 mask: 0 length: 4 headerToPayload: 0
[WS][2][sendFrame] text: red changed
:[WS][2][handleWebsocket] free: x430
[WS][2][handleWebsocket] ------- read massage frame -------
:[WS][2][handleWebsocket] fin: 1 rsv1: 0 rsv2: 0 rsv3 0  opCode: 1
[WS][2][handleWebsocket] mask: 1 payloadLen: 4
:rd 4, 10, 2

:rdi 8, 4

:rd 4, 10, 6

:rdi 4, 4

:c0 4, 10

[WS][2][handleWebsocket] text: x440
440
:ur 1

WS:dis

[WS-Server][2] client disconnected.
[WS][2][handleWebsocket] free: x440

[Links2004]

I made some changes can you test them?

[amiravni]

Hi,
So I pulled the new code, it seems I missing a file since I get this error

C:\Program Files (x86)\Arduino\libraries\WebSockets\src\WebSockets.cpp:28:35: fatal error: core_esp8266_features.h: No such file or directory
 #include <core_esp8266_features.h>

Did I missed this .h file? Is it from a certain version of the IDE?

[Links2004]

its only in the git version of the core,
what core version you have?

[amiravni]

you mean the arduino IDE core? I currently have the 2.0.0 rc2 from the staging versions.
Should it be on the new 2.0.0 stable version? or I should I download it manually?

[Links2004]

the easy-es way it to follow this:
https://github.com/esp8266/arduino#using-git-version-

you need to remove the version in your user dir.

[amiravni]

EDIT:
Wait... forgot to enable debugging on your new code
Deleted what I wrote

[Links2004]

the debug out is disabled.
but the main info is LmacRxBlk:1 which mean that the WiFi input buffer of the SDK is overloaded.
so in short, you reach the maximum possible for the ESP hardware.
you can try to run at 160Mhz.
but better think about if you need to answer to each data request you get, may rate limit it.
the TCP layer itself will ensure the packages come save to the other side.

[amiravni]

Ah... you answered before I had the chance to fix my comment :)
Thanks, I do not need to response every time, just wondered if it is a bug.

But I am still wondering how come when I've added my patch it solved the problem...
perhaps when I cancelled some of the "sendFrame" it also made the buffer smaller.

What's the maximum by the way? do you know?

[Links2004]

if you do less sendFrame there is more time to handle the incoming data :)
and in you case this saved time where enough to prevent the buffer form overflowing.

espressif not provide any info about this part of the chip.
we only know the meaning of LmacRxBlk:1 from many cases where all is coming form the same basic problem,
to many incoming data that is not handled --> buffer full.

[amiravni]

OK, Thanks for the info!

[rwmingis]

I ran into something similar on this. The websocket module would fail and not recover when transmitting data from main loop on a 1s period while receiving continuous data from an html slider.

I fixed it by putting a 1ms delay after the websocket transmit (sendTXT) portion in the main loop, as if it needs a break to finish it's job after transmit call has returned.

Also, if a client breaks connection without properly disconnecting, it hangs the server for 10 or 20 seconds every loop. I fixed this by pinging all possible clients and disconnecting the ones that fail that were thought to be active by the server.