On Wed, 2007-02-14 at 09:23 +0000, Kieran Mansley wrote: > On Tue, 2007-02-13 at 23:03 +0100, Robert Goeffringmann wrote: > > When receiving data, it always starts with lwip advertising a window of > > 29-32KB, which is quickly filled by the host pc. > > lwip then sends ACKs, reducing the window sizes until it finally sends a > > zero window.. > > Then, after a couple of millis, it sends a new window update with a size of > > 29-32KB. > > > > I already don't understand why it doesn't advertise a bigger window to > > begin > > with. > > It should advertise a maximum receive window equal to TCP_WND, which > from your settings below is around 57KB. This is less than the maximum > (without window scaling) of 64KB, so should be fine.
Having had a look at your ethereal captures I see it advertising up to around 42KB. A full capture (from the start of a connection) in pcap rather than txt format would enable me to look at this more precisely. > The reason it decreases the window down to zero is that it is unable to > keep up with processing the network traffic at the rate it is arriving, > and so packets queue and the window fills up. Actually, in this case (with the benefit of looking at your packet capture) it looks like the stack is processing the packets at a reasonable rate (the ACK numbers are increasing) but the window is still decreasing. This suggests that the packets are being buffered in the sockets API layer, and the application is not reading them fast enough. ie. This could be a scheduling issue. Kieran _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
