[Libwebsockets] trouble with external POLL array handling

Edwin van den Oetelaar oetelaar.automatisering at gmail.com
Thu Jan 17 09:01:29 CET 2013


> You are right a lookup table will do fine, and it blows through the
> complexity and remaining iterations in the hash scheme.  On a really low-end
> ARM or MIPS box with only 4 or 8MB of memory though it's quite expensive to
> reserve 128KBytes for this if he only expects one client at a time.
>
> I have been thinking for a while that MAX_CLIENTS needs to become something
> set at runtime by the app if it doesn't like the default (what should we
> tell a distro packager to set MAX_CLIENTS to otherwise?), your scheme looks
> like a good way to solve that and can also replace the library's internal
> polling hash tables we discussed yesterday are also bloated, statically
> allocated and complex.  We should get a nice throughput increase there too
> under heavy load.
>
> So I will look at adapting (the second version of) this today both in and
> out of the library and in the in-library case, runtime control over the
> allocation for it.
>
> Thanks a lot for studying it!
>
> -Andy
>

Some thoughts I have.
The size of the lookup table must be at least the largest number of FD
that the whole application expects.
So if program has 1000 files open but just 2 sockets you would still
need at least 1002 entries in the lookup table, since fds are recycled
by the OS.
If a lookup table was to be used for quickly finding the fd -> wsi
mapping, I think the memory should be allocated by the user code and
passed to the library.

My possible use case would be to run this library on linux, for now it
is just an idea but my goal is to write a little server that connects
200k devices with low traffic, low memory, low CPU,  low latency using
websockets, to create the Internet of Things.
If I can get that up and running quick I have a potential client/use-case.
I do like python and all those fancy websocket-servers but this 'C'
library can beat all of them. I am also mixing the poll loop with
zero-mq and that brings all kinds of nice things.

Maybe the handling of server/client could take into account that a
server might have the memory for lookup tables but the client might
not?

thanks for your very well designed piece of software,
Edwin van den Oetelaar



More information about the Libwebsockets mailing list