[Libwebsockets] Several questions about libwebsockets

Andy Green andy at warmcat.com
Mon Aug 22 18:18:52 CEST 2016



On August 22, 2016 10:05:29 PM GMT+08:00, Didier Brachet <dbrachet.wr at gmail.com> wrote:
>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

Right.

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

Nobody has asked for it until now, so there are no plans.

>- Why is the proxy support at context level and not at connection
>level?

Because the guys who needed it required it because all of the host's network access went through a proxy, ie, it was indeed a context-wide attribute.

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

That's actually per-vhost.

>- I have seen some discussions indicating that it was possible to
>manage
>multiple LWS contexts in multiple threads; however when I try to do

Hm no that's not recommended by me and none of the test apps do that.

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

Well, okay.  The vhosts handle this and other issues like SNI and vhost detection via Host: correctly when multiple vhosts listen on the same port, that's something else that'd blow up with multiple contexts.  Socket fd maps in unix are done process-wide per-context; it'd be wasteful of memory.  So it's not a supported way.

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

Right that sounds like a bug, it only ever needs to put one thing in the pipe between service actions.

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

If you use the libuv support in lws, it will choose its own backend including epoll().  For other reasons (eg, crossplatform, standalone plugins) other advanced lws features like lwsws require libuv anyway.  So we suggest using that if you want epoll().

>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

If you can take a look at a fix for the multi cancel service it'd be good thanks, it's midnight here.  I think that api is only needed when lws uses his built-in poll(), ie, not with libuv / ev.  So it might be enough to set /check / clear a bit in the perthread context struct in the code that writes and reads the pipe.

If SOCKS5 doesn't require any new connection states (it presumably follows the same basic pattern as http proxy in terms of waiting for network roundtrips) that might not be too difficult to piggyback on the existing support, a patch would be welcome.

>is planned the next stable release?).

Master is ready afaik, so soon.

-Andy

>Regards,
>Didier Brachet
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org
>http://libwebsockets.org/mailman/listinfo/libwebsockets




More information about the Libwebsockets mailing list