Sidney Markowitz writes: > I got some interesting results on some tests. I added a delay at the end > of new_dns_packet in DnsResolver.pm to test the theory that the problem > is related to all the reply packets showing up at once. I don't know if > the results support that specific theory, but it did make a difference. > > Before I made the change, only one reply was received, for the first > backgrounded query of the 76 that are sent out during the t/dnsbl.t test. > > When I introduced a delay by adding select(undef, undef, undef, 0.1) in > new_dns_packet, more replies were received until the delay was up to 1.1 > seconds, at which point I got between 53 to 56 replies received out of > 76. There was no further improvement when I continued to increase the > delay. I went up to 5 seconds. > > These tests were run under Cygwin. I don't see a difference between > running und win32 and cygwin on the same virtual machine.
Have you captured the traffic with tcpdump, to see if the packets are getting there to the IP stack or not in the first place? by the way that select() would give timeslices to other processes... maybe some aspect of win32 resolution relies on the DNS resolver DLL getting scheduled, whereas that isn't the case on UNIXes. > Running on the same real machine under MacOS X doesn't have these > problems, so it is not solely caused by strange characteristics of my > satellite Internet connection. Worth noting. --j.
