I have used the Mountaineer Ethernet board to implement a control type application (temperature control). The basic functions are all working. I want to use the LAN to send email notifications, and provide a simple REST based Interface for clients. This is a headless device that should run 24/7. NTP time synchronization is done with the Toolbox utilities. The Gadgeteer WebService is used for the REST Interface. My problem is that the Ethernet device is not properly telling if the netoek is down. If no cable is connected the IsNetworkConnected and IsNetworkUp flags are still set. The WebServer throws exceptions, the Dns.GetHostEntry() throws memory exceptions. Alltogether it is pretty useless for such an application. If the network Brakes or no connections are available, or if no Internet is available the System has to work still. In the case of re-establishing the netowrk all services / clients (WebService, email client etc.) have to work again. Maybe this is an issue of the NETMF framework or of the manufacturer specific implementations - whatever is the reason - it does not work as expected.
This is mostly not a problem with the framework or the specific implementation.
I find that 80% if the code I write, while doing socket communications, is handling the situations when something goes wrong. Cables get pulled out, connectivity fails, DNS servers die, and connection gets terminated abnormally…
You have to be prepared for failure and handle the failures appropriately. Not being ready for failure is the path to failure.
You mean to use try/catch logic throughout your application.
To address some of your specific concerns, the network being down should not cause Dns.GetHostEntry() to throw out-of-memory exceptions. I would consider that a bug. You would normally expect some sort of SocketException in that case. The IsNetworkConnected and IsNetworkUp flags should probably also be false if there’s no cable connected. I would consider those to be implementation bugs, but I don’t know whether they’d be bugs in the Oberon port or in the core NETMF.
Mike is correct in the general case, however, that socket programming is riddled with intricacies and edge cases, and nothing ever goes according to plan.
Any news? Me i’m getting as well such type of errors!