[Top][All Lists]

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

Re: [lwip-users] TCP [TCP Window Update]

From: Alain Mouette
Subject: Re: [lwip-users] TCP [TCP Window Update]
Date: Mon, 10 Aug 2009 20:49:01 -0300
User-agent: Thunderbird (X11/20080914)

Kieran Mansley escreveu:
On Sun, 2009-08-09 at 10:11 +0200, address@hidden wrote:
Step three results in the window being changed. However, the window update is not sent right away but after 250 ms (delayed ACK mechanism): with full duplex application-protocols, the window update would just be sent with the next packet. Since you don't send a packet in this timespan, an extra packet is generated for the window update.

Looking at the steps above, it would not even matter if your application was faster than 1ms, it's just the way lwIP is designed currently.

You *could* change the behaviour if you would use the raw API and tell the stack about the window update right away - but I guess that would be a pretty big change to your application. Another way to solve it would be to set a new flag in the pcb and update the window when putting the data into the mbox (when that flag is set) - however, that would mean you have to change the lwIP core code - or you'd have to wait until such a behaviour is implemented in CVS.

I haven't looked at the code in question, so this might not make total
sense, but from what you describe you could tailor lwIP to your current
application by either (i) getting the tcpip_thread to just use tcp_ack()
rather than tcp_ack_now(), so it too would use the delayed ACK
mechanism, and then your window update would be combined with the normal
ACK; and/or (ii) change the window update threshold so that you don't
always send a window update for such small changes in the window.  To be
honest I'm a bit surprised that lwIP sends a window update for a change
of just 11 bytes.  Which version of lwIP are you using?

I am using lwip 1.3.0.

the (ii) option seems to fullfill my needs :) can you give me a hint on where to look for that? Bigger packet sizes are not important because they don't happen very often and thus wil cause no traffic cost problem.


reply via email to

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