[Bug 770935] New: RTP/RTSP/TCP transport RTSP TIMEOUT should start at once when tcpi_ca_state is TCP_CA_Loss

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770935

            Bug ID: 770935
           Summary: RTP/RTSP/TCP transport RTSP TIMEOUT should start at
                    once when tcpi_ca_state is TCP_CA_Loss
    Classification: Platform
           Product: GStreamer
           Version: 1.9.2
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-plugins-base
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: opaque.se at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

This is a bug-report related to bug 770934.

The issue is to have a deterministic handle on the timeout on the platform.
This works fine in UDP, but in TCP tunneling the timing is at the mercy of the
persistent nature of TCP.

It stand clear that the non-blocking-write socket will continue to act normally
(as it has a buffer) even at network disconnect. Possibly also retransmit
schemes, related timeouts, number of retries, and timeout back-off scheme add
to this problem as well.

The net result is a delay between the actual tcpi_ca_state in the TCP stack
being set to TCP_CA_Loss (the first retransmit) and the user of the socket
seeing RESOURCE TEMPORARILY UNAVAILABLE (EWOULDBLOCK) that amounts up to
several seconds. In actual tests actually >10s (DEBUG mode runs though)

The impact is that functionality depending on deterministic values of the time
delay between the last frame of the lost stream and the timeout expiration,
will have a hard time bridging that gap. (e.g. fail over file save locally)

A patch has been prepared that addresses this issue.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.