Re: [lwip-users] LWIP and Websockets

[Leonardo Martínez]

I understand what you are saying but I don't get how is not a single entry point: TCP_RECV is "Used to specify the function that should be called when a TCP connection receives data". This function has to be fired when new data comes. I can get that this process may have to be retried many times.

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.

That's what I thought... What do you mean with proper value? It is supposed to be a error check before it is sent to the browser? I thought the package was checked in the browser. I also tried to use hercules to exchange TCP messages and it seemed to work fine. 

Hog? If I close the connection, it will be hogged, right? That's what I am suppose to do...

decodeHttpMessage is a function I created to do the parsing of the requests. I guess the server belongs to Atmel but I will check.

I came to this post as the base of the project is from lwip: tcp_recv, tcp_poll, tcp_write, tcp_abort. It didn't seem that complicated for me at first as it was a short .c file with calls to LWIP functions...

Thanks for your help.

On Mon, Oct 26, 2015 at 1:51 PM, Sergio R. Caprile <address@hidden> wrote:

> - 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

--


_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users

--

Leonardo.