http://bugzilla.spamassassin.org/show_bug.cgi?id=4260
------- Additional Comments From [EMAIL PROTECTED] 2005-04-26 22:08 -------
Theo, I think the whole thing about the ID is a red herring that we fell into
when we saw that there were collisions.
Here's how I remember our getting to this point:
The original problem was that we did not make use of the ID at all and we had
persistent_udp set. The persistent_udp setting is only used by send(), not by
bg_send. It causes Net::DNS to reuse the udp socket. The only time that caused a
problem was going from the calls to send() in the first queries to the
nameservers, to the calls to bgsend used in the RBL queries. The very first call
to bgsend used the same port as the calls to send(). This resulted in sometimes
a stray reply arriving that was picked up as one of the bgsend replies, because
the ID wasn't checked.
Justin implemented the single-socket code. I didn't notice how Net::DNS
increments the ID counter and I suggested something that involved keeping track
of a counter ourselves. That's where all the ID stuff came from.
We still had collisions that show up in mass check. I think that is caused by
each process being so long lived and using just one socket that the ID numbers
wrap many times.
The solution as I see it is to not have any one socket be so long lived. If we
create a socket for each message and close it when the message is done, then the
ID counter code that is in Net::DNS already should be sufficient. Creating a
UDP socket is an inexpensive operation compared to processing a whole message,
just allocating a data structure. We would not have to maintain our own counter,
figure out how to initialize it, etc. It could be done with a call to
DnsResolver->connect_sock in new PerMsgStatus, and a call to
DnsResolver->{sock}->close in PerMsgStatus->finish, and ripping out the new
counter code so that Net::DNS sets the packet ID when the packet is created, and
then we get the ID from the packet.
In addition, I think that it is a bug that the socket created in DnsResolver has
ReuseAddr set to 1.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
