twisted.names.dns: DNSDatagramProtocol doesn't release unused UDP-ports

[pittipatti]

In class "DNSDatagramProtocol" the function "startListening" attaches a UDP-port to the reactor, but leaves it attached even when the protocol is closed.

In my application I have to create new resolvers for querying many different nameservers.

Please have a look at the attachments with sample code which results

1. in many listening UDP-ports ( please see in another console: netstat -anpu | grep python )
2. in a (rather strange) exception (ImportError: cannot import name SHA)

As mentioned above, DNSDatagramProtocol.startListening() executes reactor.listenUDP, but the returned port isn't saved anywere, so it can't be closed. I saved it as a instance-variable but have no clue where to call the stopListening()-function, since DNSDatagramProtocol.stopProtocol() or DNSDatagramProtocol.doStop() don't seem to be called at all.

[pittipatti]

Example 1

[pittipatti]

Example 2

[exarkun]

doStop (and stopProtocol) are called when the DatagramProtocol is no longer associated with any port. So they're not appropriate hooks for disassociating a DatagramProtocol with its port. ;)

The result of reactor.listenUDP is saved, although in a somewhat roundabout manner (it's necessary in order to send the DNS traffic, after all). Once the port is set up, it is passed to DatagramProtocol.makeConnection which is implemented to save it at the transport attribute. So you do have a reference to it, via the transport attribute of the DNSDatagramProtocol. However, your application code still has no reference to it, since you have a Resolver (or worse, a ResolverChain), not a DNSDatagramProtocol.

I don't think the protocol can know when to clean itself up. Perhaps Resolver should have an API for cleanup, though, so that applications, which do know when to clean things up, can perform the necessary cleanup.

However, it may be that what you really want is for the server to which the query is sent to be more easily controlled. You don't have to have a different UDP port for each server you're querying, it's just that the Resolver API currently makes it difficult or impossible to specify the server to use for each query. If this were possible, you could have a single UDP port and issue all of your queries over it.

[jknight]

Probably superseded by #3342.

[exarkun]

Fixed in r24401