<div dir="ltr"><div class="gmail_default" style="font-size:x-small">HI Andy,</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I had to change the test client to add my own protocol name in the request as my server only speaks that protocol.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">That client also used to work with prior version. </div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Also I could disable the SSL support on both ends and the problem still persisted. So I concluded that this is not a SSL problem.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Yes Andy, the connection request eventually timeout like this:</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style=""><div class="gmail_default" style=""><font size="1">aiting for connect...</font></div><div class="gmail_default" style=""><font size="1">[1467754420:5046] CLIENT: lws_client_connect_2</font></div><div class="gmail_default" style=""><font size="1">[1467754420:5047] CLIENT: lws_client_connect_2: address 192.168.1.202</font></div><div class="gmail_default" style=""><font size="1">[1467754420:5047] CLIENT: connected</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER] fd=6 user=[NULL] len=3794</font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1">[1467754441:5268] NOTICE: wsi 0xbea580: TIMEDOUT WAITING on 4 (did hdr 0, ah 0xbba730, wl 0, pfd events 0)</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5268] ERR: *** not on ah wait list ***</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5268] INFO: lws_close_free_wsi: real just_kill_connection: 0xbea580</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5269] INFO: remove_wsi_socket_from_fds: wsi=0xbea580, sock=6, fds pos=1, end guy pos=2, endfd=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5269] DEBUG: Connection closed before server reply</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_CLIENT_CONNECTION_ERROR] fd=6 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=-1 user=[NULL] len=0</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5270] INFO: lws_header_table_detach: wsi 0xbea580: ah 0xbba730 (tsi=0, count = 1)</font></div><div class="gmail_default" style=""><font size="1">[1467754441:5270] ERR: header assign - free time 21</font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1"><br></font></div><div class="gmail_default" style=""><font size="1">It seems like after the </font><span style="font-size:x-small">LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER, nothing happens.</span></div><div class="gmail_default" style=""><span style="font-size:x-small"><br></span></div><div class="gmail_default" style=""><span style="font-size:x-small"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 5:26 PM, Andy Green <span dir="ltr"><<a href="mailto:andy@warmcat.com" target="_blank">andy@warmcat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On July 6, 2016 4:28:03 AM GMT+08:00, Brice Hamon <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>Thanks Roger,<br>
><br>
>I'll look into it if I am unable to find the root cause otherwise.<br>
<br>
</span>Git bisect is a good idea and the lws history is almost always buildable at any commit.  I thought it might be quicker to pull on the symptom end but maybe not.<br>
<span class=""><br>
>A little bit of progress.<br>
><br>
>1) The test server and client do work on my platform. So the problem is<br>
>in<br>
>my code somewhere.<br>
<br>
</span>Too early to say, since we don't know what the problem is.  But it means your toolchain + platform + lws version can basically work if it does what the test apps do.<br>
<span class=""><br>
>2) I changed the client's test program and now I can see that the<br>
<br>
</span>What does it mean "changed the client's test program"?<br>
<span class=""><br>
>client<br>
>get connected to the server, but nothing after that.<br>
>That rules out a network transport problem.<br>
<br>
</span>It just means "'connection refused" was bogus.<br>
<span class=""><br>
>libwebsockets test client<br>
<br>
>SSL Usage: Yes<br>
>[1467750112:5381] NOTICE: Initial logging level 65535<br>
>[1467750112:5382] NOTICE: Libwebsockets version: 1.7.0 ac4b079<br>
>[1467750112:5382] NOTICE: IPV6 not compiled in<br>
>[1467750112:5383] NOTICE: libev support not compiled in<br>
>[1467750112:5383] INFO:  LWS_DEF_HEADER_LEN    : 1024<br>
>[1467750112:5383] INFO:  LWS_MAX_PROTOCOLS     : 5<br>
>[1467750112:5384] INFO:  LWS_MAX_SMP           : 32<br>
<br>
</span>This defaults to 1 on later lws anyway, but it's likely unrelated if the test apps are ok.<br>
<div><div class="h5"><br>
>[1467750112:5384] INFO:  SPEC_LATEST_SUPPORTED : 13<br>
>[1467750112:5384] INFO:  sizeof (*info)        : 216<br>
>[1467750112:5385] INFO:  SYSTEM_RANDOM_FILEPATH: '/dev/urandom'<br>
>[1467750112:5385] INFO:  default timeout (secs): 20<br>
>[1467750112:5386] NOTICE:  Threads: 1 each 1024 fds<br>
>[1467750112:5387] INFO:  mem: context:          9800 bytes (5704 ctx +<br>
>(1<br>
>thr x 4096))<br>
>[1467750112:5387] INFO:  mem: http hdr rsvd:   67712 bytes (1 thr x<br>
>(1024 +<br>
>3208) x 16))<br>
>[1467750112:5388] INFO:  mem: pollfd map:       8192<br>
>[1467750112:5388] NOTICE:  mem: platform fd map:  8192 bytes<br>
>[1467750112:5389] INFO:  LWS_MAX_EXTENSIONS_ACTIVE: 2<br>
>[1467750112:5389] NOTICE:  mem: per-conn:          376 bytes + protocol<br>
>rx<br>
>buf<br>
>[1467750112:5390] NOTICE:  canonical_hostname = bs1<br>
>callback_bsws [LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS]<br>
>fd=0<br>
>user=[�`ơ#] len=0<br>
>callback_bsws [LWS_CALLBACK_PROTOCOL_INIT] fd=0 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=-1 user=[NULL]<br>
>len=0<br>
>libbswslog: [LOG_INFO]: lws_client_connect: direct conn<br>
><br>
>libbswslog: [LOG_INFO]: lws_client_connect_2<br>
><br>
>libbswslog: [LOG_INFO]: lws_client_connect_2: address 192.168.1.202<br>
><br>
>callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1<br>
>callback_bsws [LWS_CALLBACK_ADD_POLL_FD] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1<br>
>libbswslog: [LOG_INFO]: nonblocking connect retry<br>
><br>
>callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
>Waiting for connect...<br>
>libbswslog: [LOG_INFO]: lws_client_connect_2<br>
><br>
>libbswslog: [LOG_INFO]: lws_client_connect_2: address 192.168.1.202<br>
><br>
>libbswslog: [LOG_INFO]: connected<br>
<br>
</div></div>Hm.  "Connection refused" was a red herring then, it's not refused and does connect.<br>
<span class=""><br>
>Then when I kill the server:<br>
><br>
>callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER] fd=6<br>
>user=[NULL] len=3794<br>
<br>
</span>This comes when the client is creating his upgrade request to use ws instead of http.<br>
<br>
But that should be sequenced automatically to be done after the connect state, not happen when the peer died.<br>
<br>
What is the situation with this "changed" test client about it getting service?<br>
<span class="HOEnZb"><font color="#888888"><br>
-Andy<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER] fd=6<br>
>user=[NULL] len=3794<br>
>callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL] len=1<br>
>callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6 user=[NULL] len=0<br>
>callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL] len=1<br>
>callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=6 user=[NULL] len=0<br>
><br>
><br>
>Thanks guys.<br>
>Brice.<br>
><br>
><br>
>On Tue, Jul 5, 2016 at 3:47 PM, Roger Light <<a href="mailto:roger@atchoo.org">roger@atchoo.org</a>> wrote:<br>
><br>
>> Hi Brice,<br>
>><br>
>> If you've got a working and a non-working version, then a good option<br>
>> is to use "git bisect" to find the problem commit.<br>
>><br>
>> git clone <a href="https://github.com/warmcat/libwebsockets" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets</a> lws-bisect<br>
>> cd lws-bisect<br>
>> git bisect start<br>
>> git bisect good v1.6.0-chrome48-firefox42 # assuming this one works<br>
>> git bisect bad v1.7.0 # assuming this version doesn't<br>
>><br>
>> git will then checkout a changeset for you to test - so make your<br>
>> build directory, run cmake and carry out your tests. If the test is<br>
>> successful, run "git bisect good", else run "git bisect bad". You'll<br>
>> have to carry out roughly 6 tests. At the end of the process you'll<br>
>be<br>
>> told which commit in libwebsockets produced the error you are seeing<br>
>-<br>
>> assuming that the problem is with libwebsockets of course.<br>
>><br>
>> When you're running your tests, make sure you start from a clean<br>
>build<br>
>> and that your own client code is also recompiled against the test<br>
>> version.<br>
>><br>
>> Best of luck,<br>
>><br>
>> Roger<br>
>><br>
>><br>
>><br>
>> On Tue, Jul 5, 2016 at 6:48 PM, Brice Hamon <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>> wrote:<br>
>> > Thanks Andy,<br>
>> ><br>
>> > I will report my progress.<br>
>> ><br>
>> > The "Connection refused" is reported by the browser (Chrome), so as<br>
>you<br>
>> > said, it could be something not transport related, but rather SSL<br>
>as  I<br>
>> am<br>
>> > inclined to think.<br>
>> ><br>
>> > Thanks<br>
>> > Brice.<br>
>> ><br>
>> > On Tue, Jul 5, 2016 at 1:44 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On July 5, 2016 11:40:30 PM GMT+08:00, Brice Hamon<br>
>> >> <<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>> >> >Hi Andy,<br>
>> >> ><br>
>> >> >I have not made progress on finding where the problem is.<br>
>> >> ><br>
>> >> >One thing I was doing and seemed strange was in the SSL certs<br>
>side:<br>
>> >> ><br>
>> >> >if (http_ssl_)<br>
>> >> >    {<br>
>> >> >        if (!chain_file_.empty())<br>
>> >> >        {<br>
>> >> >          // cert file is not needed as it's included in the<br>
>chain with<br>
>> >> >all intermediate cert.<br>
>> >> >            //info.ssl_cert_filepath = cert_file_.c_str();<br>
>> >> >            info.ssl_private_key_filepath = key_file_.c_str();<br>
>> >> >            info.ssl_cert_filepath = chain_file_.c_str();<br>
>> >> >        }<br>
>> >> >        else<br>
>> >> >        {<br>
>> >> >            // Simple key/cert WSS<br>
>> >> >            info.ssl_cert_filepath = cert_file_.c_str();<br>
>> >> >            info.ssl_private_key_filepath = key_file_.c_str();<br>
>> >> >        }<br>
>> >> >    }<br>
>> >> >    else<br>
>> >> >    {<br>
>> >> >        info.ssl_cert_filepath = NULL;<br>
>> >> >        info.ssl_private_key_filepath = NULL;<br>
>> >> >    }<br>
>> >> ><br>
>> >> >    info.gid = -1;<br>
>> >> >    info.uid = -1;<br>
>> >> >    info.options = 0;<br>
>> >> >    info.ka_time = 10; // keep alive every 10<br>
>> >> >    info.ka_probes = 1; // how many times to try to get response<br>
>before<br>
>> >> >giving up<br>
>> >> >    info.ka_interval = 2; // how long to wait before each<br>
>ka_probes<br>
>> >> >    info.user = this; // to get ourself inthe static callback via<br>
>the<br>
>> >> >context.<br>
>> >> ><br>
>> >> >    context_ = libwebsocket_create_context(&info);<br>
>> >> ><br>
>> >> ><br>
>> >> >and this was the only way I made the lib work with 3 ssl files<br>
>(key,<br>
>> >> >cert<br>
>> >> >and chain).<br>
>> >> ><br>
>> >> >I tried the "correct" way with<br>
>> >> ><br>
>> >> >info.ssl_cert_filepath        = cert_file_.c_str();<br>
>> >> >info.ssl_private_key_filepath = key_file_.c_str();<br>
>> >> >info.ssl_ca_filepath          = chain_file_.c_str();<br>
>> >> ><br>
>> >> >With no luck.<br>
>> >> ><br>
>> >> >Any clues?<br>
>> >><br>
>> >> Yeah your biggest clue is "Connection Refused".<br>
>> >><br>
>> >> Also you should sanity-check the lws test server itself works on<br>
>your<br>
>> >> toolchain / platform.<br>
>> >><br>
>> >> >I think if we find the problem in 1.7, 2.0 will work as well.<br>
>> >><br>
>> >> I understand it looks like that to you, since you try 1.6 and it<br>
>works<br>
>> and<br>
>> >> 1.7 acts different.  But it's not clear the problem is in the lib.<br>
>> It's not<br>
>> >> even clear to me what the problem is.<br>
>> >><br>
>> >> If it was happening to me I would grab hold of the Connection<br>
>Refused<br>
>> end<br>
>> >> of it, eg look what netstat says and eyeball traffic with tcpdump.<br>
> The<br>
>> lib<br>
>> >> doesn't issue a tcp connection refused, as I explained it means<br>
>> something<br>
>> >> basic like the listen socket is not there.<br>
>> >><br>
>> >> So the first move is confirm if that is literally a tcp connection<br>
>> >> refused, or you mean some handwaving 'communication failed' error<br>
>that<br>
>> is<br>
>> >> actually something totally different and a red herring.<br>
>> >><br>
>> >> Build it in debug mode<br>
>> >><br>
>> >> cmake -DCMAKE_BUILD_TYPE=DEBUG<br>
>> >><br>
>> >> and crank the logs up, equivalent to -d65535 on the test apps and<br>
>look<br>
>> in<br>
>> >> there both at init and at connection attempt.  Compare the logs<br>
>for test<br>
>> >> server in the same cases.<br>
>> >><br>
>> >> -Andy<br>
>> >><br>
>> >> >Thank you in advance,<br>
>> >> >Brice.<br>
>> >> ><br>
>> >> ><br>
>> >> >On Mon, Jul 4, 2016 at 5:29 PM, Brice Hamon<br>
><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>> >> >wrote:<br>
>> >> ><br>
>> >> >> Ok 1.7.0 breaks the server. All version before are OK.<br>
>> >> >><br>
>> >> >> The only change I can see impacting my code was the warning:<br>
>> >> >><br>
>> >> >> bswebsocket.cpp:155:23: warning: `const lws_extension*<br>
>> >> >> lws_get_internal_extensions()' is deprecated (declared at<br>
>> >> >> /export/home/development/3rdparty/include/libwebsockets.h:1877)<br>
>> >> >> [-Wdeprecated-declarations]<br>
>> >> >><br>
>> >> >> So I am investigating in that side.<br>
>> >> >><br>
>> >> >> On Mon, Jul 4, 2016 at 4:25 PM, Brice Hamon<br>
><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a><br>
>> ><br>
>> >> >> wrote:<br>
>> >> >><br>
>> >> >>> Hi Andy,<br>
>> >> >>><br>
>> >> >>> I am working backwards in version. So far 2.0.2 to 1.7.2 does<br>
>not<br>
>> >> >work.<br>
>> >> >>> 1.5.1 does work. I will eventually where it breaks.<br>
>> >> >>><br>
>> >> >>> I'll keep you posted.<br>
>> >> >>><br>
>> >> >>> On Thu, Jun 30, 2016 at 1:13 PM, Brice Hamon<br>
>> >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>> >> >>> wrote:<br>
>> >> >>><br>
>> >> >>>> Thanks Andy,<br>
>> >> >>>><br>
>> >> >>>> I do not think it is a networking or environment issue as the<br>
>same<br>
>> >> >code<br>
>> >> >>>> running on the same host with 1.4 works and not 2.0.<br>
>> >> >>>><br>
>> >> >>>> I just wanted to make sure I did not forgot an new call to<br>
>init SSL<br>
>> >> >or<br>
>> >> >>>> something like that not present in 1.4.<br>
>> >> >>>><br>
>> >> >>>> I'll dig into it and report back.<br>
>> >> >>>><br>
>> >> >>>> Thanks again<br>
>> >> >>>> Brice.<br>
>> >> >>>><br>
>> >> >>>> On Wed, Jun 29, 2016 at 1:56 PM, Andy Green<br>
><<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>> >> >wrote:<br>
>> >> >>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>> On June 29, 2016 11:52:31 PM GMT+08:00, Brice Hamon <<br>
>> >> >>>>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>> >> >>>>> >Hi Andy,<br>
>> >> >>>>> ><br>
>> >> >>>>> >I just upgraded my server from 1.4 to 2.0.<br>
>> >> >>>>> ><br>
>> >> >>>>> >Not really a big task, just lws_ and a couple of<br>
>adjustments,<br>
>> >> >>>>> ><br>
>> >> >>>>> >But now my server does not work anymore.  I use an external<br>
>> >> >polling<br>
>> >> >>>>> >mechanism, and I see the first FD_ADD so the epoll is<br>
>working.<br>
>> >> >>>>><br>
>> >> >>>>> That doesn't follow actually, it means only that lws' code<br>
>to<br>
>> >> >expose<br>
>> >> >>>>> poll fds changes to the callback is working; it's caused by<br>
>> >> >creating the<br>
>> >> >>>>> listen socket during init, not by servicing (e)poll events.<br>
>The<br>
>> >> >log<br>
>> >> >>>>> doesn't show any evidence of servicing (e)poll events.<br>
>> >> >>>>><br>
>> >> >>>>> >But when I try to connect with a browser or client program<br>
>I get<br>
>> >> >a CONN<br>
>> >> >>>>> >REFUSED and I don't see anything happening on the server<br>
>side. I<br>
>> >> >just<br>
>> >> >>>>> >see<br>
>> >> >>>>> >it listening on the correct port.<br>
>> >> >>>>><br>
>> >> >>>>> Connection refused is really specific, it means for the peer<br>
>there<br>
>> >> >was<br>
>> >> >>>>> nobody listening at the port.  That can mean the listen<br>
>socket<br>
>> >> >bound to a<br>
>> >><br>
>> >> This observation is still true if it's literally "Connection<br>
>Refused".<br>
>> >><br>
>> >> -Andy<br>
>> >><br>
>> >> >>>>> different interface than your client reached (check it with<br>
>> >> >netstat -pltn<br>
>> >> >>>>> at the server, 0.0.0.0 means all interfaces) or a firewall<br>
>got in<br>
>> >> >the way,<br>
>> >> >>>>> or you reached the wrong ip (name resolution issue at<br>
>client).<br>
>> >> >>>>><br>
>> >> >>>>> >I compiled the lib plain vanilla with no options.<br>
>> >> >>>>> ><br>
>> >> >>>>> >Here is what I get as startup from your lib:<br>
>> >> >>>>> ><br>
>> >> >>>>> ><br>
>> >> >>>>> >16-06-29 11:38:24.694159 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Initial<br>
>> >> >>>>> >logging<br>
>> >> >>>>> >level 15<br>
>> >> >>>>> >16-06-29 11:38:24.694176 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >>>>> >Libwebsockets<br>
>> >> >>>>> >version: 2.0.0 xxxx@xxxx-v2.0.0-95-ge943a02<br>
>> >> >>>>> >16-06-29 11:38:24.694181 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>IPV6<br>
>> >> >not<br>
>> >> >>>>> >compiled in<br>
>> >> >>>>> >16-06-29 11:38:24.694193 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>libev<br>
>> >> >>>>> >support<br>
>> >> >>>>> >not compiled in<br>
>> >> >>>>> >16-06-29 11:38:24.694198 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>libuv<br>
>> >> >>>>> >support<br>
>> >> >>>>> >not compiled in<br>
>> >> >>>>> >16-06-29 11:38:24.694356 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Threads: 1<br>
>> >> >>>>> >each 1024 fds<br>
>> >> >>>>> >16-06-29 11:38:24.694453 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> mem:<br>
>> >> >>>>> >platform<br>
>> >> >>>>> >fd map:  8192 bytes<br>
>> >> >>>>> >16-06-29 11:38:24.694526 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Compiled<br>
>> >> >>>>> >with<br>
>> >> >>>>> >OpenSSL support<br>
>> >> >>>>> >16-06-29 11:38:24.695057 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Creating<br>
>> >> >>>>> >Vhost<br>
>> >> >>>>> >'default' port 7682, 2 protocols, IPv6 off<br>
>> >> >>>>> >16-06-29 11:38:24.695102 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Using SSL<br>
>> >> >>>>> >mode<br>
>> >> >>>>> >16-06-29 11:38:24.698961 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> SSL<br>
>> >> >ECDH<br>
>> >> >>>>> >curve<br>
>> >> >>>>> >'prime256v1'<br>
>> >> >>>>> >16-06-29 11:38:24.699011 INFO : [WEBSOCKET ]: callback_http<br>
>> >> >>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS fd=0<br>
>> >> >>>>> >context=0x7efff0002800 user=[`uZ&] len=0<br>
>> >> >>>>> >16-06-29 11:38:24.699021 ERROR: [WEBSOCKET ]:<br>
>callback_http: case<br>
>> >> >>>>> >LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS not<br>
>handled.<br>
>> >> >>>>> >16-06-29 11:38:24.700680 INFO : [WEBSOCKET ]: callback_http<br>
>> >> >>>>> >LWS_CALLBACK_LOCK_POLL fd=85 context=0x7efff0002800<br>
>user=[NULL]<br>
>> >> >len=1<br>
>> >> >>>>> >16-06-29 11:38:24.700719 INFO : [WEBSOCKET ]: callback_http<br>
>> >> >>>>> >LWS_CALLBACK_ADD_POLL_FD fd=85 context=0x7efff0002800<br>
>user=[NULL]<br>
>> >> >len=0<br>
>> >> >>>>> >16-06-29 11:38:24.700758 INFO : [WEBSOCKET ]: callback_http<br>
>> >> >>>>> >LWS_CALLBACK_UNLOCK_POLL fd=85 context=0x7efff0002800<br>
>user=[NULL]<br>
>> >> >len=1<br>
>> >> >>>>> >16-06-29 11:38:24.700811 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >Listening<br>
>> >> >>>>> >on<br>
>> >> >>>>> >port 7682<br>
>> >> >>>>> >16-06-29 11:38:24.700834 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> mem:<br>
>> >> >>>>> >per-conn:<br>
>> >> >>>>> >         496 bytes + protocol rx buf<br>
>> >> >>>>> >16-06-29 11:38:24.700919 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >>>>> > canonical_hostname = xxxx<br>
>> >> >>>>> ><br>
>> >> >>>>> >Then a<br>
>> >> >>>>> ><br>
>> >> >>>>> >16-06-29 11:38:25.972014 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
>> >> >>>>> >lws_protocol_init<br>
>> >> >>>>> >16-06-29 11:38:25.972043 INFO : [WEBSOCKET ]: callback_http<br>
>> >> >>>>> >LWS_CALLBACK_PROTOCOL_INIT fd=0 context=0x7efff0002800<br>
>> >> >user=[NULL]<br>
>> >> >>>>> >len=0<br>
>> >> >>>>> >16-06-29 11:38:25.972049 INFO : [WEBSOCKET ]:<br>
>callback_http:<br>
>> >> >>>>> >LWS_CALLBACK_PROTOCOL_INIT<br>
>> >> >>>>> ><br>
>> >> >>>>> >And nothing else after that.<br>
>> >> >>>>><br>
>> >> >>>>> Connection Refused is a tcp level thing, it means you did<br>
>not<br>
>> >> >succeed<br>
>> >> >>>>> to touch the listen socket.  So there would be no sign of<br>
>activity<br>
>> >> >from lws<br>
>> >> >>>>> about that.<br>
>> >> >>>>><br>
>> >> >>>>> >I guess  my straight port from 1.4 to 2.0 was just been<br>
>> >> >optimistic. I<br>
>> >> >>>>> >am<br>
>> >> >>>>> >forgetting something essential in order to have 2.0 working<br>
>like<br>
>> >> >in<br>
>> >> >>>>> >1.4.<br>
>> >> >>>>><br>
>> >> >>>>> I think either lws bound to the wrong network interface for<br>
>> >> >listen, or<br>
>> >> >>>>> the issue is outside lws.<br>
>> >> >>>>><br>
>> >> >>>>> >Also the only question I had during the port is that I used<br>
>the<br>
>> >> >>>>> >context->user pointer to store my own websocket object. I<br>
>now<br>
>> >> >need to<br>
>> >> >>>>> >to a<br>
>> >> >>>>> >// Getting the context from the wsi<br>
>> >> >>>>> >struct lws_context *wsicont = lws_get_context(wsi);<br>
>> >> >>>>> ><br>
>> >> >>>>> >// Getting the user cd from the context<br>
>> >> >>>>> >BSWebSocket *websocket = (BSWebSocket<br>
>> >> >*)lws_context_user(wsicont);<br>
>> >> >>>>> ><br>
>> >> >>>>> >Is there a better way to do that? I already use the user<br>
>pointer<br>
>> >> >of the<br>
>> >> >>>>> >callback to get my per_session_data structure.<br>
>> >> >>>>><br>
>> >> >>>>> No it looks good.  Both of those apis are really cheap, just<br>
>> >> >resolve to<br>
>> >> >>>>> a struct member dereference each.<br>
>> >> >>>>><br>
>> >> >>>>> -Andy<br>
>> >> >>>>><br>
>> >> >>>>> >Thank you,<br>
>> >> >>>>> ><br>
>> >> >>>>> >Brice.<br>
>> >> >>>>> ><br>
>> >> >>>>> ><br>
>> >> >>>>> >On Thu, Jun 2, 2016 at 8:48 PM, Brice Hamon<br>
>> >> ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
>> >> >>>>> >wrote:<br>
>> >> >>>>> ><br>
>> >> >>>>> >> Thank you Andy,<br>
>> >> >>>>> >><br>
>> >> >>>>> >> I will get going and report my findings.<br>
>> >> >>>>> >><br>
>> >> >>>>> >> Thanks again.<br>
>> >> >>>>> >> Brice.<br>
>> >> >>>>> >><br>
>> >> >>>>> >><br>
>> >> >>>>> >> On Thu, Jun 2, 2016 at 6:20 PM, Andy Green<br>
><<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
>> >> >wrote:<br>
>> >> >>>>> >><br>
>> >> >>>>> >>><br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> On June 3, 2016 1:08:32 AM GMT+08:00, Brice Hamon <<br>
>> >> >>>>> >>> <a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>> wrote:<br>
>> >> >>>>> >>> >Hi all,<br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>> >I have been using libwebsocket 1.4 with external epoll<br>
>> >> >notification<br>
>> >> >>>>> >>> >loop<br>
>> >> >>>>> >>> >without a single problem for over a year now.<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> Great.<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> >All the libwebsocket functions are happening in one<br>
>thread so<br>
>> >> >I<br>
>> >> >>>>> >have<br>
>> >> >>>>> >>> >followed all guidelines in the README.coding<br>
>> >> >>>>> >>> >from that version.<br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>> >I think it is now time for me to upgrade as, following<br>
>this<br>
>> >> >group,<br>
>> >> >>>>> >many<br>
>> >> >>>>> >>> >fix<br>
>> >> >>>>> >>> >and enhancement took place.<br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>> >Is there specific areas of change I should be concerned<br>
>with,<br>
>> >> >or<br>
>> >> >>>>> >>> >important<br>
>> >> >>>>> >>> >changes in the notification area?<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> Yes at 1.6 many api names got simplified and<br>
>rationalized.<br>
>> >> >Mainly<br>
>> >> >>>>> >the<br>
>> >> >>>>> >>> api prefix got standardized to 'lws_'.  There are 4<br>
>steps<br>
>> >> >listed in<br>
>> >> >>>>> >the<br>
>> >> >>>>> >>> changelog<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>><br>
>> >> >>>>> ><br>
>> >> >>>>><br>
>> >> ><br>
>><br>
><a href="https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog#L643" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/v2.0-stable/changelog#L643</a><br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> to search / replace everything in your code into shape.<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> There are many other changes and improvements, such as<br>
>> >> >multiple<br>
>> >> >>>>> >vhost<br>
>> >> >>>>> >>> support, CGI support, protocol plugins, lwsws etc.  It's<br>
>hard<br>
>> >> >to<br>
>> >> >>>>> >predict<br>
>> >> >>>>> >>> which are interesting, if you have external epoll() just<br>
>to<br>
>> >> >get<br>
>> >> >>>>> >epoll, the<br>
>> >> >>>>> >>> new built-in libuv support might be interesting... if so<br>
>then<br>
>> >> >lwsws<br>
>> >> >>>>> >and<br>
>> >> >>>>> >>> plugins might also simplify your life.<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> If you need external event loop to interface to<br>
>something<br>
>> >> >else, then<br>
>> >> >>>>> >that<br>
>> >> >>>>> >>> should still work the same.<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> >Thanks all and especially Andy, your lib rocks :)<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> Thanks for the kind words ^^<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> -Andy<br>
>> >> >>>>> >>><br>
>> >> >>>>> >>> >Brice.<br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >><br>
>> >> >>><br>
>><br>
>>>>------------------------------------------------------------------------<br>
>> >> >>>>> >>> ><br>
>> >> >>>>> >>> >_______________________________________________<br>
>> >> >>>>> >>> >Libwebsockets mailing list<br>
>> >> >>>>> >>> ><a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
>> >> >>>>> >>> ><a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>> >> >>>>> >>><br>
>> >> >>>>> >>><br>
>> >> >>>>> >><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>><br>
>> >> >>><br>
>> >> >><br>
>> >><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Libwebsockets mailing list<br>
>> > <a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
>> > <a href="http://libwebsockets.org/mailman/listinfo/libwebsockets" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsockets</a><br>
>> ><br>
>><br>
<br>
</div></div></blockquote></div><br></div>