Receiving WebSocket data

[DexterM]

Is it possible to receive information that data are waiting in module buffer and then read it?
Or data streamed together with commad is the only way?:

Code: Select all

+WS_DATA:0,4,test

I think that this form of binary data serving + problem with additional <CR><LF> before "+WS_DATA:" message that appears sometimes and sometimes not, forces additional code in the data reception routine, which reduces performance and prevents from making receive and parse routines completely independent.
1. We don't know if we are receiving command or data before parse occures. Commands are text and data are binary (in my case) so i use different buffers for commands and for data receiving. It would be better to know that data are waiting and read it by command - we could read and save data directly to data_buffer after put something like "READ_DATA" command.
So now, I have to parse begining of received command on-the-fly (in receiving routine) and switch buffer from command buffer to data buffer after detection of "+WS_DATA:" and length parameter.
2. Even worst, there is sometimes:
<CR><LF>+WS_DATA:x,data.....
and sometimes:
+WS_DATA:x,data.....
So if I want very simply check command buffer from position 0 using memcmp (that less reduce performance than strstr), i have to additionaly check if first character is <CR> or <LF> and ignore it, and this is next condition that have to check in receiving routine.

As it can be discussed if getting data by additional command also would reduce performance, simple change in "+WS_DATA" message could significantly improve the situation:
+WS_DATA:data_length,<CR><LF>data.....
Now we could parse "+WS_DATA:length," part natively in parse routine (command ended with <CR><LF> is natively transfered to parse routine) and then receive data to binary data_buffer.

The other issue is this additional <CR><LF> sometimes appears before "+WS_DATA....". Do You know about this or it is rather bug on my side?

[esp-at]

@DexterM Hi, this response should not happen.

Code: Select all

<CR><LF>+WS_DATA:x,data

The right format should be:

Code: Select all

+WS_DATA:id,len,data<CR><LF>

If you do observe a <CR><LF> before +WS_DATA, then one of the following must be true:

• The <CR><LF> belongs to the end of the previous message and was not fully consumed or handled by the MCU side

• There is indeed an issue in the firmware. You can Enable AT Interface Function Debugging to verify this. If you prefer not to build the firmware yourself, you may also download the corresponding *-debug-at firmware for your target chip from GitHub Actions and use it for testing.

[DexterM]

Thank You for response.
You are right with “The <CR><LF> belongs to the end of the previous message and was not fully consumed or handled by the MCU side”
I think this is the reason, that I missed:

Code: Select all

I (166466) intf-tx: 0x3f4063c4   0d 0a 53 45 4e 44 20 4f  4b 0d 0a                 |..SEND OK..|
I (166505) intf-tx: 0x3ffb2c80   2b 57 53 5f 44 41 54 41  3a 30 2c 31 31 2c 1f 01  |+WS_DATA:0,11,..|
I (166505) intf-tx: 0x3ffb2c90   02 04 00 ff 10 01 75 94  ee 0d 0a                 |......u....|
I (214017) intf-tx: 0x3ffb6264   2b 57 53 5f 44 41 54 41  3a 30 2c 31 37 2c 1f 01  |+WS_DATA:0,17,..|
I (214017) intf-tx: 0x3ffb6274   02 0a 00 ff 0f 01 01 00  01 ff 00 01 07 e8 a5 0d  |................|
I (214024) intf-tx: 0x3ffb6284   0a

I didn't suspect that there is 0d 0a after data in +WS_DATA:
Thanks for help.

[esp-at]

No worries~