Re: [lwip-users] raw api recv callback - procedure to

[Kieran Mansley]

On Wed, 11 May 2005, Roger Kinkead wrote:

> I'd like the LWIP stack to hang on to that data and re-issue a recv_cb again
> later.

I'm not sure that is possible with the current API.  When the recv_cb is 
called you're forced to take that buffer, and you have to decide to either 
keep it or drop it.  I think - someone else please correct me if I'm 
wrong, as I'm not 100% sure of this.

> Any and all combinations I have tried appear to just let the LWIP stack
> assume the data was processed - so I end up with lost data.
> Essentially I need flow control at this recv_cb level - it's not always
> possible to use the data at the rate it is delivered from TCP.

The way to exert back pressure on the network is to delay calling 
tcp_recved() until you've finished with the data; e.g. you've passed it 
to the application.

The stack will not open the TCP window until tcp_recved() is called. 
The sender can only transmit more data when the window is opened, and so 
will only be able to send at the rate indicated by your calls to 
tcp_recved().

The only requirement then is that you can hold one TCP window of data in 
your queue (as that is the maximum that will be sent without you calling 
tcp_recved()).  If your queue can't hold this much, either make it bigger, 
or the TCP window smaller.

For example, if you have a fixed size queue between the stack and 
application (I'm not sure of your exact arrangement, but this is fairly 
typical), you put packets on this queue when the recv callback is 
called.  I would not call tcp_recved() from the receive callback, but 
instead from the function that *removes* the packets from the queue. 
Then, if nothing is removing packets from this queue and so the queue is 
filling up, the sender will stop sending packets before it gets full (if 
the above constraint is met).  This should remove the need to deal with 
the problem of what to do when the queue gets full.

Note that you must call tcp_recved() at some point for every packet passed 
to you, even if you drop it.

I hope that makes sense, and helps with your problem.

Kieran