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

[Alexandre Janniaux]

Hi,

On Wed, Oct 28, 2020 at 12:24:44PM +0200, Rémi Denis-Courmont wrote:
> Le keskiviikkona 28. lokakuuta 2020, 11.37.14 EET Thomas Guillem a écrit :
> > On Wed, Oct 28, 2020, at 10:03, Rémi Denis-Courmont wrote:
> > > Le keskiviikkona 28. lokakuuta 2020, 10.32.07 EET Thomas Guillem a écrit :
> > > 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.
> >
> > You just changed timeout handling with
> > 67cdaeea58641d6d515728596f8b194f52538e2b.
>
> No?
>
> > I don't understand why you are not updating the activity date just after
> > httpd_Client*() like it was done before (that is what Francois tried to fix
> > in the first time)
>
> "I" update the activity timestamp after processing non-blocking I/O *and*
> after processing timeout expiration, exactly as was done before, and as seems
> logical.
>
> The order of polling and non-blocking I/O is reversed for reasons explained in
> the commit message, and has no meaningful effects on the timeouts.
>
> > The Chromecast client will fill its internal buffer to the maximum when
> > opening/seeking a file. This result on many read requests.
>
> > Then, it will wait quite a long time before doing another read request.
>
> You are making as little sense to me as the previous two times. There's no
> such things as "read requests" in TCP or HTTP 1.x.
>
> If you mean [time between] consecutive HTTP messages, then that would cause a
> time-out already in previous versions. And removing that time-out is not an
> option. The 10 seconds inactivity timeout is very much intended there to save
> resources. That's the only DoS mitigation. Practicaly all webservers have an
> aggressive timeout between requests also, for the same reasons.

Isn't chromecast single-client only?

Regards,
--
Alexandre Janniaux
Videolabs