Hi Leonardo,
I have written a Websocket server on top of lwip, and can try to help
you directly.
Just briefly looking at the code you posted though, a lot seems to be
missing though. Certainly, there is no way to tell if you are properly
returning a Websocket handshake given the code provided. Do you have
more detailed code that you want me to look at?
Mike
On 10/26/2015 10:39 AM, Leonardo Martínez wrote:
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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
Leonardo.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
