[Libwebsockets] Multiplexing with libwebsockets

"Andy Green (林安廸)" andy at warmcat.com
Tue Sep 17 01:40:16 CEST 2013

On 16/09/13 21:30, the mail apparently from Daniel Griscom included:
> At 9:21 PM +0800 9/16/13, Andy Green wrote:
>> Daniel Griscom <griscom at suitable.com> wrote:
>>  >- What kind of problems are yet to be resolved in your old code?
>> My code is incomplete and followed a much older draft.
>> Actually I'm not sure my code is good to follow except in terms of
>> extension integration.  It seemed to get ferociously complicated much
>> faster than I expected, usually a sign I missed the right way or
>> failed to understand something somewhere along the line.
> You know, I was wondering if that would happen. It seems like the
> extension needs to take all the usual libwebsockets server calls in one
> side, and produce all the same calls out the other side, which could
> lead to a combinatorial nightmare.

As I say I think that may just be my not having my finger on the pulse 
of it properly, or telling us about an impedence mismatch with current 
main library structure.

I got quite far into it before really understanding that the individual 
mux children need to exhibit very convincing tcp / ip socket behaviours 
in order to continue to work properly in all normal cases.  In my 
implementation they were no longer themselves sockets.

> Not sure it would be necessary, but what's your feeling about changing
> the core libwebsockets code to support such an extension? (Not enthused,
> I'd guess.)

Some changes are needed whatever you do, in my case it was adding 
callback hooks which are still there in the main libwebsockets code.

> I really hope it wouldn't be necessary, but what's your feeling about
> changing the libwebsockets API to support such an extension? (Pretty
> reluctant, I'd guess.)

It depends what you have in mind.

Definitely if whatever it is causes nontrivial bloat it should be able 
to be disabled at compile-time hopefully without too much mess so 
there's no real impact on code size or data footprint if you don't want it.

But you can't get away from the extension semantics of the mux stuff, it 
really is an extension in the spec.  So it will basically have to be an 

Another possibility to consider is writing a proxy front-end that does 
the bundling and unbundling only, and passes through to a regular 
libwebsockets server for every individual connection.  That gets you out 
of mixing it all together, and you can use libwbesockets itself in the 
proxy to gain access to the http - websockets negotiation code etc.  It 
doesn't solve socket proliferation completely but it leaves it only an 
issue inside the server.


> Thanks,
> Dan

More information about the Libwebsockets mailing list