|
From: | Dany Thiffeault |
Subject: | Re: [lwip-users] Non-blocking netconn_write? |
Date: | Thu, 14 Oct 2010 10:10:57 -0400 |
"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."Yeah, that's what I was thinking. Don't worry about the safety, it's just that our product is used in environments that are restricted by many rules, so we need to fit everything :)On Thu, Oct 14, 2010 at 9:32 AM, Kieran Mansley <address@hidden> wrote:On Thu, 2010-10-14 at 09:25 -0400, Dany Thiffeault wrote:"for safety"? That worries me!
> Thanks Kieran.
>
>
> Well... a non-blocking call returning an error would be great for me
> if there is a connection problem. I could then detect an error when
> writing the packet and close the connection and shutdown some stuff
> for safety of people around the device.
This is a common problem, but it's just the way that the sockets API and
> 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.
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.
Kieran
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
[Prev in Thread] | Current Thread | [Next in Thread] |