2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길: > 이희승 (Trustin Lee) wrote: > > 2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길: > >> Eero Nevalainen wrote: > >>> Btw, what was the status of DNS resolution in MINA? I remember that at > >>> some point DNS resolving used the blocking java API calls. I could > >>> imagine that an asynchronous HTTP-client would have to perform a lot of > >>> DNS queries(or not, depending on use). Could this become a pithole? > >> That's a very good point, Eero. I think blocking DNS lookups could > >> definitely be a very big pit hole. Did anything ever come from all the > >> asynchronous DNS lookup discussions? > >> > >> And that's not the only DNS issue. If a DNS returns multiple A records > >> for a given host name, most browsers will try to connect to the IP > >> address from the first A record. If that fails, they'll try the next IP > >> address and so on until the connection succeeds or all of the A records > >> have been exhausted. We should support this same behavior in AsyncWeb. > > > > I thought it's the operating system who decides which A record to use > > and it's often random round-robin style. Is there any related > > documentation or is it from your experiment? Just curious. > > The way Mozilla browsers handle DNS Round Robin is explained here > http://www.mozilla.org/docs/netlib/dns.html under the "Round Robin > Support" section. > > > It would be nice to have a built in DNS lookup mechanism in MINA as we > > discussed in our previous discussion, but once the domain name is > > resolved, it will be cached by the operation system, so it shouldn't be > > a big problem in most cases. It will of course be a problem if someone > > is writing a web robot or something similar. > > I do agree that in most cases it won't be a problem.
Thanks for the link to the documentation. So, I guess we need some pluggability in domain name resolution. For now, we are using InetSocketAddress and as long as we depend on it, we don't have any control over how domain name is resolved in MINA. This mean that we need to provide our own endpoint representation classes. It will probably cause the major API change, but I think it worth to do this. How does that sound? Will we need to implement this in 2.0 or... in 3.0? :) -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
