> On 24 Feb 2017, at 18:56, Sven Van Caekenberghe <[email protected]> wrote: > >> >> On 24 Feb 2017, at 18:14, Ben Coman <[email protected]> wrote: >> >> >> >> On Mon, Feb 20, 2017 at 6:27 PM, Sven Van Caekenberghe <[email protected]> wrote: >> >>> On 20 Feb 2017, at 10:30, Pavel Krivanek <[email protected]> wrote: >>> >>> >>> >>> 2017-02-20 10:27 GMT+01:00 Guillermo Polito <[email protected]>: >>> As far as I remember, the main problem was not bandwidth but a blocking and >>> non-responsive UI. >>> Imagine I'm in the university, or in a company with a proxy. And I forget >>> to set the proxy. Then, while spotter tries to fetch catalog entries, it >>> would block the image and throw a timeout error some minutes after. >>> >>> So, maybe for the future and besides Ben's C option (which I like) I have a >>> >>> D) Load catalog entries in background in a non-blocking way >>> - and while catalog entries are not yet available, they should not be shown >>> >>> AFIK the main problem was that there was not possilbe to do it non-blocking >>> way. >> >> Yes that is true. (It is actually DNS resolving that is blocked in some >> freak case). >> >> In sqUnixSocket.c I read... >> * Notes: >> * Sockets are completely asynchronous, but the resolver is still >> synchronous. >> >> So does this mean that if for any reason the resolver primitive takes a long >> time to respond, >> the whole VM is blocked? Thus forking the Catalog loading in another thread >> would have no benefit? > > Yes and yes. > >> Would having the resolver coded purely in-Image behave better? > > Yes (probably). > >> So a slow name resolution would not hold up the whole image if it happened >> in a forked thread. > > Yes. > >> I found such an implementation in OpenCobalt and after some minor cleanup >> basic operations work fine. >> >> http://smalltalkhub.com/#!/~BenComan/DNS/ > > Well, I did one myself too (I have not looked at the one above, I will), but > my conclusion was that it is not that difficult to get basic lookup working, > but edge cases (like concurrent requests with intermixed answers) are not so > easy. > > There is also a chicken/egg problem: what DNS resolver (host) will you > contact ? How to find out the one configured by your OS ? My idea was to use > the Google ones (8.8.8.8), but there is also a more open one (80.80.80.80) > and probably others. > > We are often accused of reinventing the wheel and carrying the burden of > maintaining all that infrastructure. Doing our own DNS client would add to > that. > > But I like the general idea, the question is one about development risk.
So Ben, I could not get the code to run (on Pharo 6) using UDP, it remained stuck on sending the UDP packet, which is really weird. I found my old code, turns out it was based on the same message/packets hierarchy. And it still worked. I committed it to your repo: === Name: Net-Protocols-DNS-SvenVanCaekenberghe.15 Author: SvenVanCaekenberghe Time: 24 February 2017, 8:08:54.299786 pm UUID: 9b8fa332-ad05-0d00-8577-5adb00d43870 Ancestors: Net-Protocols-DNS-BenComan.14 Added NeoDNSClient to Net-Protocols-DNS-Experimental === You should be able to do NeoDNSClient default addressForName: 'stfx.eu'. There is no caching yet, but there is a simple #beThreadSafe provided. (My other comments remain valid, also for my own code). Sven >> cheers -ben >> >> But the thing is, the problematic situation only occurs for a very small >> percentage of people, like less than 1%, probably even much less. (Remember, >> nobody can produce a repeatable case for it). >> >> So the question is, is that enough reason to act as if we are still in the >> 90's when internet was a luxury and cut features that depend on it ? If you >> have no network today, you're in big trouble anyway. (Again, if you turn off >> your network, no blocking will happen at all, try it). >> >> So what is more important ? The general functionality of the 99.xxx % or the >> unreproducible freak case ?
