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... Would a NFLogProtocol and factory like this be usable? Sorta like this? https://gist.github.com/david415/6790543 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? I don't know about the nflog file descriptor... but the nflog generator interface is non-blocking if used like this: def doRead(self): pkt = self.nflog.next() while True: self.handlePacket(pkt) pkt = self.nflog.send(True) if pkt is NFWouldBlock: break My nflog reader seems to work great. On Wed, Oct 2, 2013 at 12:26 AM, Phil Mayers <[email protected]>wrote: > On 10/02/2013 07:14 AM, David Stainton wrote: > >> Hi, >> >> I am wondering how I should combine various twisted interfaces >> in a way that makes sense. It probably shows here... that I'm new to >> twisted. >> >> The Linux iptables can log packets to the netfilter_log which can give >> access to user space. >> I wrote a simple twisted Reader (IReadDescriptor implementation) that is >> working functional code... >> https://gist.github.com/**david415/6789612<https://gist.github.com/david415/6789612> >> >> But since these are packets it returns... should I implement a "read >> only Protocol"? >> > > Well, if your transport is not writable, just don't implement that - > Exceptions will be raised if you mistakenly try to write, so nothing bad > will happen. > > > The protocol's dataReceive() method could be called from the >> NFLogReader's doRead() method. >> > > Since they're packets it should really be a DatagramProtocol and call > datagramReceived. > > > Does this mean that NFLogReader would be responsible for calling >> buildProtocol to construct the NFLogProtocol? >> > > Typically a factory is responsible for calling buildProtocol, but in most > datagram uses, there is only one protocol instance per port, so you just > instantiate it. See e.g. > > http://twistedmatrix.com/**documents/current/core/howto/**udp.html<http://twistedmatrix.com/documents/current/core/howto/udp.html> > > > In the normal Twisted examples the buildProtocol seems to be called from >> the react loop.. >> Should I pass the protocol factory and the reader to the service? >> > > Sorry I don't know what this means. > > > >> If I want to drop privileges right after retrieving the filedescriptor >> for netfilter_log, shall I use a Twisted Service/Application to drop the >> root privs to a non-superuser? >> > > That would be the "Twisted" way of doing it, yes. > > > Should the privileges be dropped by the privilegedStartService() method? >> The manual says that method is for preparing to drop services... >> >> What I want out of all of this is the most high performance and general >> solution to utilizing netfilter_log in twisted... >> > > Couple of general points: > > The nflog_cffi code is... hard to read. But it's not obvious to me that it > sets the FD to nonblocking anywhere, or that it's (frankly weird) generator > construct will actually yield the "nonblock" marker object at the right > times. You might want to test this. > > On a different note, a colleague wrote some code to process the IPQUEUE > target of iptables a while back. This code did something similar to your > example above, but it didn't bother integrating with the protocol/factory > machinery, and you could consider whether it makes sense to do so - unlike > a TCP or UDP port, you're unlikely to ever have >1 nflog "connection" > per-process, so it's not obvious that using the full generality of the > factory/protocol machinery is appropriate. > > However if you do that, I would just copy what Twisted does for UDP; don't > model it on TCP. > > ______________________________**_________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.**com <[email protected]> > http://twistedmatrix.com/cgi-**bin/mailman/listinfo/twisted-**python<http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python> >
_______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
