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

[Rémi Denis-Courmont]

Le keskiviikkona 28. lokakuuta 2020, 15.20.33 EET Francois Cartegnie a écrit :
> Le 28/10/2020 à 11:28, Rémi Denis-Courmont a écrit :
> > Le keskiviikkona 28. lokakuuta 2020, 11.37.14 EET Thomas Guillem a écrit :
> >> 1/ With a 1 226 kb/s video: the chromecast client read 6MB from start,
> >> then
> >> try to read 1MB - 2MB every 10secs or more 2/ With a 4 487 kb/s video:
> >> the
> >> chromecast client read 15MB from start, then try to try 2MB every
> >> 2seconds.
> > 
> > That would timeout with previous versions just the same. Not like the
> > timeout changed in recent years.
> > 
> > Frankly, I don't care if it's 5 or 20 seconds. But VLC has an aggressive
> > timeout there, everything else has one too, it's necessary, and it was
> > already there before the alleged breakage.
> 
> The current chromecast module is broken by design,

Then fix it, or make a work around in *there*?

> but also because their received app progressive download mode never
> reconnects when the connection drops.

> Seems it was designed to expect no timeout

That cannot be achieved with the TCP implementations provided by the OSes that 
VLC runs on. *All* of them will fatally time-out the connection if data 
remains in the send buffer for too long. (Only way to avoid this is to write a 
custom TCP stack, which requires raw sockets privileges.)

> (or server to use TCP keepalive),

TCP keep-alives just means sending dummy packets when the send buffers are 
empty, in order to:

1) Time the connection out if the other end is unreachable.

2) Refresh expiration timers on middleboxes (NATs & firewalls).

This is basically the opposite of what you would want in this context, i.e. 
*not* time-out the connection.

> and since most of the content is served from static files or
> through multiple files (adaptive), I guess that case was never really tested.

How is it any different with static files? TCP does not care if your data is 
from static file or paced. It only cares how long it stays in the send buffers.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/