Socket outgoing buffer overflow

[stubb0rn]

Hi folks

I'm currently working on a project that involves streaming data over the wifi. I implemented a library/component and am currently testing it. While doing so I encountered a strange behavior: Once my packets exceed a certain size, the EPS seems not to be able to send all data out as fast as they arrive and the internal buffer (?) runs over, producing a socket error.

From what I understood from the menuconfig help texts in the LWIP menu I guess it has something to do with insufficient memory but I couln't find any good documentation/references to understand the whole path from my application to the WiFi modem and would ask for anyone who has some readings on that, to share them.

Greetings
Patrick

[kolban]

I would have imagined that a call to send() to transmit data outbound from an ESP32 would block if it didn't have enough buffer space to accept a copy of the data to transmit. If it were me, I'd create a very simple and illustrative ESP32 application that connects to a remote data sink and attempts to push data at varying speeds and varying data sizes in an effort to reproduce the story in as simple a fashion as possible that would allow others to recreate on their systems with the minimal amount of effort and inconvenience.

[ESP_Angus]

For UDP sockets, there is a behaviour where send() may return an error with errno set to ENOMEM if the outgoing driver layer transmit buffers are full. Sleeping for a single tick and then trying again is the best solution if you get a failure with this errno value. You can also increase the number of transmit buffers in TCP/IP menuconfig:
http://esp-idf.readthedocs.io/en/latest ... buffer-num

We have discussed some other solutions with the WiFi team, but due to LWIP's architecture it's complex to find one which may not impact other aspects of TCP/IP stack performance.

[stubb0rn]

OK I stripped my code to the essentials and dumped different sized packets to a `netcat` on a Linux host without any issues!
Going back to my original code it came to me, that there might be an issue in the protocol implmentation that causes the socket closing.