Re: [lwip-users] Non-blocking netconn_write?

243 views
Skip to first unread message

Kieran Mansley

unread,
Oct 14, 2010, 5:09:32 AM10/14/10
to Mailing list for lwIP users
On Wed, 2010-10-13 at 13:43 -0400, Dany Thiffeault wrote:
> Hi,
>
>
> I just found out that "netconn_write" is blocking indefinitely, or
> until the operation completes. This is a problem for me. I'm currently
> testing my system to react correctly when an Ethernet disconnection
> occurs. There are safety features I must implement and one of them is
> to stop everything as soon as I detect a disconnection or a
> communication problem over Ethernet.

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

Kieran Mansley

unread,
Oct 14, 2010, 9:32:52 AM10/14/10
to Mailing list for lwIP users
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.

Bill Auerbach

unread,
Oct 14, 2010, 10:21:32 AM10/14/10
to Mailing list for lwIP users
>> for safety of people around the device.
>
>"for safety"? That worries me!

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

Reply all
Reply to author
Forward
0 new messages