Re: [lwip-users] Throttling incoming TCP in receive callback using raw API

[address@hidden]

Bruce Sutherland wrote:
> In our TCP receive callback, data is simply copied from the pbufs provided
> by lwip, into a serial ring buffer. As the serial port is much slower than
> the Ethernet port, we need a way to inform lwip that we cannot receive more
> data when the serial buffer is full. What is the mechanism to do this?
> Should I delay calling tcp_recved in the case that the serial ring buffer is
> too full?
That's exactly the way to do it. tcp_recved sends a window update to the 
remote side while the ACK is sent by stack-internal functions right 
after receiving.
> If so, when will my receive callback be called again? Is there
> some better way to achieve this?
>   
The receive callback will be called again when new data arrives, which 
can happen although you did not call tcp_recved if the RX window is not 
yet full. If the window is full, the client may send again after 
receiving a window update from you.

I'm guessing the ETH connection is much faster than the serial 
connection? In that configuration, I think it will be enough to call 
tcp_recved after having sent the data on the serial line. That way, you 
only have to make sure that the TCP RX window is bigger than (or equal 
to) the serial buffer.
> Our current implementation appears below, which calls tcp_recved for all
> data as it arrives, and just throws an assertion if the serial ring buffer
> is too full to fit the data.
>
>   
That's not a good idea as this assertion can appear very often if the 
TCP sender sends faster than the serial port can handle it.


Simon