On Oct 5, 2013, at 10:50 AM, David Stainton <dstainton...@gmail.com> wrote:
> > Right. I gave my class one of these: implements(interfaces.IPushProducer, > interfaces.IReadDescriptor) > Which means that I can easily write a class that implements IConsumer > to do something with the packets. > > https://github.com/david415/hushVPN/blob/master/nflog_reader.py After a brief glance, this stuff looks pretty cool. Very much in the spirit that these interfaces were developed in. (And you chose the correct producer interface; the other I*Producer interfaces are pretty much just legacy junk, sorry about that :-)) One thing to note, though: you should switch to this style: @implementer(IPushProducer, IReadDescriptor) class NFLogPacket... because the implements() style won't work in future versions of Python. (Plus, the implementation of @implementer is much cleaner on older versions too.) -glyph > This is basically a packet sniffer which receives packets based on iptables > rules. > > After that I wrote proxy consumer/producers too; classes that implement both > IConsumer and IPushProducer; > this allows me to transform the packets before sending them to a transport. > > I was inspired by this doc: > http://twistedmatrix.com/documents/12.2.0/core/howto/producers.html > > So far I really love Twisted! > > > On Wed, Oct 2, 2013 at 3:14 AM, Phil Mayers <p.may...@imperial.ac.uk> wrote: > 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 > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
