[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Thu Jul 7 04:12:45 CEST 2016


You're correct Andy, but in my framework, the even is checked before
calling that method.

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

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 gmail.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.com>
> >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.com>
> >>> > > 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/changel
> >>> > > 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/libwebsockets
> >>> > > >> >> >
> >>> > > >> >>
> >>> > > >>
> >>> > > >>
> >>> > >
> >>> > >
> >>> >
> >>> _______________________________________________
> >>> 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/20160706/f4ce4a91/attachment-0001.html>


More information about the Libwebsockets mailing list