GNOME Bugzilla – Bug 663542
souphttpsrc doesn't reopen HTTP connection after pause
Last modified: 2013-10-08 20:35:17 UTC
Created attachment 200864 [details] [review] patch to force souphttpsrc reconnect when connection lost The issue can be reproduced as follows: 1) start the playback 2) put gstreamer into the PAUSED state 3) wait for a long time so that the server would terminate the connection. I believe, around 2 minutes will be enough for most servers. 4) unpause gstreamer What then happens is that souphttpsrc would continue receiving a number of chunks (at my system they are in total around 124 kb) and then go to the "got body" signal handler, signalling EOS. This is inspite the rest of the file is much longer than these 124 kb. I believe it would read from some internal buffer, not realizing that the connection is broken. We have solved this issue using the attached patch file. Please consider integrating it into a new version of souphttpsrc or solving this issue in some other way.
Comment on attachment 200864 [details] [review] patch to force souphttpsrc reconnect when connection lost [Setting "patch" flag and correcting mime type so this can actually be queried for.]
Comment on attachment 200864 [details] [review] patch to force souphttpsrc reconnect when connection lost Wouldn't this infinitely retry if the server closes the connection before the end of file all the time? There should be some kind of guard to prevent it from retrying another time if no new data was received since the last retry.
In my humble opinion, it’s a normal process caused by TCP zero window. If you let pipeline in PAUSED state for a long time, TCP receive queue (advertisement window) will be decreased, continuously. The reason is, 1. souphttpsrc will try to streaming the content even though in PAUSED state 2. Some feeding context (gst_pad_push) will be blocked in some case queue full, adec/vdec buffer full…. 3. libsoup can’t read data from socket because our process is blocking 4. unread packets in TCP receive queue are will be grown 5. your device advertise TCP zero window 6. TCP streaming will be blocked 7. Server will close connection if the TCP persist timeout is occurred As far as I know, this issue can be solved server-side also. In case of Linux, you can adjust the number of retires to probe zero window via sysfs. “/proc/sys/net/ipv4/tcp_retries2” Please don’t confuse that it’s a number of retires not a time unit. The interval for each probe packet will be increased exponentially. If the number of retries exceed above value, kernel will close current socket and send a FIN to peer. When a client receive FIN packet in the middle of socket reading, syscall (read, recv..) will return zero and libsoup handle this case as a EOF.
Yes, that's all correct and I did not try to question the usefulness of your patch :) It's just that I think there should be a limited number of retries in souphttpsrc or it should at least when it got no new data at all since the previous retry to prevent infinite retrying without any new progress.
*** This bug has been marked as a duplicate of bug 683536 ***