Hi Norbert, in my opinion, this is ok: what you see here is that data is coming in faster than your application can process it. That's, ok. It would be bad the other way round as you would then probably get breaks in your mp3 stream.
The window being advertised as non-zero and then as zero again simply means the sender is fast in filling it again, which is a good thing. Regards, Simon Am 3. Juli 2023 12:21:58 MESZ schrieb Norbert Morawski <norbertzpil...@gmail.com>: >Hello, > >I'm not sure if this is a problem, but my MP3 radio streamer (lwip @ RP2040) >frequently closes the window. This is caused by a initial inrush of data from >the server, which pushes the window from 12kB to almost 0. Then it only >oscillates between 0 and 4kB with a period of about 2 seconds. > >Isn't there a way to prevent the initial depletion of window size? I'd be much >comfortable if it'd oscillate around half of the window size. Changing window >size didn't help. Current config is: >TCP_MSS 1460 >TCP_WND (8 * TCP_MSS) = 11680 bytes > >The app ACKs data as it decodes the MP3 frames, which would be 2 fast calls to >tcp_recved of around 400 bytes each 50 ms. Here are some images regarding the >problem. A chart of advertised window size from lwip client to the server and >a wireshark dump where initial 8 packets of size 87% of the window are >received in about 0.2ms (https://imgur.com/gallery/TVVcTp2) > >Or I have nothing to worry about and this is a normal TCP behavior? > >Regards, >Norbert. > > >_______________________________________________ >lwip-users mailing list >lwip-users@nongnu.org >https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
