Hi Sandra,
You seem to have an issue that gets noticed with a traffic pattern. Try
to find a way to log stats somewhere because I can't imagine a way to
figure this out without logging or real-time debugging.
Try ARP flooding locally, maybe you are lucky.
You might have an improper driver leaking m
Leonardo,
you have some board using some port from some manufacturer which uses
what API interface ? And runs with or without an RTOS (NO_SYS) ?
And that webserver is ?
As I see from your code, it looks like it is the RAW API with callbacks,
however, you are interacting with the webserver code, no
> - 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
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.
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 provide
Hi Mike,
Thanks for helping me.
Here is the code that calculates the response and do the parsing in look
for the handshake. It is still pretty primitive but I wanted to get it to
work first, at least for chrome, and then I would try to cover more cases.
static bool decodeHttpMessage (char * input
> What do you mean with proper value?
I mean the value you return when you exit in a function, the whole web
server code knows what the callee has done and needs to be done by means
of the returned value.
--
___
lwip-users mailing list
lwip-users@non