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

Alexandre Janniaux ajanni at videolabs.io
Thu Oct 29 18:33:32 CET 2020


Hi,

On Thu, Oct 29, 2020 at 06:02:24PM +0100, Pierre Ynard via vlc-devel wrote:
> > I don't know the other exotic systems (OS/2?) but it seems to be a
> > general case where keepalive is portable and unpriviledged but the
> > user timeout a bit more specific and tedious. Since we also emulate
> > the timeout in the httpd server, it could be one solution to tackle
> > this kind of limitation, though when exactly we would want to enable
> > this is quite unclear to me right now.
>
> Logically, you'd want to add it to the patch: if you're aiming for
> compatibility with the Chromecast client, at the same time that you're
> raising/removing the HTTPd inactivity timeout on new clients, you should
> also check and attempt to set the TCP timeout on their socket to ensure
> it has a sufficiently high value; otherwise you risk still hitting the
> TCP timeout, and only having a partial fix for the best cases.

Actually «sufficiently high» doesn't make sense for this case. Systems
have maximum values and an error code associated to that. So you'd have
to enable keepalive for «higher» values, but it could also have its
limits.

The point raised by François shed light on the timeout points: if the
client isn't keepalive-aware or hasn't a higher enough timer value it
could timeout as well, so this higher timeout value is useless without
a testing/dump on the chromecast to know the value/check whether
keepalive even makes sense.

It also joins the point raised multiple times which suggests the bug
should be solved elsewhere. Since Chromecast and its waiting callback
has been incriminated, maybe some points can be expanded here in the
design of the url callback?

Regards,
--
Alexandre Janniaux
Videolabs


More information about the vlc-devel mailing list