[Libwebsockets] pointers for implementing websocket tcp gateway and a static http server
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,
>>>> TCP/IP to communicate. I want to bundle a websocket to tcp
>>>> the app so i can access it through a browser. Also i want to
>>>> 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?
>>>> 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
>>> at the moment"? It's like poll() or like an event loop?
>>> If it already has its own poll() management, you should look at
>>> 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
>>> 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
>> through TCP/IP.
> Fair enough...
>> I think libuv is the way to go for me. So shall i start with
> Yes... either that or lwsws.
> 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
>> 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
> 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.
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets