[Libwebsockets] EXT: Re: EXT: Re: disconnection after 310 secondes

Peiffer Eric eric.peiffer at al-enterprise.com
Wed Sep 30 09:26:32 CEST 2020


OK, I got it,

But if the ping/pong mechanism is enable on web socket level, with a period less than the validity time out,
connection will never be closed by this validity timeout?

Regards,

Eric
________________________________
De : Andy Green <andy at warmcat.com>
Envoyé : mardi 29 septembre 2020 18:42
À : Peiffer Eric <eric.peiffer at al-enterprise.com>; libwebsockets at ml.libwebsockets.org <libwebsockets at ml.libwebsockets.org>
Objet : EXT: Re: EXT: Re: [Libwebsockets] disconnection after 310 secondes


** External email - Please consider with caution **


On 9/29/20 4:05 PM, Peiffer Eric wrote:
> Hi,
>
> I have put this
>
> |lws_validity_confirmed(wsi);
>
> efter each LWS_CALLBACK_RECEIVE, and it's work better.
>
> But what I can not anderstand is that, may server connect xmpp client
> through web socket connections. Each web socket client send to the server
> a xmpp ping and the server response to this ping. This for each client
> and each minutes.
> Thean I can not anderstand why this timeout aoccurs, because each minute
> there data in the both direction.

"Data in both directions" is not what it wants to confirm, it wants to
confirm that we sent something and received something that we can only
get if the peer truly received what we sent.

It's not confirming the validity of the connection if simply one side
thinks he can send something, and he receives something... it's like
saying one guy is talking into the telephone, and the other guy is going
"hm" every now and again... it can all be true and in fact they are not
having a conversation at all.

Kernel will continue to accept send data from userland and let it pile
up kernelside for many minutes, even when the ethernet cable is pulled
out.  Routes on the internet for outbound packets may be completely
different than the route for inbound packets.  The validity thing is for
when you saw something that can only mean it is all working, like PING
with a payload that is echoed by the PONG.

-Andy

> Regards,
>
> Eric
> |
>
>
> ------------------------------------------------------------------------
> *De :* Andy Green <andy at warmcat.com>
> *Envoyé :* mardi 29 septembre 2020 14:57
> *À :* Peiffer Eric <eric.peiffer at al-enterprise.com>;
> libwebsockets at ml.libwebsockets.org <libwebsockets at ml.libwebsockets.org>
> *Objet :* EXT: Re: [Libwebsockets] disconnection after 310 secondes
>
> ** External email - Please consider with caution **
>
>
> On 9/29/20 1:48 PM, Peiffer Eric wrote:
>> Hi,
>>
>> I have put libwebsockets trace to the max in order to see  what's happened.
>> And just before I receive the LWS_CALLBACK_CLOSED I have the following
>> traces:
>>
>>
>> level: 8 log: lws_validity_cb: wsi 0x7f66ac00dad0: *validity too old*
>
> If your connections are actually doing stuff in both directions during
> this time, you can notify lws using lws_validity_confirmed(wsi) when you
> saw something that means the connection must be working in both directions
>
> https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-timeout-timer.h#n329-349
>
> and it will reset this timeout.
>
> At context / vhost creation time you can set the timeouts
>
> https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-context-vhost.h#n728-731
>
> point to a lws_retry_bo_t and set these (in secs)
>
> https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-retry.h#n29-30
>
> if you don't, they use the context default which is for ~5min.
>
> -Andy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20200930/232707d5/attachment.htm>


More information about the Libwebsockets mailing list