> On 28. Mar 2019, at 08:02, Sven Van Caekenberghe <s...@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
