[macgyverismo]

I started using this library last week. It was easy to get started and running. When I wanted to do stuff beyond the provided example I found nothing worked as I had expected. For example, you supply a user pointer when you create a lws_context. There is a user pointer argument in the callback where you do all the actual work. One would expect these to be the Same, but they are not. Instead you have to use two different calls to get from your current connection to the user pointer which is set for all connections. Did it work? Yes. But it was very suprising behavior. Another problem I ran into was getting the event loop to be non-blocking for use in a coroutine. Appearently I was expected to use one of the preselected event libraries, which I was not. I was expected to implement a dozen or so callbacks for which there was little or no helpfull documentation. Eventually I found that there was a hack where I could pass -1 to the timeout parameter. Now the service call was non blocking. It would have been fine if the call had blocked for a millisecond or so, but that did not work. So the time-out parameter was either -1 or any other value. I kept bumping into suprises like this. The library solved a problem for me, so I will continue to use it. Unfortunately I cant recommend it to anyone unless you are willing and able to spend a good portion of your time getting this beast tamed.

[iforgotpassword]

But that "just" sounds like lacking documentation and a bit of missing support for you specific use case, or was anything actually broken or implemented in a completely stupid way? I didn't have to use websockets in C yet, but it would be good to have something ready in case I do at some point. Having to dig through source code instead of docs is something I'm used to. Are there any other contenders you looked at?

[numpad]

I've had a very similar experience a few weeks ago and even fell for the same double-userdata misunderstanding.

The documentation itself is actually good and extensive, however it feels like the authors expect its users to deeply understand the library itself. It is also harder to find some "Getting Started" docs as most provided examples felt way too bloated coming from a nodejs/ws background. Compared to the other library[1] I was considering, it took much longer to get even a simple "echo" server running.

However having used lws for some time now, I am really happy with it! The API is very clean, mostly intuitive and provides everything you need, without feeling bloated or becoming too verbose. Sometimes documentation still feels a bit harder to find, but it can be figured out eventually. One great feature for me was being able to accept both WebSocket as well as raw TCP connections on the same port, this is extremely easy and just required settings the flag LWS_SERVER_OPTION_FALLBACK_TO_RAW.

I encountered other hiccups. They are fully documented and completely valid, but were really confusing to me as a first-time user:

* Sending data requires a specific memory layout[2] – namely having to allocate memory for the websocket header youself before the actual message you want to send. This gave me confusing segfaults in the beginning.

* Sending data / responding to a client message will probably (but not always) fail when just naively using "lws_write()". To correctly send data you need to manually queue your message data, request the "ON_WRITABLE" callback[3] and only then actually send.

[1]: https://github.com/Theldus/wsServer

[2]: https://libwebsockets.org/lws-api-doc-v3.0-stable/html/group... (see the "IMPORTANT NOTICE")

[3]: https://libwebsockets.org/lws-api-doc-main/html/group__callb...

[doophus]

I found the same with this library. I'm not sure if it's missing documentation, unintuitive design or both, but I always found it a bit of a struggle to use beyond simple cases.