[Libwebsockets] How to properly handle LWS_CALLBACK_CLIENT_CONNECTION_ERROR?

Duane Butler Duane.Butler at calix.com
Tue Jul 3 22:48:27 CEST 2018

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?



-----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



using the per-vhost protocol timer.


More information about the Libwebsockets mailing list