DEV Community

zhuyue
zhuyue

Posted on

Change some line codes to fix the TCP "stickiness“ problem for ESP8266 based programmable controller

A few lines of code changes to solve the problem of communication interruption by the TCP stickiness for ESP8266 based programmable controller

In debugging the function of simple programmable controller designed based on ESP8266, from time to time encountered the built-in web page download to half of the abnormal interrupt problem.

The data received by TCP sever was printed out through the serial port and analyzed. When the interruption exception occurred, the single HTTP request for writing data sent from the PC tool was split into several receipts;

This is the TCP transmission occurred the problem "stickiness".

The TCP sticky packet and packetization problem refers to the TCP communication, because TCP is stream-oriented, so the sender may send multiple small packets together when transmitting data, and the receiver may split these packets into multiple small packets to receive, which leads to data reception errors or data sticking problems

There are three ways to solve the problem of packet splitting and sticking:
1) Packets are transmitted at a fixed length
2) Use a fixed separator at the end of each packet, such as the newline character \n;
(3) customize the digital frame format, increase the data header, specify the frame start flag and frame length in the header, the receiving program parses the header to obtain the frame length, and then receive the data specified in the frame length;

The http protocol ends with \r\n\r\n characters, which can be solved by the second program;
But the ESP8266's memory space is limited, there is no way to open up memory to store the unpacked data.

After researching, I finally used the receive buffer pbuf in the lwip stack for staging.
static err_t tcp_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err)When the received data is not ended with \r\n\r\n and the length does not exceed a certain length, indicating that a complete frame of data has not been received, then the tcp_recved function is not called, and returns directly to allow the lwip stack to continue caching data;

Otherwise, call the tcp_recved function to notify the lwip stack that the data has been processed by the upper layer and let it release the cache;

After the repair, I then modified the PC tool, using a timer to automatically download the web page repeatedly, continued to test the whole day, did not find the download interruption problem.

Image description

Image description

Image description

Image description

Top comments (0)