[Libwebsockets] HTTP keep alive timeout set to 31sec
andy at warmcat.com
Wed Feb 13 08:52:06 CET 2019
On February 13, 2019 4:28:31 PM GMT+09:00, Xi Chen <leon6827chix at gmail.com> wrote:
>I am using LWS as HTTP2 client to connect with Alexa service.
>Alexa cloud service requires client to send PING every 300 second.
>Let's say I am going to send PING at t=300sec, but will receive LWS
>at t=31sec due to this logic.
>Is this expected?
As it is, yes it's expected.
Completely idle h2 network connections shouldn't be allowed to live forever consuming resources, unless at least one stream in there upgraded to ws, which by default is specified to live forever.
It sounds like there's no argument with that since it's a keep-alive on your side, ie, also designed to kill idle connections. It's a long poll kind of strategy?
Maybe just making the timeout settable is enough. But I am traveling atm and can't look at it.... maybe you can try hack this timeout to 600s and see what happens. The individual streams have their own timeouts too, but you can set it from the callback.
>On Tue, Feb 12, 2019 at 10:38 PM Andy Green <andy at warmcat.com> wrote:
>> On February 12, 2019 1:05:51 PM PST, Xi Chen <leon6827chix at gmail.com>
>> >Hi Andy,
>> > /* let the network wsi live a bit longer if subs are active...
>> > * our frame may take a long time to chew through */
>> > if (!wsi->ws_over_h2_count)
>> > lws_set_timeout(wsi, PENDING_TIMEOUT_HTTP_KEEPALIVE_IDLE,
>> >What is the logic behind this? Any reason using the fixed value 31?
>> >Im seeing a timeout due to this.
>> An idle h2 connection with no ws streams, ie, just idle h2 streams,
>> disconnect the nwsi after 30s idle.
>> If any h2 stream carried by the nwsi does something, it'll extend the
>> network wsi timeout by 30s again.
>> Ws streams are immortal (at least timeoutwise) once established, and
>> confer that immortality on the network wsi carrying them.
>> What are you doing where this is a problem?
More information about the Libwebsockets