[Libwebsockets] Q on protocol names

Andy Green andy at warmcat.com
Mon Aug 11 03:35:45 CEST 2014

On 10 August 2014 21:06:44 GMT+08:00, Michael Haberler <mail17 at mah.priv.at> wrote:
>Am 10.08.2014 um 04:01 schrieb Andy Green <andy at warmcat.com>:
>> On 10 August 2014 04:36:42 GMT+08:00, Michael Haberler
><mail17 at mah.priv.at> wrote:
>>> I'd like to have a single protocols structure, since I have a single
>>> callback only anyway, which cover http/s and ws/s
>>> Ideally I'd inspect the ws protcol name the client desired, and
>>> to _that_ protocol, set an option in my private session structure
>>> deny altogether, modulo on protocol name)
>>> is that something I could do? how?
>> I'll study your patch for it, but is this actually something that
>needs doing with dynamic protocol names in the user code?
>In principle you're right, but making protocols dynamically allocated
>would be a big bite to swallow given the current libwebsocket_protocols
>data structure. And I think in most cases that is not needed.

No I meant rather what you're doing is dynamic protocol names, and it seems it can be just done with the existing static ones for all cases I can think of.

Notice that there is no problem with several static protocols all pointing to the same callback, so this doesn't cause an explosion in user code elsewhere.

And this way we don't get into string comparisons at runtime to figure out the versioning; we can rather add an int to the protocols struct so you can use switch / case to do versioned code.

>In practice, it's more likely you have rather similar protocols - maybe
>just distinguished by version numbers (for example, karlp's requirement
>in #147).
>the idea here is - instead of enumerating every possible protocol name
>hard-coded in additional libwebsocket_protocols structs, provide a hook
>and let user code decide which proto to support and how; that's what
>#158 does (besides giving the right answer in Sec-WebSocket-Protocol:

I think there's some confusion about #147.  I fixed it 3 weeks ago


until then, we did not deal with multiple protocol selections at all.  I sent a note by email but it never appeared on the bug at github.

Whatever other problems around that they're not related to #147.

>> I don't know what your use-case is but don't forget there is a URL
>part also coming with the ws upgrade action, that can be used to refine
>the meaning of that websocket connection.
>yes, and I use that already for other options unrelated to ws protocol,
>but that cannot sensibly handle existing client code which offers say
>several protocol versions and lets the server pick one. That code would
>have to be rewritten to pass that information in the URI, and
>server-side code to pick out that information from the URI. That being
>doable in the general case is a major assumption to make; it impacts
>stock js library use substantially - for instance, karlp would have to
>massage the URI when using mqttws31.js.
>> Because protocols themselves mandate specific code support that
>either exists in the server / client or not, handling them as static
>definitions seems more natural...
>that's generally an ok assumption. The way I deal with the
>variants/version issue is: I parse the protocol names list in
>FILTER_PROTOCOL_CONNECTION, decide which one to use, record that in my
>private session structure, and let the library know of that by calling
>libwebsocket_set_protocol(wsi,name, <opt proto if not default>).

How about just add an int to the protocols struct representing any information about that version of the protocol (capability bitfield, version ordinal etc) and let the existing code and static protocol structs do everything.  It's extensible to a large number of protocols / versions and does not require user code to parse anything, nor add strings to protocol matching in the rest of the code.

Is there any feature that your scheme gives us we actually miss out on if we just do that?  Yes you'd have to enumerate the protocol versions you support, but how many can we be talking realistically?  Ten or twenty as a one-off scan at connection upgrade time sounds OK.

BTW you mentioned the code spun when you gave a NULL name.  I pushed a patch to fix that.


>- Michael
>Libwebsockets mailing list
>Libwebsockets at ml.libwebsockets.org

More information about the Libwebsockets mailing list