[Libwebsockets] pointers for implementing websocket tcp gateway and a static http server

jsaak jsaak at napalm.hu
Tue Oct 18 13:24:05 CEST 2016

I hacked and copy-pasted something together.
It does sort of work. Until it crashes.
(man, your library is confusing :)

you can see the code here:

I do not want to use lwsws, since i can not run new processes, i have to 
embed this thing to an existing process. And dynamic .so loading is not 
very cross platform friendly i guess.

What I need is some strategy on rx/tx buffering and partial reads.
Also I want to avoid malloc if possible.


How does your lib work in this regard?

Shall I implement a dynamic buffer?

The OS TCP stack has a buffer, maybe i can use that and disable, and 
reenable filehandles, as needed?

(1. read some bytes
  2. disable filehandle, so i do not get any more data until i wrote them
  3. wait for write
  4. write those bytes
  5. reenable read filehandle)

OR leave the filehandles, and set an internal flag in my app so I do not 
read more data until it is successfully written?

I guess that they are level triggered.

OR do i have to buffer everything in my app?

Shall I copy the data to my app when reason == LWS_CALLBACK_RECEIVE?
Or can i use it later?


Also i am confused about partial reads.
according to the log i have some kind of protocol rx buf.
(how much? the 4th parameter in struct lws_protocols protocols[] ? )

" NOTICE: mem: per-conn: 712 bytes + protocol rx buf"

but you mention elsewhere that i need to check for final fragment?

"To support fragmented messages you need to check for the final frame of 
a message with lws_is_final_fragment."

So what is that buffer doing if not assembling fragmented packets?


Big thanks if you find the time to answer my questions!

On 10/12/2016 10:21 AM, Andy Green wrote:
> On Wed, 2016-10-12 at 09:38 +0200, jsaak wrote:
>> On 10/12/2016 09:25 AM, Andy Green wrote:
>>> On Wed, 2016-10-12 at 09:16 +0200, jsaak wrote:
>>>> I have an app which works under linux/android/ios/osx/windows,
>>>> and
>>>> uses
>>>> TCP/IP to communicate. I want to bundle a websocket to tcp
>>>> gateway
>>>> to
>>>> the app so i can access it through a browser. Also i want to
>>>> include
>>>> a
>>>> static http server.
>>>> I found libwebsockets, and i think it might be a solution.
>>> Sounds like the right kind of task for lws.
>>>> All I ask of you is some advice. How to start with libwebsockets?
>>>> It
>>>> is
>>>> a bit confusing for me.
>>> Run the test server is the best way to get started.
>>> The key question is "How does your existing app wait on network
>>> events
>>> at the moment"?  It's like poll() or like an event loop?
>>> If it already has its own poll() management, you should look at
>>> using
>>> External Poll support to integrate lws with it.
>>> If it uses an event loop, lws has libuv (preferred) and libev event
>>> loop support, you can integrate using that.
>>> How nice a ride you get is mainly depending on the existing app's
>>> wait
>>> for network events method.
>> I am using SDL_Net which uses select() on all platforms i think.
>> But it may be irrelevant, since i want to put libwebsocket to a new
>> thread (so i can use any event loop there), and only communicate with
>> it
>> through TCP/IP.
> Fair enough...
>> I think libuv is the way to go for me. So shall i start with
>> https://github.com/warmcat/libwebsockets/blob/master/test-server/test
>> -server-v2.0.c
>> ?
> Yes... either that or lwsws.
> https://libwebsockets.org/lws-api-doc-master/html/md_README.lwsws.html
> Lwsws will take care of all of the boilerplate and give you an lws
> webserver configurable with JSON in one step.  Basically you can avoid
> writing any code that is unrelated to your protocol.
>> Do I have to make a default websocket protocol? And in that protocol
>> i
>> have to open/read/write/close the real TCP connection?
> If you use test-server-v2.0.c style, you would copy the "main.c" type
> stuff and write a plugin (initially, just copy dumb-increment plugin is
> enough) that will hold your protocol actions.
> You'll also need to set up mounts etc to serve the http stuff
> programatically, it shows you how in the example code.
> lwsws lets you configure the mounts and so on in JSON.  You only need
> to provide the protocol plugin then which is only concerned with your
> actions.
> Any way you do it, lws takes care of socket-level stuff including
> accept and close, without you needing to do anything.
> It's best to take advantage of lwsws if your server is essentially
> standalone.  https://libwebsockets.org (and https://warmcat.com) are
> served from an Rpi 3 using lwsws.
> -Andy
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list