[Libwebsockets] v2.0 coming very soon

Thomas Spitz thomas.spitz at hestia-france.com
Thu May 26 11:15:17 CEST 2016


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.

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

> /* 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 */
> };

instead of

> /* list of supported protocols and callbacks */
> static struct lws_protocols protocols[] =
> {
> /* first protocol must always be HTTP handler */
> { "http-only", /* name */
> callback_http, /* callback */
> sizeof(struct per_session_data__http), /* per_session_data_size */
> 0, /* max frame size / rx buffer */
> },
> { "MY_PROTOCOL", callback_my_protocol, sizeof(struct
> per_session_data__my_protocole), 4096},
> { NULL, NULL, 0, 0 } /* terminator */
> };

and keep

> info.protocols = protocols;

....

> while (n >= 0 && !force_exit) {
> struct timeval tv;
> gettimeofday(&tv, NULL);
> /*
> * This provokes the LWS_CALLBACK_SERVER_WRITEABLE for every
> * live websocket connection using the DUMB_INCREMENT protocol,
> * as soon as it can take more packets (usually immediately)
> */
> ms = (tv.tv_sec * 1000) + (tv.tv_usec / 1000);
> if ((ms - oldms) > 50) {
> lws_callback_on_writable_all_protocol(context,
> &protocols[PROTOCOL_DUMB_INCREMENT]);
> oldms = ms;
> }
> #ifdef EXTERNAL_POLL
> /*
> * this represents an existing server's single poll action
> * which also includes libwebsocket sockets
> */
> n = poll(pollfds, count_pollfds, 50);
> if (n < 0)
> continue;
> if (n)
> for (n = 0; n < count_pollfds; n++)
> if (pollfds[n].revents)
> /*
> * returns immediately if the fd does not
> * match anything under libwebsockets
> * control
> */
> if (lws_service_fd(context,
>  &pollfds[n]) < 0)
> goto done;
> #else
> /*
> * If libwebsockets sockets are all we care about,
> * you can use this api which takes care of the poll()
> * and looping through finding who needed service.
> *
> * If no socket needs service, it'll return anyway after
> * the number of ms in the second argument.
> */
> n = lws_service(context, 50);
> #endif
> }

instead of libuv functions...

In fact, when you wrote

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

it is not clear for me wether libuv (and so plugins) are required or nor.

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

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

Best regards,
Thomas



2016-05-18 9:06 GMT+02:00 Andy Green <andy at warmcat.com>:

>
>
> On May 18, 2016 2:46:13 PM GMT+08:00, Thomas Spitz <
> 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>:
> >
> >>
> >>
> >> On May 18, 2016 1:43:04 AM GMT+08:00, Thomas Spitz <
> >> 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 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
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160526/f74b5193/attachment-0001.html>


More information about the Libwebsockets mailing list