<div dir="ltr"><div class="gmail_default" style="font-size:x-small">Thanks Andy,</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Maybe the event is not consumed in lws due to a state issue, from an incorrect use of the lib on my side.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I'll upgrade to 1.7.8 and debug it tomorrow and report.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Brice.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 6, 2016 at 10:24 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="">On Wed, 2016-07-06 at 22:12 -0400, Brice Hamon wrote:<br>
> You're correct Andy, but in my framework, the even is checked before<br>
> calling that method.<br>
<br>
</span>You didn't show that when you pasted the code...<br>
<span class=""><br>
> The event is READ and I am calling lws on the correct fd.<br>
><br>
> This spinning is not happening in 1.6 or previous version.<br>
<br>
</span>I wouldn't get too hung up about that as necessarily meaningful.  It<br>
does not happen on any version without your code / external libev<br>
integration for example.<br>
<br>
You have to debug it and see where it leads.<br>
<span class=""><br>
> I'll debug this tomorrow and report, but it seems to me that lws is<br>
> not triggering a read() of the fd hence the event is not consumed.<br>
<br>
</span>Yes... but why?  And why does lws work with lws own poll(), libev and<br>
libuv support?  One reason could have been the .event not being<br>
unmasked, but you're ruling that out.<br>
<br>
You'll have to follow it on one of these looping events and see what<br>
happens inside lws that it doesn't read / accept it.<br>
<br>
I guess this 'read' is signalling that the listen socket has a<br>
connection to accept, you can check it in a debugger by looking at wsi-<br>
>listener.<br>
<br>
Also... 1.7.0 had its share of bugs, the stable branch for it is at<br>
1.7.8 and you should better use that.  I don't recall anything like<br>
this though, and you mention the problem still coming on master.<br>
<br>
-Andy<br>
<div><div class="h5"><br>
<br>
> On Wed, Jul 6, 2016 at 2:04 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>> wrote:<br>
> ><br>
> > On July 7, 2016 1:27:28 AM GMT+08:00, Brice Hamon <normandviking@gm<br>
> > <a href="http://ail.com" rel="noreferrer" target="_blank">ail.com</a>> wrote:<br>
> > >More findings:<br>
> > ><br>
> > >Once the client connects to my server, I am spinning in the fd<br>
> > >notification<br>
> > >callback from my epoll mecanism, from which I call lws.<br>
> ><br>
> > That sounds more like you're getting closer to the actual issue.<br>
> ><br>
> > >    pollfd tmpollfd;<br>
> > >    memset(&tmpollfd, 0, sizeof(tmpollfd));<br>
> > >    tmpollfd.fd = fd;<br>
> > >    tmpollfd.revents = 0;<br>
> > ><br>
> > >    if (event & EVENT_READ ||  event & EVENT_READ_PRI)<br>
> > >        tmpollfd.revents |= POLLIN;<br>
> > ><br>
> > >    if (event & EVENT_CLOSE)<br>
> > >        tmpollfd.revents |= POLLRDHUP;<br>
> > ><br>
> > >    if(event & EVENT_ERROR)<br>
> > >        tmpollfd.revents |= POLLRDHUP ;<br>
> > ><br>
> > >    if (event & EVENT_WRITE)<br>
> > >        tmpollfd.revents |= POLLOUT;<br>
> ><br>
> > So which event is it spinning on?  Gdb and step what happens might<br>
> > shine some light.<br>
> ><br>
> > If, for example, you report a .revent that actually has no .event<br>
> > set, because your event mask at epoll is inconsistent with lws<br>
> > pollfd .event mask, it might spin.  So you should be able to check<br>
> > for that.<br>
> ><br>
> > -Andy<br>
> ><br>
> > >    return libwebsocket_service_fd(context_, &tmpollfd);<br>
> > ><br>
> > ><br>
> > >I check and libwebsocket_service_fd() returns 0.<br>
> > ><br>
> > >This code is untouched from 1.4 version.<br>
> > ><br>
> > >Thanks.<br>
> > ><br>
> > ><br>
> > ><br>
> > >On Wed, Jul 6, 2016 at 9:02 AM, Brice Hamon <normandviking@gmail.c<br>
> > om><br>
> > >wrote:<br>
> > ><br>
> > >> Hi Andy,<br>
> > >><br>
> > >> Yes only one is running. I check with netstat. I recompiled lws<br>
> > with<br>
> > >> -DLWS_MAX_SMP=1.<br>
> > >><br>
> > >> No change, the problem is still there.<br>
> > >><br>
> > >> I believe that the problem is in the server's side as the lws<br>
> > test<br>
> > >client<br>
> > >> and the browser failed to establish a WS connection. At least I<br>
> > now<br>
> > >know it<br>
> > >> is not SSL related.<br>
> > >><br>
> > >> I will now investigate the server side and report back.<br>
> > >><br>
> > >> If you think at something obvious in the way 1.7 server side<br>
> > works<br>
> > >versus<br>
> > >> 1.6, please let me know.<br>
> > >><br>
> > >> Thanks<br>
> > >><br>
> > >> On Tue, Jul 5, 2016 at 11:50 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
> > wrote:<br>
> > >><br>
> > >>> On Tue, 2016-07-05 at 23:08 -0400, Brice Hamon wrote:<br>
> > >>> > Yes I did not wait for 20 seconds to timeout the first time.<br>
> > >>> ><br>
> > >>> > I attached the tcp dump for that port taken from the client<br>
> > >machine.<br>
> > >>><br>
> > >>> Clearly the client thinks he sends the upgrade<br>
> > >>><br>
> > >>> 22:56:37.579369 IP bs1.blueskysystem.net.46119 ><br>
> > >>> bs2.blueskysystem.net.7682: Flags [P.], seq 1:293, ack 1, win<br>
> > 229,<br>
> > >>> options [nop,nop,TS val 1553449881 ecr 1553345730], length 292<br>
> > >>>         0x0000:  4500 0158 e634 4000 4006 ce87 c0a8<br>
> > >>> 01c9  E..X.4@.@.......<br>
> > >>>         0x0010:  c0a8 01ca b427 1e02 428c 25ab 7144<br>
> > >>> 4265  .....'..B.%.qDBe<br>
> > >>>         0x0020:  8018 00e5 b057 0000 0101 080a 5c97<br>
> > >>> c399  .....W......\...<br>
> > >>>         0x0030:  5c96 2cc2 4745 5420 2f20 4854 5450<br>
> > >>> 2f31  \.,.GET./.HTTP/1<br>
> > >>>         0x0040:  2e31 0d0a 5072 6167 6d61 3a20 6e6f<br>
> > >>> 2d63  .1..Pragma:.no-c<br>
> > >>>         0x0050:  6163 6865 0d0a 4361 6368 652d 436f 6e74<br>
> > >ache..Cache-<br>
> > >>> Cont<br>
> > >>>         0x0060:  726f 6c3a 206e 6f2d 6361 6368 650d 0a48 <br>
> > rol:.no-<br>
> > >>> cache..H<br>
> > >>>         0x0070:  6f73 743a 2031 3932 2e31 3638 2e31<br>
> > >>> 2e32  ost:.192.168.1.2<br>
> > >>>         0x0080:  3032 0d0a 5570 6772 6164 653a 2077<br>
> > >>> 6562  02..Upgrade:.web<br>
> > >>>         0x0090:  736f 636b 6574 0d0a 436f 6e6e 6563<br>
> > >>> 7469  socket..Connecti<br>
> > >>>         0x00a0:  6f6e 3a20 5570 6772 6164 650d 0a53<br>
> > >>> 6563  on:.Upgrade..Sec<br>
> > >>>         0x00b0:  2d57 6562 536f 636b 6574 2d4b 6579 3a20<br>
> > >-WebSocket-<br>
> > >>> Key:.<br>
> > >>>         0x00c0:  2f4a 5748 7668 3976 5052 336e 5675<br>
> > >>> 5267  /JWHvh9vPR3nVuRg<br>
> > >>>         0x00d0:  2f62 5554 5a77 3d3d 0d0a 4f72 6967<br>
> > >>> 696e  /bUTZw==..Origin<br>
> > >>>         0x00e0:  3a20 6874 7470 3a2f 2f31 3932 2e31 3638<br>
> > >:.<a href="http://192" rel="noreferrer" target="_blank">http://192</a>.<br>
> > >>> 168<br>
> > >>>         0x00f0:  2e31 2e32 3032 0d0a 5365 632d 5765 6253<br>
> > >.1.202..Sec-<br>
> > >>> WebS<br>
> > >>>         0x0100:  6f63 6b65 742d 5072 6f74 6f63 6f6c 3a20 <br>
> > ocket-<br>
> > >>> Protocol:.<br>
> > >>>         0x0110:  6273 7773 2d70 726f 746f 636f 6c0d 0a53  bsws-<br>
> > >>> protocol..S<br>
> > >>>         0x0120:  6563 2d57 6562 536f 636b 6574 2d45 7874<br>
> > >ec-WebSocket-<br>
> > >>> Ext<br>
> > >>>         0x0130:  656e 7369 6f6e 733a 200d 0a53 6563<br>
> > >>> 2d57  ensions:...Sec-W<br>
> > >>>         0x0140:  6562 536f 636b 6574 2d56 6572 7369 6f6e <br>
> > ebSocket-<br>
> > >>> Version<br>
> > >>>         0x0150:  3a20 3133 0d0a 0d0a                     <br>
> > :.13....<br>
> > >>><br>
> > >>><br>
> > >>> > Yes this server is a lws server.<br>
> > >>> ><br>
> > >>> > I don't get much on the server side:<br>
> > >>> ><br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.519960 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >Initial<br>
> > >>> > logging level 65535<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.519981 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > Libwebsockets version: 1.7.0 ac4b079<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.519988 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > IPV6<br>
> > >not<br>
> > >>> > compiled in<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520012 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > libev<br>
> > >>> > support not compiled in<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520021 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  LWS_DEF_HEADER_LEN    : 1024<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520027 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  LWS_MAX_PROTOCOLS     : 5<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520041 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  LWS_MAX_SMP           : 32<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520049 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  SPEC_LATEST_SUPPORTED : 13<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520055 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >sizeof<br>
> > >>> > (*info)        : 216<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520061 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  SYSTEM_RANDOM_FILEPATH: '/dev/urandom'<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520166 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >default<br>
> > >>> > timeout (secs): 20<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520213 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >Threads:<br>
> > >>> > 1 each 1024 fds<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520223 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > mem:<br>
> > >>> > context:          9800 bytes (5704 ctx + (1 thr x 4096))<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520251 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > mem:<br>
> > >>> > http hdr rsvd:    4232 bytes (1 thr x (1024 + 3208) x 1))<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520276 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > mem:<br>
> > >>> > pollfd map:       8192<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520310 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > mem:<br>
> > >>> > platform fd map:  8192 bytes<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520406 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  LWS_MAX_EXTENSIONS_ACTIVE: 2<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520418 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > mem:<br>
> > >>> > per-conn:          376 bytes + protocol rx buf<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520501 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >Compiled<br>
> > >>> > with OpenSSL support<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.520509 DEBUG: [WEBSOCKET ]: libwebsocket: <br>
> > Using<br>
> > >>> > non-SSL mode<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529082 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  interface lo vs eth0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529128 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  interface eth0 vs eth0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529136 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  interface eth1 vs eth0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529147 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  interface lo vs eth0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529153 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  interface eth0 vs eth0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529247 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > insert_wsi_socket_into_fds: 0x7fad98026450: tsi=0, sock=71,<br>
> > >pos-in-<br>
> > >>> > fds=1<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529278 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_LOCK_POLL fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >len=1<br>
> > >>> > 16-07-05 23:05:00.529302 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_ADD_POLL_FD fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=0<br>
> > >>> > 16-07-05 23:05:00.529376 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_UNLOCK_POLL fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=1<br>
> > >>> > 16-07-05 23:05:00.529453 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> >  Listening on port 7682<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:00.529470 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_PROTOCOL_INIT fd=0 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=0<br>
> > >>> > 16-07-05 23:05:00.529475 INFO : [WEBSOCKET ]: callback_http:<br>
> > >>> > LWS_CALLBACK_PROTOCOL_INIT<br>
> > >>> > 16-07-05 23:05:00.529520 INFO : [WEBSOCKET ]: callback_bsws<br>
> > >>> > LWS_CALLBACK_PROTOCOL_INIT wsi=0x7fada6ffcbb0<br>
> > >context=0x7fad98003e80<br>
> > >>> > pss=(nil)<br>
> > >>> > 16-07-05 23:05:00.529617 INFO : [WEBSOCKET ]:<br>
> > BSThread::onRunning<br>
> > >>> > called<br>
> > >>> > 16-07-05 23:05:00.719556 INFO : [BSWEBHTTP ]: Start(): THREAD<br>
> > >>> > WebSocket started.<br>
> > >>><br>
> > >>> He doesn't seem to feel he received any connect on his<br>
> > listening<br>
> > >>> socket.<br>
> > >>><br>
> > >>> If it possible you have another lws server running on 7682?<br>
> > >>><br>
> > >>> 1.7 introduced using SO_REUSEPORT for listening sockets when<br>
> > you<br>
> > >have<br>
> > >>> LWS_MAX_SMP > 1, each thread opens his own listening socket and<br>
> > the<br>
> > >>> load is shared between them by the OS without conflict.<br>
> > >>><br>
> > >>> A side effect of that is even if another process has a<br>
> > listening<br>
> > >socket<br>
> > >>> on 7682, creating the new listening socket will succeed.<br>
> > >>><br>
> > >>> I wonder if you have another instance still running somewhere<br>
> > >listening<br>
> > >>> on 7682 that gets the accept.<br>
> > >>><br>
> > >>> I notice LWS_MAX_SMP is 32 for you, how about setting that to 1<br>
> > >(cmake<br>
> > >>> .. -DLWS_MAX_SMP=1 ) if you are not using multiple service<br>
> > threads.<br>
> > >>>  That will disable SO_REUSEPORT.<br>
> > >>><br>
> > >>> -Andy<br>
> > >>><br>
> > >>> ><br>
> > >>> > and when I exit:<br>
> > >>> ><br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.379324 INFO : [BSWEBHTTP ]: BSEventMgr::run<br>
> > >Leaving<br>
> > >>> > mainloop. Thread exiting<br>
> > >>> > 16-07-05 23:05:17.379780 INFO : [BSWEBHTTP ]: Stopping the<br>
> > >WebSocket<br>
> > >>> > Thread...<br>
> > >>> > 16-07-05 23:05:17.380160 INFO : [WEBSOCKET ]: BSEventMgr::run<br>
> > >Leaving<br>
> > >>> > mainloop. Thread exiting<br>
> > >>> > 16-07-05 23:05:17.380302 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > lws_context_destroy<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.380315 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > lws_close_free_wsi: real just_kill_connection: 0x7fad98026450<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.380333 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_LOCK_POLL fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >len=1<br>
> > >>> > 16-07-05 23:05:17.380346 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > remove_wsi_socket_from_fds: wsi=0x7fad98026450, sock=71, fds<br>
> > >pos=1,<br>
> > >>> > end guy pos=2, endfd=0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.380361 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_DEL_POLL_FD fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=0<br>
> > >>> > 16-07-05 23:05:17.380389 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_UNLOCK_POLL fd=71 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=1<br>
> > >>> > 16-07-05 23:05:17.380398 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > not<br>
> > >>> > calling back closed mode=16 state=0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.380553 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_WSI_DESTROY fd=-1 context=0x7fad98003e80<br>
> > user=[NULL]<br>
> > >>> > len=0<br>
> > >>> > 16-07-05 23:05:17.380573 DEBUG: [WEBSOCKET ]: libwebsocket:<br>
> > >>> > lws_free_wsi: 0x7fad98026450, remaining wsi 0<br>
> > >>> ><br>
> > >>> > 16-07-05 23:05:17.380602 INFO : [WEBSOCKET ]: callback_http<br>
> > >>> > LWS_CALLBACK_PROTOCOL_DESTROY fd=0 context=0x7fad98003e80<br>
> > >user=[NULL]<br>
> > >>> > len=0<br>
> > >>> > 16-07-05 23:05:17.380612 INFO : [WEBSOCKET ]: callback_bsws<br>
> > >>> > LWS_CALLBACK_PROTOCOL_DESTROY wsi=0x7fada6ffccc0<br>
> > >>> > context=0x7fad98003e80 pss=(nil)<br>
> > >>> > 16-07-05 23:05:17.381734 DEBUG: [WEBSOCKET ]: BSThread::<br>
> > >[WEBSOCKET]<br>
> > >>> > Mainloop done. Bye.<br>
> > >>> > 16-07-05 23:05:17.382136 INFO : [BSWEBHTTP ]: WebSocket<br>
> > Thread<br>
> > >>> > stopped.<br>
> > >>> ><br>
> > >>> > Thanks,<br>
> > >>> > Brice.<br>
> > >>> ><br>
> > >>> ><br>
> > >>> ><br>
> > >>> ><br>
> > >>> ><br>
> > >>> ><br>
> > >>> > On Tue, Jul 5, 2016 at 5:56 PM, Andy Green <<a href="mailto:andy@warmcat.com">andy@warmcat.com</a>><br>
> > >wrote:<br>
> > >>> > ><br>
> > >>> > > On July 6, 2016 5:44:26 AM GMT+08:00, Brice Hamon<br>
> > ><normandviking@gm<br>
> > >>> > > <a href="http://ail.com" rel="noreferrer" target="_blank">ail.com</a>> wrote:<br>
> > >>> > > >HI Andy,<br>
> > >>> > > ><br>
> > >>> > > >I had to change the test client to add my own protocol<br>
> > name in<br>
> > >the<br>
> > >>> > > >request<br>
> > >>> > > >as my server only speaks that protocol.<br>
> > >>> > > ><br>
> > >>> > > >That client also used to work with prior version.<br>
> > >>> > > ><br>
> > >>> > > >Also I could disable the SSL support on both ends and the<br>
> > >problem<br>
> > >>> > > still<br>
> > >>> > > >persisted. So I concluded that this is not a SSL problem.<br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > >Yes Andy, the connection request eventually timeout like<br>
> > this:<br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > >aiting for connect...<br>
> > >>> > > >[1467754420:5046] CLIENT: lws_client_connect_2<br>
> > >>> > > >[1467754420:5047] CLIENT: lws_client_connect_2: address<br>
> > >>> > > 192.168.1.202<br>
> > >>> > > >[1467754420:5047] CLIENT: connected<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > len=0<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > >user=[NULL]<br>
> > >>> > > len=0<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL]<br>
> > len=0<br>
> > >>> > > >callback_bsws<br>
> > [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER]<br>
> > >fd=6<br>
> > >>> > > >user=[NULL] len=3794<br>
> > >>> > ><br>
> > >>> > > Hmm this is also different than what you said before, it's<br>
> > >creating<br>
> > >>> > > the upgrade request without the peer closing, which is more<br>
> > >>> > > reasonable.<br>
> > >>> > ><br>
> > >>> > > Check with tcpdump -s0 -X what happens on the wire.<br>
> > >>> > ><br>
> > >>> > > What is this server?  Also lws?  Get some logs on that as<br>
> > well<br>
> > >if<br>
> > >>> > > tcpdump shows it sent the upgrade.<br>
> > >>> > ><br>
> > >>> > > -Andy<br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > >[1467754441:5268] NOTICE: wsi 0xbea580: TIMEDOUT WAITING<br>
> > on 4<br>
> > >(did<br>
> > >>> > > hdr<br>
> > >>> > > >0,<br>
> > >>> > > >ah 0xbba730, wl 0, pfd events 0)<br>
> > >>> > > >[1467754441:5268] ERR: *** not on ah wait list ***<br>
> > >>> > > >[1467754441:5268] INFO: lws_close_free_wsi: real<br>
> > >>> > > just_kill_connection:<br>
> > >>> > > >0xbea580<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > len=1<br>
> > >>> > > >[1467754441:5269] INFO: remove_wsi_socket_from_fds:<br>
> > >wsi=0xbea580,<br>
> > >>> > > >sock=6,<br>
> > >>> > > >fds pos=1, end guy pos=2, endfd=0<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6 user=[NULL]<br>
> > len=0<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6 user=[NULL]<br>
> > len=1<br>
> > >>> > > >[1467754441:5269] DEBUG: Connection closed before server<br>
> > reply<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_CLIENT_CONNECTION_ERROR] fd=6<br>
> > >>> > > user=[NULL]<br>
> > >>> > > >len=0<br>
> > >>> > > >callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=-1 user=[NULL]<br>
> > >len=0<br>
> > >>> > > >[1467754441:5270] INFO: lws_header_table_detach: wsi<br>
> > 0xbea580:<br>
> > >ah<br>
> > >>> > > >0xbba730<br>
> > >>> > > >(tsi=0, count = 1)<br>
> > >>> > > >[1467754441:5270] ERR: header assign - free time 21<br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > >It seems like after the<br>
> > >>> > > LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER,<br>
> > >>> > > >nothing happens.<br>
> > >>> > > ><br>
> > >>> > > ><br>
> > >>> > > ><br>
</div></div>> > >>> > > >On Tue, Jul 5, 2016 at 5:26 PM, Andy Green <andy@warmcat.c<br>
<div class="HOEnZb"><div class="h5">> > om><br>
> > >>> > > wrote:<br>
> > >>> > > ><br>
> > >>> > > >><br>
> > >>> > > >><br>
> > >>> > > >> On July 6, 2016 4:28:03 AM GMT+08:00, Brice Hamon<br>
> > >>> > > ><<a href="mailto:normandviking@gmail.com">normandviking@gmail.com</a>><br>
> > >>> > > >> wrote:<br>
> > >>> > > >> >Thanks Roger,<br>
> > >>> > > >> ><br>
> > >>> > > >> >I'll look into it if I am unable to find the root cause<br>
> > >>> > > otherwise.<br>
> > >>> > > >><br>
> > >>> > > >> Git bisect is a good idea and the lws history is almost<br>
> > >always<br>
> > >>> > > >buildable<br>
> > >>> > > >> at any commit.  I thought it might be quicker to pull on<br>
> > the<br>
> > >>> > > symptom<br>
> > >>> > > >end<br>
> > >>> > > >> but maybe not.<br>
> > >>> > > >><br>
> > >>> > > >> >A little bit of progress.<br>
> > >>> > > >> ><br>
> > >>> > > >> >1) The test server and client do work on my platform.<br>
> > So the<br>
> > >>> > > problem<br>
> > >>> > > >is<br>
> > >>> > > >> >in<br>
> > >>> > > >> >my code somewhere.<br>
> > >>> > > >><br>
> > >>> > > >> Too early to say, since we don't know what the problem<br>
> > is.<br>
> > >But<br>
> > >>> > > it<br>
> > >>> > > >means<br>
> > >>> > > >> your toolchain + platform + lws version can basically<br>
> > work if<br>
> > >it<br>
> > >>> > > does<br>
> > >>> > > >what<br>
> > >>> > > >> the test apps do.<br>
> > >>> > > >><br>
> > >>> > > >> >2) I changed the client's test program and now I can<br>
> > see<br>
> > >that<br>
> > >>> > > the<br>
> > >>> > > >><br>
> > >>> > > >> What does it mean "changed the client's test program"?<br>
> > >>> > > >><br>
> > >>> > > >> >client<br>
> > >>> > > >> >get connected to the server, but nothing after that.<br>
> > >>> > > >> >That rules out a network transport problem.<br>
> > >>> > > >><br>
> > >>> > > >> It just means "'connection refused" was bogus.<br>
> > >>> > > >><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<br>
> > >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>
> > >>> > > >> This defaults to 1 on later lws anyway, but it's likely<br>
> > >>> > > unrelated if<br>
> > >>> > > >the<br>
> > >>> > > >> test apps are ok.<br>
> > >>> > > >><br>
> > >>> > > >> >[1467750112:5384] INFO:  SPEC_LATEST_SUPPORTED : 13<br>
> > >>> > > >> >[1467750112:5384] INFO:  sizeof (*info)        : 216<br>
> > >>> > > >> >[1467750112:5385] INFO:  SYSTEM_RANDOM_FILEPATH:<br>
> > >'/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<br>
> > bytes<br>
> > >>> > > (5704 ctx<br>
> > >>> > > >+<br>
> > >>> > > >> >(1<br>
> > >>> > > >> >thr x 4096))<br>
> > >>> > > >> >[1467750112:5387] INFO:  mem: http hdr rsvd:   67712<br>
> > bytes<br>
> > >(1<br>
> > >>> > > 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<br>
> > bytes<br>
> > >>> > > >> >[1467750112:5389] INFO:  LWS_MAX_EXTENSIONS_ACTIVE: 2<br>
> > >>> > > >> >[1467750112:5389] NOTICE:  mem: per-conn:          376<br>
> > bytes<br>
> > >+<br>
> > >>> > > >protocol<br>
> > >>> > > >> >rx<br>
> > >>> > > >> >buf<br>
> > >>> > > >> >[1467750112:5390] NOTICE:  canonical_hostname = bs1<br>
> > >>> > > >> >callback_bsws<br>
> > >>> > > [LWS_CALLBACK_OPENSSL_LOAD_EXTRA_CLIENT_VERIFY_CERTS]<br>
> > >>> > > >> >fd=0<br>
> > >>> > > >> >user=[�`ơ#] len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_PROTOCOL_INIT] fd=0<br>
> > user=[NULL]<br>
> > >>> > > len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=-1<br>
> > >>> > > 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<br>
> > >>> > > 192.168.1.202<br>
> > >>> > > >> ><br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > >len=1<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_ADD_POLL_FD] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6<br>
> > user=[NULL]<br>
> > >len=1<br>
> > >>> > > >> >libbswslog: [LOG_INFO]: nonblocking connect retry<br>
> > >>> > > >> ><br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > >>> > > user=[NULL]<br>
> > >>> > > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >Waiting for connect...<br>
> > >>> > > >> >libbswslog: [LOG_INFO]: lws_client_connect_2<br>
> > >>> > > >> ><br>
> > >>> > > >> >libbswslog: [LOG_INFO]: lws_client_connect_2: address<br>
> > >>> > > 192.168.1.202<br>
> > >>> > > >> ><br>
> > >>> > > >> >libbswslog: [LOG_INFO]: connected<br>
> > >>> > > >><br>
> > >>> > > >> Hm.  "Connection refused" was a red herring then, it's<br>
> > not<br>
> > >>> > > refused<br>
> > >>> > > >and<br>
> > >>> > > >> does connect.<br>
> > >>> > > >><br>
> > >>> > > >> >Then when I kill the server:<br>
> > >>> > > >> ><br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > >>> > > user=[NULL]<br>
> > >>> > > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws<br>
> > [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER]<br>
> > >>> > > fd=6<br>
> > >>> > > >> >user=[NULL] len=3794<br>
> > >>> > > >><br>
> > >>> > > >> This comes when the client is creating his upgrade<br>
> > request to<br>
> > >>> > > use ws<br>
> > >>> > > >> instead of http.<br>
> > >>> > > >><br>
> > >>> > > >> But that should be sequenced automatically to be done<br>
> > after<br>
> > >the<br>
> > >>> > > >connect<br>
> > >>> > > >> state, not happen when the peer died.<br>
> > >>> > > >><br>
> > >>> > > >> What is the situation with this "changed" test client<br>
> > about<br>
> > >it<br>
> > >>> > > >getting<br>
> > >>> > > >> service?<br>
> > >>> > > >><br>
> > >>> > > >> -Andy<br>
> > >>> > > >><br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_CHANGE_MODE_POLL_FD] fd=6<br>
> > >>> > > user=[NULL]<br>
> > >>> > > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws<br>
> > [LWS_CALLBACK_CLIENT_APPEND_HANDSHAKE_HEADER]<br>
> > >>> > > fd=6<br>
> > >>> > > >> >user=[NULL] len=3794<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_LOCK_POLL] fd=6 user=[NULL]<br>
> > >len=1<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_DEL_POLL_FD] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_UNLOCK_POLL] fd=6<br>
> > user=[NULL]<br>
> > >len=1<br>
> > >>> > > >> >callback_bsws [LWS_CALLBACK_WSI_DESTROY] fd=6<br>
> > user=[NULL]<br>
> > >len=0<br>
> > >>> > > >> ><br>
> > >>> > > >> ><br>
> > >>> > > >> >Thanks guys.<br>
> > >>> > > >> >Brice.<br>
> > >>> > > >> ><br>
> > >>> > > >> ><br>
> > >>> > > >> >On Tue, Jul 5, 2016 at 3:47 PM, Roger Light<br>
> > ><<a href="mailto:roger@atchoo.org">roger@atchoo.org</a>><br>
> > >>> > > >wrote:<br>
> > >>> > > >> ><br>
> > >>> > > >> >> Hi Brice,<br>
> > >>> > > >> >><br>
> > >>> > > >> >> If you've got a working and a non-working version,<br>
> > then a<br>
> > >>> > > good<br>
> > >>> > > >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><br>
> > >lws-bisect<br>
> > >>> > > >> >> cd lws-bisect<br>
> > >>> > > >> >> git bisect start<br>
> > >>> > > >> >> git bisect good v1.6.0-chrome48-firefox42 # assuming<br>
> > this<br>
> > >one<br>
> > >>> > > >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 -<br>
> > so<br>
> > >make<br>
> > >>> > > your<br>
> > >>> > > >> >> build directory, run cmake and carry out your tests.<br>
> > If<br>
> > >the<br>
> > >>> > > test<br>
> > >>> > > >is<br>
> > >>> > > >> >> successful, run "git bisect good", else run "git<br>
> > bisect<br>
> > >bad".<br>
> > >>> > > >You'll<br>
> > >>> > > >> >> have to carry out roughly 6 tests. At the end of the<br>
> > >process<br>
> > >>> > > >you'll<br>
> > >>> > > >> >be<br>
> > >>> > > >> >> told which commit in libwebsockets produced the error<br>
> > you<br>
> > >are<br>
> > >>> > > >seeing<br>
> > >>> > > >> >-<br>
> > >>> > > >> >> assuming that the problem is with libwebsockets of<br>
> > course.<br>
> > >>> > > >> >><br>
> > >>> > > >> >> When you're running your tests, make sure you start<br>
> > from a<br>
> > >>> > > clean<br>
> > >>> > > >> >build<br>
> > >>> > > >> >> and that your own client code is also recompiled<br>
> > against<br>
> > >the<br>
> > >>> > > 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<br>
> > >>> > > ><<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<br>
> > >>> > > (Chrome), so<br>
> > >>> > > >as<br>
> > >>> > > >> >you<br>
> > >>> > > >> >> > said, it could be something not transport related,<br>
> > but<br>
> > >>> > > rather<br>
> > >>> > > >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<br>
> > ><<a href="mailto:andy@warmcat.co">andy@warmcat.co</a><br>
> > >>> > > m><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<br>
> > problem<br>
> > >is.<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >One thing I was doing and seemed strange was in<br>
> > the<br>
> > >SSL<br>
> > >>> > > certs<br>
> > >>> > > >> >side:<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >if (http_ssl_)<br>
> > >>> > > >> >> >> >    {<br>
> > >>> > > >> >> >> >        if (!chain_file_.empty())<br>
> > >>> > > >> >> >> >        {<br>
> > >>> > > >> >> >> >          // cert file is not needed as it's<br>
> > included<br>
> > >in<br>
> > >>> > > the<br>
> > >>> > > >> >chain with<br>
> > >>> > > >> >> >> >all intermediate cert.<br>
> > >>> > > >> >> >> >            //info.ssl_cert_filepath =<br>
> > >>> > > cert_file_.c_str();<br>
> > >>> > > >> >> >> >            info.ssl_private_key_filepath =<br>
> > >>> > > key_file_.c_str();<br>
> > >>> > > >> >> >> >            info.ssl_cert_filepath =<br>
> > >chain_file_.c_str();<br>
> > >>> > > >> >> >> >        }<br>
> > >>> > > >> >> >> >        else<br>
> > >>> > > >> >> >> >        {<br>
> > >>> > > >> >> >> >            // Simple key/cert WSS<br>
> > >>> > > >> >> >> >            info.ssl_cert_filepath =<br>
> > >cert_file_.c_str();<br>
> > >>> > > >> >> >> >            info.ssl_private_key_filepath =<br>
> > >>> > > 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<br>
> > to<br>
> > >get<br>
> > >>> > > >response<br>
> > >>> > > >> >before<br>
> > >>> > > >> >> >> >giving up<br>
> > >>> > > >> >> >> >    info.ka_interval = 2; // how long to wait<br>
> > before<br>
> > >each<br>
> > >>> > > >> >ka_probes<br>
> > >>> > > >> >> >> >    info.user = this; // to get ourself inthe<br>
> > static<br>
> > >>> > > callback<br>
> > >>> > > >via<br>
> > >>> > > >> >the<br>
> > >>> > > >> >> >> >context.<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >    context_ =<br>
> > libwebsocket_create_context(&info);<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >and this was the only way I made the lib work<br>
> > with 3<br>
> > >ssl<br>
> > >>> > > files<br>
> > >>> > > >> >(key,<br>
> > >>> > > >> >> >> >cert<br>
> > >>> > > >> >> >> >and chain).<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >I tried the "correct" way with<br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >> >> >info.ssl_cert_filepath        =<br>
> > cert_file_.c_str();<br>
> > >>> > > >> >> >> >info.ssl_private_key_filepath =<br>
> > key_file_.c_str();<br>
> > >>> > > >> >> >> >info.ssl_ca_filepath          =<br>
> > 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<br>
> > itself<br>
> > >>> > > works<br>
> > >>> > > >on<br>
> > >>> > > >> >your<br>
> > >>> > > >> >> >> toolchain / platform.<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> >I think if we find the problem in 1.7, 2.0 will<br>
> > work<br>
> > >as<br>
> > >>> > > well.<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> I understand it looks like that to you, since you<br>
> > try<br>
> > >1.6<br>
> > >>> > > and<br>
> > >>> > > >it<br>
> > >>> > > >> >works<br>
> > >>> > > >> >> and<br>
> > >>> > > >> >> >> 1.7 acts different.  But it's not clear the<br>
> > problem is<br>
> > >in<br>
> > >>> > > the<br>
> > >>> > > >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<br>
> > >>> > > Connection<br>
> > >>> > > >> >Refused<br>
> > >>> > > >> >> end<br>
> > >>> > > >> >> >> of it, eg look what netstat says and eyeball<br>
> > traffic<br>
> > >with<br>
> > >>> > > >tcpdump.<br>
> > >>> > > >> > The<br>
> > >>> > > >> >> lib<br>
> > >>> > > >> >> >> doesn't issue a tcp connection refused, as I<br>
> > explained<br>
> > >it<br>
> > >>> > > means<br>
> > >>> > > >> >> something<br>
> > >>> > > >> >> >> basic like the listen socket is not there.<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> So the first move is confirm if that is literally<br>
> > a tcp<br>
> > >>> > > >connection<br>
> > >>> > > >> >> >> refused, or you mean some handwaving<br>
> > 'communication<br>
> > >>> > > failed'<br>
> > >>> > > >error<br>
> > >>> > > >> >that<br>
> > >>> > > >> >> is<br>
> > >>> > > >> >> >> actually something totally different and a red<br>
> > 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<br>
> > the<br>
> > >test<br>
> > >>> > > apps<br>
> > >>> > > >and<br>
> > >>> > > >> >look<br>
> > >>> > > >> >> in<br>
> > >>> > > >> >> >> there both at init and at connection attempt. <br>
> > Compare<br>
> > >the<br>
> > >>> > > 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<br>
> > are<br>
> > >OK.<br>
> > >>> > > >> >> >> >><br>
> > >>> > > >> >> >> >> The only change I can see impacting my code was<br>
> > the<br>
> > >>> > > warning:<br>
> > >>> > > >> >> >> >><br>
> > >>> > > >> >> >> >> bswebsocket.cpp:155:23: warning: `const<br>
> > >lws_extension*<br>
> > >>> > > >> >> >> >> lws_get_internal_extensions()' is deprecated<br>
> > >(declared<br>
> > >>> > > at<br>
> > >>> > > >> >> >> >><br>
> > >>> > ><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<br>
> > 2.0.2 to<br>
> > >>> > > 1.7.2<br>
> > >>> > > >does<br>
> > >>> > > >> >not<br>
> > >>> > > >> >> >> >work.<br>
> > >>> > > >> >> >> >>> 1.5.1 does work. I will eventually where it<br>
> > 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<br>
> > environment<br>
> > >>> > > issue as<br>
> > >>> > > >the<br>
> > >>> > > >> >same<br>
> > >>> > > >> >> >> >code<br>
> > >>> > > >> >> >> >>>> running on the same host with 1.4 works and<br>
> > not<br>
> > >2.0.<br>
> > >>> > > >> >> >> >>>><br>
> > >>> > > >> >> >> >>>> I just wanted to make sure I did not forgot<br>
> > an new<br>
> > >>> > > 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,<br>
> > Brice<br>
> > >Hamon<br>
> > >>> > > <<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<br>
> > couple of<br>
> > >>> > > >> >adjustments,<br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> >But now my server does not work anymore.  I<br>
> > use<br>
> > >an<br>
> > >>> > > >external<br>
> > >>> > > >> >> >> >polling<br>
> > >>> > > >> >> >> >>>>> >mechanism, and I see the first FD_ADD so<br>
> > the<br>
> > >epoll<br>
> > >>> > > is<br>
> > >>> > > >> >working.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> That doesn't follow actually, it means only<br>
> > that<br>
> > >>> > > lws'<br>
> > >>> > > >code<br>
> > >>> > > >> >to<br>
> > >>> > > >> >> >> >expose<br>
> > >>> > > >> >> >> >>>>> poll fds changes to the callback is working;<br>
> > it's<br>
> > >>> > > caused<br>
> > >>> > > >by<br>
> > >>> > > >> >> >> >creating the<br>
> > >>> > > >> >> >> >>>>> listen socket during init, not by servicing<br>
> > >(e)poll<br>
> > >>> > > >events.<br>
> > >>> > > >> >The<br>
> > >>> > > >> >> >> >log<br>
> > >>> > > >> >> >> >>>>> doesn't show any evidence of servicing<br>
> > (e)poll<br>
> > >>> > > events.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> >But when I try to connect with a browser or<br>
> > >client<br>
> > >>> > > >program<br>
> > >>> > > >> >I get<br>
> > >>> > > >> >> >> >a CONN<br>
> > >>> > > >> >> >> >>>>> >REFUSED and I don't see anything happening<br>
> > on<br>
> > >the<br>
> > >>> > > server<br>
> > >>> > > >> >side. I<br>
> > >>> > > >> >> >> >just<br>
> > >>> > > >> >> >> >>>>> >see<br>
> > >>> > > >> >> >> >>>>> >it listening on the correct port.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> Connection refused is really specific, it<br>
> > means<br>
> > >for<br>
> > >>> > > the<br>
> > >>> > > >peer<br>
> > >>> > > >> >there<br>
> > >>> > > >> >> >> >was<br>
> > >>> > > >> >> >> >>>>> nobody listening at the port.  That can mean<br>
> > the<br>
> > >>> > > listen<br>
> > >>> > > >> >socket<br>
> > >>> > > >> >> >> >bound to a<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> This observation is still true if it's literally<br>
> > >>> > > "Connection<br>
> > >>> > > >> >Refused".<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> -Andy<br>
> > >>> > > >> >> >><br>
> > >>> > > >> >> >> >>>>> different interface than your client reached<br>
> > >(check<br>
> > >>> > > it<br>
> > >>> > > >with<br>
> > >>> > > >> >> >> >netstat -pltn<br>
> > >>> > > >> >> >> >>>>> at the server, 0.0.0.0 means all interfaces)<br>
> > or a<br>
> > >>> > > >firewall<br>
> > >>> > > >> >got in<br>
> > >>> > > >> >> >> >the way,<br>
> > >>> > > >> >> >> >>>>> or you reached the wrong ip (name resolution<br>
> > >issue<br>
> > >>> > > at<br>
> > >>> > > >> >client).<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> >I compiled the lib plain vanilla with no<br>
> > >options.<br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> >Here is what I get as startup from your<br>
> > lib:<br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694159 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Initial<br>
> > >>> > > >> >> >> >>>>> >logging<br>
> > >>> > > >> >> >> >>>>> >level 15<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694176 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >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<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >IPV6<br>
> > >>> > > >> >> >> >not<br>
> > >>> > > >> >> >> >>>>> >compiled in<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694193 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >libev<br>
> > >>> > > >> >> >> >>>>> >support<br>
> > >>> > > >> >> >> >>>>> >not compiled in<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694198 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >libuv<br>
> > >>> > > >> >> >> >>>>> >support<br>
> > >>> > > >> >> >> >>>>> >not compiled in<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694356 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Threads: 1<br>
> > >>> > > >> >> >> >>>>> >each 1024 fds<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694453 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> > mem:<br>
> > >>> > > >> >> >> >>>>> >platform<br>
> > >>> > > >> >> >> >>>>> >fd map:  8192 bytes<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.694526 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Compiled<br>
> > >>> > > >> >> >> >>>>> >with<br>
> > >>> > > >> >> >> >>>>> >OpenSSL support<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.695057 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Creating<br>
> > >>> > > >> >> >> >>>>> >Vhost<br>
> > >>> > > >> >> >> >>>>> >'default' port 7682, 2 protocols, IPv6 off<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.695102 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Using SSL<br>
> > >>> > > >> >> >> >>>>> >mode<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.698961 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> > SSL<br>
> > >>> > > >> >> >> >ECDH<br>
> > >>> > > >> >> >> >>>>> >curve<br>
> > >>> > > >> >> >> >>>>> >'prime256v1'<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.699011 INFO : [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >callback_http<br>
> > >>> > > >> >> >> >>>>><br>
> > >>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS<br>
> > >>> > > fd=0<br>
> > >>> > > >> >> >> >>>>> >context=0x7efff0002800 user=[`uZ&] len=0<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.699021 ERROR: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >> >callback_http: case<br>
> > >>> > > >> >> >> >>>>><br>
> > >>LWS_CALLBACK_OPENSSL_LOAD_EXTRA_SERVER_VERIFY_CERTS<br>
> > >>> > > not<br>
> > >>> > > >> >handled.<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700680 INFO : [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >callback_http<br>
> > >>> > > >> >> >> >>>>> >LWS_CALLBACK_LOCK_POLL fd=85<br>
> > >context=0x7efff0002800<br>
> > >>> > > >> >user=[NULL]<br>
> > >>> > > >> >> >> >len=1<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700719 INFO : [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >callback_http<br>
> > >>> > > >> >> >> >>>>> >LWS_CALLBACK_ADD_POLL_FD fd=85<br>
> > >>> > > context=0x7efff0002800<br>
> > >>> > > >> >user=[NULL]<br>
> > >>> > > >> >> >> >len=0<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700758 INFO : [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >callback_http<br>
> > >>> > > >> >> >> >>>>> >LWS_CALLBACK_UNLOCK_POLL fd=85<br>
> > >>> > > context=0x7efff0002800<br>
> > >>> > > >> >user=[NULL]<br>
> > >>> > > >> >> >> >len=1<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700811 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >Listening<br>
> > >>> > > >> >> >> >>>>> >on<br>
> > >>> > > >> >> >> >>>>> >port 7682<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700834 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> > mem:<br>
> > >>> > > >> >> >> >>>>> >per-conn:<br>
> > >>> > > >> >> >> >>>>> >         496 bytes + protocol rx buf<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:24.700919 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >>>>> > canonical_hostname = xxxx<br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> >Then a<br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:25.972014 DEBUG: [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >libwebsocket:<br>
> > >>> > > >> >> >> >>>>> >lws_protocol_init<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:25.972043 INFO : [WEBSOCKET<br>
> > ]:<br>
> > >>> > > >callback_http<br>
> > >>> > > >> >> >> >>>>> >LWS_CALLBACK_PROTOCOL_INIT fd=0<br>
> > >>> > > context=0x7efff0002800<br>
> > >>> > > >> >> >> >user=[NULL]<br>
> > >>> > > >> >> >> >>>>> >len=0<br>
> > >>> > > >> >> >> >>>>> >16-06-29 11:38:25.972049 INFO : [WEBSOCKET<br>
> > ]:<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<br>
> > means<br>
> > >>> > > you did<br>
> > >>> > > >> >not<br>
> > >>> > > >> >> >> >succeed<br>
> > >>> > > >> >> >> >>>>> to touch the listen socket.  So there would<br>
> > be no<br>
> > >>> > > sign of<br>
> > >>> > > >> >activity<br>
> > >>> > > >> >> >> >from lws<br>
> > >>> > > >> >> >> >>>>> about that.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> >I guess  my straight port from 1.4 to 2.0<br>
> > was<br>
> > >just<br>
> > >>> > > been<br>
> > >>> > > >> >> >> >optimistic. I<br>
> > >>> > > >> >> >> >>>>> >am<br>
> > >>> > > >> >> >> >>>>> >forgetting something essential in order to<br>
> > have<br>
> > >2.0<br>
> > >>> > > >working<br>
> > >>> > > >> >like<br>
> > >>> > > >> >> >> >in<br>
> > >>> > > >> >> >> >>>>> >1.4.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> I think either lws bound to the wrong<br>
> > network<br>
> > >>> > > interface<br>
> > >>> > > >for<br>
> > >>> > > >> >> >> >listen, or<br>
> > >>> > > >> >> >> >>>>> the issue is outside lws.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> >Also the only question I had during the<br>
> > port is<br>
> > >>> > > that I<br>
> > >>> > > >used<br>
> > >>> > > >> >the<br>
> > >>> > > >> >> >> >>>>> >context->user pointer to store my own<br>
> > websocket<br>
> > >>> > > object.<br>
> > >>> > > >I<br>
> > >>> > > >> >now<br>
> > >>> > > >> >> >> >need to<br>
> > >>> > > >> >> >> >>>>> >to a<br>
> > >>> > > >> >> >> >>>>> >// Getting the context from the wsi<br>
> > >>> > > >> >> >> >>>>> >struct lws_context *wsicont =<br>
> > >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<br>
> > use<br>
> > >the<br>
> > >>> > > user<br>
> > >>> > > >> >pointer<br>
> > >>> > > >> >> >> >of the<br>
> > >>> > > >> >> >> >>>>> >callback to get my per_session_data<br>
> > structure.<br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> >>>>> No it looks good.  Both of those apis are<br>
> > really<br>
> > >>> > > cheap,<br>
> > >>> > > >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<br>
> > 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,<br>
> > Brice<br>
> > >>> > > 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<br>
> > >>> > > external<br>
> > >>> > > >epoll<br>
> > >>> > > >> >> >> >notification<br>
> > >>> > > >> >> >> >>>>> >>> >loop<br>
> > >>> > > >> >> >> >>>>> >>> >without a single problem for over a<br>
> > year<br>
> > >now.<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> Great.<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> >All the libwebsocket functions are<br>
> > happening<br>
> > >in<br>
> > >>> > > one<br>
> > >>> > > >> >thread so<br>
> > >>> > > >> >> >> >I<br>
> > >>> > > >> >> >> >>>>> >have<br>
> > >>> > > >> >> >> >>>>> >>> >followed all guidelines in the<br>
> > README.coding<br>
> > >>> > > >> >> >> >>>>> >>> >from that version.<br>
> > >>> > > >> >> >> >>>>> >>> ><br>
> > >>> > > >> >> >> >>>>> >>> >I think it is now time for me to<br>
> > upgrade as,<br>
> > >>> > > >following<br>
> > >>> > > >> >this<br>
> > >>> > > >> >> >> >group,<br>
> > >>> > > >> >> >> >>>>> >many<br>
> > >>> > > >> >> >> >>>>> >>> >fix<br>
> > >>> > > >> >> >> >>>>> >>> >and enhancement took place.<br>
> > >>> > > >> >> >> >>>>> >>> ><br>
> > >>> > > >> >> >> >>>>> >>> >Is there specific areas of change I<br>
> > should<br>
> > >be<br>
> > >>> > > >concerned<br>
> > >>> > > >> >with,<br>
> > >>> > > >> >> >> >or<br>
> > >>> > > >> >> >> >>>>> >>> >important<br>
> > >>> > > >> >> >> >>>>> >>> >changes in the notification area?<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> Yes at 1.6 many api names got simplified<br>
> > and<br>
> > >>> > > >> >rationalized.<br>
> > >>> > > >> >> >> >Mainly<br>
> > >>> > > >> >> >> >>>>> >the<br>
> > >>> > > >> >> >> >>>>> >>> api prefix got standardized to 'lws_'. <br>
> > There<br>
> > >>> > > are 4<br>
> > >>> > > >> >steps<br>
> > >>> > > >> >> >> >listed in<br>
> > >>> > > >> >> >> >>>>> >the<br>
> > >>> > > >> >> >> >>>>> >>> changelog<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> ><br>
> > >>> > > >> >> >> >>>>><br>
> > >>> > > >> >> >> ><br>
> > >>> > > >> >><br>
> > >>> > > >><br>
> > >>> > ><br>
> > >>><a href="https://github.com/warmcat/libwebsockets/blob/v2.0-stable/change" rel="noreferrer" target="_blank">https://github.com/warmcat/libwebsockets/blob/v2.0-stable/change</a><br>
> > l<br>
> > >>> > > og#L643<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> to search / replace everything in your<br>
> > code<br>
> > >into<br>
> > >>> > > >shape.<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> There are many other changes and<br>
> > >improvements,<br>
> > >>> > > such<br>
> > >>> > > >as<br>
> > >>> > > >> >> >> >multiple<br>
> > >>> > > >> >> >> >>>>> >vhost<br>
> > >>> > > >> >> >> >>>>> >>> support, CGI support, protocol plugins,<br>
> > lwsws<br>
> > >>> > > etc.<br>
> > >>> > > >It's<br>
> > >>> > > >> >hard<br>
> > >>> > > >> >> >> >to<br>
> > >>> > > >> >> >> >>>>> >predict<br>
> > >>> > > >> >> >> >>>>> >>> which are interesting, if you have<br>
> > external<br>
> > >>> > > epoll()<br>
> > >>> > > >just<br>
> > >>> > > >> >to<br>
> > >>> > > >> >> >> >get<br>
> > >>> > > >> >> >> >>>>> >epoll, the<br>
> > >>> > > >> >> >> >>>>> >>> new built-in libuv support might be<br>
> > >>> > > interesting... if<br>
> > >>> > > >so<br>
> > >>> > > >> >then<br>
> > >>> > > >> >> >> >lwsws<br>
> > >>> > > >> >> >> >>>>> >and<br>
> > >>> > > >> >> >> >>>>> >>> plugins might also simplify your life.<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> If you need external event loop to<br>
> > interface<br>
> > >to<br>
> > >>> > > >> >something<br>
> > >>> > > >> >> >> >else, then<br>
> > >>> > > >> >> >> >>>>> >that<br>
> > >>> > > >> >> >> >>>>> >>> should still work the same.<br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>> > > >> >> >> >>>>> >>> >Thanks all and especially Andy, your<br>
> > lib<br>
> > >rocks<br>
> > >>> > > :)<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>
> > >>>>>>------------------------------------------------------------<br>
> > >>> > > ------------<br>
> > >>> > > >> >> >> >>>>> >>> ><br>
> > >>> > > >> >> >> >>>>> >>><br>
> > >>_______________________________________________<br>
> > >>> > > >> >> >> >>>>> >>> >Libwebsockets mailing list<br>
> > >>> > > >> >> >> >>>>> >>> ><a href="mailto:Libwebsockets@ml.libwebsockets.org">Libwebsockets@ml.libwebsockets.org</a><br>
> > >>> > > >> >> >> >>>>> >>><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/libwebsoc" rel="noreferrer" target="_blank">http://libwebsockets.org/mailman/listinfo/libwebsoc</a><br>
> > kets<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>
</div></div></blockquote></div><br></div>