[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection

[Rémi Denis-Courmont]

Le keskiviikkona 28. lokakuuta 2020, 10.32.07 EET Thomas Guillem a écrit :
> On Tue, Oct 27, 2020, at 20:14, Rémi Denis-Courmont wrote:
> > Le tiistaina 27. lokakuuta 2020, 18.28.00 EET Thomas Guillem a écrit :
> > > Fixes #25151
> > > Fixes #25192
> > > ---
> > > 
> > >  modules/stream_out/chromecast/cast.cpp | 7 +++++++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/modules/stream_out/chromecast/cast.cpp
> > > b/modules/stream_out/chromecast/cast.cpp index 08defbd5a1b..12e175bc68a
> > > 100644
> > > --- a/modules/stream_out/chromecast/cast.cpp
> > > +++ b/modules/stream_out/chromecast/cast.cpp
> > > @@ -466,6 +466,13 @@ int sout_access_out_sys_t::url_cb(httpd_client_t
> > > *cl,
> > > httpd_message_t *answer, * should also serve data used by the old client
> > > to
> > > the new one. */ restoreCopy();
> > > 
> > >          m_client = cl;
> > > 
> > > +
> > > +        /* Chromecast clients buffer lot of data (burst mode) and can
> > > wait
> > > more
> > > +         * than 10 seconds between 2 consecutive reads.
> > 
> > Linux limits the TCP send window to 4 MiB by default for security
> > reasons.So at, say 15 seconds, between reads, the stream would be capped
> > at 2 Mbps... And there are probably OSes with even lower limits.
> > 
> > I have to doubt the accuracy of the statement because it should have been
> > a
> > major problem from the beginning. But if it's true, then it's a client bug
> > that this patchset won't be able to work around.
> 
> Chromecast always worked with the default TCP timeout in 3.0. It doesn't
> work anymore with our httpd timeout.

The HTTPd timeout has not changed in many years either. I don't know if it 
even ever changed from the current 10 seconds value.

> This patch is not a perfect solution
> (since the TCP timeout can fire anyway) but this delay the timeout enough
> to allow low bitrate playback via chromecast.

Neither the TCP nor the HTTPd timeout prevent low bitrate. The TCP timeout is 
there to drop a disrupted connection if it has unacknowledged outbound data. 
The HTTPd timeout is there to do the same (but faster), and in server-side 
receiving state, drop connections with no incoming data.

Turning the HTTPd timeout off is essentially adding a remote DoS.

> The problem is when broadcasting sd video, two consecutive reads can be
> delayed by 10-20 seconds.

And so what? Unless available bandwidth is *insufficient* for the stream, the 
connection will reach POLLOUT faster than the HTTPd (and later on, TCP) 
timeouts fire.

Not to mention that, if you delay reads by 20 seconds, you will break any 
media with bit rate at or above 1.6 Mbps from a Linux system. It breaks even 
lower on some other systems or with non-default configuration. That's 
potentially not enough even for a typical SD stream.


In other words, this sounds like yet another nonsensical, unintelligible or 
elliptic problem statements. If you want to "fix" the HTTPd code, you have to 
provide a sensible explaination of what is wrong with it. And in the mean 
time, I can only assume that any bug lies elsewhere, likely in the Chromecast 
plugin proper.

-- 
Реми Дёни-Курмон
http://www.remlab.net/