[Libwebsockets] Several questions about libwebsockets

Didier Brachet dbrachet.wr at gmail.com
Mon Aug 22 16:05:29 CEST 2016


Hello,

I am a pretty new user of libwebsockets 2.0 library (I have been previously
using nopoll WebSocket library but wanted to try libwebsockets because of
various issues faced with nopoll and extra features available with
libwebsockets); and I am currently working on adding WebSocket support for
Eclipse Target Communication Framework agent (http://www.eclipse.org/tcf/)
using this library.

Overall things are working okay but I have some questions and comments
about libwebsockets library. Note that I may not have a typical setup; In
my case I have a WebSocket server that may have to handle tenth of
thousands of client connections and I also have clients that may have to
handle multiple connections to one or more servers (and for test purpose we
may have a client issuing thousands WebSocket connections requests to one
or more servers).


   - I have been using the proxy support in libwebsockets and I would like
   to get the confirmation that it supports http/https proxy but not socks 5
   proxy. I have not yet looked at the proxy code but this is what my
   experiments have shown. Is there any plan to implement a SOCKS 5 proxy if
   it is not already there?
   - Why is the proxy support at context level and not at connection level?
   This is not really an issue for me but IMO it would make more sense to have
   this as a parameter of lws_client_connect_via_info() API instead of
   lws_create_context() API.
   - Same comment as previous one regarding the ssl_ca_filepath (there may
   be more but those are the ones I had "issues" with until now).
   - I have seen some discussions indicating that it was possible to manage
   multiple LWS contexts in multiple threads; however when I try to do this I
   face several issues:
      - OpenSSL library is not reentrant (multi-thread compatible) unless
      we implement SSL locking functions (
      https://www.openssl.org/docs/man1.0.2/crypto/threads.html). It means
      that if you want to use multiple contexts then you need, in your
      application, to initialize the SSL locking functions.
      - If I delete one lws context, it will cause random crashes when
      using other lws contexts because lws_context_destroy() calls
      lws_ssl_context_destroy() which in turn
      calls ERR_free_strings(), EVP_cleanup() and CRYPTO_cleanup_all_ex_data();
      those APIs will impact all SSL contexts not only the current one
(note that
      based on documentation those APIs are noop starting with OpenSSL
1.1.0 but
      in my case I am using OpenSSL 1.0.1f). Note that creating
multiple contexts
      may not make sense with vhost support on the server side but in this case
      we should clearly state in the documentation that only a single
context can
      be created in a single name space (at least when we use SSL).
   - On Unix platform implementation (Linux in my case) we use a pipe to
   interrupt a pending poll request. With my setup made of a server with
   several thousands of clients that connect/disconnect very quickly, I end up
   in some cases where the pipe is full because lws_cancel_service() has been
   called many times. This can cause several issues:
      - It may take a huge amount of time flushing all those requests
      because we read bytes one by one in lws_plat_service_tsi().
      - I can even have a deadlock -if
      the LWS_CALLBACK_LOCK_POLL/LWS_CALLBACK_UNLOCK_POLL locks are implemented
      and if lws_callback_on_writable() is called from a different
thread (which
      seems to be completely valid)- because the thread
      calling lws_callback_on_writable()->...->lws_cancel_service(_pt)
can block
      on write because the pipe is full while owning the lock.

I don't think there is any need to have multiple pending cancel requests;
maybe we should implement a mechanism to skip a lws_cancel_service()
request if there is already one pending. This should, as far as I
understand- solve both problems.


   - For performance reasons, it seems it would make a lot of sense to make
   use of epoll() instead of poll() when possible in the libwebsockets code. I
   have seen one message posted about this but there was no reply; is this
   something already planned?

Sorry about this (too) long email; let me know if I should better send
individual emails about each issue. I would also be happy to contribute to
help improving libwebsockets; let me know if you agree with my points and
if you want me to provide fixes for one or several of them (any idea when
is planned the next stable release?).

Regards,
Didier Brachet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libwebsockets.org/pipermail/libwebsockets/attachments/20160822/4999624c/attachment.html>


More information about the Libwebsockets mailing list