[Libwebsockets] Question with libwebsocket_client_connect
Subi S S
subi.s at cambiumnetworks.com
Wed Mar 11 04:19:21 CET 2015
Thanks Andy , it is clear now.
From: Andy Green [mailto:extracats at googlemail.com] On Behalf Of Andy Green
Sent: 10 March 2015 19:43
To: Subi S S; libwebsockets at ml.libwebsockets.org
Subject: Re: [Libwebsockets] Question with libwebsocket_client_connect
On 10 March 2015 22:06:12 GMT+08:00, Andy Green <andy at warmcat.com> wrote:
>On 6 March 2015 18:37:42 GMT+08:00, Subi S S
><subi.s at cambiumnetworks.com> wrote:
>>As per my understanding to make a web socket connection with server,
>>from client libwebsocket_client_connect API needs to be invoked and
>>on successful web socket connection WSI pointer will be returned and
>>NULL on connection error.
>Hm that's not quite right.
>The lws client connect occurs asynchronously.
>So a wsi is created when you ask for the connection, but he returns
>right away after initiating the tcp connection action.
>It's not until later when you run the service api and the wsi gets
>service, that he can move on his connection (according to if a proxy,
>or ssl is involved, it may take many steps performed asynchronously
>with service inbetween before he actually connects to the server).
>And later, after several steps he does handshake with the server, the
>server may say, 'no'.
>So getting a wsi back doesn't indicate anything about the connection
>health or state.
>>But in code :
>>In fuction libwebsocket_client_connect at line no : 405 ,
>>libwebsocket_client_connect_2 is invoked and in
>>libwebsocket_client_connect_2 when connect fails in certain error
>>cases, WSI is returned even though connection is not successful.
>As I explained above, getting the wsi doesn't mean it was 'successful'.
>And in this case, getting like WOULDBLOCK does not mean the connection
>It may mean SSL layer needs to SEND something on the connection before
>it can RECEIVE anything further. For example he has to send some
>crypto related data before the encrypted connection can proceed.
>So this code is arranging for the SSL layer to have sent whatever it
>needed before retrying still in the connection state that will bring us
>back to lws_client_connect_2 next time.
>> if (connect(wsi->sock, v, n) == -1 || LWS_ERRNO == LWS_EISCONN)
>> if (LWS_ERRNO == LWS_EALREADY || LWS_ERRNO ==
>> || LWS_ERRNO == LWS_EWOULDBLOCK)
>> lwsl_client("nonblocking connect
>> * must do specifically a POLLOUT poll to
>> * about the connect
>> if (lws_change_pollfd(wsi, 0,
>> if (LWS_ERRNO != LWS_EISCONN)
>> lwsl_debug("Connect failed errno=%d\n",
>>How to handle this in client code, if we assume that we not getting
>>CONNECTION_ESTABLISHED callback, is there a change of leak with wsi ??
Sorry I got into a big explanation and missed your question.
No there should be a 5s TIMEOUT covering the entire connection action by default, at which point service will kill the connection and free the wsi.
>>Libwebsockets mailing list
>>Libwebsockets at ml.libwebsockets.org
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets