On Fri, 2009-10-16 at 13:41 +0200, Jan Wester wrote: > Hi > I have the same problem > Kieran mention about to set TCP_WND_UPDATE_THRESHOLD = 0. I have not tested > yet, will start to test next week > > Kieran wrote > The window advertisement code was re-worked in 1.3.1 to only send an > explicit update when the change in window is greater than > TCP_WND_UPDATE_THRESHOLD. This defaults to (TCP_WND / 4). You could define > this to be zero to get the old behaviour, but the new behaviour should be > much better. I would be interested to know what the problem you encounter > as a result of the less-frequent window updates is. Note that any ACKs for > data that get returned should have the up-to-date window information in them > - it is only the sending of explicit window update ACKs that is restricted.
I was a bit wrong there. I've taken another look at the code and this change in behaviour is intentional. There were two changes in 1.3.1: - only send an explicit window update if the change is greater than TCP_WND_UPDATE_THRESHOLD. - only change the window advertised (including in normal ACKs) if the change is greater than 1 MSS. This is silly window avoidance, and designed to prevent the sender getting small amounts of window and then sending small packets. This doesn't therefore work well if your window is the same as the MSS as the advertised window will decrease to zero before the amount it can increase by equals 1 MSS, and it will then jump up by 1 MSS. We could make the threshold for announcing more window configurable, but I prefer documenting this property, perhaps with a compile time warning if your lwip options are configured this way, as having MSS == WND is bad for lots of reasons. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
