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]> 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] > https://lists.nongnu.org/mailman/listinfo/lwip-users > -- Leonardo.
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
