[Libwebsockets] dynamic websocket_protocols
"Andy Green (林安廸)"
andy at warmcat.com
Wed Sep 18 12:20:18 CEST 2013
On 18/09/13 16:27, the mail apparently from Michael Haberler included:
> Hi Andy, good to see you back!
> Question - not sure this can be done in the current framework:
> I use libwebsockets to serve messages to/from zeroMQ, among them
> publish/subsubscribe patterns
> as for mapping channels to sockets, the easiest way is to map a
> ZMQ_PUB channel identity (a string) to a websocket protocol of the
> same identity - a client subscribing to a particular channel would
> select a matching protocol name
> this works fine in a static setup; however the set of channels in my
> project may vary over time; in my current scheme that would suggest a
> varying libwebsocket_protocols array, and fiddling with that array at
> runtime while connections are open doesnt strike me as a good idea
No that's not necessarily a problem... the array is only used to walk
through it looking for protocol matches at handshake time.
Once the protocol is agreed the wsi just has a pointer directly to the
> any suggestions how to do that?
I don't really get what you're trying to do overall but if I understood
it the idea is that protocols may come and go, there may be a lot of
them as if they were each an IRC channel or something. I don't think
that's the idea of the protocols thought....
It is possible to change things around to make the protocols array a
linked-list instead, so you could meddle with it and new connections
could use new entries / no longer connect to removed entries in the
> the other alternative I see is in-band signaling while the connection
> is open (a single protocol in that case) - have the server offer a
> list of channels by say a json object, and have the client send a
> subscribe JSON object in reply which will cause the server instance
> to subscribe to the channels listed in that message
> I'm not a great friend of in-band signaling if it can be avoided.. I
> might be missing something, however maybe there is a different way to
> fudge the channel list/subscription message through HTTP headers? (I
> am too HTTP agnostic to know)
> thanks in advance!
When you connect and ask to upgrade to a websocket connection, there's
an oldstyle URL given by the client at that time you can use. It sounds
like it would be a better fit.
So you keep one protocol (which maps to one callback function...) to
implement everything and take care to tag the user data with the
original URL that came in at handshake time. You use that string / path
(er... "ZMQ_PUB channel identity") to act differently, which still
operating within a single protocol.
Does it sound like a better fit? If not maybe you can help me see the
point I'm missing ^^
> best regards
> ps: I am very eager to see Andrew Canaday's libev work to fold back
> into mainline - I think it's the way to go as far as event loops go
Right now I don't have any itch it scratches, but if someone else wants
to integrate or can explain why it might scratch an itch I didn't know I
had, I'd be happy.
> _______________________________________________ Libwebsockets mailing
> list Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets