[Libwebsockets] v2.0 coming very soon

Andy Green andy at warmcat.com
Thu May 26 11:48:08 CEST 2016



On 05/26/2016 05:15 PM, Thomas Spitz wrote:
> Hello Andy,
>
> On one hand, I have tried to use the new plugin approach in my program
> but it is very hard in my case because lws server and my main plugin (ws
> connection) are very tied together (they share many variables that would
> need to be exposed to my application through shm or other sharing options).
> On the other hand, in order to get advantage of better HTTP file
> handling, auth management and further improvements, I would like not to
> have to write my own callback_http.

If you are going to serve dynamic http, you'll need to have your own 
http handling.  But that can be in the same plugin - the same protocol 
callback - as the ws parts, so there is no problem about "sharing 
variables".

> In other word, is it possible to declare my own protocol definitions and
> user callback contents like in first test-server but without declaring
> http-callback. That is to say

If you need it, because you're not serving files but generated html, you 
need it.  If you're serving files, like leaf.jpg, you can use mounts.

>     /* list of supported protocols and callbacks */
>     static struct lws_protocols protocols[] =
>     {
>     { "MY_PROTOCOL", callback_my_protocol, sizeof(struct
>     per_session_data__my_protocole), 4096},
>     { NULL, NULL, 0, 0 } /* terminator */
>     };
...
> it is not clear for me wether libuv (and so plugins) are required or nor.

Lws is pretty flexible, it does not itself need libuv or plugins.  But 
you are into writing a lot of code and structs if you go that way.

One of the knock-ons is then you must provide an explicit http-only 
protocols[0] yourself.

If you use the plugins stuff, actually you can avoid it -->

> I also do not understand how test-server-v2.0 manage to serve leaf.png
> and any other file in any other folder (what test-server isn't able to
> do) using HTTP

test-server-v2.0.c is even more remarkable if you notice he doesn't 
define any protocols at all.  Lws defines a dummy "protocols[0]" one 
then and assembles the protocol structs dynamically from the plugins 
enabled in the config (or info.pvo if you do it by hand with structs).

The reason it can serve everything is it declares a mount:

static const struct lws_http_mount mount = {
	(struct lws_http_mount *)&mount_post,		/* linked-list pointer to next*/
	"/",		/* mountpoint in URL namespace on this vhost */
	LOCAL_RESOURCE_PATH, /* where to go on the filesystem for that */
	"test.html",	/* default filename if none given */
	NULL,
	NULL,
	NULL,
	NULL,
	0,
	0,
	0,
	0,
	0,
	0,
	LWSMPRO_FILE,	/* mount type is a directory in a filesystem */
	1,		/* strlen("/"), ie length of the mountpoint */
};

binding the URL namespace from / to LOCAL_RESOURCE_PATH, which is 
/usr/share/libwebsockets-test-server or wherever you installed lws.

Once you set it up, unless it finds another mount that's a better match 
to the URL, lws will automatically serve files from that dir when asked 
for things in /.  leaf.jpg is in that directory.

The equivalent bit of lwsws conf is this

        {
        "mountpoint": "/",
        "origin": "file:///usr/share/libwebsockets-test-server",
        "default": "test.html",
        }

Lws lets you also declare mounts that are bound to a protocol name.

        {
         "mountpoint": "/dynamic",
         "origin": "callback://my-protocol-name"
        }

HTTP GET or POST down /dynamic/* will occur on the callback for 
"my-protocol-name". (The name /dynamic is not meaningful, it could be 
anything).

So this way you can automate serving static content so it is no effort, 
and isolate serving dynamic content for a region of the URL space in a 
plugin, by name.

> As you can see I am quite confusing with all the new possibilities. If
> my questions are not clear, I can send you part of my code...

It's difficult to answer in a more straightforward way because the best 
solution is pushing to make it as abstract as possible (lwsws, libuv, 
protocol plugins) but you want to implement it all in code.  So while 
explaining you should use plugins you're also asking how to do it 
without them.

Maybe you should better prototype it with the high end stuff and when it 
works, look at reducing that to code, including the plugin content 
direct in your app etc if you still want to.

-Andy

> Best regards,
> Thomas
>
>
>
> 2016-05-18 9:06 GMT+02:00 Andy Green <andy at warmcat.com
> <mailto:andy at warmcat.com>>:
>
>
>
>     On May 18, 2016 2:46:13 PM GMT+08:00, Thomas Spitz
>     <thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>> wrote:
>     >Hello Andy,
>     >
>     >I think I will use plugins however regarding lwsws I will rather not
>     >use it
>
>     That'll get you most of the benefits.
>
>     >because my application need to computably  computationally (not
>     >manually)
>     >configure ports, redirect and protocols. Thus, I think going through
>     >JSON
>     >files will certainly be more complex than dealing with native C
>     >structures... I might be wrong...
>
>     You know your application better than I do... if it's easier to wire
>     up with structs, no problem.
>
>     One observation though... JSON is easy to machine-generate if need be.
>
>     -Andy
>
>      >Best regards,
>      >Thomas
>      >
>      >
>      >2016-05-17 20:48 GMT+02:00 Andy Green <andy at warmcat.com
>     <mailto:andy at warmcat.com>>:
>      >
>      >>
>      >>
>      >> On May 18, 2016 1:43:04 AM GMT+08:00, Thomas Spitz <
>      >> thomas.spitz at hestia-france.com
>     <mailto:thomas.spitz at hestia-france.com>> wrote:
>      >> >I think I will have to go for option 1 as you explained in
>      >>
>      >>https://libwebsockets.org/pipermail/libwebsockets/2016-April/002303.html
>      >> >in
>      >> >order to get an easy and maintainable solution for port
>      >redirections,
>      >> >http
>      >> >processing, ...:
>      >>
>      >> It's workable, but compared to just having a custom JSON config
>     and a
>      >> plugin, with everything else off the shelf, it's not the easiest or
>      >most
>      >> maintainable way.
>      >>
>      >> >1) Keep your existing code and attach your own mounts at vhost
>      >creation
>      >> >time
>      >> >
>      >> >
>      >>
>      >https://github.com/warmcat/libwebsockets/blob/master/README.coding.md#using-lws-v2-vhosts
>      >> >
>      >> >Lws will serve the mounted contents automatically from where it's
>      >> >mounted
>      >> >in the server namespace
>      >> >
>      >> >Could you confirm that this solution requires libuv and or libev? I
>      >> >hope
>      >> >this will not stress too much my emdedded system ;-)
>      >>
>      >> Plugins are what implies libuv (not libev).  However I think you
>     find
>      >for
>      >> Arm v7 running Linux, the idea libuv will 'strain' it is probably
>      >just
>      >> prejudice.  Libuv is cheap as a crossplatform  wrapper around socket
>      >events
>      >> or timers, and we're otherwise using it for crossplatform dirent and
>      >plugin
>      >> operations at init.
>      >>
>      >> Until recently when it got updated to a Rpi 3, libwebsockets.org
>     <http://libwebsockets.org> was
>      >a
>      >> 1GHz Armv7, before that a series of weaker Arm devices like CA8,
>     even
>      >the
>      >> weakest ones with 256MB would have had no trouble with libuv in the
>      >mix.
>      >>
>      >> >I think this would have been nice to have cgitest, server-status in
>      >> >libwebsockets-test-server-v2.0 and libwebsockets-test-server to
>      >compare
>      >> >the
>      >> >three solutions (the third solution is lwsws).
>      >>
>      >> The old test server code is bloated with adding support for the
>      >kitchen
>      >> sink in there, making it difficult to use as the example it's
>      >intended to
>      >> be; the advantage of the plugins + lwsws for maintainability is
>      >clear.
>      >>
>      >> You can add everything in the plugins + lwsws JSON into
>      >test-server-v2.0.c
>      >> as structs + protocols + api calls, but then it will become
>      >inflexible and
>      >> huge... that's a big step backwards.
>      >>
>      >> So the official test-server-v2.0.c should stay like it is, just
>      >having
>      >> enough 'config by struct' to demonstrate the concept and leveraging
>      >the
>      >> plugins, where a standalone server app is possible lwsws is the way
>      >to 'do
>      >> everything' flexibly and maintainably.
>      >>
>      >> >libwebsockets-test-server is
>      >> >probably not necessary as I assume it will be a depreciated
>     solution
>      >in
>      >> >the
>      >> >future? I will certainly try to complete
>      >libwebsockets-test-server-v2.0
>      >> >tomorrow.
>      >>
>      >> Yes the old all-in-one test server will continue to be supported
>      >(indeed
>      >> the default, since everything else needs enabling at cmake).
>     But new
>      >stuff
>      >> - I plan to discuss a completely new, highly abstracted protocol
>      >plugin
>      >> project soon, and suitable third-party plugins could become provided
>      >as
>      >> part of lws - will be provided as 'mix and matchable' standalone
>      >plugins
>      >> only.
>      >>
>      >> -Andy
>      >>
>      >> >Best regards,
>      >> >Thomas
>      >>
>      >>
>
>



More information about the Libwebsockets mailing list