GetHostEntry() Blocking

TinyCLR OS
1

Is there any way to get around GetHostEntry() locking everything up if it can’t get a reply from the DNS server?
My testing device is plugged into a switch and uses fixed IP addresses. However, there is no connection to the internet. GetHostEntry() blocks UI updates and all other code.

Any suggestions would be helpful.

1 Like
2

Hi Steve, is there any way to check if Internet is connected before making the call to GetHostEntry()?

3

I could ping Google’s DNS (8.8.8.8) to see if there is an active connection out to the internet. Is it possible to send a ICMP Ping in TinyCLR?

4

On what thread is the DNS lookup running?

5

You could try pinging the dns server first or is it that you can’t get an IP address either?

6

The call to GetHostEntry() is on a thread different from the UI and other functions. However, everything locks for about 10 seconds before an exception is thrown.

7

The IP address of the TinyCLR is set by the user, as well as the gateway and DNS addresses. Since it’s connected to a network switch embedded on the same circuit board the network appears active and has a link.

Pinging could be an option if TinyCLR supports the setup of a raw ICMP socket which I don’t believe it does. A timeout on the request would be best. I am not sure what would happen if the DNS was on the local router but the local network still didn’t have a connection to the internet. If the local router is just forwarding the request out to the internet but it can’t get there I don’t know if the result would be the same.

Ideally the GetHostEntry() call would not block all threads and have a reasonable timeout.

I will post a GitHub issue and see if there can be any resolution.

1 Like
8

I added this to the GitHub issue, but repeat it here for this audience…

To be honest, this is a problem throughout the stack. Most networking calls block the interpreter, when one would hope that the interpreter keeps running, and only the calling managed thread gets blocked. It’s probably a pretty big mountain to climb to fix this because you would need to offload networking calls onto a dedicated native thread that then notifies the interpreter rather than blocking it from running at all. It’s a huge and often deal-braker issue in terms of keeping an app responsive, but it’s also probably a Big Deal to try to fix.

9

I’ve had the same issue–used to sync the RTC with an NTP server based on a DNS address. I haven’t found a way to fix the blocking problem, but I have noticed a few things that help.

  1. Make sure the network settings are all correct, especially the LAN DNS address and gateway values.
  2. Once a DNS is resolved to an IP, save the IP (if that’s an option) and just directly use that instead of parsing the string again.
  3. Throw a try catch around the parsing if not already, sometimes the connection is just weak depending on sorts of issues.

I agree with @mcalsyn though that I think it’s a deeper issue with a mountain of overhead to fix. Similar, holistic style blocking methods in other network classes such as ethernet. It’s kind of unfortunate :confused: