Theo Van Dinter wrote: > I'm trying a small patch which basically calls the reinit function when > the counter wraps to 0, as well as using rand when initializing. This way > it'll get a new random starting point and a new socket occasionally.
I think I understand the problem now. It's similar to what you said. I noticed when debugging t/dnsbl.t that the one message in it generates 52 DNS queries. When there are tens of thousands of messages in a mass check and -j=4, there are going to be several wraparounds of the 16 bit ID. Apparently nameserver responses can arrive quite late. My guess about the slowdown you saw when using the sha1 patch is that while it avoided errors from collisions, all the old reply packets were still read and hashed before being discarded. A fix would be to close and reopen the socket at each message, or as you suggested when the counter wraps. But it should not be when the counter wraps to zero, it should be when it wraps to its initial value. I think it would be better to create the new socket with each message. If old replies are arriving as they seem to, wouldn't it be more efficient to not have a listener on the socket when they arrive? -- sidney
