srt: optional server silence timeout to detect a dead path

[RomanHerbstmann]

SRT: optional server silence timeout

Motivation

When the network path dies silently, the SRT client keeps sending and never reports a failure. Examples: a tunnel, a dead zone where the interface stays up, NAT rebinding, or UDP silently dropped by a middlebox. UDP send does not fail, SrtSender does not wait for ACKs, and handleServerPackets treats every SocketTimeoutException as ConnectionFailed.TIMEOUT. The app therefore streams into the void until the server-side session is dropped. We measured more than 60 s with MediaMTX.

setCheckServerAlive(true) does not help in our setup. It relies on isReachable() (ICMP/Echo), which is blocked by most cloud firewalls (e.g. Azure), so it reports healthy connections as dead.

Change

• New opt-in SrtClient.setServerSilenceTimeout(millis), exposed as SrtStreamClient.setServerSilenceTimeout(millis). The default is 0, which disables it, so existing behavior does not change.
• handleServerPackets remembers when the last packet (ACK, keepalive, NAK, …) arrived from the server. If a read times out and nothing has been received for at least millis, it reports onConnectionFailed("No response from server") and cancels the scope. That is the same path the existing checkServerAlive branch uses, so reTry works as usual.
• While data is being published, the server acknowledges it with ACK packets (MediaMTX: about every 10 ms). A silence of several seconds is therefore a reliable signal that the path is dead. Servers only acknowledge received data, so the timeout should be well above the longest pause in which no media is sent. Because of the 5 s socket read timeout, detection happens between millis and millis + 5 s.

Testing

Android emulator publishing to MediaMTX 1.18.2 over SRT. docker pause on the MediaMTX container for 60 s simulates a silent dead path (no reply, no ICMP).

	without the timeout	with setServerSilenceTimeout(10_000)
While paused	nothing is reported for the whole pause	onConnectionFailed("No response from server") 11 s after the pause started; reTry then attempts roughly every 7 s (handshake timeout)
After resume	the failure only surfaces now ("Shutdown received from server")	reconnected about 1 s after the container was resumed

• No false positives: the timeout fired exactly once in the run. It did not fire while streaming normally before the pause, or during the 60 s after reconnecting.
• No unit test: handleServerPackets is private and the client creates its socket internally, so a unit test would need a socket-injection refactor. Verified end-to-end instead.

[pedroSG94]

Hello,

Thank you for the fix. Merged