"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 <[email protected]> wrote: > On Thu, 2010-10-14 at 09:25 -0400, Dany Thiffeault wrote: > > 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. > > "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. > > Kieran > > > > _______________________________________________ > lwip-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
