[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] raw api recv callback - procedure to
From: |
Kieran Mansley |
Subject: |
Re: [lwip-users] raw api recv callback - procedure to |
Date: |
Wed, 11 May 2005 20:55:54 +0100 (BST) |
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