Sidney Markowitz writes: > I've been thinking about why the DNS tests have uneven failures and came > up with a conjecture. Since DNS queries and replies use UDP, delivery is > inherently unreliable. What if when many queries are sent out at once > there is a chance of too many responses appearing at once and some get > lost? Perhaps my satellite connection makes it worse because the high > latency and burstiness causes packets to queue up and then try to arrive > all at once. > > If this is the case, maybe we could configure a maximum number of > packets to send in the background (bgsend) and put the rest of the query > packets in a pending send queue. When a reply packet is received and > removed from the pending reply queue, we could take another packet off > of the pending send queue and bgsend it. That way we keep things going > in the background to the maximum extent that still allows it all to work. > > What do you think of this?
as far as I know, in "real world" terms nowadays on most internet links, UDP is pretty damn reliable most of the time; I would say it's more likely timeouts, and in particular that scaling-timeout issue you've identified before. (Maybe the scaling-timeout algorithm is particularly ill-suited to satlink latencies/burstiness.) It might be worth breaking out tcpdump to see if you can observe what's happening on your line. Also have you checked /etc/resolv.conf to ensure it's using a good nameserver first? remember, Net::DNS only uses the first one listed, it won't failover like other resolvers do. Are you happy with putting out an rc3 anyway? --j.
