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

[Rémi Denis-Courmont]

Le torstaina 29. lokakuuta 2020, 19.33.32 EET Alexandre Janniaux a écrit :
> 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.

For the third time, keep-alives do not help here.

> The point raised by François shed light on the timeout points: if the
> client isn't keepalive-aware

There are no such thing as TCP keep-alive-aware clients. TCP keep-alives are 
not perceived by the other end. The TCP/IP implementation handles them 
silently. In theory, a raw IP-level TCP implementation could expose keep-
alives to the application layer, but that never happens in real life.

And again, it's not even a problem of keep-alives. It's a problem of not 
timely dequeuing and acknowledging data sent by the server.

> 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.

Ok, I give up explaining at this point. Go ahead and waste however much time 
you want on not solving the problem.

-- 
Rémi Denis-Courmont
http://www.remlab.net/