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.