[Top][All Lists]

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

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

From: address@hidden
Subject: Re: [lwip-users] TCP [TCP Window Update]
Date: Sun, 09 Aug 2009 10:11:35 +0200
User-agent: Thunderbird (Macintosh/20090605)

Unfortunately, I think there is currently no way to change this behaviour when using the socket API. The reason is this: 1) the ACK packet gets sent from the tcpip_thread, when the received data is put into the mbox. 2) Then there's a thread change to your application thread. After reading the data from that thread, 3) there's again a thread change back to tcpip_thread to tell the stack the data is actually processed.

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.


Alain Mouette wrote:
Hi, I am getting quite a lot of these in WireShark:

TCP [TCP Window Update]

0) I am using the socket interface :)
1) lwip sends a 15 byte packet to the server
2) the server responds an 11 byte packet, with ACK
3) lwip sends an ACK with a reduced window, from 2048 to 2037, delay is between 5 and 66ms
4) lwip sends an extra ACK with the full window size, delay is around 250ms.
5) next packet is sent usualy many minutes later...

What I can understand that is happening is this: I take a little too long to read the received data. I am using select to poll for data, with 1ms delay, but it is with FreeRTOS and so it might take a little longer sometimes...

My question is: is there a way to delay that ack so that it only goes after I read the data? Or store it somewhere (like buffers)?

This is to be with GPRS and I am getting over 20% extra trafic just for that :(


lwip-users mailing list

reply via email to

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