The problem you'll have with this is that the return code and error
setting for the netconn_write() (and similarly for sockets API built on
top of netconn) will not be correct. The code has to wait for the write
to be successful to know that it can return success. If there was an
error it must report it.
Does do a non-blocking write call instead help you?
Kieran
_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
"for safety"? That worries me!
> I have a device that is acquiring data and streaming everything on
> Ethernet. So, the majority of the time when streaming, the application
> is writing data on the Ethernet port. So, if I disconnect the Ethernet
> cable or another communication problem occurs that "hangs" the thread
> in the netconn_write function, I cannot detect it.
This is a common problem, but it's just the way that the sockets API and
TCP are designed: they try to be resilient to connection breakages and
hope that the connection comes back. I would suggest using a different
thread to monitor the link state (not through lwIP) and base your
decisions about connectivity on that.
Me too! I would add a UDP pinging type of feature that is the minimum time
that you can live without the connection. A missing ping means it's
disconnected (effectively). I did this with a 1/2 time ping so I needed to
miss 2 pings to be disconnected just in case one is dropped.
Bill