[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Thu Jun 30 19:13:03 CEST 2016


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
> 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/changelog#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
> >>>
> >>>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libwebsockets.org/pipermail/libwebsockets/attachments/20160630/1f8fbcbb/attachment.html>


More information about the Libwebsockets mailing list