[Libwebsockets] Libwebsocket Upgrade from 1.4

Andy Green andy at warmcat.com
Wed Jul 6 05:50:40 CEST 2016


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



More information about the Libwebsockets mailing list