On 28. Mar 2019, at 08:02, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Holger & Norbert,
great. Regardless of how many versions exist. We should get one into the image with proper platform integration. I wasn't aware of your code but I assumed it is something you could write, hence the Paleo prefix. Now that the Paleo code is the Neo one is more funny...
NeoSimplifiedDNSClient default addressForName: 'pharo.org'. "104.28.27.35"
One of my goals was to use it as a more reliable, non-blocking 'do we have internet access' test:
NeoNetworkState default hasInternetConnection. "true"
What is internet access and how would this be used? Is this about captive portals? With local network policy the big anycast services might be blocked but the user can still reach services. Or with deployed microservices they might reach other but not the outside? ... snip ...
The main problems are concurrent and asynchronous requests, as well as error handling.
I would be great if we could do this well in-image. (But getting OS DNS settings is hard too).
We should talk ;-)
Agreed that getting the OS DNS settings is hard but not impossible (go seems to get away with its implementation on unix). It seems we manage to honor platform settings for http proxies and I am confident we can do it for DNS as well. I planned to solve concurrency by creating one stub resolver per request and having a shared cache. The internet can be a hostile place and DNS is an easy victim. Cache poisoning does exist and random source port, 0x20 randomization, random transaction ids, disrespecting PTMU ICMP messages are the few mitigations we have. Let's definitely talk. I hang out in the pharo discord group. :) holger