lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Confused about flow control


From: Kieran Mansley
Subject: Re: [lwip-users] Confused about flow control
Date: Mon, 27 Jul 2009 09:43:45 +0100

On Sat, 2009-07-25 at 20:53 -0700, JM wrote:
> 
> As I understand, in the recieve callback I would call tcp_recved() and
> pbuf_free() to tell lwIP that I have the data and it can clear it from
> its buffer.  How do I tell lwIP that I can't accept more data now, and
> it should send ZeroWindows?  I have tried not calling these functions
> in different combinations, and the host (what lwIP is connecting to)
> keeps retransmitting because lwIP apparently didn't ACK.

There is no API for an application to directly control the receive
window and prompt the stack to start sending zero window updates.  To do
so would break the TCP spec, as it would involve shrinking the
advertised window.  The only control you have is:
 - the initial size of TCP_WND, which sets how big the receive window
can grow to;
 - calling tcp_recved() when you want the stack to re-advertise space
after you have received some data.  You can delay doing this if you want
to artificially hold the window small, but you should make sure that it
gets called eventually.  pbuf_free() must always be called when you have
finished with a pbuf.

In these circumstances you should see stack continue to receive and ACK
packets until the receive window is all used up, at which point the
sender should stop transmitting.  Once you call tcp_recved() to free up
some space, lwIP will send a window update and the sender will start
sending again.  Note that even if you don't call tcp_recved() straight
away, there may still be space in the receive window, and so the sender
will continue - you can't control it directly.

If that's not sufficient, perhaps you can explain why you need to halt
incoming packets?  Normally an application would just stop reading data
from the network for a while when it was busy, and start reading again
when it wanted more.

Kieran





reply via email to

[Prev in Thread] Current Thread [Next in Thread]