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

Rémi Denis-Courmont remi at remlab.net
Tue Oct 27 18:10:03 CET 2020


Le tiistaina 27. lokakuuta 2020, 18.28.00 EET Thomas Guillem a écrit :
> Fixes #25151
> Fixes #25192
> ---
>  modules/stream_out/chromecast/cast.cpp | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/modules/stream_out/chromecast/cast.cpp
> b/modules/stream_out/chromecast/cast.cpp index 08defbd5a1b..12e175bc68a
> 100644
> --- a/modules/stream_out/chromecast/cast.cpp
> +++ b/modules/stream_out/chromecast/cast.cpp
> @@ -466,6 +466,13 @@ int sout_access_out_sys_t::url_cb(httpd_client_t *cl,
> httpd_message_t *answer, * should also serve data used by the old client to
> the new one. */ restoreCopy();
>          m_client = cl;
> +
> +        /* Chromecast clients buffer lot of data (burst mode) and can wait
> more
> +         * than 10 seconds between 2 consecutive reads. Tell httpd
> that the
> +         * timeout of this client should not be handled (infinite
> timeout) to
> +         * avoid closing the client connection after 10
> seconds without any
> +         * read. */
> +        httpd_ClientSetTimeout(m_client, 0);

In sending state, the timeout will fire if the client cannot keep up with the 
data. That being the case, the TCP connection timeout will fire anyway after 
some tens of seconds. You can't do infinite timeout.

And that's not even to mention what Alexander already noted.

Besides, URL callbacks are not supposed to clobber client state beyond the 
HTTP transaction.

>      }
> 
>      /* Send data per 512kB minimum */


-- 
レミ・デニ-クールモン
http://www.remlab.net/





More information about the vlc-devel mailing list