[vlc-devel] [PATCH 2/2] chromecast: don't close the client connection
ajanni at videolabs.io
Wed Oct 28 12:08:39 CET 2020
On Wed, Oct 28, 2020 at 12:59:18PM +0200, Rémi Denis-Courmont wrote:
> Le keskiviikkona 28. lokakuuta 2020, 12.51.52 EET Alexandre Janniaux a écrit :
> > > 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?
> I don't know. What does it matter here anyway? The HTTPd instance is shared by
> all HTTP clients. So, for instance, Chromecast and the HTTP interface are
> handled in the same instance and thread.
Yeah sure, my remark was not about the current state of the code,
which I don't master. It's just that if we allow only a single
TCP connexion for those HTTP endpoint, we probably don't need a
timer at all (as I've mentioned, TCP keepalive + no timer at the
HTTP server level), to protect from DDoS so this situation would
be different from standard generic HTTP server. There's already
an intrinsic timer (though it could be high) when playing finite
duration files through chromecast.
That would only mask the underlying issue though currently, but
could be an improvement for such use cases. It could also lead
to issue if the chromecast disconnects without signalling it
and try to reconnect but that's not happening according to
François's network traces and making this happen in real life
is probably hard given usual 10 seconds keepalive.
More information about the vlc-devel