ESP8266 Community Forum

While studying the ESP8266, I understand that I can form a TCP connection to the partner. The partner can then start pushing data down the pipe for consumption by my own application. When the partner sends data, I wake up in the callback registered by espconn_regist_recvcb() and am passed a copy of the data that I can't "hold onto" after the callback completes.

Since I also can't spend too long in the callback function, it makes sense to take a copy of the received data for subsequent processing.

And with that background ... here is my dilemma.

Imagine my partner is sending me data faster than I can process it. For example, if my partner is sending me 5K of data each 100msecs but I can only process 1K of data each 100msecs then I am going to be in trouble.

If I can't process the data at the rate my partner is sending, I somehow need to throttle the transmission rate. The question is ... how do I do that? Imagine I have no application level protocol control at the application level. What I feel I want to do is throttle the ability of the ESP8266 to say "Hey partner, I know you have data to send to me ... but keep it in your own buffers ... my buffers are full. I'll tell you when you can push more to me!".

Is such a thing possible?

TCP has a window size that is advertised by each receiver, which is the amount of data that the sender may send unacknowledged, i.e., before sending the next byte beyond this window the sender must have received an ACK for the first byte in the window. The window size advertised by the esp8266's SDK is 5840, i.e. 4 ethernet packets, so the sender can't send more than that amount before having to wait for an ack. I would hope that the SDK doesn't send an ACK until your app has returned from the recv callback, but I have not tested that.
In addition, there is an SDK call to stop the flow, which I assume reduces the advertised window size, but I've never tried it.

Thanks for the response. Do you happen to know the name of the SDK API call?

I also wonder what happens if one NULLs the receive callback? That *might* be an indication to the SDK that we should not acknowledge receipt of incoming packets.

later .... I found an API called espconn_recv_hold(). I think this may be the one that @tve had in mind.