[Libwebsockets] Seeking advice on the best libwebsockets server implementation for my scenario

biolaser at frii.com biolaser at frii.com
Sat Feb 13 07:50:14 CET 2021

Hi Andy,

Very good advice and I'd like to seriously take to heart all your
suggestions on design and implementation.

One worry I have - that existing Editor application that is currently
using Winsock APIs - I don't have the ability to make any changes to that
source code, so I think I'm stuck with using the existing Winsock-based API
to communicate with that application. I don't want to have to make a server
that uses Winsock on one side and lws on the other side of the
communication connections. I just don't know if I can bypass that current
API. It seems like a big risk to try. That current API undoubtedly does a
number of things under the hood (beyond simple data transfer) that I have
no visibility into.

I have to think about how I might be able to use lws throughout my server,
rather than mixing Winsock with web sockets.

Please let me know any further thoughts or ideas you may have - I want
this project to turn out clean and professional as you suggest, not a hack
that gets uglier and uglier over time.



On Sat, 13 Feb 2021 05:21:01 +0000, Andy Green <andy at warmcat.com> wrote:
> On 2/12/21 10:54 PM, biolaser at frii.com wrote:
>> My scenario is as follows:
>> All players in the following scenario currently reside on the same
>> Windows
>> 10 PC. But a scenario where the elements are distributed is also
>> in future.
>> But for now:
> The big challenges designing things turn out to be "maintainability", 
> that covers "simplicity" so you have less bugs and can still understand 
> clearly how it works later.  If you prioritize those it will usually 
> cause the other considerations to end up in a good place.
>> I want to connect a locally-hosted web page (HTML and Javascript hosted
>> by
>> Python simple HTTP server) to a local server I will write in C,
>> leveraging
>> libwebsockets for the connection to the web page and Winsock for a
>> totally
>> separate connection to yet another local C++ application (an Editor).
>> So the C libwebsockets server would host a connection to each of two
>> different clients using two different libs - libwebsockets and Winsock.
>> These should be totally independent of each other within that server.
> If the data from those two sides will interact -->
>> I want to pass simple integer data from the web page (initiated by
>> user-clicks) to the server over libwebsockets, then pass that data
>> further
>> along to another local C++ application (an Editor) over Winsock.
> ... then that separate approach is not the way to do it.
>> In this scenario data travels from web page to libwebsockets server and
>> is
>> always initiated from the web page client. But in future I may wish to
>> initiate from the local C++ application (an Editor) and send data to
>> server and then finally up to the web page.
> Right, so they are not in separate worlds at all but want to freely 
> intercommunicate in both directions.  If you think about how to do that 
> maintainably and simply, it doesn't lead you towards two separate 
> implementations under the hood.
>> I have already written the code for the Winsock server and client
>> connection and it is working - I need to add the web socket logic to
>> server using libwebsockets.
>> What would be the best implementation of libwebsockets to employ to
>> enhance my server to be able to do web socket connection to the web
>> page? I
>> don't need to worry about libwebsockets client, since I can use
>> Javascript
>> in the web page to get a connection to the libwebsockets server.
> Most threads (and locking / bugs) people throw on their problems are 
> pointless, they exist only as a consequence of using blocking apis when 
> they should have used nonblocking.  They do not need or want parallelism

> of blocking primitives, but just serialization of async primitives.
> There are a lot of event libraries around to enable using the 
> nonblocking / serialized pattern because it means the users can do all 
> their comms on a single thread, with the guarantee that consequently 
> there can never be any contention for access to data, since a single 
> thread can only do one thing at a time.  So there is no need for any 
> locking, any code participating in the event loop can reliably use any 
> data structures only touched by other event loop code directly at any
> So I would look at replacing the existing winsock part you want to 
> cooperate with the ws side either with lws raw socket role, or make that

> use ws as well.
> The lws raw socket role presents the same protocol callback scheme as 
> the ws stuff, but allows listen and client connections directly on the 
> socket without any protocol framing, you can send and receive just the 
> socket payloads directly.  Eg,
> With a separate protocol in the same context for the ws side, both sides

> are then under the same roof and operating on the same event loop and 
> can cooperate without friction using common data structures like 
> ringbuffers to proxy things around.
> There's the added benefit the lws pieces will not be tied to windows, 
> the ws proxy piece can be crossplatform since lws knows how to work on 
> many platforms for this and you will just use that for socket comms 
> rather than winsock.
> The proxying of a "shared world" to multiple contributing clients that 
> may consume the data at different rates (or fail) isn't that trivial. 
> The lws_mirror example protocol shows one way to do it reliably
> -Andy

More information about the Libwebsockets mailing list