[Libwebsockets] How to properly handle LWS_CALLBACK_CLIENT_CONNECTION_ERROR?

Duane Butler Duane.Butler at calix.com
Tue Jul 3 23:00:46 CEST 2018


Andy, you're right, my mistake.

Thanks.

Duane.

-----Original Message-----
From: Andy Green <andy at warmcat.com> 
Sent: Tuesday, July 03, 2018 3:54 PM
To: Duane Butler <Duane.Butler at calix.com>
Cc: libwebsockets at ml.libwebsockets.org
Subject: RE: [Libwebsockets] How to properly handle LWS_CALLBACK_CLIENT_CONNECTION_ERROR?



On July 4, 2018 4:48:27 AM GMT+08:00, Duane Butler <Duane.Butler at calix.com> wrote:
>Hello Andy,
>
>I upgraded to libwebsockets 3.0 per your suggestion.
>
>I noticed one difference that is causing me some trouble.
>
>lws_client_connect_via_info() now seems to be blocking. E.g., I call 
>this function while there's no connection to the host, it returns NULL 
>after a period of time. Previously, it would return immediately
>(non-blocking) with non-NULL lws, and I would receive an 
>LWS_CALLBACK_CLIENT_CONNECTION_ERROR.
>
>Is this a known behavior change, and is there a way to make
>lws_client_connect_via_info() non-blocking in this case?

It has always been blocking wrt name resolution, which is done by the libc.  I don't think anything changed in lws AFAIK.

Is there some problem with name resolution on that box, like no network?

-Andy

>Thanks.
>
>Duane.
>
>-----Original Message-----
>From: Andy Green <andy at warmcat.com>
>Sent: Wednesday, June 27, 2018 9:06 PM
>To: Alfred Sawaya <alfred at huji.fr>; Duane Butler 
><Duane.Butler at calix.com>
>Cc: libwebsockets at ml.libwebsockets.org
>Subject: Re: [Libwebsockets] How to properly handle 
>LWS_CALLBACK_CLIENT_CONNECTION_ERROR?
>
>
>
>On 06/27/2018 10:24 PM, Alfred Sawaya wrote:
>> Hello Duane,
>> 
>> A memory leak has been corrected in the v3.0 branch. It happens 
>> exactly in your case (when a websocket fails to upgrade), can you try
>this version ?
>>
>https://github.com/warmcat/libwebsockets/commit/3f7ffeddac34e85c5c000c
>> 687dbdbd204e74b376
>
>I think that leak was introduced between 2.4 and 3.0, and corrected in 
>v3.0-stable.  So it's probably not his issue.
>
>The leak is likely fixed anyway in v3.0 though.  So please try it.
>
>If not, use valgrind and provide information about exactly what is 
>leaking.
>
>About the other things, it doesn't matter about the client info struct 
>lifetime, everything in it is copied out by the call.
>
>It sounds like OP has this working, but depending on who creates the 
>client connection, there are different ways to keep it nailed up.  If a 
>protocol basically owns the client connection, a nice way is to build 
>the retries into the protocol
>
>https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-cl
>ient/minimal-ws-client-pmd-bulk/protocol_lws_minimal_pmd_bulk.c#n81-100
>
>https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/ws-cl
>ient/minimal-ws-client-pmd-bulk/protocol_lws_minimal_pmd_bulk.c#n264-27
>0
>
>using the per-vhost protocol timer.
>
>-Andy


More information about the Libwebsockets mailing list