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?