Add command to Query TCP Connection Data Transmitting State

[arturv2000]

Is your feature request related to a problem?

When using Wifi TCP (Client Mode) in Normal Transmission Mode there can be instances that we are sending more data to ESP32 than the data it can send to the server (due to weak Wifi Link to router, internet connection problems, etc...), in my particular case I am using AT+CIPSEND to send blocks of data up to 4096 bytes.

In such cases after a while (I am assuming that is in case the internal buffer is full) it will start replying SEND FAIL, but part of that message is still arriving to the server, it seems that it does not block the complete message sent in AT+CIPSEND=<link ID>,<length>, we can retry to send the message after a while but the server will have issues since the last message was "broken" and the parsing gets tricky.

In my case I have configured <so_sndtimeo> to 2s (although the reply SEND FAIL appears before this timeout), since I need the AT interface to perform other tasks.

Describe the solution you'd like.

If possible, implement an AT Command that indicates the state of the internal buffer, something similar to Quectel AT+CIPSEND=1,0 when the send length is zero, will indicates the status of the internal TCP buffer.

Or in SimCom modems AT+CIPACK

Where we have information of how much data is not yet acknowledge from the server, ideally the size of the internal buffer should also be reported or be indicated in the documentation, with this information we may delay new data transmission until enough internal space exists to accept new data.

Describe alternatives you've considered.

At the moment, in case of SEND FAIL answer i am implementing an exponential timeout retry mechanism to attempt to send data to the server and modifying the message to include the protocol terminator at the start of the message to help the server parse the message successful.

This method kind of works, but it's kind of slowdowns the connection / data throughput and create additional traffic in the network.

I could set <so_sndtimeo> to 0 but that would potencially lock the AT interface for a long period of time, and I need to serve other TCP/UDP sockets in a timely manner.

I have limited "power" to change the protocol configuration at this moment in order to facilitate / improve the parsing issue on the server side.

Additional context.

No response