[Libwebsockets] Libwebsocket Upgrade from 1.4

Brice Hamon normandviking at gmail.com
Mon Jul 4 22:25:11 CEST 2016


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
>> 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: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160704/34d0c6db/attachment-0001.html>


More information about the Libwebsockets mailing list