[Libwebsockets] v2.0 coming very soon
andy at warmcat.com
Sun Apr 24 20:20:24 CEST 2016
On April 24, 2016 9:28:32 PM GMT+08:00, Thomas Spitz <thomas.spitz at hestia-france.com> wrote:
>Hello Andy, hello everyone,
(adding back the ml)
>I have looked at the new features you have introduced and I wonder
>this could solve one of the old issue we discussed in the following
>To make it clearer, here is my application :
>At the present, I use libwebsocket on an embedded linux (1core 450MHz
>mainly to communicate (two-way communication) in real time through one
>(SSL port 443) with desktop softwares, mobile apps and also browsers
>important) using my own protocol over websocket.
>I now also need to retrieve files that are stored on my embedded linux
>(data log files, pictures, sounds, ....) in a simple way (eg: a bit
>ftp) but using the same port 443? Thus, we only need to create one NAT
>in routers to access our embedded linux server from the WAN.
Right... you could always do that on one port by choosing what files to serve in the http callback. For example the test-server serves both his ws connections and the html and png all on one port. But for that you had to write the low-level code.
Master branch (to be lws v2.0) gives you two additional options
1) Keep your existing code and attach your own mounts at vhost creation time
Lws will serve the mounted contents automatically from where it's mounted in the server namespace
2) Replace your whole server app with lwsws, which is how libwebsockets.org is working now.
Then you can configure the vhosts and mounts (and everything else) in JSON instead of writing code.
To implement your custom ws protocol part, do it as an lws protocol plugin. These are much simpler and more selfcontained than 'cut and paste the test server'... eg
You can build your plugin against lws headers and libs, and copy to /usr/[local/]share/libwebsockets-test-server/plugins/, lws scans the dir and initializes any plugins found.
You need to enable the ws protocols you want to offer in each vhost, see how the libwebsockets.org conf above does it. You can also set per vhost protocol options there to modify or control what yhe protocol plugin does on a per-vhost basis.
This way you can shed almost all your custom server code and get more featureful and maintainable results.
>If I am correct, it seems that vhost can help us to have the standard
>webserver, the WS server and a kind of "FTP" all running on the same
>port? If so, do you have an idea of a service that could work with LWS
>order to serve files from an embedded linux file system? Ideally, I
>wouldn't like to have to create my own protocol to retrieve files from
>Thanks in advance for your very nice support and sorry for such novice
>2016-04-23 14:12 GMT+02:00 Andy Green <andy at warmcat.com>:
>> Hi -
>> In the spirit of eating my own dogfood the last couple of weeks my
>> services for https://libwebsockets.org and https://warmcat.com have
>> running using lwsws on master, with real traffic and with real CGIs
>> After tracking down the last CGI related bugs this week, it seems to
>> It's running 11 vhosts, although a lot of these are redirects for
>> services. You can see its current status (via websockets, naturally)
>> (This is a ws protocol plugin on lwsws and is included in ./plugins)
>> I've prepared a page listing the new features here
>> Basically a big advantage is if you are making a server type
>> you can just use lwsws and only need to write the ws protocol plugin
>> set up some JSON to deploy it, instead of cut and pasting custom
>> If you want to deploy more protocols later, they are selfcontained
>> and will play nice together. The server stack is already much more
>> than 1.7 (the automated mountpoint serving and http cache control,
>> apache-compatible logging amongst other things). And you can benefit
>> centralized maintenance of the whole server stack that way.
>> For example the lws test server on
>> has its ws protocols served by lwsws plugins; there's no code at all
>> them in lwsws itself.
>> If you don't care right now, well it's disabled in cmake by default
>> currently and everything works as before by default.
>> There's some docs on lwsws here:
>> and you can see the actual lwsws JSON config for libwebsockets.org in
>> tree as an example
>> There are two features that will have to wait for a subsequent
>> think, one is http proxy, although it works it's not integrated into
>> yet (because I don't have a use for it right now and nobody has asked
>> it), the other is mbedtls (people asking for it but nobody wants it
>> to help work on it, even though I have done all the plumbing).
>> Otherwise it's in good shape AFAICT, it was in Coverity today and
>> back at zero defects.
>> If there's any comments, questions or suggestions, it'd be helpful to
>> them before it gets released ^^
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets