Date: Tue, 31 Dec 2002 11:57:49 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-hackers@freebsd.org Subject: Re: Multi-threaded or async Mozilla (NSPR, really) Message-ID: <20021231115748.GA73141@happy-idiot-talk.infracaninophi> In-Reply-To: <200212310156.gBV1ukw03272@sheol.localdomain> References: <20021222071854.A86914_sheol.localdomain@ns.sol.net> <20021222154722.GA8522_happy-idiot-talk.infracaninophi@ns.sol.net> <200212310156.gBV1ukw03272@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 30, 2002 at 07:56:46PM -0600, D J Hawkey Jr wrote: > In article <20021222154722.GA8522_happy-idiot-talk.infracaninophi@ns.sol.net>, > m.seaman@infracaninophile.co.uk writes: > > On Sun, Dec 22, 2002 at 07:18:54AM -0600, D J Hawkey Jr wrote: > > > >> I can't imagine what Moz is doing within it's DNS code, even with the > >> serialized DNS lookups. If nslookup replies within fractions of a second, > >> why doesn't Moz?? > > > > Take a look at look at the getaddrinfo(3) man page and then try doing > > a look up of the AAAA or A6 records for the troublesome locations. > > After looking at the man page, and understanding all of ~35% of it, I'll > ask this: Are you referring to the oft-mentioned, ill-configured, INET6 > records in some DNS servers, or are you referring to less-than-correct > code in FreeBSD's TCP/IP stack, or are NSPR's routines indeed flawed? None of the above --- although they may have an effect in addition to what's observed. It's sites that run DNS server software that doesn't do the right thing when confronted by a lookup of a RR type they don't recognise. Instead of returning a "not found" result, they seem to not reply at all, which leaves the machine asking the question no option but to sit and wait until the 30s timeout before it can assume it's not going to get a reply. Quite apart from the fact that a AAAA request (let alone A6 or DNAME or any of the other more recently introduced types) is hardly that exotic nowadays and any reasonable DNS server software should be able to cope, even if there is no appropriate data available. It's particularly annoying that the prime culprits always seem to be the companies that run banner adverts, and you're left waiting for some silly top of the page image before your browser will render the rest of the page which it has retrieved quite smartly. I've found the http://www.theregister.co.uk/ quite often suffers like that. Of course, just telling Mozilla to refuse the images from the advertiser makes things a whole lot nicer. > I guess I'll ask this, too: is getaddrinfo(3) called by gethostbyname(3)? > It's the latter that Mozilla/NSPR calls, and is the blamed culprit. Hmmm... it seems not to. My misunderstanding, although it doesn't detract from my main point. According to the man page getaddrinfo(3) is apparently a more modern replacement for gethostbyname(3), and I'd read that as implying that it handled IPv6 whereas gethostbyname(3) didn't. However, a quick peek at the gethostbyname(3) source shows that it is IPv6 capable too, and that gethostbyname(3) doesn't call getaddrinfo(3) or vice versa. > For giggles, I disabled INET6 in the kernel, re- built and installed it, > and the problem vanished. But this doesn't answer the question: Is it > problematic DNS records, a problematic OS, or what? The second, I doubt... It is no fault of yours, for using an OS that follows standards like RFC 2553 which have only been around for 4 years. Eventually, the rest of the world will catch up... > Windows: "Where do you want to go today?" > Linux: "Where do you want to go tomorrow?" > FreeBSD: "Are you guys coming, or what?" Exactly. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021231115748.GA73141>