Resuming that discussion I think we have a final view and fix of the problem which is a general problem, not specific really to us. I'll use an example to describe the problem, although it is not exactly the flow of events for squeezelite
- an mp3 file is 3.5 MB at 160 kbits/s = 20 kB/s - a client reads it at the exact required speed, 20kB/sec, let's say one recv() of 20kB per second, no pre-buffering for simplicity - some OS, like Windows, can have very large TCP kernel buffer (about 3MB or more) and with a fats connection, the TCP windows size is widely open - in a matter of seconds, the whole file is sent to the client, let's say that about 3MB are in the kernel buffers - as far as the server is concerned, all has been sent and acknowledge, so it does a close() - the close() sends a FIN to the client which responds by an ACK and enters FIN_WAIT_2 state - BUT, at that point from a client point of view, all recv() will have plenty of read for the next 150 s before it sees the eof! - so client, will not do a close() and thus will not send a FIN - the server is in FIN_WAIT_2 state and according to the TCP specs, it should stay like that *forever* - now, various OS (Windows at least) start a timer similar to TIME_WAIT (120s) when starting a close(), or when receiving the ACK of their FIN, that I don't know (in fact Windows has a specific registry entry for that, AFAIK). This is to more aggressively deal with half-closed sockets. - of course, after 120s, the server has not seen a client's FIN and send a RST - that RST is received by the client and cause and error there and all the remaining data in the TCP buffers to be discarded and lost That's it. That can be reproduced with a few lines of code and every HTTP server. This can be debated, but I see that as a systemic OS issue. Now, the solution that seems to work is to force client's receive buffers (SO_RCVBUF) to a lower level so that the server has little chances to have sent all data and that data sits in client's kernel buffers for too long. Note that this can still happen though if the buffer is 20kB and the client consumes it at 1B/s... hence I call it a systemic failure instead. LMS 8.2 on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3 ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=114661 _______________________________________________ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
