Kieran Mansley wrote: > On Wed, 2009-10-21 at 17:04 +0200, [email protected] wrote: > > But is that really what we want (an bug free)? If so, we would really > > need a compile-time check that TCP_WND is at least 2*TCP_MSS (or only > > greater than TCP_MSS?) to prevent problems: > > I think a compile time check would be a good idea.
Unless we fix it. > > > If, in Jan's case, the > > remote side was lwIP, too, the connection would stall as the window > > would never reopen because the remote side wouldn't be able to send a > > 2-byte-segment. I know we can fix this in lwIP, too, but there might > > be > > other embedded stacks having a problem with this? > > I don't understand this new problem. Looking at Jan's 1.3.1 trace, lwIP shrinks the window down to 2. At that moment (after a timeout, I guess), the remote side sends a packet of length 2. This results in the window getting 0 (not advertised) and our algorithm opening the window by MSS (resulting in a window of MSS). *If* the remote side would be lwIP too, and it would have pre-splitted segments on the unsent queue that are bigger than 2 bytes, it would stall because lwIP currently cannot split segments that are already created and thus wouldn't be able to send a 2-byte-segment that would be necessary to reopen the window. I don't know if this is still a problem after we change the algorithm, we'll have to see that. Simon -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
