lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP and Websockets


From: Sergio R. Caprile
Subject: Re: [lwip-users] LWIP and Websockets
Date: Mon, 26 Oct 2015 13:51:55 -0300
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

> - If I need to wait for a handshake in the HTTP form, it would be fine
> if I start with a HTTP server. As I understand it, HTTP server is mostly
> a TCP server with some retries and the particular communication scheme
> (Get, post, etc.).

No it is not
>> A web server is a delicate piece of code [...].
An HTTP server is a statefull machine, and the fact that you are not
working with sockets but with callback functions makes it even more
complicated and cumbersome to follow.

> I will take a look at your code to try to figure this out. It can be
> something with the HS for sure. It's weird that I am doing the same that
> they do and it doesn't work...

Evidently you are not, otherwise it would work... ;^)

> For me, if I get XX from http_recv it
> should be easy to send YY back as a response. HTTP should be the next
> step, right?

You don't have a single point of entry, your application is distributed
among many functions, you may not get the whole request at once, you
might not be able to send the whole response at once, etc.

You need to modify the http_parse_request function to understand the
websocket request. Then you have to serve your response instead of the
server's standard response with is send_headers + send_file.
If you don't return the proper value, your data won't be sent. If you
hog tcp buffers, your data will stop being sent and nothing else will work.
Then, you have to patch other functions so next coming dara is sent to
your websocket server and not rejected as unknown data. Essentially,
HTTP was not conceived as a bidirectional protocol and so is the server,
so you might find this is not easy to do.

Your first step now should be to determine if the web server your vendor
provided is the one in the lwIP contrib tree or it was modified by them.
I don't see references to decodeHttpMessage() (and it doesn't follow the
lwIP group code standard guidelines for naming convention)

$ grep -R decodeHttpMessage *
$

so my bet is that that webserver does not belong to lwIP but your vendor.
Then, you have to choose whether:
        you'll use that webserver, in which case you should ask your vendor for
help
        you'll use the contrib tree webserver, in which case you'd ask this
list for help
        you'll use my fork of the contrib tree webserver, in which case you
would ask me for help. If you are not in a hurry, I can try to add
support for this to my server, but I'm quite busy right now.

Regards

-- 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]