[Libwebsockets] How to set the "user" callback parameter for adopted sockets?
aconway at redhat.com
Wed Nov 23 15:46:51 CET 2016
On Wed, 2016-11-23 at 08:50 +0800, Andy Green wrote:
> On Tue, 2016-11-22 at 19:02 -0500, Alan Conway wrote:
> > I'm making progress! I can crash my router from a web brower :)
> > I can't figure out how to set the "user" parameter for lws
> > callbacks
> > for a socket adopted with lws_adopt_socket(). I can access the
> That's not what *user_space is for.
> It's for protocol-specific local data, per-connection. When the
> protocol changes, which it may often do with a http/1.1 keepalive
> connection visiting urls that map on to different plugins, the user
> data allocation is destroyed by lws and a new one sized appropriately
> for the new protocol allocated.
For me, the protocol starts as "http" and may change to "binary" or
"amqp" (which I treat as both "amqp"). Does that mean that if I store
context for the http protocol, it will be wiped out in the upgrade? Is
there any way to preserve some per-connection data between the two or
is each protocol session treated as entirely separate from previous
> > allocated space *after* the adopt call with lws_wsi_user(), but
> > lws_adopt_socket() itself is firing my callbacks so that's too
> > late.
> > The docs mention setting up your session data on the
> > LWS_CALLBACK_ESTABLISHED event, but at that point I have nothing I
> > can
> > use to find data from my application.
> LWS doesn't have this concept of external shadowed data per-
> You have two ways to do it
> - add a new opaque void * in struct lws and set it at adopt-time,
> provide an accessor to get it from the wsi. This is a bit of a
> for everyone who doesn't care about this then.
For current purposes I need to use a released, packaged version of lws
so modifying it isn't an option - I do hope to make contributions
> - Set the context user pointer at context creation time. You can
> this from a wsi in the callback. You can then use this context-wide
> pointer to dereference the wsi pointer to your private connection
> pointer on your side, entirely outside of lws.
I could use either the fd or the wsi pointer to look up my application
data, but it's an expensive lookup that requires a map of all the known
fds/wsi-pointers. I could use thread-local storage as a hack to get my
context into the initial "http" established callback, but that doesn't
help if it will get wiped out in the upgrade to "amqp"... Hmmm.
> > Thanks,
> > Alan.
> > _______________________________________________
> > Libwebsockets mailing list
> > Libwebsockets at ml.libwebsockets.org
> > http://libwebsockets.org/mailman/listinfo/libwebsockets
More information about the Libwebsockets