On 02/10/13 09:25, David Stainton wrote:
In examples of Twisted UDP clients they all do this: reactor.listenUDP(3000,MyProtocol()) What would I do instead? reactor.addReader makes sense to me since what I have is a file descriptor, and the reactor loop and use select or epoll find out when there is data to read... and call our doRead() method of the Reader. I don't know about implementing this as a Protocol because I do not have any equivalent to ReactorUDP. ReactorUDP's listenUDP returns a ListeningPort. And I'm not sure how a Transport is related to my Reader... but it seems to me that there is some abstraction which sets callbacks for io and also calls buildProtocol...
Sorry, maybe I was unclear: you were asking about protocols, so I was merely pointing out that *if* you were to use a protocol, you should copy the approach DatagramProtocol and udp.Port take.
However as I noted, it *might not* make sense to do this, if there's only ever going to be one socket listening on this "thing", your current approach might be fine.
If I am going to be using a Twisted Service to drop privileges after gaining access to the fd... How would I do this? Would I have startService() instantiate a Protocol instance?
As above, it depends. If you're using Protocol instances, then yes. If not, then no.
Services are just things which start and stop; they may or may not use objects implementing the transport/factory/protocol pattern.
I don't know about the nflog file descriptor... but the nflog generator interface is non-blocking if used like this:
Ok. Weird API, but if it works...
My nflog reader seems to work great.
If it works for you, and you're using documented Twisted interfaces, then there's probably no need to fiddle with it.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
