RTP/RTSP/TCP transport RTSP TIMEOUT should start at once when tcpi_ca_state is TCP_CA_Loss

Submitted by Dag Gullberg

Assigned to Tim Müller @tpm

Link to original bug (#770935)

Description

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.