Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mosquitto-dev] Moving away from libwebsockets

Dear all,

We've been using libwebsockets (lws) to provide websockets
functionality in mosquitto for a long while now. I would like to move
to a different solution, and am writing this to give my reasoning and
ask for feedback.

In of itself, I'm reasonably happy with what we get out of lws, but
there are problems which affect mosquitto and other projects. It is a
large and sprawling library which, in my opinion, tries to do far too
much or at least far more than we want or need (dhcp and ntp being two
examples). Backwards compatibility isn't a priority and both behaviour
changes and ABI breakage have been problems for us in the past.
Thankfully that seems to have come under tighter control since the 4.x
series.

Those points are an annoyance, but can be dealt with for the most
part. The real difficulty is that lws considers their external poll
support to now be a "hack" and so have disabled it by default and will
be removing it in the future. As mosquitto uses this interface,
something has to be done and given the annoyances, moving to something
different seems wise.

I am currently looking at using the picohttpparser and wslay libraries
to provide websockets support. For comparison, picohttpparser is 5kB,
wslay is 27kB, and libwebsockets is 498kB (mosquitto is 293kB). I have
created a very rough prototype at
https://github.com/ralight/mosquitto/tree/wslay This covers the broker
only, but I would also like to extend support to the client library.

If you'd like to try it out:

```
git clone https://github.com/ralight/mosquitto
cd mosquitto
git checkout wslay
git submodule init
git submodule update # for picohttpparser
make WITH_WEBSOCKETS=yes
```

You'll need wslay available as well.

One difference with the prototype is that there is no plain http
support - it's websockets only. So no serving files over http. When I
added websockets support, I added the ability to have plain http
support because libwebsockets offered it, but actually I'm really not
sure that it's a sensible approach. There are plenty of capable http
servers out there, but I don't think mosquitto should be one of them.
What do you think? My current line of thinking is to keep the
libwebsockets support, available at compile time, for anybody who
wants plain http support in the near term, until the next breaking
release at which point it would be dropped. If you think mosquitto
should be able to serve files over http, please make your case and
persuade me. The prototype already has the ability to compile against
both websockets solutions I've described - either `make
WITH_WEBSOCKETS=yes` for the new wslay prototype, or `make
WITH_WEBSOCKETS=lws` for the libwebsockets support.

Any comments welcome.

Regards,

Roger


Back to the top