[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Thu Jul 7 17:01:56 CEST 2016


Hi Andy,

1.7.8 recompiled in debug, with 1 thread.

I traced in the debugger after the READ event on the lws fd.

Although I don't understand your code, it appears that lws does not process
the event due to the check in line:

server.c line 1011.

as follow:

Breakpoint 2, lws_server_socket_service (context=0x7fffc8001670,
wsi=0x7fffc8025090, pollfd=0x7fffcfffee10)
    at
/export/home/development/3rdparty/libwebsockets-1.7.8/lib/server.c:1011
1011                            if (!(fd-poll>revents & LWS_POLLIN) ||
!(pollfd->events & LWS_POLLIN))
(gdb) n
1062                    return 0;
(gdb) c
Continuing.
16-07-07 10:53:44.656235 INFO : [WEBSOCKET ]: processUserEvent called for
fd=71 ret=0

Breakpoint 2, lws_server_socket_service (context=0x7fffc8001670,
wsi=0x7fffc8025090, pollfd=0x7fffcfffee10)
    at
/export/home/development/3rdparty/libwebsockets-1.7.8/lib/server.c:1011
1011                            if (!(pollfd->revents & LWS_POLLIN) ||
!(pollfd->events & LWS_POLLIN))
(gdb) n
1062                    return 0;



(gdb) p *pollfd
$20 = {fd = 71, events = 0, revents = 1}

So the thread is spinning and the event not consumed.

I do not know why at this point, just wanted to share my early findings.
Any ideas?

Thanks
Brice.





On Wed, Jul 6, 2016 at 10:41 PM, Brice Hamon <normandviking at gmail.com>
wrote:

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


More information about the Libwebsockets mailing list