[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
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
>> 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.
>> Python simple HTTP server) to a local server I will write in C,
>> libwebsockets for the connection to the web page and Winsock for a
>> 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
>> 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
>> 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
>> 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
More information about the Libwebsockets