[Libwebsockets] lwsws reload / was lws + libuv ( mac/freebsd ), explicit_vhosts

Andy Green andy at warmcat.com
Wed Nov 30 13:55:34 CET 2016

On Tue, 2016-11-29 at 19:49 +0800, Andy Green wrote:
> On Tue, 2016-11-29 at 12:36 +0100, Denis Osvald wrote:
> > Hi Andy,
> > 
> > On 2016-11-29 12:27, Andy Green wrote:
> > > A proper "reload" type functionality would also need to deal with
> > > killing or modifying vhosts too.  But anyway the bottom line is
> > > if
> > > you
> > > add a vhost later - much later - with libuv, you must do what
> > > lws_uv_initloop() does to vhost listen sockets to the new guy's
> > > vhost
> > > listen socket.  That's the only limitation I think.
> > 
> > Just checking, with lws I shouldn't encounter any problems with
> > live-reloading vhosts when not using libuv, right? Namely, I'd be
> > doing
> > it with the extpoll support?
> This "libuvification" / deferred listen socket instantiation thing is
> just for libuv, yes.  It's related to libuv mode not directly using
> socket fds and POSIX stuff directly, it has to instantiate libuv
> generic "listener" wrappers for the socket to get libuv events.  And
> that requires libuv to be in a state that it may not actually be in
> until after we finished creating vhosts.  So it is deferred.
> But today, lws doesn't have any support for "reload" type

There's maybe a reasonably nice and maintainable way to do this...
basically allow a context to become "deprecated" and a new one created
from the new config in parallel.  The new context * becomes "the
context" for the app replacing the original one (which is now held by
lws on a "deprecated context list").

The deprecated context continues to operate and get service one way or
another (eg for poll() type, the newest context maintains a linked-list 
of deprecated contexts and service on the live context calls through to
all the deprecated ones too), while he has live wsi.  But deprecated
contexts no longer receive listen accepts, so they cannot get new
connections.  When his pre-existing live wsi count drops to zero,
everything about the deprecated context is destroyed and freed.

While deprecated contexts are dying down and losing connections, the
new context and his vhosts has "seamlessly" been getting any new listen
accepts and operating under the new config.

That creates a split in the shared "world" when you do the server
reload... for example if it was mirror protocol, only guys who already
connected to a deprecated context can see your drawing if you also are
connected to the old context; only guys connected to the new context
could see your drawing if you were connected to the new context. 
Eventually the deprecated context "world" becomes a lonely place and
then becomes completely extinct.  Likewise the reloaded "world" is
empty until new connections come.

This total boundary between the two worlds is a reasonable tradeoff
because it makes it possible for the reloaded context to have
completely different plugin code + structs without conflict, if the
plugins can also be reloaded.  I haven't figured out how to implement
plugin versioning or whatever it needs, but it is at least
theoretically possible to do this way.

Also it removes any need to perform and maintain any detailed config
changelist generation and dynamic application, which would be bloated
and a nightmare to be sure was not buggy under some corner case.  It
also couldn't handle extreme deltas like a protocol's pss struct
changing after the reload.

Wsi and vhosts already hold their context * and most everywhere is
already getting the context from those.  Likewise at least most libuv
object wrappers have the context * in them.

Anybody see any problem with this approach?  Is there interest in
debugging it and actually using it?


> functionality.  I think Aleksey doesn't actually care about that in
> the
> service reload sense, he just wants to add vhosts.
> If you want to add vhosts later, you also need to do what is
> currently
> general one-time vhost init in ./lib/context.c lws_protocol_init(). 
> This is responsible for making ordered per-vhost protocol lists that
> contain both the user protocol list and any plugin protocols attached
> to the vhost.
> That'll also need the modification treatment where it can be called
> again after any subsequent vhost addition before this random vhost
> addition stuff will work.
> -Andy
> > 
> > Thanks,
> > 
> > Denis
> > _______________________________________________
> > Libwebsockets mailing list
> > Libwebsockets at ml.libwebsockets.org
> > http://libwebsockets.org/mailman/listinfo/libwebsockets
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list