-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sidney Markowitz writes: > Matt Sergeant wrote: > > I didn't think you could do that because in newer versions of Net::DNS > > the id is a lexical variable. The only way to reinitialise it is to > > reload the module. > > If I remember it correctly, Justin's code keeps its own counter and sets the > packet ID after creating the packet, making it independent of Net:DNS's > counter. Yep, our code just uses its own counter, and avoids using Net::DNS' counter code as much as possible. > I guess that would break down if there are any uses of Net::DNS by the same > process that do not go through his code. If that is what is happening and it > results in ID collision, the fix would be to use code like yours to reload > the module and rely on its own counter. I'll try that now that I can > reproduce the problem myself (painful as it is). That should not be a problem, as long as Net::DNS uses a different part of the ID space and increments separately: Net::DNS: 123456789... our code: 123456789... I have a hard time figuring out how Net::DNS could be using the same counter value, since it just uses rand() to seed it and counts consecutively from there by default -- plus there's very few places we still use Net::DNS::Resolver::search() or bgsend(). I think collisions with Net::DNS are a red herring. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFCbpe8MJF5cimLx9ARArW6AJ9cla2VSn6TKzomdMrBptXhdUPl/wCeLmJi qmt5sNEb2NKbvIuV+H7NlR8= =nJpD -----END PGP SIGNATURE-----
