[Bug 663542] souphttpsrc doesn't reopen HTTP connection after pause

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=663542
  GStreamer | gst-plugins-good | 0.10.29

Davy <realbrightster> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |realbrightster at gmail.com

--- Comment #3 from Davy <realbrightster at gmail.com> 2012-02-06 04:49:01 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.